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.

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.

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?

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.”

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.

5S in Three Bullets

I was in a conversation today and we ended up boiling 5S down to three key points:

  • You have everything you need.
  • You need everything you have.
  • You can see everything clearly belongs where it is.

Of course at the next level, these statements are the standards you are continuously checking against.

Presumably we have cleared out everything else, leaving only what we thought was needed, and established visual controls to verify we have those things, and only those things, in the work area.

Then, as the work is done, the moment someone discovers something else is needed, THAT is the time to deal with the issue.

– Ask “Is this something we should need in the normal course of the work?”

If so, then you learned something that you didn’t know or didn’t remember when you first organized the area. Add that item, find a place for it, and establish a visual control. Right now.

If not, then “Why did we need it this time?”

What broke the normal pattern of work?

This is where 5S breaks down – when we don’t discriminate between something that is needed in the normal course of work, and something that is needed as an exception.

If we just “get it” and add it to the work area, then we normalize deviance and incrementally erode the process. If we ignore the issue, we add “getting this when it is needed” to the work cycle.

If, on the other hand, we seek to understand what broke the normal pattern and deal with the core issue, we have a shot at real kaizen. (It is perfectly OK to get what you need and keep it around as a temporary countermeasure. Just put it someplace where you will KNOW when you used it.)

The worst thing you can do is allow these small problems to accumulate and try to correct them en-mass as some kind of “corrective action.”

Kanban

Likewise, kanban can be expressed the same way. It is more dynamic, but is really answering the same questions in the context of materials.

 

Standard Work

If you paraphrase these key points to just about any other “tool of lean” then the purpose of surfacing problems and driving solution becomes apparent.

  • You are doing everything that is required.
  • Everything being done is required.
  • Everything being done clearly is part of the sequence.

Take a look at the other classic “tools of lean.” How would they fit into the same pattern?

 

Boeing Moving Line

Boeing’s “PTQ” (Put Together Quickly) videos show a time lapse of an airliner in production. They have been producing the for years – certainly since I was working there.

This one, though, shows something a little special.

When I first started working there, the idea of a line stop was unthinkable. The plane moved on time, period. Any unfinished work “traveled” with the plane, along with the associated out-of-sequence tasks and rework involved.

The fact that the 737 is now built on a continuously moving assembly line in Renton is fairly well known.

But what struck me in this PTQ video is that one of the things highlighted in it is a line stop. It happens pretty quickly at about 1:57.

The video is also full of rich visual controls to allow the team to compare the actual flow vs. the intended flow. See many many you can spot.

Keep Visual Controls Simple

In this world of laser beams and ultrasonic transducers, we sometimes lost sight of simplicity.

Remember- the simplest solution that works is probably the best. A good visual control should tell the operator, immediately, if a process is going beyond the specified parameters.

Ideally the process would be stopped automatically, however a clear signal to stop, given in time to avoid a more serious problem, is adequate.

So, in that spirit I give you (from Gizmodo) the following example:

Warning Sign