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!
If you are enjoying this series (or even if you’re not), please feel free to leave a comment, question, or recommendation. Thanks for reading!
No comments:
Post a Comment