Category: In The Chalk Circle

You can observe a lot just by watching. — Yogi Berra

Posted on

From The Toyota Kata Seminar

I am taking the Toyota Kata seminar this week in Ann Arbor. There are two programs offered:

  • A one-day classroom overview of the concepts in Toyota Kata.
  • The one-day classroom overview followed by two days of practice on a shop floor, for a total of three days.

I am taking the three day version.

Impressions of Day 1

There are about (quick count) 36 participants, a big bigger group than I expected considering the premise. I don’t know how many are not going to be attending the shop floor part, but most people are.

I suppose the ultimate irony is the slide that makes the point that classroom training doesn’t work very well for this.

Realistically, I can see it as necessary to level-up everyone on the concepts. The audience runs the gamut of people who have read, studied, written about, made training material from, and applied the concepts in the book; to people who seem to have gone to the class with quite a bit less initial information.

That being said, everyone had some kind of exposure to lean principles, though there was a lot of “look for waste” and “apply the tools” mindset present. Since one of the purposes of the class is to challenge that mindset, this is to be expected.

You can get a good feel for the flow and content of the material itself on Mike Rother’s web site. He has a lot of presentations up there (via Slide Share).

Like any course like this, the more you know when you arrive, the more nuance you can pull out of the discussion.

Since I have been trying to apply the concepts already, my personal struggles really helped me to get a couple of “ah-ha” moments from the instruction.I arrived with a clear idea of what I wanted to learn, and what I thought I already knew. Both pre-disposed me to get insight, affirmation, and surprise learning from the material.

I would not suggest this for anyone who was looking to be convinced. Classroom training in any case doesn’t do that very well, and this material isn’t going to win over a skeptic. You have to be disposed to want to learn to do it.

At the end of the day, the overall quality, etc. of the presentation was pretty typical of “corporate training” stuff – not especially riveting, but certainly interesting. But we don’t do this for the entertainment value, and the learner has a responsibility to pull out what they need in any case.

Insights from Day 2

Day 1 is intended, and sold, as a stand-alone. The next two days are available as follow-on, but not separately.

The intended purpose was to practice the “improvement kata” cycle in a live shop floor environment. Today was spent:

  • Developing our “grasp of the current condition.” There is actually a quite well structured process for doing this fairly quickly, while still getting the information absolutely necessary to decide what the next appropriate target is.
  • Developing a target condition. Based on what we learned, where can this process be in terms its key characteristics and how it performs, in a short-term time frame. (A week in this case)

Key Points that are becoming more tangible for me:

The “Threshold of Knowledge” concept.

I elaborated on Bill Costantino’s (spelled it right this time) presentation on this concept a while ago. In the seminar, I am “groking” the concept of threshold of knowledge a bit better. Here is my current interpretation.

There are really three thresholds of knowledge in play, maybe more. First is the overall organization. I would define the organizations’ threshold of knowledge as the things they “just do” without giving it any thought at all.

For example – one company I know well has embedded 3P into their product design process to deeply that the two are indistinguishable from one another. It is just how they do it.

They still push the boundaries of what they accomplish with the process, but the process itself is familiar territory to them.

Likewise, this company has a signature way to lay out an assembly line, and that way is increasingly reflected in their product designs as 3P drives both.

It wasn’t always like that. It started with a handful of people who had experience with the process. They guided teams through applying it, in small steps, on successively more complex applications until they hijacked a design project and essentially redid it, and came out with something much better.

Another level of knowledge threshold is that held by the experienced practitioner.

Today I walked into a work cell in the host company for the first time, and within a few minutes of observation had a very clear picture in my own mind of what the next step was, and how to get there. My personal struggle today was not in understanding this, but in methodically applying the process being taught to get there. I knew what the answer would be, but I wasn’t here to learn that.

An extended threshold of knowledge in one person, or even in a handful of people, is not that useful to the company.

But that is exactly the model most kaizen leaders apply. They use their expert knowledge to see the target themselves, and then direct the team to apply the “lean tools” to get there.

They tell the team to “look for waste” but, in reality, they are pushing the mechanics. You can see this in their targets when they describe the mechanics as the target condition.

