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.

A Tale of Two Factories: Chapter 4 - A Grief Observed

This is the fourth in a series discussing the impact of technology, production processes, and the intersection of where they meet – the production workers on the factory floor.  Chapter 1 demonstrated the differences in the impact technology has on two plants – Deuxieme Botte Manufacturing (DBM) and Premiere Chaussure Industries (PCI).  Chapter 2 described the strategic basis which eventually led to how workers at both companies experience technology.  Chapter 3 illustrated the underlying strategies each organization adopted toward plant floor system implementation. This chapter – contemporary to chapter 1 - compares the processes both organizations utilize to implement similar changes.

Change at DBM

Jeff had been thinking about the asset effectiveness system DBM had recently implemented.  Engineering and IT had collaborated to connect the PLCs which automated the production equipment to a data historian which collected information directly from the controllers and provided it for the new software to generate real time metrics.

"I'm spending at least 1 man-day a month having someone read the hour-meters on the production equipment, write that information on a clipboard, then enter it into the CMMS (computerized maintenance management system) so we can schedule PM (preventive maintenance) based on machine run time", he thought.  "I'd be willing to bet that the controllers also have total run time and even cycle count information available on them.  We could probably automate that whole process!"

Jeff picked up the phone and called Dave, the engineer responsible for the automation systems, and ran the idea past him.

"Doesn't sound like it would be too difficult", Dave said thoughtfully.  "Thanks to the asset effectiveness implementation, all our PLCs are now on the network.  We don't really have a standard which requires a tag for total run time or cycle count on all our PLCs though.  Some already have it, but I suspect others don't.  We would need to modify the programming on those that don't, but that shouldn't be too tough to do.  Some of our controllers are maintained by the equipment integrators though; if those don't already have the tags available then we'll need to contract the integrators to make those changes.  There may be other cost-effective options we could explore, but it really shouldn't be a problem exposing this information to the CMMS."

"OK, so hurdle 1 is getting the all the controllers to provide the data tags as a standard.  What's hurdle 2?" Jeff asked.

"Well, once the tags are available, we would need to collect the data from controllers into the plant historian, and then IT would need to do the 'wiring' between the historian and the CMMS", Dave replied. 

"Ah, so we'll need to get IT involved in this."  The thought didn't thrill Jeff; he knew the drill.  First there would be the business justification evaluation, then change prioritization, and finally (if luck was on his side) implementation.  But freeing a resource from the data collection and entry task seemed like a worthwhile effort, so Jeff thanked Dave for his input and dialed Ellen's number.  After Jeff explained his idea and Dave's thoughts, he waited for Ellen to reply.

"It sounds like a good approach to me", she said.  "I'll send you the link to the SharePoint software change request form and we'll get the process started.  I should tell you though that all of my resources are currently committed for the next 3 months.  But we could get a contract programmer in to work on this if the business case justifies it."

Change at PCI

Brad was pretty excited; the new servo drives PCI had purchased included real-time predictive analytics; they could sense when system changes were occurring and use this information to predict failure, in much the same way as vibration or oil analysis techniques could, but without the manual effort those techniques required.  He stopped by Mike's office (Mike's the maintenance planner and PM process owner) to share the news.

"We'll have to connect that capability to our maintenance planning", Mike replied.  "That way we'll be able to get a technician to correct a problem before failures occur." Brad and Mike discussed the mechanism for how the drives would provide the impending failure alerts, then Mike brought up a PM process in his workflow editor.  After mapping the new data item and modifying some process steps, he said:

"I'll put this new workflow in the sandbox environment.  Let's try it out for a while and we'll tweak it as necessary.  We can create some predicted failure event emulations to trigger the new process steps just to see how everything works.  Once we're happy with the changes, we can put the new workflow into the production environment and take advantage of the new servo drive capabilities."

Mike remembered the pain of the data centralization and governance processes IT had implemented two years earlier.  The brass had promised the exercise would eventually make life easier for everyone; while Mike had been an initial skeptic, changes like the one he had just made would have been time-consuming and expensive without a standardized platform.

