Tag: Kaizen

Posted on

Who Took My Grease Pencil?

I was in a popular “Gold Rush” themed restaurant the other night, and they were struggling with a new table assignment system.

In the past the system was very simple. When you arrived, you told them your name, the number in your party. They wrote your name on a list, and gave you a pager. They had a laminated chart of the table layout, and marked tables as occupied, uncleared and available with a grease pencil. As tables became available, they moved down the list, triggered the pager, and took guests to the table. As tables were cleared and bussed, they were reported as available.

No more. Now there is a computer screen with the layout on it. They hand you the pager, and I suppose it gets logged in to “the system” as a party of 2, or whatever. And the computer pages you when an appropriate table is available. Sounds great, doesn’t it?

Of course the system is new, and the team was struggling a bit. That is expected, it is unfamiliar. But as we handed in our pager, I commented “I thought the grease pencil worked just fine.” The response was “Tell me about it.”

Now I suppose the technology enables them to track all kinds of great metrics like table turnover, etc. But if it is like most similar software implementations, those benefits are solutions in search of a problem. They are justifications for the expenditure.

I am always very wary when someone proposes to replace a functioning manual process with a computerized one. The main reason is this: The people who do the process no longer can improve it.

With a chart and a grease pencil, the team owns the process and readily understands the (non-) technology behind it. If they find a better way, it is easy for them to make an improvement.

Bury the process in a computer and you take that away. All the team can do is blindly execute whatever the programmer thinks should be happening. Programmers are smart people, but they generally do not have to execute their process hundreds of times a day. Maybe a few times – or even a few days – for testing, but not day after day. They do not, and can not, see the small issues that accumulate to become aggravation.

Before you introduce a “high tech” solution into your work area, think long and hard.

EXACTLY what is the current situation? EXACTLY what standard of performance is not being met by the current process? EXACTLY what are you trying to achieve? Remember that “automating the process” is a countermeasure, and that a “manual process” is not a problem. Let me say that again: If your problem statement says “Process is manual” then you do not yet understand the problem, and there may not BE a problem. What, exactly, about this manual process does not meet your expectations?

If the problem is that the process is labor-intensive or cumbersome, then you are getting closer. But jumping to automation still is not appropriate here. Have you carefully studied the process to see why it is labor-intensive or cumbersome? Have you looked at every step, every motion, and evaluated:

  • Why is it necessary?
  • What is the purpose?

Don’t know? Then that step is a candidate for elimination as pure waste.

  • Where should it be done?
  • When should it be done?
  • Who should perform this step?

These questions give you insights that let you combine operations. Administrative processes, especially, are full of redundant work – people looking up or entering the same information at different times in different places, or copying information from one place to another. Your goal is to take the remaining operations, the ones which passed the “Who / What” test and rearrange the steps into the best logical sequence, with the right people doing them.

  • How should this task be done?

Take the remaining steps and simplify. Make the job easier and quicker. Jigs, fixtures. In administrative processes – forms, templates. Find sources of error and mistake-proof them. Work out the method.

When you are done with all of this, then take a look at what is left. NOW, if there is a problem that has not, or cannot, be solved within the existing context you might consider an automated solution as one possible countermeasure… but don’t reflex there, unless you want to turn your kaizen over to programmers.

Last Thought – what about those great metrics the automated system can collect? Question: Do they pass the “Who Cares?” test? What is your plan to use those measurements to know where you are, and are not, performing to your standard? What is your plan to use that information to target improvement activity? Keep in mind that you cannot get performance simply by measuring it, any more than calculating your fuel mileage makes your car drive further. The purpose of measurement is to compare What Should Be Happening vs. What Is Actually Happening so you can compare your results against your predictions to see if the process is working the way you expect it to.

Posted on

Kaizen Events – Why and Why Not… continued

The other day I wrote about the situations where I felt a 5 day kaizen event was actually useful. I want to add one more.. sort of. Actually I want to elaborate on “education.”

Sometimes in the early stages of an implementation, there are influential people who need to be won over. Now for those who are cynical, there is not a lot of hope of that, at least not now. But for the people who are honest skeptics – meaning they will take in what information they have and assess it – those first few kaizen activities can have a high emotional impact.