The team learns the mechanics of the tools, but the knowledge of why that target was set remains locked up in the head of the staff person who created it.

So his job is to set another target condition: Expanding the threshold of knowledge of the team.

He succeeds when the team develops a viable target themselves. It might be the same one he had, but it might not. If he framed the challenge correctly, and coached them correctly, they will arrive at something he believes is a good solution. If they don’t he needs to look in the mirror.

So the next level of knowledge threshold is that held by the team itself.

If enough teams develop the same depth, then they start to interconnect and work together, and we begin to advance the organization’s threshold. Now what was previously required a major “improvement event” to develop is just the starting baseline, and the ratchet goes up a bit.

None of the above was explicitly covered today, but it is what I learned. I am sure I’ll get an email from a certain .edu domain if I am off base here. Smile

There is no Dogma in Tools

This is the third explicit approach I have been taught to do this.

The first was called a “Scan and Plan” that I learned back in the mid/late 1990’s. It was more of a consultant’s tool for selecting a high-potential area for that first “Look what this can do” improvement event.

Though I don’t use any of those forms and tools explicitly, I do carry some of the concepts along and apply them when appropriate.

Then I was exposed to Shingijutsu’s approach. This is heavily focused on the standard work forms and tools. Within the culture of Shingijutsu clients, it would be heresy not to use these forms.

The “Kata” approach targets pretty much the same information, but collects and organizes it differently. I can see, for myself, a of better focus on the structure of establishing a good target. I can also see a hybrid between this method and what I have used in the past. Each form or analytical tool has a place where it provides insight for the team.

One thing I do like about the “Kata” data collection is the emphasis on (and therefore acknowledgement of) variation in work cycles. (All of this is in the book by the way. Read it, then get in touch with me if you want some explanation.)

Now, I want to be clear – in spite of the title of this section, when I am coaching beginners, I will be dogmatic about the tools they use. In fact, I plan to be a lot more dogmatic than I have been.

I am seeing the benefit of providing structure so that is off the table. They don’t have to think about how to collect and organize the data, just getting it and understanding it.

What I can do, as someone with a bit more experience, is give them a specific tool that will give them the insight they need. That is where I say “no dogma.” That only applies when the principles are well within your threshold of knowledge.

The real ah-ha is that, unlike the Shingijutsu approach, we weren’t collecting cycle times at the detailed work breakdown level. Why not? Because, at this stage of improvement, at this stage of knowledge threshold for the team, the work cell, that level of detail is not yet necessary to see the next step.

I will become necessary, it just isn’t necessary now.

Target Conditions and PDCA Cycles

One place where my work team bogged down a bit this afternoon was mixing up the target condition that we are setting for a week from now, and what we are going to try first thing in the morning.

The target condition ultimately requires setting up a fairly rigid standard-work-in-process (SWIP) (sometimes called “standard in-process stock) level in the work cell.

There was some concern that trying that would break things. And it will. For sure. We have to stabilize the downstream operation first, get it working to one-by-one, and make sure it is capable of doing so.

The last thing we want to do while messing with them is to starve them of material.

So – key learning point – be explicitly clear, more than once, that the Target Condition is not what you are trying right away. It is the predicted, attainable, result of a series of PDCA steps – single factor experiments. You don’t have the answers of how to do it yet. So don’t worry about the SWIP level right now. That will become easier… when it is easier.

More tomorrow…

Posted on

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.

Posted on

What Are You Sharing? What Are You Learning?

A common topic of discussion in many companies is how to document and share what has been learned as they improve their processes.

The most common approach is some kind of database (either online or on paper) that documents the various “best practices” solutions to various problems.

They might, for example, show the before and after of the development of a work cell, how their visual controls are set up, or a particularly clever tool or gadget they developed.

Perhaps not so surprisingly, these bits of information turn out to be far less useful than people think they should be.

Why is that?

Let’s back up a bit and look at a larger scale.

Toyota, and other companies that are doing these things well, have all been pretty open about letting people come on and see what they are doing.