"Standards such as S88 and Make2Pack are foundational, but successful organizations extend those to create their own standards tailored to the needs of the business", he recalled that consultant (Steve, wasn't it?) saying.  Mike didn't have a clue what those standards were, but the controls engineers seemed to understand.  Standardization didn't end with controls though; IT got involved and took charge of the "master data", then a "service bus" was implemented.  While these were all things Mike was happy not to know in detail, they did let him use the tools he understood – process workflows – to do things in a few hours that would have been stuck in IT's priority queue for weeks or months before this new architecture was in place.

Two Worlds

An environment that embraces continuous improvement must also accept continuous change as a result.  Information architectures must be designed in such a way as to thrive in changing conditions.  Lean kaizen, Six Sigma DMAIC, and ToC drum-buffer-rope approaches all require the ability to adapt to change rapidly, and traditional IT approaches are inadequate for such an environment.  While a Business Process Management (BPM) approach (as exemplified by PCI) may bypass the traditional IT models (in play at DBM), it must reside on top of an architecture based on standards and built for change.  The competitive advantage PCI has over DBM is clear – change comes simply and naturally.  PCI implemented the change in the time DBM spent talking about it.

What's next in this comparison of the two organizations?  We've yet to talk about IT costs, technology adoption, and ROI.  Check back for future installments of this series!

A Tale of Two Factories: Chapter 3 - Mere Maturity

This is the third in a series discussing the impact of technology, production processes, and the intersection of where they meet – the production workers on the factory floor.  Chapter 1 demonstrated the differences in the impact technology has on two plants – Deuxieme Botte Manufacturing (DBM) and Premiere Chaussure Industries (PCI).  Chapter 2 described the strategic basis which eventually led to how workers at both companies experience technology.  This chapter opens with characters we've met before: Earl and Ellen at DBM, and Joe and Steve at PCI.

Maturity at DBM

Earl found himself in Ellen's office – again.  Brian had asked to see the implementation plan for the new system; he had confided to Earl his unease with installing yet another software package when there were already so many – ranging from the ERP to the spreadsheets the line supervisors used for production planning – people needed to interact with on a daily basis.  He wanted to make sure this implementation would be done right, and that DBM would get real value from the investment.

"Don't worry, Earl", Ellen had said, "we know what we're doing.  Are you familiar with the Software Engineering Institute's Capability Maturity Model for Integration?"

"Never heard of it", Earl admitted.

"Well, it's essentially and assessment tool for determining organizational maturity across a range of practices.  There are many flavors of the assessment, and it provides a broadly applicable framework for road mapping the 'as-is' organizational capability to the 'to-be' state.  We have a customized version we're using to assess the people, processes, and technologies that will be affected by the new performance management system", she explained.

"That sounds like it's a pretty thorough analysis!  But what do you mean by 'maturity'?"

Ellen thought for a moment about the best way to define the term.  "We prefer 'capability maturity'; what we're referring to is the organization's ability to perform specific activities.  For example: if the process for managing asset downtime is poorly controlled and reactive, we would assess that to be a 'level 1' or 'Initial' capability maturity level.  If it is proactive, measured, controlled, and focused on continuous improvement then we would assess the process at 'level 5' or 'optimizing'".

"So the goal would be to move everything from an initial state to an optimizing state?" Earl ventured.

"Perhaps in the long term.  In many cases it's sufficient to move from a level 1 to a level 3 capability.  There are costs associated with increasing organizational capability maturity, so the challenge is to balance cost and benefit."

"I think I get it.  So the basic approach is to assess, road map, then create the project plan. So when do you think we can have the project plan ready for review?" Earl asked.

Maturity at PCI

"Capability maturity models are a good way to create a map from current state to future state", Steve said, "I use them myself.  But understand that there needs to be a larger context in which those models exist."

Joe and Steve had been discussing the approach IT proposed for implementing the new equipment effectiveness system.

"I think you're going to need to explain that to me in more detail", Joe said pensively.

Steve rubbed his chin and thought for a moment.  "Someone once said 'Management is doing things right; leadership is doing the right things'", he quoted.

Joe remembered the quote from the great "Are leaders managers? Are managers leaders?" debate of the late 1990's.  Was it Goleman, Cotter or Drucker who said that? Drucker, he decided.

"The CMMI is a management tool – it will help you do things right, but not necessarily do the right things" Steve continued.

Now Joe's interest was piqued.  Not knowing what he should be doing with technology in his plant operations was keeping him awake at night.  It seemed that – at last – he might be on the verge of an answer.

"So how do I determine what the 'right things' are?"

"That's never an easy question to answer", Steve replied.  "I think it's a mix of the leader's vision, the corporate strategy, and an effective platform for execution."

"OK, so I get it – I'm responsible for the vision, and we talked about the importance of a corporate strategy.  I'm assuming the technology is in the platform for execution."  Joe's frustration level was rising – he felt like yelling "WHAT DO I DO WITH INFORMATION TECHNOLOGY!"

Sensing Joe's mood, Steve replied "Yes; in fact researchers have suggested that the technology architecture is the embodiment of strategy.  As you might suspect, there are a couple models for platform architecture maturity growth which help determine what technologies you should be considering."  Pulling out his tablet, Steve brought up a slide deck and started flipping through it.  When he got to the appropriate slide, he showed it to Joe.

"This is the first model.  It's from the MESA International organization, and shows a 4-step change in organizational thinking as it relates to manufacturing system architectures."

"At the initial stage, individual applications are implemented to meet organizational needs.  Then comes a recognition that there is common data that could be shared between applications. At the next level, there is a focus on standardizing exchange mechanisms between applications.  At the highest level, the technologies of the individual applications become almost invisible and the focus is on the work processes."

Flipping through a few more slides, Steve showed Joe the second model.

"This model was created by MIT's Center for Information Systems Research; there are many parallels between the two models.  For example, the initial level in both models – Business Silos and Application-Centric – are characterized by numerous applications linked together by custom interfaces maintained by the IT department.  At the highest level in both – Business Modularity and Work Process-Centric – you find platforms designed for change, where it may not even be necessary to get IT involved when changes are needed."

"I think this is just what I've been looking for!" Joe nearly shouted.  "I'd like to put together a short presentation for the executive team – can you help me with that?"

"It's what I do" Steve said with a grin.

Two Worlds

While DBM is jumping as quickly as possible into the execution of their implementation plan, PCI is being more deliberative.  Joe has recognized that growing capability maturity is important in both process and architecture.  In future chapters, he will also learn that organizations which grow their architectural maturity reduce IT costs between stages 1 and 3, but begin increasing IT spending in the fourth stage as they experience increased return on investment from their technology. There will also be an exploration of the importance of change management between the two organizations. Check back next week!

A Tale of Two Factories: Chapter 2 - The Problem of Pain

This is the second in a series discussing the impact of technology, production processes, and the intersection of where they meet – the production workers on the factory floor.  Once again, the story focuses on two plants – Deuxieme Botte Manufacturing (DBM) and Premiere Chaussure Industries (PCI).  In this chapter we observe with how both organizations address decision-making related to plant floor information technology. This is a precursor to Chapter 1, occurring a few years earlier, and begins with both Brian, the COO of DBM, and Joe, the VP of Operations at PCI, considering options for performance management systems.

Pain Points at DBM

Brian scratched his head; the consulting firm's recommendations he held in his hand included a focused effort on improving asset effectiveness. He picked up the phone and dialed Earl's number.

"Earl – we're going to need to measure the effectiveness of our production equipment. What's the best way to do that?"

Earl had read the consultant's report too, and had been expecting this call.  Earl had years of industrial engineering experience and knew that manual methods collecting and analyzing asset performance information were time-consuming, cumbersome, and error-prone.

"I think an automated system to collect and analyze the data from each machine is your best option", he replied. "The information we need can be obtained directly from the machine controllers."

"Does any of the software we currently own do this?" asked Brian.

"Don't think so", replied Earl. "Let me talk to Ellen and find out what our options are."

Ellen was the IT manager responsible for manufacturing systems.  Earl took a walk over to Ellen's office.

"Hi Ellen – got a few minutes?"

"Sure Earl – come on in.  What's on your mind?"

After a brief conversation, Ellen commented:

"It looks like you have a well-defined pain-point; we really don't have any systems which can help.  The next step is to estimate business value, and then we can put together a request for proposal for solution providers and get some idea of the implementation costs.  Then, assuming the numbers justify the investment, we can present this as a project to the investment steering committee."

After a few minutes of discussing who would do what, Earl headed out of Ellen's office and stopped by Brian's to report what he'd learned.

"So we need to implement yet another software package on the plant floor?"

Brian sighed; he wasn't sure he was getting the value from the systems in which he'd already invested. "Well", he thought to himself, "if the numbers work out, then I suppose we'll be OK."  Still, he couldn't shake the feeling that he was missing something important.

"OK", he told Earl, "Let's get the wheels in motion."

Pain Points at PCI

The meeting discussing equipment performance management had just concluded, and a few of the participants were have a casual after-meeting chat about some of the information systems used. Joe, the VP of Operations, spoke up:

"You know, I get really frustrated with information technology – I don't know what we should be doing with it.  See this phone?  (Joe was famous for having the most advanced smart phone on the market.)  I can hold it up in a noisy restaurant, and it can tell me what song is playing in the background and the artist performing it.  But in my plant, I'm buying more inventory than I need because one guy calls a material a tube and another calls it a hose, so we end up buying both.  We have engineers and mechanics spending time entering equipment bills of material in one system that already exists in another because the systems can't talk to each other.  When I ask our CIO what technologies I should be investing in, he just asks what my 'pain-points' are and we never seem to make any progress.  I'm afraid we keep adding new systems and aren't getting the benefit we should."

"Pain management is a kind of strategy", said Steve, the consultant working with PCI to implement the performance management system, "but it has limited effectiveness.  It is really inadequate for addressing the problems you are expressing."

Joe, who had been staring at his phone contemplating the disparity between what was and what could be, jerked his head up.  "What you just said – you know that's tantamount to heresy with IT?"

"Yeah, it doesn't win me many friends in the consulting community either.  There is nothing inherently wrong with dealing with pain points, as long as you realize they are only symptomatic.  But think about it: pain-point management has the advantage of being relatively easy to implement, and can remain independent of corporate strategy.  It assumes a generally stable architecture and environment, and you can build substantial business rules around it.  But is also results in fragile systems that do not adapt easily to change and are not necessarily aligned with business objectives."

"I'm assuming there are alternative approaches, and that – for a fee – you'd be willing to share them with me", Joe chided good-naturedly.

"Well, I don't give away my expertise and experience," agreed Steve with a quick smile, "but I will offer you some clues. Consider what high-performing companies such as UPS and P&G are doing with regards to technology.  Their IT strategies are not driven by the IT department.  They have implemented systems designed for change, and adapt their business processes to take advantage of the capabilities the technologies provide."

Usually, discussions like this didn't much interest Joe, but today the thought of an alternative which could lead to more effective systems prompted him to ask "Well, if IT isn't driving the technology strategy at these companies, who is?"

Steve smiled more broadly.  "There was a wonderful article in Harvard Business Review entitled 'Six IT Decisions Your IT People Shouldn't Make'.  While it was published in 2002, the points outlined in that article are still valid today. In short, it places the responsibility for IT strategy on the senior management team – not the IT department. Sometimes the driving force can even be traced back to a single individual like a Bob McDonald at P&G…or a Joe at PCI."

"Wait a minute – I'm not a technology guy!" protested Joe.

"You don't need to be.  Joe, you're an operations guy - you know what you want PCI to achieve. Look, you've instituted Lean philosophies to drive operational excellence – were you a Lean expert?  You've instituted quality management practices – were you a quality expert?  Beside your own people, there are organizations and consultants ("like myself!", Steve thought) who can help you put a business framework around your technology vision, but you and the executive team must own and drive that vision.  Until that happens, you'll continue to manage pain points."

"Hmmm", said Joe thoughtfully, "Perhaps you and I should have a more detailed discussion."

Two Worlds

At this point in in the story, the worlds of PCI and DBM are essentially identical.  However, a fundamental difference is about to be established at PCI as Joe and Steve talk further.  Joe and the rest of the senior management team are about to take the reins of their manufacturing IT strategy – an essential foundation for long-term effectiveness of their technology investments.  Conversely, DBM will continue to defer IT decisions (such as "how much should we spend on IT?" and "which business processes should receive our IT dollars?") to their IT managers.  Future chapters in this story will explore the differences in the enterprise architectures (which embody corporate strategy) between PCI and DBM, differences in how investments are justified, and differences in the effectiveness of the technologies in which each company invests.  Stay tuned!

A Tale of Two Factories: Chapter 1

How many applications do plant floor personnel need to learn to do their job?  The title of my blog is Dickensian enough, so I won't open with a cheesy "best of times, worst of times" parody.  This is the first in a series discussing the impact of technology, production processes, and the intersection of where they meet – the production workers on the factory floor.  The story begins with two plants – Deuxieme Botte Manufacturing (DBM) and Premiere Chaussure Industries (PCI).  We are introduced to two workers: Don is a maintenance technician at DBM, and Brad has a similar position at PCI.  Let's take a look at a typical morning for each of them.

Morning at DBM

Don began his day just like every other; he stopped by his desk to see what work orders he needed to complete during his shift.  He found three in his inbox – all preventive maintenance work.  He picked the one he knew would take the longest, popped his head in the maintenance supervisor's office and said "'Mornin' Jeff – I'm headed off to Assembly Machine 3 to take care of the PM work."

"What work order number is that?" asked Jeff.  "I need to make sure it's entered into the maintenance dispatch system."

Don knew the WO was already in the system, but read it off of the paperwork for Jeff anyway.  "Yep, it's there!" Jeff said.  "Let me know when you're done and I'll update the status in the system."  "Will do" said Don as he headed out the door.  As he pushed his tool cart to the assembly lines, he began reading the details of the work order. "Hmmm, guess I'll need to stop by MRO to pick up the parts kit for this PM".

When he got to MRO, Don showed the attendant Debbie the work order and asked for the part kit. "I'm going to have to look this up by kit number to make sure we give you the right one – you know, correct storage bin number and all" she said. As he waited, Don thought about what an improvement it was getting PM parts pre-kitted over requesting each part individually like they used to.

"Hey Deb – you going to be long?" ("Maybe there's time for coffee", he thought to himself.)

"Well, the system seems a bit slow today.  This usually only takes a few minutes, but for some reason it's taking longer today!  Finally – ", she said with dramatic flair, "- here it is.  Could you fill out the requisition form using kit #80054124?"

"Oh great – I don't have a charge number on this work order. Deb, do you happen to know the department charge for Assembly?"

"I think I have it on a list here somewhere…here it is", she says.

"Thanks Deb.  I don't know why we can't just use the work order number instead of a department charge. Life would be so much easier."  He completed the paperwork and returned it to Deb.

"We can ask IT to make that change, but you know how long that will take" Deb replied.

"Yeah, I love my job" muttered Don.  He was being only partially sarcastic; he mostly enjoyed his work but it seemed to him that more and more of what he did was to feed a system that really only provided benefit to the bean counters somewhere in the front office.  Things that would make his life easier got "prioritized" and placed in a queue until IT could assign resources to make the necessary system changes.

Deb laughed and handed Don the part kit, and he was off to the Assembly area.  About 30 minutes into the job, he happened to notice Jeff approaching.

"Hey Don!  I've been trying to get ahold of you! We've got a machine down in Parts and I need you to get over there right away!  Why didn't you answer your cell phone? We gave them to you so we could reach you immediately!"

Don looked at the phone sitting on his tool cart.  The PM job required reaching into some tight spaces, so he had taken the phone off his belt.  Assembly is a noisy area, so he couldn't hear the phone ring. "I love my job", he thought to himself. "OK – give me two minutes and I'll be there."  He looked for the nearest Maintenance Dispatch display board to see which machine was down, gathered up his tools and was off.

Morning at PCI

Brad stopped by his locker and fit his Bluetooth-enabled personal protective equipment – which interacted with his smart device - over his eyes and ears. He used to have a desk, but since he hadn't really used it in over a year he had given it away.  "Good morning, Smarty" he said to his personal digital assistant.  He named the device "Smarty" because he didn't want to play favorites among the competing technologies, and it really was a smart device.  It interfaced directly with the enterprise systems and actually helped him do his work. "What's on my 'to-do' list for the day?" he asked.

The device responded "Good morning Brad.  The first job on your list is a preventive maintenance task on Assembly Machine #4. The part kit was delivered to the department and is waiting by the machine, and I have the procedure list ready when you need it.  Would you like to hear about the other tasks on your list?"

"Later Smarty. I'm off to work on the assembly machine." Brad grabbed his tools and headed directly to Assembly Machine #4 and began working.

After some time, Smarty interrupted Brad.  "Excuse me Brad, but your assistance is needed. An operator has reported a parts machine down.  The upstream buffer for this machine has space available, but the downstream buffer will be empty in 15 minutes. This will cause other processes needed to meet schedule to shut down, which elevates the priority over the PM task you are currently working on."

"OK Smarty – which machine is it?" asked Brad.

A plant map appeared in Brad's protective eyewear; the breakdown glowed red on the map, along with a green routing from Brad's current location to the machine requiring his attention. Brad first made sure his LOTO was secure on the assembly machine and then headed for parts, where he was greeted by Betty, the machine operator.  "Hi Brad.  Wow – that was fast!" she said. "I just reported the breakdown five minutes ago!"

"Yeah, Smarty here told me it was kinda urgent" said Brad, pointing to his smart device.

Two Worlds

There are many comparisons to draw between Don's world at DBM and Brad's at PCI. Both have similar systems in place, but in Brad's world the artifacts of the technology – things such as work orders and department charges – are invisible at the worker level. Even the systems themselves are not apparent to the technician.  He has one interface – his smart device – which ties all the enterprise systems (such as ERP, CMMS, MES/MOM, and PLM) together.  They collaborate to help him do his job.  In contrast, Don's world is so cluttered with these artifacts that he cannot imagine a world without them. He has log-ins for all of the systems, and knows a few transactions in each.  He even keeps instructional "cheat sheets" in his tool cart for reference when he accesses systems on the plant floor.  He may have to search for an available PC on the floor to interact with the enterprise systems, which is a "hit or miss" proposition; an operator may have the PC tied up doing quality checks, or a supervisor may be performing a downtime study during his gemba. Feeding the technology has been bolted onto his work processes.

Which factory is more competitive?  Which factory is seeing greater technology ROI? The world of the PCI factory seems like science fiction, but every technology that enables it currently exists and is readily available.  Many can identify with (and many more may even be envious of) the world of DBM, but cannot see the path to the PCI world.  What strategies are in play?  Who owns them? Who drives them?  How did management become convinced to fund this approach? What additional technologies are needed, or how can existing technologies be re-deployed? These questions will be explored in future postings in this series.

Downtime Follies

The journal "Academy of Management Executive" published a classic article entitled "On the folly of rewarding A, while hoping for B" by Steven Kerr (1995, Vol 9. No. 1).  The article explains why we end up with a less desirable state when we really want something better.  Kerr covers a wide array of sub-optimal situations: medicine, consulting, sports, government, and business.  He concludes that the reward system is at the heart of the issue; there are organizational forces which reward the less desirable behaviors and essentially starve the more desirable ones.  Jim Collins opens his book "Good to Great" with a similar thought: "Good is the enemy of great." We want things to be better, but we continually accept and reward the mediocre.  This is no less true on the plant floor than it is in other areas of life, and asset downtime provides a prime example. 

Asset Performance

This posting is not specifically about machine ​downtime, but about how people respond to downtime and the consequences of their decision-making processes.  Consider the following graphic:

It shows two identical machines in running and stopped states over time (the horizontal axis).  Note that OAE is short for "overall asset effectiveness", a metric that is essentially the same as OEE, or overall equipment effectiveness.  In this example, total running time is the same, production is the same, and asset effectiveness is the same (i.e. quality and schedule are equivalent between machines).  Answering the question of which performs better isn't obvious based on these metrics, but common sense would say that Machine A is more desirable than Machine B.  It has a higher reliability (greater mean-time between failure, or MTBF) even though the individual downtime periods are longer.  Since it has fewer downtimes, it is easier to address the downtime causes.  Machine A also has lower operating costs – starting and stopping equipment is inefficient and costly.  There are also greater opportunities for quality issues to occur when there are frequent starts and stops, and of course there is more wear on the equipment which increases maintenance requirements. How is it we end up with assets performing more like Machine B, with more frequent downtime events, but faster recovery (mean-time to restore, or MTTR)?

Unwritten Rules

Let's examine some of the unwritten rules which dominate the production environment:

• Rule 1: Downtime is bad.
• Rule 2: Long periods of downtime are worse than short periods of downtime.
• Rule 3: People should not be idle in the production environment.

All three rules are highly logical; who would question them?  Why would a manufacturer invest capital in equipment that isn't producing, and why pay people to stand around?  But notice these are also exactly the rules that drive behaviors which cause more frequent but shorter downtimes.  Technicians are rewarded for reducing downtime duration without maintaining equipment reliability.  As long as production schedules are being met and asset effectiveness metrics are maintained, equipment reliability and process predictability are of little concern.  I'm familiar with one case where process MTBF was less than 2 ½ minutes, but because the machines could usually recover without operator intervention the failures were not even noticed (MTTR was around 5 seconds).  The MTTR frequency distribution was highly skewed toward the lower end, with median MTTR around 2 seconds.  In short, the machine was effectively unreliable, stopped frequently but recovered quickly, and the operators were essentially unaware of the downtime.  Since this type of performance became accepted practice, budgeting and planning were built around the sub-optimal operation and there was little incentive to change.

The Point

An organization which embarks on an operational excellence initiative must be willing to challenge the unwritten rules which govern plant floor behavior because they have unintended consequences.  There are no business drivers which would cause anyone to consciously choose Machine B over Machine A, but that is exactly what ends up happening as a result of these cultural imperatives.  The ability to measure downtime does not automatically translate into better asset effectiveness, but it should cause the organizational introspection and culture changes which do.  The folly of accepting B while expecting A comes in rewarding inefficient processes because they fit into a flawed set of beliefs.