Agile Manufacturing Update

Book Review: American Icon

George Bohan — Tue, 14 May 2013 11:33:00 GMT

American Icon is the story of Alan Mulally's turn-around of Ford. You wouldn't call it a puff piece because it does go into a lot of detail as to what Mulally did and how he did it. It's effectively written and flows nicely. That said, it does read like it was commissioned by either Ford or Mulally himself. The author is clearly impressed by Mulally and what he accomplished. To be fair, Mulally accomplished a lot that's worthy of a good impression.

I was most interested in the steps Mulally took to change the culture at Ford. As regular readers know, I'm going to be presenting a webinar with Industry Week on that very topic later this month. I was pleased to read that the steps Mulally took fit well with the model I'll be presenting. So well, in fact, that I'm going to use the book as one of my examples of successful culture change using the model.

When Mulally got to Ford, top management was pretty much a dysfunctional family. They bickered, they tossed barbs at one another, they sought to gain advantage for themselves at the expense of the other managers, even if it hurt the company. Mulally knew he had to change this if the company were to survive. He knew he had to turn this culture around 180 degrees.

So, he instituted a mandatory weekly meeting of all his senior execs where each was expected to review the results in his or her area, including problems and barriers. During the toughest times, the team met daily (if I remember correctly). Some didn't want to come but he made them. Some didn't want to fully participate but he made them. Many thought it was a waste of their time but he didn't care. Most didn't like the standard format and the rigor but he didn't care. He stuck with it.

All that fit's with my model. Have in mind what you want to see change and what you want it to look like when it changes. Do something different. Do it consistently. Do it for a long time.

It took awhile but eventually the team started coming around. He reinforced the first exec who admitted failure. He reinforced each new effort at collaboration. He reinforced each new movement toward greater transparency and sharing of info. And, yes, one of the ways he reinforced these behaviors was to replace folks who couldn't get on board with folks who could. Starting with Bill Ford's brother-in-law.

The book is a good illustration of successful culture change and a good read in it's own right.

Plant Tours and Implementing Lean

George Bohan — Mon, 13 May 2013 11:31:37 GMT

I've had occasion, recently, to take some prospective clients to present and past clients' operations to see what they've been doing regarding lean. I'm going to be doing the same for those present and past clients, taking them to visit each other's sites.

I have to admit, up front, that I'm a bit of an agnostic about plant visits. I know a lot of them are conducted. My former employer, Work In Northeast Ohio Council, used to conduct tours to Saturn, Harley-Davidson, Miller Brewing, Toyota, and Honda and they were popular.

On the other hand, Lonnie Wilson, author of How to Implement Lean Manufacturing (a book I recommend, by the way), says that taking plant tours is a sure sign of a lean initiative that's going to fail.

So...who's right? Lonnie and me or all those organizations getting folks to pay to take plant tours?

Here's the issue: I think too many folks go on such tours for the same reason folks go to Disney World...to be wowed by all the neat stuff they hope to see. I've heard of the whole plant tours thing referred to as "industrial tourism" and I think that's probably accurate.

Don't get me wrong...a lot of an effective lean implementation does involve orderliness and visual methods so there should be a lot to see in a plant that's moving in the right direction. My problem with plant tours is that they necessarily focus on the neat visuals and not the culture change it takes to get there. And this isn't usually the fault of the company providing the tour. They will generally do a good job of telling what they did to get where they are especially if asked.

I used to have a client that attended tours of other local companies arranged by another consultant. I didn't attend the tours but I worked with the managers to develop a list of questions that they were going to ask at each tour. Then, we'd talk about the tour and what they learned at our next Steering Committee meeting. I found that it took a couple of tours to really get them to ask the questions. The first couple of meetings pretty much went over the neat stuff they saw and were a rehash of whatever the "tour guide" told them. I knew what I was looking for, though, and didn't let them off the hook. Eventually, they got the idea and did a good job of getting good information that went beyond the info that the plant had shadowboards everywhere.

If you're going to do a plant tour, then, you have to prep. You have to be ready with questions about the host's process and how they rolled it out. Mind you, you're not looking for flaws or chinks in the armor. You're trying to learn what they did, how they did it, and how they overcame the inevitable barriers.

Industry Week Web Seminar...I'm Gonna Be a Big Star!

George Bohan — Mon, 22 Apr 2013 12:34:03 GMT

