Scientific Improvement Beyond The Experiment

“How do we deploy this improvement to other areas in the company?” is a very common question out there. A fair number of formal improvement structures include a final step of “standardize” and imply the improvement is laterally copied or deployed into other, similar, situations.

Yet this seems to fly in the face of the idea that the work groups are in the best position to improve their own processes.

I believe this becomes much less of a paradox if we understand a core concept of improvement: We are using the scientific method.

How I Think Science Works

In science, there is no central authority deciding which ideas are good and worth including into some kind of standard documentation. Rather, we have the concept of peer review and scientific consensus.

Someone makes what she believes is a discovery. She publishes not only the discovery itself, but also the theoretical base and the experimental method and evidence.

Other scientists attempt to replicate the results. Those attempts to replicate are often expanded or extended in order to understand more.

As pieces of the puzzle come together, others might have what seems to be an isolated piece of knowledge. But as other pieces come into place around them, perhaps they can see where their contributions and their expertise might fit in to add yet another piece or fill in a gap.

If the results cannot be replicated at all, the discovery is called into serious question.

Thus, science is a self-organized collaborative effort rather than a centrally managed process. All of this works because there is a free and open exchange among scientists.

It doesn’t work if everyone is working in isolation… even if they have the same information, because they cannot key in on the insights of others.

What we have is a continuous chatter of scientists who are “thinking out loud” others are hearing them, and ideas are kicked back and forth until there is a measure of stability.

This stability lasts until someone discovers something that doesn’t fit the model, and the cycle starts again.

How I Think Most Companies Try To Work

On the other hand, what a lot of people in the continuous improvement world seem to try to do is this:

Somebody has a good idea and “proves it out.”

That idea is published in the form of “Hey… this is better. Do it like this from now on.” image

We continue to see “standardization” as something that is static and audited into place. (That trick never works.)

What About yokoten. Doesn’t that mean “lateral deployment” or “standardize?”

According to my Japanese speaking friends (thanks Jon and Zane), well, yes, sort of.  When these Japanese jargon terms take on a meaning in our English-speaking vernacular, I like to go back to the source and really understand the intent.

In daily usage, yokoten has pretty much the same meaning [as it does in kaizen] just a bit more mundane scope…along the lines of sharing a lesson learned.

Yokogawa ni tenkai suru (literally: to transmit/develop/convey sideways) is the longer expression of which Yokoten is the abbreviation.

Yoko means “side; sideways; lateral. Ten is just the first half of “tenkai” to develop or transmit. Yokotenkai..

If you take a good look at the Toyota internal context, it is much more than just telling someone to follow the new standard. It is much more like science.

How the Scientific Approach Would Work

A work team has a great idea. They try it out experimentally. Now, rather than trying to enforce standardization, the organization publishes what has been learned: How the threshold of knowledge about the process, about a tricky quality problem, whatever, has been extended.

We used to know ‘x’, now we know x+y.

They also publish how that knowledge was gained. Here are the experiments we ran, the conditions, and what we learned at each step.

Another team can now take that baseline of knowledge and use it to (1) validate via experimentation if their conditions are similar. Rather than blindly applying a procedure, they are repeating the experiment to validate the original data and increase their own understanding.

And (2) to apply that knowledge as a higher platform from which to extend their own.

But Sometimes there is just a good idea.

I am not advocating running experiments to validate that “the wheel” is a workable concept. We know that.

Likewise, if an improvement is something like a clever mistake proofing device or jig (or something along those lines), of course you make more of them and distribute them.

On the other hand, there might be a process that the new mistake-proofing fixture won’t work for. But… if they applied the method used to create it, they might come up with something that works for them, or something that works better.

“That works but…” is a launching point to eliminate the next obstacle, and pass the information around again.

oh… and this is how rocket science is done.

Edit to add:

I believe Brian’s comment, and my response, are a valid extension of this post, so be sure to read the comments to get “the rest of the story.” (and add your own!)

Cruise Ship Cabins on an Assembly Line

Royal Caribbean Cruise Lines released a cool P.R. video showing the production of cruise ship cabins on an assembly line with a 14 minute(!) takt time.

The key point, for me at least, is that even “big one-off things” can often be broken down into sub-assemblies that have a meaningful takt time of some kind. We have to look for the opportunities for what can be set up to flow vs. reasons why we can’t.

