A Six Minute Read
The work order read, “Replace filter on Pump One.” Bruce spent about two hours shutting down the machine, flushing the lines, locking it out, opening the shaft and clearing entry, and reviewing the Confined Spaces permit with his safety attendant before climbing in. He saw evidence of oil on the floor, always a troublesome sight. He suspected the gasket seal simply needed to be replaced. He climbed out, reassembled everything, cleaned up, and turned in a work order to inspect the gasket.
Three days later, new work order in hand, he returned, starting from the top: two hours prepping, about half an hour changing the gasket, a few hours putting it back together and cleaning up.
I asked him why he didn’t just fix the leak the first time he was in there? It would have saved at least five more hours of downtime, the machine’s efficiency would have been restored three days earlier, and he and his colleague could have been busy doing something else.
“The system doesn’t allow it,” he told me. “You can’t get parts without a work order. It’s not a matter of the tool crib being difficult, you literally can’t get part numbers or locations without an active work order. And you can’t assign a work order on a subassembly until the previous one has been completed, unless it’s flagged as an ‘Emergency.’”
Geoff, his manager, also told me that it would skew the system-generated metrics. “You’d have a filter change, which is supposed to take four-and-a-half hours, and a gasket change, which is also supposed to take four-and-a-half hours, both getting done in… what? Six hours for the first and zero hours for the second? That makes no sense! Arbitrarily close one ticket and open the next? It throws everything off!”
“The system doesn’t allow it.”
This is not an isolated incident; when I want to drive myself crazy, I think of the time I waste doing stupid things because the system “has to”. (Latest example: For my “protection” 
yesterday, could not proceed without entering my PIN. Did not have a PIN, so went back one screen, set a PIN, and then proceeded. Protected.) When software doesn’t support a sound underlying business process, the software will win.
Software can certainly be modified to meet individual demands, but that adds cost to the purchase and implementation. The cost of wasted time and material, as well as the frustrations of those fighting it, is certainly never calculated.
A textile processor’s new system was able to add lot numbers to its inventory, which greatly improved the accuracy of its raw materials accounting. However, it could no longer blend multiple lots into one production ticket. Traditionally, when one lot started to run low, a second would be added to the same order and production would continue. Once the new system was turned on, if operators didn’t have enough raw material from one lot to start the next batch, they would close the ticket and start a new batch with a new lot. The remaining material, because it couldn’t be accounted for in production, sat in a corner gathering dust – and sat in WIP on the general ledger until it was time to write it down.
It’s Not the Software, It’s the Whole System
This is not the anti-technology rambling of a cranky old man. If software fails because it does not support business processes, that only reinforces the importance of getting the fundamentals right. Good business processes are adaptable, but they too can fall short of the mark when they don’t reinforce the needs of the organization.
Organizations often look to off-the-shelf solutions as a cure-all. Replacing Post-It Notes with ERP won’t flow materials any better if there isn’t already a good method for flowing materials; a fancy-pants call distribution system won’t boost Net Promoter Scores if no one understands why people call, or have a staff level ready to provide support. This is not limited to IT solutions (i.e., software): the same happens when attempting to force-fit “Lean Manufacturing/Lean Office/Lean Healthcare”, Six Sigma, Agile, and so on.
Obstacles to Getting It Right
As Maria von Trapp might say, let’s start at the beginning. Systems are doomed for failure if they aren’t focused on the right issues – whether to “fix” them or improve them.
This begins with truly understanding the existing, current state – that is, how people actually get work done and interact with each other (and customers). If the current gaps are not understood, it is difficult to design the system that will close them.
This gets skipped when leadership believes it already knows what’s happening, and it fails when an unrepresentative sample of performance is taken as gospel. (Or the software designer spends one day observing one department, or site, and extrapolates that to represent the whole.) Perhaps worse is when actual behavior and practices are ignored in favor of written documentation. All of this is as good an argument as any to bring in a good consulting team – for the objective, non-political viewpoint, and for the diligence they will put in to paint a complete picture.
Just because the gaps have been clearly identified, it does not mean that they will be properly closed. Business Process Management had a bad name when it was felt that processes were designed in glass towers and handed down from on high; the corrective was to drive design down to ground level. Neither approach is optimal.
Relying on executives or internal continuous improvement divisions – or worse, external consultants –not in the trenches leads to 
“improvements” disconnected from real business needs; putting the future entirely in the hands of those at the operating level can be perilous, as the “big picture” can be hard to see. It can be a struggle for the “do-ers” break from the entrenched practice and create something new. Assemble an appropriate, cross-functional and multi-level design team – and allow the consultants (internal or external) to facilitate, but not own, the results.
Implementation matters – maintain a focus on change communications. The best-designed solutions will fail if not properly communicated. Proper communication goes beyond the blast e-mail telling everyone change is coming; it focusses on the “why” and the impact, and needs to be frequent and comprehensive enough to minimize fear and resistance.
Training/education in the new process is a must. This seems obvious, but is frequently engineered down in schedules and budgets, becoming ineffective.
Schedule time to “debug” the process. In an Agile environment, this is likely built into the calendar. Regardless, everyone needs to recognize that no matter the effort or brainpower put into the design, or how often it works in simulation, it will fail in the “real world”; people need to be prepared for that, and have a plan to make the necessary corrections.
Implementing an off-the-shelf solution to a problem without understanding the drivers behind the issues only masks the symptoms. Before replacing the gasket, Bruce should understand why it failed in the first place. Likewise, before embarking on any process improvement (including software implementation), begin by understanding the current state of affairs, and put genuine effort into finding the best alternatives.
B-SPOKE 