When attempting to improve process performance, automation is a tempting solution. While automation can be very effective, other process problems should be addressed first in order for an investment in automated systems to pay off.
Most of us need our processes, particularly our production processes to happen faster and at less cost. A common go-to solution is to invest in automating manual processes.
Automation offers two-fold benefits. Automated processes are generally faster, and once tuned in, they also boast better, more consistent, quality because they eliminate human error. This is generally true.
Automated processes are much like computers, however. They do exactly what we tell them to do or what they are programmed to do. They don’t always do what is right. If we don’t error-proof the process before automating it, or at least while automating it, then automation, instead of eliminating waste, tends to produce more waste faster. It is my experience that automation succeeds best if it is the last improvement to a process. It disappoints when it is the first.
A few years ago I helped to institute a standard, enterprise-wide, automation of Engineering Change (EC) and document control processes as part of the institution of an Enterprise Resource Planning (ERP) and Manufacturing Resource Planning (MRP) system. At that time there were several design and manufacturing centers, each using its own EC system and rules.
In one center in particular, two people worked full-time to manage the EC process. It had many facets to it that required some intelligence. One in particular was that a large number of people needed to be notified of engineering changes and each had the privilege of approving each one to indicate that the change was reviewed.
You might imagine the waste that went with such behavior. The EC process people had to manually determine from the rule set who needed to approve each EC and e-mail it out. Then the EC would wait in e-mail boxes for someone, sometimes someone who had much bigger concerns than an EC, to get around to reviewing the EC and responding.
To keep ECs from being help up eternally, if no response was received within a week, the process people would begin to make phone calls and leave voice messages. If after three weeks there was no response, it would automatically be approved and would move on to the rest of the process.
You can see, from just that one explanation of a minor portion of the process, why people were dedicated to managing the process. Now let’s imagine automating that process.
If the example were automated as is, how fast would a large number of people get their e-mail boxes filled up with EC requests? Obviously, it would occur as fast as engineers could produce them. Now consider that the process people did a quality screening function as well and kicked back any incorrectly applied or incomplete EC requests back to the engineers before executing the process.
An automated process might not include that function. So, not only is all of the over-processing, overproduction, and waiting waste taking place, it is also producing all of the defective ECs that are input into the system. Now, to correct the errors, all of that waste has to also be repeated. Obviously, more waste for everyone to deal with, more often, is not what we wanted from an automated process.
Instead, what we did is reduce the EC process to its most fundamental, essential elements. We had to redefine some beliefs and alter some authority in order to reduce review and approval to a single person per EC instead of many. We error-proofed the request system and eliminated the options and decisions as much as possible. Yes, we gave up a great deal of flexibility, but we also unloaded an enormous amount of waste.
Once the process was simplified and error-proofed as much as possible, we instituted the automated system according to the simplified solution. Life was much better before everyone, except perhaps the dedicated EC process people who were routed to alternative responsibilities. In the end, after adjusting, I think life was even better for them. Their new responsibilities were more meaningful (no one likes being a monitor of wasted time and energy).
The same phenomenon occurs with automated production processes. We often justify investing in automated equipment by calculating improvements in production time and reduction of errors and defects. However, if a bad input is inserted into an automated system, a bad output occurs faster, consuming materials and resources faster.
Bad inputs to automated processes can come from a wide variety of sources.
- Poor materials.
- Poor programming.
- Incorrect assumptions or settings.
- Poor process design.
- Lack of control.
- Too much adjustment or over-control.
- Instability in the process or environment.
- Poor timing.
- Too many initiated.
- Too few initiated.
- Incorrect order initiated.
Above are a few common sources. Specific processes will have specific errors that can occur.
If the sources for error are not addressed prior to instituting automation, the errors will still occur. They might occur more often because there is no longer an intelligent person in the process to recognize when something is in error and call for a correction before the output is complete.
If the first opportunity to recognize and correct an error is after the output is complete or when the system fails because of the error, then the automated system will drive more expense and defects and down-time instead of save it.
Before automating any process, break that process apart and work diligently to remove the waste and errors from it. As I wrote above, an automated process does what it is told. Poor inputs result in poor outputs. Make sure that the process you automate is a solid, error-proof, consistent, and reliable process.
The misperception about automation is that automated processes are by nature error-proof and faster. It is not so. Only a good, error-proof process that is automated in a reliable manner will be faster with better quality.
Take this message away from this post. Automate a process only after you have applied the other process improvement tools and methods to reduce opportunities for error, eliminate waste, and improve consistency. It may be that such is done while developing or programming the automated system, but it must be done first. Otherwise, the waste and error occurring within or as an output will undermine the business plan that justified the investment.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com.
