This post is in response to Ethan’s post on “The White Board.” He asked about the paper shuffle – admin processes.
This seems to be a hot topic today. First, because these techniques are increasingly being applied to operations that don’t do manufacturing. They are service delivery, information processing, and creative processes instead. And second, I think, because manufacturing companies are realizing that these paper (or information) processes are often the ones that cause havoc on the shop floor.
Many consultants (and others) like to differentiate between “manufacturing processes” and “non-manufacturing” or “administrative” (or “office”) processes and say that there is a fundamental difference in how these types of processes need to be approached.
They go so far as to produce separate products and methods for “administrative kaizen.” Part of this, I suppose, is sales and marketing. But part of it is, I think, a sincere belief.
Ironically, these same people are (usually) cheerfully adamant that there is no fundamental difference in approach for kaizen between custom circuit boards and airliners. They are right about this. But I question whether 747’s and circuit boards are less different than lawnmowers and insurance claims.
I do believe that, in most cases, there has not been a lot of thought applied to what administrative processes are actually trying to accomplish, nor exactly what tasks are required to do it. But this isn’t something that makes administrative kaizen unique, it just requires a bit more work up front.
The First Questions
These questions should really be asked for any kaizen activity. For this process:
- What is the intended outcome?
- How is the actual outcome checked?
To paraphrase, what, exactly, does the customer expect? How does the customer expect it? When does the customer expect it? Where?
and.. how do you verify that what you delivered, how you delivered it, when you delivered it, where you delivered it, and exactly match what the customer expects?
Answering these questions gives you the definition and confirmation criteria of a “defect-free outcome.” If you don’t have answers to these questions STOP, because you will have no way to know if your process works or not.
The Second Questions
- What tasks need to be performed, in what sequence, to assure the defect-free outcome (defined above) is produced?
- As you perform each task, how can you check that it was done as expected, in the sequence expected, in the time expected?
- As you perform each task, what is the expected result of that step and how do you check that you got it?
In other words, just what is required to just meet the customer’s exact requirement? This is the “just” of “just in time.” (At least part of it.)
The Third Question
What conditions are required for the process to succeed?
What information, tools, materials, environment, skills, software, hardware must be present?
If a manufacturing process, what is air pressure required for your tools to run to the proper torque?
What information must be present for the approval process to evaluate?
What parts are required?
What forms must be signed? By whom?
In a larger sense, this question defines what your process needs from its suppliers. Again, “just” what is needed? “Just” when is it needed?
Between these three sets of questions you have (hopefully) defined an ideal. Your actual process might not come anywhere close to the ideal, but until you think through what is necessary, there is really nothing compare to. You could look at your current process and say “this is pretty bad” (or “pretty good,” for that matter) but I ask “Compared to what?” and that comparison is vs. the ideal.
It is certainly true that (usually) manufacturing processes are further along with these answers, but that doesn’t mean they are fundamentally different.
What about one-time processes?
There is no such thing.
“What? Is he crazy? We have to customize every time!”
Yes you do customize. But if what you did was totally unique and had to be created from scratch each time, then you are claiming you have no experience in your field. Even something as uniquely complex as a building construction project or a tailored treatment plan for a cancer patient, still has answers to the above questions. There is some outcome you are trying to achieve, and you really ought to know what it looks like. And you construct a specific sequence of tasks which you believe will get that done. And those sub-tasks are all things you already know how to do, or have a good idea what to expect when you try them. You still have (or should have) a verifiable outcome, and your best estimate of what is required for success. You may answer these questions every time, but you still answer them.
What Kind of Process?
Your improvement approach depends a little on the nature of the process. This has less to do with “manufacturing” or “non-manufacturing” than it has to do with the nature of the variation drivers.
Is largely repetitive?
A surprising number of administrative processes fit into this category. Almost all accounting transaction processing does. So do order entry, insurance claims, medical records updating, routine approvals (contracts, loans, etc), and preparing routine reports. Those are just the ones that come to mind right now.
What makes them seem different from “manufacturing” processes is that no one has ever really thought of them as repetitive. But once people grok that these tasks are mostly doing the same thing over and over, then just about every trick in the manufacturing kaizen book directly applies.
Here are a few things to keep in mind:
A lot of repetitive process are buried in noise. People do not have what they need, so they have to go on safari. In manufacturing it is possible to see this happening because the Team Members usually have to stop working and go looking. But administrative people do their hunting and gathering from their desks, so they (and their leaders) are often unaware that they have “stopped working” – but they have. They just look like they are working. The process feels irregular because the hunting and gathering gets mixed in with the “doing.”
In manufacturing we say “do not launch the job until the parts are available.” The solution is the same in admin – a front-end process of triage.
Triage is a term from the medical community. In a largely repetitive administrative process, the idea is to ensure the people have what they need before they start. A quick assessment of the documents can quickly divide incoming requests into three categories:
- Everything needed is here, it is routine. Drop into the work queue.
- It is routine, but incomplete. Finish the information gathering first. Do not send it to the work queue until it is complete and routine.
- This is a true exception. Process it off-line, not as part of the routine work.
Consider the alternative. Most of the packets can be processed in an hour. But if one is incomplete, there is another hour or two of research, interruptions, information gathering to do. While that one is being worked on, there are two more routine ones that are not getting done. Every time the process is interrupted, more work falls behind.
A true exception that takes two days, meanwhile, stalls 16 routine ones.
By separating the routine from the non-routine, you allow at least part of the process to stabilize. With stability comes standardization, and with standardization comes kaizen opportunities.
Is is truly non-repetitive?
If you apply the thinking described above, surprisingly few processes drop into this category. But there are true exceptions. Preparing complex bids and proposals, true research and design, some trials and tests, and true creative work come to mind as some possible examples.
Nevertheless, “the questions” that I posed at the beginning still apply, and the better you ask them, the more clear you are.
In the end, you want to have a plan. This consists of:
- A defined, verifiable outcome. A definition of “success.”
- A defined series of verifiable tasks, listed in a specific sequence, with expected timing.
To put the same thing in the terms used in “Decoding the DNA of the Toyota Production System” – your activities are “Highly specified in terms of content, sequence, timing and outcome.” Further, you have checks on execution (content, sequence, timing) and checks on the outcome.
What’s the point? Kaizen is a process of applying structured learning.
In both of the above cases you have defined what you are going to do, and defined what you expect as a result. You are checking to see if what you actually do differs from what you planned to do; and you are checking to see if your actual result differs from the expected result.
When you see a difference STOP. Does this mean literally stop in place? Sometimes, but usually no. But it does mean to stop pretending you are still following the plan as intended, because you aren’t. You are now processing an exception to the plan. This simple consciousness is the first step in learning.
Why did the Team Member have to depart from the plan? Maybe there was something you didn’t think of. Maybe you designed a process that is actually impossible. Maybe there is a vital tool, fixture, part missing. Maybe information is missing or wrong. Whatever it is, see it, fix it, understand why it happened and then fix that.
What Makes Administrative Kaizen Hard?
The “Big Picture” is often invisible.
Many administrative processes involve a lot of complex interconnections. Nobody ever designed them, they just morphed into what they are as local people tried to deal with the effects of system problems. Since there is no real architecture, it is probable that nobody actually knows how the whole things works, or understands the unintended consequences of local countermeasures that cause problems elsewhere. (A disturbing percentage of corporate information systems follow the same general architecture.)
Countermeasure
There are two broad approaches. The first is to decide that whatever is the current process, it is too complex and too broken to fix. Start over. Honestly, I think this isn’t done often enough. Go through the questions listed above and systematically engineer how things are supposed to go.
The other (and more common) approach is to try to fix it. That means:
- Thoroughly understanding how it works today.
- Looking for:
- Ambiguity – places where people are unsure what is expected.
- Breakdown – places where there is a difference between what you expect (should happen) and what really happens.
- Rework – places where people have to fix something that should have been done differenty.
- Overprocessing – places where people are doing, again, something that has already been done. (Data entry is notorious for this… re-entering information that is already in the computer.)
- Systematically addressing these issues starting at the customer end and working your way back.
Most “kaizen events” stop at this point, and they fail to anchor the improvements. Again, this is not unique to administrative processes, but it is much easier to omit this step, and much harder to see the consequences.
The vital step is, as you define what should be happening, to also put in those “checks.” Any departure from your specified outcome, or your specified process to produce that outcome, is a “problem” and problems must be identified and corrected immediately; then they must be understood. The learning gained must be applied to make the process itself more robust.
At the end, administrative kaizen is exactly the same as manufacturing kaizen, but most of us do both badly, and manufacturing kaizen is more tolerant of a poor approach. This, I believe, is why many people think the two are fundamentally different.