A Tale of Two Factories: Chapter 6 - The Great Divide

When management wants to make something happen, they change the structure of the organization.  Whether its ad-hoc project teams to deliver a product or service, or departments developed around specific disciplines such as IT, engineering, procurement, or accounting, organizational structure provides the framework for business execution.  It can also be a significant hurdle to successful change as people become entrenched within the practices of an established structure.  How does this impact manufacturing and engineering technologies?  This chapter examines how two organizations - Deuxieme Botte Manufacturing (DBM) and Premiere Chaussure Industries (PCI) – deal with the challenges of organizational boundaries.

The Divide at DCM

"I am not letting IT anywhere near my SCADA system!"  Dave was adamant; he'd experienced the late-night calls when operating system updates caused batch processes to fail due to software incompatibilities. He'd read similar horror stories of network problems that took days to diagnose, of governance-gone-wild where IT was specifying hardware in shop floor panels, of IT-mandated anti-virus software interfering with historian performance.  As more and more of his control processes were placed on the company network, Dave was increasingly feeling pressure to get IT involved with his systems.

"If you want those systems on the company network, you are going to need to comply with IT policies", responded Ellen.  Things were getting out of hand; Ellen remembered the time - not so long ago – when the only devices on the network were servers, office computers, and printers.  Now there were three or four times as many non-office devices connected either via wire or wirelessly as there were traditional IT-managed devices.  PLCs, CNCs, vision systems, remote I/O, barcode scanners, data capture devices – the list seemed endless, and it was growing.  "There are a number of risks that we need to manage, and the only effective way to do that is through policy compliance!"

"Ellen, I recognize the need for standards, but these control processes are finely tuned.  People who are not intimately familiar with them should not be accessing them – and that includes 'IT professionals'!"  Dave was choosing his words carefully; he knew several of the people in the IT department and didn't want to make them seem inept. "There are just so many details to be aware of that one inadvertent change can stop production – for days!"

"I understand what you're saying Dave, but it seems to leave us at an impasse.  I don't mean to tell you how to do your job, but I also can't put the company's IT assets at risk.  Any suggestions on how we might resolve this situation?"

Dave had anticipated this question. "You said 'if we want those systems on the company network'; what if we set up a separate network for our industrial control applications?"

"Not a bad idea", Ellen said after a brief pause.  "I've been to one or two IT conferences where this has been recommended as best practice.  Would Engineering own this network?"

"Why not?" Dave replied. "We already manage the servers hosting our industrial automation software, OPC servers, and data historians.  We're also managing programming for the controllers and user interfaces, and all the software licensing associated with it.  We've got our own little IT department going; including network management shouldn't be too much added burden.  It seems to me like the perfect solution – we don't violate IT policy and we can do what's necessary to make our engineering processes work."

Ellen winced at the thought of a "little IT department", but knew Dave was right.  That ship had already sailed, and Ellen didn't really have the staff to handle what Dave's group was doing anyway.

The Divide at PCI

It was the first time in anyone's memory that key representatives from finance, operations, quality, and engineering had been included in a meeting to discuss information technology.

"We are not going to have a 'shadow IT' within PCI!"  Rob, CIO of Premiere Chaussure Industries, had spent most of his career in manufacturing.  He was familiar with the importance of automation, quality, and engineering and had observed the growing reliance on information technology within these fields.  He had also experienced the divisions between these functional groups and the organizational ineffectiveness caused by those divisions.

"To quote Honest Abe", he continued, "'A house divided against itself cannot stand.'  It's both inefficient and counter-productive to the organization as a whole to have siloed pockets of technology based on specialized needs. Joe (VP of Operations) has been talking with the executive leadership team about creating a technology platform that embraces change.  If we are going to be successful architecting such a platform, we – IT, Finance, Operations, and Engineering - are going to need to build bridges between our domains of expertise.  Once we have this platform, we'll be able to effectively tap into the real-time information our automation systems provide.  We'll have the capability to restructure our organization to benefit from product lifecycle management, manufacturing operations management, and business process management technologies in ways that make strategic sense for this company."

Diane – lead Automation Engineer – spoke up. "How are we going to get these groups to work together?  We've been talking about 'bridging silos'" - she did the little air-quote sign with both hands – "for years, but never seem to make headway.  It's not like we don't know how to work together, we just have different goals and objectives."

Todd – head of Engineering Design – joined in. "We also respect each other's turf.  For example, I know the PLM tools we're using could fundamentally change the way the quality guys manage specifications and implement SPC, but it's not my place to tell them how to work."

Rob held up his hands in surrender.

