Member Forum by Khaled Mabrouk
Industrial Engineer’s column for IIE members to share their perspectives (March 2013)
Fix your process before seeking a new one
After graduating from Purdue University, I went through an intensive training program for Andersen Consulting that helped me develop advanced programing skills. One of the most important lessons I learned was if the process is broken, don’t automate it. After all, automating a broken process results in an automated broken process, which cost lots of money to automate and likely will be more broken than the original process.
As my career evolved from IT to simulation modeling and continuous improvement, that lesson has helped ensure my success. I learned to understand the current process and its failure points before trying to make it better.
Nowadays, I advise and teach companies how to implement successful continuous improvement programs. One of the more difficult conversations with some of these companies revolves around their strong desire to drop whatever operational improvement program they are using and finding a new program to install. Their thoughts are that the previous program, whether lean, Six Sigma or another methodology, did not work for them because it did not fit their organization. However, they believe that some new program is going to solve all their problems. The reality, though, is much different.
Most organizational failures with a specific operational improvement program are tied to how they tried to implement the program. They were dogmatic about their approach instead of understanding what aspects of the program fit their culture and operational improvement needs. The leadership team expected all change to occur at levels below them, as opposed to understanding that the leadership has to lead by understanding what behavioral change is required of them to ensure the program’s success. Leaders also must exhibit that behavior on a daily basis.
Sometimes organizations put a person in charge of the program who has a limited range of experience with operational improvement tools. That person pushes through what he or she knows instead of using what is needed to meet the organization’s needs. And on and on the reasons for failure go. The bottom line is that the failure of the operational improvement program is due to how the organization tried to use it, not the capabilities of the operational improvement tools and techniques.
From there, these organizations start looking for a new program. And many programs sound new, even though they are just a repackaging of existing tools and techniques. The fresh program will feel good for a year or two, but unless the organization changes its approach, it will fail. Just like in IT, automating a broken process is never a good idea.
PDCA, DMAIC, CPS and others are effective ways to package and communicate the problem-solving process, but the problem-solving approach itself has not changed in decades. It comes down to understanding the problem, collecting data to understand the root causes, generating solutions based on the information available, testing the solutions, and permanently implementing the solutions that have significant payback. Then repeat this process as needed.
If your operational improvement process is not working, first understand why it is failing, then work to fix the process before exploring other approaches. Otherwise, your organization’s operational improvement efforts will waste money and effort instead of being a critical driver for improving your bottom line.
Khaled Mabrouk is a process improvement leader for Sustainable Productivity Solutions. He received his B.S. in industrial engineering from Purdue University and has been a member of IIE since 1985.
VOICE YOUR OPINION
To submit an opinion for this column, e-mail the text to Michael Hughes at firstname.lastname@example.org. Columns must be 500 to 600 words in length. All submissions are subject to editing. Include a brief bio that includes your IIE membership status.