Column Archive: 2010

Dear Gemba Coach,

We’re a tier two supplier and we’re trying to implement a pull system. We’re leveling our production schedules, but our customer’s variation in the demand for products immediately makes us miss shipments. Our OTD is not getting better. Although production runs more smoothly, people are getting frustrated. Where would you start?

 That definitely is a tricky question, and I’d start at the Gemba. Are your truck preparation areas all set up? The only practical way of guaranteeing shipments is to have the truck prepared in advance and in full. The first place to go is shipping, checking that truck preparations areas are under control. This means that for every customer destination, shipping staff need to understand: 

• Truck destination
• Truck departure time
• Preparation zone (where are the parts for this truck)
• End of preparation time (at what time the truckload should be complete)
• Status (are we ok or are we late)
• Comments (if we have missing parts, why?) 

As a Kaizen focus in shipping we should try to have all trucks prepared in full by the end of preparation time. The gap between end of preparation and truck departure is meant to be able to respond an emergency if a box is missing. Some would argue that we’re creating Muda of handling the parts as opposed to picking them directly in a warehouse and placing them in the truck, and that is the case. When we grow up we’ll be able to do so. But in the meantime we use the truck preparation areas to (1) visualize our mis-shipments, (2) be able to react immediately and fight for the completion of every truck, and (3) ask why? when a truck preparation area is missing crates at closing time. 

The next step is to wonder about how the parts get to the truck preparation area. If you’re running a pull system, then parts should not come from a finished goods warehouse, but from a shop stock on the line itself. The production line, Cell, or machine owns its own stock, and has a Supermarket of parts with dedicated lanes for high runners: A, B, C, and a general purpose lane for low runners, X. 

Parts are picked up from the line’s Supermarket by parts withdrawal Kanban. These Kanban instruct the train operator (or the forklift) that a crate of A has to be withdrawn from the shop stock and brought to the corresponding truck preparation area at the specified time. 

Time is specified by a leveling board. This is a big box with slots for Kanban cards. On the vertical side, the box is organized by destination first, and within a destination, by parts numbers – each part number has its own line on the board. If the same part goes to two different destinations, it can appear twice on the leveling box – each at that customer’s Takt Time. Horizontally, the board presents time-based pigeonholes in which the Kanban cards are placed – several slots for every hour. A truck preparation area should be consolidated from a start time to an end time. 

Learning by Leveling

This leveling board is like a bicycle crankset. It converts the pull from customer trucks into withdrawal on the line. Without a pull system, the MRP would order to pick up all the necessary parts at once on the line (in the finished goods warehouse, more likely). What the pull system does is consolidate the load in the truck preparation area at the same rhythm as parts are used on your customer’s assembly line. 

Why a physical leveling board and not simply instructions to the material handler via some electronic device? Kaizen and visualization, of course. The leveling box is a learning tool to teach us to do two rather difficult things: 

1. Consolidate truck loads to guarantee complete shipments
2. Transmit Takt Time to the lines to Level Production 

We need to learn to do this because it’s far from obvious. Truckloads are dictated by customer’s requests. In an ideal world, they’d be perfectly smooth, but we all know that customers change their minds constantly and at the last minute, so truck loads tend to vary a little in volume (most customers do try to fill their trucks) and a lot in mix (aaargh!). On the other hand, Takt Time is a leveling device: it’s the total daily operating time divided by the total daily production requirement. The production requirement is issued out of a leveled plan that averages out customer demand per reference and spreads it evenly by day. Basically, these numbers correspond more or less and we need to learn to manage this more or less ever more finely in order to 1) guarantee shipments as well as 2) maintain an even pull on the line. 

The assumption here is that customer variation is not that wild. Particularly when the customer is an assembly manufacturer, he’s got a plan as well, and although at tier two you might be experiencing a lot of spot demand variation, experience shows this tends to be created variation – variation created by the supply chain mechanisms themselves. 

The basic idea behind leveling the production plan is that what the customer has not picked up today, he’ll pick up extra tomorrow. Conversely, what he’s asking for extra today, he won’t ask for tomorrow. On average, customer demand for any part tends to be fairly stable, because (barring seasonality or promotions) market behavior tends to be stable. A given size of market will have a given rate of purchase replacement, and so will buy products at a given rhythm. There are all sorts of reasons volume varies from one day to the next, but the law of large numbers works in our favor. On large volumes, variation is actually quite small in percentage, and, more than anything else, it’s steady. 

The leveling board, therefore, represents first the leveled production plan – the weekly customer demand averaged by day – in order to pull smoothly and in small quantities on the production lines – but also needs to take into account the real customer order for this truck. The leveling board should visualize start and end of truck preparation. 

Waiting Pool

So if the customer orders more parts than the plan, where do they come from? Or if they order fewer parts than the plan, where should they go? Our assumption is that if they order fewer parts than the average planned, we will still build them. Certainly, this smacks of Overproduction, but the belief is that if the customer doesn’t want the parts today, he’ll want them tomorrow on top of the averaged demand – and we wouldn’t be able to deliver because of fully loading the production line. In essence these are not parts in stock, but parts in waiting for a delayed order. 

In order to learn how to deal with the discrepancies between the leveled production plan and the real truck order, we will start by visualizing the situation: we will set up a Buffer Stock, a “pool stock” in lean parlance which is not an Inventory, but a waiting area for crates corresponding to the variation of created demand. 

So, if the customer is asking for nine crates instead of ten today for truck number one, the tenth card will be placed in the leveling board, with a sign saying that the destination of the parts is not the truck preparation area (which is now complete) but the pool stock. Conversely, if the customer asks for eleven crates rather than the average of ten, the eleventh card will appear in the leveling board with an instruction to pick it up in the pool stock. 

Inventory sitting in this pool stock is tracked part by part with the Kanban cards, which get their own board. Variations in the pool are the key to understanding real demand and customers’ behavior. Part by part, the amount of crates in the pool stock should be fiddled with endlessly to stick as closely as can be to real customer behavior. This stock is not, well, a stock so to speak, but a tool to understand the real nature of customer demand. For instance, it should be distinguished physically from any Safety Stock, which is kept to protect the customer from fire, strike, machine breakdown or a comet hitting the plant. 

Handling the pool stock is not easy, but great Kaizen material. You’ll discover there are many combinations of things going wrong, such as trucks not arriving on time (or with no set schedules), parts going to different customers (and at different takt times: don’t put them together, but treat them separately), or not receiving firm orders until the very last minute (fill the leveling board according to the leveled plan, and complete it as new information comes in). But that’s the fun of it. 

At the Gemba, check that your leveling board actually reflects trucks. In practice, most people who Work with leveling boards are more focused on their impact on production (withdrawing from the line’s Supermarket), and not on consolidating the truck (and delivering exactly to customers). I suspect the key to unlock your question lies in using the pool stock to absorb the difference between the leveled plan and the actual truck load. Make sure the leveling board visualizes both dimensions of the problem and that the people in shipping understand the Kaizen they have to do on that matter, and I am willing to bet that your OTD will improve visibly.

Dear Gemba Coach,

We manufacture a seasonal product and are working on leveling, but are having a tough time. Our peak sales occur in a four-month time frame, but we need to use year-round production for capacity. Any advice on how to level what feels to us an impossible cycle?

Your challenge is difficult. I once visited a diary factory. We started at the beginning of the Process as I always do, and we walked through a huge, half-empty warehouse. To be more specific, half of the warehouse was full, and half of the racking was empty. I asked them whether they should not have, at this stage, half-empty racks all over the place and they just looked at me blankly. They had nine months to prepare for the diary selling season, so they’d release one type from design, produce it, store it and then move on to the next type of diary – which is why the half of the warehouse was full, and half empty.

What were their main problems? I asked. Well, they told me, we are late on own release schedule, which was a real worry because they sold through retail chains, and so if they lost the time slot, they lost the shelf positioning. And of course, they had forecasting problems because, for inexplicable reasons, the same types of dairies did not sell every year, and they were always left with large quantities of diaries to pulp. Hmm.

This is indeed a difficult question and one where I’d dearly wish to have a magic wand – clearly the leveling concept doesn’t apply naturally to a seasonal business. Or does it? It’s hard to be specific without knowing more about what you manufacture or your industry but we can take a step back and try to reason out how leveling might Work in case of a seasonal activity.

To start with, why level in the first place? You do so to build capacity and flexibility. Say you’re making 100 units a day. Demand increases 10% to 110 per day. You’ll struggle a bit, but you’ll cope without even considering changing the capacity of the Process. If demand suddenly increases to 130 a day or more, though, you have a real problem. You’re going to have to Work weekends, hire temps, train them, order more from suppliers, deal with parts shortages until the extra parts arrive, strain your equipment because there’s no more time to do routine maintenance, and so on. All of this will create exceptional costs that will eat significantly into your margins.

But how come production increased suddenly by 30%? Did customers decide from one day to the next to buy that much more than they did? Unlikely. Demand probably did increase but not in one day. Say we’re producing 100 units daily in June and decide that July’s plan should be 130. We’d know about it since the very beginning of June – sales must have picked up progressively. If we had been flexible enough to change the plan in, say, mid June, we could have moved to 115 parts a day on June 15 and 130 on June 30. More flexible still, we could have increased from 100 to 110 on the second week of June, to 120 on the third and to 130 on the forth, ready for July.

How would that make a significant difference? Ask yourself how many new temps a factory can hire and train to standard all at once. Or how many new parts you can get out of a supplier once they’ve shipped all that is in their stocks. Or what is the lead-time to get an additional machine on line. In production, lead-time is of the essence as we have a limited capability to do things all at once, but an infinite capability to do so one at a time.

Making Coats and Havoc

Most companies Work to forecast, and the forecasting cycle itself adds to the delay in responding to real market changes. Forecasts tend to be reasonably accurate in terms of total demand – we know historically what the market is like. But forecasts are very poor at predicting what customer preferences are in terms of mix – the weather is sunnier, people feel more cheerful, and start preferring wearing bright upbeat colors. Snow comes a bit early this year, and instead of buying elegant Indian summer coats, the rage is for the heavy duffle coat. The total number of coats is likely to be the same, but not the actual product type. This has a huge impact for production because although the total volume forecasted might be practically equal, on one given line or equipment wanting more As than Bs this can create havoc.

How does this relate to seasonality? In my experience, seasonal businesses rely more than others on their forecasts. The forecast cycle is usually long enough to encompass the seasonality: six-monthly, or yearly. Once the yearly plan is set, it’s very tempting to adapt production accordingly and optimize to plan. If the plan is wrong, which it always is, you’re in deep trouble with no easy way to get out.

For argument’s sake, say that you produce twelve variants of a product (A, B, C… L) and that, as you say, you mostly sell them over four months – like the summer season. January, February, March, April, May are off-season, then June, July, August, September are the peak sales, and then October, November, December are low sales again. As you need to produce all year long for capacity reasons, the temptation is to ignore the sales pace, and produce to forecast to fill the warehouse, and hope for the best when sales orders come raining in.

Typically, optimizing to plan would lead you to produce As in January, Bs in February and so on until Ls are made in December. In doing so you’re keeping your changeovers to a minimum and can focus on one product at a time. You’re optimizing the use of your production equipment compared to forecast.

From a lean perspective, however, you’re producing each type once a year, which means a lead-time of a full year. If come June, you find out that customers are, for whatever reasons, buying a lot more As than Bs, you’re stuffed, because you’ve already produced As and Bs, and should you decide to start producing As again to fulfill the sudden demand, you’ll have to postpone producing Fs scheduled in June. But in June, people are asking for some Fs as well – you’ve got some in stock from last year, but will they be enough? and so on.

On the Level

What’s the alternative? What happens if we produce all twelve types every month? Well, by June, when the season is about to start, we’ll have produced 70% of the total volume. We can now focus more on the models that are selling best this season. By producing every product every month, we reduce lead-time to a month and are that much closer to real demand.

Clearly, this example is childishly oversimplified, but I hope it highlights the reasoning. By leveling the volume forecast and trying to produce all products all the time, we can use the off-season to increment Inventory by small quantities regularly. When the season starts, we have a cushion of products in Inventory – if we’re experienced, this cushion is the baseline that sells every year, the expected minimum for every product type, and then we have the flexibility to produce the models that actually sell when the peak season arrives.

Back to the first point, if one type starts selling like hotcakes, we can progressively increase the demand on the supply chain without changing the forecast at the last moment and going to the factory and suppliers saying, “you know what, fashion experts tell us that red is going to sell like crazy this year, so please double the volume of the red ones, for next month.” By (1) building all types stocks progressively through the year and (2) increasing our flexibility accordingly, we can (1) have a mattress of each type that should sell no matter what and (2) the flexibility of following real demand during the peak season.

Which brings us, not surprisingly, to the real bottleneck of such a strategy: our Changeover capability. As long as changing batches in production is not studied, reduced and under control, building Inventory by producing a little bit of each type every day is in jeopardy. One rule of thumb is that you invest 10% of your capacity in flexibility so batch sizes are calculated at ten times the Changeover time. If you want to make every product every day, which is kind of the lean first goal, you need to reduce Changeover time accordingly.

A further advantage of building a little bit of each type frequently rather than once a cycle is that you can Work on standardizing operations for each type simultaneously. If you only build one model at a time, people will solve all the issues while they’re building As, but will forget about all they’ve learned about As when they start on Bs, and so on. By the time they’re doing As again, it’s like starting from a blank sheet. Producing A, B,.. L frequently will keep them focused on keeping up standards for all products at all times, which will come in extremely handy when real demand kicks in, and we finally find out which model we need to focus on.

Human nature being what it is, your planning and production colleagues will probably mock you for suggesting that although your building up Inventory for eight months in a row, you should produce as if sales were regular week by week. You’d be using your warehouses as a perfect customer. If you were in the toy business, for instance, your warehouse would “purchase” from the production plan as if parents averaged out their Christmas spree for their kids over the year on a monthly, even daily basis. It’s laughable.

Yet, what you’re doing in practice is build up the production sites and supply chain’s ability to change. By changing frequently and building a little of each one every week, the manufacturing system learns flexibility by practice. Consequently, when that flexibility is really needed because, in the sales season, customers never behave according to forecast but do their own thing – and surprise you – your processes are ready and able to change. This ability to change will then protect your profitability by keeping the exceptional costs of flexibility down to a minimum, and your production installations running close as can be to nominal capacity.

Dear Gemba Coach,

In the webinar, you’ve defined LEAN = Kaizen + RESPECT. Isn’t it simplistic? Is that all there is to it? What about TPS?

Thank you for asking this question and giving me the opportunity to clarify. Of course, there is more to lean than Kaizen, you are right. TPS does stand out. Many companies have continuous improvement programs in one shape or form, but few have developed it to Toyota’s extent – or had the results Toyota did from it. So what did Toyota do different?

To a large extent, I see lean as a system to support individual Kaizen. As John Shook pointed out one should not confuse Toyota’s system of production with the Toyota Production System. One is the sum of Toyota’s actual shop floor practices and the other was originally defined as “a series of related activities aimed at the elimination of Waste in order to reduce cost, improve quality, and improve productivity” (in Art Smalley’s translation of Taiichi Ohno’s introduction to the very first TPS leaflet).

Whereas many companies do “open-eye” Kaizen (look around and if you see something that needs fixing, do so), or savings related Kaizen (the essence of six-sigma with a clear business benefit per project), Kaizen in lean is directed by the principles of TPS. The aim is complete customer satisfaction in terms of quality, delivery and cost, and to do so we need to improve (1) our Jidoka – spotting a defect, stopping and fixing the problem right there and then, and (2) our just-in-time conditions – essentially getting closer and closer to Takt Time by leveling, pulling and producing in single piece flow, by (3) getting operators involved in redesigning their own workstations through standardized Work and Kaizen. In essence, TPS specifies which kind of problems to solve through Kaizen.

Getting People to Think for Themselves

I’ve been collecting Ohno anecdotes over the years and I’ve come to believe that TPS is the codification and enrichment of a few strong intuitions Taiichi Ohno had and strengthened in his time on the shop floor. These intuitions – obsessions, one could probably say – are distinctive and, I believe, sent the whole lean movement through its specific evolutionary path. This is not unlikely, as industry has been grounded in other strong men’s intuitions such as Taylor’s obsession with measuring every single thing (the legend has it that he timed himself to the train station everyday), which created single-handedly the entire science of Work measurement, or Ford’s obsession with standardization of parts and processes which led him to revolutionize industry with the black Ford model T.

Whereas Henry Ford was driven by organizing Work for people, complaining that every time he hired a pair of hands a brain came attached to them, Taichii Ohno had a radically different obsession, constantly illustrated in his shop floor practice and which is probably at the root of the paradigm change Toyota initiated: he wanted people to think for themselves.

As anyone who has tried will testify, this is not necessarily easy, and Taiichi Ohno did so in an inimitable style that terrified his co-workers and has created his legend. He would basically yell at them to push them beyond the obvious answer, force them to stand in front of a problem until they saw it, and put them under constant pressure to do something quick. He gave problems in the morning and came to check something had happened in the evening. He gave problems in the evening and came to check people had moved in the morning. But he never gave an answer. And when he did give hints, he berated people for not thinking beyond his own advice. He was constantly pushing every one from shop floor workers to managers to think for themselves. Whether he’d learned it from the Toyodas or whether it was a personal quirk, teaching employees to think for themselves is probably what distinguishes lean most clearly from Taylorism.

Reveal your Mistakes

Ohno’s topics for mental torture where not random – he had a few pet subjects, which, in time, morphed into the pillars of TPS. The first huge bee in his bonnet was about not hiding mistakes but revealing them so that you could stop right away, ask why? and fix it. Having struggled all my working life with teaching people to use red bins and use their mistakes to improve, my personal favorite Ohno story (maybe apocryphal) is the one where he asks a colleague to pick up an empty box and follow him for his shop floor visit. After a while, as the terrified and mystified young man follows Ohno around carrying his empty box, Ohno starts berating him for not seeing the bad parts hidden under shelves or lying at the foot of stations. The guy then had to pick up the hidden defectives and carry them in the box. At the end of the tour Ohno asked him something like “why are you following me around and not fixing these problems?”

I was in one my favorite plants yesterday and they’ve been doing lean for years in the right spirit – and getting the results. The production manager has now instigated “one day Kaizen” for each production Cell and was showing me what they’d done in one Cell. I pointed out a part lying under a workbench and he said – “Yeah I know about this one. It’s a defective and I asked them to hang on to it so we could examine it together.” I thought about Ohno’s box – don’t hide the bad part. Build an altar to quality and place all your bad parts there, so that everybody can see that it’s okay to reveal mistakes.

Never Overproduce

The other topic that drove Ohno wild was Overproduction. There are endless stories of inventing switches to turn off machines if they went faster than takt or giving people a very hard time when they had too many parts standing idle after their Process. He saw Overproduction as the root of all the main wastes and repeatedly insisted in visualizing and stopping Overproduction – as well as restricting space for overflowing ahead of schedule Inventory.

As with “reveal your mistakes and react at first defect” this message is as valid today as it was half a century ago. I was in a factory recently where the only way to get machining operators to see Overproduction was to forbid them to send parts to the warehouse. The operations manager imposed a “you make it, you keep it” rule which, at first, filled machining with crates of unnecessary parts, until the supervisors learned to only produce what was needed. This, of course had a dramatic effect on WIP (in a good way) and on capacity (in a bad way), and became the basis for a sustained SMED effort.

Reduce Headcount

The fourth obvious Ohno obsession is headcount. The Ohno legends have him forever pushing people to get the same job done with fewer operators – without making them Work harder. Finishing a headcount reduction Kaizen generally only meant being asked to do so again, and again.

It turns out that reducing headcount is one of the best ways to get middle-managers understand the reality of variation in the shop floor as Manpower, Materials, Machine, and Method issues crop up all the time. Furthermore, reducing headcount is also a great lesson in improving again and again. I’m always surprised that the fourth workshop on the same area still yield between 10 to 20 headcount reductions – sometimes forcing you to think radically differently about production.

The Challenge of 100*1% Rather Than 1*100%

It is clear that Ohno was aware of both emotional aspects of change: it is simultaneously exciting and scary in widely different proportions according to the individual. Ohno would on the one hand set apparently impossible challenges for his juniors, as well as have the cool-headedness and resilience to accept the step-by-step reality of Kaizen.

At one point he explains why he did not instruct some workers to apply correctly some TPS element or other: “I am being patient,” he is quoted saying, “I cannot use my authority to force them to do what I want them to do. It would not lead to good quality products. What we must do is to persistently seek understanding from the shop floor workers by persuading them of the true virtues of the Toyota System. After all, manufacturing is essentially human development that depends heavily on how we teach workers.”

Ohno’s fixations are important because lean folk can sometimes miss the trees for the woods, so to speak and get so involved with the ins-and-outs of TPS that they forget what it’s all about. As Hajime Ohba once colorfully put it, it’s easy to create the Buddha image and forget to put the spirit into it. Lean is the finger that points at the moon – individual Kaizen to develop skill and understanding – and it’s easy to look at the finger rather than the moon. To cultivate the lean spirit, my experience is that mimicking Ohno’s obsessions is good practice.

In the end, I believe that Ohno’s quote sums up it all. As I see it, lean is a system to get every employee to redefine their job as Work + Kaizen, and yes, you’re right, if I was to write the full equation I’d have to say that LEAN = TPS {Kaizen + RESPECT}

Dear Gemba Coach,

The head of the lean initiative in our company has left and they gave me the job. I’ve been asked to review our current approach and propose a way forward. I’m a Gemba gal and not sure about how to go about it. Would you have any suggestions?

 Well, the Gemba certainly is a good place to start. Here’s how I would go about it. First, clarify the problem. It’s important to recognize the purpose of any lean effort from a Gemba perspective. That’s because lean initiatives can range from shop floor activities (usually workshops) to suggestion programs, standardized Work training, quality circles, or any other way to organize Kaizen for frontline workers. So start by asking the following three questions:

1. How do the outcomes of these activities relate to the firm’s bottom-line?
2. How do we sustain the results of these activities?
3. How do we progressively increase employee’s commitment to these activities?

I’ve found that any Kaizen Workshop on the Gemba that can’t figure out clear answers to these three questions is in deep trouble. Without a clear sense of purpose, it’s inevitable that management will tire of the program and want to move to the next best thing (de-motivating all the people who have committed to it, and giving reason to the cynics), or that the employees will soldier on or resist the Kaizen activities because they feel there’s nothing in it for them. This risks turning the entire initiative into a bureaucratic rain dance of counting how many workshops and training are done without any real impact on the business – a story that rarely ends well.

 The Business of Lean

The two pillars of lean management are: first, continuous improvement, which is challenge, go and see and Kaizen. And second, respect for people: teamwork and respect. Can we e this framework to shed some light on our problem?

What is the challenge of the program? In practical terms, what are the key results we need to achieve? I find it strange that many lean efforts are unclear on this front, which makes it difficult to say whether they are successful or not. As long as we’re not able to express clearly what we’re trying to achieve in terms of significant improvement of a few KPIs, we can never be sure of what we’re trying to achieve. Here are some specific examples of explicit challenges that Work:

• Halving Work accidents every year until we reach zero
• Halving customer complaints every year
• Reducing Inventory by 20% every year
• Improving productivity by 15% every year

And so on. These would be typical lean challenges, you can tailor yours to your company’s issues. For instance, absenteeism can be a huge issue, or capex. The key here is to relate the lean initiative to the business model and figure out how lean practice can help the business to flourish.

Gemba Savvy

After becoming clear on the results part of the challenge, we can now apply Lean Thinking to the learning challenge. Say that you want to cut down your customer complaints by half (if you already knew how to do it, you’d have done it a long time ago).

Customer complaints occur as an outcome of certain things we don’t know how to do well, such as stop defective products at final Inspection, or control the assembly Process and so on. In order to deliver on this result, we need to have a good idea of exactly what it is we need to learn. This is where being Gemba savvy helps considerably. In many cases, such as customer complaints, seeing what the company needs to learn is already a challenge. In this case, the lean tools are a great way to “clean the window” and figure out exactly where we’re going wrong. This is not an intellectual exercise. There’s a lot of Kaizen and Gemba Work to do to get it right and be definite that if the company learns to do X better, then we’ll get the order of magnitude of expected results. If we’re not constantly worrying about whether we’re working on the right problem or not, we can expend a lot of shop floor efforts and have little to show for it.

Having figured out what the results challenge is and how this translates into what specific things the firm has to learn in order to get these results, we must now map out how we’re going to train all employees to do this.

The answer, typically, is standard Kaizen workshops. For instance, say we have a productivity problem in assembly operations, which is the closest case to the birth of lean in automotive assembly, then we have a standard flow and layout workshop which has been perfected over decades: 7 Wastes, clocking of operator cycles, identification of variation and calculation of Takt Time, Work content and true potential, brainstorm to eliminate causes of variation and balance the line, follow up implementation and so on.

This standard Kaizen Workshop has spectacular results when done well and so-so results when done poorly. Above all it must show frontline staff how to achieve greater productivity (although, if management is not involved, the good ideas put forward can remain wishful thinking, particularly in the area of Cell logistics). The key here is to turn the overall learning challenge into a Kaizen learning by doing challenge.

Go and See

Finally, once you’re clear on your results challenge, the corresponding learning challenge, and how to get every employee to learn through standardized Kaizen activities, all that remains is to make sure you have a robust checking mechanism to make sure that you’re getting the expected results because (1) you were right abut the learning challenge (2) the Kaizen are delivering these results and (3) at a sufficient pace to train enough employees quickly enough to deliver the needed orders of magnitudes in results.

‘Go and see’ is an essential part of the clarification Process. By constantly verifying whether the outcomes of our efforts deliver the qualitative and quantitative results we expect, we also refine our results to learning lever points to Kaizen vision, which makes it more effective.

To answer your specific question, the first thing I‘d do would be to use your Gemba experience to clarify:

• What results are expected from the lean initiative and how do they contribute to the business model (and bottom line)?
• What learning “lever points” do you need to focus on in order to deliver those results?
• Are the Kaizen activities aimed at training all employees to improve on these lever points?

Being clear on this logic chain is essential to both the effectiveness of the program and its sustainability.

Pillowcase Syndrome

However, lean management also highlights a second pillar: “respect-for-people,” or in more mundane terms, people involvement. There are two issues here that are fundamental to any lean effort. First, a company is an integrated Value chain so, in many cases, working on just one link only shifts the problem further on. For instance, trying to stabilize production without focusing on planning and logistics isn’t likely to get you anywhere quick. A common ailment of lean programs is the pillowcase syndrome: you squeeze one end, and it bulges on the other. For instance, having a forceful program to pull people out of the Process through flow-and-layout workshops without the equivalent HR program to figure out how to take the equivalent number of people out of the business WITHOUT punishing the people who have been involved in the Kaizen (usually reducing reliance on temp workers) is asking for trouble.

Let’s ask ourselves the three main questions again. In order to get the expected results:

1. Which main functions have to learn to Work together?
2. What learning platform will we create to make them do so?
3.  How do we Kaizen this so that they actually learn?

A good example is the weekly production plan. This is where I tend to start in most cases, by creating a weekly meeting where planning, logistics, production, procurement, and HR come together to solve a specific problem: a leveled production plan for the week that will then be signed off in blood. This means that they have to collectively solve two problems:

• How to fulfill customer demand with the leveled plan
• Identify the risks to holding the plan (machine breakdown, for instance) and determining an alternative plan beforehand so that we can still stick to the plan (Subcontracting the parts produced on the machine that is down? Quicker maintenance?)

As the team meets and learns to Work out these issues (and as a consequence their internal issues), I ask the planner in charge of the meeting to keep and update an A4 sheet of planning “rules” which need to be constantly kaizened.

Many other such teamwork “platforms” can be created throughout the company. One other instance is a “slow build” workshop: when a design comes out of engineering and all the prototype parts have been sourced, production operators can be asked to assemble the final product in the presence of engineering, manufacturing engineering, quality, production, purchasing and so on, to finalize the new product and put together a proper manufacturing plan. The goal here is zero engineering changes after launch and there are, as you can imagine, many opportunities for product Kaizen.

Last but not least, employee involvement. If your program is not purposefully designed to produce increased mutual trust, it is not likely to succeed in the mid term (beyond the early infusion of energy and low-hanging fruits). On this front as well we can ask ourselves the same questions

1. Which people should we address in order to get the results we need?
2. Are we clear on what “wins” they each will get out of the Kaizen activities?
3. Is every activity reinforcing mutual trust, or creating disappointed expectations?

Who Wins?

Let’s take again the flow-and-layout example. In the ideal case, the Kaizen Workshop will deliver (not necessarily in this order) (1) a productivity gain for the company which feeds into the cumulated “heads” win to create the aggregate productivity improvement target, (2) a Work win for the operators on the line who now should have easier working conditions and participated at fixing their line in the way they wanted it and (3) a personal win for the person on the line that is pulled out because this will be a career move upwards: Team Leader on another line, a technical job, something they wanted and they worked for by involving themselves in improving the line they’re now leaving.

Without a clear idea of “who wins what” in the lean initiative, the program can easily flounder in the swamp of poor industrial relations. For instance, usually the Kaizen Workshop is only the first step of improving the situation. More often than not, the Kaizen Workshop highlights many issues that need to be resolved. Without an attitude of “problems first” and without thanking operators for pointing out problems and working hard to resolve them, much of the gains surfaced during the workshop won’t materialize. We will have destroyed trust rather than created some (typical management, they ask us for our opinion and then ignore it), and we’ll have further embattled our middle-management in their “nothing can be done or ever changes in this company so keep your head down” attitudes.