"You're both right.  That's what this meeting is about.  It's been said that when management wants to make something happen, they change the structure of the organization.  That's just what we're doing.  We are creating a new team within PCI we call the Manufacturing Operations Center of Excellence, or MOCoE.  This team will be cross-functional, with representatives from each of your disciplines.  Its mission will be to help PCI align the capabilities of available technology with corporate strategy.  This team will not report to any particular department, but will report directly to the executive management team.  The MOCoE will be empowered to cross organizational boundaries to implement changes in the way we work."

"Todd – your example is a good place to start.  Product Lifecycle Management has the potential to radically change how we design and introduce new products, but has serious organizational implications as well.  It is likely that it will change business processes not just in Engineering, but in Operations, Marketing, Finance, Procurement, Quality, and R&D.  With such broad ramifications, it's easy to see why no single department could accomplish the necessary changes.  But without those changes, we may never gain the advantages the technology provides.  That's why the executive team believes so strongly that the MOCoE is needed."

Two Worlds

One of the greatest challenges to gaining true business benefit from technology is bridging organizational silos.  Initiatives such as MOM, BPM, or PLM often find their roots within groups such as engineering or operations.  Unless such initiatives are embraced by the entire organization, the benefits are marginalized.  In this chapter, DBM is maintaining - even strengthening – the boundaries between Engineering and IT.  They recognize the waste associated with duplication of effort, practices, and skill development but have no means of eliminating this inefficiency.  PCI is addressing the issue holistically through a center of excellence designed to supersede boundaries – allowing them to gain full benefit from the capabilities available within the technology in which they invest.  Such centers of excellence are a recommended best practice as taught in MESA International's global training programs. ​

A Tale of Two Factories: Chapter 5 - Studies in Change

"Is it us, or is it the technology?"  Whenever MES/MOM technology is discussed, the importance of change management is emphasized.  Chapter 4 of this series examined the architectural aspects of change – the importance of having a platform that flourishes with change.  This chapter delves into the "soft skills", perhaps the most difficult part of successful integration of technology into operations.  Once again, we examine change at two plants: Deuxieme Botte Manufacturing (DBM) and Premiere Chaussure Industries (PCI).

Change at DBM

Brian looked over the monthly figures again; as COO, he had a problem that needed solved.  While some areas of the plant were meeting asset effectiveness targets, others were not.  The software DBM implemented nearly a year ago was supposed to improve the visibility of the asset effectiveness so that plant personnel could address the issues and make corrections.  Brian saw the numbers in his monthly operations report, but the metrics were available on the plant floor on a real-time basis.  They had instituted process improvement teams – PIT crews, one NASCAR fan suggested – to deal with the causes of downtime, but it seemed to Brian – based on the metrics he saw – that those teams weren't all that effective, at least in some areas of the plant.  The system implementation costs and ongoing support costs had been justified based on meeting those effectiveness targets.

"Are we getting the ROI we were promised from this technology?" Brian wondered to himself.

John picked up his ringing phone and before he could even say hello, he heard "Hey John - Brian. I need you to do something for me.  I'm concerned that we're not getting the value from that asset effectiveness system we installed. We're going to be invoiced for annual support on this soon, and I just want to make sure the expense is still justified.  Can you investigate and make some recommendations?"

"Uh – Hi Brian."  As a Lean Facilitator and Industrial Engineer, John knew several techniques he could apply to answer the question.  "I think there are a few approaches I might use to help come to a definitive conclusion.  I might like to blend problem analysis, kaizen, and value stream mapping for this evaluation. I'm going to need several other people – perhaps a machine operator, a production supervisor, a maintenance tech, a PIT crew leader, an accountant, an engineering rep, and someone from IT.  Could you help me secure those resources for perhaps 3 days?"

Brian and John did the necessary haggling and horse-trading with supervisors and managers until they finally had the necessary people, place, and agenda for the event.  John's planning and pre-event preparation allowed the analysis to be completed in two days instead to the expected three.  Here's some of what the evaluation team learned:

• The technology was not delivering the expected return on investment.  While the process changes implemented did provide a positive net present value, they did not meet the corporate standard for payback period or rate of return.
• Process changes to improve asset performance were not effective:
• Many equipment operators weren't using the system.  "It doesn't tell me anything", one stated flatly.
• Some downtime causes required engineering changes to correct; there were no processes in place for PIT crews to engage engineering.
• Supervisors were managing to metrics obtained using methods other than the automated system.
• Some supervisors paid lip service to the new effectiveness metrics, but still managed based on production counts.
• There were multiple opportunities to integrate information from various systems to reduce paperwork, eliminate custom software applications and spreadsheets that would further enhance the value of the technology and improve ROI.

