Respect, Standards and Jidoka

Many years ago I wrote an article for SME called The Essence of Jidoka. In that article I described a four step process designed to improve productivity and drive continuous improvement. Since then these four steps have been picked up and incorporated into the training materials of many consultants, used to write the Wikipedia article on jidoka (which I most assuredly did not author), and even found their way into some academic papers. Sometimes with attribution back to my article, may times without.

In that article, “jidoka” was described as a four step process:

  1. Detect a problem.
  2. Stop.
  3. Fix or correct the problem.
  4. Find the root cause and implement a permanent countermeasure.

But I would like to take a hard look at the first step: Detect the problem. This is where, I believe, most organizations actually fall down. And in doing so, they also fall down on respect for people.

The key question is: “What do you consider a problem?”

Most organizations do not see a problem until the symptoms are bad enough that they are compelled to do something about it. This means people have been struggling with issues for some time already. The machine isn’t reliably producing good parts. Or someone is having to rework material. Or the supplies cabinet is always short, and the nurses have to launch a safari to find what they need.

Contrast this with a company like Toyota. Every Toyota-trained leader I have ever dealt with is very consistent. A problem is any deviation from the standard. More importantly, a deviation from the standard (1) forces people to improvise and (2) is an opportunity to learn.

This definition, of course, leads to a question: “What is a standard?”

Probably the best explanation to date is in the research done by Steven Spear at Harvard. His work was summarized in the landmark article Decoding the DNA of the Toyota Production System.

Spear’s research concluded there were four tacit rules for how activities, information connections, flow paths, and improvements were designed and executed in Toyota operations. Each of those rules describes:

Any deviation from the standard triggers some kind of alert that gets someone’s attention. And whose attention is explicitly defined – That is a standard as well.

As I look at a work area, I often see a lot of 5S type of activity. Things and their intended locations are marked and labeled. These are standards. They establish what should be where. But the question to ask is “What happens if something is out of place?”

That is a deviation from the standard. It is a problem.

Stop

Fix or Correct (put it back – restore the standard condition)

Investigate the root cause

“What’s going on with the air wrench today?”

“Actually it is an extra one.”

“Really? Where did it come from?”

“I borrowed it from the Team Member in work zone 3.”

“Ah, OK. Why did you need his?”

“The regular one isn’t working.”

“Hey – thanks for letting me know. I’ll get it to maintenance.”

“Thanks”

“Did you tell anyone about the problem before now?”

“No, I just borrowed the wrench. I just needed to get this job done, then forgot. It’s no big deal, it’s easier to just borrow Scott’s wrench.”

And in that exchange, what have you discovered about your daily management system by simply being curious about a trivial deviation from a 5S standard?

Is this the Team Member’s fault?

Probably not. What is your standard? What is he supposed to do if the wrench stops working? Is there an escalation process and a response for this kind of small stoppage? Or are your Team Members just expected to find a way to work through the issue? Which of those responses is more respectful of the Team Member who spends her time trying to create value for you?

Often times there is no standard.

But without a standard you have no way to tell if there is a problem (other than a feeling that something isn’t right). And if you are sure there is a problem, without a standard you can’t really define what “fixed” is.

So start with defining the standard. First, go back to Decoding the DNA of the Toyota Production System. You can get an idea of the kinds of things you should standardize.

As you think of standards, consider a standard for your standard:

  • Express it from the viewpoint of the process customer.
  • Define it in a way that can be verified as “met” or “not met.” No gray zones. You can quantify the magnitude of a problem, but not whether you have one.
  • There is a visual or other control tells the appropriate person, right away, if there is a deviation from your standard?
  • Is there a standard that triggers a response to clear the problem?

5S is nothing more than the first step of setting standards. Many people say to start there, but don’t say why. The point is to practice setting standards and holding them. Taiichi Ohno is quoted as saying:

“If there is no standard, there can be no kaizen.”

Any deviation from the standard is a problem.

Your choice, as a leader, is how to handle that problem.

Daily Management for Improvement