Click Here for the direct link to the page on Royal Caribbean’s press page.

 

Checklists: “Do.” vs. “Did you do?”

When operations or steps get omitted, a common countermeasure is to establish a checklist.

A typical checklist has a list of items or questions – sometimes even written in the past tense.

“Was the _______?”

There are a couple of common problems with this approach.

First, the time to actually, physically make the checks is not included in the planned cycle time. This implies we are expecting the team member to review the checklist and remember what she did.

The second issue is that the team member often does remember doing it even if it wasn’t done.

This is human nature, it isn’t a fault or flaw in the individual. It is impossible to maintain continuous  conscious vigilance for any length of time. There are techniques that help, however they require some discipline from leaders.

Overall, a checklist that asks “Did you___?” in the past tense is mostly ineffective in practice.

We make things worse when the checklist is used as a punitive tool and we “write up” the team member for signing off on something that, actually, didn’t get done. Most of the time it does get done, but everyone in this system occasionally misses something. Sometimes those errors get caught. This kind of “accountability” is arbitrary at best.

Where checklists work is in “what to do next” mode – referring to the check list, doing one item, checking off that it was done, then referring to the next item on the list. This is how it works in an airplane cockpit.*

CAPTAIN: okay, taxi check.

FIRST OFFICER: departure briefing, FMS.

CAPTAIN: reviewed runway four.

FIRST OFFICER: flaps verify. two planned, two indicated.

CAPTAIN: two planned, two indicated.

FIRST OFFICER: um. takeoff data verify… one forty, one forty five, one forty nine, TOGA.

CAPTAIN: one forty, one forty five, one forty nine, TOGA.

FIRST OFFICER: the uh weight verify, one fifty two point two.

CAPTAIN: one fifty two point two.

FIRST OFFICER: flight controls verify checked.

CAPTAIN: check.

FIRST OFFICER: stab and trim verify, thirty one point one percent…and zero.

CAPTAIN: thirty one point one percent, zero.

FIRST OFFICER: the uh…. engine anti-ice.

CAPTAIN: is off.

FIRST OFFICER: ECAM verify takeoff, no blue, status checked.

CAPTAIN: takeoff, no blue, status checked.

FIRST OFFICER ON PA: ladies and gentlemen at this time we’re number one for takeoff, flight attendants please be seated.

FIRST OFFICER: takeoff min fuel quantity verify. nineteen thousand pounds required we got twenty one point eight on board.

CAPTAIN: nineteen thousand pounds required, twenty one eight on board.

FIRST OFFICER: flight attendants notified, engine mode is normal, the taxi checklist is complete sir.

(This is also how it works when assembling a nuclear warhead, but I can’t tell you that.)

This is also very effective for troubleshooting. For example, I was working with a team in a food processing plant. The obstacle being addressed was the long (and variable) time required to change over a high-speed labeling machine and get it “dialed in” and running at full speed without stops and jams.

Some operators were much better at this than others. We worked to capture an effective process of returning the machine’s settings to a known starting point, then systematically adjusting it for the specific bottle, label, etc. It worked when they were able to slow down enough to use it. That was an instance of “Slow is smooth; smooth is fast.”

The act of reading out load, performing the action, and verbally confirming is very effective when it is actually done that way. Even so, people who are very familiar with the procedure will often take shortcuts. They don’t “need” the checklist… until they do.

Still, you have a sequence of operations, and it is critical that they are all performed, in a specific order, in a specific way.

What works?
I’d say look around.
If you are reading this, you likely have been at least dabbling, and hopefully trying to apply “lean” stuff for a while.

What is a basic shadow board? It is a “checklist” of the tools to confirm they are all there – and a lot faster because missing items can be spotted at a glance. At a more advanced level, companies move away from shadow boards and to having the visual controls outlining what should be where to perform the work.

Color coded tool holders.

If you kit parts, you can set them out in a sequence – a “checklist” that cues the team member what order they should be installed.

I could continue to cite examples, but here’s the point.

When things are being left out, there is a high temptation to say “Let’s make a checklist” and sometimes make it worse by saying “…and we’ll have the worker sign it off for accountability.” That is more often than not simply a “feel good” solution. You feel like you have done something, and I’ve even heard “Well, it’s better than nothing.” I’m not sure it IS better than nothing – at least not in very specific conditions.