Here is where you, the change agent, have an opportunity to make this “sticky.” Back in August I wrote a couple of posts that suggested that deliberately applying the elements of “stickiness” outlined in the excellent book “Made To Stick” would go a long way in building and sustaining an initial momentum. An initial kaizen event that is specifically structured to be high-impact can go a long way to do that.

In this special case you are producing a “reality show.” You are building a structure and a situation that will give your participants a specific experience. You want to create the six elements of “stickiness” that are covered in the book.

Simple. You want to send a simple and direct core message, a take-away, that everyone involved will be able to relate to. They have to understand experience just how much waste (and therefore opportunity) exists in the operation. They have to experience for themselves the power of engaging the people who do the work, of seeing for themselves, living in the conditions that exist in the work area every day. They need to experience the drag that is put on effective operations by all of the short-sighted decisions that are made every day.

Unexpected. You want to structure this kaizen event so that there is a big change in the performance of the operation, preferably in a way that was thought to be impossible. The highest-impact thing you can do is to create flow across several previously isolated process islands. This will typically crash inventory levels by one, and sometimes two, orders of magnitude, with a relative increase in velocity.

Concreteness. Same as above, actually. By participating directly in something that produces tangible, and real, results they immediately begin to learn application vs. academic theory.

Credibility. Again – direct participation in seeing the problems, clearing and solving those problems, brings credibility to the message – that a dramatic performance improvement is something we can do if we just pay attention to the right things.

Emotions. The purpose of the report-out at the end of these events is to allow the team that did the work to get.. and take.. credit for what they did. The report-out also emotionally engages the team in their work and their results.

Stories. If it is done well, the experience starts to be shared. People inevitably talk about the improvements they made, and how they solved this or that problem. People love to solve problems, and they like to talk about what they have done and what they learned in the process. When the General Manager starts telling these stories from her personal experience, people tend to pay attention. Hopefully they begin to say: “I’ll have what she’s having.”

Posted on

Kaizen “Events” – Why and Why Not

To many people, 5 day “kaizen events” are the way to implement lean manufacturing, and the way to improves processes. There is another, larger, group which insists that “events” are only one method, but in actual practice, kaizen events are all they do.

At the risk of being branded a heretic I propose there are two, maybe three, cases where kaizen events are the most appropriate tool. This is based on my personal experience, so your mileage may vary.

  1. Teaching. My contacts with long-time Toyota veterans are consistent – they have week-long events. They call them PKT or Practical Kaizen Training. The purpose is to:
    1. Teach leaders (and potental leaders) how to truly grasp the current situation – to see the actual issues being experienced by the workers as they do the work.
    2. Teach those leaders the cumulative effect of many small improvements, especially focused on the problems that disrupt routine work.
    3. Teach leaders that most of these problems are quick and simple fixes, if only someone did something about them.
    4. Teach leaders to teach others to observe, see problems, and solve them.
  2. Stabilization after a major change. Implementing flow often involves making major changes to the material and work flow. Those changes naturally introduce instability (or more properly, they reveal problems that have always been there, but hidden). It is crucial to have a team ready to intervene and quickly see, fix and then develop countermeasures for those problems. The week would start with the major change, then the team would focus on observing the actual (resulting) work, seeing problems (sources of instability), and devising and implementing countermeasures. The objective is to make the change, and leave it in a stable, sustainable state. All too many kaizen events do the opposite – make the big change at the end of the week after a lot of debate, and leave an unstable process for the Team Members to cope with on their own. This is “drive by kaizen” and leaves a bad taste in people’s mouth.
  3. Gathering a team to solve a specific problem. This is different than implementing a major change above. In #2, you already know what you want to do, you are just doing it and re-stabilizing the process. In this case, you know the problem, or what must be accomplished, but the local team does not have the time or wherewithal to actually solve the problem Some examples:
    • Achieving a dramatic reduction in changeover time.
    • Understanding and solving a nagging quality problem.
    • Setting up a layered maintenance checks on a machine.

All of this implies one important thing: That the kaizen event is planned based on a thorough understanding of the current situation. This can only be gained by careful observation and study. Note that none of the above items describes a scenario of bringing a team together to implement vague or unreachable goals and targets. Enough for now, before I start rambling again.

Posted on

Computer Kaizen