I’m digging through old archives again, and came across this graphic I put together around 2006 or so. It depicts more detailed version of “Organize, Standardize, Stabilize, Optimize” showing the continuous comparison between “what should be happening” and “what is actually happening.” It is the gap between these two that drives improvement forward.

Like the pocket card in the last post, this is built on a foundation established by the work of Steven Spear, especially his PhD dissertation that is summarized in Decoding the DNA of the Toyota Production System. By the way, if you are in the business of continuous improvement, reading (and understanding) this breakthrough work is critical for you.

Other than generally sharing this, my other reason for putting this up is that in the Toyota Kata community there has been discussion for about a decade about whether or not the right hand loop – pushing for stability – is an appropriate use of the Improvement Kata.

I think that is an unfortunate result of some very early conversations about the difference between “troubleshooting” and “improving” a process. We get into semantic arguments about “problem solving” as somehow different from “root cause analysis” and how the Improvement Kata is somehow distinct, again, from those activities.

This makes no sense to me for a couple of reasons.

Scientific Thinking is the Foundation

Toyota Kata is not a problem solving tool. It is a teaching method for teaching scientific thinking, and it is a teaching method for learning to teach scientific thinking. In the books and most literature, it uses organizational processes as working examples for the “starter kata,” but exactly the same thinking structure works for such diverse things as working through quality issues, developing entirely new products and processes, working through leadership and people issues. The underlying sub-structures may change, but the basic steps are the same.

When I encounter an organization that already has a “standard problem solving approach” I do not attempt to tell them they are wrong or confuse them by introducing a different structure. Rather, I adapt the Improvement and Coaching Kata to align with their existing jargon and language, and help them learn to go deeper and more thoroughly into their existing process.

Stability is a Target Condition

I see a lot of pushback about working to “return a process to standard.” In reality, that is the bulk of the activity in day-to-day improvement. The whole point of having a standard in the first place is to be able to see when the actual process or result is somehow different.

Think about it: If there isn’t an active means of comparing “actual” vs. “standard” what is the point of having a standard in the first place?

Think of the standard as a target condtion.

What obstacles are preventing you from [operating to that standard]? You can guess, but the best way is to diligently try to operate to the target condition and see what gets in your way. That might not happen immediately. Maybe some time will go by, then BAM! You get a surprise.

This is good. You have learned. Something you didn’t expect has interfered with getting things done the way you wanted to. Time to dig in and learn what happened.

Maybe there was some condition that you could have detected earlier and gotten out in front of. Who knows?

This is all part of the continuum of Troubleshooting by Defining Standards.

You Cannot Meet a Challenge Without Working on Stability

As you are working to reach new level of performance – working toward a new challenge – there will be a point when the process works sometimes, so you know it is possible. But it doesn’t work every time because there are still intermittent obstacles that get in the way.

Nevertheless, you have to work diligently to see problems as they occur, respond to them, dig into causes (root cause analysis anyone?) and systematically protect your process from those issues.

The only real difference between covering this territory for the first time vs. trying to recover a previously stable process is that in the later case you can ask “What has changed?”

But, in the end, in both cases – stabilizing a new process vs. re-stabilizing an old one – you are dealing with conditions that are changing from one run to the next. That is why it works sometimes and not others. You don’t know what is changing. You are trying to figure it out by experimenting and learning.

What About Root Cause Analysis?

My challenge is still a stable process.

My current condition is my level of understanding of how the process works today, and the exact mechanism that results in a defect. Even defects are produced by a process – just not the process we want.

That understanding will be incomplete by definition – because if we truly understood what was going on we wouldn’t have the problem. So… what do I know (and can prove with evidence) and what do I not know.

What do I suspect? What evidence do I need to gather to rule out this possible cause, or keep it in play? Next experiment. What do I expect to learn?

I’ll write a more detailed post about this at some point. I think it is a topic worth digging into. Suffice it to say that I have absolutely used the Improvement Kata structure to coach people through finding the root cause of wicked quality problems.

It really helped that they were able to see the same underlying pattern that I had already been teaching them. It made things simpler.