Instead, you need to study the actual work. Don’t try to ask questions, just stand and watch for a while. (Explain what you are doing to the team member first, otherwise this is creepy. “Hi – I’m just trying to understand some of the things that might get in your way. Do you mind if I just watch for a while without bothering you?”)

What cues the team member which step to perform next? Does he have to know it from memory? Or is there something built into the way the workplace is organized?

Does he end up going back and doing things he forgot?
Does he set out parts and tools in order on his own so he doesn’t forget?
Does he get interrupted, by anyone or anything, that takes him out of his mental zone?
(I go through airport TSA security checkpoints at least twice a week. I have a routine. When the TSA agent tries to “help” by talking to me, my routine gets broken, and that is when I forget stuff.)

If you are coaching someone, it helps if you go there with them, help the see the details by spotting these things and “asking” about them; then taking them to another area and challenging them to see as many of these issues as they can. See who can spot more of them.

What you are seeing are obstacles that impact the team member’s ability to do quality work.

Checklists don’t help remove those obstacles.

___________________

*The checklist transcript here is a cleaned up version of the Cockpit Voice Recorder transcript from Cactus 1549, the US Airways A320 that successfully landed in the Hudson River after multiple bird strikes knocked out both engines. I used it here because it is authentic, and the accident was one where everything went right and no one was seriously injured.

Applying 5S to Processes

The idea that “you always start with 5S”, for better or worse, has been deeply ingrained in the “lean culture” since the late 1980’s. A lot of companies start their improvement efforts by launching a big 5S campaign.

Often, however, these 5S efforts are focused on striving for an audit score rather than focusing on a tangible operational objective.

It is, though, very possible to help bridge the gap by putting the process improvement in 5S terms. By using a language the team already understands, and building an analogy, I have taken a few teams through a level of insight.

For example –

We are trying to develop a consistent and stable work process.

Sort

Rather than introduce something totally new, we looked at the process steps and identified those that were truly necessary to advance the work – the necessary. The team then worked to avoid doing as many of the unnecessary steps as possible. In their version of 5S, this mapped well to “Sort.”

Now we know the necessary content of the work that must be done.

Set in Order

Once they knew what steps they needed to perform, it was then a matter of working out the best sequence to perform them. “Set in order.”

Now we’ve got a standard work sequence.

Sweep or Shine

The next S is typically translated as something like “Sweep” or “Shine” and interpreted as having a process to continuously check, and restore the intended 5S condition.

Here is where a lot of pure 5S efforts stall, and become “shop cleanup” times at the end of the shift, for example. And it is where supervisors become frustrated that team members “don’t clean up after themselves or “won’t work to the standard.”

In the case of process, this means having enough visual controls in place to guide the work content and sequence, and ideally you can tell if the actual work matches the intended work. A deviation from the intended process is the same as something being “out of place.” Then, analogous to cleaning up the mess, you restore the intended pattern of work.

One powerful indicator is how long the task takes. Knowing the planned cycle time, and pacing the job somehow tells you very quickly if the work isn’t proceeding according to plan. This is one of the reasons a moving assembly line is so effective at spotting problems.

Now we have work content, sequence and maybe timing, or at the very least a way to check if the work is progressing as intended. Plan, Do and Check.

I believe it is difficult or impossible to get past this point unless your cleanup or correction activities become diagnostic.

Standardize

The 4th S is typically “Standardize”

Interesting that it comes fourth. After all, haven’t we already defined a standard?

Kind of. But a “standard” in our world is different. It isn’t a static definition that you audit to. Rather, it is what you are striving to achieve.

Now, rather than simply correcting the situation, you are getting to the root cause of WHY the mess, or the process deviation happened.

In pure 5S terms, you start asking “How did this unintended stuff show up here?”

The most extreme example I can recall was during a visit to an aerospace machine shop in Korea many, many years ago. The floors were spotless. As we were walking with the plant manager, he suddenly took several strides ahead of us, bent down, and picked up….. a chip.

One tiny chip of aluminum.

He started looking around to try to see if he could tell how it got there.