Industry Week has asked me to conduct (or just take part in...I'm not sure) an upcoming web seminar on lean. I'll pass along more details as I have them.

Pre-Review: American Icon

George Bohan — Fri, 19 Apr 2013 11:00:26 GMT

I'm reading this book about Alan Mulally's successful turnaround of Ford. It doesn't say much about lean but it does have a lot to say about Leader Standard Work and culture change. More when I finish the book.

Book Review: American Drive

George Bohan — Wed, 03 Apr 2013 16:41:56 GMT

I like books about American companies and how they do what they do but I typically don't like those written by the guys or gals who actually run them.

First, most of them can't write worth a lick. I know...they get folks to help them (in this case, a fellow named Hank Cox). But, too often, those writers seem to be mostly dictation takers if the quality of their work is any indication.

Second, too many books "written" by senior execs are really boring. If you leave out the generalizations about how to be a good leader and the shop worn management cliches, you're often left with the table of contents and the index.

Third, such books tend to come across as vanity projects for retired hotshots. There's a lot of self-adulation as to what a good job they did under tough circumstances and not much of value for the reader.

American Drive: How Manufacturing Will Save Our Economy falls prey to most of these shortcoming to one extent or another but its strengths make it worth a read anyway.

Richard Dauch is a long-time auto guy. He worked for GM and Volkswagen before getting a chance to run his own store, American Axle and Manufacturing (AMM). I'm drawn to stories of heavy manufacturing, so I figured his might be an interesting one. It turns out I was right...mostly.

The story of his purchase and turnaround (two of them, actually) is, indeed, interesting. Dauch goes into enough detail as to what he did and how to keep the reader engaged. (That's not to say he went into as much detail as I would have liked...just that he told more of the story than many in his shoes do.) He has a chapter devoted to lean manufacturing. You won't learn much that you don't already know but he does give it more than a quick mention and it's apparent that he actually knows something about it. (I'm going to assume that the references to "value system mapping" were the fault of his writer.) The description of the fourteen phases of the company's Restructure, Resize, and Recover initiative that saw them through the recent recession (along with the auto company bailout), might be worth the price of the book in and of itself.

As mentioned, the book gives a good amount of detail of the AAM story. It's replete with examples, situations, illustrations, and cases. A number of the author's associates over the years were interviewed for the book and their additions are meaningful. (Many of their quotes focus on what a fine leader the author was but enough aren't to make them worthwhile over all.) The AAM story is a good narrative. In fact, I wish he had focused on that and pretty much nothing else.

My take-aways from the book are:

You must have a cogent management system that includes attention to quality, attention to employee engagement, and continual improvement of everything.
Senior leaders must instill vision and implement change themselves. This starts with regular and frequent face-to-face contact with everybody. (Daily plant walk-arounds were mentioned several times in the book.)
If you don't have the resources to invest in infrastructure, technology, and people, don't even get started.
A turn-around requires a great deal of sacrifice on the part of the management team.

The book isn't without significant problems. It would be about 70 pages shorter if it left out all the self-congratulations. I believe the author mentionds every award and honor he ever received back to the gold stars on his spelling tests in the third grade. By the last chapter, we're more than certain that he loves a challenge and sees himself as just the guy to take it on.

It's not well edited. Several times I had a feeling of deja vu...there are some episodes and lines of thought that he repeats for no apparent reason. Further, the interesting narrative of AAM is broken up by said self-adulation and general wordiness on the problems of manufacturing and challenges of management.

It's not as prone to cliche and platitude as other books I've read by retired bigwigs but it's got its share. Hint to every aspiring CEO cum writers nowhere in your book should appear the words "human resources" in proximity to "greatest asset".

The chapter on the future of manufacturing is the usual National Association of Manufacturers' boilerplate. (I found it odd that, having written a story about how a good management system, hard work, and continual communication of the vision can be so effective, the author didn't take the chance to tell other manufacturers to get off their fat butts and do the same. Easier to complain about taxes and health care for sick kids, I guess.)

In spite of these issues, I'd recommend the book to manufacturing managers. It's a quick read and there's enough of value here to make it worth your time.

10,000!

George Bohan — Tue, 02 Apr 2013 11:26:12 GMT

My humble blog past the 10,000 visitors mark for the first time last month. Thanks to everyone who showed up.

Lean Book Review...Sort Of

George Bohan — Fri, 29 Mar 2013 13:39:00 GMT

I bought a book on lean through Amazon a few weeks back. I hadn't read much on lean in awhile and figured this would be a good one, given that it focused specifically on the supply chain and logistics functions, which I don't know a lot about. And I was going to review it here because I hadn't done one of those in awhile.

But now I don't really want to do a review because the book wasn't very good. Well, I get to trade it in to Amazon for a ten dollar gift card but, other than that, there's not much positive to say about the book. Those of you who have read my other reviews a year or so ago know that I don't gush over lean books; I give both the pros and the cons. But there are no pros to this book (other than the fact that I can get a gift card for it). So, I'd feel badly disparaging a book some guy spent a lot of hours putting together.

Instead, I've got a list of "don'ts and do's" for anyone wanting to write a lean book.

Don't Tell Me About the Eight Lean Wastes
Every lean book written, every lean presentation given during the past 25 years went over the eight lean wastes. We all know them by heart. There's nothing new to say about them. Perhaps more to the point, there's nothing new anyone is saying about them. You and I both know that you've just pulled your "eight wastes" material from past writings or presentations, dusted it off a bit and stuck it in your book. Trust me, everybody is skipping that chapter, hoping that the rest of them won't be filled with material they are already as familiar with.

Don't Tell Me About Takt Time in the Second Chapter
The book I'm not reviewing here gives a definition of takt time on page 17. At that, it's just a short paragraph. The book doesn't get back to takt time for four chapters when it brings it up in a one or two-page discussion of work cells. The next time takt time is mentioned is way back in the appendices...where the importance of takt time is covered.

Here's my point: don't just throw stuff in the book to show us you know about it. (This book does a lot of that...quick mentions of concepts and tools but little real discussion.) Takt time is a simple idea but can be complex in its applications and uses. It's a powerful and helpful tool. One could write a separate chapter on takt time and its uses. The same is true for many other lean concepts and tools. If you're going to bring them up at all, tell us all about them.

Don't Just Give Me a List of Tools
This is related to my point above. Most of the books I've read on lean simply list the tools and methods, giving no more than a quick description and maybe (maybe) a quick example or two. You can't just tell your readers that there is such a thing as 5S or line balancing or value stream mapping. If you're not going to fully explain what a particular tool or method is, why it's important and useful, how and when to implement it, possible implementation challenges and how to address them and as many illustrative examples as you can stuff between the covers, then don't bring it up at all. I've done a ton of 5S in my career but I'd read a book devoted only to 5S written by someone who really went into it. As it is, too many books simply tell me what the five S's stand for and leave it at that.

Tell Me Something About Culture Change
My own experience tells me that implementing lean is ten percent about the tools and ninety percent about culture change. And the tools are pretty easy. It takes, at most, two hours to pretty fully explain 5S. I've found it takes about two years to create the culture change necessary to fully implement 5S.

Further, I spend a lot of my time on culture change issues so I figure other consultants must be doing so as well. So how come there's so little about culture change in most lean books. The index of the book I'm trading in doesn't mention it at all as nearly as I can tell.

It's this simple: If you're going to tell me about tools, you must talk about implementation. If you're going to talk about implementation, you must talk about culture change. I don't necessarily expect you to be an expert but I do expect you to identify and address the cultural issues you faced and how you addressed them. If you don't, I can only assume that you've never actually implemented the tools or methods you're telling me about.

Tell Me Some Stories
One of the testimonials on the book I'm not reviewing says it provides "many examples that help explicate the complexities" of lean. Except...it doesn't. Oh, there are a number of general case studies gleaned from various journals and consultancy reports. But there are precious few "real life" examples of implementation of the tools and methods. I can get the basics of, say, value stream mapping from any of a hundred books. I want to know how you've used it, what it's done for you, what hassles you ran into and how you overcame them. Giving me a definition of kanban and providing a picture of a kanban board doesn't help me much. I need illustrations, examples, stories, and anecdotes that will help me figure out what it is, how it helps, whether or not it will work in my situation and how to implement it. The book I'm not reviewing has two pages on kaizen events that includes a list of twelve bullet points on kaizen event management. The list could have been pulled from about any other book on lean. I don't get the sense the author ever actually participated in or managed a kaizen event because he doesn't tell me any more about the topic than I could have discovered through a quick web search.

Tell Me How to Get Started
I've talked with any number of managers who've told me "I've read lots of books on lean but I don't know what to do to get started". That's because lots of books on lean don't say anything about how to get started.

I understand that authors want to stay away from the "cookbook approach". But they stay so far away from it that they don't provide value. I also understand that authors want to speak to as many people in as many different situations as possible. But they end up not being of much help to anyone in any situation. At some point, you have to tell the reader, "Do this and do it this way." You need to be able to tell the reader what to do next Monday. You've done it yourself or you wouldn't be writing the book. Tell the reader what you did, how you did it and why. Use your own stories to illustrate. Trust that your readers are smart enough to translate what you're telling them to their own situations.

Takt Time - Part 3

George Bohan — Mon, 25 Mar 2013 10:29:00 GMT

If you've gotten this far, you're probably thinking, "I see your point, Rick, but takt time isn't identical to rate. Rate is standard. Rate (for the most part) doesn't change. But takt time can change as the time available changes. It can also change as demand changes."

That's true. We've looked at examples that start with rate and figure out available time. But what if we started with customer demand and available time, then worked our way to the "needed rate"? I have a client that's working to improve the flow in a cell that makes a component for its products. The company uses, let's say, 1000 of those components a shift. And let's further say that the available time in each shift is 7.5 hours. (To make the calculations easier, I'm going to assume there is no downtime, scrap, or changeover time.) So....the cell needs to be making one of those components every 27 seconds. Or, the way I prefer to look at it, 134 parts per hour. (It's actually 133.33.)

This is the official definition of takt time: customer demand divided by time available. The cell needs to produce at the rate of 134 parts per hour to meet demand. If it produces less, there will be a shortage of components. If it produces more, there will be a surplus of components.

Right away we can start doing some things with takt time. The first thing we need to do is to ask: "Can the cell make a component every 27 seconds?" If the answer is no, then we have to add capacity, i.e., we have to make some changes to the cell so that it can make a component every 27 seconds. If the answer is yes, then we're golden. If the answer is we can actually make a component every, let's say, 20 seconds, then we have "too much" capacity. We can reduce the capacity by reducing people or equipment but, most times, cells like to have a bit of additional capacity to respond to sudden and temporary increases in demand.

Another thing we can do with takt time is figure out whether the line is balanced or not. If the cell needs to be finishing a component every 27 seconds, then everybody in the cell needs to be doing whatever they are doing at the rate of one component every 27 seconds. Remember our last post when we talked about my operation taking twice as long as yours in our two person cell? If our cell has two people, four people, ten people or 100 people in it, product will only get out of the cell at the rate of the slowest operation. If everybody is 27 seconds per part or better, we're in good shape. If a process step takes longer than 27 seconds a part, then we have some fixin' to do...we've got to add capacity at that step. The same, by the way, is true if we have a process step that's substantially faster than 27 seconds per part; we have too much capacity at that step and it should probably be reduced.

All that said...we've come back around to where we started in Part One of this discussion. We've figured out that the cell's rate needs to be one part every 27 seconds (134 parts per hour). The key is to operate at that rate...consistently.

Good Series of Articles on Value Stream Mapping and Capacity

George Bohan — Sun, 24 Mar 2013 18:05:15 GMT

I've been posting a series on how to read a value stream map. I also had a recent discussion on LinkedIn regarding whether or not extra capacity represents waste.

By coincidence, I stumbled across this set of articles that pulls the two topics together. Good reading.

Capacity Has Value - Part 1

Capacity Has Value - Part 2

Capacity Has Value - Part 3

Takt Time - Part 2

George Bohan — Wed, 20 Mar 2013 12:53:00 GMT

In my last post, I talked about takt time as being nearly equivalent to "standard rate" but I focused on operations that had just one process step (essentially). If I'm running a stamping press at 750 pieces per hour then that's my takt time, assuming I'm making a finished product. (I know, I know...my takt time is actually 4.8 seconds or something like that. But you get my drift.)

So, takt time pretty much equals rate for single step processes. (Again, I'm assuming that available time is adjusted based on the standard rate for the process, which is usually the case.)

What about multiple step processes? Like in a cell? In this case, the ideas we've presented still hold but sticking too closely to the "takt time as standard rate" idea can get us into trouble if incorrectly applied. Let me illustrate with an example. Let's say you and I are in a cell with two operations. I run my operation at 100 pieces per hour and you run yours at 50 pieces per hour. If we take the "run at rate" concept too literally, I'll be stacking product in front of you until it reaches the ceiling. Not a good thing. Or I'll be running product for an hour then reading the paper for an hour. Also...not a good thing.

In this case, we have to look at the rate of the cell as a whole, i.e., the two operations in tandem. What's the rate at which product is produced by the cell? That's right...50 pieces per hour. We can't get more out of the cell than you can make.

We have a problem, of course; what to do about that discrepancy in the rates of the two operations? Well, we have some options:

Slow me down to 50 pieces per hour,
Speed you up to 100 pieces per hour,
Add another second operation so that the cell becomes me at 100 pieces per hour and two of you at 50 pieces per hour,
Add more time at the second operation, e.g., run my operation for one shift and yours for two shifts,
Put a supermarket between our two operations so that you pull at your rate and I replenish at my rate.

Which of these options we choose depends on a variety of other factors. Each choice has differing impacts on flow, overall cycle time, etc.

How to Read a Value Stream Map - Conclusion

George Bohan — Tue, 19 Mar 2013 09:35:47 GMT

I know I haven't said everything there is to say about reading value stream maps but I hope I've said enough to help you. And I hope that this info on how to read a map will help you in developing your own maps.

I'm helping a client improve the flow of a component. We're using a map that was developed before I got there. It has some useful data and is missing others. For example, I can (after some study of the map) determine batch size between each of the process steps but cycle times are missing. There are no data regarding scrap or downtime at each process step. It's difficult to tell exactly how many people are needed to run the cell. Inventory data are present but a bit difficult to figure out and I can't tell whether they are "snapshot in time" figures or averages over some period of time. It's a good example of a map that was drawn up without fully thinking through what was desired from the map.

Looking back at our series, the information we found most useful was:

How does stuff flow?
How much stuff gets shipped each day?
Where does stuff sit and for how long?
What's the "batch size" at each step?
How many people work at each step?
How long does it take to process a batch at each step?
How long does it take to changeover between different jobs at each step?
How much downtime does each step suffer? How much scrap?
How much time is available to make stuff at each step?

If I have all this information, I can usually tell how well (or not) things are working. Even better, I can start figuring out what's needed to improve flow.

Takt Time - Part 1

George Bohan — Fri, 15 Mar 2013 12:52:00 GMT

I had the toughest time figuring takt time out. Every lean book talks about it's importance. Every lean book gives a definition of takt time: available time divided by customer demand. But none of the books really explained it.

I remember a seminar, several years ago, at which I asked a presenter what takt time was in practical terms. He repeated the book definition. I pressed the issue saying that my client's customers didn't demand the product be produced at a certain rate; they wanted their product right now (as promised by my clients). Further, the volumes they demanded varied considerably in many cases. Did that mean takt time varied? The presenter really didn't have a response. It was clear he didn't understand takt time any better than I did.

I finally figured out that the important thing about takt time isn't the number that comes out of the equation. It's the concept of takt time that's important. And trying to get supervisors and managers to buy into that concept has gotten me into lots of "interesting" discussions.

The important concept is this: You have to make product at a steady rate. That's it. Don't make product below rate, don't make product faster than rate. Stay with the drum beat. (I gather takt time is German for "beat" or something like that.) So when folks ask me what takt time is, I tell them it's running consistently at rate. Period. (OK, there's a bit more to it than that...eventually. But this is a very good place to start.)

Let's look at an example. I had a client that made metal stamped widgets. One operator at a press stamped the widgets and put them in the packaging. In effect, it was a one-person cell. The company already had a "standard rate" at which it wanted to see each different type of widget stamped and packaged. In effect, that was the takt time. Because the folks in scheduling looked at how many widgets were needed, divided by the rate, then scheduled the appropriate amount of time. So...takt time wasn't something you figured out once you knew customer demand and available time. Available time (or the time needed to produce a given number of widgets) was figured out once they knew how many were needed. Takt time (aka: standard rate) was constant.

That was an epiphany for me. I didn't have to introduce this brand new concept and try to explain it. I could just say, "Run at rate consistently. No more. No less. All the time. " (And, believe me, that statement is controversial enough sometimes.) That statement is clear for any "one step" operation like metal stamping, roll forming, extrusion, molding, and most process manufacturing situations.

Here's the thing: I've never had a client that consistently ran these sorts of operations at a consistent rate. Never. I put up hourly charts that show the operations only hit rate at all about 75% of the time, usually less. This means that "available time" has to be increased. This, in turn, means that overtime has to be paid and/or available time taken from other products and/or expedited shipping has to be purchased and/or customer service takes a hit. There's not much sense in talking about "improved flow" when you can't even consistently run at rate.

So before I get talking to my clients about takt time (if I do at all) and flow (which I always do), I talk with them about solving the problems that keep them from running at rate consistently.

The concept requires a bit of modification for a cell but the basics stay the same. In that case, the cell has to run at a standard rate consistently. That might mean making some significant modifications to the rates of the individual process steps within the cell. I'll talk more about that in my next post.

How to Read a Value Stream Map - Part 5

George Bohan — Mon, 11 Mar 2013 12:27:00 GMT

OK, just one more, only because I'm getting such a kick out of this.

Look at this map and figure out a few things for yourself before looking at my discussion. I know it's a big hard to read but I think most of the data show up. One datum that you'll need is the batch size at Fabric Cut: it's 6 days, I think.

So, it looks like they're making chairs. It's a very rough hewn map; data are incomplete. We don't have batch size for each operation. We don't have cycle time for fabric cut. At operations with more than one operator, are all the operators working on one chair or is each operator working on his or her own chair? At Upholstery, for example, is one chair produced every 501 seconds or are six chairs produced in that time? We don't know and it makes a difference. And, as in an earlier case, we have days of inventory but not amounts but we can figure them out given that they ship 1000 chairs a week.

We don't have scrap or uptime data but I'm not too worried about that, given the product (I'm guessing they don't toss out many chairs...they just keeping working on it until they get it right.) On balance, though, it couldn't hurt to have it, especially for the earlier steps like Fabric Cut and Foam Cut, where mistakes probably can't be reworked and have to be tossed out.

We always look at inventory first and we see what seems to be a pretty lean operation. Three days of inventory in finished goods: that's seven (or so) turns a months. That's darned good. Going upstream from finished goods, we see that WIP is commensurate with finished goods inventory. In fact, they might be cutting it a bit close in some cases but let's assume it's working for them.

They keep two weeks of raw materials, which makes sense given the frequency of deliveries. Again, in the case of "Other stuff", which gets delivered bi-weekly, a two week inventory might even be cutting it a bit close.

I have a problem, though. Look back at the batch size at Fabric Cut; as near as I can tell it's six days. Large batch sizes might make sense if changeover times are long but that's not the case here. Also, look at the inventory between Fabric Cut and Sewing; if Fabric Cut batch size is six days, how can there be one day of inventory on average? If you finish a batch and put six days of Fabric Cut in front of Sewing and work it down to zero days, that's an average of three days of inventory.

Here's what I think it happening: the inventories aren't averages, they are "snapshot in time" measures. In other words, they went out one day, counted up what they had and that's what they reported on their map. Now, that's not a terrible thing to do but it does mean that actual inventories between the operations may be a good bit higher than they appear to be on this map. We don't know what the cycle time is at Fabric Cut so, for all we know, it's a fast cycle, they cut Fabric until they don't have any place to put it (which, coincidentally, is six days worth of inventory), then quit cutting Fabric until they work the inventory off. If they are doing this at Fabric Cut, they are probably running the other operations the same way. The fact that all those dotted arrows indicate that they are on "push" scheduling and production is consistent with this hypothesis.

So, reading the value stream map with a sharp eye and a detective's mindset helps us tweak out possibilities that aren't immediately apparent.

How to Read a Value Stream Map - Part 4

George Bohan — Thu, 07 Mar 2013 12:54:00 GMT

It's just a short post today. I have an example of a bad value stream map (or, at least, one I can't figure out given the data on it). See if you can tell what's wrong with it before I spill the beans. Hint: We've always looked at inventory first.

Here it is. (I got this at
If there's something I'm missing, let me know.

I found this report online at the Aberdeen Group website. (Aberdeen Group Lean Report) (They provide some of their whitepapers for free....like this one. Might be worth registering at their site.) It's a summary of a survey of about 86 companies regarding their lean practices. Very readable and some very worthwhile info contained herein.

Among the (IMHO) interesting findings:

About 2/3 of the companies saw cost reductions as a primary driver of their lean efforts. This isn't good news. I've written here and elsewhere that cost reduction isn't a good primary goal for lean efforts. My hypothesis is that companies that are primarily after cost reductions will get fed up with lean long before the concepts and tools start to work.
No one will be much surprised to hear that alignment of goals and measures across and up-and-down the organization is fundamental to success of the lean effort. I was surprised (and very pleased) to see that visibility of processes was given a shout out. One doesn't see the issue of visibility get a great deal of coverage in lean literature. Every lean book out there dutifully provides a definition of takt time in the first or second chapter, whether or not it has much to do with what they are talking about. Not so many cover the vital importance of visibility of processes and how to achieve it.

How to Read a Value Stream Map - Part 3

George Bohan — Thu, 28 Feb 2013 12:25:00 GMT

Let's look at another value stream map with some additional and some different data on it and see what we can see. (I found this one here: engineeringeconomist.blogspot.com/2011/01/profitable-applications-of-value-stream.html. Sorry for the white space but I can't figure out how to get rid of it.)

As we did last time, let's look at inventory. This time we have amounts (in the sort-of triangles) and days (down on the time line). We see we have four days of inventory in finished goods, which isn't bad at all. But...we have another 25 days in WIP. That ain't good. We could run the process for a month if our supplier didn't ship.

Maybe it's because the demand from the customer is highly variable. We can't say for sure because our map doesn't show it. That's why I like to have standard deviations or, at least, ranges for averages. But let's assume it's not highly variable.

Maybe it's because the process itself has a lot of variability in it. But the uptime is lots better than it was for the previous process we studied, so that doesn't look like an issue. We do have a lot of variability in cycle times between process steps, which can be an issue. On the other hand, the largest block of inventory is in front of the process step with the lowest cycle time. We'd expect that inventory to be lower given that we can process it faster. Generally, a situation like that is due to poor scheduling. (That's also the step with the lowest uptime, so that might explain some of the inventory.)

Maybe one or another of the process steps makes lots of scrap but we don't have that data. Maybe the cycle time for each process step is highly variable but we don't have that data either. We can see that the supervisor is scheduling each process step separately based on an overall production plan. It's probably safe to assume that the supervisor is paying more attention to keeping each process step running no matter what than in good flow through the value stream. That, as much as anything, is probably at the root of our high inventory.

Notice that this map shows the lot size for each process step: 1000 pieces at each step. That's two days worth of shipments. That strikes me as a lot of product. It'll take 44,000 seconds or over 12 hours to get one batch through Machining, about the same amount of time to get it through Honing, about 1.5 hours to get it through Deburring, more than 8 hours to get the lot through Inspection, and about three hours to package it. That's nearly a week of work days to get a batch through the entire cycle.

A lot size that large might make sense if changeover times were long but they aren't. Sixty minutes isn't anything to sneeze at but the other changeover times are just a few minutes. If we can get the Machining Changeover time down, we can reduce the lot size quite a bit.

On this map, we have the Available Time for each process step. It looks like only one product is run through this value stream because the map shows the entire shift is available to run the product the map focuses on. If more than one product is run through the value stream, the available time for each should be noted.

I don't know what the numbers inside the red and blue triangles are for.

Overall, it looks like we've got a classic "push scheduling" situation with large lot sizes and little coordination between process steps that's leading to a lot of stuff sitting around.

How to Read a Value Stream Map - Part 2

George Bohan — Mon, 25 Feb 2013 12:24:00 GMT

Here's our value stream map again:

(Eventually, we'll look at some others but let's stick with this one for a bit.) Last time we looked at inventory and found out that there's a lot of stuff sitting around. This time we'll look at operations. Most of that data is contained in the boxes under the process steps.

Here's a quick glossary of the terms in the boxes:

C/T - Cycle time to make one piece or one unit at that process step. My own preference is to use an hourly rate.
C/O - Changeover time or the time it takes to change from one product to another.
Uptime - The amount of time we can expect the process step to run without interruption or problem.

Looking at our map, we see that the cycle times vary quite a bit across the process; some process steps run more than three times as fast as other process steps. Everything else being equal, product will build up in front of slower process steps because slow process steps are bottlenecks. Sure enough, our map shows 15 days of inventory in front of painting.

Looking at uptime, we see Painting has terrible performance: it's up less than half the time. That's another reason it's a bottleneck. And the other process steps aren't much better. Milling has the best uptime and it's down one hour of every four.

At least our bottleneck is toward the end of the stream. In my view, that's a bit better than having WIP clogged up at the front end of a stream but others might not agree, thinking a bottleneck is a bottleneck wherever it is. I wouldn't argue with that.

So, it's apparent our process needs a lot of improvement.

We see how many people work at each process step. That doesn't help me much as of yet because I don't know what any of them are actually doing. I do know that there are ten people working in a pretty bad process, so I can imagine that output per labor hour is pretty low.

There are data missing that I'd like to have:
Scrap rates at each process step
Available time for the product we're focused on at each process step
Lead time for raw materials and frequency of shipment
Lead time for finished goods to customers and frequency of shipments
On time delivery performance from suppliers and to customers
Amount of inventory at each step (in addition to days)
Variability around the various averages

These data would help me learn more about the value stream.

How to Read A Value Stream Map: Part 1

George Bohan — Wed, 20 Feb 2013 11:27:23 GMT

We're getting ready to move this summer so I'm going through and packing my books. Naturally, I find books I haven't looked at in a long time and get to re-reading some of them. One of my lean books reminded me of a problem with much of the lean literature: they all tell you to make up a value stream map but they don't really tell you what to do with it (ergo, the problem I mentioned in a recent newsletter...value stream maps posted on the wall with nothing done about them.)
So, I figured I should write a post or two about just what's on those maps and how to interpret it. This won't be a definitive discussion. It will be based on my own experience and views and may understate some things and overlook others all together. But it'll be better than what's in much of the literature which doesn't get much past listing the symbols (most of which I don't use any way).
You might ask, "What's the value in knowing how to read a VSM when I don't even have one yet?" Well, I'm thinking that, once you know what's important and how to interpret it, you'll do a better job when you develop your own maps. And, best of all, they won't just hang there on the wall, useless.
The best way to learn how to read a value stream map is to look at some value stream maps. There are a bunch of them all over the internet I've found (Google "value stream map" and look for "Images") and I'm going to use some of them. I'll make an effort to make sure credit is given where it's due but, full disclosure, none of the maps you're about to see are my own. I didn't do the work...somebody else did.
Let's start with a fairly simple one without too much clutter. (I found it at this address - http://www.epa.gov/lean/environment/toolkits/environment/ch3.htm):

The first thing I look at is inventory. This one shows inventory in days; I like that. It tells me how many days the processes downstream can keep going if the processes upstream shut down completely. (Eventually, I'd also like to know amounts of inventory as well but days of inventory is a good start.) In this case, I see the company could keep shipping for a month if the plant shut down entirely because it has 30 days in finished goods inventory. That's a lot of inventory but not bad...it's twelve turns a year. But let's keep going...if everything but Assembly shut down, the company would be able to ship for more than five weeks (Thirty days of finished goods plus eight days of WIP in front of Assembly.) If everything but Assembly and Painting shut down, the company would be able to keep shipping for 53 days. Working all the way back, if the supplier were to shut down and the plant run, the company would be able to keep making parts and shipping for more than two months. That's only six turns a year....it's a lot of inventory. There might be some good reasons for that but I doubt it. Most companies, prior to implementing lean aren't controlling inventories at levels they know to be necessary to keep service levels high. They just have a lot of stuff sitting around. And a lot of stuff sitting around means lack of control of processes.

While we're focused on inventory, there are a few things I'd like to know that the map doesn't tell me. Let's look at that thirty days of inventory in finished goods as an example. Is that thirty days on average or was that the amount in inventory on the day the map was drawn up? If it's an average (and I hope it is), over what period of time? And how much variability is in the average? Is it thirty days, give or take a day or two? Or thirty days, give or take twenty days? There's a big difference between:
Thirty days based on a count the day we drew up the map,
Thirty days based on an average taken over a week, with a range of five to forty days,
Thirty days based on an average taken over a year, with a range of 25 to 35 days.

We'd want to know the same things about the inventory at the other points along the value stream.

The first thing I look for, then, is how much stuff is sitting in the value stream at any given point. Our first glance at the map shows us that we've got a lot of stuff sitting around. We don't know how well it's being controlled but our guess is that it's not. (Mo' better data will help us nail that down.) One piece of info that leads us to believe that the inventories aren't in control? See those jagged lines emanating from Production Planningthat show each process step being scheduled separately? That almost always means that WIP is building up or being depleted, willy-nilly, in response to all the problems and chaos that tend to be a part of the mix.

Next time, we'll look at the operations themselves to see what we can learn about that chaos.

Make it Visual: Part 2

George Bohan — Fri, 15 Feb 2013 23:26:00 GMT

When we last talked about "making it visual", I left you with a "pop quiz" of sorts. I gave you the example (real life, by the way) of a supermarket of four ingredients and asked you to come up with some visual methods for managing the supermarket.

Before we get to the actual solutions, let's spend a moment thinking through what questions we want our visuals to "answer":

Where is the supermarket?
Within the supermarket, which ingredient goes where?
How much of each ingredient am I supposed to have?
At the moment, do I have enough? Too much?

If you can think of other questions, add 'em onto the list.

OK, let's apply the visuals....

How about we paint a square on the floor for each of the four ingredients just big enough to hold the right amount of pallets? We label each square, either on the floor or with a sign overhead, as to which ingredient goes into which square. On our sign, we put how many pallets maximum and minimum are to be in each square.

Or we can store our ingredients on racks, label the racks, and color code the racks green, yellow, and red as to amount of inventory.

Or you might come up with a different approach. The point is, the visuals make it easy to manage the supermarket. Good visuals would allow us to take someone at random off the street and tell them, "Go find my supermarket and tell me what my schedule for making the materials should be," and they could do it. The goal, of course, isn't to enable folks off the street to run your shop. The goal is to enable you and your folks to make routine, process control decisions quickly and effectively.