I don’t know whether that’s any help, but I do believe that the Gemba perspective is a key to having an opinion on the full program. At the Gemba, we can start figuring out:

1. How clear we are on the “results to learning leverage points to Kaizen” chain;
2. Whether this mental chain is clear on operations, and on teamwork and developing mutual trust as well.

Verifying and refining this chain of thoughts is an essential activity on the Gemba: are things working out the way we’ve planned them? Are we doing the right thing? Are we doing enough of it? Which is a key ingredient to success with your lean initiative.

How Do We Help Our Plant Managers Want to Do Lean?

Dear Gemba Coach,

We've just changed our divisional general manager and the new boss wants our lean approach to be less directive and more participative. That is to say, our plant managers should want to do lean instead of feeling that they are being forced to. This is a big change from our previous boss. Any advice on how to handle this transition?

"The largest weakness of the Toyota Production System (TPS) is that it relies entirely on the plant managers," is the first thing my father Freddy was told by his Toyota Sensei when he became CEO of an automotive supplier. A more positive (and less Toyota-like) way of saying this is that lean transformation relies on the plant managers, a fact that has been proved time and time again. So how do we motivate plant managers to carry on with lean activities and to develop their own brand of Lean Thinking?

My father's recipe was a blend of fear, support, and clear direction. In any case, that's what the plant managers remember more than a decade later. They were terrified by the budget sessions and the CEO Gemba walks: they felt their job was constantly at stake (which turned out not to be true: although several plant managers left pursuing other opportunities, he only actually fired one). They respected him because he never left them to face the music alone, and he spent hours discussing their problems and guiding them to solutions without narrowing their autonomy. But what they most remember as a golden age was the clear direction: they knew where they had to go, and even in the face of specific issues with customers, suppliers, or other problems, he never avoided addressing the long-term problem as well as getting an immediate reaction. In hindsight, this is where the cookie crumbled: the plant managers who believed in the long-term vision flourished (regardless of their implementation difficulties – they learned), and those who thought this was just automotive business as usual, trying to respond to every event tactically, ended up leaving the company.

Now that he's taken on the role of Sensei, we have frequent discussions about how to get plant managers to practice lean. The fundamental problem he sees is that the essence of lean is creating problems for yourself, pushing yourself in a corner, and working at it until you find a way out. Very few plant managers are up to doing that on their own volition (usually very experienced guys with nothing to prove). The day-to-day reality of any plant manager is that problems keep raining down, and pressure from both the top (more results, more reporting, more everything) is only paralleled by the endless stream of things going wrong on the shop (quality issues, Downtime issues, supplier issues, personnel issues, etc.). No plant manager needs any more problems to keep occupied! It takes a strong hand to get plant managers to accept focusing on yet more problems, and worse, not solving them by a quick workaround, but doing the Work of discovering root cause and training their people to Work it out. His position is that if you don't push very hard, the plant managers won't even pay attention.

True Lean or "Rain Dance"
On the other hand, he concedes that lean system implementation based on pure authority leads to a travesty of lean: the plant managers will implement the system to look good and avoid punishment, but have no incentive to actually solve the problems. How many pull implementations have we seen where shop stocks remain empty, red bins are overflowing, production analysis boards blank and so on? All the pieces of the system have been implemented forcefully, but none are used by the people to solve the underlying problems – they've just added one more layer to the plant's management system and shrug as they fill one further batch of "lean" paperwork. Without building relationships of constant support to get the plant managers to face their problems and solve them in a lean way, the lean activities will remain a ritual rain dance without any transformative power.

"Directive vs. Participative" is not a frame I'd apply to lean, as senseis and lean managers tend to be both directive ("you'd better tackle this problems and show me progress") and participative ("let's hear how you intend to do so – go ahead and let's see what happens") at the same time. But there definitely is a problem in terms of being pushy enough as a boss to get the plant managers to pay attention, considering all the other pressures they're under, as well as determined to develop their autonomy in both having initiative of seeking problems by themselves and figuring out their personal path to solve them. The way lean essentially works is:

Lean systems highlight problems
↓
Plant managers solve the problems with their teams
↓
Lean systems can be applied in greater detail
↓
That will reveal problems previously unseen
↓
That will have to be resolved, again and again

After a couple of years of this regimen the plant should look radically different: the lean systems are implemented widely and the tools are used in detail and performance has significantly improved because managers and operators have learned how to run processes more precisely. The main issue is that (1) applying a new aspect of the lean is Work and requires willpower and brains, (2) solving the problems it surfaces is Work and requires willpower and brains and (3) doing it all over again is yet more Work and requires willpower and brains. It's a tough sell.

Checking Baggage
I'm assuming from your question you're a lean manager and have to come up with a proposal for the new divisional manager on how to roll out lean activities. I don't have any specific advice but maybe we can frame your problem a bit better. If we go by the previous chart, this is a lot like teaching math to kids in school: you've got to teach them the tool (how to solve a problem) and then get them to apply this tool to an increasingly difficult set of problems, so that you can move on to the next concept and tool and tackle more difficult problems until you're doing path integrals and solving quantum physics problems. However, we're not dealing with kids but adults, and we have to do this in an organizational culture setting, not at school. So, what do we know about adult learning and cultural learning?

The main difference between teaching adults and children is that adults come with their own baggage: the cup is already full, so adding more knowledge to it is not going to be easy. Because they know what they know, in training adults we need to pay attention to different things:

1. Make it worth their while: Whatever we try to teach them has to be immediately relevant to their current issues — adults need to see a rapid and relevant benefit (because of all the competing demands on their time). In this sense, pointing a gun to the plant manager's head does focus the mind wonderfully, but you also have to choose areas where they can see progress and where they believe this will bring them a real and present benefit.
2. Give them autonomy: Whether they're right or wrong, adults know what they know, and you can't change that anymore than they can ignore their experience. The learning mechanism has to offer initiative in what issues to tackle and leave open how they intend to do so. Of course, this doesn't make teaching easier because you're there to teach how to solve this problem this way, but that's where the Sensei skills are essential.
3. Make it practical: Grownups enjoy heated debates about theory and concepts, but are notoriously poor at translating any of this in practice. Any actual learning occurs on a very hands-on, practical level. As my father's Sensei said, quoting Ohno, "Look with your feet, think with your hands." Workshops are the basic learning tool of lean because classroom teaching has very, very poor returns for adults.

Cultural Learning
Setting aside the directive/participative debate, how does your lean program check on these three dimensions and how can it be improved? If the program is too loose, nothing much is likely to happen because the plant managers have many better things to do with their time, but if the program is too based on applying corporate standards, learning will not occur either. No, at the risk of sounding like a parody of a Zen: neither too tight nor too loose.

Learning never occurs in a vacuum. Kids are taught math in the classroom, within the specific context of the school and in the wider culture of national education and we all know there are good schools and bad schools, and cultures where learning is more valued than others. Similarly, lean activities do not occur in a vacuum but in the context of a specific organizational culture. So, what do we know of cultural learning?

Unfortunately, not a lot – this is, oddly enough, a nascent field in anthropology and it's hard to find any authoritative voice on the topic, but certain key ideas seem to emerge. For the sake of argument, let's think through the three main aspects of cultural learning:

1. Role models: A culture, as a whole, is greatly influenced by a few individuals, a few stars, which have a disproportionate of how everyone else behaves. Although no one voluntarily copies star behavior, this still defines the envelope of permissible or advisable behavior. Certainly, in organizations, the behavior of the CEO and senior executives has a disproportionate effect on the rest of the troops. This is why most experienced lean guys will insist on a CEO's personal involvement — without it, rank and file is unlikely to follow.
2. Space to make mistakes: If the cost of mistakes is too high, experimentation stops. For instance, very tough bankruptcy laws in some European countries completely smother any entrepreneurial drive: the price of failure is just too high to pick yourself up and start over again. Learning occurs faster in cultures that are relatively tolerant of mistakes, where individuals can take risks in attempting to do things differently. This feature is also very strong in the lean movement as interesting failures are explicitly viewed with favor. "Stop the line" is a uniquely advanced form of hard-wiring the positive aspects of mistakes.
3. System of symbolic meaning: At the culture level, people create, remember, and deal with ideas as well as practice. To a large extent, culture can be seen as the set of ideas a group of people transmit and evolve (many of these ideas are concerned with defining what is a problem and what is not – human driven climate change? – and what is an acceptable solution or what is not – carbon tax? Cap and trade?). A clear system of symbols is a strong vehicle for cultural learning, whether bible studies or Euclidean geometry. Lean is very well favored in this respect as the TPS provides a strong symbolic system (as does Six Sigma, for that matter).

Time for Reflection
As with individual learning, how does your lean approach rate on these three dimensions and what can you do to reinforce these aspects: how can you entice senior execs in greater personal involvement? How can you create space for (not too costly) mistakes by permitting (interesting) failures?

Change is never easy, and not easier for lean managers than for plant managers – why should it be? But any change is an opportunity for Hansei. For what it's worth, my advice is to take the directive/participative question seriously and return to the roots of your lean initiative and why it got to be the way it is. Bottom-line is that if you can't find something the new general manager is comfortable with, lean Work will stop, period. The challenge is not to dumb down what you were previously doing, but to take this opportunity to reflect deeply on your understanding of teaching lean to plant managers and to lay new plans to move forward.

Dear Gemba Coach,

We’re having an internal debate about how to involve the quality department and how to use “red bins.” Any advice?

I’d have to know more about the specifics of your company to write a meaningful response, but I can share a Gemba story of a plant that struggled long with the Red Bin concept.

But first, let’s go back to basics: what do we want to use Red Bins for? The aim is to build in quality: no bad part should make it past the Process that produced the defective. To do so, the lean approach is to stop and react at every defect, for two main reasons. The first is to train every operator to recognize in detail a good part from a bad part. Second, the only practical way to understand what goes wrong in the physical Process (e.g. how the machine makes a bad part) is to catch the equipment as it is making defectives in order to have a closer look when figuring out what is going wrong. A murder case is much simpler to solve when you catch the assassin bloody-handed. Having to investigate after the fact is much harder (and takes much greater investigative skills).

Now, back to the Gemba. This plastic injection plant heard about red bins from the corporate Sensei, which triggered a heated discussion. From a previous application of “lean” (no joke), they had invested in regrind equipment right next to the presses in order to avoid going through a “Monument” regrind machine and to ease the “flow of regrind back into molding”. Installing red bins to isolate bad parts was a problem because it created a break in the defective-regrind-re-use flow. Plus, the red bins would quickly overflow if the parts “stagnated” there waiting for Inspection. The next question was, of course, why they did they have so many defectives in the first place? But you start where you start.

The main issue was that production and quality managers had agreed to tour all the red bins once a day, but this turned out to be difficult to do in practice. The quality manager then intervened with a forceful solution. He lined the red bins with plastic bags that gathered all the defective parts. When full, the bags were taken to a meeting room, cleared for the purpose, where the quality department would inspect all the defectives and create Pareto charts. This action triggered a surprising but quick improvement in good parts throughput: it turned out many of the “defective” parts gathered in the red bins were actually OK parts. The operators had gone into the habit of clearing the parts that accumulated on the conveyor (if the operator walked away from the station, for instance) straight into the red bin. More stringent guidance on what was a good part and what was a defective gave the plant immediate quality results.

But now the quality department was swamped with defectives to analyze. Furthermore, the actions on the head of the paretos didn’t seem to improve the overall quality performance of the presses. A queue progressively built up in the defective room, which had then to be organized as FIFO lines and all sorts of clever ideas to cover for the fact that there were not enough quality operatives to both check every defective and do the rest of the quality job. (One thing they did spot is the negative impact of regrind on quality)

The plant manager finally joined the fray, and decided to lead personally the daily red bin review – tasking production and quality to do the same on the other two shifts. With this system, the defective parts stayed in the red bin at the machine, were checked once a shift on site, and gathered at the end of the shift into a central area for regrind. The plant manager had agreed with the Sensei to pick one type of defect per visit and get it solved. This quickly generated an immense action plan and triggered the involvement of engineering in the red bin reviews, but also, over a couple of months, had a spectacular impact on the plant’s overall quality level. Rather than tackling the “biggies” they had hitherto failed at solving, engineering and maintenance attacked many small things to bring the machines back to standard, and, fortunately, it worked. Still, the focus remained on “problem presses” rather than trying to understand how people were making bad parts

The shop was organized by areas with a press technician in charge of four to five presses. An operator stood behind each press to finish the part and pack it, but the operators reported directly to the shop supervisor (as did the technician) and the technician’s responsibility was limited to the machine. Life on the Gemba being what it is, the technicians skillfully avoided getting involved in the red bin review, and the supervisors’ attendance was spotty. It was perceived as yet another management fad to avoid confronting the fundamental truth: the presses needed significant investment to function properly.

In order to get the technicians involved, the Sensei then suggested creating a “marketplace” for each technician: one central area where the parts in the red bin would be categorized, right there on the shop floor, according to defect type. The new Process was now that when the operator spotted a defect, he or she would place it into the red bin and call the area technician, who would then inspect the part and take the defective to his own personal marketplace where he would sort it by defect type – the red bin review by management would include both red bins at the press and each technician market place.

This is still a far cry from stop-at-defect (injection presses are notoriously awkward to stop), but it did create a platform for discussion between quality, supervisor and press technicians, which did contribute to drive the number of defectives down further. One thing that appeared is that the head of paretos at plant level were not reflected by the heads of the physical paretos visualized by the market place. Issues where far more localized than expected – hence the difficulty to resolve quality issues at the plant level.

The sad part of the story is that the plant did improve and get out of the red (at the start the cost of non-quality was greater than the plant’s budgeted margin), but the group did not, and it got taken over in difficult circumstances and I lost contact with the firm – so I can’t say whether they continued to improve both their quality performance and their Jidoka.

So here’s the thing: there is no one way to divide labor on quality between production, quality, maintenance, engineering – it is all dependent on the personalities and competences of the people in house. Quality, probably more than any other subject, rests on good teamwork. The key is to keep focused on the “North Star”: how close are you to getting one by one confirmation of the parts by the operators, and to conduct root cause analysis on every defective part. I realize this sounds like an impossible job and the closer you get to the mountain, the larger it seems. But that’s not the lesson I’d like to take from the previous plants’ efforts. Every time they tried something, it was kinda silly at first, and “far from the path”, but still, quality improved steadily and they learned, slowly, painfully, but steadily. Three to four years down the line, this plant’s quality performance was a benchmark for the entire group (corporate could never figure out exactly how they’d done it).

As you debate with your colleagues the specifics of what you’re trying to do with the red bins, take the time to discuss what you aim to do with the “Red Bin” tool: what do you want to achieve, how would you describe a successful Red Bin implementation. And then go back to what is practical in your current situation. My guess is you’ll find that much of the debate is fueled by departmental turf quibbles about who is in charge of what and who has the resources to do what. By focusing back on the operators and the capability to identify the root cause of every problem at every defective parts, you’ll (hopefully) be able to overcome the functional perspective and create, with your colleagues, an ad hoc Red Bin Process that will both give you immediate quality improvements, and teach you some more about how to build in quality into your operations.

Dear Gemba Coach,

Isn't Follow the Learner a story of improvement without a Sensei? That isn't to say the journey described wouldn't have been faster with a Sensei, but Dr. Bahri's practice has been successful.  I often wonder how senseis skip to new areas--from the shop floor to the back office, or to healthcare.  Is this leap something that makes experience a handicap?  Or, at least, something that neutralizes experience because of the different environment?

This is an interesting and important that question I get asked often. I believe that Sensei questions are critical to understanding lean practice because I see “lean” essentially as a learning method (in which people use the discipline of eliminating Waste systematically as a way to learn more about products, processes, people and how to make them Work). Consequently, the teacher/student relationship is a core dimension of lean. Now, while determined individuals can learn mathematics or Tai Chi on their own, through trial and error, there’s no question that having a Sensei helps enormously. In fact, when you look at high-performance individuals in any activity from sports to business, I believe you will find that the more advanced the student is, the more coaching they get – not the less.

How does this Work at the Gemba? To dig deeper I asked this question of John Bouthillon, the CEO of a family-owned construction company, who I know. He made the leap from book learning to working with a Sensei, and when he picked a Sensei he chose one without any previous experience in his particular industry. Here are his thoughts:

“I have been working with a Sensei for almost three years now, in an area he didn't know at all. I was looking for a Sensei whose expertise was in lean itself, as opposed to my particular business, since I believe that Lean can be applied to any field of activity. In other words, I was looking for a Lean Sensei, not for a Lean Construction Sensei.

If you are looking for someone who can change your company, you should pick someone who knows your company's business. But, if you are looking for someone who can help you change your company yourself, then I would recommend finding a specialist in change and in people, a personal teacher (a better definition of a Sensei).

This type of experienced Sensei can help you understand how change can be made, how it can be made faster by raising your understanding of Lean. The faster you go and succeed, the better the Sensei.

This Sensei will:

• teach you to see and understand your problems before (and instead of) imposing solutions. He will push you to ask if you are working on the right issues .
• teach you to learn from your experience (PDCA). The question here is: What does a decision I make mean? What hypothesis am I testing? How can I do the "Check" ?
• teach you to change your behavior, to act in the same manner that you speak and believe  (put customers first, go to the Gemba, practice 5 Whys - not 5 whos, respect people...)
• do all this as fast as you can do it well (challenge).

I believe that the more experienced the Sensei, the higher the chances of success. It might even be that by changing areas the Sensei has to go back to basics, must avoid shortcuts and gains more experience than by staying in the same business he knows. But this is pure speculation, because I am not a Sensei...”

I recently visited a company that is trying to do lean without a Sensei. Although they are doing good Work they still encounter the usual problems that plague many lean efforts. Workshops improve the local situation spectacularly but (1) the improvements rarely last and (2) they don’t generalize to the point where it has an impact on the budget. In this respect, companies often make two typical errors in their approach to lean:

1. They see it as a stabilization tool – trying to standardize and rigidify every Process – and miss the fact that it’s essentially a dynamic approach, which brings standardization as a result of problem solving, not the other way around. Lean is indeed about learning to change: a change directed towards a lean ideal and not a random walk, and a gradual small step by small step change rather than break and rebuild, but rapid and constant change nonetheless.
2. They adapt the lean tool to their situation and pull its teeth out. Clearly, some adaptation of the tools is necessary (for instance, to construction as opposed to automotive or healthcare) – but this adaptation has to be very cautious. The aim is to make the company leaner, not to water down lean. Many of the tools have evolved through half a century of lean experience and are the way they are for specific reasons. Local adaptations are often nothing more than workarounds – something in the tool was too hard to implement (the learning point), so the tool was changed so that it could be implemented, but now without the learning benefit.

Getting Better
How does a lean system Work? First you implement a tool, which will not do much in itself other than reveal a problem. Second, the people who run the Process figure out how to solve the problem. Third, you either (a) use the same tool again more rigorously to visualize more of the fundamental problem or (b) you implement a second tool to attack another issue. Four, people learn to solve problems more rigorously, using PDCA, and so on.

As the lean Work progresses, on the one hand a “system” starts appearing: interrelated tools which, altogether, create the learning system (or the business system) and, on the other, people get better and better at PDCA, choosing the right problems, formulating them more clearly, testing factors, seeking root cause, experimenting with alternatives, confirming solutions, sharing learning. Results become transformational not so much because the problem solving fix all that was broken in the processes, but because as each individual person gains in his or her skill to (1) visualize problems (using lean tools) and (2) solve them (mastering PDCA), their level of skill increases tremendously, which is leveraged across their entire job – and will deliver transformational results for the business.

In this context, a Sensei provides Value in three main ways: knowledge and understanding of the tools themselves (and their underlying principles); experience with the problem solving Process; and handling of the pace of change.

The detail of the tools matter. The presentation of the Production Analysis Board frames the question that we ask the operators. For instance, adding a column for the supervisor to “sign off” every hour says something radically different about how the company understands “respect”: it adds a control dimension that is not necessarily conducive to increasing mutual trust. Even choosing to display just the hourly target or double it by the cumulative target changes the message. To a lean novice, these debates might sound like hair splitting, but experienced Sensei know just how much details in the tool itself affect its use. The tool asks a very specific question to the people in the Process, a question they’ll Work hard to answer. Different questions lead to different answers. If the question does not address the fundamental problem, the answers will not deliver the hoped for results.

There is now more than fifty years worth of experience with both the tools and their underlying principles. Knowledge at this level of detail is not written down, but transmitted orally, by tradition, mostly by arguing with your own Sensei. When two Sensei meet, onlookers often feel they are innocent bystanders in the “battle of the Sensei” – what is really happening, is that the experts are sharing (not necessarily nicely, but that’s up to them) expertise at a very involved level of knowledge.

Tools only reveal problems – they still need fixing: bad parts in the red bin require understanding of what caused them. Empty shop stocks need resolution. Experience shows that solving problems correctly is far from immediate and must be learned, often the hard way. Lean practice has evolved a considerable amount of experience in the field of problem solving, from learning to look for oneself, seeking to figure out what is the right problem (and what is annoying but we can live with), testing hypotheses to focus on the right factors in complex, muddled situations, learning to ask why? Repeatedly to look for root causes, experimenting with multiple alternatives to explore the world of the possible, and confirming the results of one’s solutions (as opposed to taking it on faith). None of this is easy, and often requires determination. Learning is not particularly easy, and professional life is often rife with pressures and burning fires not very conducing to in-depth analysis.

Finally, organizational learning is rarely easy – as it combines individual learning, both at senior level and on the shop floor and collective learning as whole groups take on board Kaizen projects. As John Bouthillon points out, it’s hard to maintain the rhythm and momentum of learning, particularly when the going gets tough. Dropping the issue or looking for a workaround are natural behaviors and a Sensei is often key to sticking with a problem when the first or second attempts have not yielded quick benefits. Moving further in terms of lean systems implementation and “try again” in terms of following through with problem solving all the way to the root cause often require a guiding hand.

Evolutionary Learning
I have no doubt that Dr. Bahri’s practice has been successful, and it is an inspirational story – but that doesn’t change the fact that learning is easier done with a teacher, and that the transformational dimension of lean generally requires a guiding hand. Lean systems co-evolve with root cause problem solving, much as the lean learning conversation co-evolves between the Sensei and the CEO. I believe this one of the key messages of Takahiro Fujimoto’s groundbreaking The Evolution Of A Manufacturing System At Toyota: the system’s strength is its evolutionary learning capability. Which is also why although the principles and tools of lean are fairly set (as a result of long evolution), no two transformations follow the same route and roadmaps are a pipe dream.

Large businesses are uncomfortable with the notion that it all rests on the specific people and that the business system is not the careful thought-out Work of experts in their ivory tower, but the result of a continuous Gemba interaction between the CEO, the Sensei and the shop floor teams (the fact that the system is evolved for a specific person is starkly obvious when senior executives change). To answer your question about whether the Sensei needs experience in the industry, it appears that’s not the case. What is certain is that the Sensei needs experience in using lean as a transformational Process to help the company’s leadership to lean their firm by involving their employees in better satisfying their customers and lowering their costs – every one, every day.

Dear Gemba Coach,
As logistics manager, I disagree with our lean expert who insists we should have “truck preparation areas” in the shipping hall. It adds more handling and goes against the lean principle of touching every container the least possible. As we have many trucks leaving per shift, it would also require a lot of space at the shipping docks and I will not build an extension for lean requirements. Am I missing something? Is our lean expert just following the dogma?

Building a warehouse extension for lean reasons wouldn’t be very lean, I agree, and a definite no-no. Actually, lean should help you get rid of warehouses, not the other way around. Nonetheless, truck preparation areas are indeed a classic lean trick and the first place I personally “go and see” when I do a plant visit. Before we debate about how valid or relevant the solution is, let’s go to the Gemba and try to clarify the problem we’re trying to solve.
A generic four-step improvement program for any Value Stream can be described as:

1.    Protect the customer
2.    Control lead-time
3.    Reduce lead-time
4.    Reduce costs

From a logistics point of view, protecting the customer means having exactly the right containers in the right truck. Typically, the customer might be either an assembler or a distributor. In any case, it should be possible to establish a precise manifest of which containers should be placed in which truck in order to deliver on time in full. In a perfect world, all parts should be available as and when necessary, but in reality we all know that many mishaps can happen, and when shipping operators go and look for the parts in the finished goods warehouse or the production shop stock, one container can easily be missing.

If a container of finished goods is missing from the stores and the truck is already there, waiting to be filled up, there is no time to react. The truck will leave with a missing container. The only practical way to make sure the truck will be complete in full is to assemble it ahead of time to see whether all parts are there. One can argue that you can make the same check through the computer software, but this assumes the software is perfectly up-to-date in terms of what exactly is in the warehouse. Experience shows there are frequent discrepancies between what the computer believes is in the warehouse and what parts can actually be found there. The only way to be really sure is to touch the parts themselves.

Handling Muda?
By deciding the truck preparation area (TPA) corresponding to one truck should be completed some time before the truck’s departure, it’s possible to let yourself the time to respond if one container is missing. Upon discovering that a container is missing, if the Process is flexible enough, a couple of hours are enough to stop the current production, run enough parts of the missing reference to fill a container, and get those to the truck on time – thereby protecting the customer and delivering on time in full.

But what about the argument that this creates an unnecessary handling Muda? Well, there is a second reason for having truck preparation areas. Beyond protecting the customer, the second step of lean improvement is controlling the lead-time. If the parts are brought directly from either the finished goods warehouse to the truck or from the production Cell’s shop stock to the truck there will be unavoidable variation in lead-time. In the first case because we don’t control the time it takes to find the parts in the finished goods warehouse, nor do we control how they get there. In the second case because the parts would sit in the shop stock and then be drawn in one go according to the truck’s manifest. Both cases will create a variation-riddled situation that will increase the lead-time of moving the parts from production to the truck and then on of production scheduling.

The TPA allows us to break up the anticipated truckload into a regular Pitch in order to withdraw from the previous point of stock steadily, thus controlling that part of the lead-time. Whereas a real truck (which needs to be loaded and go) would have to be filled all at once, a virtual truck represented as a TPA can be filled incrementally through the shift at the same pace as the customer uses the containers on their line or shops. This is an ideal, in many cases, as the customer plant’s pace and the suppliers are not exactly the same, so there’s some fooling about with filling some TPAs in advance in order to have a steady pace of building up the truck loads as well as let the customer pick up at their leisure.

Create a Steady Pace
Pulling on the line regularly in order to fill up the truck preparation area at an even Pitch has the added benefit of giving a steady pace of production to the Cell, and creating the kind of tension conducive to lean Work: if the line is late, it will show up immediately and the supervisors can react immediately and solve the issues at the root of the delay. Not having a truck preparation area would impose a stop-and-go rhythm on the line (Mura) which would make Kaizen very difficult.

In case of working for distribution centers it’s often hard to know what the truck load will look like until the orders come in through the day. In this case, a finished goods warehouse stock is necessary, but the same argument applies. Building up the truck as the orders come in at an even Pitch will keep the finished god stock operating as a buffer rather than real Inventory, which will help in controlling the lead-time for the shipping part of the Process.

In any Kanban system, controlling the upstream part of the lead-time is essential to Heijunka and smooth production as the information is transmitted down stream through the Kanban signals. In this sense, the truck preparation area is a necessary tool of the Kanban system. Without a way to pace the pull of finished goods, the lines would have to deal with unbearable variation in lead-time, which would make smooth production and Kaizen very difficult.

Key to Cutting Lead Time
Come on, you will say – live in the real world: how can we control our lead-time when customer demand itself has so much variation? Here again there are a number of tricks, from talking to the customer, to creating buffer “pool” stocks to handle the variation: separate Inventory places where the difference between the leveled “perfect” customer demand and the real customer demand is kept. Whereas the Truck Preparation Area should hold the exact customer demand, the leveling board giving instructions to withdraw on production should be the image of a “perfect” customer – a completely leveled customer. The discrepancy between this “perfect” customer and the real demand is in fact lead-time variation that we can place in a dedicated area and first control and then reduce by improving our communication with our customers.

The truck preparation area is also the key to reducing lead-time once this is in control. In many cases it’s hard to think of ways to reduce lead-time because that would involve more customer trucks coming to pick up – and then theses trucks wouldn’t be as full, which would create Waste by moving air rather than parts. But this is also an opportunity for Kaizen. If the customer trucks withdraw several parts from the same facility, are we certain each truck picks up a little of every type of parts, or do they withdraw, as usual, full truck loads of one type? Even pallets made of storage units need not necessarily hold only the same product. The idea is to divide and mix the truck loads so that every truck lifts a bit of everything rather than have one truck full of one product and the next full of another. Doing so requires a pallet building stage, which, in practice often necessitates a further handling point before the truck preparation area (which consolidates pallets).

How is any of this ever going to reduce our costs? All we see so far is a multiplication of storage points and handling: more Muda, not less! Not really, and that’s the magic of lean. Firstly, pulling steadily from the line can be done with a regular train as opposed to forklifts. This is a massive cost improvement because, if you stand in any warehouse, you’ll see that for every forklift running loaded you can find at least one coming back empty and another sitting idle. In every plant where we’ve created a steady pull of parts with a regular trained crew we’ve decreased transportation equipment cost dramatically.

