Each of us has a nemesis process; that process that we engage regularly and that drives us crazy because of its inefficiency, its guarantee to waste our time or energy, and some variety of reasons that prevent it from being reasonably improved. Some of us have more than one.
Whether your nemesis process is a production or manufacturing process or a transactional/office type of process, I find that simply removing the problem from the environment, putting the process in a laboratory for all intents and purposes, often provides eye-opening perspective. Doing so can show us what efficiency our process is capable of achieving when it isn’t waiting for attention or other processes.
For several reasons, I strongly recommend doing so on both broken, frustrating processes, as well as on those we think we have improved.
- It immediately shows everyone involved how the whole process works
- It immediately demonstrates where the inefficiencies of the process exist
- It shows everyone what the real process lead time should be
- It easily identifies the sources of variation within the process
Now that I’ve written the list above in plain English, it strikes me as appearing rather mundane. I suppose, because of the simplicity of the method, it must appear rather obvious. What I’d like to communicate is the stunning surprise we often experience when we conduct the exercise.
First, let me describe how it works, and then I’ll provide an example with some rough numbers to try to communicate the surprising impact. It’s easy to read these posts and decide that the ideas in them are novel or not. I very strongly encourage the reader to put this particular advice into trial or practice. Don’t stop merely with reading the advice herein.
Here’s how it works. Pick a problem process, one that simply doesn’t get the job done quickly enough to satisfy you and your team. Alternatively, do this exercise on the process you are currently improving, before you put your improvements into practice. Office processes that are based on acquiring approvals such as purchase orders or engineering change orders are excellent experiment candidates. Once you have your process chosen, set a date and time for everyone involved in the process to meet.
Get as many people as possible in the same room at the same time. At lease one representative of each role needs to be able to participate. If you can get managers or other influential authorities to witness the exercise it’s very powerful. If physical locations prohibit everyone from sharing the same space, get the remote participants to dial into the speakerphone on conference call.
While waiting for the meeting date to come around, make sure that all of the elements necessary to execute the process are in place. Make sure that everyone has the correct software and login elements. Make sure that all of the materials are in place. Consider process maps or visual displays that will help everyone follow along or track the process as it executes. Assign a timer and note-taker to record meaningful measures and observations.
When everyone and everything necessary to execute the process, start to finish, are gathered, execute the process in the vacuum of the conference room environment. Do it several times with differing inputs representative of natural variants. Observe how the process does or doesn’t work.
The method is as simple as that. If your process is a production process instead of an office process, the conference room isn’t where we do this method. We must do it on the production line. The challenge is isolating the production line from the rest of the system for the sake of the exercise. This might mean that you must do it during an off-shift, between production runs, or on the weekend.
For the production process, the same idea of providing all of the roles and materials necessary applies. Sometimes, as we improve our production processes, we over-optimize them. We inadvertently cause processes to wait for other processes because we have reduced work-in-process and inventory too much to account for natural variation or we have induced variation unintentionally.
If we isolate our personnel, our system, and our equipment, and we provide an ample supply of materials to the process we can see what it is capable of accomplishing independent of the chaos of reality and external influences. Why would we want to see the “laboratory” results when we know that reality is where we are going to perform? So that we know what we are missing!
That’s the surprise I mentioned above. When we observe and experience what does happen without the distractions of every-day operating conditions (in the case of observing the broken processes) and when we observe and experience the real potential efficiency of our fixed processes we get an often-stunning taste of what performance we might have. Once we taste it, we want to make it real, every time.
Here is a recount of one real example. We set out to fix our engineering change request and order process. The average lead-time for the process from the time an engineer submitted a request to the time the drawings were released into the system was 52 days. The best lead times were between 1 and 3 days. The extreme outliers were measurable in months or years, and some went into eternity since they never did get closed out before the product was retired.
For some of you, that performance might be laughable. Some readers are probably living a very similar reality. There were a lot of things that contributed to the lead-time and the extraordinary variation. It’s enough to write a book about.
At the beginning of our effort to fix that process, we gathered everyone above into a room and “walked” the process. We did this in order to both map and communicate the actual process, as compared to the one written in the procedure, to identify the “hidden factory” or unspoken process steps, and to get some timely measures and observations about the individual process steps.
What we learned was that we could do that 52-day process several times an hour if everyone involved were sitting there with nothing else to do. The process time was limited by how long it took a signature authority to read and review the changes to the drawings. Otherwise, most of the steps took only a few seconds for each participant.
Of course we also identified and made obvious all of the unnecessary steps, approvals, hand-offs, and other opportunities for waste. By the time we were done with the first round of walking the process, most people in the room were laughing at the absurdity of what was in place. By about the third round everyone was begging not to have to do it again.
When we were ready to launch the new and improved engineering change process, we reconvened the process owners and participants and ran it several times again. Regardless of the numbers, the experience of the improved process compared with the old one had people smiling, even cheering. Resistance to the change was effectively eliminated.
The bottleneck step remained the review and evaluation of the change and drawings by the engineering signature authority, but we discovered that approximately 70 percent of the change orders could be processed in less 3 minutes, every time. The remaining 30 percent required that concerted review and took from 3 to 30 minutes. There is a big difference between 30 minutes and eternity for an upper end of the process. I’m being flippant.
When we released the process and set it to execution in the real environment, the moving average for the process bounced around 1 to 3 days, and the upper end was generally around 10 days with the extreme outliers at 30 days (coincident with the alarm limits set on the process).
Here’s the insight that those meetings where we measured the process execution in a “reality vacuum” provided. Everyone involved in the process knew that the process should only take a few minutes, not a few days. Therefore, while everyone understood that reality is messy, they still maintained a realization, if not an expectation, that if their engineering change weren’t completed in a day or two, they didn’t have to accept any further delay; they had already allowed 10 times or more the lead time necessary.
One lead engineer, having been part of the exercise, took the memory of the exercise to heart and proactively forced the issue in a practical way. When the end of the development phase came around and it was time to begin releasing drawings for production, he scheduled meetings with all of the process participants at various times over a couple of weeks to do nothing else but execute the process. He even provided the drawings ahead of the meetings to the signature approvers so they could review them prior to the execution of the process.
He knew that if he put all of his program’s drawings into the system at once, they would create a spike within the system and that his approval time would push into the 10-day zone and some of his components might escape that process limit and go into the 10 to 30-day zone. He wanted his done ahead of schedule, not late.
Knowing that the process could be executed in a few minutes if the drawing review were done or not necessary, he batch processed (yes he broke the Lean rule) his engineering changes in ½-hour and 1-hour meetings. He was able to control the priority of the drawing releases, answer questions and address potential process blocks real-time, and he got the program’s important drawings and specifications released in less than 10-days.
That is one example. Knowledge is powerful. Knowing that it is possible to execute a process in a few minutes or seconds, instead of days, changes expectations and, therefore, behavior. It drives focused, concerted effort to achieve what we know is possible instead of simply accepting what currently is.
One of my teachers and mentors in Statistical Process Control referred to it as “Process Entitlement.” It is the performance we are entitled to if we successfully remove the inhibitors.
Office and transactional processes are often the victims of waiting and rework from defects because people in office environments operate many processes. They don’t facilitate a single process as most production floor personnel do. So, the method I’ve described above tends to produce very stark and eye-opening results for office processes when the waiting is forcefully removed and questions are immediately addressed.
It works for production processes too, even so. As I mentioned, sometimes we over-optimize our processes and inadvertently create unnecessary constraints. Isolating a process from its interdependencies allows us to see what our process’s real potential is if external constraints are removed. It also allows us to play games with resources.
Sometimes we discover that we have correctly resourced a production process given its performance with interdependent processes, but if those interdependencies are corrected to better facilitate our process the addition of a few personnel at key steps would be required to get the most out of the production process. These can be important insights toward that idea of process entitlement. Knowing that some interdependent adjustment and some additional personnel will yield better output can help us make much wiser decisions about investing in moving or buying capital equipment to improve our output.
Nothing sets our expectations like personal experience. The exercise of getting everyone involved in a process to personally experience what that process can do when it is optimally enabled sets everyone’s expectations. I know of no better way to remove resistance to change and encourage active effort to continuously improve upon the status quo.
What I have described is a very simple exercise. Do not let its simplicity fool you into dismissing its powerful impact on your team’s expectations and behavior. Instead, consider that you absolutely should try such a simple exercise for yourself because it is so simple and you have no excuse not to do so. It has become a habit for me because it is so easy and powerful. I believe it will for you too.
Stay wise, friends.
If you like what you just read, find more of Alan’s thoughts at www.bizwizwithin.com.