Other companies seeking to benchmark these companies then want to find one that faces similar types of problems, say “low-mix / high-volume production” or similar process flows.

Our community has developed a sense of what a “lean system” looks like. We express it in terms of the solutions to problems that have been developed.

Work cells.

Kanban.

Clever tools or gadgets.

But we also (hopefully) know that seeing examples of these things with the intent of copying them doesn’t really help that much.

Oh, they can be copied… but the track record for sustaining is pretty poor.

Nope, we know (again, hopefully) that it is not about the solutions, but about the process of solving the problem. In other words, it is the method used to develop the solutions that is important to grasp. Seeing the solutions after the fact actually gives very little insight into how to develop the skills required to do it yourself, or sustain it yourself.

OK, back to the original topic.

IF we know that copying another company’s solutions doesn’t work very well, and that we need to instead get a grasp of the thinking process that resulted in those solutions, then what should we be sharing internally, and how should we be sharing it?

The classic way to share is with a single page that says “Before Kaizen” on one side, and “After Kaizen” on the other. There might be a space for “problem” but when it is filled in, the words are usually pretty superficial. 85% of the space is devoted to a couple of pictures.

Even if it does state the problem clearly, it still doesn’t get into the process used to solve the problem.

Nor does it get into what was learned about the process of solving problems.

Now… before you leap in and say “Sure, that is what an A3 is for!” I will agree with you. Except that unless an A3 is written with that specific purpose in mind, most of the ones I have seen tend to do little better than the Before-and-After pages. Or they are so full of charts and graphs that they are really impossible to follow.

In other words, they are too complicated to convey the message, because the intended message wasn’t clear when they were developed..

It really comes down to intent.

If you are trying to share, be crystal clear on what you are sharing. What are you trying to communicate?

I believe it would be far more valuable to depict where your problem-solving process was faulty, what mistakes you made, where you went back and corrected yourself, and what you want to pass along about problem solving.

That would be a far more useful for the next person to come along.

Posted on

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.

Posted on

What Does Your Customer See?

Travel plans sometimes come together at the last minute. I went to the green company’s web site to rent a car, and got a message saying the site was down for maintenance.

It said to please call the 800 number if I wanted to make a reservation.

I called the number.

The nice person on the phone asked if I wanted to make a new reservation or discuss a current one.

I said new reservation.

“Oh, our system is down for maintenance. Can you try again in a few hours?”

It was already midnight, so I really didn’t want to do that.

“That’s OK, I’ll just call Hertz.”
Which I did.

I encountered two problems here.
First was the message that implied that a human could make a reservation while the system was down. The accurate message would have been “Our system is down for maintenance. If you want to make a reservation, please try again in a few hours.”

And, since this is the de-facto process, I have to assume that the company is doing it this way on purpose.

Then again…
Do their executives rent cars through the online system? Do they experience what their customers do? Do they see the “we’re closed, please go away” sign that is part of their normal process every Saturday night?

Another company once put me on hold. The system kicked to a local radio station rather than silence. And so I was waiting for a customer service response while listening to Mick Jagger “I don’t get no… sat is fact ion…”

Posted on

Some Healthcare Observations

A couple of weeks ago I had the opportunity to return and see my friends in the Netherlands, and I’d like to share some observations from the Lean Thinking in Healthcare Symposium I attended over there.

But that conference was on Friday. I arrived in-country on Monday morning at 7:30am. By 10:30 am I was in sterile scrubs in an operating room observing a knee replacement operation. (I was told of this agenda while on the way there, at about 9:30.) I’ve got to say it was quite an interesting experience, and here is my public, if belated, thanks to Dr. Jacob Caron, who graciously brought me into his domain. Thanks, also, to his patient for allowing me into this bit of her life as well.

The experience was fascinating, and enlightening. Here is the core value-add of a long and complex process as the patient is moved through the various stages of treatment. And at that core, things are organized, quiet, efficient. Of course it is nothing like an O.R. on television. Drama is the last thing a real-life surgeon (or patient, for that matter) wants in the O.R.

The work flow of instruments caught my eye. We all know that the surgeon asks for the instrument he needs, and the O.R. nurse hands it to him, usually anticipating his request.

