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!
I would like to thank everyone who read and commented on the first chapter of this series. I hope you find these posts both interesting and useful, and also that they spark new ideas and innovation within the manufacturing IT community. As always, I look forward to hearing your thoughts on this topic.
No comments:
Post a Comment