Don’t Complicate a Simple Concept

It’s all “solving problems” (the term “problem solving” apparently has some specific form it needs to take for some people).

The underlying structure for all of it is scientific thinking. Some say it’s PDCA / PDSA. Same thing.

Splitting semantic hairs and saying “this is different” makes simple things complicated. Yes, there are advanced tools that you use when things get tough. But… addition and subtraction; basic algebra; advanced polynomials; basic differential calculus; advanced multivariate calculus – IT IS ALL MATH. You apply the math you must to model and solve the problem at hand.

DON’T apply more math than you need just because you can. That serves no purpose except, perhaps, to prove how smart you are… to nobody in particular.

Solving problems is the same. There are some cases where I need to develop a designed experiment to better understand the current condition – the interactions between variables. There are cases where other statistical tools are needed. Use them when you must, but not just because you can.

Use the simplest method that works.

It will feel worse because it’s getting better.

image

The line is starting to flow, or at least there is more time flowing than not flowing. The places where it isn’t flowing well are now much more evident.

Things are speeding up. That is placing more stress on the engineering and materials supply processes where, before, they were shielded by a rough start-up that was always behind schedule.

They are catching up on the backlog, closing in on “on schedule shipment.”

“John” forgot to send a batch of parts to an outside processor. Before that would have been no big deal, it would be a day or so before those things were actually needed. But this time it briefly stopped the line and forced a work-around.

When everything was a work-around, nobody noticed. This time it got on the radar. It feels worse because the system is sensitive to smaller problems now, and there are plenty of those.

It isn’t “John’s” fault. He is flooded with a constant flow of things he needs to react to. There isn’t a structure for him to work within. That is the next opportunity.

Thus, it is critically important to remember a Toyota mantra:

‘No problem’ is a big problem.

If problems are not coming up, then your system is hiding them, plain and simple. You have stopped learning, stopped improving, stopped growing.

It is an easy groove to get into because we get all kinds of feel-good brain chemicals when things are going smoothly. We want more of those, less of the ones that call us to action.

But it is those “call to action” things that drive us to get better.

Team Member Saves

image

Now and then one of your team members makes a great save. They catch something that could have caused a defect, an accident, or done harm in some way.

Often we celebrate these saves, sometimes informally, sometimes formally. And that is well and appropriate.

But let’s make sure we are celebrating for the right reasons.

The save isn’t what should be celebrated.

Rather, the celebration should be a big THANK YOU for finding a gap in your process.

Somehow the process is capable of producing a defect, resulting in an accident, or doing harm. Your team member noticed that.

We usually just celebrate correcting the immediate problem.

But What is preventing exactly the same thing from happening tomorrow?*

image

That front-line customer-facing team member is your last line of defense.

They only get an opportunity to make a “save” when every other point in the process has failed to detect the  problem.

Given enough “shots” at this front line team-member, sooner or later, one is going to get through.

What happens then? Is the inverse logic applied? “You should have caught that.”

Perhaps, but where in the process was the problem actually created?

Somewhere, long before this diving catch, there is an instant when the process went from operating safely and defect free to creating an opportunity, an opening, for a problem to pass undetected.

Where and when was that moment?

Or is that how the process normally operates, and we are just lucky most of the time?

Dig in, think about it.

And thank that team member for saving you, but don’t count on it every time.

———-

*Thanks to Craig for this great way to sum up the question.

Prediction Doesn’t Equal Understanding

Lunar Eclipse over Everett, WA. Photo by Mark Rosenthal, © 2015Sometimes people fall into a trap of believing they understand a process if they can successfully predict it’s outcome. We see this in meetings. A problem or performance gap will be discussed, and an action item will be assigned to implement a solution.
Tonight those of us in the western USA saw the moon rise in partial eclipse.

We knew this would happen because our understanding of orbital mechanics allows us to predict these events… right?

Well, sort of. Except we have been predicting astronomical events like this for thousands of years, long before Newton, or even Copernicus.

