Category: The Basics

Posted on

Jim Collins: “Good to Great” Website

Jim Collins book “Good to Great” has been a best selling business book for several years. But I am not so sure everyone knows about Jim Collins web site. It as on-line mini-lectures, and much more material that reinforces the concepts outlined in the book.

As for how the concepts in the book relate to “lean thinking” – I believe they are 100% congruent. Examining Toyota in the context of the model outlined in the book shows everything Collins calls out as the crucial factors that separate sustainable improvement from the flash-in-the-pan unsustainable variety.

The only difference I can see between Toyota and the companies that were profiled is that Toyota has had these ingredients pretty much from the beginning, and Collins’ research was looking at companies that acquired them well into their existence.

Posted on

Waste

I guess four months into this, it kind of makes sense to talk about waste. But rather than repeat what everyone else says, maybe I can contribute to the dialog and toss out some things to think about.

Identifying / Seeing Waste.

Taiichi Ohno had 7 wastes, a few publications say 7+1. I have always disliked trying to put “types of waste” into buckets. I have seen long discussions, some of them fairly heated, about which list of wastes is “correct” and whether this waste or that waste should be included, or whether it is included in another one. None of this passes the “So What?” test. (A related military acronym is DILLIGAS, but I’ll leave it as an exercise for the reader to work out what it means.)

The problem, as I see it, with lists of categories isn’t the categories themselves. It is that we teach people using the categories. We make people memorize the categories. We create clever mnemonics like TIMWOOD and CLOSEDMITT. We send them on waste safari with cameras to collect “examples” of various types of waste. Well.. you can’t take a photo of overproduction because it is a verb. You can only photograph the result – excess inventory. So which is it? People end up in theological discussions that serve no purpose.

Like I mentioned in an earlier post, teach it by inverting the problem. The thing people need to understand is this: Anything that is not adding value is waste. If you understand what value is, then waste is easy to see. It is anything else. What category of waste is that? Who cares. That only matters when you are working on a countermeasure.

What about “necessary waste?” Even Ohno concedes there is some of that. OK – ask “does this work directly enable a task that does add value?” Then it is probably necessary – for now.

Let’s take a real-world example from my little corner of the world – welding. Welding is pretty easy. If there is an arc, it is very likely value is being added. Not always, but it is a good place to start. Now – watch a welder. What does he do when he is not “burning wire?” (the phrase “and producing a quality weld” has to be tacked onto the end of this because I can burn wire, but it doesn’t mean I am welding.)

What stops the welder from welding? When, and why, does he have to put down the gun and do something else? For that matter, what makes him let go of the trigger and stop the arc? Is he loading parts into the jig? Does he have to jiggle those parts into place? Does he have to adjust the jig?

Special Types of Waste

In spite of what I said above, there are two types of waste that merit special attention. Most everyone who can spell “J-I-T” knows that overproduction is one of them. I won’t go into it here – anyone who is reading this probably already gets that at some level. If I am wrong about that, leave a comment and I’ll expand.

The other is the “waste of waiting.” Of all of the categories, overproduction is clearly the worst, but the waste of waiting is the best. Why?

It is the only type of waste that can be translated directly into productivity. It is the waste you are creating as you are using kaizen to remove the others. That is because all of your kaizen is focused on saving time and time savings, in the short term, turn busy people into idle people.

Let me cite some examples:

  • The Team Member is overproducing. You put in a control mechanism to stop it. Now the team member must wait for the signal or work cycle to start again before resuming work.
  • You remove excess conveyance by moving operations closer together. The person doing the conveyance now has less to do. He is idle part of the time where he was busy.
  • Defects and rework – eliminate those and there is less to do. More idle people.
  • Overprocessing – eliminate that, less to do.
  • Materials – somebody has to bring those excess materials. Somebody has to count them, transport them, weigh them. Somebody has to dispose of the scrap.
  • Inconsistent work or disruptions: Eliminate those and people are done early more often than they were. More idle time.

If you look at a load chart, these are all things which push the cycle times down. You have converted the other wastes to the waste of waiting.

Now your challenge is how to convert that wait time to productivity. What you do depends on your circumstance. You can drop the takt time and increase output with the same people. Or you can to a major re-balance and free up people – do the same with fewer, and divert those resources to something productive elsewhere.

Does something stop you from doing that? Do you have two half-high bars that you can’t combine onto one person? Start asking “Why?” and you have your next kaizen project. Maybe you have to move those processes closer together, or untie a worker from a machine.

Summary:

  • Don’t worry too much about teaching categories of waste. Teach people to see what is truly value-adding, and to realize everything else is waste – something to streamline or eliminate.
  • In most cases your kaizen activity will result in more waste of waiting. This is good because wait-time is the only waste that converts directly to increased productivity.
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

Takt Time and Leveling – What’s The Point?

A few days ago I wrote about asking “What is your takt time?” and the likely responses to that question. But in my list of common responses, I left one out – “What’s the point? We get everything out by the time the truck leaves.”

Here’s a real-life example: In a high-volume consumer goods factory we had a daily transportation cycle. Shipments left once a day. Parts and materials arrived once a day. Although the operation was not without its glitches, the process itself incorporated a lot of automation (another story entirely), and the time through the machinery was pretty quick.

We were trying to implement the production leveling (heijunka) into the enterprise flow between the factory and the distribution system. While the mechanics were very straight forward, leveling the model mix during the course of the day encountered a logical question: What’s the point?

And what is the point? With or without model-mix leveling the same stuff ended up on the truck at the end of the day, and the total amount of inventory in the factory was not going to dramatically change. So why go through the trouble, especially of working changeovers on the packaging equipment, when there was apparent no net effect?

The question is a logical one until we understand that takt time (or pitch in this case) is not a production quota. It is part of a standard.

What’s so important about standards?
Without a standard, you can’t detect a problem.

Daily management is about rapidly detecting, correcting and solving problems. This is much easier to do when dealing with small problems before they grow into big ones.

The “What’s the point?” question even gets asked in the course of many lean manufacturing implementations. The operation reaches a level of performance that is “good enough” – for example, everything makes it onto the truck by the end of the day – and they are satisfied with that level of performance. This is when continuous improvement stops.

Have all of the problems been solved? Has all of the waste been removed? Of course not. But the next level of problems, and therefore the next level of performance, is under the radar.

In the factory I described above they had more demand than they could handle. They were already working 24/7, and were working to add capacity. They wanted to speed up the automation, and possibly even add additional lines. Yet, during the course of a day:

  • They lost many units to defects.
  • The lost production to machine stoppages and slow-downs.
  • They had part shortages and frequently substituted one product for another in the shipments, and made it up tomorrow.
  • Because they were “behind” they relentlessly kept the lines running, only to find defective product in final inspection.

The list goes on. They are all familiar things.

So what is the point of applying leveling product mix and establishing the discipline of a takt time or pitch?

Honestly, there isn’t any point unless they also implement a leadership process to immediately call out and respond to any slippage or deviation from the intended pace and sequence of production.

So – what started out as a question about a common tool or technique in the TPS has come around to what the core issue really is when that “What’s the point?” question is asked: Lean manufacturing is not about the tools and techniques. It is a system to assist a proactive leadership culture that is almost obsessed with finding and fixing the problems that keep them from achieving perfect safety, perfect quality, perfect flow, with zero waste.

A “problem” is any deviation from the standard. (And if you don’t have a standard, that is a problem.)

Two key questions:

Are we meeting the standard? If the answer is “yes” then:

Are we looking at perfection?

One or the other of those questions is going to drive you to address the next level of problems.

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?