At the report-out, the primary recommendation from the evaluation team was that DBM continue to use the software in spite of the discouraging financial metrics.  Some organizational changes would be necessary to maximize the value of the technology investment.  Additional recommendations included a laundry list of applications and spreadsheets that could be eliminated through additional integration efforts plus a number of process improvements as depicted in the future state value stream map.  After he heard the recommendations, Brian thanked the team for their efforts, but left them with yet another question…

"Didn't we know that we would need to change the way we work after we implemented the system?  I really thought we had planned for these kinds of changes.  Were we not ready of the technology, or was the technology not ready for us?"

Change at PCI

As he looked at the walls upon which once hung the various line product counts and pace setters, Joe (VP of operations at PCI) recalled the conversation which initiated their removal.

"Organizational change is hard work", Joe remembered the MES/MOM consultant Steve saying. "Far too often I've had clients who believed that just implementing the technology and making a few process changes would be sufficient to get the promised ROI.  Too bad it doesn't work that way.  You know, people were able to accomplish their work before the technology was installed – they had procedures and 'rules of thumb' that allowed them to be successful enough that the company could turn a profit.  Often these things were so ingrained within the culture that people couldn't see the benefits of the technology.  Eli Goldratt calls these 'local optima rules' – because people lack a complete understanding of what's happening within the entire production process, they implement methods to optimize activity within their scope of control.  These practices are so strongly tied to the plant culture that they can inhibit an organization from gaining benefit from their systems."

Joe could see this was a hot-button issue with Steve – the passion was evident.  "Could you give me an example of 'local optima rules'", he asked.

"Sure!  Let's look at the MOM system we're putting in.  Without the technology, the management metric is total production per shift.  Do you recognize all of the unwritten rules that go along with this metric?  For example, what happens when multiple lines are producing for a specific order and the order quantity has been satisfied?  I know I'm over-simplifying here, but this is just an example for insight - when you're managing to production per shift, the line operator just keeps on producing.  Her other option is to become idle unless another product is scheduled and she can change over the equipment.  So what do you think would happen if her supervisor found her idle?"

Joe considered for a moment.  "I think I see what you're getting at.  The operator over-produces either because she doesn't know the order quantity has been filled – incomplete knowledge, or she knows but also understands that she's not being paid to be idle. She can't be faulted if she meets her per-shift quotas.  She optimizes based on her 'local' understanding of what's going on in the system."

"Goldratt has an axiom: 'Technology may only bring benefit if and only if it diminishes a limitation.'  He says that in order to obtain the benefit, you must not only understand the limitation and how the technology reduces the limitation but also understand the rules that allow operations with the limitation in place and the new rules once the technology has been implemented.  Change management needs to go beyond business processes – it needs to dig deeply into the culture as well.  If you say you are changing management metrics, you cannot leave the old metrics in place" Steve said as he gestured toward the production counters.  "They are entwined with the culture and the local optima rules – as long as those remain, people will not embrace the new rules which allow them to beneficially use the technology."

Joe remembered the capital request for installing the counters some years back.  "Sunk cost", he thought with a sigh.  He could see Steve's point – those counters would need to come down.

"So is that what people mean when they talk about 'technology adoption'?" Joe asked.

"'Technology adoption' is an implementer's perspective.  This is organizational change – it cannot be 'managed' into place, it must be led.  Can I tell you a funny story about leadership?" Steve asked.

"Sure!" Joe was always interested in anecdotes – you never knew when one might come in handy.

"My wife and I were at a funeral with several other out-of-town people in attendance.  As we were driving between the cemetery – where the gravesite service was held – and the church for the after-service gathering, my wife remembered that a relative had recently purchased a home near the church.  She had wanted to see it, so she asked me to take a slight detour.  We found the house down a residential cul-de-sac and stopped briefly in front of it.  As I looked in my mirror, I noticed six other cars behind us stopping in front of the house as well!  Without my knowledge, these folks had decided to follow my car to the church. We had a nice little parade!  But here's the point: if people think you know where you are going, and that you know how to get there, they will follow you.  It is human nature."

Joe chuckled – thoughtfully.

Two Worlds

The term 'change management' is not sufficiently comprehensive; change must be led as well as managed. DBM uses several change management techniques, but the company is still not getting the expected value from its technology investments.  The management team at PCI is discovering that the cultural aspects of change are significant as they consider the gap between "as-is" and "to-be".  As manufacturers consider MES/MOM technology, they must also consider how they will deal with change.