The photo below is of a sophisticated computer that predicted lunar eclipses, solar eclipses, and other astronomical events in 1600BC (and earlier). Click through the photo for an explanation of how Stonehenge works:

Photo of Stonehenge
Creative Commons flickr user garethwiscombe

Stonehenge represented a powerful descriptive theory. That is, a sufficient level of understanding to describe the phenomena the builders were observing. But they didn’t know why those phenomena occurred.

Let’s go to our understanding of processes.

The ability to predict the level of quality fallout does not indicate understanding of why it occurs. All it tells you is that you have made enough observations that you can conclude the process is stable, and will likely keep operating that way unless something materially changes. That is all statistical process control tells you.

Likewise, the ability to predict how long something takes does not indicate understanding of why. Obviously I could continue on this theme.

A lot of management processes, though, are quite content with the ability to predict. We create workforce plans based on past experience, without ever challenging the baseline. We create financial models and develop “required” levels of inventory based on past experience. And all of these models are useful for their intended purpose: Creating estimates of the future based on the past.

But they are inadequate for improvement or problem solving.

Let’s say your car has traditionally gotten 26 miles-per-gallon of fuel. That’s not bad. (For my non-US readers, that’s about 9 liters / 100 km.) You can use that information to predict how far a tank of fuel will get you, even if you have no idea how the car works.

If your tank holds 15 gallons of fuel, you’ll be looking to fill after driving about 300 miles.

But what if you need to get 30 miles-per-gallon?

Or what if all of a sudden you are only getting 20 miles-per-gallon?

If you are measuring, you will know the gap you need to close. In one case you will need to improve the operation of the vehicle in some way. In the other case, you will need to determine what has changed and restore the operation to the prior conditions.

In both of those cases, if you don’t know how the car operated to deliver 26 miles-per-gallon, it is going to be pretty tough. (It is a lot harder to figure out how something is supposed to work if it is broken before you start troubleshooting it.)

Here’s an even more frustrating scenario: On the last tank of fuel, you measured 30 miles per gallon, but have no idea why things improved! This kind of thing actually happens all of the time. We have a record month or quarter, it is clearly beyond random fluctuation, but we don’t know what happened.

The Message for Management:

If you are managing to KPIs only, and can’t explain the process mechanics behind the measurements you are getting, you are operating in the same neolithic process used by the builders of Stonehenge. No matter how thoroughly they understood what would happen, they did not understand why.

If your shipments are late, if your design process takes too long, if your quality or customer service is marginal, if the product doesn’t meet customer’s expectations, and you can’t explain the mechanisms that are causing these things (or the mechanisms of a process that operates reliably and acceptably) then you aren’t managing, you are simply directing people to make the eclipse happen on a different day.

“Seek first to understand.”

Dig in, go see for yourself. Let yourself be surprised by just how hard it is to get stuff done.

 

 

Toyota Kata, Kaizen Events and A3

I’ve been asked to explain the relationship between “Toyota Kata” and Kaizen Events, and I am guessing that the person asking the question isn’t the only one who has the question, so I thought I’d take a crack at it here.

To answer this question, I need to define what I mean when I say “kaizen event.”

Kaizen Events

In a typical western company, a kaizen event is geared toward implementing lean tools. There are exceptions, but I think they are different enough to warrant addressing them separately. (If you don’t read this, I changed my mind as I was writing it.)

At this point, I am going to borrow from an earlier post How Does Kaizen Differ From a Kaizen Event:

The kaizen event leader is usually a specialist whose job is to plan and lead these things, identifies an improvement opportunity. He might be tasked by shop floor management to tackle a chronic or painful problem, or might be executing the “lean plan” that calls for a series of implementation events.

It is his job to plan and execute the event and to bring the expertise of “how to make improvements” to the work force and their leaders.

Here’s the Problem

The full-time kaizen event leaders typically get really good at seeing improvement opportunities, organizing groups for improvement, and quickly getting things done. They get good at it because they do it all of the time.

The area supervisors might be involved in a kaizen event in their area a few times a year if that. Some companies target having each employee in one kaizen event a year.