We were at a business meeting and my coworker was waiting impatiently for his laptop computer to finish booting up. He and I were sitting next to each other, had identical machines, but I was already working. He made some comment about my machine booting faster for some reason.

But that wasn’t the case.

Here is his laptop startup sequence:

  1. Unzip bag, remove computer from bag, set on table: 7 seconds.
  2. Remove power cord from bag, unwind: 8 seconds.
  3. Crawl under table to plug in power cord: 14 seconds.
  4. Re-emerge, connect power cord, connect network cord: 11 seconds.
  5. Open lid, press start: 3 seconds.
  6. Wait: 61 seconds.

This seems reasonable, doesn’t it? Why was my setup faster?

  1. Unzip bag, remove computer from bag, set on table: 7 seconds.
  2. Open lid, press start: 3 seconds.
  3. Remove power cord from bag, unwind: 8 seconds.
  4. Crawl under table to plug in power cord: 14 seconds.
  5. Re-emerge, connect power cord, connect network cord: 11 seconds.
  6. Wait: 61 – 33 = 28 seconds.

The core question is “Why can’t I turn on the computer sooner?”

It is a laptop. It will start up just fine on the batteries while I fidget with the power cord. And the networking doesn’t come on line until well into the boot cycle, so no time is lost if the network cable isn’t connected right away.

Net result is my wait time was half of my co-workers even though we both did the same thing. We just did them in a different sequence.

In the terms of a changeover, this is identifying internal tasks that could be external and moving them there.

This is the kind of improvement opportunity your Team Leaders should leaders should learn to spot. In most cases, though, they should not implement a change. Instead they should use the opportunity to teach the Team Member who does the work how to see this opportunity, and teach the Team Member how to make the improvements.

What kind of performance would you have if everyone in your operation thought this way for a year?

Posted on

Don’t Lose Sight of “Why”

I just finished responding to a post on lean.org where the poster was struggling a bit to justify moving two sequential operations together vs. the proposed simple solution of adding conveyance from one to the other. I thought it would be worth a bit to think that through.

In a previous post “Sticky or Slick”, I admitted struggling a bit myself trying to capture the “lead story” of the Toyota Production System, the one sentence core principle that could guide decisions. I still think it is close to “Structuring the organization and the work environment to harness people’s creativity to save time.

Let’s apply that logic to this situation. Now obviously I have not seen this operation myself, so I have no idea about the work breakdown, the cycle times, the nature of the work elements, so I am going to make up opportunities that illustrate the point.

I believe the key point that gets lost here is that, in 99% of the cases, you are not moving operations closer together. You are moving operators together. You are improving material flow with the purpose of creating better people flow. The TPS is about people. Specifically, it is about organizing the work and the work place so the people can make improvements that save time and make a difference.

If two operations operators team members who are performing sequential operations are separated in space or time, then although each can work to improve her own individual work, the results don’t pass the “so what?” test. “I reduced my work cycle from 10 minutes to 7 minutes.” So what? Now you are idle for 3 minutes. You still need to be there. And it is usually beyond the technical wherewithal of a shop floor team member to automate himself completely out of a job. Since they cannot reduce cycle time to zero, there is no net difference.

But now you have a problem to solve:
This person is idle (the waste of waiting). What must I do so he has meaningfully work?

Changing the layout is now the obvious countermeasure.

To turn this “problem” into true kaizen, create or improve flow by placing those two operations very close together. Now the magic happens. As each team member works to save time (or as they work as a team), they can also continually re-balance their work so at least one of the two is still loaded close to the takt time. Eventually they reach the point where one of them can perform both operations, freeing up the other. Even if this does not quite happen, by always consolidating the wait time onto one person, that person can take on more tasks assuming they are within reach. If they are not within reach, then move them closer together and facilitate more kaizen. Changing the layout is a countermeasure, not the objective. It is a countermeasure to the problem – the waste of waiting.

The “why” of putting things close together is to give the workers the power to improve their own work and the total flow of the system. The side-benefit of doing this is that you reduce inventory and save time. People’s time, throughput time.

Structure the work and the work place so the people who do the work have the opportunity to improve the system in a meaningful way.

The cycle of kaizen:

  • Attack overproduction so other wastes are revealed.
  • Convert other forms of waste to the “waste of waiting.”
  • Adjust the work balance, and then the physical flow to eliminate the waste of waiting.