But there is a return flow as well. As the surgeon is done with an instrument, he puts it down as he asks for the next one. The O.R. nurse then quickly picks it up, wipes it (if necessary), and re-orients it so she can pick it up quickly when it is needed again.

None of this is really surprising with a little thought. I imagine the tight circle around the patient is organized pretty much the same way in every operating room in technologically advanced countries. In manufacturing, we use the “like a surgeon” analogy to describe how team members who directly add value should be supported.

Later that afternoon, I was touring the ward where the orthopedic surgery ward with the supervisor.

They are working on kaizen, they have an Problem – Improvement board and do a decent job keeping track of things that disrupt work.

“No time” seemed to come up a lot as a reason for the nurses. And, from what I know of the workload of hospital nurses, this is not a surprise either.

But where does their time go?

Let’s consider that nurses are the front line. Yes, the physicians get the attention, but aside from cases like surgery, it is the nurses who actually deliver the care to the patient. In other words, though the physicians design the care, it is the nurses who actually carry it out.

So here was my question / challenge to the audience at the conference:

No operating room in the developed world would ever tolerate a situation where the surgeon had to go look for what he needed to deliver care to the patient. The surgeon’s world is fully optimized so she can devote 100% of her attention to the patient.

Yet, in those very same hospitals, all over the world, we tolerate – every day – conditions where nurses, who are also primary care providers, spend too much of their time fighting entropy, looking for what they need, improvising, dealing with interruptions – all of the things we would never tolerate in the O.R.

Why the disparity?

Posted on

Pull as Kaizen

Michael Ballé’s recent Gemba Coach column drives home the importance of understanding that all of the so-called “tools of lean” are really there to drive problem solving.

A well designed kanban system is (or at least should be) built to not simply provide a pull signal, but more importantly, to continuously ask, and answer:

  • “What is supposed to be happening?” (what is the target condition?)
  • “What is actually happening” (what is the current condition?)

and give at least a hint of the problem that needs to be addressed right now when there is an issue. As a minimum, what condition must be addressed right now, and the first “Why? to be investigated.

A couple of months ago I posed a hypothetical question about a team’s effort to put in a kanban process and asked for your thoughts and comments.

The scenario I described was, with one or two trivial changes, copied directly from pages 48 and 49 of the Lean Enterprise Institute’s latest workbook, Creating a Lean Fulfillment Stream.

Although the process as described would likely work (at least for a few items), I was really surprised to see an LEI book describe a process that explicitly and deliberately breaks the “rules of kanban” that they have published elsewhere, particularly in Lean Lexicon. The LEI did not make up the rules of kanban, they have been well established for decades. Thus, I have to admit that my first response was to question the credibility of the entire book (Lean Fulfillment Stream), even though there are many things in it that are worthwhile.

Many of you correctly called out issues with the mechanics. Now, in light of this new information, I would again like to invite comment.

If a good process should be set up to continuously ask, and reveal the answers to, those two questions, where does this kanban scheme come up short?

How would those issues cause problems with the processes that Ballé is describing in his column?

 

Posted on

“TWiT Live” Walkthrough of Ford’s Rouge Plant

Tom sent this link to me, and I thought I would share it.

I can’t say much for the correspondent, but this is a decent view of a modern automobile assembly line.

The actual tour starts at around the 6:00 point.

When I look at a production line, one of the key things I am looking for is how they detect and respond to problems – both the mechanics and the strength of the problem solving culture.

I am curious to hear from any of my readers from Ford (I know you are out there).

Posted on

5S Audits – Part III

I would like to thank everybody for a really engaging dialog in the previous two posts about 5S audits.

Now I would like to dig in and look at what an “audit” is actually finding, and how we are responding to those issues.

Our hypothetical production area is getting an audit. The checklist says things like “There are no unnecessary items in the work area” and “There is a location indicated for all items.”

If there are unnecessary things in the work area, or things are not in their designated locations, what happens?

Of course, the checklist is filled out and a score is assigned.

But what has been learned about the process?

In one of the comments, I asked something like “When was the problem first noticed?”