Secondly, labor costs will also decrease sharply as less people are needed to drive the forklifts and run after the parts This will also avoid the perennial waiting times and traffic jams due to the fact that, thanks to Murphy’s law, all forklifts always have to be at the same intersection at the same time, and will also create a safer working environment by separating man and machine sections. A few forklifts might still be necessary to load the pallets on the trucks, but these can be confined to a “no walk” area. If the system is pushed to its logical conclusion and the pallets are ready to be loaded, the truck driver himself can open his truck, jump on a forklift, take out an empty container, and replace it by a full container and load the truck himself rather than wait idly at the wheel.

Magic Wand Wanted
In terms of shipping area space, yes, it is true that there is an awkward moment when you first establish the TPAs – it usually involves moving some Inventory away somewhere else. But as soon as the truck preparation areas are properly used it becomes obvious that less Inventory is needed in order to fulfill customer orders. Progressively controlling and reducing lead-time will release more and more storage locations until all Inventory can be held in virtual trucks prepared ahead of time rather than a finished goods storage warehouse – the end result is likely to be about half as small as when you’ve started, if not two-thirds smaller. So draw a deep breath and look for ways of creating the first TPAs rather than judge ahead of time whether it will Work or not.

Lean techniques rarely come with a magic wand – at the best bring a lot of head scratching and honest sweat. There are rarely comfortable either. In lean tradition, most new tools can be greeted by an expression of “Oh No!” as a nod to Taiichi Ohno, the inventor of many of these tools. Lean tools are support for Kaizen, not the other way around. The upshot is that it’s hard to prove the benefit of any tool without actually working with it. Any cost-benefit assumes “all things being equal”, but the very nature of the lean tools is change, so all things are never equal and the benefits come from unexpected places, challenging assumptions deeply imbedded in financial accounting.

I am aware that you heard exactly the same thing from your in-house lean expert and that you probably don’t feel anymore reassured by having read this. Unfortunately, it’s in the nature of lean that learning by doing can only be achieved by, well, doing. If nothing else, the first step rationale for the truck preparation area is to make sure we’ve got the truck’s contents ready before the truck gets there, which will secure both the delivery and the loading Process (it’s quicker to load than if we’ve got to go and fish for parts in the warehouse). Having passed through that first door, you’ll find out that controlling the lead-time at the customer truck level is the key to the stability of the entire pull system, which, in it turn is the key to dramatically reducing Inventory and improving radically the cash flow – so all in all, it’s worth some hard thinking to figure out ways to make Truck Preparation Work, rather than argue that they’re wasted time and effort.

Dear Gemba Coach,

I’ve been following the exchanges on The Lean Edge with great interest, and all the lean authors seem to focus on problem solving. In our company, lean has essentially been about implementing pull across the plants. Which way should we go?

Your question captures a key lean challenge, which is how to describe this system of numerous interrelated ways of thinking and behaving in specific and seemingly isolated terms. Because lean is a system that functions on several dimensions at the same time, it is difficult to describe in linear terms. Moreover, it is inaccurate to focus on one element without acknowledging its relationship to another. Consider, for example, the pull system and the focus on problem solving, which are two key aspects of lean. They must be viewed as part of a whole, like the palm and the back of a hand. In the lean system they Work together to help teach every employee to improve their own processes. That’s because this learning can only occur when you have both the tension of pull, coupled with a firm focus on solving the problems that crop up. The old timers call this approach lowering the water in the river and seeing the rocks appear.

All the major elements of the system are linked. Just-in-time and Jidoka are the two pillars of TPS. One way of describing the relationship between these two practices is that just-in-time is about productivity improvement, and Jidoka is about highlighting problems made visible by the pull system. Pull creates the tension that reveals problems, but these problems must be seen, and dealt with, in a way that they won’t arise again – which is what delivers the productivity gain.

Kanban as Kaizen
Let’s take this to the Gemba. Suppose you have a Kanban-based pull system in place. Now, have you watched what happens when you take cards out of the loop? Taking cards out reduces the batch size. If you’re producing As, Bs, and Cs, it means that you have less time to run B and C until you run out of As in the shop stock. This means that the impact of any variability in the Process, either a Changeover that takes longer than it should, or a machine that is off for a few minutes (change of welding tip?), or a late component, anything will cause the shop stock to dry up. When there are no parts to pull out of the shop stock, cards accumulate in the launcher – which should be seen as a problem.

Kanban was designed as a tool for Kaizen, not the other way around. But as you tour many factories, you will see launchers full of cards and empty shop stocks, yet few supervisors becoming flustered over this condition. They shrug their shoulders; yes, we are in a backlog situation, and someone must be working on it, but so what? This is production, right? Murphy’s law will strike here first. Folks will argue that the missed delivery happened because of the pull system: if we had more boxes in the shop stock, we could have tolerated a longer machine breakdown, and still delivered to the next Process and the customer. Problems accrue. A longer breakdown reduces productivity further as parts per hour per person go down and machines are underutilized. In fact, I’ve seen several factories running elaborate pull systems with fat inventories everywhere and poor efficiencies. The more Inventory, the greater tolerance for mishaps, the less productivity. Conversely, the less Inventory, the greater reactivity (one hopes), the smoother the production and the higher productivity.

What makes pull system effective is not the pull itself, but the reactivity of people to problems when they appear – what Steve Spear calls “swarming” problems in his breakthrough book The High-Velocity Edge. Furthermore, should the management set this as a goal, swarming problems can lead to root-cause problem solving, which will produce fundamental Process improvement. A pull system alone does not guarantee effectiveness. To pay its promised returns (15% more productivity, 50% less defects, 25% less stocks than an MRP-run line) the pull system needs to be managed in a “lean” way. This means teaching people to see, react, reflect, share and challenge. We’ve discussed these basics before, but once again, they are:

•    See: a lean system is designed to show something that is not right. In the ideal, the Process will simply stop. This is hard to do in practice, so create some physical aspect that will indicate that you’re driving on the wrong side of the road (such as too many Kanban cards in the launcher). However, in order to see, you’ve got to look. Team leaders and their supervisors must take the responsibility to own these problems and stop and think, as opposed to ignore the signs and soldier on. Taking responsibility for problems is far from natural, and needs constant reinforcement from management to encourage “problems first.”

•    React: how many times have you spotted something not quite right at home yet failed to respond until you suddenly have a real problem: the dripping pipe which suddenly springs a leak that ruins your neighbor’s ceiling, and so on. The first task of lean management is to teach people how to react (for starters, to react at all). I recently visited a factory where they insisted on “escalation” as a reaction: in case of any problem, the problem should be escalated quickly up the ranks. As a result, everybody filled forms and wrote on boards assuming that someone else had to solve the problem. Escalation might be necessary, but that is not the aim of reacting: the aim is getting people to solve their own problems quickly. To do so, they’ve got to be trained. So it’s not a question of escalating the problem so that the boss gets out of the meeting and saves the day, but of creating a system where the boss can tell there is a problem and where, and come along to watch how people are doing by themselves and teach them how to do it better.

•    Reflect: lean is about learning by doing. There is no point in blue-sky thinking, no matter how clever, if you’ve not reacted first to plug the leak. So first stop the oil from gushing into the sea, and then try to figure out how to make sure this doesn’t happen again. Reacting will teach you about the true nature of the problem, but rather than be happy with the plaster, the idea is to start asking why? Until the root cause becomes apparent, and the Process fixed so that the problem will not arise again (with no – or little – investment). Oddly, people prefer to reflect when they’ve not done anything… and usually get it wrong. Reflecting on one’s own actions is more emotionally challenging because one is forced to accept that the reaction was never perfect – there’s always something we missed under fire. But that’s the whole point of learning. By reflecting on the way we’ve reacted, we first have more facts at hand (from just having done it) as opposed to tons of data, and second we pay more attention and learn.

•    Share: no one is expected to reinvent the wheel by themselves, and many brains are better than one – so it’s important to share learning, both at the reflection stage and at the confirmation stage. In lean, to share does NOT mean “apply best practice” – it actually means, well, share: comparing different ways to solve similar problems in different local conditions to spark new ideas. Again, the aim is learning, not just applying. And not to worry, if the practice really is a “best practice”, people will adopt it in a flash. “Not invented here” exists, but tends to happen when its unclear whether the touted change really is an improvement or simply a change.

•    Challenge: we are natural problem solvers, but we’re also natural satisfiers; we’re extremely good at finding a workaround that passes the problem on to someone else or to some time in the future. Getting people to see their problems every day, to react, reflect and share requires constant challenging. Is the pull system tense enough? Is the immediate reaction good enough? Is the reflection deep enough? Is the sharing broad enough?

Lean as Learning System
As discussed in a different column, lean is a learning system, which determines a sustained pace of learning: you don’t get to choose how quickly you learn. I remember visiting a Toyota forklift plant just after their Sensei had been there. There was a huge hand-drawn Value-stream map on one of the plant’s walls (in the production area, actually), with parts containers identified as round circles on the flow. They showed me how, after touring the plant, the Sensei had crossed out several of these circles, indicating the stocks should be taken out. In the end, this led the plant to radically reconfigure how they brought parts to the line and to invent an elaborate system of trolleys inserted into a train. The plant didn’t feel like it, but they did it: they learned at the speed imposed by their Sensei’s lowering the water and revealing the rocks.

A lean pull system is a sensitive mechanism – it’s prone to fall over at the slightest mishap, kind of like juggling plates on sticks. And that’s the whole point of pull. Pull is not a stabilization tool, but something to keep you moving forward. On the plus side, it also becomes a stabilization tool because leveling the production plan, doing what it takes to make people show up on time in the morning, stabilizing the component supply, working at keeping machines running smoothly and conducting SMED workshops forever and ever are the only ways of keeping a pull system up. In other words, the pull system creates problems – and solving these problems creates performance. The pull system is the greatest production teacher you’ll ever have, but you have to be ready and willing to learn what it teaches.

Dear Gemba Coach,

Our operations VP is disappointed with our lean program. Despite his close personal involvement with the program, it is not delivering the level of results he expects. How can he be a better Sensei? Is this even the right question to ask? Both of your recent books stress the importance of the Sensei role. What advice should I share with my VP so that he can support greater results from our lean Work?

The role of Sensei (an experienced coach or mentor) in lean programs is indeed problematic, and probably the greatest bottleneck to the widespread diffusion of “real” lean. True senseis are rare, expensive, and uniquely difficult to Work with. They often Work with senior managers who doubt their Value, since these executives believe they’ve got enough brains in-house to run the lean program. They are often considered too expensive, intrusive, or unnecessary by companies convinced that they are indeed lean.

So why is it that I have yet to come across a convincing lean transformation that occurred without a Sensei’s help? And believe me, I’m looking. If somehow we could circumvent the high barrier to entry the “Sensei” represents, we could greatly accelerate the speed of lean diffusion. It’s just that in my experience, while many companies show some improvement with their lean programs, they fail to distinguish themselves dramatically from their competitors. The dramatic results are to be found in the few instances where the management team has worked with an experienced Sensei. Here you will often see a specific – and highly recognizable – blend of radical results obtained through small-step Kaizen improvement. We’re talking 15% productivity improvement, 50% defects reduction and 25% stock reduction per year (after two or three years, the gap with competitors really shows). Any given company may not achieve all three aces, but certainly at least one, and sometimes all three.

(These significant results are obtained by radical changes in the Process as well, usually visualized by a working pull system and a low-level focus on problem awareness and problem solving.)

So what is it that the Sensei actually do? Their power has nothing to do with day-to-day coaching, or a great formal Playbook that he teaches individuals to follow. Recently I visited an automotive parts plant that I’ve known for years. The plant has reduced their in-Process WIP to about .7 days, which is good. They had switched off the computer tracking as a way to manage their internal flow even better, as it forced their supervisors to Work exclusively with Kanban cards. A recently-hired Value-stream manager was struggling with the absence of scheduling software. “Guys, what’s the parallel system?” he asked his workers. “I’ve worked in automotive before: no one ever really follows the cards. There has to be a scheduling software somewhere: you can tell me, I’m your new boss.” It took some time for him to accept that there really was no phantom system—that the continuous WIP improvement was due to maintaining the tension on the Kanban cards; and pulling some out regularly (which, of course, created many headaches in machine availability and changeovers and so on).

This new manager was just as surprised when he asked to see the manual, and was told that there wasn’t one. “But you had a consultant help you with implementing this pull system,” he asked, “surely he left you some slides?” It wasn’t like that, he was told. The consultant visited once every couple of months and discussed what we were doing with your predecessor. Mostly he pointed out areas where we were not following up on our own ideas and then argued about the one or two big things we should Work on for the next step. There never was a manual, because we did all the Work ourselves, explained his colleagues. It sort of came together over time. We used to have four days of Work in Process Inventory when we started, but we took it out step by step.

Learning by Doing

This response didn’t help much the new Value-stream manager – who, by the way, continued to struggle for a while before figuring out that working at further reducing the WIP was the best way to get “into” the pull system and learn – but it describes fairly well the Sensei’s role. Lean’s learning approach is learning by doing, not learning by design. Rather than have several presentations about the ins and outs of a pull system and then try to implement the perfect system all at once, lean learning will occur by working out one problem after another according to a regiment devised by, you’ve guessed it, the Sensei. A Sensei is a coach who has the experience of taking people through the implementation journey and who can (1) demonstrate current problems and (2) explain what the next step should be (in Mike Rother’s “kata” terms: the next target condition).

Why can’t people figure it out by themselves just by reading the books or using a consultant who will “implement” the tool for them? The trick is to realize that not only does the Sensei control the direction of implementation (making sure the lean tool is working as it should on the Gemba), but also the rhythm of learning.

By and large, we all feel that we like learning and are eager to do so on the job. But what we mostly have in mind is learning (1) what we think we should learn and (2) at our own pace. What this means, in our culture, is learning more about what we already know to fill in the gaps and get into more detail, and take the time to read and discuss and debate and think before we actually commit to action. Working with a Sensei is very destabilizing on both accounts because first, he or she will push you to learn new things (that you haven’t done before at all), which is kinda scary, and worse, will push you to do it at his or her own rhythm – not yours. The deal is “do and then think”, rather than “think, and then do.” This sounds at odds with the notion that the Japanese culture is about “aim, aim, aim and then fire” rather than our tendency to shoot from the hip, but the misunderstanding comes from the fact that “aim” in lean often means “try” in a Kaizen situation, before you commit. Learning will occur from reflecting on the Kaizen experiments and getting it right until we go for the large-scale radical change.

On the Gemba, it’s not an easy proposition. Most people resist the Sensei’s comments and indications for a number of reasons ranging from distrust (what does this guy know of our daily Work?) to fear (if I start doubling the number of changeovers, I’ll never hit my production numbers) or straightforward annoyance (who does this guy think he is to show me up like this on my own turf? And if he knows the answer why doesn’t he just spit it out?). The point is that most of these emotional reactions to the Sensei’s challenge are just that – resistance to having to learn at an imposed pace, rather than at our leisure. Consequently, these reactions are also understandable and totally okay (it’s a free world) as long as they don’t hold back the learning Process. You don’t have to like your Sensei – just get cracking and do the Kaizen.

Any business is an interconnected system: that is an inescapable truth of wholesale improvement. In order to get budget-level sales, cash, cost and capex results one can’t focus only on piecemeal issues – fixing one leg of the table won’t help much is all the other three are not rebalanced as well. Obtaining sustainable business results of the order we discussed simply can’t be achieved by just fixing a few local issues in operations. Experience shows that eliminating a “bottleneck” only means creating another one. It’s the balloon syndrome: squeeze at one end and it will bulge on the other.

Sustaining Improvements

The Sensei will help you to construct an approach that encompasses the full company or business unit. For instance, the pull system we were discussing is a particular case of a more general approach. In order to deliver to customers and obtain cash results, the Value Stream needed an improvement Process – not a way to make it Work, but a Process to drive the improvement on the delivery and cash dimensions. The pull system they built under the guidance of the Sensei is this mechanism. The game is not about replacing the MRP with Kanban cards, it’s having a system that will lead to improvements sustainably. And indeed, by working with the pull system (first building it and then running it), the Value Stream Manager (should he want to) could identify at every visit one specific area for improvement which would deliver on-time delivery and reduce Inventory.

At the plant level, the Sensei and the plant manager spelled out a “north star”, a list of dimensions which needed to be improved day in, day out, in order not only to deliver results right now, but also to ensure the future existence of the plant, and its flourishing. These dimensions ranged from the obvious operational issues of safety, quality and lead-time, to cooperation with engineering, machine maintenance, developing technical expertise in specific areas, growing people, working with suppliers and so on.

On each of these dimensions, the Sensei helped the plant manager to set in place an improvement Process (for instance, what would be the improvement Process for better working with engineers? In this specific case, the first step was creating full-size cardboard cutout cells of new projects to collaborate before the machines were finalized). And within each improvement Process, the discussion at every visit was about which necessary improvement came out of the Process and whether this improvement would deliver results both right now and for the future.

In the end, the resulting lean program had nothing in common with the frequent “apply the roadmap” approach. It could be summarized on a couple of A4 sheets in four columns: Area for improvement – improvement Process – specific improvement topic – did it Work or not?

The fun part is the Sensei really doesn’t know what shape these improvement processes will take – it completely depends of the organization and the personalities involved – just as the Sensei won’t have specific ideas about what to improve in each case. The lean program’s fundamental aim is to develop local leadership in improvement so the specific form it will take is unique, a blend of lean principles, the people in the bus and the contextual spot the company finds itself in. The only thing we do know is that if people Work hard, they will deliver an order of magnitude in results. It might sound like religion, but that is what tends to happen.

I believe you’ve got to be a genius to learn math out of a textbook. We didn’t like it, but most of us learned math with a teacher who got us through the curriculum. Top athletes don’t require less coaching, but more to keep on the top of their game. Similarly, I’m certain it is possible to learn lean on one’s own through trial and error, but without a firm guiding hand, this is likely to take a while, with not much to show for it in the end. Learning IS hard, and it cannot be delegated. To sum up, the Sensei’s role is to:

1)      start from the Gemba.

2)      highlight problems and show the right direction.

3)      maintain a rhythm of learning.

4)      build up the improvement Process, and show good judgment on improvement ideas.

The next question tends to be: “okay, where do I find a Sensei?” And to this question as well there is no easy answer. But indeed, this is the first step on the path of “real lean”, the path that leads to radical transformation and spectacular result. And the only answer I know to this question is that finding one’s Sensei is the first challenging task in the lean journey.

Dear Gemba Coach,

Can you provide some guidance on splitting roles and responsibilities amongst the various hands-on leaders of the lean implementation (lean support group, operations managers, team leaders) in order to get the best mix of engagement and proper Process?

Hmmm … this is a very interesting and very politically sensitive question - because of the senior commitment to one approach or another, a decision that is usually made before realizing the ins and outs of either approach (how do you get out of the signed deal with the consultant to run X number of Kaizen events?). More than ever, the real underlying debate here is: what are we trying to achieve? To try and answer, I’ll oversimplify two extreme positions, and then we can look for compromises in the space in-between.

Most people will agree that better processes deliver better performance. Short of inventing ab nihilo a newer better Process (which many IT vendors suggest), the lean approach is to eliminate Waste from existing processes and in doing so improve them, which will improve performance. So far, so good, right? Common sense says that if we take Waste out of the Process, it will perform better, and so deliver better results. The obvious way to do so is to create a team of lean experts well versed in the lean tools, to line up every business Process and to give the lean team the goal of hitting these processes one after the other until the entire business has been “leaned.” By now, experience has repeatedly shown that this lean team runs into trouble both with management and frontline staff, so it’s necessary to give them support.

Show Me the Money

In solving the problem of Process performance this way, we generally end up with a lean support group which tackles shop-floor projects “championed” by a senior or middle-manager to deliver spot savings. It is expected that the accumulation of such savings will boost the bottom line. In this approach, most projects are successful and, in the first two years, the support group is highly motivated, well thought of, and learns a lot. As time goes by, two typical issues surface: (1) the lean “savings” can’t be found in the accounts at bottom-line level and (2) many of the Process improvements have turned out to be unsustainable. At this stage, the organization typically casts around for solutions with, on the one hand, the senior lean leaders asking “sustainability” questions, and the lean experts finding out that after two years in a “lean” job, it’s hard to go back to the management line.

From very early on, the senseis have been telling us that lean is not about applying the tools to every Process but developing the Kaizen mindset in every employee. How would that impact the bottom-line? With this angle of view, people make processes, not the other way around (which does not invalidate that the Process drives the behavior). The reasoning is the following: more competent people come up with smarter processes, which delivers superior results. In this perspective, Waste elimination is the basic training tool to teach employees to better care for their customers, do their job more precisely and understand more deeply the underlying principles of their Work.

Boss and Sensei

In the “JOB = Work + Kaizen” attitude, the line manager is directly responsible for Kaizen. His or her mission is to develop his or her staff, and to do so by getting them to do Kaizen and lean their own processes. In the purest form, there is no need for any lean support group as lean is what management does. When Art Smalley recalls his time at Toyota’s Kamigo plant, he describes being taught TPS by the engine shop’s manager Toomo “Tom” Harada – who has the dual role of boss and Sensei. Harada himself was a young engineer at the Kamigo plant when it was still run by Taiichi Ohno, its founding plant manager.

Now, few western managers would be up to both manage and teach Kaizen to their staff, as few would have been trained that way by their own manager. In practice, when Toyota started transplanting plants out of its home base, the company developed a “coordinator” role. Every mid-level manager (starting with supervisors upwards) was doubled by someone from the mother plant in Japan whose role was to teach Kaizen to the western manager – and to coordinate with Toyota City. Most transplants have a “shadow organization” of coordinators to train line managers to their Kaizen role. This is not a permanent role – engineers from Toyota in Japan are given this three-year appointment to develop them and give them overseas experience. Any manager in a Toyota transplant would expect to deal with several coordinators during his or her time in the job.

Toyota also created a specialist “lean” group (the Operations Management Consulting Division – OMDD in Europe and TSSC in the US) in the sixties to help suppliers get started with Kaizen. This group has evolved in various ways since then, and they would be considered to be the paratroopers of lean – if you need a shock treatment to get going with Kaizen, these experts will coach you through projects to teach you the ropes of TPS. Now that does sound like a Lean Support Group, but the underlying thinking is very different. The idea is not to generate results, but to teach. One of my senseis who works for an automotive supplier has been coached continuously for twenty years by OMCD experts, and in some cases doing projects in plants which did not even deliver parts to Toyota.

The point is that between the two extreme positions of on one hand (i) managers manage and lean specialists come in at shop floor level to lean the Waste out of their processes (so they can go on managing) and (ii) there is no lean support group because to it managing means improving and it’s managers main job is to teach Kaizen to their teams (which is where the Team Leader comes in as the lead operators to maintain standards and facilitate Kaizen), every company, starting where it does, has to find a working organizational design to get moving.

What I’ve learned from studying many lean programs and how Toyota goes about it with suppliers is that the key person to develop lean is the plant manager (or the corresponding unit manager in service operations). Consequently, I frame the question you’re asking in terms of: how can I best develop plant managers. In practice, we often end up with a variety of mechanisms:

1.      Senior management visits with a Sensei to challenge the plant manager and define areas to Work on and overall objectives

2.      Personal coaching of the plant manager by an internal lean expert to help him or her understand the details of the tools and their applications in specific shop floor situations

3.      A full-time lean specialist working for the plant manager, coached by the corporate lean expert, to train supervisors to run their own Kaizen workshops

4.      A community of practice of plant managers to support Yokoten within the company (both sharing and competing to obtain results).

Plan for Every Manager

There are no cookie-cutter organizational solutions and every company has to reach the proper balance between staff and line roles. For what it’s worth, my take is that the operations manager, plant manager, supervisor, Team Leader line bear the entire responsibility for getting results by running operations day to day AND doing Kaizen. Now, this is a rather tall order, and they often need support. I believe the form this support takes should be ad hoc: whether an internal specialist group, external consultants, trainers, access to a Sensei. Most organizations I see run into trouble when they devise a one-size-fits all program irrespective of the training needs of each individual manager.

I don’t know how to answer the question other than by suggesting to try and develop a “plan for every manager” and think on a case by case basis of what kind of support they would need to develop Lean Thinking. In many cases, the organizations would be very reticent to a tailored approach to lean learning (and would need to control the Process tighter), but starting from the learning needs of managers is the best way I can think of to design support roles and responsibilities which will truly engage the line management in their Kaizen roles.

Dear Gemba Coach,

How about standardized Work in a business Process environment? For example, in a procurement Process or supply chain processes? There are not many books/articles on standardized Work in a transactional environment. Please help to shed some light on how we should approach standardized Work in business processes.

Let’s take a step back here: why would you want to apply standardized Work in transactional environments in the first place? As you may know if you’ve followed this column, I’m a great believer in the lean tools, and don’t subscribe to the tool vs. philosophy dichotomy – on the contrary, I firmly believe the tools and principles must be aligned to deliver the hoped-for results.

Lean tools are countermeasures to specific problems. More specifically, lean tools are countermeasures to people who are running a Process and not understanding some specific problem in the way they operate this Process. A lean tool is above all a standard analysis method enabling people to look at a typical problem. For instance, SMED is about separating internal from external Work in Changeover in order to make operators see the Muda in the way they carry out changeovers. Five S is a tool to visualize zone control in order to make operators realize the Muda that is caused by not keeping the right things at the right place, and so on.

As far as I understand, standardized Work was developed to help workers find assembly patterns with the least Waste and overburden so that the target Cycle Time can be achieved consistently through the shift. At the Gemba, when you watch how operators put products together, very often you’ll see they know what to do (insert these three bolts here, here, and here) but their practice varies on the how – they don’t make the same moves from one part to the next, which leads to quality issues. Also, if the Work hasn’t been well designed, operators will tire during the shift and risk professional illnesses as well as not reach the target. As a countermeasure to such issues, Toyota developed the “standardized Work” tool to analyze motion, find the best method, and train operators to follow it. Standardized Work is clearly a tool for continuous improvement (as opposed to Work standards which describe the basic Process – the what).

Transactional operations hardly fit in that pattern: few business processes are so rigorously defined that what lean guys call “pre-requisites” would apply. For standardized Work, this would be a repetitive cyclical Work within a 10-minute cycle, with a stable Process and low equipment Downtime. Transactional processes often involve interactions between people, and if there’s one thing people hate is being treated as a number: the robocaller, the inflexible administrative staff, the salesperson who refuses to understand your problem and so on.

However, we should be careful because the temptation to “script” is always strong: this is the Taylorist answer to transactional operations. The experts define the perfect interaction and the human operator lends his or her voice to say it out loud, or fill in the right spots on the computer system. However, business interactions are, well, transactions and scripting high variability situations often (1) fail to resolve the problem and (2) angers or frustrates the other party. Positive relationships are an essential part of good outcomes, as they lead to quicker and better problem solving. “Standardizing” such operations prematurely can easily lead to fixing the wrong problem, and be endlessly disappointed by the outcomes.

What is the Problem?

So, before we start thinking: hey, this is a great tool in assembly processes: where else can we apply it – let’s take the question the right way around and try to clarify what exactly are the problems we’re trying to solve?

My experience with business processes is that the “normal” case is usually pretty easy to handle. But then the difficult cases are many, and they all come in differently. It’s like opening a window: 90% of the time, it’s a no brainer, but then when you hit a snag, it can be a real challenge (or am I the only one to struggle with the new window handles that open sideways, upwards, downwards and, well, never just open?). For instance, back at the Gemba, I’ve recently been shown an application of “standardized Work” (or so they told me) to a banking back office Process. The lean specialists had looked at all the possible cases in one simple Operation, and written standards, which had then been computerized with rolling menus to be sure that the operator followed the right sequence in the right circumstances. As a result, an Operation that took routinely 10 to 20 seconds now took a minute and a half: in 90% of the cases, the Operation was really simple and the operators did it perfectly well by hand. In the remaining 10% there were difficulties, and yes, checklists would be useful – but setting the “standard” to engulf all cases simply slowed down the Process tremendously (and annoyed the operators). If the only tool you know is a hammer you tend to treat everything as a nail.

Business processes tend to be fluid and interactive – they have only one way of going right (hopefully what happens most of the time) and a zillion ways of going awry. However, because of the very fluidity of the Process, most operators know how to deal with the normal situation but are often unprepared to deal when things are off. More to the point, they find it hard to recognize when they are an abnormal situation until it’s reached crisis point, management has to get involved, tempers are high, and everyone loses points.

The aim of a lean tool here would be for a team of operators to learn to (1) analyze their own Work and (2) recognize the Muda they create by some of their reactions so that (3) they find better ways of handling this.

Firstly, let’s start with outcomes:  what constitutes “good Work” as opposed to “bad Work.” In effect, we need to help them analyze their own Work and see the consequences of their own actions. In a procurement office, suggesting that procurement operators are responsible for getting correct parts to the assembly station as opposed to blindly following the IT system (and so managing parts lead time rather than Inventory level) usually triggers many adverse reactions – the operators feel powerless to do anything else than what they currently do, and generally have no visibility on the impact of their decisions.

Secondly, we need to help them distinguish normal conditions from problem situations, and help them with basic problem solving skills to Work with third parties. In any interaction, the deal and the relationship are equally important outcomes, and basic negotiation skills are essential to help operators resolve issues amicably with their vis-à-vis.

