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!