They didn’t do daily cleanup, because every time a chip landed on the floor, they sought to understand what about their chip containment had failed.

Think about that 15 or 20 minutes a day, adding up to over an hour per week, per employee, doing routine cleanup.

If you see a departure from the intended work sequence, you want to understand why it happened. What compelled the team member to do something else?

Likely there was something about what had to be done that was not completely understood. Or, in the case of many companies, the supervisor, for his own reasons, directed some other work content or sequence.

That is actually OK when the circumstances demand it, but the moment the specified process is overridden, the person who did the override now OWNS getting the normal pattern restored. What doesn’t work is making an ad-hoc decision, and not acknowledging that this was an exception.

Once you are actively seeking to understand the reasons behind departure from your specification, and actively dealing with the causes of those departures, then, and only then, are you standardizing. Until that point, you are making lists of what you would like people to do.

This is the “Act” in Plan-Do-Check-Act.

Self Discipline or Sustaining

One thing I find interesting is that early stuff out of Toyota talks about four S. They didn’t explicitly call out discipline or sustaining. If you think about it, there isn’t any need if you are actively seeking to understand, and addressing, causes in the previous step.

The discipline, then, isn’t about the worker’s discipline. It is about management and leadership discipline to stick with their own standards, and use them as a baseline for their own self-development and learning more about how things really work where the work is done.

That is when the big mirror drops out of the ceiling to let them know who is responsible for how the shop actually runs.

How Critical is Documentation?

Duke has posed an interesting question on the forum:

http://forums.theleanthinker.com/viewtopic.php?f=11&t=35

Actually a couple of questions.

They get to the heart of “When can you say something is actually a process?”

I have my views, but I want to hold back until I hear from some of you.

This could get as good as the 5S discussion.  🙂

Simple and Easy Processes

In the last post I commented on Ron Popeil’s product development approach – to make the product easy to demonstrate drives making it easy to use, which creates more value for the customer.

Let’s take the same thinking back to your internal customers.

What if, rather than just writing a procedure, you had to go and demonstrate it to the people who had to follow it? What if you had to demonstrate it well enough that they saw the benefit of doing it that way, and could demonstrate it back to you to confirm that they understood it? If you broke down the work and organized it to be easy to demonstrate and teach, would it look any different? (Hmmm. TWI Job Instruction actually sounds a lot like this.) Would you still ask “Why didn’t they just follow the procedure?”

Look at the information displays and the controls on your equipment. Do they provide total transparency that things are working? Or do they abstract and obscure reality in some way? Can your internal customer be sure things are going as expected?

Do controls give clear feedback that they are being set correctly? Are sequences of operations readily apparent?

How many “blinking 12:00” situations do you have out there on your shop floor – things that have been put into place, but nobody uses because nobody can really figure it out?

Come back to the design of the product itself. Is the manufacturing and assembly process apparent, obvious, and as simple as you can make it? Would it be designed differently if you had to demonstrate how to fabricate and assemble it?

How about your administrative processes? I recall, many years ago, a “process documentation process” being taught. In the class they were using “baking cookies” as a demonstration example. Yet the instructors, who presumably were experts, actually struggled trying to show how this works. This “process” was far less clear than they had thought it was when they had simply thought through it. “It did not work on TV.”

Look at your computer programs and their user interfaces. What makes sense to a programmer rarely makes sense in actual use. Watch over someone’s shoulder for a while. Could you easily demonstrate this process to someone else?

Ron Popeil cooks real chickens and real ribs in the production of his infomercials. He does not use contrived or carefully limited demonstration examples. As you look at your examples and exercises, how well do they stand up to the real world application? Can you go out to the shop floor and demonstrate your “product” in actual use?

This post is full of questions, not answers. I don’t have the answers. Only you (can) know how well your processes are engineered.

Design your production system (for product or service) as carefully as you would design the product or service itself.

“The Origin” by Roger Slater

I remembered reading this years ago, and thought I had lost my copy. In the midst of my current file purge, I came across my photocopy of a photocopy of a photocopy that was passed around Boeing with the hand written notation “Hey team, this is a good read – enjoy!”

Even better, though, is that the article is included in its entirety in Google Book’s preview of the original book “Integrated Process Management: A Quality Model .”

I am not going to discuss the article much because I don’t want to play spoiler to the punch line.

