Category: The Basics

Posted on

TPS Failure Modes – Part 1

Following on from the buzz created by the last couple of posts, I would like to go back in time a bit.

In 2005 Steven Spear wrote a working paper called “Why General Motors Lost and Toyota Won.” A reader can clearly the see emerging themes that were developed into his book Chasing the Rabbit .

Spear talks about the leverage of “operationally outstanding” in changing the game, the capabilities he sees in “operationally outstanding” organizations, then “Failure Modes at Becoming Toyota Like.”

I would like to dwell a bit on these failure modes, and reflect a little on what they look like.

Failure Mode 1: Copy Lean Tools Without Making Work Self Diagnostic

So what does “self diagnostic” mean?

For something to be “self diagnostic” you need two pieces of information:

  • What is supposed to happen.
  • What actually happens.

Then you need some mechanism that compares the two and flags any difference between them. This sounds complicated, but in reality, it isn’t.

Let’s look at a common example: At the most basic level, this is the purpose of 5S.

5S as a Self Diagnostic Tool

In 5S, you first examine the process and seek to understand it. Then, applying your best understanding, you decide what is necessary to perform the process, and remove everything else. Applying your best understanding again, you seek to locate the items where they would be used if the process goes the way you expect it to.

You improve the self-diagnostic effect by marking where things go, so it immediately clear if something is missing, out of place, or excess.

Then you watch. As the process is carried out, your “best understanding” is going to be tested.

Can it be done with the things you believed are necessary? If something else is required, then you have an opportunity to improve your understanding. Get that item determine where it is used, and carry out the operation. But go a little deeper. Ask why you didn’t realize this was needed when you examined the process. Challenge your process of getting that initial understanding and you improve your own observation skills.