The core purpose of 5S is to establish a testable condition that asks the question: “Does the team member have everything he needs, and nothing he doesn’t, where he needs it, when he needs it, to carry out his process as we understand it?”

One of the primary purposes of marking out the locations is to indicate the standard so that someone can notice right away that the standard has been broken. What should happen right then and there?

Since we define a “problem” as “any departure from the standard or specification,” and we have taken the first step of removing ambiguity from the situation (by deciding what should be here, and marking it out), we want an immediate response to the problem.

Ideally this means that the team member would indicate trouble (andon call, or other means) as soon as he discovered that his air gun was missing, or didn’t work.

The back-up to this is the team leader’s standard work. His eyes should be scanning for situations where there is a problem that the team member hasn’t called out. This is why the standards are marked out, posted, etc. To make this job easy for him. His immediate response would be to (1) Seek to understand the situation – what pulled the team member off his standard work, where did the problem originate, (2) Correct the situation. Sometimes that’s it. Other times, there is another problem to dig into.

It could be that something about the work process or conditions has changed and the team member is improvising a bit. That would bring extra stuff into the area, for example. I recall a great example where we pulled all of the thread cutting tools out of assembly so we could better detect when assembly was getting defective fabricated parts. It worked by forcing the process to stop and an andon call since assembly could not proceed if the threads were not cut.

At the same time, if a thread cutter found its way back into the assembly area, we would know we had two problems. First, we had defective parts. But more important, the process of telling us about that problem had been bypassed.

The back-up to the team leader’s standard work is the supervisor’s standard work. She is looking two levels down, but her response is going to be different. Unless safety or quality is jeopardized, the supervisor is going to find the team leader and (1) Seek to understand what pulled the team leader off of his standard work, and (2) correct the situation.

If the next level up is spending any time at all out on the shop floor, it is the same thing – maybe once a day – seeking out verifiable evidence that things are working as they should be. In the lack of positive evidence of control, we must assume there are hidden problems.

Now, if the audit finds something like this (click on the image for a bigger one):

Then it isn’t about the tape being out of place, nor is it a question about where the screwdriver is. What we have discovered is that none of the checks have been made, or if they have, no one has done anything about them.

Someone said “If we don’t do audits then 5S deteriorates.” OK – but why does 5S deteriorate?

Simply put, it is going to deteriorate, just as your process does, a little bit every day. Disorder is always being injected into everything. Your process will never, ever be stable on its own. No matter how good you are, the next level of granularity will show up as deterioration.

This is the “chatter” that Steven Spear talks about.

The question comes down to your core intention for the audit.

If you are assessing how well the area manager is coaching and teaching his people to see and respond to problems so that you can establish a target condition for his learning, and then develop his capabilities accordingly… there are better ways (in my opinion) to do that.

If you are assigning a numeric score in the hope that, by measuring something you can influence behavior, it might work, but people can come up with ingeniously destructive ways to achieve the numeric goals. As a thought experiment – how might an area manager get a high score on his 5S audit in ways that run completely counter to the goals of 5S, people development or “lean?”

The bottom line is that “Audit 5S” is not something that you should accept as a given. Rather, it is a proposed countermeasure to some problem. But if you start with a clear problem statement like “Team members are bringing thread taps into the assembly line,” and start asking “Why” five times, get to a root cause to that problem, you are unlikely to arrive at a monthly or periodic 5S audit as a countermeasure – nor are you ever going to need one.

The problem?

I think we feel the need to do audits because we have no process to immediately detect, correct and solve the little problems that happen every day. These little issues are the ones that cause the 5S erosion. Because we don’t have a process to deal with them one-by-one, we have to have an elaborate process that disrupts our normal work flow and takes them on in big batches.

Does that sound like a “lean” process to you?

How might we relentlessly drive the “audit” process closer to the ideal of one-by-one confirmation?

That would be “lean thinking.”

 

 

Posted on

Just a Few Seconds

What is a few seconds of delay? Why is it such a big deal?

Consider this example.

While touring the Pilsner Urquell brewery in (surprise!) Pilsen, Czech Republic, we saw a lot of really good information boards, general organization, and a clear management commitment to continuous improvement.