If you do it in the other order – attack the waste of waiting first, the only way a team member can remain busy is through overproduction… and overproduction is bad. Very bad.

and.. after a couple of months and several dozen posts I finally added the category “kaizen” for this one. I am not sure why it took so long.

Posted on

Art of Lean

Art Smalley has a fantastic web site called Art of Lean.

I highly recommend it to anyone who is looking for “where to begin.”

Pay special attention to the e-learning piece on “Basic Stability.” This is where the money is, folks. Most of the waste (probably almost all of the waste) in your operation today is the result of inconsistency and variation. If you can get the daily problem solving engine started and systematically attack sources of variation in your operation every day, you will probably double your productivity over a couple of years. Is that worth it? I didn’t make that number up. I know a plant that got just those results and did nothing more than attack variation to get there.

Posted on

Hoopla – Another Quality Story

As I said in a previous post, I am spending the majority of my time in China right now.

As part of his preparation for attending a corporate class, one of my kaizen specialists was reviewing some of the training materials. From the other side of the cubicle wall he asks “What is ‘hoopla?” Although his English is very good, he is Chinese, and “hoopla” just isn’t a word that they teach in the universities.

Now I know for sure he is not the first non-native English speaker to read that material, and I also strongly suspect many before him did not know what “hoopla” means. But the others just made a guess from the context and kept reading.

Derrick, though, applied the first two steps of jidoka – he Detected a problem – something wasn’t right, didn’t meet the standard, or seemed to be in the way. Then he Stopped the process, and called for assistance. Instead of guessing what to do, the Team Member pulled the andon (got his Team Leader’s attention) and pointed out the problem.

The standard in this case is that the person reading the material can understand it, or at least understand the words that are not specifically being explained by the material. In this case, that didn’t happen. “Hoopla” was not understood, so the andon was pulled.

The third step is Fix or correct the problem, restore the standard (without compromising safety or customer quality in any way) and re-start the process. I explained what “hoopla” means, and Derrick could keep reading.

The fourth step is Investigate the Root Cause, Apply a Countermeasure. I sent an email to our training developer and mentioned what has now become “the hoopla incident.” The ensuing discussion among the training developers has resulted in a set of standards and guidelines for writing materials. Among other things, it calls out the need to avoid idioms and slang that might not be understood by non-native speakers. It also addresses other issues which will both make the materials easier for non-native speakers to read and make it easier for translators working to port the material to German, French, Spanish or… Mandarin.

W e should have some hoopla! The process worked – all because someone called out something he didn’t understand instead of just dealing with it on his own.

Posted on

5 Seconds Matter

I was with the factory’s kaizen leader, and we were watching an operation toward the end of the assembly line.The takt time of this particular line was on the order of 400 minutes, about one unit a day. The exact takt really doesn’t matter, it was long compared to most.

One of the Team Members needed to pump some grease into a fitting on the vehicle he was building. But his grease bucket was broken. We watched as he wandered up the line until he found a good grease bucket, retrieved it, went back to his own position and continued his work. The entire delay was much less than a minute. No big deal when you compare it to 400+ minutes, right?

Let’s do some math.

There are six positions on this particular line. Each one has two workers, a few have three, for a total of 14.

What if, every day, each worker finds three improvements that each save about 5 seconds. That is a total of 15 seconds per worker, per day. Getting a working grease bucket would certainly be one (maybe two) of those improvements. (Consider that the worker he took it from now doesn’t have to come and get it back!)

That is 14 workers x 15 seconds = 210 seconds a day.
210 seconds x 200 days / year = 42,000 seconds / year.
42,000 seconds / 60 = 700 minutes
700 minutes / the 400 minute takt time = we are close to having a line that works with 12 instead of 14 workers.

What is that grease bucket really worth?

Of course your mileage may vary.

But how often do you pay attention to 5 second delays?

Of course getting the grease bucket is really just simple 5S — making sure the Team Member has the things he needs, where and when he needs them.

So how would 5S apply in this case?
Mainly a good visual control would alert the Team Leader, or any other alert leader, to the fact that the grease bucket is out of place. A good leader will see that and ask a simple question:

Why?

And from that simple question comes the whole story, and an improvement opportunity.
But in order to ask “Why?” there must first be recognition that something isn’t right. And this is the power of a standard.