That’s 40 hours of improvement. All at once. The question is: What do they do (and learn) the other 1900 hours that year?

What do they do when something unexpected happens that disrupts the flow of work? Usually kaizen events don’t deal with how to manage on a day-to-day basis other than leaving an expectation for “standard work” in their wake.

But “standard work” is how you want the work to go when there aren’t any problems. When (not if) there are problems, what’s supposed to happen?

This is why many shop floor leaders think “kaizen” is disconnected from reality. Reality is that parts are late, machines break, things don’t fit, Sally calls in sick, and the assembler has to tap out threads now and then. In the hospital, the meds are late, supply drawers have run out, and there is a safari mounted to find linens.

These things are in the way of running to the standard work. They are obstacles that weren’t discovered (or were glossed over as “resistance to change”) during the workshop.

The supervisor has to get the job done, has to get the stuff out the door, has to make sure the patients’ rooms are turned over, whatever the work is. And nobody is carving out time, or providing technical and organizational support (coaching) to build his skills at using these problems as opportunities for developing his improvement skills, and smoothing out the work.

OK – that is my paradigm for kaizen events. And even if they work really well, the only people who actually get good at breaking down problems, running PDCA cycles, etc. are the professional facilitators or workshop leaders. Many of these practitioners become the “go-to” people for just about everything, and improvement becomes something that management delegates.

What are they good for? Obviously it isn’t all negative, because we keep doing them.

A kaizen event is a good mechanism for bringing together a cross functional team to take on a difficult problem. When “improvement” is regarded as an exception rather than “part of the daily work,” sometimes we have to stake out a week simply to get calendars aligned and make the right people available at the same time.

BUT… consider if you would an organization that put in a formal daily structure to address these things, and talked about what was (or was not) getting done on a daily basis with the boss.

No, it wasn’t “Toyota Kata” like it is described in the book, but if that book had been available at the time, it would have been. But they had a mechanism that drove learning, and shifted their conversations into the language of learning and problem solving, and that is the objective of ALL of this.

Instead of forcing themselves to carve out a week or two a year, they instead focused on making improvement and problem-solving a daily habit. And because it is a daily habit, it is now (as of my last contact with them a couple of months ago), deeply embedded into “the way we do things” and I doubt they’re that conscious of it anymore.

This organization still ran “event” like activities, especially in new product introduction.

In another company, a dedicated team ran the layout and machinery concepts of a new product line through countless PDCA cycles by using mockups. These type of events have been kind of branded “3P” but because changes and experiments can be run very rapidly, the improvement kata just naturally flows with it.

Kaizen Events as Toyota Kata Kickstarts

If you take a deeper look into the structure of a kaizen event, they generally follow the improvement kata. The team gets a goal (the challenge), they spend a day or so grasping the current condition – process mapping, taking cycle times, etc; they develop some kind of target end state, often called a vision, sometimes called the target and mapped on a “target sheet.” Then they start applying “ideas” to get to the goal.

At the end of the week, they report-out on what they have accomplished, and what they have left to do.

If we were to take that fundamental structure, and be more rigorous about application of Toyota Kata, and engage the area’s leader as the “learner” who is ensuring all of the “ideas” are structured as experiments, and applied the coaching kata on top of it all… we would have a pretty decent way to kickstart Toyota Kata into an area of the organization.

Now, on Monday morning, it isn’t what is left to do. It is the next target condition or the next obstacle or the next PDCA cycle.

Toyota Kata

If we are applying Toyota Kata the correct way, we are building the improvement skills of line leadership, and hopefully they are making a shift and taking on improvement is a core part of their daily job, versus something they ensure others are doing.

One thing to keep in mind: The improvement kata is a practice routine for developing a pattern of thinking. It is not intended to be a new “improvement technique,” because it uses the same improvement techniques we have been using for decades.

The coaching kata is a practice routine to learn how to verify the line-of-reasoning of someone working on improvements, and keep them on a thinking pattern that works.