Key Operations

In tackling a business Process, I would first get the operators to draw out the chain of agents in the Process leading to the customer. In the procurement chain, for instance, we would have the supplier’s producer, the supplier’s planner, the procurement agent, the logistics contractor, the goods-inwards logistics material handler, the operator and so on. Plus we would have supplier sales and our purchasing department involved somehow. Next, we would try to map what each of these departments would consider a good outcome, from their window, and compare it to what kind of outcomes we would need to deliver right first time to our customers.

Having clarified this chain, I would then focus on the key operations leading to a successful outcome – when all goes well so to speak. For these operations I would start discussing Work standards (not standardized Work): how to stabilize the Process of doing certain repetitive tasks to lead to positive outcomes:

1.      Which Process and what it’s supposed to achieve

2.      Sequence of steps to achieve a good outcome

3.      Key points at each step to get it right

4.      Lists of materials, information or equipment needed to perform

From working on these Work standards on key parts of the Process, the team can identify basic problems, as in, frequent issues that make the standard inoperable. The goal is to help operators see they are no longer in standard conditions and special care needs to apply. We’ll end up with a checklist of:

1.      Frequent problems

2.      How to spot them early

3.      How to react when this occurs (not problem solving, but next step)

Having clarified common problems in the Process, the team can then Work on checklists to help operators solve the problem. These very different from “standardized Work” inasmuch as problems rarely can be solved with a set sequence of steps in a given time. These are lists of various typical aspects of the problem to check before escalading it to the next level of management. Such checklists are maintained continuously as experienced operators share how they solve such and such problems.

Having done this basic Work, we can ask ourselves: how could we improve things so that the problem does not appear – and start the Kaizen Process. A good book to read on these topics is Steven Spear’s remarkable The High-Velocity Edge [The High Velocity Edge]

To my mind, attempting to apply “standardized Work” to business processes is a slippery road. The temptation will be to prescribe greater rigidity in Work patterns dealing with fluid and flexible situations. At the end of that road, you find the call center operator chained to his or her phone with a set script or the automated robot caller who drives you crazy.

I’d choose a different route: making sure the business outcomes are properly defined at each point of the chain in the business Process. Before we “solve” problems in the Value-stream map, let’s make sure these are the right problems. Standards can be very useful there to describe what is a quality interaction, and to explain what is important to succeed at every step, in order to achieve the proper objectives.

The many “standards” tools in lean are about having a discussion with operators to find the most Muda-free way of doing a repetitive job. It’s one of the tools that is the easiest to misinterpret as a Taylorist way of getting operators to apply the “one best way” devised by central experts. In business processes, before we even get to discuss standards, it’s well worth working with the team to clarify their understanding of the Work they do (in particular, I always find that discussions about what is a good outcome are valuable), what Waste is generated by mishandling some specific situations, and what local tricks can we devise to (1) spot that something is going wrong and (2) react immediately to avoid escalation. Working continuously on these ideas will first lead to checklists, and, maybe, if the situation is frequent enough, to standards that will then be taught upfront to the next generation of workers (when this happens, you do that…). But let’s keep in mind that the Value of the tools is in teaching people to understand better their own Work (and thus improve their performance), not apply blindly the “one best way” someone else has devised for them.

Dear Gemba Coach,

Most lean literature and case studies to date focus on assembly type manufacturing which utilizes very people-intensive operations. This is not the case in the machine-intensive Process industries and therefore has major implications on the format of standardized Work. Can you shed some light on what standardized Work should look like in the Process industries?

Thank you for this question, which provides an opportunity to investigate the point of a lean tool. Many people use magical thinking when adopting tools—assuming that by simply applying them, the Process will improve and so will performance. Five S is typically prone to such hopes—and disappointments. Hopeful improvers see endless cycles of 5S drives fail to generate any radical change in either Process or performance, because the tool has not been applied for the right reasons.  

The crucial lean principle to keep in mind is that lean tools were invented to help people analyze their own Work patterns and see the Muda they themselves generate in their own processes, so that they can look for better ways to get the job done. “Standardized Work” (a set sequence of steps to do within a target Cycle Time), for example, is a great tool to help assembly operators see that they rarely perform the same tasks the same way, see that this involves a lot of walking, fumbling and creates defectives as well as safety risks, and learn a better way. Consequently, you are right to question whether this applies to machine shops or flow processes. The fundamental question is: which aspect of the Work do we want to focus on?

The Core of Standardized Work

Before we get to the nitty-gritty of the tools, let’s go back to the Gemba. I recently visited an industrial tannery where raw hides are processed on a conveyor through chemical baths, and then dried in large oven-type equipment. Or, a few years back, I worked with a manufacturer of industrial carpets: huge rolls of materials go through a number of processes in large equipment that fills up entire halls. Where are the operators in such settings? Some operators Work at set stations in the Process, typically to move materials from one step to the next. For instance, the hides will be taken off the conveyor to be taken to the ovens. This could be automated, but in some cases the flexibility necessary for the Operation requires human labor. Operators can also be found doing specific operations such as tool changeovers or material supply. In a machine shop, for instance, an operator’s main job is to bring the part to the machine, insert it and then set the proper tool for machining. This would be true also of the large flow-processing operations such as the carpet making I mentioned. Finally, human operators are also found running the entire Process – most commonly within a central control room where the computer system keeps track of all the equipment, and from there, human operators go and perform a number of checks on the machines themselves.

The core idea of standardized Work is to determine the most efficient (as in: “Muda-free”) Work sequence and to repeat it exactly in the same way so that operators avoid unnecessary motion and wasted effort. Standardized Work guarantees quality and precision, saves time, maintains safety and prevents equipment damage. But what about when there is no sequence, because a few operators are called to and fro to deal with materials and equipment, but without any apparent cycle to their Work?

Standardized Work is primarily there to show the operator a Muda-free way of working: by referring to the operations standard sheet and the standardized Work sheet, operators can find out what they do wrong and correct it, or what they do better, and improve the standard. Secondly, standardized Work is essential in helping operators cope with change: change in the mix of products with tool change-over, change in the volume, with more or less people in the shop (and integrating part time colleagues, for instance), change of production with new product introduction and so on. Without standardized Work, each of these changes becomes a huge headache that the shop will naturally try to avoid or resist. Standardized Work is an essential aspect of flexibility.

Where are the main examples of Muda in a machine intensive Process shop? By standing in the Ohno circle in any machine shop or Process shop we can see Muda:

• A few operators are isolated at workstations doing either checking or moving components from one Process to the next. With all the focus on the machinery, these workstations have rarely been looked at in detail, and are in dire need of being improved.
• Most machining or Process shops require moving materials and parts to and from the equipment – often in large crates or rolls, and through haphazard routes. Such movement is unavoidable, but essentially Muda, and can often be organized as a regular cycle and regular routes.
• The periodic jobs which need doing on the machines such as changeovers, basic maintenance, or material supply are themselves Muda-prone, as its felt that every time is different and there is no standard way to perform the job. Certainly, any SMED workshop in a machine shop will reveal exactly how unorganized and difficult most tool changeovers really are.
• The control part of the Process is also rife with Muda, as operators move to and fro in large halls to check this or that according to what appears on the computers screen, often after the fact and when they deal with a lot of defectives or rework. Having operators spend their time “babysitting” the equipment is an obvious form of Muda in most Process industries I’ve seen.
• Last – but not least – defectives are often considered as “normal” in Process industries: every time tools are changed in a machine shop, or material is changed in a Process shop, some parts and some product is considered defective for “setting” purposes. In machine shops, typically, the first part of a batch will be thrown away as part of the setting Process. If one reduces the batches to only a few parts at a time to follow real demand, this procedure becomes unbearably wasteful.

 #1 Form of Muda

Before we go to the tool itself, we must ask ourselves what can we do to reduce Muda in a machine-intensive Process shop. 

The number one form of Muda in a machine shop occurs, not surprisingly, when machines go wrong: either they produce defects, or they break down. To avoid this, labor is utilized to “patrol” the shop and make sure the product is good and that machines run. Most of these activities are either too early (you check but there’s nothing wrong) or too late (something went wrong, and you only find out when you come to check). In effect, the way to fight this source of Waste is to be able to spot real-time where you need to be when.  The main tool for improving machine-intensive processes is Andon, before standardized Work.

How can the machines spot something is going wrong and how can they call your attention to it? Jidoka is often seen as the hidden part of the lean iceberg – an engineering technology Toyota has developed to make its machines “autonomous” in the sense of having some judgment over whether they were making parts to specification or working correctly. Think, for instance, of installing captors behind cutting tools to make sure the tolerance are held and to stop the machine if they’re not. Andon (the call mechanism) is essential to Waste reduction in a machine shop or a flow Process because it takes away the “random walk” of operators checking on the machines. The equipment no longer needs a babysitter – it will call for help when needed. In this manner one can dramatically reduce the resources needed to ensure things run, and invest more in maintenance activities and problem solving to keep the equipment at its nominal Value.

The second common form of Waste found in machine intensive environments occurs when operators carry out technical tasks such as changing tools or maintenance. Standing in the Ohno circle during these activities it becomes painfully obvious that much of the time is spend going back and forward looking for tools, parts, second-guessing, correcting previous Work and so on. Operations standards (the bedrock behind standardized Work) are an essential tool to help people minimize Muda in these operations. By (1) listing clearly the steps of, says, the maintenance, (2) highlighting the critical point at each step and (3) explaining why this is a critical point, one has a tool both to help operators learn how to do this better, but also to Kaizen their own Work by analyzing the specific reasons they do not follow the standard at any given time.

Thirdly, a lot of Waste occurs as operators shuttle materials from and to the machines. These trips are mostly organized “on demand” and often suffer from conflicting priorities and many mishaps. On this kind of Waste, standardized Work (a stable sequence of steps) can be very to help operators better organize their delivery and pick-up routes.

I have discussed this question with Art Smalley (author of Creating Level Pull and co-author of Understanding A3 Thinking), who is currently writing a book on standardized Work with  Mr. Isao Kato the original creator of the modern day standardized  Work course in Toyota, and his take from his experience in Toyota’s machine shop is that:

“The question is sort of tough to answer and the devil is in the details ... the 100% strict truth is that Toyota does not use pure standardized Work in engine or transmission machining lines. The reason is that the Work pattern is not cyclical. Instead the operator walk pattern to different stations is dictated by the Andon signal. It tells them to go and change cutting tools, conduct quality checks, and find out why machines have stopped, etc. So in the purest sense it is not governed by the three elements of Takt Time, Work sequence, and standard Work in Process (SWIP). That is mainly for man machine combination that have repetitive Work that is the same cycle after cycle.

“In machining we use operator instruction sheets that for all intents and purposes look the same to the untrained eye. They still contain columns on the left for Main Work Elements of the job and a column for Key Points for each step of the job. There will be a picture or diagram to the right and the usual information at the top. If you look closely however the elemental times don't exist and there is no indication for Standard Work in Process (SWIP). In machining we use lots of Operation instruction sheets for tool changes, quality checks, gauging of parts, and various tasks such as machine start up, shut down, or some cases involving troubleshooting.”

Andon Challenge

To answer your question, the “standardized Work” tool was created to help assembly operators find the best Muda-free way of assembling parts. In describing the sequence of steps to achieve in a takt, standardized Work is a great tool to learn the proper sequence, and then spot problems in the way we currently do things (if we can’t get the job done with the target Cycle Time, if we don’t do the operations in the correct sequence, etc.); which then highlights the opportunities for Kaizen. In a machine shop or Process flow environment, the issues are different, and the first question to solve is how to direct the attention of operators in large, complex and demanding areas. Before addressing standardized Work questions, make sure you’ve done enough Work on the Andon mechanisms. Modifying machines so that they recognize the problems they create is never easy and often a worthwhile challenge.