Comments and discussion, however, are encouraged.

So, without further delay: Click here to read “The Origin

Notes From a Kaizen Event

I was cleaning out some old stuff and came across a folded piece of paper with notes on it. They were from my parting comments to a kaizen event team that had put in a great week with spectacular results. They had started out wanting to improve the delivery of WIP to and from the warehouse.

When we went to the shop floor to see the current situation, what I saw was much more opportunity. It took a little work, especially with the area manager, but by the end of the week they had gone from needing 5 work cells with 6 people each – plus more to meet the holiday seasonal production – to 4 production cells with 5 people each, that could comfortably meet the rush. Not bad for a week’s work.

That’s the background.

When I look at old notes like this, I am always comparing what I knew then with what I know now. Now and than I turn up something that gives a hint that I knew what I was doing.

These comments were as much for the rest of the audience as they were for the team members themselves. After all, they knew what they did, and were fully aware of what they had to do next. But the other teams, and their collective bosses, needed to hear it as well.

  • Wow – great team. You caught flow fever early in the week and ran with it. You make me look like I knew what I was doing – thank you.
  • You connected the operations into a smooth flow.
  • Now you can begin the process of kaizen. Stick with it, stay on the shop floor, and work to stabilize the work. Many problems will come up. Help the work teams learn how to see them and solve them.
  • If you can save, and stabilize, a quarter of a second every day, in three months you can get another 20% of productivity. Think about that – and do the math for yourself.

What made this work?

First and foremost, we had the operational manager there, fully participating. He was skeptical at first, but once I sat down with him and went through his production requirements, step by step, he began to see things in terms of takt times and production leveling rather than just quantities to push out the door. That was a big shift.

The other big thing was having  the team work off line for a few hours to construct a mock-up of a “typical” work cell. Then, without worrying a bit about the takt time, work to minimize the cycle time of one person going through the complete cycle. They learned for themselves that to save time you must study motion. We went through three or four cycles of granularity – every time they thought they had “the” solution, we introduced another tool to see the next level of extra motion. Through this exercise, they gained confidence that it was entirely possible to make a dramatic improvement in the “optimal layout” that they already had.

After that, it was a matter of getting to work. They watched the actual operators, and now could see the excess motions that were being driven by the way the work was arranged. They started making little adjustments – always being respectful of the workers. “We’d like to try something different here, just to see if it works better for you. May we just try something?”

That “May we try this?” attitude introduced something into the dynamic that doesn’t show up often enough – humility. Rather than these managers saying “We’ve got a better way, do it like this.” they were saying “We really don’t know if this will work or not,” and asking not only permission to try, but for input on whether it worked, or how it could work if it wasn’t quite there.

A lot of changes got implemented, but there was no arguing or friction because everything was just an experiment to see if it would work or not.

In the end, I saw something I had never seen before – the manager put in a budget request for a reduction, because he knew he could  get it done with less, or at least figuring out how was within his reach.

That scrap of paper reminded me of a pretty good week.

Audits vs. Leader Standard Work

5S audits, standard work audits, and for that matter ISO-900x audits, are a frequent source of questions in various online discussion forums. At the same time, the topic of “leader standard work” comes up frequently, as it did in a recent question / comment on “Walking the Gemba.”

I think the topic is worth exploring a bit.

Let’s start with audits.

Typically the purpose of an audit is to check compliance with a standard. The auditor has a checklist of some kind that defines various levels of compliance. He evaluates the current situation against the checklist, and produces a score, a report of discrepancies, a pass/fail evaluation of some kind.

So, for example, a typical 5S audit would assign various criteria in each of the 5 ‘S’ words, and assign a 1-5 scale against each of them. Periodically, the person responsible for 5S will come into the work area, do an audit, and post the score. Often there is a campaign to “get to level 3” or something.

Although there are fewer boilerplate checklists out there, “standard work audits” tend to be pretty similar, at least the ones I have seen.

Further up the scale is something like an ISO 900x audit, or an “Class-A MRP II” audit or a corporate “lean assessment.” These are often done by outside agencies to certify the organization. There is a lot of work up front to pass the audit, a plaque goes on the wall, and everybody is happy.

So what’s the problem? (this is turning into one of my favorite questions)

