Pain X Frequency

Sometimes, when my clients look over a process that could be improved, it is difficult to tell exactly where their bottleneck is located. I use 2 or 3 tools to identify the bottleneck constraint.

Work in Process Inventory

The first tool is simply looking for the biggest pile of raw material or work-in-process inventory… this includes looking for the biggest electronic or paper “inbox” as well! This pile of inventory (or information) is waiting for the bottleneck constraint to process it! If the senior managers aren’t sure (or don’t want to be implicated) ask 3 or 4 first line supervisors where they always have to go to get the information, materials, supplies (or safety solutions) to do their jobs…. This method is as good as a bloodhound at tracking down the bottlenecks! (Be advised that sometimes the bottlenecks wear Gucci’s… or boots!)

Pain x Frequency

A second simple tool I have used is to log “backflows” in a process. A backflow occurs when a first-line supervisor or a manager has to go on a “treasure hunt” looking for some piece of material, supply or information that SHOULD have flowed their way but did not. The initial purpose is not to fix the backflow so much as it is to sample and capture a snapshot of what is really going on in the process.

Essentially, the manager creates a log form with the following column headings:

• Date (say, YYMMDD so that they sort nicely in a spreadsheet.)
• Code (or Codes) for the Department(s) where the incident occurred
• Initials of the person logging the incident
• Brief Description

Then the manager or some designee simply logs the incidents. Tip: You might lay this log form out in Landscape format (the wide way) to provide more room for the Brief Description to stay on one line. (Here is a Back Flow Incident Log Excel File (MS-Excel, 14kb) .

There are two kinds of pain in this sort of system.

1. Problems which are a little bit of pain and happen all the time. They are the ones that are so inconsequential for the moment that they never justify fixing them.
2. Problems which are infrequent… but produce a large amount of pain! These, on the other hand, are so infrequent as to not justify fixing them.

You can’t go after all of the backflow problems at the same time! However, a simple method of evaluating which of these you should go after first starts with recording how frequently each type of pain occurs, say, number of times per week or month… or shift. Just be consistent with the frequency interval across the whole list.

Next, code how much pain each of them causes, say, on a scale of 1-10. Don’t worry about if you are getting the weighting correct. After you go through 2 or 3 dozen of these items, you will get a very good feel for their relative pain and thence their coding! Simply spend 2-3 minutes and go back and update any errant earlier coding. All of my clients who have used this method go through this learning curve. It is pretty straight forward.

Then, for each item, multiply pain x frequency and sort the list in descending order by this product: with the large numbers at the top. As you look at the event log over the course of 3 to 10 days, the high-volume items pop out at you with big red flashing pain. Take the biggest one… and eliminate it…!

AVIT Flow Modules

The third tool is introduced in the AVIT Flow Modules document and has to do with process flows being organized into four different types of modules. The point of recognizing the structure is to know where to place the control point in your process. Or, in other words, design the system so the control point IS the bottleneck point.