Secondly, when operators do intervene on the equipment – how do we make sure they do it right? Such activities are usually different from walking around a workstation to use equipment in sequence, but certainly a step-by-step approach can help tremendously, as well as a focus on explicit “pay attention” points at each step (which can often differ from machine to machine”. In this case, operations standard would be the more relevant tool.

In specific cases – the change-over is now down to a few minutes, or there is a materials pick up and delivery route – the standardized Work sheet in its classic form of showing the operators’ steps from one station to the next can be helpful to find more detailed Waste and Work on it. But it wouldn’t be where I’d intuitively start. I’d first make sure operators can tell by themselves when to be where, to do what, and how to go about it to do a good job of it. The key to tools is that they should help the people doing the Work better understand how they do their job, and see what kinds of Muda they are generating in the Process. Different situations do call for different tools.

Dear Gemba Coach,

I keep hearing about “making people before making products” but I have a hard time visualizing what this means in practice. Would you be able to shed some light on this practice?

I’ve spent the best part of the previous 15 years trying to figure this out and can share what I’ve learned … so far. When I first studied how Toyota engineers implemented TPS at a supplier, they always knew what the next step was, and so I assumed (as did the supplier’s engineers) that had a roadmap of how they wanted to make the Cell progress. I kept badgering them to show me this map, thinking that they didn’t want to share this for proprietary reasons. The Toyota guys always refused, explaining that they didn’t have a roadmap. All they were doing was focusing on problems as they appeared and then working hard at solving them. One day, exasperated with my annoying questions, the lead engineer said to me” “WE DON’T HAVE A ROADMAP. But—we do have kind of a golden rule: making people before making parts.” I’ve tried to puzzle this out ever since.

Toyota differs radically from most modern firms in the fundamental assumption that people, not systems, make the best products and deliver the financial performance. The Toyota saying is that “there can be no successful monozukuri (making things) without  hitozukuri (making people).” Indeed, the true function of the Toyota Production System is to develop people first, in order to make better products through better thinking. That’s why some have said TPS can also be termed the “Thinking” Production System.

The terms can be confusing. We often see TPS as a system (as it calls itself) that controls people more narrowly with a pull system, and Andon system and so on. Over time I have come to realize that the TPS is not as much of a “schedule and control” system that deals with matters such as IT, workflows, and procedures, than it is a system of on-the-job training whose fundamental aim is “hitozukuri” – developing people.

But how can developing people generate leaner processes? Why would people, on their own accord, be more rigorous, less wasteful, and look for smarter, lower investment solutions? Especially when highly trained experts display a human tendency to focus on their narrow specialist interests rather than the overall flow or the company, and certainly not their customers.

4 Steps

The answer, once more, has to do with the system. Developing people within the lean sphere has in fact four very clear meanings: (1) knowing the detail of one’s own operations; (2) seeing the main Waste generated by one’s own activity; (3) deepening one’s fundamental knowledge about the job and (4) developing one’s ability to Work with colleagues across functional barriers.

The first step involves developing a thorough, detailed, understanding of one’s own operations. This may sound obvious, but experience shows that this is rarely the case on the Gemba. Very few operators, for example, who perform a repetitive job can make exactly the same gestures from one cycle to the next. When you discuss this with them, you’ll often discover that they have only a vague notion of the desired outcome (make the part) and how to do it (use this machine). This lack of understanding becomes even more pronounced in non-manufacturing jobs. How many people can precisely breakdown the routines of their jobs in repetitive steps? Most employees will argue that they never perform the same task in exactly the same conditions, so they’re bound to do it differently. In fact they can learn standard Work regardless of their setting. And so the first part of developing people is to teach them to understand the details of their own operations – in a wide range of circumstances.

The next aspect to developing people is helping them learn to see the main Waste in their current way of working. There’s always a problem that produces Waste, and that’s okay. No Process can ever be perfect. Too often, we consider the Waste to be part of the job. For instance, as a writer, I accept that rewrites are a necessary evil to get to a good text (they are) – but I have to also accept that rewrites reflect some of my weaknesses as a writer, and by thinking of some things upfront, I can Work to minimize them. Yesterday on the shop floor, the team leaders said that the main Waste in their assembly operations of large machines was the amount of unnecessary walking; and so they intended to reduce Waste by changing how parts got to the operator. Once people accept that there is inevitably some Waste in the way they’ve chosen to Work (and that it’s okay – no blame attached), and that this Waste can be reduced with a little scratching of heads, then processes will become leaner.

Third, we want to develop people’s deep knowledge about the underlying principles of their Work. Social science studies show that the main difference between experts and novices is their understanding of underlying structures. Novices for instance, will tend to project the curved trajectory of a ball as a curve, where experts will rely on the fundamental laws of motion to project a straight line and so on. Engineers need to know more about the physics of the processes they design, marketers need to know more about the real-life usages of the segments they Work with, but operators also need to know more about the fundamentals of their job – be it placing bolts, screwing them or dedicated equipment. Deep knowledge is largely undervalued in non-lean companies (follow the procedure and you’ll be fine) and this generates huge wastes in the form of poor judgment. Deep knowledge is what leads you to do the right things before worrying about doing them right – and is probably the greatest driver to the competitive gap between lean companies and the rest.

Fourth: teamwork. Teamwork in the lean sense means cooperating across functions (generally by solving problems together). Teamwork is an essential component of lean processes for three main reasons: (1) treating internal customers as, well, customers and not enemies; (2) finding smart compromises with support functions – which can avoid disasters and untold exceptional expenses and (3) adult learning mostly occurs through confronting perspectives with others. Without teamwork, both the learning Process and the quality of outcomes are likely to remain poor. Yet, teamwork rarely comes naturally to anyone – we prefer getting on with solving our problems on our own and then try to impose our preferred solution to our colleagues. This bias is natural and due to both the way we think and to our deep-seated control instincts (and the guilty pleasures of seeing others bend to our will). Teamwork needs to be constantly taught for people to start seeing the fundamental Value of it.

In practice, most lean tools are designed to develop one or several of the preceding aspects of competence. Typically:

• Knowing the detail of one’s operations comes through the systematic use of operations standards (step by step, highlighting the important points, explaining why) and standardized Work.
• Visualizing the main Muda in one’s own Process occurs through Kaizen. It’s tricky to tell people “you’re creating Waste, look!” Employees Work in their given processes all day long and hearing their management or outside experts claiming their Work is Waste is not likely to go down well. However, getting the same employees to run several Kaizen Workshop by looking for Waste and then picking a theme will develop their problem awareness and their ability to see typical solutions
• Deep knowledge grows out of the more structured A3 problem solving Process. Not all problems need be treated with the big guns, but at any given time, the manager may pick one topic to be explored more fully according to the A3 practices (as described in John Shook’s Managing To Learn) in order to develop the deep knowledge of their junior on a specific point.
• Teamwork can be developed by using a technique that constantly crops up in descriptions of how Toyota works, but that is less well known than other lean tools: Nemawashi. Originally, this is a gardening term meaning carefully preparing the ground and weeding before transplanting a sapling. Organizationally, this practice means going to see all stakeholders while trying to solve a problem to take into accounts various points of view. It occurs when the Team Leader helps an operator develop a suggestion by helping the operator present his or her idea to their colleagues in the team and the other shift. Or when an engineer in charge goes round the various stakeholders to develop his or her problem-solving A3.

Leaner and Smarter

Within TPS, developing people is all about managing. Toyota engineering managers spend their days working their engineers through technical problems rather than managing the engineering Process. The Toyota supervisors’ job is to maintain stability by developing standardized Work constantly. Processes are leaner because smarter people who realize there is some Waste in their area and understand how to Kaizen it away will, inevitably, come up with smarter processes. On the other hand, set-in-stone processes devised by the organizational expert or IT specialists can only run down: there is no way up. Lean Thinking is about fighting “big company disease” by encouraging entrepreneurship and the artisan’s pride in doing a good job whilst keeping the productivity and scale results of industrial operations.

“Making people before making products” expresses the radical paradigm shift pioneered by Toyota. As one CEO I know once put it: “I don’t want people who will do the job right. I can find those any time. I want people determined that the next time they’ll do the same job, they’ll do it better. Those are the people I need.” Lean Thinking’s paradigm shift is about organizing the individual on-the-job learning rather than organizing Work for employees.

Dear Gemba Coach,

I’ve just started working with lean with my team, and we’re doing a Value-stream mapping project with a consultant. While this has been challenging, and eye-opening, and a great motivator for going to the “Gemba,” I must confess something. I still don’t seem to see anything—at least anything deeply important. How can I adopt lean glasses?

There’s a beautiful Taiichi Ohno quote about this: “There is a secret to the shop floor, just as there is a secret to a magic trick. Let me tell you what it is. To get rid of Waste you have to cultivate the ability to see Waste. And you have to think about how to get rid of the Waste you’ve seen. You must repeat this--always, everywhere, tirelessly and relentlessly.” The question, of course, is that in order to “see”, you first have to “look” – so where should we look?

Ohno’s approach was the fabled chalk circle. Pick a spot in your workplace, draw a chalk circle on the floor, and stand there—literally for hours if need be—until you see some Waste. The idea is that there is Waste anywhere you look, so you will identify some just by staring open-eyed. And yet to start right away with the “Ohno circle” can be a bit steep – and not a great help in terms of focusing efforts for improvements. This method is often best for experienced lean practitioners who are already good at seeing the “obvious” Waste and need to hone their skills in seeing finer grained Waste, such as wasted motion in a machine’s Operation or detailed hand movement at a manual assembly workstation.

So what shall we look at? The lean system outlined by the TPS is a very useful guide because it tells you what needs improving right away (and then again, and again, indefinitely):

1.      Customer satisfaction: how can we see customer satisfaction on the shop floor? Is it visualized? Do we know what we need to do to improve it today?

2.      Jidoka: everywhere there’s an Operation, can we distinguish a good job from a bad job? Can operators working the Process tell the difference between a good part (or file) and a bad one? Do they have a way to stop bad parts moving along in the Process? Who do they call for help when they find a bad job or if they have a doubt?

3.      Just-in-time: Is the flow of parts clearly visible? This is where spaghetti charts and VSM help the most. Is the flow of parts smooth? Or do we find accumulations of parts here and there (or worse, in the warehouse!)? Is there anyway to see how the production pace relates to the sales pace?

4.      Standardized Work and Kaizen: are workers following repetitive sequences of steps, or do they move around randomly running after what needs to be done? Can they tell whether they are ahead or late? Can we see their problems? Is there evidence of Kaizen at the workplace

Focus on 6 Areas

In other words, to practice seeing we need to practice looking, and we can start by focusing on five areas: looking at whether safety rules are respected, looking at how we serve customers, looking at how we check quality, looking at how we schedule Work, looking at how we move parts around and looking at how we organize people’s Work. Try asking the following questions:

1. Are the safety rules clear? Are they respected? Is the environment safe? Before even thinking about more “lean” approaches, a straightforward safety audit will open your team’s eyes to your workplace and to the working conditions you impose on your staff. Personally, if I want to have a quick rule-of-thumb estimation of any company, I’ll look at their accident record and their Inventory level – these two figures give you a pretty good picture of the company’s health.

2. How do we serve customers? Start by going to the shipping area and ask to see how it is organized to deliver to customers. Usually, people will have a shipping or loading schedule, but very little information about what the customer expects – this falls in the area of sales admin. Compare what the customer has actually asked for (before negotiation) with the loading plan in use. Looking at that is usually enough to keep a Kaizen team busy for months working at fixing on-time-delivery.

3. Are we sure we only ship good parts? This is the next place to investigate how well quality is checked at every Process. More specifically, how do operators know whether they’re doing a good job or a bad job? In many cases, this is no idle question as few processes have been defined in such detail. This will prompt operators to explore how they can ensure that no bad parts reach the next Process. Looking at that will reveal many correction wastes, and give you the opportunity to schedule many Kaizen workshops.

4. How do we schedule parts? This is typically hard to see, but the easiest place to look is the Inventory: how many days of stock on hand do we have for main parts? How long have the low running parts staid in the “parts hotel” in the warehouse? Looking at the Inventory will give you a good idea of how precise the scheduling is and what kind of Overproduction decisions are taken.

5. How do we move parts around? This is what you’ve probably done with the Value Stream Exercise. Following a part, a customer, or a project from wall-to-wall allows you to see right away the complexity of the Process and the barriers to flow.

6. How do we organize people’s Work? Last but not least, we can stop at every workstation and look at how people Work: foot movement, hand movement, eye movement. The way I do it is visualize a frame in front of the operator and take note of every movement that takes his or her hands out of that frame. Then we can wonder about how the operator sees his or her role: What does it mean to succeed at this job during one shift? Then we can look for Work standards: is the difference between a good job and a bad job explicit on the stations? Are operations done in a stable sequence and so on? As a very first step we should be able to spot irritants (or outright dangerous) operations the operator has to deal with, and which could probably be taken out with a little forethought. Good place to start.

Having practiced looking at your workplace for a while, you can get started with doing. Assemble a small Work team at one of the five previous points where you’ve spotted something glaringly obvious, and ask them to improve. To get started, the rules are simple:

1.      No investment (okay to some very limited spending, but no money to buy equipment)

2.      Do the best you can to improve the Process

Yes, I realize this sounds vague compared to what I’ve said in other columns regarding planning Kaizen workshops, but this will get you going. You need to help some people start improving autonomously rather than follow the long action plan drawn up in the meeting room after the Value Stream Mapping exercise. These actions are not about improving the Process right away, but teaching every one to look and see further than the obvious.

Chances are, they will improve. Chances are, the teams will also reveal: (1) some deep overall problems of your operations (simply by hitting the barrier while trying to improve) and (2) draw out what your operations could look like if these issues were solved across the board. Once you’ve got a clearer idea of what your target conditions could be at the workplace, it’s time to get that A3 piece of paper out again and redraw the VSM – in a way that reflects the problem you’ve seen on the Gemba as you now understand it. And so on.

Dear Gemba Coach,

How do you balance the sometime conflicting practices of gaining employee engagement while ensuring that everyone remains faithful to known lean tools and principles?  In other words, when a Kaizen team arrives at a solution that you know to be flawed with respect to the overall Value Stream or lean principles, how do you get them on the right path quickly without sending the message that you are not listening to them nor do you truly Value their input and ownership of the problem?

That’s a tricky question, and undoubtedly an uncomfortable position to be in. It’s a very good question because the two pillars of the Toyota Way, continuous improvement and respect for people, are not always immediately compatible. In this case, the need for continuous improvement demands that the group move in the right direction with the right kind of solution. Their engagement, however, is linked to how much autonomy they have in running and improving their own workspace. Your job is to find the sweet spot where the ideas of the Kaizen team reflect a deeper lean principle and the solutions are both pragmatic and useful to “lean” the Process further.

Defining “Check”

The underlying question here is how to define a successful Kaizen exercise. Ask yourself: what kind of solution is satisfactory? What sort of team interaction is sought? One of the key tenets of Lean Thinking is not to start spelling out solutions until a standard and a test method has been defined. What is it that allows you to see the solution is flawed but not the group? This discrepancy reflects the fact that your standard and test method differs from theirs, which, in turn, means they were not clearly defined at the outset.

One of the key aims of any Kaizen Workshop is to get people to practice PDCA in real life. The Kaizen event, in itself, is also part of a PDCA cycle. There is a Plan phase before the event, then a Do phase (the event itself), a Check phase (right after the event, one week, three weeks after, etc.) and an Act phase: what have we learned from doing this Kaizen event, and what can we adopt for the future. Typically, getting bogged down in the Do phase reflects a weakness at the phase: Plan.

How should one prepare for a Kaizen event?  Well, to be honest, one should have realized most of the Work already, in defining the scope of the problem, picking the group and so on. The leader of the event should already have a good idea of what the problem is and some idea of a solution (can’t help himself or herself, that’s the way the mind works). So, to avoid either forcing a solution on participants, or asking too open questions, the trick is to define the Check at the Plan phase. Having done Plan, one should be able to formulate quickly the standard, and the test method for the kind of solutions sought. The role of the workshop is to get people to understand the problem in detail (often not what the preparation had highlighted) and to come up with solutions that pass the Check test defined during preparation.

Pre-defining the test method should avoid too great a divergence between the solutions the group is likely to invent and the “correct” solution in the facilitator’s mind. If the group comes up with something clearly inappropriate, the facilitator’s Work is to bring the discussion back to better clarifying the problem or testing whether this idea would fit the test method (no, purchasing a new press doesn’t fit with the “no investment” requirement for this Kaizen exercise).

Facilitation Failure

Still some groups do go off in weird directions, confusing the act of inventing a workaround for the problem with looking for a fundamental solution. As you correctly note, being too heavy handed in imposing your solution will lead to either (1) the team closing ranks against the facilitator, and reaching a deadlock or (2) the team nodding on without buy-in: fine, if that’s what you want, I’ll rubber stamp it, but it’s not my solution so don’t expect me to stand by it

As a facilitator, we’re often as much part of the problem as part of the solution. I personally believe that most conflicts stem from a mix of misunderstandings and hot tempers. By the time the facilitator defends his or her solution to the team, the odds are that (1) the problem is not shared and that (2) tempers are running high. The difficulty, as a facilitator, is to recognize the adversity early, and not steam-roll it. Many facilitators end up in hot water because of their over-reliance on the Process: they want to get ahead, and to move the group on towards a solution. However, if something is stalling the group, chances are a deeper problem is lurking there which has not been identified, and pushing the group along will end-up precisely where we don’t want to be, with the “wrong” kind of solution.

It’s important to recognize this form of adversity early on and to spend the time it takes to surface the underlying beliefs held by the participants. At this stage, although it may not be part of the formal agenda, one might want to drop the team discussions and send every one back to the Gemba to do some more observations. The key thing is to accept that the misalignment is mostly created by the facilitator failing to realize that the group was moving into an adversarial position, and not taking the time to make beliefs explicit and then comparing them to actual facts derived from direct observation.

Beliefs are never idle – in people’s minds, they’re often indistinguishable from consequences. We constantly visualize a mix of our beliefs and their (exaggerated) impacts on the situation – hence the sometimes bizarre dead-ends that a group can wander into. To avoid this, you essentially need to develop a set of special skills as a facilitator: (1) feel adversity when it starts to happen; (2) get to the bottom of the beliefs that create this adversity and (3) make explicit the consequences participants expect from these beliefs. When you are able to specify what is at stake, what can happen, beliefs can be attacked by Gemba observation and consequences can be questioned and disputed until the group re-frames its thinking and reaches more reasonable conclusions.

As a Kaizen facilitator, I believe this should be a large part of the “Act” of the PDCA cycle: during the event, which misconceptions emerged? Are participants better aware of their wrong-headed beliefs? Will new beliefs now guide them to more relevant actions – and hence leaner processes? This, as much as the real “physical” change on the Gemba, is an important outcome to seek. If you’ve moved some equipment around but not changed the people’s beliefs about how this equipment is to be used effectively, you’ll find out that the change won’t last very long and won’t have the hoped for effects.

Pull the Cord

To sum up, it’s at the preparation phase of the Kaizen events that important questions such as “how will I see that the workshop has been successful?” and “what is the main point I want them to figure out in this area?” have to be stated clearly, so that you can walk into the workshop with a clear standard (the lean principle relevant to this situation) and test method (what are the characteristics required from any “solution”).

Secondly, as a facilitator it’s important to develop one’s sensitivity to adversity (feeling when the group is not behaving as it should), and then pull the Andon chord: hang the agenda, let’s reexamine our assumptions (mostly by going back to the Gemba) to surface beliefs and expectations, until people have agreed on how they see the problem. Don’t let yourself be drawn into a discussion about solutions until you’ve reached an agreement on the nature of the problem.

Dear Gemba Coach,

I’m in charge of the engineering department in our company and the CEO has asked me to start with lean. I’ve been reading the books and it seems very complicated and geared towards much bigger outfits than ours. I’m at a loss as where to start in practice – any advice?

Okay – take a deep breath and plunge in. Let’s start at the beginning: what is the problem you are trying to solve? Or more to the point, what problem does your CEO have in mind? Usually, the issue I come across is senior managers who feel they’re not getting their money’s worth out of the engineering department. These senior managers complain that projects are late, over budget, and aren’t keeping clients happy either. I’m not saying that your department is guilty of these flaws—but the fact that your CEO may feel that you are guilty matters.

Before starting any lean engineering initiative, it would be worthwhile spending some time with your CEO clarifying his or her objectives in terms of the results he or she expect from lean engineering. A great way to start is by visiting the Gemba and looking at a couple of projects together. This enables you to piece together a common understanding of what’s right and what’s wrong with both the resulting product and the development Process.

What are we looking for? A fundamental lean principle is that our misconceptions create unnecessary costs (Waste) that can be eliminated if we can fix our wrong-headedness. Where, in engineering terms, are we creating extra costs? Firstly, there are excessive costs to customers. A product or service that does not fit the purpose the customer has in mind generates unnecessary cost of ownership for the customer. If the product breaks down, it needs to be repaired – which has a cost, both financially and in hassle terms. If the product is not easy to use, it has a cost in pain and peace of mind, and so on. The second form of excessive cost produced by our misconceptions in design and development deal with cost of the product itself: its material content, the labor hours needed to put it together, the investment in equipment and so on. The third area to monitor for excessive cost is in the engineering project itself, as unnecessary design hours will count both as man-hours costs and all the other costs associated with being late.  Your fundamental challenge in applying lean to your engineering initiative is to spot what you doing wrong and then to Kaizen it away.

Lean principles can help with one of the toughest challenges for people working together: recognizing one’s own misconceptions. In project Work, it’s harder to distinguish between our Work that delivers Value to the customer from that which is Waste, than it is in operations. You cannot boost engineering productivity, for example, by forcing engineers to Work longer hours on more projects. Engineering productivity is linked to engineers’ capability to find the correct solution to engineering problems on their first try. It’s a completely different ball game. Adding Work and pressure to engineers just makes them bog down, or go too quickly with workaround solutions that are not in fact solutions at all.

In this respect, lean practice can help in engineering, just as it does in manufacturing, by looking at your issues in a lean light:

1. Are customers completely satisfied? This is always the most fundamental question to ask—yet it is never an easy one, as companies are seldom equipped to answer it. One practical way to start is invite various functions such as sales, marketing, post-sales service, and so forth, to a workshop on the performance of the new product. Solicit every point of view on how well the new release is performing, assessing it against competitor’s products, against your former products, always trying to understand it from the customer’s point of view. What benefits are they enjoying? Are there trade-offs involved?
2. Is project lead-time under control? Using a simple GANTT format, plot your recent projects, tracking the start date, initially planned completion date (when engineering resources are no longer needed on the project) and actual completion date (when engineering resources are really pulled out of the project). This visual record will give an immediate feel for how well the engineering department is controlling its lead-time, as well as issues about leveling and resource planning. 
3. Can we reduce some project lead-times? Here a “lean” engineering project might make sense – pick one pilot project, and try to get the lead-time down by hook or by crook, starting with a Value-stream map of the project and driving Kaizen hard. This will not solve the engineering department’s problems, but will help you get a hands-on feel for what the problems really are. As you Work at reducing reduce lead-time, all the barriers the company throws at you will be revealed as a gift, or sorts. This is like sending an advance team into an ambush to find out where the enemy positions are. 
4. Can we reduce cost? Reducing one project’s lead-time will surface many opportunities for cost reduction, which need to be tackled with care. The difficulty here is that for costs to be truly reduced and not pop up somewhere else (worse case, in cost of ownership at the customer’s), a real effort has to be made first to stabilize the whole engineering flow and control project lead-time.

So where to start? The temptation in engineering is to start worrying about costs before customer satisfaction. Management will push for more detailed timesheets to better understand what engineers are spending their time on and more rigorous project management with all the paraphernalia of gate reviews, steering committees, project plans and so on. Experience shows that you might succeed in the short term, but at the cost of untold damage to your engineering competence by pissing off engineers and distracting them from the fundamental issue of coming up with better products than the competition.

From the lean perspective, the place to start has to be complete customer satisfaction. Clarify who has ultimate responsibility for that. In your organizations, do the project leaders have access to customers? Do they have explicit responsibility to fulfill customer needs? Or are they expected to design to specs drawn out by marketing and signed off by management? 

For lean to stick in any engineering department, everyone must accept that one physical person (the project leader) must integrate all information from customers, marketing, sales, aftermarket, etc. and come up with a technical vision of what customers really want. We’ve all been through endless horror stories where the first prototype is shown to customers and they say: “sure, all the boxes on the checklist are ticked, but that’s not what we want!” An automotive Dashboard for a medium range car is not the same as for a luxury brand: it might have the same functionality, but it doesn’t feel the same.

Getting started with lean in engineering requires taking a hard look at what is expected from project leaders: do they have full responsibility for satisfying a customer or are they simply expected to design to spec? As with many lean initiatives, defining success is the starting point of deeper thinking. By “respect,” as John Shook has brilliantly pointed out in his Sloan article, we mean that every person has a right to succeed in his or her job – so success must be clearly defined.

Engineering projects are complex inasmuch as “clear” goals often hide deep trade-offs between innovation and reliable technology, between look and feel and price, between performance and customer usage, between internal competence and resources and so on. Clarifying such complex trade-offs and getting them right is almost impossible to do from the outset – this is precisely, in Lean Thinking, the first responsibility of the project leader.

So here’s the question to ask yourself to get started on your lean journey: are we really convinced that Value is defined by the customer (as opposed to what we, internally believe)? And does the project leader has end-to-end responsibility to specify the Value as defined by customers, and to deliver this Value in the forms of products or services which can be build consistently at quality and cost requirements?

To discuss this and other points of views on lean, join me on The Lean Edge

Dear Gemba Coach,

Our corporate production system asks us to post standard Work at workstations, but we feel that the paperwork clutters the stations and operators tell us they don’t use it in any case. Should standards be posted at the workstation?

Operators are most likely right. I don’t mean to nitpick, but I’m not sure which document you refer to as “Work standards.” In the “standardized Work toolbox”, we usually find four documents:

1. Standardized Work chart: this is a graphic chart which fits on an A4 paper (8 1/2 x 11inches) and draws the Cell from the ceiling, numbering operations and essentially describing the standard sequence of steps the operator has to follow to realize the Work within target Cycle Time (a few seconds lower than Takt Time), with the number of standard parts in the Process, and visual indications of safety and quality checkpoints. This is the only “standards” document we’ll post on the workstation.
2. Operations standard instruction sheet: this is a list detailing each step to actually make the part, the key point to note at each step and drawings or photos to clarify tricky operations which involve unnatural hand movements and so on. As the Work on standardized Work progresses, this instruction sheet can grow to several sheets as a result of analyzing movements in greater and greater detail. Consequently, this will not be posted on the workstation, but typically held in a nearby binder, close to the workstation.
3. Standardized Work combination table: this a synthetic sheet showing the full cycle divided in tiny time increments and visualizing as in a GANTT chart the manual Work, walking time and machine Work necessary to make the part. The Work combination table is essentially about timing each of the key job components to make the part and is linked to the supervisor’s Work with the stopwatch to identify the best times (repeatable minimums) and train operators to pace their Work accordingly. It will not be posted on the Cell either.
4. Process Capacity Sheet: this last, essential document, is, for some reason, rarely seen in corporate production systems. It focuses on machine Work and lists step by step the manual time, the machine time, the total completion time for the step, the Changeover time, enabling people to determine the standard number of parts one can expect from each piece of equipment during one shift. Knowing the processing capacity of each machine per shift is essential to check whether machines are performing at standard and identifying the bottlenecks in each Cell.

Of these four documents, only the standardized Work chart should be posted on the Cell: it’s an A4 drawing and doesn’t take too much space so it shouldn’t add to the clutter. Of the four documents this is the only one likely to be used by operators and team leaders during a Work cycle.

The fundamental question to ask yourself is: who are these documents for? The operators? They do the Work, day in day out, so they know what they’re doing (even if they sometimes don’t do it right). Why should they need paperwork to tell them their jobs? And in practice, other than with a very fresh temp (and even so), one rarely sees any operator refer to the long operations standard sheets which are posted on many cells, sometimes in binders hanging loosely over their heads.

Using the Whatchamacallit

Why is there so much Muda in any workstation? Typically, engineers understand what needs to be done to build a part (or perform a service job), but not how to do it. They can tell your that the gizmo has to be clipped into the thingy and then you need to apply the whatchamacallit, but they can’t tell you that in order to clip the gizmo, you’ve got to push it in lightly then turn slightly, as opposed to forcing it in until it fits. Only operators will know how to actually do the Work with the least mental and physical burden. That’s because they explore the Work hundreds of times a shift and will eventually hit upon the tricks of the trade that reduce the Muda inherent with the design.

Understanding Work at this level of detail is key for frontline management. To some extent, in lean, eradicating Muda from workstations by working with operators on standardized Work is the main aspect of frontline management. This is a privileged moment to Work with operators, improve the Process and develop mutual trust. Yet, because supervisors are not on the line making parts, they need tools to understand the detail of the Work and see what operators do.

My Sensei recently showed me a workstation where the operator had to place four small pins in a metal base, add a lid and then place the assembly in a small press activated by putting both hands on two manual buttons. For safety reasons, both hands have to be on the triggers to make sure the operator hasn’t got a hand near the tool. Since the part is fairly small and light it’s tempting to pick it up with one hand, place it in the jig and trigger the press with the other hand at the same time – but quite scary from a safety perspective.

Stopwatch in hand, he timed the Operation (a few seconds, I’ll never be that good at taking times!) for one worker, and then we came back for a second timing after shift change. The second person was significantly faster. I stared and stared but could not see any difference in the way the faster operator was working. He was following the same sequence of steps, in the same position, and basically doing the same “standard” job as the first one. Until my Sensei pointed out the position of his wrists. Rather than use his hands to press the start buttons, the second operator rested his wrists on them, which enabled him to go much faster in placing and pressing, but also kept his hands much closer to the press tool when it came down. I’ve been watching factory operations for decades by now, and still need to wash my eyes of the dirt that stops me from seeing! (none of the other guys working in the factory had seen it either – but that’s no excuse).

Where Kaizen Begins

This is exactly the level of detail we need to operate at when working with operators to help them execute safely and find ideas for Kaizen that removes Muda. The standardized Work sheets are a tool for managers to learn to see and to Work with operators to improve their own workstations. Without these sheets and the observation they generate, the conversation will stick with generalities and never be narrowed down to the real difference-making “hows.”

 As such, standardized Work documents should be somewhere close to the workstation, but not necessarily posted. Each workstation should have a folder nearby with its Operation standards, Work combination and Process capacity sheets, fully completed and updated, but not posted. These documents will be pulled out by the supervisor in training exercises to check with the operators they’re following the standards or if not why? This is where Kaizen begins: it’s rarely a matter of compliance. Usually, something is happening in the workstation’s environment that makes following the standard impractical if you have to do it 700 times a shift and operators have found a workaround. Identifying these workarounds, understanding their root cause and asking for suggestions to keep or improve the standard is precisely the supervisor’s job in a lean workplace.

The one exception is the standardized Work chart, which will be posted on the workstation. When an operator is having trouble keeping up with the cycle (which will show up by making the next person in the line wait) or is having trouble with quality aspects (which she will detect, will be blocked by a Poka-Yoke or hopefully picked up by the next person), it’s the Team Leader’s role to rush to the station and see what happened and help decide whether to call for a line stop to solve the problem.

The first place to start is checking whether the operator is following the set sequence of steps outlined in the standardized Work sheet. In this case, having it on the workstation is a support for the operator/Team Leader conversation: this is an objective teamwork document that removes the subjective elements of “this is how I do the Work.” A quick check is usually enough to see whether a step is missing (such as missing a component, or losing time by getting a sequence of assembly wrong) and the Team Leader can teach the person how to do the Work correctly on the spot. Having checked that the sequence is carried out correctly, the problem remains, the Team Leader will have to stop the line, call the supervisor and start the investigation to figure out what is really wrong at the station.

The standardized Work chart is the basic teamwork document that draws how we’ve agreed to do the Work. It’s just one A4 per station, and I’ve yet to see a Process where it can’t be astutely posted visibly without getting in the operator’s way.

Frontline Management Tools

To answer your question directly, the reflex question I have been taught to develop is to ask myself: what is the operator’s role with this tool? If the operator doesn’t do anything with the tool within the cycle, it shouldn’t be posted on the Cell – period. The standardized Work chart will be used as a teamwork tool to support the operator/Team Leader conversation on how Work is going, so it has a legitimate place on the station. All the other documents are tools for frontline management, not directly for operators.

If your own central team argues that operators should read from the operations standards to figure out how to build the parts right, my recommendation is you suggest they try assembling parts for a few consecutive shifts, and see how easy it is to figure out the proper movement from a sheet of paper. The charts are support for the supervisor’s understanding of the job and training of the operators – not “instructions” for the operator on the line to read and deal with himself or herself.

In a way, as lean guys, we should ask the same question of every lean tool: who uses it to do what and how? And we have the same problems supervisors face everyday. It’s easy to pick up the tools on the web or in a book, but the templates only tell you’re the “what”. Our problem is to figure out the “who” to use them correctly. To do so, we need to focus on the roles each person has in using each tool.

Dear Gemba Coach

I am a Kaizen coach in a large company, and it never seems to get any easier. We’ve been doing Kaizen for several years but people seem just as resistant, the problems we face are just as huge, and our Sensei is never satisfied. I find it hard to remain positive, and am not the only one in our group who experiences this sense of discouragement. Do you have any advice?

Thank you for that question, which is a thorny one, and unfortunately not uncommon in the lean efforts I’ve come across. At the Gemba, lean can indeed be difficult. Fostering the Kaizen spirit means chipping away at issues continually, even while people feel overwhelmed with simple day-to-day Work. They legitimately perceive Kaizen events as an increase in their workload and a perturbation in their Work. Unless they also believe that as a result of the Kaizen they will have gained in autonomy and competence, the net result of anticipating a Kaizen event will be increased stress. Understandably, they’ll drag their feet to attend.

There is one aspect of lean tradition that might help. Soichiro Toyoda, one of Toyota’s key players, once chairman and father of the present President, formulated the three Cs that became the basis of the “Challenge” dimension of the Toyota Way: Challenge, Courage, and Creativity. Breaking this down, challenge is defined as: “We form a long-term vision meeting challenges with courage and creativity to realize our dreams.” Okay, you’ll think, more lean slogans, jargon, and Japanese folklore? How does that help in practice?

As part of my research in how to implement lean outside of Toyota I’ve often been struck how many aspects of Toyota’s teachings that we consider to be Japanese folklore are in fact bona fide tools to help us deal with difficult situations. I’ve also grown increasingly respectful of how astutely they have, over time and in a very tradition-laden way, recapitulated a number of sophisticated psychological concepts. In this instance, I’d like to refer to psychologist C. R. Snyder’s Work on hope. Snyder was one of the foremost thinkers in the relatively new field of “positive psychology” and he developed a powerful and original theory of hope. By studying people in concrete situations, Snyder came to focus on hope as goal-directed thinking which blends the perceived capacity to find routes to our goals and the motivation to use those routes. Snyder defines hope as:

Hope = Mental Willpower + Waypower for Goals

Mental willpower is the energy, attitude, and persistence one brings to meetings one’s goals, and waypower is the capacity to generate alternate plans to do so. Both are particularly important in the face of the inevitable setbacks, since one needs to: 1) not give up and find the energy to stay the course as well as 2) invent different routes to the goal if the way is blocked. That is exactly what the “Challenge” concept expresses. In order to realize our dreams (hope), we need to be clear on the three Cs: challenges (goals), courage (willpower) and creativity (waypower).

How does this help at the Gemba? Well, having an operational definition of the terms helps considerably. The three main strategies we can develop here are: first, clarify the goals; second, rebuild your willpower by focusing on past successes; and third, develop waypower by trusting the lean tools.

The first step in rebuilding a positive attitude to Kaizen is to make sure the Kaizen goals are crystal clear. You must be able to address the simple question of “what is the problem you’re trying to solve?” Most groups get bogged down when they go for “open eyed improvement” (look at all that’s wrong and see if we can find something to fix) or blinkered tool implementation (we were told to implement a Kanban, so that’s what we’re doing). Understanding the problem in detail and expressing it clearly is key for the group. As psychologists know we are irredeemably goal-seeking creatures. Try NOT to think about goals. Can you do it right now? Or is that already a goal?

The clearer the goal, the better we all feel. In Kaizen events, I typically look at five main goals:

1. Improve ergonomics (lower mental and physical burden)
2. Improve quality (fewer ppms)
3. Improve productivity (higher pphs)
4. Improve lead-time (fewer Inventory days)
5. Improve environment (lower consumable bill)

The idea for the Kaizen is to focus on one of these five objectives without losing ground on the other four. Clarifying the goal, such as “improve productivity by better balancing the line” or “improve ergonomics by using smaller containers” and so forth, is a great way to focus the group on what we want to achieve.

Remember as well that as a Kaizen coach, your goal is not exactly the same as the participants. While you want to improve things, your main goal is to develop their engagement and autonomy. They will feel motivated if they get good results, for sure. But they also need to realize the solution themselves. If you direct them too forcefully, the workshop is likely to end on a disappointment, because no matter what the benefit, they won’t be interested or thankful. Your main goal is to get them to Work through their own problems and build their own solutions by practicing with the tools you give them. Dumping the corporate one-size fits all Kanban system on them won’t do much in that respect.

Rebuilding Courage

Kaizen means endlessly starting again. Quite legitimately, some days you feel down, tired, and not quite up to revving up one more group to solve one more problem they should have dealt with on their own a long time ago. We all have ups and downs. And sometimes, the challenge simply seems so great that we don’t feel up to it, period. We’ve all thought: I’ve had it, I can’t, it’s not worth it, I am not up to this and so on, all the more so in the Kaizen coach position since that’s exactly what the participants are going to be telling you. Courage can be either chronically low, or recently drained by a tough break. But in any case, it’s useful to see it as a renewable stock, not a fixed quantity. The first step to having courage is to rebuild courage. If you feel low energy about doing the job, spend some time rebuilding that flow of enthusiasm rather than drag yourself through the event through sheer discipline. You might force yourself this time, but what about the next? And if it doesn’t go well, you’ll end up feeling even more negative about the job.

The most practical way of doing this is rehearsing all the previous cases where you have succeeded: the group has had some positive results, and reached this through their own ideas and by working together. Even if the result is not all the way up to the objectives, your goal of getting participants to Work together and develop their engagement and autonomy by improving their Process has been reached. Rather than rehash your perceived failures, give yourself some time to rethink of all the good times. And as for real disasters, and we’ve all had some, let’s try to find the humor in them. It’s hard on the morning after, but a few months later, the funny side is often more apparent. So here’s the pep talk you can give yourself: this is your chosen job (if not, hmm, maybe a rethink is in order?), you’ve succeeded at it many times, and you’ve survived the few disasters to fight another day. Helping the group to Work together to understand and improve their own situation is a good thing to do, I’ve succeeded in the past and I will see this as a chance to stretch myself and do some good.

Alternate Routes

Sometimes, there is will, but without the way. Some situations appear so daunting we simply don’t see how we can come through in one piece. No matter how much courage you have, you can still be stuck. On this front, you’re lucky to be working with lean because it has a long tradition of dealing with impossible challenges. The first step is to think “Kaizen”: let’s break down the larger goal in smaller ones: 100 times 1% rather than 1 time 100 percent. Secondly, trust the lean principles and tools. They are the result of a cumulative Process of more than sixty years. Whenever I’ve found myself stuck on the shop floor, it always emerged later I had ignored one of the basic principles. So, go back to the basics and apply the tools even if it doesn’t feel that it applies. For instance, in many cases, people tell me “Takt Time” doesn’t apply. Takt Time always does, why shouldn’t it? It’s about dividing open time by workload to get a rhythm of delivery. This is where creativity is useful: how can we apply takt to a job shop environment? Or to projects? Or to service? Usually this mental exercise is enough to get you unstuck. And if one principle doesn’t do the trick, try another one.

The other trick to develop waypower is to plan for alternate routes. Rather than let people jump to their preferred solution right away, get them to formulate at least two valid alternate ways of doing whatever they want to do. This will usually lead them to clarify their goals further by better understanding the problem they’re trying to solve. One useful technique is “walk through talk through’: by rehearsing several alternate routes step by step, you can build waypower by creatively thinking of new ways of doing things.

Hope is not a vague thing we’re born with (or without). It’s not optimism or cheerfulness or blind confidence that all is for the best and will turn out well in the end. It’s a skill in itself which one can develop in the course of challenging jobs such as being a Kaizen coach. Challenge, courage, and creativity are not vague exhortations, they are practical tools to build up your capacity to change the world one step at a time.

As for the Sensei? Think of it this way. From the start, the senseis have told us their challenge is not to implement lean in every Process but to develop the Kaizen mindset in every employee. The Sensei’s goal is NOT to make you feel good about what you’ve done (recognition or praise is your boss’ job – if she or he is not doing this, you’ve got a problem of another nature). The Sensei’s job is to stretch you by keeping you thinking and realizing that the moment Kaizen has delivered a result, it’s time to start again. So don’t worry about it: senseis are never happy – they can’t be. If you get a chance to have a quiet beer with the guy later on, he’ll probably tell you how impressed he is with your overall progress, but on the Gemba, the Sensei’s job is to point out what has NOT been achieved – which usually means that the Process has not been challenged deeply enough. There you go: a new cycle of challenge, creativity, and courage! As a Kaizen coach, try not to see difficulties or setbacks as letdowns, but as chances to practice your craft.

Dear Gemba Coach,

I’m in manufacturing engineering and have been asked to design a lean line. I’ve participated to several Kaizen workshops and have some general ideas about how to go about it, but I’ve also heard many horror stories of lines that were designed so “lean” they can’t run in practice. Any ideas as to how lean should lean be?

How lean is lean? Good point, and hard to answer without more specifics about what kind of line you’re looking into, but I do understand your concern. I have indeed seen lines designed to be lean and totally impractical to run on a daily basis.

What should a lean line look like? The focus of any lean line is its operators. Ideally, they should sow the components like a farmer sowing a field and all parts should assemble easily and naturally into a faultless product. In particular, this means that (1) workstations are designed to make assembly easy, (2) the product can flow from one station to the next without in-between accumulation and (3) the line should be flexible in mix as well as volume, with quick and smooth changeovers, and (4) mistake proofing devices should stop defectives without encumbering the line with over-complex systems.

From the operator’s point of view, let’s imagine a tray table fitted on your airplane seat for a business class dinner about ten inches deep and twenty inches wide. All components should reach the operator in that range so that hand movements can be within easy reach and avoid ergonomic strain. This, in turn, involves VERY small containers for components. A good sign is when you can’t find containers small enough in industrial equipment catalogues and need to go to Wal-Mart to shop for Tupperware.

The part itself should flow smoothly from one person to the next, so that it can be handed over hand-to-hand, as a baton in a relay race. This means initially having operator workstations placed next to each other – by no means a small feat with most semi-automatic machinery – and without any barriers to hinder part movement. One of the best lines I’ve seen had parts auto-ejected by machines and pushed along the line by operators on simple rollers, with machine cycles triggered by thin joysticks.

Ideally, machines on the line should be able to change tools in “one touch/one breath” – the idea is that the tool change occurs in the time it takes to draw one breath. Hardly realistic in most processes I know, but still a worthwhile goal to pursue. In any case, ease of Changeover – by the operators themselves rather than specialized setters – is a key component for a lean line.

Finally, the line should be fitted with smart error-proofing devices (Poka-Yoke) to stop defectives from moving forward in the Process, but without encumbering the line with hydraulics, cameras, and over-sophisticated electronics which will encumber the line more than anything else. I’ve lost count of production lines where operators have disabled the “poka-yokes” dreamed up by engineers just to be able to run the line.

3 Common Problems

If you add the usual lean criteria that the machines should not be wider than the part they make by more than 20% and that the spread of the “U” (in case of loading/unloading machines – if not a straight “I” line is better) should be less than 50 inches, you could design a very lean line indeed. The question is would it run?

Let’s look at the problem the other way around: why are existing lines so full of Waste? The production lines I see on the Gemba tend to suffer from three common ailments. First, equipment manufacturers propose large machines with lots of conveyors; second, manufacturing engineering tends to specify buffers in order to keep production running even when there’s a problem; and finally, both equipment vendors and manufacturing engineers tend to be partial to a lot of unnecessary automation.

To be fair on the first point, it’s hard to make a complex machine with a small window facing the operator. Usually, the equipment manufacturer (I’ve worked with some on their designs) will have a favored design on the manufacturing Process, and then build the supporting processes around them, wrap the result with some solid steel and glass and then try to fit the machine in the line. Part conveyance is typically handled by internal conveyors or platters working like choo-choo trains. Designing machines to present a small window to the operator is quite challenging. Make sure parts can flow seamlessly from one machine to the next (for instance, safety lifeguards placed horizontally rather than vertically). Not to mention changeovers. All in all, the main effort in lean line design is not with the line design itself by co-developing the machines with the vendor so that they come up with the kind of equipment you need for lean.

The second issue is related to the first. Lean lines are “lean” because a lot of the variation has been taken out of the Process, and buffers become unnecessary – and, in fact, a hindrance. But on the other hand, when the machines first arrive the usual level of variation is to be expected, and chances are that a lean line (without buffers) simply won’t Work: where will the variation be stored when it occurs? To understand lean line design you have to relate every buffer to a specific form of variation in the Process, in order to visualize that if you take the buffer out, you will have to reduce the variation at that step of the Process as well. I recently had this experience with a large paint conveyor that was shortened progressively as the paint team controlled the paint Process better, and no longer needed the parts on hangers for miles on end. However, if we’d started with the existing paint Process and no conveyor, they simply wouldn’t have been able to run and would have had parts all over the place. The physical size of the line is often linked to specific variation points hard to master in the Process – whether human (in the operator cycle) or mechanical (in the machine cycle itself).

Furthermore, in order to “facilitate” operator’s Work, engineers tend to overdesign the automation on the line, with lots of hydraulics to pick up parts and place them, robots, visual captors and so on. Like the guy who ran out in the desert and sat on a cactus, when asked why they did this or that, engineers tend to answer: “at the time, it seemed like a good idea.” And, most of the time, it was a good idea, but executed with mechanical devices that add variation to the Process rather than reduce it. The automation can be too long (causing the operator to wait for doors to open and close, for tables to rotate and so on) or untrustworthy (for instance, video-control processes or light captors that have a high rate of false-positives). It’s essential to make sure that the automation of the line provides the support required without hindering the operator’s movements, creating barriers to the parts flow or add unwanted variability in the line’s operations.

Line Design Implementation

All in all, designing a “lean” line is less of a challenge than having it run at target Cycle Time. In fact, you are quite right: it’s easier to Kaizen a line to get it leaner than design it for lean at the outset, so here are two Kaizen exercises we have learned to do with manufacturing engineers to improve line design.