Their packaging plant produces 60,000 bottles of beer an hour. Even though they produce “bottles of beer” this is more of a process industry than a discrete product industry. Most of the operations are highly automated with human supervision, rather than human operated. So do the principles of “lean” apply?

Partly, it depends on your definition of “lean.” If you subscribe to the most common partial definition, where “lean” is a set of tools, then most people would struggle finding relevance to the context. On the other hand, if you look at this as a structure for the work, the work place, and the organization to drive out and solve problems – then you are in comfortable territory here.

While those machines are largely automated, they do occasionally have problems.

Those problems can be seen as a disruption or slowing of production. But in a large complex operation, many times these things are subtle and hard to pick up.

If you are running a process industry, consider these questions.

What is your nominal, expected rate of throughput at each and every critical juncture in the plant?

How do you know you are achieving that rate?

What is the threshold of slowing or disruption that will get your attention?

Remember, we want to look at “chatter as signal” here. While failure is a common condition, it is not a condition we ignore.

conveyer

This conveyer is coming out of the carton machine. Bottles go in. Flat cartons go in. Glue pellets go in. Cartons of beer come out, at a pretty good clip.

While we were there, though, a carton was mangled. As it got just downstream of this spot, the line was stopped. I don’t know if it was an automatic or a manual stop – I would hope it was automatic.

A couple of team members pulled the carton out, and re-started the line.

The line was stopped for 32 seconds.

Count how many cartons of beer go by in 32 seconds. Subtract that from the day’s production. It isn’t one mangled carton, it is almost 60 cartons of beer that will not be made today.

Sitting next to our mangled carton was another one, presumably from earlier in the shift.

120 cartons.

“Stop and respond to every deviation.”

Why did the line stop? Because the carton was mangled. Good call.

Why was the carton mangled?

Again – this is an operation bordering on world class, but I don’t know what goes on behind the scenes. They could be doing everything I mention here. So please look at this as an opportunity for a hypothetical example.

This is the kind of problem that executives often decide is not worth solving. It is, in the grand scheme of profit and loss, floor sweepings.

Hopefully that is not the case at Pilsner Urquell. I honestly don’t know. But what I do know is I can estimate that a couple of pallets of beer never get made each day as long as this problem persists. If a thief stole two pallets of beer from the warehouse every day, security would be all over it.

In a “lean” operation, though, we pay attention to these things. Just a few seconds matter. Why? Because those few seconds are what stand between the current condition and a target of more production with no more capital equipment.

In a process industry, that equipment costs big, big bucks. So now we are talking, not about a case of beer, not even about a little problem, but rather the fact that if there is a systematic approach to dealing with these little problems we might be saving many millions in future investments.

How reliable and consistent is the equipment and machinery in your operation?

Do you carry out regular maintenance checks? How do you know? Is there a way to verify that those checks were actually made – or at a minimum, verify that someone had to go to the place where they should be done? How do you know? It is one thing to have the pretty pictures in notebooks or on a board. It is another to have a physical check of some kind.

If you can verify those checks are being made, great. That is standard work. You have created a working hypothesis:

“If we carry out these checks, and this routine maintenance, at these times, in this way, then we will never be surprised by a stoppage.”

Of course you will be wrong. Unexpected slowdowns and stoppages are going to happen. But in our lean world, chatter is signal. Being wrong tells us something we didn’t know when we created those checks. That unexpected failure or breakdown had some kind of precursor that we might have prevented, and certainly should have seen. So we set up the process to immediately detect a slowdown or stoppage and let us know. We verify that the checks have been made, and then look at what we must change about them to cover the new insight we have.

Maybe this time we are only saving a few seconds. But it is really impossible to measure the effects of problems that do not occur.

If you are overrun by these problems, deal with the ones you can, maybe just a few every day, but deal with them in the right way, using thorough problem solving to the root cause. Be able to answer the question “What did we learn about our process here?” with something that you didn’t know previously.

Just a few seconds, but just as you save sixty seconds to save a minute, those seconds add up. At the very least, know what is happening out there. Go and see.