By practicing these things on a daily basis, these thought patterns can become habits and the idea of needing a special event with a professional facilitator becomes redundant. We need the special event and professional facilitator today because a lot of very competent people don’t know how to do it. When everybody does it habitually, you end up hearing regular meetings being conducted with this language.

We can be more clear about what skills we are trying to develop, and more easily assess whether we are following sound thinking to arrive at a solution. (Luck is another way that can look the same unless the line of reasoning is explained.)

What About A3?

When used as originally intended, the A3 is also a mechanism for coaching someone through the improvement pattern. There are likely variations from the formal improvement kata the way that Mike Rother defines it.

However, if you check out John Shook’s book Managing to Learn, you will see the coaching process as primary in how the A3 is used. Managing to Learn doesn’t describe a practice routine for beginners. Rather, it showcases a mature organization practicing what they use the Improvement Kata and the Coaching Kata to learn how to do.

The A3 itself is just a portable version of an improvement board. It facilitates a sit-down conversation across a table for a problem that is perhaps slightly more complex.

An added afterthought – the A3 is a sophisticated tool. It is powerful, flexible, but requires a skilled coach to bring out the best from it. It can function as a solo thing, but that misses the entire point.

For a coach that is just learning, who is coaching an improver who is just learning, all of the flexibility means the coach must spend extra time creating structure and imposing it. I’ve seen attempts at that – creating standard A3 “templates” and handing them out as if filling out the blocks will cause the process to execute.

The improvement kata is a routine for beginners to practice.

The coaching kata is a routine for beginners to practice.

Although you might want to end up flying one of these (notice this aircraft is a flight trainer by the way):

T-38

They usually start you off in something like this:

image of Cessna 172

The high-performance aircraft requires a much higher level of instructor skill to teach an experienced pilot to fly it.

And finally, though others may differ, I have not seen much good come from throwing them up on a big screen and using them as a briefing format. That is still “seeking approval” behavior vs. “being coaching on the thinking process.” As I said, your mileage may vary here. It really depends on the intent of the boss – is he there to develop people, or there to grant approval or pick apart proposals?

So How Do They All Relate?

The improvement kata is (or absolutely should be) the underlying structure of any improvement activity, be it daily improvement, a staff meeting discussing changes in policy, a conversation about desired outcomes for customers (or patients!).

The open “think out loud” conversation flushes out the thinking behind the proposal, the action item, the adjustment to the process. It slows people down a bit so they aren’t jumping to a solution before being able to articulate the problem.

Using the improvement kata on a daily basis, across the gamut of conversations about problems, changes, adjustments and improvements strengthens the analytical thinking skills of a much wider swath of the organization than participating in one or two kaizen events a year. There is also no possible way to successfully just “attend” an improvement activity if you are the learner being coached.

Navigating the Learning Hairball

Credit: A lot of stuff comes across my screen, sometimes more than once. I have seen this illustration several times, but don’t remember where it originally came from. If you created it, PLEASE comment so I can give appropriate credit.

Improvement is messy. Science is messy. Research and Development is messy. These are all cases where we want an outcome, are pretty sure what that outcome looks like, but there isn’t really a clear path to get there.

This illustration has illustrates two very different mindsets.

On the left is how many people believe the improvement / organizational development / learning process works. We set out a phased project plan to transform the organization. We carry out a set of pre-defined steps, and when they are completed, we are at the goal.

Sadly our education process is largely constructed on this model. Take the classes, pass the tests, the student is educated.

This thinking is appropriate when the outcome is something we have done before, like constructing a house. Even if this house is a bit different, the builders have rich experience in carrying out all of the constituent process steps. Further upstream, the designer carefully followed building and construction codes. In those cases, we are applying a rich body of experience (or the documented experiences of others) to reach the end goal.

These tasks can be scheduled and sequenced in a project plan. The steps are known, the result is known.

 

image

On the right is the hairball of learning and discovery.

We know where we are starting.

We know where we want to end up.

We are reasonably certain we can get from Point A to Point B. But we don’t know precisely which detailed steps or experiments will give us the results we need.