First, construct your planned line with cardboard boxes and ask experienced operators to pretend to run it with real parts in the Process. Run for about ten consecutive minutes, and then get the team together for Kaizen. The point of the exercise is to (1) visualize operator movements and (2) visualize parts and components flow. In many cases, we’ll find that people are so focused on getting the Process to Work that they’ve given very little thought to these aspects of running the line in production. With the operators and with logistics people, you can design the supply side of the line while the machines themselves are still a black-box. If you invite the machine manufacturer in these sessions you will radically improve the design of the line right upfront.

Secondly, once you’ve spotted the main sources of variation in the technical Process – which will need to be buffered – you can take your team to existing similar processes and run a Kaizen event to improve them right NOW. By struggling and scratching your heads on how to improve the old processes you’ll understand a lot better what to do and not to do in the new ones. Also, you will train your team to react properly to the early problems your new machines will have during ramp-up. This is equivalent to training a sailing crew to respond to unexpected maneuvers before the race rather than once the “go” signal has been given.

You probably will be able to think of other instances where this applies: the general idea is to conduct Kaizen before and during the design to help engineers correctly understand the problems they need to solve, rather than focus on what they’re interested in and let production deal with the rest as best they can.

Leanness is the outcome of a superior handling of flow and flexibility and reducing variation in any processes (since variation will show up as stoppages or buffers - Waste). None of this comes naturally, so the design teams must be trained to fix these problems if they want to avoid them in their final design. To answer your question, the line can be as lean as your teams can run it. Leaner than that, it simply won’t Work. We need to develop the teams before we can make the products, so the place to start is with a Kaizen program for the engineers themselves. In one company, the rule-of-thumb we’ve come to is that a manufacturing engineer can only start her project on a new line if she has convincingly improved the performance of an existing old one.

Dear Gemba Coach,

I am in charge of a service activity and have started a lean approach with a Sensei. In our last Gemba tour, one of my staff got very upset about the fact that we seem to point out only the negatives and never recognize all the good Work they do. The area was a mess, and most of the discussion was with her direct manager, but I feel she’s got a point. I’m curious to hear your thoughts on the matter.

Difficult question, indeed, and a real one. First of all, lean is not designed to upset people. And yet hurt feelings and discouragement are often unfortunate by-products of a disciplined lean approach. Especially when individuals feel challenged, or unable to meet constant new demands, they will see the new program as something seeking blame—looking for “who?” rather than “why?” In fact, every time someone gets emotional we, as a whole, lose points. This needn’t be the case. The aim of lean Work is to reinforce mutual trust between staff and management, not to create more pressure on employees. Of course this is easier said than done, so let’s explore just how to tackle this challenge.

Your question highlights a fundamental conundrum about managing people. On the one hand, people need positive feedback and recognition to feel motivated at Work. On the other hand, it sounds false to recognize people for just doing their job. Worse, if (in order to protect their self-esteem and bolster their confidence) we give positive feedback to people who are actually doing a poor job, we create an environment of lowered expectations in which no one is going to improve any time soon. It is tricky.

Praise and Performance

What does science say? Rodd Wagner and Jim Harter, who are researchers for the Gallup organization, have conducted literally millions of interviews for their studies. They found conclusively that while each employee may be motivated by any number of different things, every single one seeks that surge of dopamine. And yet they find that praise is rare in business settings. Their findings show that in many workplaces you will find one-fifth to one-third of employees disagreeing with the statement “In the last seven days I have received recognition or praise for doing good Work.”

Furthermore, the researchers find that regular praise and recognition boosts business performance. In one large healthcare organization, a difference of 10 percentage points on the recognition statement represented an average improvement of 11% on patients' evaluations of their experience. In one investment firm, the difference between half of its investment advisors feeling recognized and one-third feeling that way represented an 11% boost in revenue -- millions of dollars. A large, multi-company analysis puts the average benefit of such a shift in recognition at 6.5% greater productivity and 2% higher customer engagement. (See: http://gmj.gallup.com/content/28270/the-fourth-element-of-great-managing.aspx)

Yet aspiring to these healthy Work environments seems to pit two basic lean principles against each other. On the one hand, we need constant challenge to develop the Kaizen spirit; and on the other, mutual trust depends on recognizing or praising employees for doing good Work often. At the Gemba, how can we resolve this difficulty?

If we take this problem to the Gemba, I believe the first step is in fact to develop a shared understanding of what exactly we mean by “good Work.” In lean, proficiency at any job is measured on the following four levels:

Level one and two deal with the working environment as much as the person. Does the workplace enable individuals to understand how to distinguish good Work from bad Work? Are people able to articulate and identify the standard cycle? In many cases, and certainly in service, this often hasn’t been defined by management, which makes it very difficult for employees and managers alike to distinguish a good job (and worthy of praise) from a bad job. In many places, people simply rely on more exertion as a means of doing better.

Wired for Blame

Your employee’s reaction raises questions about her direct manager. Does he or she realize the importance of continually letting people know how they’re getting on? Or does he or she assume they are getting on well, therefore focusing on other things? Furthermore, is it clear at the Gemba how one can succeed at one’s job? Are targets clear and can staff see what their job cycle is? Is it easy to see the difference between a good job and a bad job; or is this left to the judgment of each employee?

In other words, it’s the direct manager’s job to create opportunities to recognize or praise workers frequently. Thanking, praising, recognizing when things go right rarely comes naturally to any of us. We’re wired to respond angrily to problems, and to blame the person for the situation. Knowing that, you have to make a deliberate effort to go out of your way to praise people or at the very least, listen to them, especially about what they do right. As we don’t want to praise people for doing the wrong job or not keeping to the cycle, it is important that the lean tools are in place at the Gemba to make sure we recognize people doing the right thing.

What of the Sensei visits in the workplace? It’s a fact that Sensei visits can be scathing because the Sensei’s job is to define the next “target conditions” in Mike Rother’s terms (http://www-personal.umich.edu/~mrother/Improvement_Kata.html)  – drawing the next line in the sand to stretch people and support the Kaizen spirit. To many people, this can be received as criticism (which assuredly, it is not). So as a senior manager, where and how can we praise people during a Sensei visit? Just doing their Work is not a very good candidate because the Sensei has, in all likelihood, just pointed out all abnormal situations that need attention, and the sluggishness of response in others. Finishing by saying “good Work everybody” is likely to sound false, or as corporate-speak.

On the other hands, a Sensei visit is a perfect opportunity to reinforce the higher levels of competence: solving problems and making suggestions and teaching others. During the Gemba visits, it makes sense to actively look for actual problems that have been solved by people and to praise them for their efforts on this aspect of their Work. This does not necessarily come naturally, as it’s easier to see the current conditions, and discuss what needs to be developed. Yet, during Gemba visits, one can learn to ask systematically about recent problems solved and recognize people for their efforts (as well as coaching them).

People tend to believe one of two things about their ability. Either they believe that competency is fixed and they need to demonstrate this every day, staying clear of problems they can’t solve. Or they believe that competency is the result of hard Work and being patient and persistent in tackling problems they don’t know how to solve just yet, but will one day. When you listen carefully to what people tell you at the Gemba, it’s relatively easy to see which camp’s colors they’re flying. As a senior manager, praising people for just doing their job is problematic in the extreme, because that’s the end of Kaizen. On the other hand, praising people constantly for solving problems and making suggestions is the key to bolster confidence in the Kaizen Process, and, in doing so, deepen the mutual trust that, together, we will face our challenges and overcome them – and learn.

Maintain the Positivity Ratio

Let’s go back to the Gemba. What is really praiseworthy in lean practice? First, seeing problems in one’s own area. Second, working with the team to understand the problem in detail. Third, trying new things to solve the problem right away. Fourth, improving the local standard. In fact, there are many opportunities to recognize the Work people do and praise them, which start with the Production Analysis Board or the Kaizen board. The first technique to master is confirmation: agreeing with people that the problems they have spotted are properly phrased. In a lean environment, it’s usually easy to praise and recognize people for their sincerity in trying to spot problems and solve them. They might not always succeed, but most of them do try to flag issues.

All in all, the advice of the Sensei remains relevant today. Improvement can be started at any point today, no matter what by:

• Encouraging people to practice one-by-one confirmation
• Listening to frontline staff
• Trusting them to do the right thing
• Supporting them in solving problems

The hardest thing in lean is getting operators to “stop the line” or at the very least, speak up when confronted with a difficulty. This is also a great opportunity to recognize people because you can thank them every time they bring up a problem. With this in mind, there are many opportunities to maintain the positivity ratio of three positive comments to one negative one. If you can’t find three positives to say for every negative you must say, then you have a problem of another order and must look up the management food chain to figure out what is going on.

Dear Gemba Coach,

We’re having a heated debate in our company over whether to pursue cost reduction through Waste elimination by accelerating Kaizen events, or whether to focus on lead-time reduction by implementing a pull system. It appears to me we’re not clear on the link between Waste and lead-time. Could you help us clarify this?

This is absolutely the right question to ask and the answer is … Overproduction. Please bear with me while I try to clarify why Overproduction is considered the worst of wastes, the original lean sin, and how this relates to lead-time. This is a bedrock concept of Lean Thinking, which needs to be understood in Gemba terms.

Imagine a sci-fi gizmo that materializes objects, such as a cup of strong, steaming tea, out of component molecules. There’d be very little Waste there: no need to gather tea leaves, package them, store them, transport them, unpack them, Process them, throw some away, transport them internally, repackage them in a large packaging machine, throw substandard tea bags away, pack them, transport them to the warehouse, store them, transport them and so on (you get the picture). All the further Muda of having people moving around with empty packages, forklifts, and so forth would also disappear. Muda is in fact created by the simple fact that we need to transport materials around in order to produce and then to ship. It’s unavoidable.

Batch du Jour

Now, the equipment we use is neither infinite in its capacity nor is it flexibility. I often argue that Kanban is no different to what most restaurants do: the waiter takes an order, which is then placed on a board in the kitchen, and then the cook prepares the dishes in the order they come in. But not so fast. If the cook had to start preparing the soup of the day with every order, no one would ever get served. So a few batches of typical dishes are kept simmering so that when they’re asked for they can be served immediately. And the trouble is anticipating just exactly how much soup you need: too much and there’s leftover (Waste), too little and some clients don’t get any.

It makes perfect intuitive sense to overproduce: while I’ve got this set up, let’s make a few more and store them for when someone asks for them. Conversely, let’s group the orders until I have a full load, and then I’ll deal with them. I have to confess that’s precisely what I do with opening my mail or doing the accounts. This is also what we do when we go for the Supermarket expedition and why on-line shopping progressively changes everything by enabling more frequent deliveries.

Regardless of how natural it feels, Overproduction (producing more or ahead of real demand) creates a number of cost overruns. The first one is fairly obvious: you need far more instant capacity than necessary. This is not always a problem. Laundry, for instance, is done in batches and your own washing machine is used a very small portion of the actual time it sits there. If you were somehow to wash clothes every night for the next day, you’d probably need a much smaller machine (if we knew how to make such a device), not to mention less clothes. Okay, so we like having lots of clothes we rarely wear, and lots of equipment with seldom use. So does the shop floor manager. It’s still Waste.

Overproduction is possible precisely because at one given point in time, we have far more manpower and machinery on hand than needed to do just what is required for customers right now.

This disconnect between the capacity really required to follow the sales pace and what we have is the source of most Muda. First, you’re over-invested with machines that are unavailable due to breakdowns, slowdowns, changeovers and so on. This may not be felt as a vital problem since we have too much capacity in real terms. All problems remain safely hidden. Second, it’s quite comfortable since Overproduction allows for bad parts, missing employees, Downtime, etc. However, the drawback is that not only does it hide all problems and doesn’t push you to excel, but it also costs money in terms of more pallets, more forklifts and conveyors and Material Handling staff, and more warehouses and transports. Overproducing imposes a significant cost overrun on your operations both in terms of capital expenditure and running costs.

Less Inventory, Better Delivery

The irony is that overproducing doesn’t even help to keep customers happy by delivering on time. This is where Overproduction links to lead-time. If I’m making several batches of different products on the same equipment or the same line (A, B, C, D, X – where X can be various exotic references), I have to take into account the fact that production time of B is non-production time of A, C, D and X. So the longer I produce B ahead of its sales pace, the greater stocks of A, C and D I will need to keep to satisfy their sales pace. The upshot is that quite a bit of time can elapse before I start producing As again. If I’m changing product once a day, I won’t be producing A again for another week or so. Added up over several steps this creates the lead-time: the time it takes between the moment when you’ve last finished a product and when you’ll get the first one of the same reference from the next run.

This is what you do to customers, and suppliers do to you. When a large order comes in, the supplier pulls everything they’ve got in finished product stock and then puts the rest in of the order in the production queue. The lead-time is thus the time the order sits in the queue plus the time it takes to actually make it.

I routinely find supply chains with 40 days or so in the pipeline - the best ones will be close to a week. This means that a planner has to make a guesstimate of what will be required by customers in two working months in order to create the production program of the upstream link. Not surprisingly, forecasts are often off  - and although we have a lot of stock in the system to “protect the customer” we’ve still run out of the specific product they need NOW. When I Work with groups of several factories, I usually start by asking them to chart the Inventory of each of the plants against its on-time-delivery performance. In almost every case, we get a linear relationship: the most Inventory, the poorer the delivery performance; the least Inventory, the better the delivery.

Not only is Overproduction costly in terms of the Waste it generates on the Gemba, but it’s also costly in terms of frustrating customers by not fully delivering on time. The link between Waste and lead-time is the following: lead-time is generated by production planning decisions, often based on producing ahead of demand (and thus being late on delivery) which involves holding and transporting stuff, and creates Waste in terms of capacity and layout as well as hiding quality, personnel and machine upkeep problems:

Lead-time <—> Overproduction <—> Waste

What Toyota taught us is that just “improving” things doesn’t always help much. That’s true when the Process is a mess because one can’t understand the cross-impact of what has been “improved”. In many cases, increasing production capacity by increasing productivity (say, from 100 parts an hour to 120 with the same people and equipment) doesn’t really help because all it does is encourage further Overproduction. Toyota has taught us that focusing on the lead-time enables you to spot what needs to be improved right NOW.

And so the first question to ask yourself is: when I launch this Work order (whatever the Process), can I predict exactly when it’s going to be achieved in full (no defects, no missed jobs)? Asking yourself this question will lead you to realize that:

No one believes in matching production pace to sales pace, so the planning is all about somehow juggling the need to maximize the use of equipment and to respond to the customer yelling the loudest right now.

1. Batches in the ERP have been set once in a while without good reason and are so ingrained that they can’t be changed, no matter how unreasonably long they are compared to real demand (basically, your production lead-time is your Processing Time plus your batch size).
2. Your Process flows are a mess and products crisscross each other in the shop with several intersections and roundabouts instead of freeways, making it very difficult to predict who’s going to arrive when.
3. The supply chain is organized by logistics with the explicit purpose of filling the trucks, thus imposing concentration and batching on the entire chain: you need warehouses all over the place because you can’t tell when or what the next sale has just happened.

Kaizen Architecture

The next key lesson we learned from Toyota is that by visualizing the flow and the sales pace in physical processes, we create an architecture for Kaizen: wherever components are missing or stagnate is crying out for improvement. In this way improving step by step also improves the overall system and its performance. Lower the water in the river and the rocks will appear, which only works if we can see the rocks appear. If the rock is a number in the computer system, we’ll miss a customer delivery and never know which part of the flow actually failed.

To respond to your question directly, there is no debate: Kaizen without a pull system will be disappointing. The pull system visualizes Overproduction on the Gemba, which focuses Kaizen efforts on how to limit it, which leads to reducing the cost structure. We just had a bit of fun with one company who’d done so because after a couple of years working with their pull system, they had cancelled the construction of the new warehouse, taken down racks in the existing warehouse, trimmed down forklifts, cut down conveyors and lastly they were selling their huge automated dynamic storage equipment. The fun part is that they were selling them to a competitor who was happy with the bargain price it was getting for prime condition machines. No kidding.

You need to do both. Setting up the pull system is more of a Kaikaku project (breakthrough change) than Kaizen (small-step improvement) and you need to plan your way to do so.

The first step is to Work with production planning to level the demand in order to dampen customer variation in incoming orders. Without this, your pull system won’t be easy to maintain and everyone will end up quickly discouraged. Start by identifying the 10% of your products that account for half the overall volume (in parts, not sales – this is a bet I very rarely lose), then create a plant that assumes we’re going to make the same quantity of these products every day of the week to settle down production. Typically, after having done that, production capacity becomes much clearer and there’s still plenty of time in the day to make all the others.

Then, conduct a project to have each production Cell own its finished product stock (and actually see it in front of the Cell). This will help you to visualize the link between the leveled demand pace (averaged out through the previous step) and the actual production orders as well as visualize the flow and start to unravel the spaghetti.

Third, use SMED like maniacs to reduce batch sizes by increasing the frequency of tool set-ups without losing too much production time to the production changes.

Fourth, look at the implications on procurement practices and try to level wall-to-wall by increasing delivery frequency and crating level plans for suppliers through the way you order: no scoops!

As you conduct these four activities have one person from logistics Work with the Kaizen team to Work their way through Kanban instruction system – it’s not that hard, everyone figures it out and eventually gets to the point of switching off all computer screens on the scheduling system in the shop.

A few months ago, I had the good luck of having dinner with Mr. Masaaki Imaï, who coined the word “Kaizen” and introduced it to the West a quarter of a century ago. We discussed the new book he is currently working on and he outlined the key principles of a “Kaizen” strategy: flow, synchronicity and leveling. You can’t either/or pull systems and Kaizen. Pull creates the architecture for Kaizen, and Kaizen delivers the cost improvements by getting all minds thinking in the shop floor on how to eliminate the Waste revealed by the pull. As my father’s Sensei once said: “Never interpret JIT for your own convenience.”

To hear other points of view on lean practice, join me on The Lean Edge.

Dear Gemba Coach

I am struggling with the problem of training our leaders to become lean leaders. After a full year of doing lean at our company, it is clear that the individuals leading the effort have been transformed. While they were cautious at first, they are now asking many questions, and are always seeking ways to visualize their performance and discover more improvements. But now we are trying to continue this momentum. It turns out that we have become skilled at indicating what goes wrong, but solving the problems is not our strength. Making the transformation to problem solving and Kaizen feels like a challenge of leadership—how do we make this happen?

You're asking a deep question that everyone practicing lean gets confronted with sooner or later. My answer, unfortunately, may not seem all that helpful - but it's the most important thing to do. And that is: find a Sensei that your CEO can Work with, and have them visit the shop floor together regularly. This advice will not help you much, because I've found that most companies who start lean are reluctant to make this step, which they see as a huge commitment. In fact, it's far less of a commitment than launching a program, getting early results, slipping back, having to do it all again and so on - but try telling that to them.

Senseis are rare, expensive, unavailable and generally a pain. But they're essential to lean transformation.

When I first met Pat Lancaster from Lantech, I was struggling with the question of why so many companies try lean, yet so few succeed. Since he'd succeeded, I asked him outright for the secret. In his own inimitable manner he just smiled and said "start from the top, find a Sensei you can Work with, and drive it through the line." At the time (and probably now as well), most companies approached lean by creating a lean office, and then hiring consultants to implement "Kaizen event" drives. So I found his answer striking. That’s not to say it was a great surprise - my father Freddy had implemented lean twice by following this exact same recipe. Yet I wanted to be sure, so I asked the same question to everyone I knew who had done lean for real, and they all said more or less the same thing - though rarely so nicely put.

This raises an interesting question: can lean be done without a Sensei? I've yet to encounter one convincing case of this - and I am looking. I'd love to be proved wrong because it would take away the largest bottleneck to lean diffusion. Yet the evidence that a real Sensei must lead is compelling. Last week I visited a company that had achieved good lean results three or four years ago. Yet when we visited the Gemba, while there were some traces of visual systems, by and large, the efforts were lackluster: no standards, no Kaizen and... no results. When I asked them why, the people there eventually shared that they used to Work with a very tough Japanese Sensei, but stopped for a variety of reasons. They felt they needed to be autonomous.

That clearly was at the root of their problem! This is like a top athlete telling you he's so good that now he doesn't need any more coaches, coaching, or even going to practice. How does this sound? Will he still be winning medals? In fact, top athletes need more coaching not less as they climb the ladder.

Change Behavior First
Here's another way to think about the need for a lean Sensei. Lean is essentially about applying the PDCA to your own processes. In doing so, you are teaching the people who run the Process daily to improve their performance by improving how they do the Work. This will also develop their autonomy and their satisfaction, because they’ll have better results, and because they'll be more engaged in their jobs. But there are a number of issues about following the PDCA cycle correctly that are very hard to solve without a Sensei.

First, as John Shook has brilliantly written in his Sloan Management Review article on How to Change a Culture: Lessons from NUMMI, it's very clear in lean that changing thinking comes from first changing behavior: you learn by doing. However, this "change behavior first" approach requires that you get the topic right. If you change behavior on the wrong issue, you'll have the wrong result or (indifferent ones).

The Sensei is key at the Plan stage because he or she will point out the right problem that needs solving NOW. As we’re trying to change behavior first, so that thinking will follow, we can only take one step at a time - if not, it's going to be hard to draw conclusions. Senseis have seen many lean implementations and will often tell you the initial step to take. In many cases, you won't agree - and that's the whole point: solutions are rarely found in the mindsets that created them. For instance, Shook describes how at NUMMI, the Toyota folks started with "stop the line." Has anyone come across any company crazy enough to start lean by "stop the line"? I haven't. It's always been: "improve the flow" or "do some Kaizen to eliminate Waste," etc. When I tell people we're going to start by focusing on quality and ergonomics (i.e. overburden) they usually tell me I know nothing of their business and what they need is cost reduction NOW.

The second point where senseis are very useful at the Plan stage is making sure that he "Check" mechanism is already planned at the "P" stage. On the Gemba this means having production analysis boards, red bins, shop stocks, etc. and understanding how the paraphernalia of lean tools actually works as "Checks" to specific problems. Again, getting this part right usually requires a lot of lean experience and is hard to figure out on your own.

At the "Do" stage, the Sensei is usually reluctant to get involved. At this point it's important that teams are developing autonomy. They should be willing to try something on their own. Consultants can be used to hold their hands, but I find that the Process of using consultants tends to turn expectations from "solve the problem" into "have a good event." In general if the problem is clear, people will have ideas on their own, and if they are given permission to try and encouraged to see potential "failures" as good failures, they'll do something on their own.

The Sensei is essential at the "Check" phase once more. That's because experience on the shop floor is essential to see whether the Check the team has done actually corresponds to the reality of the "after" situation. In many cases, something has happened, and they have done their check, but completely missed other issues and areas they were not looking at: you think this happened, but let me show you this ... and so on.

Different Perspective Needed
Finally, and this is probably where the Sensei has the largest impact, it's very hard to draw conclusions from your own experiments. Learning occurs when someone else gives you a different perspective on what you've just done. Most "ahas" occur when people have tried something, are interpreting what happened according to their usual mental models and the Sensei reframes the situation and shows them they could draw vastly different conclusions. Certainly, all my own learning as a "deshi" has occurred in situations such as this: I was inferring a conclusion from something I'd tried and my Sensei turned it on its head and showed me something profound - and "aha!" (and wow!)

Mike Rother has made a research breakthrough by modeling lean learning as applying "katas" - formal learning steps that sustain problem solving and Kaizen. To answer your question, the issue here is to develop these katas in your company. Toyota has invested in a people structure to do so: there are Sensei at the executive levels, and then coordinators at the frontline management level. For many years, we'd assume that Toyota's practice of "doubling" frontline managers with Japanese coordination was an issue of control, but the people being doubled always denied it. As David Meier once told me of his experience as a Supervisor at the Georgetown plant, his coordinator sat all day long with his feet on the table dreaming up exercises for him to do - on top of running the line. Now, this is surely just an image, but it conveys strongly the role of the coordinator: keeping frontline managers doing their katas as well as running operations day to day.

I know, I know, none of these answers are very palatable: the door is narrow. But there is a lot of collective experience in this:

1. Thinking more amongst yourselves won't help. The lean model is to change behavior, then figure it out, as opposed to change your mind first, and then do something. Going through training courses or debating amongst yourselves simply offers distractions from the real step: doing something.


2. Doing without guidance is tricky because one can do a lot of trial-and-error before figuring things out. Just as you can't learn math without a teacher (and not necessarily a good one), you can't learn lean without a Sensei (and not necessarily a good one either).


3. Creating the lean culture is a result of establishing "learning katas" throughout the organizations. This is very hard to invent oneself because you need to know both the katas, and where/when which kata is appropriate. This is what your Sensei does.


4. Developing the lean culture overtime involves reinvesting some of the performance result in a "coaching" structure in which every five frontline supervisors have a Kaizen coach to make sure they continue to improve and teach their teams how to solve problems. Without this coaching structure, the double-loop learning mechanism won't get started. The Sensei is there to coach the coaches as well as the senior execs.

You can't think your way into becoming a lean leader, just as you can't think your way into becoming a golf pro. Whatever your mind tells you, doing it is another matter. Experience shows that the entry ticket to lean is finding a Sensei and getting senior execs on the shop floor once a month to discuss what the key problems are and how to plan their resolution, then checking the outcomes of the actions and drawing the right conclusions; Without this basic learning structure, you can wander a long time in trial-and-error without ever getting past the low-hanging fruit. Finding a Sensei (which is not easy) is indeed the first test of commitment to a lean culture.

Dear Gemba Coach,

At the company where I am production manager, we've done lean for nearly three years. But my team is running into a real challenge when it comes to motivation. My team often feels that they are alone in their improvement efforts. Even after all our Work we continue to encounter resistance from other functions of the company, who do not see the Value of our lean efforts. So how do I maintain the motivation of my team?

Thank you for this question. Your challenge is unfortunately a very common problem at the Gemba. That's because some of the very goals that you seek with Kaizen will in fact produce intractable problems over the long term. Keep in mind that Kaizen reveals the things we do wrong, the things we don't do (and probably should), and the problems we have with partners (suppliers or other functions). There's no reason to believe that confronting these matters regularly won't at some point discourage the folks doing the Work.

Lean Work presents challenges to our commonly held assumptions about motivation. Motivation is usually seen as a problem of getting people to show up in the morning and Work diligently through the day. In lean, motivational issues are more complex. First of all, there's the challenge of convincing people to look at what they are doing wrong, accept that they are doing it wrong, and then find a way to do it right. This must happen while keeping people enthused about trying things they've not done before and experimenting with daily changes in order to sustain continuous improvement (another significant challenge from a motivation perspective.) Finally, lean leaders must finesse the motivational challenges of teamwork- of getting the different functions to solve problems together, particularly when the other side doesn't want to play ball.

Grappling with these challenges calls for the second pillar of lean management, "Respect." Much has been written on the first pillar of "Continuous Improvement," but the second often remains nebulous. Most managers are more comfortable and better skilled with practices such as go and see, challenge, and Kaizen. Yet this second pillar is essential to successfully leaning processes. Respect, in lean terms, has two main aspects. The first one is fostering mutual trust through engaging every employee in their Work with the company. The second is developing individuals through teamwork so that each can reach their full potential and actively participate in running and improving their own workshops.

Because respect rarely develops by itself in most Work cultures, leadership is essential. As a leader you must demonstrate respect, particularly by creating a Work atmosphere where problems are viewed as sources of progress, where difficulties can be shared openly and taken earnestly, and where failure due to experimentation is actually seen positively rather than frowned upon. Leadership usually accounts for a large part of the motivational problem - but what about the people themselves? Why would they want to participate? What are the drivers to their motivation?

On that front, I would recommend a great read: Drive is Dan Pink's inspiring book on what he calls "Motivation 3.0" - upgrading our operating system about motivation. The author's main point is that our naïve notions about what motivates people (carrot-and-stick pay-for-performance systems) are completely out of step with what science says really motivates folk on the Gemba. Motivation 3.0 is particularly relevant to lean because it's motivation through engagement. The three key dimensions of this motivational system are: autonomy, mastery and purpose.

• Autonomy recognizes the need for individuals to have some degree of control over what they do, when they do it, who they do it with, and how they do it. In tightly-organized industrial environments, this appears to contradict all the control systems in place and to a large extent it does -but that's precisely what Kaizen is about. Starting from a basis of stable teams and standardized Work, Kaizen is about giving operators autonomy to change their Work environment and their processes for the better - and thus realize more control over their own Work. The Andon system, for instance, gives a very large amount of control to the individual worker over the entire chain. This is an essential part of lean management which requires careful nurturing and constant leadership to develop as it should.

• Mastery is about the inborn drive to become better at what we do. Most of our organizations emphasize compliance over competence, an approach that kills engagement and Kaizen every time. Mastery is about seeing your own abilities not as finite but as infinitely improvable. This is the root of the Kaizen spirit (even a dry towel can give a drop of water if you put your mind to it), and this what people find so rewarding in Kaizen if it's encouraged. A key element of mastery is defining every Work situation as a challenge and creating immediate feedback on how well we're doing (through Visual Management). The next step is actively supporting people through training and coaching to demonstrate that the challenge can be successfully achieved. A day of clear, interesting challenges will both build up individual competence and enjoyment of Work, the keys to engagement. At middle-management level, A3 management as brilliantly taught by John Shook in Managing to Learn is the main tool to develop mastery amongst managers.

• Purpose is a strong need in most of us: we want to participate to something bigger, more enduring than our day to day. A key aspect of Respect is to Work hard at sharing the objectives of the company with every employee so that they understand the larger picture and see how 1) the firm contributes to society and 2) they contribute through their Work. In lean, the link between Gemba Visual Management and high-level challenges through Hoshin Kanri, as skillfully described by Pascal Dennis in Getting The Right Things Done is the fundamental tool to encourage a sense of purpose throughout the business.

