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?

What Must Be Done To Make It Happen?

The May 2013 edition of the U.S. Airways inflight magazine has a really interesting article in a monthly “Making it Happen” feature called “One Job At A Time.” (Click the link to follow along at home. The article is on page 12 of the magazine, page 14 of the pdf.)

The piece follows a machinist through his shift in their maintenance facility.

What is interesting is what he has to do to get the job done.

I’m not going to detail it all out here, but suffice it to say that his shift starts at 2:30 pm, and between then and 7:00 pm he only spends about an hour and 10 minutes to pull the old bearings and install the new ones – actually doing the job he set out to get done on the airplane.

The rest of the time is spent interacting with the job tracking computer, gathering the required tools, supplies, waiting for the inspector, and making a part because the one in the kit didn’t fit.

This team member is working within the system, and what is described here is so routine that it is a featured article in the inflight magazine.

Now – before you get really critical, you might want to follow one of your primary team members around for a shift and see if your organization does any better.

For example a ward nurse in a local hospital spent exactly 10 minutes over a 4 hour period actually providing care to patients and charting – the things I would call “nursing.”

These are dedicated team members, but the system gets in their way.

The Weird Stuff We Notice

Monday and Tuesday I had lunch in the client’s facility.

I had the same sandwich, prepared by the same worker each day.

Monday he put the mayo directly on the chicken salad, on his left.

Tuesday he put the mayo in the other piece of bread on his right.

Then I smiled at myself wondering why on Earth I even noticed that, all the while conversing about something unrelated.

Note to self: get brain checked and turn down the gain a bit.  🙂

Mike Rother Overview of Toyota Kata

This is a 5 minute edit of the presentation Mike Rother made at the UK Lean summit.

It is a succinct summary of interaction between a coach (leader) and learner (someone working on improving a process).

My thoughts are below the video…

OK – here are some things I have learned with these methods “in the wild.”

Most organizations I have been working with can’t take on 1-3 year challenges and stay the course for that duration. The horizons are too far for them to see what is possible within that kind of time frame and stay the course.

I have been trying 3-4 month time horizons for initial challenges in organizations where everyone is learning the basics at all levels. That gives them an opportunity to practice with a horizon that is less likely to be derailed by a sudden change in direction during that time. Eventually, as they develop capability, they can extend the time horizon and morph these practice challenges into something more formal, linked to the business plan.

Middle managers like to leap onto the coaching questions much too early – before they are capable of actually coaching. The coaching questions are seductive because they are written down and structured.

The PDCA process is much more nuanced, but it must be mastered before attempting to coach. Why? Because the coaching process is application of PDCA toward the learner’s development.

While it is OK to round-robin coaching and actual process improvement, everyone has to work together to reflect and learn.

In addition, those middle managers tend to try to leap into coaching before they have an internally set non-negotiable sense of “True North” – driving toward better and better flow.

When a middle manager is taking on the role of the “learner” there is a great temptation for him to delegate tasks to others, and get reports. This is status quo, and does nothing at all to develop capability.

Like everything else we do in the West, or at least in the USA, we try to get there fast by skipping the basics.

Make no mistake – you don’t “implement Toyota Kata.”

You use it as a structure to build foundational capability and new thinking patterns.

Those patterns are only developed through practice, and deliberate reflection on the management process itself.

I have also seen an organization that is “getting it” pretty quickly. The difference is that they are all overtly in “we are just learning this” mode, and willing to make mistakes and learn from them vs. trying to appear to be competent from the get-go.

Mike Rother has other videos on YouTube as 734Mike.

5S With Purpose

The team was driving toward a consistently executed changeover process as a target condition.

In the last iteration, the process was disrupted by a scrapped first-run part. The initial level cause was an oversize bit in the NC router resulting in an out-of-spec trim and oversize holes.

This occurred in spite of the fact that there are standard tools that are supposed to be in standard locations in the tool holders on the back of the work pallet.

Upon investigation, the team found:

  • The previous part had a programming error calling out the oversize tool from the wrong location.
  • All of the operators were aware of this, and routinely replaced the “standard” tool with the one the program required.
  • After that part was run, the standard condition had not been restored.
  • There was likely a break in continuity between operators here, but that was less clear.
  • The two bits are only 1/8 different, and hard to distinguish from one another across the 10 feet or so of the work pallet.

The team addressed the programming error, but among the thousands of other programs out there, they were reasonably certain that there were other cases where the same situation could be set up.

They wanted to ensure that it was very clear when there were non-standard tools in the standard locations.

Their initial approach was to create a large chart that called out which tools were to be in which holders. Their next experiment was to be to put that chart up in the work area.

 

“What do you expect to happen?”

That turned out to be a very powerful question. After a bit of questioning, they implied that the operator was to verify that the correct tools were in the standard positions before proceeding.

“How does this chart help them do that?”

They can see what the standard is.

“Don’t they all already know what the standard is?”

Yes…..

“So how does this chart help them do that?”

Now, to be clear, the conversation was not quite this scripted, but you are getting the idea. The point was to get them to be specific about what they expected the operator to do, and to be specific about how they expected their countermeasure to help the operator do it.

One team member offered up that maybe they could color-code the standard tools and their holders so it would be easy to check and easy to see if something was off-standard. That way, even IF the situation came up where the operator needed to deviate from the standard, anyone could easily see what was happening.

(I should add that they have already put an escalation process into place that should trap, and correct, these programming errors as they come up as well.)

The tools were color-coded over night, and in place the next day.

Color coded tool holders.

This wasn’t a “5S campaign,” nor is there an audit sheet that tries to measure the “level” of visual control in the work space.

Rather, this is using a visual control to visually control something, and reduce the likelihood of another scrapped part (and therefore, disrupted changeover).

Over the last week, the work cell has been improving. When things are flowing as they are supposed to, changeovers are routinely being done within the expected time.

But there are times when their standard WIP goes low; there are times when someone gets called away; when the flow doesn’t go as planned. When those things happen, they get off their standard.

The next countermeasure is to document, clearly, the normal pattern for who works where, for what inventory is where. Then the next question is “How can anyone verify, at a glance, whether or not the flow is running to the normal pattern?”

More visual controls. Ah.

Now we are seeing the reason behind 5S. It will come in to that work area, step by step, as the necessity to make things more clear arises.

“No Question…Sketch!”

One of the more famous tools taught by Chihiro Nakao of Shingijutsu fame is to direct the learner to observe an operation and “sketch the flows.”

Another Time Ideas article by Anne Murphy Paul, How to Increase Your Powers of Observation, validates Nakao’s instinct.

She makes the distinction between casual observation that we all do, and scientific observation.

[…]scientists train their attention, learning to focus on relevant features and disregard those that are less salient. One of the best ways to do this is through the old-fashioned practice of taking field notes: writing descriptions and drawing pictures of what you see. “When you’re sketching something, you have to choose which marks to make on the page,” says Michael Canfield, a Harvard University entomologist[…]  (bold emphasis added)

The common factor here is that, like scientists, we don’t want to simply watch a process, we want to observe it. We want to predict what we think will happen, and then observe to confirm or refute our predictions.

While casual observers simply sit back and watch what unfolds, scientific observers come up with hypotheses that they can test. What happens if a salesperson invites a potential customer to try out a product for herself? How does the tone of the weekly meeting change when it’s held in a different room?

The next time you are in your work area, rather than simply watching, bring a bad and pencil, and sketch out what is happening.

How does the material actually flow through the process? Where does it pause, stop, get diverted?

How to people flow, move into, and out of, the process?

Where does the information come from?

Does the layout support, or get in the way of, smooth flow?

How about the tools, equipment, machines? Do they help the worker get the job done, or make it awkward?

And finally, what actually happens when there is a problem of some kind? How does the team member indicate this? What is the response?

By sketching, you force your eye to see the details that you might have missed. You force yourself to actually see, and might be surprised when that is different from what you assumed was happening.

Sharpen your eye – learn to observe like a scientist.

No question… sketch!

Make a Rule / Keep a Rule

I was driving home today and saw a construction sign on the sidewalk. It read: “Sidewalk Closed, Use Other Side.” Ahead was a section of the sidewalk which was, indeed, closed off and impassible.

By the time a pedestrian encounters this sign, he is well into the middle of a long block.

The sign is at least implying that the pedestrian should cross the street in the middle of the block to get around the construction. The alternatives are:

  • Ignore the sign, and walk on the street around the torn up sidewalk.
  • Backtrack to a legal crosswalk, and cross the street where it is legal to do so.

This situation is actually fairly common in a lot of companies. There is a rule “Don’t cross the street in the middle of the block.” Then there is an expectation that is incompatible with following the rule.

  • “Be careful, but hurry.”
  • “Stop and fix problems, but don’t lose production.”
  • Stop for quality, but make the numbers.”
  • Get 90 minutes of work done in an hour.

The team member has the same alternatives as above – ignore the expectation, or ignore the rule.

This is a slightly higher level than Hirano’s observation that “the words ‘just for now’ are the origin of all waste.” Here we are putting the team member in an untenable situation because there is no action available that is clearly OK.

Take a look at the rules you have. Take a look at the actual behaviors. Remember that what people actually do is generally what they sincerely believe you expect of them.

If it is impossible to follow a rule, consider why the rule exists.

The words “Do the best you can.” are a warning that you are in this kind of situation.

Smooth is Fast

When you are at the gemba, you are watching the work. We like to say you are “looking for waste” and list seven, or eight, or ten different categories of waste that you are supposed to look for.

I think it is simpler than that.

An ideal workflow is smooth.

The product moves smoothly, without starts and stops, without sudden changes in momentum.

The people move smoothly. Each of their motions engages the product and advances the work in some way.

Machines do not interfere with the smooth movement of product or people.

Information flows the same way. There is nothing in how it is stored, retrieved, or presented that causes people to break their smooth rhythm.

When you watch the work, try to visualize what smooth would look like. Smooth has no wasted motions, no excessive activities.

Anything that doesn’t look smooth is likely the result of an accommodation, an awkward operation, poor information presentation, poor computer screen layout and workflow.

Just another way of looking at it.

Steve Spear on Creative Experimentation

On Monday MIT hosted a webinar with Steven Spear on the topic of “Creative Experimentation.”

A key theme woven throughout Spear’s work is the world today is orders of magnitude more complex than it was even 10 or 15 years ago. Where, in the past, it was feasible for a single person or small group to oversee every aspect of a system, today that simply isn’t possible except in trivial cases. Where, in 1965 it was possible for one person to understand every detail of how an automobile worked, today it is not.

My interpretation goes something like this:

Systems are composed of nodes, each acting on inputs and triggering outputs. In the past, most systems were largely linear. The output of upstream nodes was the input of those immediately downstream. You can see this in the Ford Mustang example that Spear discusses in the webinar.

Today nodes are far more interconnected. Cause and effect is not clear. There are feed-back and feed-forward connections and loop-backs. Interactions between processes impact the results as much as the processes themselves.

Traditional management still tries to manage what is inside the nodes. Performance, and problems, come from the interconnections between nodes more than from within them.

The other key point is that traditional management seeks to first define, then develop a system with the goal of eventually reaching a steady state. Today, though, the steady state simply does not exist.

Product development cycles are quickening. Before one product is stable, the next one is launched. There is no plateau anymore in most industries.

From my notes – “The right answer is not the answer for very long. It changes continuously.”

Therefore, it is vital that organizations be able to handle rapid shifts quickly.

With that, here is the recorded webinar.

(Edit: The original flies have been deleted from the MIT server.)

A couple of things struck me as I participated in this.

Acknowledging that Spear has a bias here (as do I), the fact that Toyota’s inherent structure and management system is set up to deal with the world this way is probably one of the greatest advantages ever created by happenstance.

I say that because I don’t believe Toyota ever set out to design a system to manage complexity. It just emerged from necessity.

We have an advantage of being able to study it and try to grasp how it works, but we won’t be able to replicate it by decomposing its pieces and putting it back together.

Like all complex systems, this one works because of the connections, and those connections are ever changing and adapting. You can’t take a snapshot and say “this is it” any more than you can create a static neural net and say you have a brain.

Local Capability

One thing that emerges as critical is developing a local capability for this creative experimentation.

I think, what Spear calls “creative experimentation” is not that different from what Rother calls the “improvement kata.” Rother brings more structure to the process, but they are describing essentially the same thing.

Why is local capability critical? Processes today are too complex to have a single point of influence. One small team cannot see the entire picture. Neither can that small team go from node to node and fix everything. (This is the model that is used in operations that have dedicated staff improvement specialists, and this is why improvements plateau.)

The only way to respond as quickly as change is happening is to have the response system embedded throughout the network.

How do you develop local capability? That is the crux of the problem in most organizations. I was in an online coaching session on Tuesday discussing a similar problem. But, in reality, you develop the capability the way you develop any skill: practice. And this brings us back to the key point in Kata.

Practice goes no good unless you are striving against an ideal standard. It is, therefore, crucial to have a standardized problem solving approach that people are trying to master.

To be clear, after they have mastered it, they earn a license to push the boundaries a bit. But I am referring to true mastery here, not simple proficiency. My advice is  to focus on establishing the standard. That is difficult enough.

An Example: Decoding Mary – Find the Bright Spots

Spear’s story of “Decoding Mary” where the re-admission rate of patients to a hospital directly correlated with the particular nurse handled their transfer reminded me of Heath & Heath’s stories from Switch. One of the nine levers for change that they cite is “find the bright spots.”

In this case the creative experimentation was the process of trying to figure out exactly what Mary did differently so it could be codified and replicated for a more consistent result independent of who did it.

The key, in both of these cases, is to find success and study it, trying to capture what is different – and capture it in a way that can be easily replicated. That is exactly what happened here.

A lot of organizations do this backwards. They study what (or who) is not performing to determine what is wrong.

Sometimes it is far easier to try to extract the essence what works. Where are your bright spots for superb quality? Does one shift, or one crew, perform better than the others? Do you even know? It took some real digging to reveal that “Mary” was even the correlating factor here.

Continuous Improvement Means Continuous Change

Since “continuous improvement” really means “continuously improving the capability of your people,” now perhaps we have “to do what.” I have said (and still say) that the “what” is problem solving.

What you get for that, though, is a deep capability to deal with accelerating change at an accelerating rate without losing your orientation or balance.

It is the means to allow the pieces of the organization to continue to operate in harmony while everything is changing. That brings us back to another dilemma: What is the ROI on learning to become very, very good? You don’t know what the future is going to throw at you, only that you need the capability to deal with it at an ever quicker pace.

But none of this works unless you make a concerted effort to get good at it.

Here is the original link to the MIT page with the video, and a download link for PDFs of the slides:

http://sdm.mit.edu/news/news_articles/webinar_010912/webinar-spear-complex-operating-systems.html