Is everything you believed is necessary actually used? If not, then you have another opportunity to improve your understanding. Is that item only used sometimes? When? Why? Is it for rework or exceptions? (see failure mode #2!) Why did you believe it was necessary when you did your initial observation?

Does something end up out of place? Is it routinely used in a place other than where you put it? This is valuable information if you now seek to understand how the process is different from what you expected.

Now think about the failure mode: What does fake-5S look like? What is 5S without this thinking applied?

How do you “do” 5S?

Look long and hard if you are trying to audit your way into compliance rather than using it as a diagnostic for your understanding of your process.

Though the jargon “self diagnostic” sounds academic, we have all talked about visual controls “distinguishing the normal from the abnormal” or other similar terms. It is nothing new. What makes this a failure mode is that people normally don’t think it is that important when Spear cites a mountain of evidence (and I agree) that this is critical to success. You can only solve the problems you can see.

Another Example: Takt Time

What is takt time? Before you whip out your calculators and show me the math, step back and ask the core question of “What it is” rather than “how to calculate it.” What is it?

Takt time is part of a specification for a process – it defines what should be happening. By setting takt time you are saying “IF our process can routinely cycle at this interval, then we can meet our customer’s demand. Takt time defines both part of a “defect free” outcome of your work cycle as well as a specification for process design.

Then you apply your very best knowledge of the process steps and sequence and set out a work cycle which you believe can be accomplished within the takt. It becomes self-diagnostic when you check, every time if the actual work cycle was the same as the intended work cycle. An easy way to check is to compare the actual time with the designed time.

In Decoding the DNA of the Toyota Production System, Spear cites an example of seat installation.

At Toyota’s plants, […] it is instantly clear when they deviate from the specifications. Consider how workers at Toyota’s Georgetown, Kentucky, plant install the right-front seat into a Camry. The work is designed as a sequence of seven tasks, all of which are expected to be completed in 55 seconds as the car moves at a fixed speed through a worker’s zone. If the production worker finds himself doing task 6 (installing the rear seat-bolts) before task 4 (installing the front seat-bolts), then the job is actually being done differently than it was designed to be done, indicating that something must be wrong. Similarly, if after 40 seconds the worker is still on task 4, which should have been completed after 31 seconds, then something, too, is amiss. To make problem detection even simpler, the length of the floor for each work area is marked in tenths. So if the worker is passing the sixth of the ten floor marks (that is, if he is 33 seconds into the cycle) and is still on task 4, then he and his team leader know that he has fallen behind.

assembly-valencien-640

On this assembly line, time is used, not so much to pace the work, but as a diagnostic tool to call out instances when the work departs from what is intended – or in simpler terms, when there is a problem.

All of this has been about checking that the process is being carried out as expected. But, bluntly, the customer really doesn’t give a hoot about the process. The customer is interested in the output. How do you know that the output of your process is actually helping your customer?

To know that you first have to be really clear on a couple of things:

  • Who your customer actually is.
  • What value do you provide to that customer?

Put another way, can you establish a clear, unambiguous specification of what a defect free outcome is for each supplier-customer interface in your process? Can you follow that trap line of supplier-customer interfaces down to the process of delivering value to your paying customers?

To make this self-diagnostic, though, you have to not only specify (what should be happening), you have to check (what is actually happening), and you have to do it every time.

So poka-yoke (mistake proofing) is a way to verify process steps. Other mistake proofing will detect problems with the outputs. All are (or should be) designed to diagnose any problems and immediately halt the process or, at the very least, alert someone.

The theme that is emerging here is the concept of PLAN-DO and CHECK, with the CHECK being thoroughly integrated into the process itself, rather than a separate function. (Not that it can’t be, but it is better if CHECK is continuous.)

The Supply Chain

I was walking through the shop one afternoon and spotted an open bundle of steel tube – about half of them remaining. They used kanban to trigger re-order. The rule of kanban is that the kanban card is pulled and placed in the post when the first part is consumed. To make this clear, they literally attached the kanban to the bands with a cable tie. Thus, breaking the band would literally release the kanban. Simple, effective.

But, though this bundle had been opened, there was the kanban card still attached to the (now broken) banding. It was lurking at the base of the pallet, but visible.

I went and got the supervisor, and told him that “You are going to have a shortage of 4×5 tube on Wednesday, and it is your fault. Would you like to know why?” I guess I should point out that I had a pretty good relationship with this guy, so he knew I was playing him a little. Then I just said “Look, and tell me what you see.”

It took a few seconds, but he saw the kanban, said “Argh” and started to pick it up to put into the post. I stopped him and asked if it was his responsibility to do that. No, it was the welder’s responsibility. “Then you should take a minute with him, and do what I just did with you.”

Then I asked him how often the kanban cards were collected. (I knew, I wanted to check that he knew.) “Daily, about 1 pm.”

“How often do you walk by here every day?” He said at least twice, in the morning and right after lunch. “So all you need to do is take a quick glance as you walk by, twice a day, and you will always get that kanban into the post before 1pm.”

He did, and their periodic shortages dropped pretty much to zero.

Why?

First, the system was set up JIT. We knew the expected rate of use of that part. We knew the supplier’s lead time and delivery frequency. We knew the bundle size. MATH told us the minimum number of kanban cards that would need to circulate in this loop to ensure the weld cell never ran out… unless one of the inputs was wrong or unless the process operated differently than we expected.

We also knew that, given the rate of consumption, how many bundles should be in the shop at any given time, and we had space market out for just that amount. Thus, we could tell immediately if something was received early, or if our rate of consumption fluctuated downward. (Because a pallet would arrive, but there would be no place to put it.)

We could have just had a Team Member come by once a day and check if a bundle had been opened, and send an order to replenish it. We could have been even more sophisticated and just set up a barcode scan that would trigger a computer order.

But if we had set up the process that way, how could the Supervisor distinguish between “Ordered” or “Not Ordered?” It was that stray out-of-place kanban card that told him.

Bin with kanban cardThus, physical kanban cards, physically attached to the materials, represent a self-diagnostic check. If the card is there, then that container should be full. Quick to check. If the container is not full, there should be no card. Quick to check. If a container arrives with no card, it was not properly ordered and is likely excess (or at least calls for investigation). Quick to check. The physical card, the seeming crude manual operation, provides cross-checks…self-diagnosis… simply and cheaply in ways that few automated systems replicate.

So far these have all been manufacturing examples. But Spear is clear that all work is self-diagnostic, not just manufacturing.

What non-manufacturing work fits into this model?

(Hint: All of it.)

What about a project plan? Though in reality, most project plans don’t. Read Critical Chain by Goldratt to understand the difference – and produce and manage project plans that are much more likely to finish on time.

What about a sales plan? Do you predict your monthly sales? Do you check to see if week 1 actual sales deviated from what was expected? Do you plan on activities that you believe will hit your sales targets? Which customers are you calling on? What do you predict they will do? (Which tests how well you really know them.) Do you actually call on those customers? Do they need what you thought they would? Or do you learn something else about them? (Or do you make a best guess “forecast” and wait for the phone to ring?)

Once you have a sales plan, do you put together a manufacturing and operations plan which you believe will match production to sales? How much variation do you expect to accumulate between production and sales over the course of that plan? Do you put alarm thresholds on your finished goods or your backlog levels that would tell you when that predicted variation has been exceeded?

How do you (and how often do you) compare actual sales (volume, models, and revenue) against the plan? Do you know right away if you are off plan? How long will you tolerate being off plan before you decide that something unexpected is happening? Is there a hard trigger point already set out for that? Or do you let the pain accumulate for a while?

A lot of companies were caught totally by surprise a few months ago when their sales seemed to fall off a cliff. Question: Did you have rising inventory levels before that? Was there a threshold that forced attention to something unexpected? Or did you increasingly tolerate and normalize deviance from your intended business plan?

At the next levels up – you have a business plan of some kind. You have financial targets. Do you have specific actions you plan to take at specific times? Do you check if those actions were actually taken? Do those actions have some kind of predicted outcome associated with them? Do you check if the actual outcome matches what you predicted? If you just “try something to see what happens” you might learn, but you might not. If you predict, then try to see IF it happens, you are more likely to gain more understanding from that experience.

When you design a product, do you have performance specifications? Do you test your design(s) against those performance specifications? Do you do that at every stage, or just at the end?

When you say “We need training” have you first specified what the work process is? Have you studied the situation and determined that people do not have the skills or knowledge to do the job? Have you specified what those skills are?

Have you developed the training to specifically develop those skills? Do you have a way to verify that people got the skills required? Do you check if, now, they can perform the work that they could not perform before? If you didn’t do the last, why did you “train” them at all? How do you know it was not just entertainment?

“Management Is Prediction”

deming

This quote, attributed to W. Edwards Deming, really sums up what this is about. By specifying an outcome – “defect free” (which implies you know that is), within a certain time; and by specifying the process steps; you are predicting the outcome.

“If we do these things, in this sequence, it should require this amount of time, and produce this result.”

Then do it, and check:

Does what you really had to do reflect the tasks you thought would be required?

Does the order you really did them in reflect what was in the plan?

Does the time required reflect the time you planned on?

Did it produce the intended result?

Building those checks into the process itself makes it self-diagnostic.

Try This

Go study a process, any process. Just watch. Constantly ask yourself:

How does this person know what to do?

How does this person know if s/he is doing it right?

What alerts this person if s/he makes a mistake?

How does this person know s/he succeeded?

If there are clear, unambiguous answers right in front of you – without research, without requiring vigilance or luck on the part of the Team Member, then you probably have something approaching self-diagnostic work. Likely, you don’t. If that is the case, don’t say you are “doing lean.” You are only going through the motions.

Posted on

Expectations

This is a bit of a more pragmatic breakdown from the “How Strong Is Your Immune System?” I plan to follow-up with some practical approaches and tools to implement and conduct the kind of problem solving that needs to be done every day.

As we “promote lean,” what expectations to we set?
How well do those promises match up with what is delivered?
If there is a gap, does it dampen the enthusiasm of “management support?”

I think this is important for us to understand.

In the enthusiasm to “make the case” many lean manufacturing proponents point (and rightly so) to the higher performance levels of organizations that have done it. They talk about greatly improved quality, much faster inventory turns, greater returns on capital, much quicker response and throughput. By whatever measure, these systems clearly perform better.

The implementers start teaching the system through its mechanics. Takt time to pace everything; one-piece-flow; pull systems, supermarkets and kanban; quick changeovers; standard work; mistake-proofing.

Now I will be the first to tell you – this is how I was taught – the “just do it, and you will understand” approach. But no matter how well-intended, there is the danger of a diluted message: “Copy the mechanics of how these operations work, and you too can have these results.” Or, put another way, it “Don’t ask questions, just do it” gets (mis)translated into “You don’t have to understand it.”

Wrong. You do.

An expectation is created that, by implementing the basic mechanics of takt, flow and pull, these terrific results can be achieved and sustained.

Here’s the rub. All of the “tools of lean” are designed to force problems to the surface and make them too obvious to ignore. There is an implied expectation that the organization will see these problems and take on the challenge of tackling them as they emerge – true kaizen.

Of course all of this presumes that the organization has the resources, skill and most importantly the stomach to deal with these problems quickly and efficiently.

Bluntly, most don’t. If they did then none of this would have been necessary in the first place.

By implementing the tools alone, they are in effect taking a Newcomen steam engine – primitive, big, inefficient, slow, but functional through brute force- and replacing it with a state of the art steam turbine.

Yes, the turbine is much more efficient, but if you took one and dropped it into the year 1715 it wouldn’t run for very long. They didn’t have the resources or the skill to operate or maintain it.

So, in our lean- implementing factory, the new system is put in and in fairly short order, all of the previously hidden and tolerated problems are now revealed.

And it reveals the problem of “no process to devote the time or to develop the resources and skills to handle those problems” – to detect them, fix them, understand them and solve them.

Lacking the time and skills, the first line leaders do what they must to get the job done… they return to the tried-and-true countermeasures that keep the problems from disrupting things too much:

Kaizen Deterioration Reinforcing Loop

This is the fate of many so-called “kaizen events” which seek to make great change in a hurry.

So why does this happen?

I can speculate that it is a combination of ignorance on the part of some implementers who “got” the “just do it” part but didn’t pick up the “think for yourself” part.

Somewhere, sometime, someone established a precedent that making dramatic but unvalidated changes to a system was “kaizen.” Perhaps, at some point, a sensei said “Don’t ask questions, try this…” with the intention that people would try it and learn what problems came up, only to have it turned into “Do this” without any follow-up or understanding.

Others, perhaps, have an underlying fear that if they revealed just how much work and change was really involved that the leaders would be scared off and not take the first steps.

Now, to be clear, a certain amount of “just try it” is required to anchor that initial leap of faith. But the implementers must be prepared to immediately guide, lead, teach, coach and build the problem solving capability of the organization.

But, in the end, digging further into “Why?” doesn’t give us any more actionable information. “The system is designed to surface problems, and there is no process to handle them” is a root cause that can be directly addressed. It is simply important to acknowledge the truth.

What to do about it. I’ll get into more detail in future posts, but to begin, here are some things to think about:

  1. Small steps. (Note that “small steps” ≠ “slow steps”). Kaizen can be done rapidly, but it must be done deliberately in a context of understanding. Understand why things are the way they are, understand the effect your change should have. Try it out – ideally simulate if first – and see what problems surface. Solve those problems, then implement your change.
  2. Dedicate and manage time for solving problems. This is briefly covered by a couple of previous posts, “Why Doesn’t Daily Kaizen Happen?” and “Systematic Problem Solving” but is worth repeating. Problem solving and kaizen are work, just like anything else. If you want it to happen, you need to allocate time, resources and management to organize it.
  3. Develop a systematic approach, then follow it. I am going to go into some detail on this over the next few posts, but I need to emphasize the last part: then follow it. Too many “standards” are declared, then ignored.
  4. Don’t wait for “the next event” to make improvements.
  5. Just get started. Don’t wait until you are ready, you never will be. The only way to learn is to practice, observe yourself, see what works, what doesn’t, and learn. This, in turn, requires something that is sadly in very short supply in most corporations: humility. Learning means acknowledging, usually in public, that “we don’t have the answers” and perhaps that is the most important lesson.

I could digress into a leadership roles discussion here, but I won’t. But if you want to do a bit of pre-reading for future discussions, find a copy of “Learning to Lead at Toyota” by Steven Spear, and as you read it think about the role of the leader in that story. Bob, the protagonist, starts out with one role, and learns his role is actually quite different. There will be a quiz later.

Posted on

A Firefighting Culture

In honor of October being Fire Prevention Month (at least here in the USA), I’d like to talk about firefighting.

“We have a firefighting culture.”

“We spend all of our time fighting fires.”

We have all heard (and sometimes made) these statements. But I would like to take a couple of minutes and look at what real firefighters do.

They don’t just run in and spray water everywhere in an effort to “do something.”

They study fire. They seek to understand how fires start, how they burn, how they spread. They understand the interactions between fire, air, the specific environment (building structure, outdoor terrain, etc).

They develop a plan to attack the fire. They make themselves reasonably sure that if they do (a), (b), and (c) that the fire will respond in a predictable way.

They execute the plan.

They watch the results. If the fire behaves the way they predicted it would, they continue with the plan. If something unexpected happens, they pause their thinking long enough to understand what additional factor may be at play; what they might not have known or considered. They seek to understand the situation whenever something is going differently than what they predicted.

They adapt the plan to account for the new information or the changed circumstances.

They continue to do this until the situation is under control, and the fire is out.

While doing these things, they work methodically. They verify success at each step of the plan – they do not move ahead of their confirmed progress (which would put fire behind them and block their escape route).

While theirs is a dangerous business, they do not, as a matter of course, put human life in jeopardy simply to save property. Heroics are reserved for saving the lives of others.

Once the fire is out, the fire investigators arrive. They seek to understand how this fire started. Where did fuel, oxygen and a source of ignition come together and how? What fire suppression mechanisms failed, and why? How, why, did it spread? Did containment fail? This information is incorporated into the knowledge base of the society in general in the form of regulations, building codes, electrical codes – countermeasures.

In short – firefighters relentlessly follow PDCA.

Now, I must admit that, occasionally, in the excitement of the moment, firefighters get ahead of themselves, or rush into something they don’t fully understand. We usually know when this has happened because there are somber processions and bagpipe music. But even then, they seek to understand what happened, why, and improve their process to prevent recurrence.

Now, the next time you say “All we do is fight fires” consider the above. My guess is that you aren’t fighting anything. Rather, you are running around, making a lot of noise, but tomorrow the building is still burning – just in a different place.

Don’t forget to check your smoke alarms and change the batteries!

Be sure to read the follow-on post here: /2011/01/17/firefighting-kata/

Posted on

The Power of Vision

In the last post I brought up the advantage of having a long range plan vs. quarter-to-quarter thinking. I’d like to explore the concept a little more by way of an analogy.

Put yourself in the spring of 1961.
The USSR, by all demonstrative measures, is ahead of the USA in human space flight, and seems to be increasing that lead. On April 12, Yuri Gagarin orbited the Earth. On May 5, Alan Shepard went up, and came down on a 15 minute trajectory.

At the time, there were important geo-political reasons for establishing a public perception of technological leadership, and space exploration seemed to be the place to do it.

On May 25, President Kennedy made a public commitment to regain, and maintain, that leadership. He could have done it with corporate-speak:

This nation will become the world leader in space exploration.

But he didn’t. He said:

“I believe that this nation should commit itself, to achieving the goal, before this decade is out, of landing a man on the moon, and returning him safely to the Earth.”

Only the second statement is actionable. Only the second statement carries the possibility of failure. And only the second statement galvanizes action. In pursuing that goal with that degree of commitment, it achieved the first – to demonstrate world leadership in space exploration, not with words, but with action.

Of course the first statement carries no risk, since there is no actual performance requirement. Perhaps that is why corporate-speak carries that kind of language today. The shareholders can’t fire the board for not achieving something that was never articulated. The statement leaves open the capability to re-define the goal so that it matches what was actually done – something that happens all too often in today’s world.

So when one company says “We are going to sell more products next year.” and another says “We are on year 2 of our 10 year plan to be #1 in sales with 15% market share.” which one do you think can align actions of the people in the company?

To continue, when Kennedy made that speech:

  • The United States had a human space flight experience totaling 15 minutes.
  • The world had human space flight experience totaling under 2 hours.

Nobody actually knew, for sure, what the moon was made of.

To be sure, the visionaries within NASA had been thinking about sending someone to the moon for a long time. And in May, 1961 there were competing strategies in play at NASA for getting it done. They either involved an unimaginably HUGE rocket (think twice the size of the one that actually did it), or two or three Saturn class rockets to launch and assemble the lunar spacecraft in orbit. But when faced with a deadline of “before this decade is out,” the challenges were immense. Another strategy, considered a bit crackpot at the time, was named “lunar orbit rendezvous.” It involved a smaller (but still huge) rocket to send a throw-away lander on the moon along with a re-entry capsule. The capsule remains in lunar orbit, the lander lands, takes off, docks with the capsule. The crew transfers to the capsule, and they head home. As each piece fulfilled its intended purpose, it would be discarded.

It became increasingly clear, in the months that followed the speech, that neither of the “mainstream” approaches would get the job done with the time and resources available.

During the summer, consensus formed around the lunar orbit rendezvous scenario.
Key Point: Once they decided to pursue that option all further pursuit of the others was stopped. They committed. They did not have the resources to do otherwise.

In the corporate world, how often does that happen? Once a project, or even an idea, has any kind of resourcing or momentum behind it, stopping it is incredibly difficult. More things to do get added, but it seems that nothing gets taken off. This is equally true of “improvement schemes.” I recall a company that had active people in various improvement initiatives. There was the “Workout” group. There were the TQM people. There were the Six Sigma folks. (It took me a while to realize that the TQM and Sigma people considered each other competitors, where I had initially lumped them in together.) Then there were the “Lean guys” who had just come in. There were also pockets of Theory of Constraints believers, the agile guys, everyone saying they had “the answer.”

Back to NASA.

Landing a person on the moon by the end of the decade was a clearly articulated vision for accomplishing the high level mission of becoming “the world leader in space exploration.” That was the hoshin.

After a round of “catchball” a strategy was selected from the options available. Note that the catchball didn’t negotiate the goal. That was stated. The question was not whether to do it, but how to do it. The strategy was Lunar Orbit Rendezvous (LOR). They committed to the strategy and ceased all distracting activity to focus 100% of their energy on getting it done.

To make LOR work, they had to learn three things:

  1. Can people stay and work together in space for the 10-14 days required for the trip?
  2. Can people work outside the spacecraft in protective suits?
  3. Can one space vehicle locate and dock with another?

We do these things routinely today, but in 1961 nobody knew the answers.

These three things were the ONLY major objectives of Project Gemini.

The fourth big task was to develop the Saturn V as well as the facility to assemble and launch the rockets.

This goal is very sticky.
Any time one of the hundreds of thousands of Team Members working at NASA and in the contractors had a decision to make, the criteria was simple: “Will this action help the effort to put a man on the moon by the end of the decade?” If the answer was “No” then don’t do it. Great idea. But don’t do it. We don’t have the time or energy for the distraction.

The second thing it did, and this is even more important, is in the face of major setback – the Apollo 1 fire in January 1967, the organization was able to recover, regroup and stay on course because they had a sense of destiny. There was a clear goal, and they were working to meet it. It provided a compass that pointed the way when all other navigational references were blacked out.

Contrast this with the way NASA has been run during the Shuttle era. The massive amounts of energy involved in space travel mean this is, and is likely to remain, a risky business. But in the shuttle era, the tragedies seem to have created doubt and loss of confidence. There is no higher purpose other than space flight for its own sake. They are running it like a business.

“But we ARE a business! you may say. Sure you are. But the truly excellent businesses, those with the ability to adapt to changing situations quickly and recover are the ones whose sense of “self” transcends quarterly profits and financials. They are successful because they stand for something more.

A few years ago I remember standing outside in the Seattle area during an earthquake that lasted close to a minute. It was an unsettling experience because the ground itself was moving. Leadership’s job is largely providing a sense of solid ground so everyone else can operate without feeling off balance. This is done with very clear goals that are

  • Simple to understand.
  • Unexpected – they compel attention
  • Concrete – they can be seen, touched, felt.
  • Credible – they make sense in the larger context.
  • Emotional – they appeal to people’s feelings and
  • have Stories – they can be communicated in a way people can visualize.

Kitchen sink “KPI” lists don’t do this.

Posted on

Beyond the Value Stream

As I mentioned a long time ago, Art Smalley’s web site, http://artoflean.com, is an excellent resource for learning. His thinking is cutting edge – he has kept up in the field.

I am mentioning it here because he has a couple of really good resources available.

Learning From Toyota is a presentation that challenges some of the conventional thinking about what “lean” is… or better, contrasts the current “lean industry” from Toyota’s thinking and approach.

The Eight Basic Questions of TPS is a longer article on the same topic.

In both cases, Art emphasizes that the classic approach of mapping value streams and implementing flow cover only a very small fraction of what makes up the system. Indeed, in my opinion, those steps will uncover (e.g. confront) many more previously buried problems than they resolve. Yet so many practitioners, many of them even taking your money as consultants, never go beyond these basic steps.

Look at the “classic” questions and Art’s questions, and see for yourself how different the path is.

Posted on

Anchoring a Problem Solving Culture

More than a few organizations I know are starting to understand the importance of establishing a culture of problem solving. Hopefully they are shifting from a tools implementation model to one which emphasizes how people respond to the daily friction generators.

In an email on the topic to a friend today, I cited four things that I think need to be there before this can be achieved. Upon reflection, I’d like to expand upon and share them. I think I can say that a lot of the failures I have seen can be traced back to only emphasizing one or two of them.

The organization must reset its definition of “a problem.”

I started to get at this mindset back in January with the post “Chatter as Signal.”

In “traditional” organizations something is labeled “a problem” when it causes enough disruption (or annoys the right (wrong?) person). Anything that does not cross that threshold is tolerated. The “problem” with this approach is that many small issues are ignored and worked around. Their effects, though, tend to clump and cluster into larger cumulative symptoms. When those symptoms reach the threshold of pain, someone starts wanting some kind of action, but by now it is too late for simple solutions.

Another face of the same thinking is the “big problem” syndrome. “We can’t fix everything.” “We have to prioritize on the big hitters.” True enough, but it is not necessary to fix everything at once. That’s the point. Sure, prioritize the technically tough problems. But, at the same time, put the systems into place that allow everyone to work on the little ones, every day.

When the “big problem” statements are used as a “can’t do it” or “we can never be perfect” excuse, the organization’s underlying mindset has dropped into the ”

The “Chatter as Signal” attitude really means instead of putting together plans and processes and then tossing them over a wall for blind execution, the problem solving organization systematically and continuously checks “reality” (what really happens) against their “theory” (the plan, what they expect to happen). Whenever there is a difference between the two, they look at that as “a problem.”

Maybe the term “problem” is unfortunate.

A lot is made out there about being truly forward-looking organizations seeing “mistakes” as opportunities to learn. A “mistake” is nothing other than an instance of “We did this thinking some specific thing would happen, but something unexpected happened instead.” Or “We thought we could do it this way, but it turns out we couldn’t.” In different words, those events are “the outcome wasn’t what we planned” and “we couldn’t execute the process as planned.” In other words, “problems.”

In summary, specify what you intend to accomplish, how and when you intend to do it.
Any departure, necessary or inadvertent, from this specification is a problem.

The organization must have a process for immediately detecting and responding to problems.

It doesn’t do much good to define a problem unless you intend to respond. And you can’t stand and watch every second for problems to occur. That is the whole point of jidoka. When Sakichi Toyoda developed his loom, the prevailing common thinking was “sometimes the threads break.” “When that happens, some material is ruined.” “That is reality.” “Perfection is impossible.” Chatter is noise.

But Sakichi changed the dynamic when he designed a loom that detected a broken thread and shut itself down before any bad material was woven. Now I am fairly certain that, even today, threads break on weaving equipment. (And the same technology developed by Sakichi is used to detect it.) So, as a jidoka, this is a case of detecting a small problem and containing it immediately so it can be corrected.

Consider this: If the organization really understands jidoka then any problem that goes undetected is a problem. Thus, it isn’t necessary to fix it all at once. Rather, when problems occur, get back to where they occured. Look at the actual situation. What was the very first detectable departure from the intended process? It is quite likely that it is a small thing, and also likely it happens all the time. But this time it didn’t get caught and corrected.

Then ask: Can you prevent this departure from process?
If you can’t, can it be immediately and automatically corrected?
If not, can the process be stopped?

But detecting the problem is only the first step. The response is even more important. When a Team Member (or a machine) detects a problem and calls for help, a real live human needs to show up and show genuine interest. The immediate issue is simple: Fix the problem. Restore a safe operation that produces defect-free output. That may take a temporary countermeasure involving some improvisation, and may compromise speed and cost a little, but safety and quality are never compromised for anything… right?

The next step is to start the process of actually solving the problem. At a minimum, it needs to be written down and put into the “We’ll work on that” management queue (See the next item) to get solved. Note that “fixing it” and “solving it” are two completely separate things.

The organization must have a process for managing problem solving.

When a problem occurs, the first response is to detect it, then to fix (or contain) it. That is jidoka. But at some point, someone has to investigate why it happened, get to the root cause, and establish a robust countermeasure.

Again, I have talked around this in a couple of previous posts:
Systematic Problem Solving
A Systematic Approach to Part Shortages

However it is done, however, the organizations that do it well:

  • Have a public written record of what problems are on the radar. The most common approach is a board of some kind in the area where the daily review takes place.
  • Did I just say “Daily Review?” There is a process to check the status of ongoing problem solving activity every day. Problems being worked on do not get a chance to fall off the radar.
  • They manage their talent. The organization I talked about in the “Part Shortages” story had a lot of problems, not just in part shortages, but technical issues as well. Initially they had been assigning each problem to someone as soon as it came up. That quickly became unworkable because, in spite of their tremendous talent, the key players really couldn’t focus on more than one or two things at a time. It was demoralizing for them to get hammered at the meetings for “doing nothing” on five problems because they had been working on the other two. The countermeasure was a prioritized pull system. Each new problem went into a queue. As a problem solver became available (because s/he was done with one), the next problem on the list was assigned. The prioritization system was simple: The manufacturing manager could re-sequence the queue at any time.Thus, the problem at the top of the list — the next one to be assigned — was always the next most important. But it was another important rule that made this work. No one could be pulled off a problem s/he was already working on in favor of a “hot” problem. The only exceptions were a safety issue or a defect that had escaped the factory and had been reported by a customer. However you manage it, keep these things in mind:
    • Don’t arbitrarily multi-task your talent. People can’t multi-task. This is actually overloading. The other word for it is muri.
    • Don’t jerk them from one thing to the next without allowing them completion.
  • They solve the problem at the lowest level of the organization capable of solving it. The corollary here is largely covered below, but it bears mentioning here: If the level that should be solving it isn’t capable then they work THAT problem – developing the skill – rather than ignoring the issue or overloading someone who is never going to have the time to work on it. This is probably the most important lesson in this piece.

They deliberately and systematically develop their problem solving skills at all levels.

It is easy to fall into the trap of assuming that someone with a technical degree is a skilled problem solver and critical thinker. Experience suggests otherwise. And even if there are a couple of people who just have the innate talent, there are not enough of them to go around. There are lots of approaches out there. In reality, all of the effective ones are anchored in the same thinking, they just use different tools and lingo to frame that thinking. My best advice is pick one, teach everyone to use it, then insist that they follow the process exactly. Only by doing that will you actually learn if the process itself has weakness or shortcomings.

Along with this is don’t confuse the tools with the process itself. THIS IS CRITICAL: Anything you draw on paper (or create in a computer) is a tool. The seven problem solving tools are not a process. A statistical control chart is not a process. An A3 is not a process. A cloud diagram is not a process. All of these are tools. The framework in which they are used is structured thinking, and that is a process.

This is important because the process itself is straight forward and simple. It can be taught to anyone. Teaching them the tools, however, teaches them nothing at all about how to solve problems. So many “problem solving courses” spend a week teaching people how to build Pareto charts, histograms, tree diagrams, run charts, even build control charts, and yet teach nothing at all about how to solve problems. Most problems can be solved by unsophisticated troubleshooting techniques that systematically eliminate possible causes. Some can’t, but most can.

This got long, but I guess I had a lot to say on the topic. In the background, I am planning on putting together some basic material on “the process of problem solving” and making it available. Hopefully that will help.

As always, comments are encouraged and appreciated. It tells me that someone actually reads this stuff.

Posted on

Theological Debates

A frequent topic in the lean.org forums is some version of “what is the difference between lean and ____” where the blank is one of the industry buzzwords. Some of the common ones are various prefixes to “Sigma.” Others are old standards such as TQM, SPC, TOC, etc. These discussions are always interesting as the various camps line up. “Lean looks at waste, while xxx-Sigma looks at variation” is a common one. Apparently “Agile” is about high-tech machinery, and of course, none of that is found in “lean.”

My put on all of this is pretty simple. It’s all the same, people.

There is nothing about TPS that excludes any level of machining technology, so long as that technology is applied as a solution to a problem rather than for its own sake. The last time I checked, Toyota, and TPS, were obsessive about stamping out variation. Constraints? Yup. You bet I know what the constraint is, and you bet I manage it tightly. If I have done everything right, my enterprise constraint is production (rather than sales), but just barely. And internally, if I have done it right, my constraint is manual work rather than technology. Why? Because every Team Member can work on improving manual work cycles. Not the case with an engineering constraint.

In the end, this is all about the rational, deliberate application of skilled problem solving, using the scientific method, aka PDCA.

If you are looking at “which one to implement” stop fretting about it. Go out to your work area, stand and watch a while, see what is stopping your good people from doing a great job, and start fixing it.

Posted on

Costs and Kaizen

How does kaizen actually show up on the bottom line?
This is a question that gets asked a lot, and honestly, we owe the asker a better answer than “it just does, trust us.” (Even though this is true.)

Here’s my thinking – it shows up two ways.
One is intangible. By that I mean it is incredibly difficult to quantify, even afterwards. But it is there.

IF the organization manages to get the continuous improvement engine running – meaning they understand that “pursue perfection” is not a “step in implementation” but rather the thing that gets it going in the first place – then, over time, everything starts running more smoothly.

It is hard to put a hard-monetary return on things like:

  • Everybody is working together, as a team, toward the organization’s overall goals.
  • Everybody understands who the customer is, and keeps their focus there.
  • Every instance of a problem causes the organization to improve and learn.
  • Everybody comes to work knowing what they must do to succeed; knowing they can do it; knowing that, if there is a problem, they will find out right away; knowing that they will get support in resolving it.

In short, the organiztion performs, and that performance is getting better and better.
What is that worth? Is it better to have a superbly performing organization, or one which requires continuous micro-management of every detail? (Hint: It isn’t about hiring better people, it is about creating working conditions and processes where regular, competent people can create superb performance.)

But it is possible to understand some direct, tangible returns as well. In fact it is possible to set solid targets, understand what must be done to reach them, and track progress on activities and results.

Any organization that is self-funding (including a non-profit) must offer some kind of value to its paying customers. If “value” is what the customer is willing to pay, then it is easy to determine the, ah, value of the value.

“Value add” defines the economic result of a transformation process. We buy some stuff at some cost (value), transform it into something that is worth more to the customer, and sell it. The difference between what we paid for the stuff we bought, and what the customer paid for the product or service we sold is the “value add.”

Note that this has absolutely nothing to do with what it cost to make that transformation. Nothing at all. It is possible to add value and lose money at the same time. It happens every day.

It does cost something to run the operation that adds the value. When those costs are less than the total value added (over some period), then the organization gets to keep some of the money as profit.

When those costs are more than the amount of value added, then someone has to fund the gap – the owners / shareholders, debt, the money has to come from somewhere.

When it comes to costs, I like to keep things really simple and easy to understand.

Costs are incurred two ways, and in the details, they intermix.

  1. In order to operate, we spend money every day on things like payroll, rent, utilities. This is cash burn.
  2. We have stuff needed to operate. This is cash tied up in the business, capital, inventory, etc. Just having that stuff costs money, and a lot of this stuff depreciates. That depreciation can, in turn, be counted the same as cash burn, but real life is more abstract than that because, while payroll must be paid, “depreciation” is something we can hold our breath about.

I have not included the cost for materials that are transformed into finished product here. That cost is captured in “value add.” The above two things add up to the cost to add that value, and those costs are largely fixed (in the classic sense of the word), whether we make anything or not.

Aside from the actual materials that are bought, transformed, and sold, there are very few truly “variable costs.”

“Continuous improvement” means to continuously increase value add, and continuously decrease what it costs to add that value.

There are fundamentally four ways in increase value-add.

  1. Improve the product offering so that customers will pay more. Ideally this is done without increasing any costs. This is really the only leverage point of purely service businesses.
  2. Pay less for the raw materials and parts – push your suppliers for lower prices.
  3. Change the engineering design to one that is less expensive to source.
  4. Examine your make / buy. Look for high-leverage items that your currently purchase. These are items which:
    1. We could make if we wanted to.
    2. Have a very high differential between the cost of the pieces and what we pay for them. (i.e. the supplier has a very high value-add to us.)

    Now, here’s the rub (and where this ties in to kaizen). If you have been doing a good job at kaizen, you have made some people available. If you know how to make these high leverage parts, can you put those people to work making them? A lot of this depends on the capital required, etc. but, as a general rule, the further up the supply chain you reach, the higher your value add. It comes down to capability and cost. And if you are using labor made available through kaizen, it does not matter what this labor costs. If you are adding more value today than you were yesterday, and incurring exactly the same costs to do so, your profit is higher. And the last time I checked, that was the name of the game.

Aside from increasing value-add, the other objective is to do so at the lowest possible cost, and there is a bit of a circular reference here.

Good kaizen can free up a lot of time. I suppose, if you wanted to do scorched-earth kaizen, you could immediately lay those people off. (Don’t expect much help with further improvements after that.) Aside from the ethical issues, these kinds of actions are really disruptive to the organization, in ways that are difficult to quantify.

If you are trying to simply increase production volume (the right kind of problem to have), then dealing with this issue is fairly simple, you just avoid hiring more people. You increase output without increasing payroll.

But also take a look at the in-sourcing option mentioned above. A lot of organizations overlook these kinds of opportunities today.

Like I said, this model is very simple. It is essentially the “throughput accounting” model offered by the Theory of Constraints folks. (Believe me, I don’t just make this stuff up.) Traditional cost accounting models can be mapped directly into this model. I just find it a lot easier to understand, and more importantly, to explain to the people who actually have to make all of these things happen.

Posted on

There Are (almost) No Big Problems

In a “management by metrics” world, problems are detected when performance indicators are off track. Perhaps inventory is too high, first pass quality is a problem. Maybe operational availability is tanking.

Once the problems are abstracted into numbers, the numbers become the problem. The solution, then, is usually a directive to reverse the trend, to improve this measurement or that measurement, to get things back on track.

Here is the rub: The numbers aren’t the problem. They don’t even tell you what the problem is without a whole lot of investigation, digging, and stratification. And why was this investigation and stratification necessary in the first place? Because now you are trying to sort out a batch of problems that weren’t dealt with, one-by-one, at the moment they occurred.

The further you go up in the organization, the more things are aggregated and summarized. And the more they are aggregated and summarized, the more things look like big problems, even though they are composed of many (hundreds, sometimes) of little problems.

Let me cite an example. I was in a factory where the site manager was proudly showing off his real time display of Overall Equipment Effectiveness (OEE). Each time the equipment slowed, for any reason, the display would immediately change. He could see, at an instant, how the day’s OEE compared with his target, and, he said, “take action.”

But exactly what action is he going to take?
Even the real-time display lags the actual problem.
Two weeks ago a lubrication point was missed. Today something is overheating, and we need to slow or stop the machine to deal with it.

A bracket securing a roller is loose, today the machine is stopping all the time as they clear jams.

A hole in a screen let chips and debris clog a filter, and the coolant pumps are overheating.

This list can go on. The point is that the things that actually slow down or stop the machinery are second, third, fourth levels in chains of events. The actual problem had no immediate effect on the machinery.

In this system, the very best they will ever do is fix it fast and hold the number at some level. They will never be able to actually improve it, because they aren’t dealing with the underlying systemic issue: They aren’t finding and dealing with the actual root causes.

When you get to financial measures, things are even more abstract.

Inventory levels (or inversely, inventory turns) is a great example. “We have too much inventory!” “Our inventory levels are above the industry norm!”

In the boardroom, or in the Chief of Operations’ office, this is all they can see. Because most leaders in that position really like direct action, they.. um.. “direct” that some “action” be taken.

So the organization goes to war against inventory.

Two levels down, “We have too much inventory” is still characterized as the problem because that is what they have to report every month.

Two more levels down it is often still attacking the symptom – too much inventory.

But inventory isn’t the problem.

The problem is an engineering change that missed one part on the bill of material update, delaying production for a day while all of the other parts continued to roll in.

The problem is a paint system that is unreliable, so the factory obsesses on maintaining four hours of buffer on either side of it.

The problem is pressure to keep the line moving, so people work ahead, and push incomplete or problem units into the “hospital” for later repair.

The problem is that the upstream processes have to be ready to respond to massive fluctuations in assembly’s demand.

The problem is a broken jig, local initiative to make something else instead, resulting in too much of what nobody needs and none of what they do – because they don’t want to waste time doing nothing.

An additional problem is that the typical organizational response to these problems is to add more inventory because each local unit needs to protect itself from the dysfunction problems of their suppliers and customers.

Worse, just “taking out inventory” is going to tank everything else because the underlying problems are still there.

Inventory isn’t the problem.

The problem is that each of these small problems is too small to bother addressing as a systematic breakdown that leads to “too much inventory.” While the high-level leaders are looking for a big problem, they are missing their real responsibility.

It isn’t to “do something about inventory.”
It is to ensure that the small problems that occur every day, the ones which cause all of that inventory to accumulate in the first place, actually get addressed. Actually no. Their responsibility is to ensure there are systems in place which catch those problems and address them. They do this by teaching, setting example, then checking.

Leaders – if you want to “do something about inventory” you have to do it by setting an expectation that:

  • Processes are well defined.
  • Those processes are followed.
  • When there is a problem following the process, it is raised immediately.
  • When a problem is raised, it is swarmed, fixed, understood and prevented.

You handle big problems by making sure the small ones are dealt with, every day, all day.

Then your OEE will go up quickly. OEE is an indicator of how well you respond to problems, not how well your machines run.

One more thing – for my Health Care readers.
You can substitute “medication errors” for any of this. But until there is a system in place that alerts anytime someone spots the possibility of confusion, medication errors will occur at pretty much the same rate they always have.

Posted on

The Paper Shuffle

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:

  1. What is the intended outcome?
  2. 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

  1. What tasks need to be performed, in what sequence, to assure the defect-free outcome (defined above) is produced?
  2. As you perform each task, how can you check that it was done as expected, in the sequence expected, in the time expected?
  3. 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:

  1. Everything needed is here, it is routine. Drop into the work queue.
  2. It is routine, but incomplete. Finish the information gathering first. Do not send it to the work queue until it is complete and routine.
  3. 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.