Within lean management, teamwork is a further aspect of engaging individuals by getting them to build strong relationships across steps in the Process, staff functions and with suppliers. As Dr. Ishikawa once famously noted: the coworkers in the next step of the Process are not our enemies, they are our customer. Just after WWII, social psychologist Kurt Lewin showed that the most effective way to get people to change their attitudes and behavior was to have them participate in regular group session where they can freely express their feelings and experiences with the change. This opened the door to understanding the importance of the team in sustaining individual motivation, individual change and collective change.

Teamwork and the importance of team is an essential part of lean management, best discussed by Terry Besser in Team Toyota. Belonging to a team is an essential part of people's motivation, and so is having good relations with other members of the organization. To foster this, it is key to create platforms for teamwork where people come together to solve problems jointly, from the production team's five minute standup meeting, to a weekly production planning session involving the managers of all key functions. Ultimately, the entire firm is seen as a team.

Two wings are necessary to fly, two legs to run: hopping on one foot will sooner or later end with falling flat on one's face. Respect is just as important as continuous improvement, not the least because it holds the key to continued motivation in the face of setbacks and resistance. Problems are the source of continuous improvement, but people must acknowledge these problems day in day out, and find the continued resilience to solve them - indeed, learn to enjoy it. Problems are not something that keeps you from your "real" job. Problem solving is the job.

In lean terms, the three keys to motivation are leadership, engagement and teamwork:

• Leadership is about relentlessly demonstrating the Kaizen spirit in facing problems, encouraging Kaizen and valorizing good failures (good ideas that didn't Work) as much as successes. Leadership means taking care of people and taking their problems seriously and looking earnestly for ways to help them resolve them. Empowerment in lean terms is about teaching people to solve their own problems.


• Engaging people means creating the kind of working environment where they have daily opportunities to exercise their autonomy, improve their mastery of their job and feel that they belong to a greater project. Go and see, challenge and Kaizen have to be practiced daily in the spirit of engagement.


• Teamwork is fostered by organizing platforms to solve problems together - collective problem solving is the key to developing positive relationships at Work through accepting mutual responsibility of problems and growing mutual trust.

Dear Gemba Coach,

I'm the lean manager of a mid-sized company, and have been getting teased by many folks about Toyota's troubles. It's mostly good-natured, but I fear the public flogging gives nay-sayers an argument for not doing lean. So I am unclear about how to respond to these critics. What advice do you have on what I should tell my employees who are doing lean Work?

As you can imagine, I get a fair amount of ribbing about Toyota as well these days. And, as you say, most of it is quite light-hearted. Moreover, I believe that at the Gemba, the people who do lean seriously are far too involved with their own issues to worry about what happens to Toyota as a shining example on the hill. By now they have seen enough of the benefits for their company not to challenge the need for lean.

Personally, I see this as a coming of age moment for the lean movement. By losing the "Toyota walks on water" argument, we will now have to justify lean on its own merits - which will make us all that much stronger. One of our core challenges from the start has been to break out of the "you either get it or you don't" mindset, and bridge the gap with people who see lean change more cautiously than we do. After all, that’s the very challenge Toyota has had to face internally over the seventies and eighties.

What is happening with Toyota? And how does this relate to our own Gemba? I have been intrigued by three different aspects of the hoo-hah. First, the issue of why Toyota got so dragged in the mud all of a sudden. Did they really become that bad and were been able to hide it for so long? Or did they get caught in yet another round of 'gotcha' politics? Second, what really has happened at Toyota? Have they lost their way? And third, how are they responding to the crisis? Let me preface my comments by saying that I have no special information other than what is said in the press, discussion with other lean experts and the people I know in Toyota, but I’ll try to clarify the picture as I see it.

Three Main Issues
On the first point, let's get some perspective. Out of a list of 20 automotive manufacturers in the U.S., Toyota comes in as the fourth safest, in percentage of incidents reported to number of cars sold, after Smart USA, Porsche, and Mercedes-Benz. They’re ahead of Honda, Subaru and Hyundai, and the U.S. OEMs. And this data comes from the NHTSA complaints database. So, it doesn’t look like Toyota turned out to be bad - just that they're not perfect. Big surprise, right? Somehow they badly mishandled their relationship with the safety board and ended up with a major conflict on their hands. Clearly much of the media storm has more to do with the fact that no one likes a wise guy, and it's time to take Toyota down a peg. In terms of lean, this doesn't change things much. The lean promise has always been to perform at a level competitors struggle to follow (for instance, one can argue that the size of Toyota's current recalls can't be easily replicated by its cash-strapped competitors). For those who seek the perfect company, the philosophy class is next door.

So, Toyota doesn't look to be in any real peril right this minute, but it still has taken quite a hit in image, which will translate into lower sales in an already depressed market, and, if issues keep cropping up, the damage might be lasting. This is the largest perception crisis (How the mighty have fallen! and so on) they've had in a decade, so they did mess up. Three main issues are emerging out of the noise. First, the technical issues about floormats, sticky accelerator pedals, braking systems in the new Prius. There are possibly electronic glitches, yet Toyota denies that this is the case. Second, they were slow to respond to customer complaints, and there is evidence they vigorously lobbied the safety board to avoid doing the recalls all the way back to 2007 or earlier. Third, there's been a lot of discussions about whether they have "lost their way," which would account for the two prior issues.

What is interesting in the case of the floormats and the sticky accelerator pedal issues is that they both involve partners working with Toyota. In the floormat case the owner or the dealer who installs the wrong floormat. In the sticky pedal, the supplier who developed the part (there seems to be no problem with the same part developed by the Japanese supplier). We have not heard Toyota try to shift the blame to either, and in this they are behaving consistently with the values of teamwork in the Toyota Way. Still, in my own Gemba experience, all the really bad quality issues I've witnessed - those that end up in a CEO to CEO phone call (and heads will roll) - have been related to supplier problems. This is not very surprising as internal issues tend to get caught, whereas supplier glitches are a lot harder to spot. Furthermore, many of the quality disasters I've witnessed were due to poor interaction between the design and the supplier manufacturing processes.

There is a real lean lesson here concerning the source of quality. By its very nature, the lean transformation starts with one's own shop floor. As the lean system matures, lean activity moves upstream towards engineering, and downstream towards suppliers. This evolution is slow, because lean in our own operations is already hard and resource-consuming, and having the know-how and the resources to talk to engineering and suppliers is far from obvious. Talking to engineering people about supplier issues is rarely the first thing on the agenda. So one of the true weaknesses of lean practice that I observe (and believe to be a difficult flaw to correct) is that engineering/supplier interactions are "leaned" late in the Process. This tends to be reinforced by frontline managers who already feel overwhelmed by the current issues they have to solve, and have trouble accepting that supplier concerns are their problem as well.

Technical Limits of Kaizen?
The braking glitch in the new Prius is a very interesting case. The error has been attributed to the electronic system, which might be something that lean cannot do justice to. As a movement, we have a lot of lean experience in shop floor operations. There is some lean experience in software development (and indeed I wrote about this in a previous column. But, so far, I've not come across any case of lean activities dealing with electronic design. I'm sure there must be some - but I've not seen one. As Kenichi Ohmae points out in his New York Times piece - Kaizen may not be well adapted to the complexity of electronics systems. Whether it is or not, I can't say. I have not yet seen a meaningful experiment in this area.

I suspect that part of the reason Toyota has been flummoxed by the technical issues is that they have cropped up in areas where the lean system is simply not as strong as it is elsewhere. And here there might be a larger problem. As Toyota has expanded rapidly, it has also driven Value engineering and cost pressures very hard on engineering and suppliers. TPS is not so strong in these areas, particularly outside of Japan (Japan's engineering is more experienced, and many Toyota Japanese suppliers are part of the Keiretsu and have a number of ex-Toyota staffers in their management). Reports of how Toyota has dealt with the economic misery of the past few years show that the plants have reacted in an exemplary lean fashion, by retaining full-time employees and using the Downtime to further improve plant quality. But the technical issues we're seeing here don't come from production. Furthermore, with the commonalization of parts (which is brilliant from a cost perspective), one problem affects a large cross section of vehicles. The upshot is that we can expect more of these issues to crop up. My bet is that they will share the same characteristic of engineering/supplier interactions; and be equally hard to pin down and fix. As lean guys, we have a real challenge there: how do we Work more closely with engineering? And how do we extend what we do to suppliers without losing momentum internally?

Toyota has also been hammered for being slow to respond to customer complaints. Toyota's reply has been that they get so much customer information from across the globe that they were slow to connect the dots; and, that they have not been able to replicate the alleged defects. As I understand it they have a global system to collect customer information from their dealers, and when they spot a specific issue they then narrow it down and chase it on location. The political debate is about whether Toyota was unaware of the problems, and reacted spectacularly when it found out; or whether it did in fact know, and like any other greedy corporation fudged the issue hoping to get away with it.

I personally find it hard not to believe in some arrogance from Toyota headquarters in the light of the adulation they've had over the last ten years. Human nature is what it is, and even though Toyota leadership carefully cultivates a feeling of healthy paranoia, the temptation to "game" the system is always strong. As always, incidents are created by a mix of factors which combine unluckily, and the difficulty to find a smoking gun allied to headquarters hubris can well have led the company down the path of trying to lobby its way out of the recalls rather than fix the problem (certainly, the Prius braking problem would not have warranted a recall in "normal" times, but a rolling fix at car maintenance time). The lesson for lean is to constantly, constantly check the Information Flow from customers. It is so easy to get caught into the day to day of solving internal problems and losing the customer perspective.

Customer preferences will always change and evolve. Because this question of Value evolves, companies that seek to truly satisfy customers must have a robust Process to pick up and understand these customer preferences. Again, because this is usually what marketing does, lean programs tend to be weak on that front. Maintaining the discipline of solving one customer complaint a week, for instance, is a healthy way to keep focused on what customers really want right now, and something we should all bear in mind when we do lean on the Gemba: where is the customer NOW!

All this leads up to several fundamental questions. Has Toyota lost its way? Or is the Toyota Way flawed? So far, Toyota execs have gone out of their way to reinforce their belief in Toyota Way values and take responsibility for any straying from it. Akio Toyoda stated clearly that the priorities of the company have always been Safety first, Quality second, and then third, Volume. But the massive demand for more Toyota cars in recent years and the lure of the top spot on the podium may have gotten those priorities confused. If we give the company the benefit of the doubt (and as lean guys, we're kind of obliged to give them the credit), here's how the whole mess reads:

• Toyota is slow to recognize the problem (and yes, there probably was some hanky-panky at Toyota's U.S. headquarters in terms of avoiding publicizing the incident), due to the rarity of cases and the difficulty of pinpointing the fault


• When it did, Toyota triggered both a stop-the-line and a spectacular recall; Akio Toyoda has reiterated that the longest standing tradition of the company is to stop and think when it comes across a problem


• Toyota executives have repeatedly taken responsibility for the problems and asserted they must make more efforts to put customers first


• Under fire, Toyota's top leadership's reflex has been to reexamine the Process leading to recalls and to come up with Process changes (as opposed to knee-jerk reaction)


• Toyoda's final point at the end of his statement was the need for Toyota executives to drive the cars and go and find out what happened on location, reinforcing strongly "go and see."

From the lean point of view, a striking aspect of the incident is that in the arena facing the lions, Akio Toyoda has professed as strong a statement faith in the Toyota Way as could be. Clearly Toyota's leadership is not questioning its basic principles, but taking responsibility for straying from them and committing to return to the Way.

None of this makes a case against lean. The picture it paints is one that we'll all recognize. Toyota execs are as human as the next guy, and they got caught on the one hand with a runaway growth suddenly halted by the recession (a recession which sent GM in Chapter 11) and on the other hand, undoubtedly some degree of overconfidence from having had such a free pass from the media so far. Doesn’t that sound familiar? I can't think of one company I've worked with to whom this has not happened at some point or another.

What is unique about lean is not so much that people never falter, but their reaction when they do: accepting responsibility for mistakes, recognizing where and when mistakes were made, having the will to fix the Process to prevent these problems from reoccurring and having the know-how to do so. So far, Toyota is keeping to the lean script. Whether they’ll be able to go to the end of the analysis and solve the problems is anyone’s guess, but they sure will try.

Inspirational Response
Is Toyota no longer a guiding light? Well, maybe I'm simply too close to this issue, but this Gemba Coach has found Akio Toyoda's response to the crisis inspirational. On the Gemba, I've never expected not having problems. Actually, on the Gemba, one of the issues I worry about constantly is the black swan - the unlikely combination of factors that will lead to a disaster. I've lived through my fair share of catastrophes and it's not much fun. More to the point, it hardly shows people in their best light. In this respect I am more than impressed by Toyota's acceptance of responsibility and willingness to take a beating.

This is uniquely uplifting because one of the drawbacks of the lean commitment to "problems first" is that, well, it's sometimes a bit depressing and living it happily requires a good dose of optimism and the firm belief that any problem acknowledged and recognized will be solved because of everyone's motivation and ingenuity. Watching Toyota's President take the tsunami wave head-on and not wavering from the basic tenets of the Toyota Way tells me that if he can do so, so can we all, and that no matter how tough the situation, facing challenges with creativity and courage will pull us through.

What should we tell people about lean and Toyota’s woes? Is Toyota still a model of lean? Personally, I believe that Taiichi Ohno started us all on the lean journey with a straightforward intuition: wrong-headed thinking - misconceptions in his terms - adds unnecessary costs to any activity. The two most obvious misconceptions he fought against in his time were producing ahead of demand and keeping production running although something is not right. Toyota as a company is having to re-learn these fundamental lessons. When the 2008 crisis hit, the company found itself brimming with Inventory, and indeed they are working hard at pacing production again to fit with actual sales volumes rather than build up stock. The second lesson they are grappling with again is not to let abnormal situations pass but stop and solve the problem, no matter how embarrassing or difficult. Sudden acceleration must be dealt with - and the root cause identified.

For all of us in the lean world, John Shook has pointed out a large misconception: the Toyota Production System should not be confused with Toyota's production system. One is a set of interrelated activities one pursues to better oneself, the other is the hodgepodge result of Toyota's real-life evolution. Those of us who have studied Toyota more closely have never been under the illusion that the company is perfect, and indeed, many of us aren't surprised that some of its issues finally surfaced (although the vehemence of the U.S. government's attack is startling - but, hey, the U.S. OEMs had to walk the gauntlet last year). Nevertheless, Toyota's reaffirmation of the principles of the Toyota Way in the face of the storm is exemplary, if only for its resilience and the scope of its reaction, and my money is on Toyota wowing us with the way it's going to solve its current problems. I, for one, believe that the company will continue to inspire us for a good while still.

To hear other points of view on lean implementation, join me on The Lean Edge.

Dear Gemba Coach,

In our job shop we make high precision modules and tools, Work that involves a great deal of variety and very little repetition of products or processes. How can we apply lean principles in an environment like ours?

Thank you for that question. Many people I meet assume that lean can only be useful in high volume situations. This misconception is particularly interesting when you consider that many lean techniques were developed by Toyota when the company was in fact a job shop that was evolving into a full-blown Mass Production model. One of the questions that has obsessed Toyota over the years is how to avoid "big company disease". Toyota leaders constantly ask themselves how they can retain entrepreneurship and artisanship while becoming a massive global player. As we can tell from the news, this question is still as valid now as when it was first asked.

The roots of lean were sown in the workshops of Henry Ford, who had the brilliant idea to transform the nature of automobile production - away from artisans and into something entirely new. His first breakthrough was in standardizing parts (through better precision machining and processing), which eliminated the need for skilled workmen to refine each individual part so that they could fit together in assembly. Ford also broke Work down to the smallest possible Work component, eliminating the need for skill in the assembly Operation itself. He is quoted as complaining: "why is it every time I ask for a pair of hands, they come with a brain?" Many managers today still assume that if a Process in a Mass Production system is detailed and standardized enough, they can put anyone on the job - and then give the customer what comes out. As customers we know better: we deal with the consequences every day that we try to talk to someone on a help line where the people can’t actually do anything for us because they are tied to a narrow scripted response.

So here's the conundrum. The strength of an artisanship approach is the ability to produce one-off products with great care, and to be responsive to every customer's unique requirements. The problem is that this diligence costs a great deal- artisans consider rework as a necessary component of quality and deadlines as lesser concerns to getting it right. And so artisans often price themselves out of the market, losing consumers to cheaper mass produced goods or services. Only in the luxury segment can excellent artisans make a living without having to improve drastically their Efficiency. On the other hand, Mass Production operations could benefit greatly from the care artisans give to their Work.

The Best of Both
Ideally, lean operations aspire to occupy the space bridging these two approaches. On the one hand, they seek to retain the cost benefits of Mass Production in aspects such as line assembly at a regular pace, with Work content close to one minute enabling standardized repetitive cycles, producing parts that are perfectly ready for assembly. Yet this system also needs operators with the ability to maintain care for the product. A robot can assemble a car door, but it will never care about the feel of a door closing well. It can never experience that sense of satisfaction a customer feels when a door closes just right or a seat positions itself at just the right angle. It takes an enormous amount of Work to find that sweet spot in the Gemba. It requires a lot of training and the kind of team structure and Andon mechanisms where operators are taught to develop this fine tuned judgment on parts and the ability to spot when things don’t feel right and Work with the rest of the team and frontline management to get the situation back into standard.

Your challenge is to make artisans more efficient without forcing them to adopt techniques that will lower the quality of their Work and piss them off in the Process. To visualize your Gemba, I am going to imagine your job shop designs dies for specific parts. Your Work has two essential components: one is the design cycle, and two is the production of the die cycle. Both cycles are deeply interlinked, but typically, the flow will be broken down between specialists (the engineer, the miller, the grinder, etc.). Flow integration is typically done through an ERP that mixes and matches information about customer demands, component availability, standard times and machine capacity to come up with job orders and a schedule. And then people do the Work as best they can, following production orders produced by the computer system.

In a craft culture like this you must Work with people to improve their effectiveness. Forcing any new way to organize Work on them will backfire in more ways than one - employee resistance, spotty customer deliver, and battered quality. Therefore your first priority should be to formulate a common project. Establish a clear breakthrough challenge that every one agrees to. In job shops, reducing lead-time is a good place to start. Engineers know that providing new dies to customers quicker pays big dividends; shop operators understand that turning out molds faster will increase throughput and reduce backlog.

It's About Time
A good place to start in terms of a lean exercise is to figure out your particular Takt Time (operating time divided by production requirement). Determining this metric, making it explicit and commonly understood helps everyone shift from a mentality of "we'll deliver when we're done" to a commitment to a steady rhythm of delivery to fulfill customer demand. At first, many people will find Takt Time a natural fit. But as you do this exercise you'll find that it will focus people on the right time measure. By figuring out a way to apply Takt Time, you'll have a better understanding of your capacity, which is usually a problem in job shops. After people have accepted and calculated their takt, the next step is make it visible at every step of the Process so that people can know at all times whether they're ahead or late compared to the takt.

The next big challenge is to get everyone - engineers and operators - to agree that rework is costly, unnecessary, and should not be a regular part of doing quality Work. Everyone should simply assume that they know how to do their Work, and should deliver what the customer ordered the first time. This means investigating every time that the shop fails to deliver right-first-time. Making this a regular practice can start with visual boards that are set up across the offices. People are then trained to spot problems, with the goal of creating a system of continuous self-examination. Every time rework occurs, people need to write what happened, what they believe the cause is, what can be done about it, by whom for when. People will balk at having to write all this, which means explaining that this is about confirmation: writing it down allows us to commit to our explanation and share this explanation with others as a starter to teamwork.

Once you've got a steady rhythm of delivery visualized and the confirmation boards in place, you can focus on recurring issues. The trick here is to get every operator to define the good conditions in which to Work (Work standards); and to elaborate how they go about any job in a sequence of steps (standardized Work). This may provoke hard feelings in a craft culture where people are proud of their way of working - asking for standards may threaten what they feel distinguishes them from their co-workers. Explain that standards are not the enemy of, but in fact the baseline for, creativity. It's imperative to Work with them to formulate their personal working standards, get them to questions all situations in which they don’t follow their personal working standards, which gets them to share their working standards, compare, and progressively create common standards.

Share Problems, Not Skills
The next challenge is creating teamwork between specialists. Try these two simple techniques. First, a "walk through, talk through" preparation session at the beginning of all the new jobs - having folks anticipate anything we think will not go smoothly. The idea is to get engineers and operators together, to talk about how the Work is going to be done in a step-by-step manner, in order to list all potential problems, highlight the large ones, and solve them before starting to machine parts. The second practice is to establish a mid-term plan of cross-training. The aim here is not to develop true multi-skilling. Engineers will never become proficient machinists. The idea is for people to practice each other's job sufficiently to understand the difficulties they create for each other. What we aim to do is to share problems, not skills. In doing so, we can progressively focus on:

1. Work flow - the logical sequences of steps across the entire job


2. Methods to get to repeatable Process steps and machine processes


3. Regular lengths of time allowed for each Process steps according to the takt rhythm.

Remember that the workforce determines the success or failure of the business in a job shop far more than in a Mass Production setting: it's about the people, not the machinery. They have the common sense and experience to recognize when something isn't right and fix it. They can think and solve problems. They have pride in their Work and bring insight to their jobs every day - if they are asked. Improvement can be started at any point if management creates an improvement project that all persons can understand and identify with. Then it's a matter of encouraging engineers and operators to practice confirmation and to exchange their difficulties with an open mind, and to get management to listen to people, learn to trust them and to support their improvement efforts.

Craft cultures tend to center around the pride in the final result and the pride in making each item unique. Your challenge is to build this pride in having projects unfold without a single rework step, end-to-end right first time. If your people latch on to this ideal, they will quite naturally realize the Waste caused by some of their practices and attitudes, and this spark of Kaizen spirit can then be nurtured to develop lean fully in a job shop environment by applying the discipline of continuous lead-time reduction.

To hear other points of view on lean implementation, join me on The Lean Edge: http://www.theleanedge.org/

Dear Gemba Coach,

My company has been doing lean for a while now, and I've been asked to start lean in the IT department. I've read the books and gone to the conferences, but most of what I see is very focused on manufacturing. I'm unsure about where to start - would you have a few pointers?

Lean and IT: interesting topic. I understand your difficulty because it is one hard topic to tackle. First, let me encourage you to learn more about the agile and extreme programming community. Some of these guys have been applying lean techniques and giving them cool names such as scrum, sprints, sashimi, and unit tests. There's some very good stuff in there and the agile crowd tends to be both fun and quirky. Unfortunately, such techniques seem to be hitting the same acceptance barrier in IT departments that early just-in-time efforts had in production, which is not helpful. If your company has a strong lean drive, you might want to see how you can borrow from the agile world as well as develop an approach to lean in IT.

Lean tools don't translate immediately to the IT world for good reasons. The two worlds have significant differences. The most important distinction is that IT is project-based. While manufacturing can be seen as project-based as well, its operations are repetitive, while IT projects are not, and have time frames of at least several years. In project development, projects have different phases during their life cycles, so workers feel that no two steps are the same. Moreover, development teams are typically put together from a pool of individuals for each project, or for certain tasks within a project, which makes team-based learning is difficult to organize.

A second large difference is that in manufacturing, customer requirements are, by and large, pretty clear - once the product has come out of engineering, rightly or wrongly, that's it. The goal of manufacturing is to produce as close to specs as possible, and to fix matters in response to customer complaints. Understanding what the product is supposed to be is quite clear. Not so in IT where, in many cases, the understanding of what the system is supposed to do remains vague to the last stages; and can be the source of many disagreements with customers and users.

A third large difference is that IT Work is mostly invisible and personal. The coder is alone with her screen, and only she really knows what's really going on in her code. In manufacturing people Work together on visible things, such as components and machines. This makes seeing the flow and the quality issues (relatively) easy, if you know how to look.

Fundamentals
As you can imagine, applying all aspects of lean to IT is a topic that entire books can be written on (and have been; I highly recommend Mary Poppendieck's Work on the subject). So let’s focus first what kind of environment or program would help you to be able to do lean in IT. If you get that right, then you can move on to the more detailed Work of getting each project to Work in a leaner way. Let’s see how lean fundamentals can apply to a lean IT department.

First, customer satisfaction. Now, there's a biggie! The first, difficult step here is to accept once and for all that we don't know what we don't know. And when it comes to what customers want from an IT system, we really don't know what we don't know. Worse, often they don’t know as well and will only tell you this after all the Work is done, and it's not to their liking. This is a HUGE issue, and should be tackled accordingly. It's not new to IT, of course, and there have been many attempts at resolving that by more communication with customers. Unfortunately, it doesn't help that much. Customers don’t come to the meetings (they've got better things to do than listen to a bunch of IT guys jabbering techie lingo), and whatever they tell you is highly misleading. So if talking to them more is not really an option, what can we do? The first step is accepting we've got a problem: not only don't we understand what customers truly Value (because they don't know themselves) but, to add insult to injury, this misunderstanding evolves over time (the same customer will not Value the same things all the time). The answer is a determination to becoming really good at understanding what customers are ready to pay for as opposed to what they say they want.

How? The hard way: by learning. The first thing to set up for lean in the IT department is a rigorous, three-day Hansei or "post-mortem" session after each project has been delivered. The key questions of this event is "did we get customer requests right?" and "if not, why not?" The output of these sessions shouldn't be about a better system - that's come and gone - but for a stronger way to figure out what customers want. In other terms we need to learn how to understand what customers Value, and how to share this with our teams. In practice, you'll probably see that we do find out what the customer really wants, but late. So the question is how do we discover this earlier on? This will probably lead you to schedule mini Hansei sessions (half-a-day) throughout the project just to check that we're still in phase with the customer values.

Here's an interesting question: IT is supposed to be a lever for productivity and delivery. Is it? When we deliver a new system to internal customers can we see an improvement of productivity (after and expected short initial dip corresponding to getting the system in hand)? The proof of the pudding is in the tasting. IT systems should make Work easier, better faster. This is a good question to have in mind in the Hansei sessions: what, exactly, is the Value to final customers?

Just-in-Time for IT
Second lean principle to we want to apply is just-in-time. How can we possibly Work in pull when we're not delivering one product regularly, but a string of activities that build up one integrated system: nothing is twice the same? That's true, but one of the core ideas behind JIT is takt: leveling the Work so that we have the production capacity to flow smoothly through the chain. In IT this is relevant for two reasons. In the first place, and this is explained by queuing theory, if you saturate your resource beyond 80%, everything just stops: nothing gets out of the pipe. Secondly, management usually finds it very difficult to prioritize projects (everything has to be done now, regardless of resource). Leveling rules, such as a number of deliveries per week or per month (dividing the usual yearly amount of projects per month or week) will force deeper discussions about priorities and Work content.

All projects are not equivalent - some are greedier in resources than others, or have greater scope. So why would we treat them the same and schedule them regularly? First, because no matter how large the project is, customers typically can't absorb more than a project at a time, evenly spaced. So what really matters is the pace at which the developments come on line for customers to learn to use. Secondly, a regular scheduling of delivery will force a real discussion in terms of priorities (which one do we do next) and staffing (how many man-hours are needed to do this piece of Work). Although JIT within a project might be difficult at first, establishing a takt of delivery is the key first step of this thousand mile journey.

Building in Quality
Third lean principle: Jidoka. How do we spot mistakes early and react quickly? Extreme programming and other development approaches have techniques to test code on an ongoing basis. This involves either automating tests after each block of code, or continuous integration, such as compiling daily to see whether the system crashes and so on. The key thing from a lean point of view is to have a way to spot coding or design errors right after they were created, and a managerial system set up to react immediately and not let the Work proceed until the impact of the problem has been understood and countermeasures outlined.

Extreme agilists have also imagined some rather far out techniques such as pair programming. Two programmers Work at one station: one types in the code, the other checks each line of code as it is written. Every half-hour (or less), the keyboard changes hands and roles are reversed. This sounds odd, but in this case, bugs are spotted right where they appear. Is it worth the extra labor? Aficionados claim that the result of pair programming is shorter programs, better designed and fewer bugs. One study reports that pair programmers are 15% slower than individual programmers, but error free code moves up from 70% to 85%. The added advantage is that programmers in the team learn to familiarize themselves with each other's code. It sounds weird, but, in effect, this is like creating micro-cells with quality control in each Cell rather than isolated operators (coders) and quality control (debugging) in the final product.

Lastly, I'm not aware of any specific agile or extreme techniques focusing on standardized Work and Kaizen. As John Shook pointed out, there are elements of Work standards, such as tests and checklists, but these are not necessarily standardized Work (set steps sequenced in a given time), and projects are reviewed for learning points and refactoring at the end, but this isn't much like Kaizen. In any case, to start with, having regular Hansei session during any project’s development is bound to be a good start.

The last difference between IT Work and production is the visibility of the Process. This is a matter of being creative and finding ways of making the Process visible (board, indicator tracking, etc.) Many IT guys have learned to create specific visualizations to represent their own processes. The trick is to keep the basics of Visual Management in mind:

• Visualize the Process: find clever ways of doing so (are we ahead or late?)


• To reveal problems and react quickly (to protect the customer)


• And solve them one by one


• So that we improve our management policies

If you keep the core principles of lean in mind - by which I mean having a continuous Process to discover what customers Value, planning a smooth takt of deliveries, having tools to spot non-quality as it is developed and to react quickly, and standardizing and doing Kaizen on your operations - then you're already doing lean.

Purpose, Process, People
Whether by serendipity or design, lean is more advanced in IT than in other areas because many of the tools have already been developed. Merging the two together is mainly a question of sharing the same vocabulary (by no means an easy challenge) and keeping the principles of lean in mind - just as with manufacturing, programmers tend to get carried away with the tools and forget the reasons for the tools (as Mr. Ohba once phrased it: to build the Buddha image without putting the spirit into it). So if there is one word of caution this is it: always go back to what customers want. Ultimately IT is about making its customers more effective, and this can be tested. Also the immediate customer might not be the final customer, and it's the final customer that really matters. Before making IT projects and development more efficient, it’s well worth spending some time figuring out why we want to do this development in the first place.

To answer your question, the place to start is by asking Jim Womack's fundamental question of each proposed development: before we get people to improve the Process, do we understand the purpose of what we're asked to do? Good luck, and please let me know how it goes!

Dear Gemba Coach,

Our management team introduced Kaizen events to our company three years ago. As a manager involved with lean, I have participated in many of these, and can say that a large number of managers are now able to run Kaizen with our own black belts - without consulting support. Yet in this difficult period, I find that events are lagging. Managers often cancel or postpone scheduled events, and the Kaizen approach is being challenged by executives who say that it is costly in resources and disappointing in improvements. I can see the benefits Kaizen has brought our company, but find it hard to formulate the argument persuasively. Is there a powerful way to make the business case for Kaizen?

Thank you for this deep and difficult question, which crops up often. The good news is that yes, there is a business case for Kaizen. Unfortunately, it's not easily explained to someone who is not open minded enough to hear it.

The traditional argument for Kaizen finds a way to calculate actual "savings," i.e. translating the improvement in dollar Value. This is a great way to confirm the Value of the Work to the Kaizen group, but it rarely convinces management. That's because these savings often appear paltry at the global level compared to overall budgetary considerations, and because these specific savings are rarely tied directly to the bottom line - there are too many other factors over time in the system that muddy these numbers. So how can one clarify the cost/benefit formula here?

The first step is to ask the simple question: what is the real benefit of Kaizen? It is quite clear that the profitability of any industrial Process (whether manufacturing or service) is mainly a result of its design: the technology and organization which structure the Process which should deliver a product or service at a target unit cost for a target volume level. However this target level is rarely reached because reality happens. People have to use the software, equipment, materials, premises and so on in varying local conditions, with varying markets and supply conditions, with varying degrees of staff training and motivation and so on. As a result many unforeseen problems occur which hamper the "ideal" working of the Process, and make it run suboptimally. These problems add up and create real costs which do show up in the accounts as extra resources (or lower sales due to disappointed customers).

The Biggest Benefit
Running processes closer to target performance is essentially about getting the operators of the processes to learn the tricks of the trade that will allow them to use the software, equipment, materials, premises smartly in real-life conditions. Continuous improvement in this sense is a constant drive to close the gap between actual performance of the existing Process and target performance of the Process as it was originally designed.

Occasionally, during a Kaizen event someone might hit upon a brilliant idea which will lead to a very profitable Process redesign - which is nice, but not the main aim of Kaizen. The number one benefit of Kaizen is teaching people how to solve day to day issues to run the Process well in existing conditions. This will show up in the accounts by taking out a layer of additional costs one incurs to compensate for broken processes.

To estimate the potential benefit of Kaizen, take the best day performance of your Process, and apply this to every day of the month (if we've done it one day, we should be able to do it every day) and compare this to real day-to-day performance data. The gap is the potential benefit from Kaizen.

Why Kaizen? Because frequent iterations is a superior training method. The best known way to learn to do something is to try it again and again until one gets the hang of it. So the best way of learning how to solve specific Process problems is to Kaizen on this topic again and again until the problem is "solved" (i.e. the new way of doing things is inscribed in the standard). On this topic I recommend Rob Austin and Lee Devin's great book on Artful Making.

Kaizen Non-Events
Now, to your question: what about the cost side? As Austin and Devin show, frequent iterations is the best known way to both learn and explore problems, but each iteration has a cost. And indeed, running a "classic" Kaizen event has to be the costliest way of doing Kaizen: a team of people "immobilized" for three to five days, a coach (internal is cheaper than a consultant, but still), a meeting room, sometimes stopping operations for the event.

From a cost point of view, what would be the ideal Kaizen event? Well, a non-event. Imagine that an operator herself figures out something is wrong in the Process (at a rental car service desk, for example, she has to pick up the phone to help customers find their way to rental returns, thus slowing the queue of customers who want to pick up a car), and tries several ways in which to solve the problem (written instructions, maps, etc.). This isn't likely to happen on its own with every operator, so it's the supervisor's job to get us closer and closer to this ideal.

In fact, we can Kaizen how we do Kaizen. There is a real skill in learning to do Kaizen at the lowest possible cost of iteration. From the starting point of "no investment" in full-scale Kaizen events, to getting operators to use cardboard mock ups and simple tricks to test Kaizen ideas directly on the workstation in the course of their shift. Indeed, one of the fascinating things to look for in a Toyota plant (and not obvious to see at first glance) is all the scotch-taped and cardboard modifications around workstations where operators are trying new ideas as they Work. And ideally, operators would be able to draw a "Kaizen" document explaining the problem they tried to solve, and the savings generated by their solution, once this has been refined and accepted by the entire team.

Iterations are the way to learn how to keep processes close to target performance, but iterations have a cost, so it's part of our lean Work to learn to increase these iterations while continuously reducing their cost. This is a specific Kaizen skill which must be developed in-house and taught to the supervisors, so they can engage every one of their staff into such ongoing activities.

Should we entirely forego "classic" Kaizen events? Probably not. The coach led Kaizen events are important as a refresher course on what Kaizen is supposed to be. The important point of these events is that they should tackle larger changes, involving more cross-functional players and rigorously follow the PDCA methodology to "show how it's done." In order to support Kaizen done in the Work areas by the frontline managers and their teams, it's important to maintain a schedule of full production Kaizen events - but these can be planned through the year and budgeted carefully.

Kaizening Kaizen
I'm not sure whether this will help you with your management colleagues, my experience is that it's hard to wake up someone who is pretending to sleep, but here is how the Kaizen argument goes:

1. To make money in our business and satisfy our customers, our processes must run every day close to their target performance.


2. People who run these processes at the Gemba experience day-to-day difficulties due to local conditions that reduce effectiveness and generate additional costs to compensate for these inefficiencies.


3. To reach target performance we need to constantly engage and train people to solve these problems and improve real performance, aiming for target performance.


4. The best known way of doing this is through "Kaizen" - frequent quick iterations of problem solving in order to "get it right" from experience and deep thinking, locally.


5. These iterations, however, have a cost (most obviously the cost of running "classic" Kaizen events), and we must Work to reduce this cost by pushing Kaizen further and further into a normal part of daily Work.


6. This requires deepening our own understanding of Kaizen every day and, in a way, kaizening how we do Kaizen.

Should we forgo the hope of big payoffs then? Absolutely not - we still want the big bucks. But the big payoff won't likely come from existing processes. As we learn how to deal with the problems posed by existing operations (through solving them), we will also generate new ways of doing things for the next investment.

When I first studied how Toyota involved one of their suppliers 15 years ago, I was surprised by the fact that they didn't ask for any financial concessions upfront for all their help (as opposed to their competitors who said: give us a 15% price rebate now, and we’ll show you how to get the next 15% out of your processes). It took me a while to figure out that Toyota did have a financial advantage at having a supplier Cell which ran smoothly without quality issues for then. But what happened then, a few years down the line, is that when it was time to design the new version of the product, all the learning accumulated from a couple of years of Kaizen led to a design which was 27% cheaper than the first one - and Toyota and the supplier shared this windfall.

I recently had the privilege of dining with Mr. Masaaki Imai who coined the term "kai'zen" 30 years ago, and as we discussed Kaizen, I realized he had explained this basic mechanism linking small step improvement to large performance leap right from the start. It just took me many, many, iterations to figure it out.

Dear Gemba Coach,

I Work for a large governmental organization that has decided to do lean. I have been interested in lean for some time, yet am concerned about the current program: it appears as if our leaders intend to conduct across the board cost-cutting workshops to eliminate Waste. This certainly does not seem to be the right way to do lean, but I have very little freedom to change their approach. What can I do?

You pose a deep question that many people will identify with. In fact, you raise a philosophical question that goes way beyond lean. In a world of interlinked cause and effect, what freedom do any of us have? Most of us are caught in a game of falling dominoes where our individual actions make very little difference. So where, and how, can we find freedom to act when we have no power and few options?

I believe that lean practice truly has something to contribute to this fundamental challenge. The Gemba reveals that Work situations can be seen as matters of choice: within the real constraints around us, we all have a great deal of freedom in our attitudes, and hence our choices, and the choices we influence. The question of freedom is often one of values. The lean approach has its own set of values that can be practiced every day, even in the most trying circumstances (of course, as anything in lean, it requires some Work).

These values can ultimately help every individual develop more choice, and therefore, more freedom. Let's start with the very core attitudes of lean management: self-development, and developing others. The practice of self-development is essentially about making a daily effort to better understand the cause/effect relationships that underlie day-to-day events. Lean practice helps us see that every event is the result of a Process, which is a sequence of dependent, repetitive steps. Rather than be satisfied with the immediate surface reaction to any situation, we all have the freedom to think more deeply about things, ask “why,” and as a result, better understand the deeper processes that lead to specific outcomes.

Back to Deming
These attitudes go hand-in-hand with powerful tools that make them doable. For instance, we can learn how to quickly draw the standard Process (how things are supposed to Work out without hiccups) on a napkin or on the back of an envelope, which enables us to think about what really happened on the Gemba and identify the gaps between real and ideal. This practice is demanding - not just in time and effort but in developing the discipline to make it Work. Anyone can make progress in this area: start by digging deeply into the Process behind, or symptoms leading up to, a certain outcome, rather than simply accepting assumptions about how things really are. Again, in most cases you have ample freedom to do so: it's a matter of asking politely.

The other powerful lean tool to help us develop our understanding of any situation is the formal practice of testing and experimentation - the explicit creation of markers for success or failure for every proposed new action. This goes back to the very roots of quality, back to Deming's insistence on knowing how to distinguish a good job from a bad job. Everyone must know how to ask the question of: do I know, in any case, whether I'm doing a good job or a bad job? How would it look? These are by no means easy questions to answer. But we all have the freedom to explore them. Drawing out the outcome we want out of any situation, and then testing it, teaches us a lot about our own understanding of how things Work. It also reveals how strongly we are being implicitly pushed by the system one way or the other.

Without starting a fight with our bosses (if senior management of our organization wants something, we're going to have to deliver it!), we can still influence the practice of any new way of working. We can build coherent arguments, influence the debates, help guide the methodology. Knowledge leadership itself can be a powerful form of influence that has nothing to do with actual power or authority. If by self-development you learn to understand situations better, and thereby explain outcomes more clearly and powerfully, then in most cases your own credibility and airtime will increase dramatically. You will have established more clout than your pay grade warrants.

In this sense, self-development naturally leads to developing others. Even if you have no troops and are at the bottom of the pecking order, you still have the freedom of practicing the five tenets of lean management, all of which will develop yourself, and by practice, those you Work with. Keep these five basic values in mind always:

Practice Five Basic Values
First, go and see. It's not so hard to get people out of the office regularly by arguing that the group should really go and look for itself. Sure, they won't always do it (meeting rooms are nice and warm, with cookies and coffee), but over time the appeal of having a look first will grow. The skill here lies in finding a close-enough Gemba so that "go and see" is not too much of an investment for people who are not fully committed to the lean ideal of Genchi Genbutsu. Still any Gemba is better than the meeting room.

Second, challenge. The most powerful way to focus people's minds away from their pet solutions and towards a more productive and workable approach is to find a way to express what a group is trying to do in terms of the challenge: what specifically are we trying to resolve in order to improve the situation? Formulating the challenge, rather than arguing for or against any specific solution, is a matter of skill. This goes back to self-development: as you develop the skills to frame problems in the form of challenges, then you have a better prospect that people will listen to you. Then you can steer the group to a productive evaluation of how well their preferred solutions respond to the challenge. Here again, no one is going to stop you from formulating things in this way. The trick is in learning to do so in a way that other people listen to and accept. This is something that you can learn regardless of your position in the organization.

Third, Kaizen. Arguing for step-by-step problem solving rather than one fell swoop usually makes sense in most cases. When confronted with a difficult challenge, most people will want to change the Process rather than solve the problems within the Process. Here again, even without any power, one can argue that while a large-scale solution is investigated and providers are evaluated, one can still Work at better understanding the problems within the existing Process - trying to get the people involved in solving these problems one by one. This is a small diversion of resources, and who knows, it might even pay off in a big way. Even if your bosses don't want to listen to this, you still have the freedom to make the case for Kaizen. It's not an unreasonable position. Furthermore, the greater your skill at problem solving (and being recognized for it), the more credible you will be on that stance.

Fourth, respect. Today it's a very hard sell to convince managers that the Work environment should enable people to perform well, and moreover, that they should be encouraged to improve their own working environment. Still, even if no one else does, you are still free to listen to people and take their problems seriously. Help uncover the systematic causes for defects, errors, and other flaws without blaming people. When we don't know the details of the situation, it's so easy to blame people for complaining. In almost every case, asking 'why' several times will reveal that they are faced with a real difficulty, even though they're not always expressing it clearly. Many times they are too focused on a possible solution rather than a deeper exploration of the problem. The belief that frontline workers are not lazy folks creating excuses for poor performance, and that they must be defended and supported, is lean's biggest departure from any other management system. Workers are the most important people in any outfit because they add the Value. Consequently, their point of view is always legitimate, no matter how skewed or whether we can do something about it. Even if you are totally powerless to affect decisions or outcomes, you still have the freedom of taking frontline issues seriously and arguing for their resolution. This is a real choice that we face every day. The lady pushing the mail wagon complains about shoulder ache: do we listen and try to figure out what to do about it, with her, or do we dismiss it as part of the normal gripe from operators?

Fifth, teamwork. Power or authority can't create teamwork across functions. As most senior managers lament, it takes more to get people working together. Teamwork can be formed through a common goal, and developed by one person making a personal commitment to listen to other points of view with an open mind. Remember, understanding someone else's point of view doesn't necessarily mean agreeing with them. But there is no harm in listening. Unfortunately, we often weaken our working relationship out of fear that other perspectives will corrupt our purely formed thought, undermine our convictions, and even weaken our authority. And yet, even without any authority, one can foster teamwork by taking the time to listen to other people's point of view and then reformulate these thoughts for the whole team. This skill is not about freedom as much as it is about self-confidence and people skills. Actively listening across borders will nudge the situation towards more teamwork, even if the movement can be frustratingly slow at times.

Regardless of how high up we are, none of us ever feels we have enough authority or power to get things done the "right way." Yet stick to the lean ideals of self-development and the development of others, rather than thinking about getting more done by acquiring more power. The true danger of power is that it will turn people close to us into instruments of our will rather than working partners, thereby losing their unique contributions. The simple truth is that whether in a position of power or not, all of us have the freedom of learning more every day, and coaching more everyday. Many people only see lean as something that revolutionizes processes. In fact, practicing lean is as much about learning how to master specific attitudes and techniques that can help anyone, at any time, gain more freedom through development of themselves and others.

Dear Gemba Coach,

In our manufacturing business, we have several opportunities for improvement that involve reducing WIP and excess Inventory (of both purchased and fabricated parts). Is there a way to put a dollar Value (cost savings) on these types of improvements? We have trouble gaining CFO support for a Process improvement that reduces WIP time for one specific option by one day, mainly because it doesn't provide him any way to sell our product at a lower cost. Maybe it does, but we don't know how to quantify it.

Interesting question, and one that many lean practitioners encounter at some time or other. Are you sure you've fully grasped the situation? I am surprised to hear that the CFO doesn't see the point of reducing Inventory in WIP or purchased parts. To explore this issue I believe we must keep in mind that every business situation has two dimensions: the deal and the relationship. Or, in lean terms: the improvement we're making, and the teamwork we are building through cooperation across functions.

The first aspect of the issue is to try to clarify our understanding of the disagreement with the CFO. What are the implicit assumptions that both of you are making? Before we look into the cost issue, we need to bear in mind that the main impact of Inventory on the books will be on cash flow - something that no CFO would not want to improve!

Reducing Inventory in Value will improve the cash flow of the situation. Less cash out means both less financial costs and an opportunity to pay back debt, invest, or even stockpile. This has to be a good thing. The only financial problem with reducing Inventory would be reducing the overall amount of assets, but, as Orry Fiume (co-author of Real Numbers) is fond of saying: profit is an opinion, cash is a fact.

The dollar Value on Inventory reduction has two components: (1) the cash flow improvement and (2) the cost savings from requiring less space. Less Inventory means less storage space and less handling. This leads to real budget-level cost savings if you’re in a situation to do one (or more) of three things: close external storage or sell or rent internal space; reduce the number of logistics operators; and reduce the number of forklifts and other handling equipment. In my experience, the cash component is by far the main gain.

Why would any CFO not be interested? Well, if I put myself in the CFO's shoes (God forbid!), I can think of a number of reasons I would not buy the cash improvement argument. Here are the main ones on the top of my head.

My first worry is that a reduction of Inventory, whether in WIP, or worse, in purchased parts, can result in lost sales if the On Time In-Full Delivery service rate is negatively affected by missing components or missing parts. This is a very real concern as many companies who attempt just-in-time without leveling correctly find themselves in exactly that situation: inventories go down, but so does customer service, which creates lost sales, damages the company’s reputation and generates all kinds of panics in production, not to mention exceptional costs in overtime, special freight, and more.

The first aspect of lean is complete customer satisfaction. In many cases, the first thing I've seen Toyota do with a new supplier is to increase the Inventory in the system, to the point that they can now deliver 100%. Only then do they Work on reducing the causes of this Muda of Inventory: the Muri of inflexibility and the Mura of poor planning decisions. So the first thing to check is that your lean activity is monitoring very carefully OTD and to explain how your leveling of customer demand will help you to both increase OTD and reduce Inventory. This absolutely needs clarification.

The second large concern I'd have from a finance point of view is that Work-in-Process reduction is essential from a lean perspective (as a key reflection of lead-time improvement) but hardly ever impacts the overall cash flow. In an assembly Operation Work in Process typically represents a small share of the total Inventory, the bulk of it being in purchased parts, and exactly where it's more likely that reducing stocks will create parts shortages.

It's not easy to explain that making the Process level and flexible will first reduce WIP, and, as this generates a more level pull signal to suppliers, will enable us to carry less stock, mainly by increasing the mix in the deliveries (or the deliveries themselves), with milkruns, crossdocks, etc. To a financial mind, this sounds like overcomplicating things when straightforward solutions exist such as consignment stock (the supplier has to hold some Inventory for you, which they carry on their books until you help yourself at will). Trying to explain to a CFO that by lowering the apparent cost of holding stock, in effect, you increase the economic order quantity and thus create an incentive for the firm to become less flexible, not more, is something of a challenge (one that this Gemba Coach has failed at so far). The issue here is to demonstrate that WIP reduction is the entry ticket to safe purchased parts Inventory reduction - where the big bucks are. I know a company that has recently followed that path and reduced their parts Inventory by a third whilst improving customer service, becoming cash positive for the first time in ten years. The CFO is looking at this "lean thing" in a very different light.

Thirdly, from a financial perspective, I'll worry about the cost of all this proposed Kaizen activity to reduce stocks. Furthermore, there's a good chance that if I support the initiative, they’ll come up with investment demands which will affect my free cash flow and impact my costs event further. From a purely financial perspective, Kaizen can be seen like cost (of putting people in a room away from their desk) to give license to ask for more spending!

You have to make very sure that the opportunities for improvement you mention are pure Kaizen: zero investment! If you can’t guarantee that, then go back to the Gemba and do more people Kaizen before equipment Kaizen. Even a dry towel can deliver a drop of water if it's squeezed hard enough as the old lean hands used to say. In other words, zero-investment performance improvement is the only way to persuade a financier that, at some point, it might be worth it to put some money into it to get even further results. But the key is to demonstrate that without spending any money (barring small stuff costs, of course) you have a credible return on the Kaizen actions. If your zero investment activities have not delivered visible performance improvements, why would finance believe you'll do any better with capital expenditure?

So, yes, there is a way to put a dollar Value on Inventory reduction (beyond the cash flow improvement), but it's a tricky, technical, and highly subjective debate about the cost of holding Inventory. Clearly, Inventory has a cost - both fixed (warehouses, handling, etc.) and variable in terms of depreciation of the Inventory. I tend to attack Inventory by suggesting that people go into the warehouse and tag every crate which has not been moved in the past six months. Then, once all these crates have been tagged, the idea is to lower a few every week and look at what's inside. The amount of obsolete parts in the stock is always staggering. To the cost of the physical holding of the Inventory we can then add the real costs of obsoletes.

And what do we most know from doing lean? That the real cost of holding Inventory is much, much higher than just the total of the cost of goods of parts held in the stock. First, holding huge inventories doesn't help with missed deliveries because we often have the wrong parts in stock (because forecasts are always wrong); second we know that Inventory begets Inventory because the time of production of part A is the time of non-production of part B, so the longer my batch of A, the larger the stock of B in order to deliver both As and Bs; and thirdly, Inventory is the deadly Muda that hides all the other wastes in the system. But whereas from a lean point of view Inventory is one of the ultimate evils (that and defective products to customers) it's going to be hard to convince a CFO. For one thing, inventories are counted as assets and, as such, increase the balance sheet. For another, inventories are measured as the cost of goods sold applied to the products in stocks, so clearly under-evaluated from a lean point of view.

Now to the relationship aspect. Reevaluating the cost of Inventory is not a five minute discussion while waiting for the elevator. This is a long, technical discussion that can only happen within a positive working relationship. The deeper issue I see in your question is how to develop teamwork: how to learn to solve financial problems with the finance department - not by convincing them, but by solving problems together. What problems could we possibly solve which would introduce financiers to Lean Thinking?

If you go back to the cash flow calculation, there are two issues which can be interesting to tackle with finance: accounts payables and accounts receivables. Holding Kaizen events with the finance folks on either the invoicing Process or the paying Process to suppliers could create platforms for teamwork where you could demonstrate the power of Kaizen and have many discussions with your finance counterparts! The main thing is to accept that you can't convince anyone of anything in their own fields. The only answer is to Work with them on specific problems until you both forge a common way of seeing the issue.

I participated recently at a hiring Process for a position at a lean company (a true leader in the lean field). They were about to fire a manager who had a bad attitude and was performing poorly. However, the company was handling this in what seemed like a fearful and excessively risk-averse method: they were interviewing candidates for his replacement off-site (to keep the person from finding out) and did everything to keep the person from knowing he was to be fired, since they feared that if he left early then their relationship with the customer would suffer. So how can a good lean company tackle this type of problem? Where is the honesty and transparency in the company to people? I know that not everyone can fulfill the lean ideal—but shouldn’t the system of managing folks who fall short be more consistent with lean principles?

Many thanks for this powerful comment. Ultimately lean does come down to people, and attitudes, and values, so your question raises hard questions that we should all discuss together as lean guys.

Your comment reminded me of the CEO who was dedicated to lean - to truly walking the walk, not just talking the talk. Accordingly he sought to establish a "Value Stream of people", a clear promotion path for middle managers based on their ability to learn, and to their commitment to lean in terms of both results and Process. People would be promoted internally whenever a spot opened up.

Unfortunately the CEO had a senior manager who was simply not working out - who was not getting it, and, after many efforts, not even trying to. The guy had to go. But, working life being what it is, this branch manager was engaged in many delicate customer negotiations (in several cases dealing with problems of his own making). The CEO felt it would be better for the company to let him finish these open files.

Now, a spot had opened up in this senior manager's area. One of production managers started making noises about not being paid enough, and began a loud search for other jobs. This production manager was felt to be okay, but not outstanding, and certainly not site manager material yet. This would be a challenging problem for a senior manager committed to lean - let alone one who was not on board. Sure enough, during this period of working out the final problems, this director told the CEO that he had come up with a solution. His production manager didn't really want more money, he said, but more recognition and responsibilities. So he offered him the job of site manager without increasing his pay. The CEO was aghast at this solution: it promoted a guy who was not ready, and what about the message that it sent to all the other production managers? What a missed opportunity to promote the kind of site manager that showed the right promise! As you can imagine the situation went from bad to worse. In the end, keeping the director longer, even if some of the reasons were valid, created many more fires to put out.

I believe that there are three main dimensions to this issue. First, the fact that lean is an ideal, and that even when we’re totally committed to it, we often fall short, particularly in people discussions because there are so many aspects involved - many of them very emotional and unspoken. Second, it's very hard to understand the real causes of individuals falling short of lean ideals. Are they doing lean for real yet failing locally because the problems are more complex than our ability to solve them? Or are they people who say they are doing lean, but are just using the vocabulary without actually re-thinking or improving usual practices? Third, people who seek "lean" companies to join are often disappointed. It’s probably better to look for a job and a company you feel good about and bring the lean spirit with you.

Lean is an ideal. Toyota, at its best moments has demonstrated many aspects of what this ideal means in practice, but it is also a company like any other and Toyota employees and managers will be the first to agree to the fact that it often falls short, as Jim Womack, LEI founder, has recently pointed out in his e-letter. Indeed, one of the striking aspects of lean is that this True North ideal is very hard to reach. Let's start with a few basic components of the Lean Ideal:

• Complete customer satisfaction by constantly improving mastery of technology and technical skills


• Employee engagement by developing people and reinforcing teamwork


• Constantly seeking new markets and new Value creation for society overall

A defining feature of lean is that this "striving for better" is operational-ized in each department in very specific ways (such as zero defects, zero late deliveries, zero accidents, one by one production on demand in sequence, employee suggestions, etc.)

The first part of studying lean, therefore, is studying this ideal. How does Toyota do it? How should we do it? How does the system Work as a system? How does the ideal translate to our local situation? We must always keep our wits about us and bear in mind that this is an ideal, and so reality will always fight back. This means that lean leaders must always be willing to be realistic when the company and its individuals fall short. It's always a difficult judgment to know whether (1) we're trying hard and failing (which is okay as this is what PDCA is all about) or (2) we're not trying hard enough and we're telling ourselves we're succeeding. I believe this distinction is very important to keep in mind, particularly if your job is connected with lean programs in any way. The danger otherwise is to be constantly frustrated by apparent lack of progress and the scope of the Work to be done: the closer you get to the mountain, the larger it looks!

So the second aspect to Work on is trying to figure out how committed people are to progressing towards the ideal. This is not always easy to evaluate. During our busy jobs it's very hard to determine exactly where people are coming from and at what speed they can progress. And in fact, the better that you come to know your people, the less likely you are to push them beyond their comfort zone, to refuse to accept their failures since you believe they are doing the best they can. This is one of the reasons a Sensei is so essential to the lean journey. The senseis keep challenging us on how hard we're really trying.

The key question here is to evaluate whether any behavior which doesn't fit with the lean ideal is the reflection of a local situation we don't understand well enough, or whether this is the symptom of a lean principle thoroughly ignored. This is a key question because it arises so often, particularly during the Gemba visits.

The third aspect is whether, when we're personally committed to lean, we should seek "lean" companies to Work for? In absolute terms, absolutely. But in practice, it's trickier. Because of the two previous points it's hard to know exactly what it means when a company is recognized for its leanness. There is a great account of the terrible disappointment of an American engineer who joined a Toyota supplier in Japan to learn the "lean" way to Work first hand. He did find lean, but this was not at all what he had in mind, and not much to his liking. I recommend Notes from Toyota-Land: An American Engineer in Japan by Darius Mehri as an entertaining, enlightening and occasional painful read.

The best thing to do is to look for companies you like: companies that have products that interest you (hard to be engaged if not), with values that you respect and understand if not share wholesale (hard to be happy working there if not), and that offer you a decent position and wage (hard to be motivated if not). "Lean" is what you bring to the company. As the CEO says to his plant manager in The Lean Manager: "You are the help. You are the plant manager. You are all the help the plant needs. There is no cavalry to the rescue. We have no cavalry. The plant's got you—and that's it."

Lean spirit is an attitude and a practice. This is what we bring to the job. The company cannot provide this. It's easier to Work with colleagues who share the same spirit, than not. Although, on the other hand, people who don’t have the lean spirit can most benefit from discovering it. Thank you again for your comment because part of what makes lean hard is the constant disappointment, the relentless feeling we should be doing more, and better. The upside, of course, is what we contribute when we bring a better understanding of processes and teamwork to an area that has none, and when we start engaging our teams in Kaizen. True empowerment is teaching people to solve their own problems and make better decisions in their day to day job: that's the lean management promise.

To hear other points of view on lean implementation, join me on The Lean Edge: http://www.theleanedge.org/