Monday, January 19, 2015

A Tale of Two Factories: Chapter 3 – Mere Maturity

By Patrick Weber, MESA International Technical and Education Committee member  

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, 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!

No comments: