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

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.

Clearing the Problem / Solving the Problem

As I work with clients to get a “problem solving culture” embedded, one common challenge is the distinction between the short term work-around to remove the obstacle, and the long-term countermeasure that actually improves the process.

I addressed this at a conceptual level in the “Morning Market” post a while ago.

Last week I was working with a client who has begun using the work-around as their key insight into the issue they have to solve.

When the work flow is disrupted, they are careful to capture what they had to do in order to clear the problem and get the item back into the normal production flow.

“We had to wait for parts.”

“We had to rework _____.”

“We had to get on someone else’s login for enough security to do the task.”

“We had to find the ____.”

“We had to replace ___”

This is really valuable information. By appending “Why did…” in front of the statement, they have a fairly well defined starting point for getting to the bottom of the actual issue.

By making the containment action the first “Why?” they get off the containment-as-solution mindset.

It might not work for everyone, but it is working very well for them.

“Please continue.”  Smile

Mike Rother: Time to Retire the Wedge

Note – this post was written pretty much simultaneously with a post on the lean.org forum.

Mike Rother has put up a compelling presentation that highlights a long-standing misunderstanding about the purpose of “standards.”

[slideshare id=9312458&doc=retirethepdcawedge-091711-mr-110918191213-phpapp01]

Some time ago, a (well-meaning) author or consultant constructed a graphic that shows the PDCA wheel rolling up the incline of improvement. There is a wedge labeled “Standards” shoved as a chock block under the wheel to keep it from rolling back. That graphic has been copied many times over the years, and shows up in nearly every presentation about PDCA or standard work.

The implication – at least as interpreted by most – is that a process is changed for the better, a new standard is created, and people are expected to follow the standard to “hold the gains” while they work on rolling the PDCA wheel up to the next level on the ramp.

Slide 6 (taken from the book Toyota Kata) shows the underlying assumptions that are implied by this approach, especially when it doesn’t work.

There are some interesting assumptions embedded in the “wedge thinking.”

The first one is that “the standard can be ‘held’ by the people doing the work.

That, in turn, means that if when things start to deteriorate, the workers and first line leaders are somehow responsible for the “slippage” or “not supporting the changes.”

With this attitude, we hear things like “Our workers aren’t disciplined enough” or “How do I make them follow the standard?” The logical countermeasures are those associated with compliance – audits focused on compliance, and sometimes even escalating punitive actions.

Back in my early days, I had a shop floor team member call us on it quite well: “How can you expect us to hold some kind of standard work if the parts don’t fit?” (or aren’t here, or the tools don’t work, or jigs are misaligned, or the machine isn’t running right, or someone is absent, or we are being told to hurry and just get stuff out the door?)

This is the approach of control. The standard is fixed until we decide to change it.

Taiichi Ohno didn’t teach it this way.

Neither did Deming or Juran. Neither did Goldratt. Nor does Six Sigma, TQM, TPM.

Indeed, if we want creativity to be focused on improvements, we have to look up the incline, not back.

We are putting “standards” on the wrong side of the wheel. Rother’s presentation gets it right – the “standards” are the target – what we are striving to achieve.

The purpose of standards is to compare what we actually do against what we wanted to do so we know when they are different and so we have some idea what stopped us from getting there.

Then we have to swarm the problem, and remove the barrier. Try it again, and learn what stops us the next time.

The old model shows “standards” as a countermeasure to prevent backsliding, when in reality, standards are a test to see if our true countermeasures are working.

I believe this model of “standards” as something for compliance is a cancer that is holding us back in our quest to establish a new level of understanding around what “continuous improvement” really means.

It is time to actively refute the model.

If you own your corporate training materials, find that slide (it is in there somewhere) and change it.

If you see this model in a presentation, challenge it. Ask what should happen if something gets in the way of meeting this “standard.”

“What, exactly do you expect the team member to do?”  That sparks an interesting conversation which reveals quite a bit.

Rapid PDCA with 3P

“3P” is not a Toyota term. The workshop structure was taught by Shingijutsu and is now being propagated by people who learned it while working in their client companies.

The most visible characteristic of 3P, the Production Preparation Process, is the idea of creating quick and dirty mock-ups of the product and the process. These mockups are often constructed of wood, cardboard, PVC pipe – materials at hand.

600x3p-benches

The idea is to be able to quickly and cheaply try out, and experience, a process (or product) so that problems can be surfaced, opportunities for improvement can be seen, and the PDCA cycle can be turned far more rapidly than would otherwise be possible.

The purpose of the mockup is to create a gemba of sorts, where you would not otherwise have one. Now, rather than doing an abstract analysis, you have something that people can see, touch, and interact with. Doing so forces details to the surface that are simply invisible in abstract models in computers or on paper.

Some companies use the process to design their products as well as the processes that are used to manufacture them.

Last week one of my clients took their first steps into this process. The photo above has been pixelated so as not to reveal details about their product design.

They had done pretty extensive analysis using traditional industrial engineering methods, and had a CAD drawing of the proposed layout. That was the starting point.

The first step, then was to create that layout in real-size. That took the team about 90 minutes.

They assembled some tables, got some boxes and cardboard, and represented the machines, the work positions, the material and people flow.

Even as they were doing this, some of the team members saw things that they questioned, such as an ergonomically awkward operation. Others simply had questions. Why? Because in translating the drawing into the real world, even a superficial one, details already had to be resolved.

Once they had the starting condition mocked up, the team took prototype parts of the product and went through the motions of a team member trying to assemble it.

This felt a little awkward at first, but they began to see more opportunities, and resolve more detail.

We did a little coaching, pointing out motions that could be eliminated, others that could be consolidated. We talked about the smooth flow of people’s work, and looked for opportunities to better match the work flows to the takt time.

In the next couple of hours the team went through dozens of small PDCA cycles, each time adding a little more detail, adding a physical control, or a visual control. They found “knacks” that enabled quicker assembly with less adjustment.

They identified exactly how and where parts should be presented to the assembler.

They discovered small design and packaging changes that could make a big difference in the assembly time and quality. It did not hurt that the design engineer was trying to work out the details of one of the more awkward elements of the assembly.

They found key points that were critical to quality, examined the vulnerability to simple mistakes, and worked on how to make those more clear.

3pAndon

They identified characteristics that would help the machines better support the work flow. How do parts move in, move out? Where do the hands go to start the machine? How does the location of the controls support (or hinder) the work steps that come before and after?

As they looked at test operations, they started working out what they wanted to happen when there was a problem. They started to work out a line stop protocol and added andons to those machines, so they could signal an abnormal result.

Curious visitors, some senior managers, others just happening by and wondering what was going on, were enlisted as test subjects. Is the work cycle simple and clear? Is it easy to teach? Is the layout intuitive?

What can we do to make the visuals more clear, and to lay things out to guide the correct process sequence? Which “knacks” have to be taught? How quickly can a “new operator” be brought up to speed and make the takt time?

Over three days, the details came into sharper and sharper focus.

In the end, the team had constructed a full size model of their target condition. They are clear how the process needs to operate to give them the performance they want; and they are equally clear about the next problems that must be solved to get there.

They can specify their equipment with far more insight, and many of the details of how to guide the product and people through the process are now much better understood.

And, as a side benefit, this cross functional team has communicated far more than they would have otherwise with meetings and email. They have spent three days embedded in a joint project to envision what they want this to look like.

To be clear, a lot of work remains, and many more details remain to be worked out. But over three days this team now has a much more clearly aligned concept of what they are striving to achieve.