Who Drives Change?

Lately I've been thinking about change initiatives within an organization, particularly about who owns these initiatives and harnesses them to achieve true value.  Whether it's Lean, Theory of Constraints, Product Lifecycle Management, Business Process Management, Manufacturing Operations Management, Supply Chain Management, Resource Consumption Accounting, or even Project Management, someone must champion the initiative from conception to integration.  There is, of course, a whole management consulting industry around organizational change, and I think that's a valid approach for assisting change.  However, consultants do not have ownership of the initiative; they can sell and support, but only the owner can derive business value.

So who's responsible for change within an organization?  The answer cannot be "everyone" – when everyone is responsible, then no one is accountable. "Management" also seems to be too vague as an answer; who in management will decide which initiative to pursue?  Responding with "It depends on the initiative" seems to fall flat – the kinds of transformational initiatives previously mentioned have organization-wide impact, and pigeon-holing one into a business silo seems to be the oft-cited cause of failure.  What's left seems to be the executive team, but given their other responsibilities for running the organization, driving change initiatives often falls into lower-tier priority levels.

One approach that has gained a foothold is the creation of "Offices" or "Centers of Excellence".  Project Management and Lean tend toward the "office" moniker (PMO, Lean Office), while BPM, PLM, and MOM frequently utilize the "CoE" tag.  No matter the name, these are changes to the organizational structure that can work between business siloes to achieve the strategic initiative.  These have the advantage of being focused on the success of an initiative – resources are allocated and the team/group/department is accountable for specific results. People can look at the organizational structure and say "this group is responsible for driving change related to this initiative."  Depending on organizational precedence though, even these sub-structures are at risk of being siloed.  For example, Lean is typically "owned" by Operations, and other parts of the organization are often free to choose whether or not they want to participate in the initiative.

Change is as certain as taxes

I think the change to organizational structure is the right approach, but must be divorced from existing business sub-structures.  There needs to be a C-level executive responsible for organizational change, not only change management but leadership as well.  The fact that organizations have CFOs, CIOs, COOs, and heads of HR and Marketing is an acknowledgement that specialized focus is necessary in these areas; I'm arguing that the same can be said for organizational change.  The "Chief Change Officer" would lead a team of business architects, analysts, internal consultants, and change facilitators to:

• establish standards and practices
• institute governance
• assure alignment between organizational entities
• make changes to existing organizational structures as new technology permits new capabilities
• engage and involve the organization in change
• provide measures to the executive team demonstrating the value of change as it is implemented

Perhaps this could be called the "Office of Strategic Change Leadership (OSCL)" or "Change Leadership CoE (CLCoE)".  All the existing CoE's would become subsets of the CLCoE, creating a clear line of accountability throughout the organization for successfully adapting to change.

Some studies have shown that organizational change efforts account for between 25% and 35% of every project budget.  Other studies have shown that transformational change initiatives are unsuccessful over 40% of the time, with only 5% being completely successful.  With these kinds of numbers, it's clear that organizations need to become better at adapting to change.  It's axiomatic that when Management wants to make something happen, they change the organizational structure to ensure it does.  It's time this same logic is applied to change itself.

The Real Skills Gap

There's been a great deal of discussion in industry press about a growing skills gap – typically focused on technical skills but occasionally on leadership skills as well.  The March 16^th issue of Crain's Cleveland Business had a front page article on manufacturing leaders nearing retirement; "Who", they ask, "will run the manufacturing industry when the generation in charge eventually walks away?"  The US Chamber of Commerce Foundation published a 2014 white paper entitled "Managing the Talent Pipeline: A New Approach to Closing the Skills Gap" which paints a dire picture of talent systems that are not keeping pace with economic requirements, and manufacturers who struggle to find the skills they need in the job market as talent nears retirement.

Peter Cappelli of The Wharton School skewers the current understanding of "Skills Gap".  His 2012 book "Why Good People Can't Get Jobs: The Skills Gap and What Companies Can Do About It" debunks the mythology of technical skills gaps, and states the problem really lies within the systems used to acquire talent.  The April 2014 issue of Inc magazine contains an article entitled "Why the Skills Gap 'Crisis' Is Overblown", offering further evidence that the skills gap isn't as great as we've been led to believe.  Interestingly, both sides of this argument focus on management systems to resolve the issues around acquiring needed skills.

To me, this suggests a very different kind of skills gap – the skills around strategic planning and management.  I recently attended the Siemens/Electro-matic "Manufacturing in America" Symposium where one of the seminars was focused on acquiring and maintaining technical expertise.  A slide shown during this session depicted one company's skills gap analysis, with large deficiencies over a broad range of skills. This left me wondering if the company's leadership had a clear understanding of the skills required to operate their business.  But acquiring people for skilled trades and keeping skills current is just one symptom.  On March 13^th, iBASEt's Conrad Leiva posted a blog noting a disconnect between Manufacturing Operations Management strategy and challenges.  He cited a recent LNS Research study,  and observed a mismatch between respondent's stated objectives and the business challenges they are experiencing – and recommends a realignment of objectives to address challenges rather than a myopic focus on cost & quality.

In his book "Good to Great", Jim Collins notes that Level 5 leaders "look out the window to apportion credit…they look in the mirror to apportion responsibility"; perhaps it's time for corporate leaders to look in the mirror to address the skills gap they may find there.

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!