We don’t know for sure that the next result will be a forgone conclusion from the next action step.

Each step gives us more information about the next step.

In the world of continuous improvement, we live in an interesting paradox.

We often believe we are operating in the set-piece model on the left. We see a situation, we apply tools to duplicate a solution we have seen work in a similar situation before.

An interesting thing happens at this point. The Real World intervenes, and we discover that the situation was actually more like the right side. We thought we knew the right answers. We might have even been mostly right. But at the detail level, things don’t work quite as we predicted.

Now… if the system has been deliberately set up to flag those anomalies, and we are recording them and being curious to discover what we didn’t understand then we are in learning mode.

But all too often the experts who guided the original installation have moved on, leaving the people executing the process behind. The assumption was “It works, we can go to the next problem.”

The people in the process did what they were told, or guided, to do. We might have even asked for their input on the details. But that process rarely leaves them with additional skills they need to deal with anomalies in ways that make the process more robust.

So they do what they must to get things done. Mostly that means adding some inventory here, some additional checks or process steps there. Over time, the process erodes back to something close to its original state.

Why? Because we thought we knew everything… but were wrong. And didn’t notice.

This model applies to any effort to shift how an organization performs and interacts. We outrun our headlights and take on the Big Change because that company “over there” does it, and we just copy the end result.

What we missed was doing the work.

More about this later.

Active Control

Imagine you are driving an automobile with a high-performance suspension. You are on a perfectly straight stretch of road, with smooth pavement. Get yourself up to, say, 65 miles per hour (100 km/h). Got it pointed down the middle of the road?

OK, close your eyes, let go of the steering wheel and wait. (Actually closing your eyes is optional.)

Can you predict what will happen, more likely sooner than later?

It doesn’t matter how “stable” your car is.

There are small, random things that are eventually going to cause your car to drift away from the centerline and off the road, into the ditch on one side, or over the cliff on the other. (Didn’t I mention those?)

I often see people set up a well performing process and treat it the same way – as though it will continue to work the same way forever, without any intervention.

But your process is going to encounter random chatter, and when it does, what typically happens?

In most cases, the team members can find a way to work around the issue, and likely continue to get things done, though they will have added a bit of friction, requiring a bit more effort, to do so. They will add a redundant check to make sure no mistake got made. They will add some inventory under the work bench, in case something runs out. They will carry the product over to the other machine because the one they are supposed to use isn’t working as it should be.

They will clean up the spilled coolant, catch the leaking oil.

They will head up-line to borrow a team member’s grease bucket.

They’ll tap out paint clogged or unthreaded holes, cut wires that are delivered too long to length, even drill new holes to mount the part that doesn’t fit.

In the office, they get one more signature, send an email to back-up the “unreliable” ERP messages, and make screen prints so they can enter the data into another system.

“Waste is often disguised as useful work.”

All of this easily goes unnoticed, and eventually (maybe) the process becomes cumbersome enough that someone decides to address it with an improvement activity. And the cycle starts again.

How do we stop the cycle?

The point of intervention is in the last paragraph… “All of this goes unnoticed.”

It isn’t a matter of standing and watching for problems. Sakichi Toyoda figured that out almost 100 years ago. It is about designing your process to detect anomalies in either execution (how it is done, how long it takes) or results immediately, signal, and trigger some kind of response.

Here are some fundamental questions to ask yourself:

Before the process even begins, does the team member have everything he needs to succeed? How does he know? I’m talking about parts, information, tools, air pressure, assistance… whatever you know is needed to get the job done.

If the team member doesn’t have everything needed exactly what do you want him to do?

Is the team member carrying out the process in a way that gets the desired result? How does she know? Is there a sequence of steps that you know will give her the result you want? What alerts her if one of them is skipped?

If the team member, for whatever reason, isn’t able to carry out those steps in sequence, exactly what do you want her to do? Go find a grease bucket? Or let you know?

How long do you want to allow your team member to try to fix something or make it work before letting you know there is a problem? Related to this – how far behind can you allow him to get before he can’t catch up, even with help?