The key is in the difference between a “check” and a “countermeasure.”

A countermeasure is a change or adjustment to the system itself so that the root cause of a problem, or at least its effect, is eliminated.

Audits, on the other hand, actually change nothing about the underlying system. All they do is assess the current state against some (presumed) standard.

Yet so many organizations try to use “audits” as a means to alter the system.

What an audit is good for (if it is planned and performed well – a big assumption) is to CHECK to see if the other things you are doing are working. But, by itself, it is “management by measurement.” People will do what they must to pass an audit (if it even matters that much to them), then go back to what they were doing before.

Leader Standard Work operates at a much lower level of granularity, and looks for different things. Think of the analogy in a previous post about cost accounting:

When dieting, standard cost accounting would advise you to weigh yourself once a week to see if you’re losing weight. Lean accounting would measure your calorie intake and your exercise and then attempt to adjust them until you achieve the desired outcome.

So, to paraphrase, audits are weighing yourself once a week (or once a quarter!) to see if you are losing weight. Leader standard work, on the other hand, is a process to continuously verify that the calorie intake is as specified, and the exercise is as specified, while those things are being done.

That, in turn, implies that there is a daily plan for calorie intake, and a daily plan for exercise. Without those specifications, there is nothing to check.

Leader standard work defines what the leader will check, when it will be checked, and how it will be checked. It also defines how the leader will respond if there is a problem.

He is looking for solid evidence of control.

Are things going as planned?

Is anything disrupting the work cycles or flow of material?

Are quality checks being made as specified?

And, in my opinion, the most important: Are problems being handled correctly, or worked around?

This is important because a culture of working around problems is one in which problems are routinely hidden, often without malice and with the best of intentions. But hidden problems remain, come up again tomorrow, and become part of the routine, adding a little waste, a little friction, making the system a little worse every day.

The typical effort to “pass an audit” reinforces this – it actually hides problems, and the auditor’s job is to ferret them out. This is the exact opposite of the kind of problem transparency we need.

It is human nature to work around problems, and it is the default behavior, everywhere. It takes constant leader vigilance, coaching, response to prevent it.

Is This a Problem – Part 2

Last week I posted a story of a failed freezer, ruined food, and a customer support experience that could be summed up as “That’s how we do it.” I invited comments and asked:

“Is this a problem?”

And when I say “problem” I mean, is this a “problem” from the standpoint of the company’s internal process?

There are some interesting comments, some about the internal culture of the company, others about the support process itself.

But I promised to offer my thoughts, so here they are.

The key question is “What did they intend to happen?” While we can speculate, unless we have the process documentation or are otherwise privy to that internal information, we really don’t know what they intended in this case.

Let’s assume, for the sake of argument, that Frank’s experience was exactly as the company intended it to be. Then, from the point of view of their internal process, there is no problem.

“Wait a minute!” I can hear, “Nobody wants  a customer to never buy the product again.”

And here is my point. We don’t know. This company may be perfectly willing to accept that consequence, i.e. “fire the customer” to preserve their warranty cost structure. They certainly would not be the first. Whether that is good business or not is a totally separate issue. The question is “Did they produce this result on purpose, as a logical, foreseeable outcome of the process as they designed it?.” If the answer is “Yes, they did” (and only they can know), then there is no problem. It might be bad business, but the process is working just fine. (I acknowledge that “bad business practices” can result in unintended results – like bankruptcy. But my point is the results are the outcome of a process, and the process is the result of a decision, even if that decision was to “not care.”)

The key point here is that only after there is clarity of what should happen, can the process itself even be addressed. Until the intended result is clear, then there is no way to see if the process works or not.

Was there a problem here? I don’t know. But this is what I would like people to take away from this little story.

Whenever something in your company seems “not right” ask this really powerful clarifying question:

“Did (or would) we do this on purpose?
If the answer is anything other than an unqualified yes then it is likely you have a problem.

Here is a tougher position: If something was unpleasant for your customer, and you don’t intend to fix it, then embrace the truth that you did do it on purpose. Take responsibility for your decisions, look in the mirror, and say “We meant to do it exactly that way, and will do it the same way next time.” If you can’t stomach that, then go back the the first question.

Here is an extra credit question for this little case study in customer support.
What, exactly, did the customer want here?