Once the team member has completed the process, how does he know the result is what was expected? If the team member doesn’t have a way to positively verify a good outcome, who does detect the problem, when, where and how? It might be your customer!

An Active Control System

Even if you have all of those checks in place, however, you still need to answer a few more questions starting with “Once the team member detects a problem, what do you what exactly do you want them to do?”

I alluded a little to this above, but let’s go a bit deeper.andon-pull

On a production line, a typical way for a team member to signal a problem is with some kind of andon. This might, for example, take the form of a rope along the line that the team member can pull in order to trigger a signal of some kind.

But that is the easy part. Lots of factories have copied the mechanics of Toyota’s andon only to see them fall into disuse following a period of cynicism.

The hard part is what is supposed to happen next?

Now we are back to the original questions because the andon is nothing more than a trigger for another process.

Who is the designated first responder? (Remember, if it is everybody’s problem, it is nobody’s problem.) Does that person know who he is?

What is the standard for the response? What is the first responder supposed to do, and how long does she have to do it?

When we had takt times on the order of dozens of minutes, our standard for the first response making face-to-face contact with the team member who signaled was 30 seconds.

How much intervention can the first responder make before being required to escalate the problem to the next level?

As a minimum

As a minimum, the first responder’s primary goal is to restore the normal pattern of work. This might be as simple as pitching in and helping because something minor tripped up the team member’s timing.

This is active control – a system or process that detects something going outside the established parameters, and applying an adjustment to get it back. Active control requires a process to detect abnormalities, a trigger, and a response that restores things. It is no different than maintaining thickness in a rolling operation – the machine measures the output, and adjusts the pressure accordingly – or an autopilot that keeps an airplane on course.

Without some kind of active control system, your process will erode over time as the team members do the only things they can do in an effort to keep things moving: They can overproduce and build inventory to compensate, they can add extra process steps, they can add just about any of the things we call “waste.”

The only question is what do you want them to do?

What Mode Are You In?

The main purpose of an andon is to signal that some part of the system is no longer in normal operating mode. The immediate response should be to quickly assess the situation, and recover the process to the normal mode.

Many organizations, however, do not make that mental shift. They don’t have a clear sense of whether they are in the normal operating pattern, or in recovery mode.

Without that sense of mode, “recovery” can quickly become the norm, and a culture of working around problems develops. Sometimes we call this a “firefighting culture,” but I find that term regrettable, as it reflects poorly on actual firefighters.

In the andon driven environment, the andon is either on or off. That is, things are either operating as they should be (no andon) or they are not (andon is triggered).

All of this presumes, of course, that you have some idea what your normal operating pattern should be. Go and walk your shop floor or work area. What can you see happening?

Is what you see what you want to be happening? How do you know? What do you compare it against?

Can the people working there tell if they, and their process, are in the normal operating pattern, or in some other mode?

If they are recovering, do they know they are recovering? Are they striving to get things back to the normal operating mode; or are they striving to simply get the job done in spite of the immediate problem? Big, big difference here. This is what makes or breaks your continuous improvement effort.

Once the normal operating mode is restored (assuming you had one), are at least some of these incidents investigated down to root cause, with countermeasures tested by appropriate PDCA cycles and experiments?

What mode are you in right now?

How can you tell?

Visual Key Points

(Apologies for this post being “Password Protected” – I posted it from my smart phone, and obviously need to mistake-proof  something in the interface.) – MR

A key element of TWI Job Instruction is breaking down the job into important steps, key points, and reasons why.

An important step advances the work.
A key point is a critical aspect of the work that would:

  • injure the worker (or anyone else).
  • make or break the job.
  • make the job easier to do (a knack or technique that an experienced operator knows).

If it is worth making a key point over, it is worth putting a visual cue in the workplace.

If the key point is about something that would injure the worker, or make or break the job, you have a rich opportunity for mistake proofing.

In other words, a key point is something you are asking the team member to remember.

Help him out by reminding him or even better, engineering the work so that he doesn’t have to remember.