Column Archive: 2013

What Exactly Is - or Isn't - a Lean System?

December 20, 2013

Dear Gemba Coach,

I’m confused as to what a “lean system” is or should be. Could you clarify?

Good question and not easy to answer as, as with many lean concepts, there is not one single answer and much depends of the perspective of the person answering. For instance, an executive vice president of Ford describes the Ford Production System as how Ford operates within all of its manufacturing facilities throughout the world:

“FPS is our blueprint for today and for the future,” said John Fleming, executive vice president, global manufacturing and labor affairs. “It’s about bringing processes together. It’s about learning from each other. And it’s about having operating systems developed from best practices from around the world which are truly the best way that we know how to build vehicles.”

“Having a standardized approach is very important because it provides a baseline on which to build and improve. Without that, we know we won’t be successful,” he said. “And although we have operated in different ways around the world in the past, our teams recognize the benefit of having a structured standard that’s integrated together and works as a system.”

Toyota presents the Toyota Production System differently:

A production system which is steeped in the philosophy of "the complete elimination of all waste" imbuing all aspects of production in pursuit of the most efficient methods. Toyota Motor Corporation's vehicle production system is a way of "making things" that is sometimes referred to as a "lean manufacturing system" or a "just-in-time (JIT) system," and has come to be well known and studied worldwide. This production control system has been established based on many years of continuous improvements, with the objective of "making the vehicles ordered by customers in the quickest and most efficient way, in order to deliver the vehicles as quickly as possible."

The Toyota Production System (TPS) was established based on two concepts: The first is called "jidoka" (which can be loosely translated as "automation with a human touch") which means that when a problem occurs, the equipment stops immediately, preventing defective products from being produced; The second is the concept of "just-in-time," in which each process produces only what is needed by the next process in a continuous flow. See:

So, What Is a Lean System?

So is it a system of best practices standardized around the world, or is it a philosophy of the complete elimination of waste? In his introduction to the first booklet on TPS, Taiichi Ohno presents the system differently again as “a series of related activities aimed at elimination of waste in order to reduce cost, improve quality, and improve productivity.” (Art Smalley’s translation of the first TPS manual in 1973)

Then, in the old days, before it got its name, the Toyota Production System was known as the kanban system – no more than a tool box? What is a lean system?

A system is officially a set of interacting or interdependent components forming an integrated whole through the relationships between the elements. What are the elements? What are the parts? A system is also an organized or established procedure to do something, such as a system to beat the roulette, or your system to handle your e-mails.

If we look at how the TPS came to be, we can see all these various strands come together.

At the turn of the 20th century, Sakichi Toyoda first invented a way to have automatic looms stop by themselves when a thread of cotton broke, so as not to produce reams of defective material. This is a clear element of the system: ways to stop rather than continue to produce when something is out of kilter.

Taiichi Ohno, in the 1920s was working in Toyoda Looms and involved with the efficiency movement sponsored by the Japanese government of the time. They realized that using the jidoka techniques developed by the founder, they could make massive productivity gains because no one needed to babysit the machine to make sure it operated correctly, and one operator could now run several machines. They had, at the time, no concept of flow.

Which is what Kiichiro Toyoda invented when he realized the inefficiency of having unneeded parts lying all around the factory and, right before WWII, he produced a manual on how to control production “just-in-time”, a phrase he coined in English and that Taiichi Ohno explained as, rather, exactly on time. He tinkered with this idea before all experiments were stopped when the military took control of the plants during the war.

The Lean Elements Come Together

In the dreadful struggles of the post war years,  Ohno put two of the elements together through the use of kanban and the supermarket concept. As he describes in his books he hit upon the labor saving potential of working at takt time and producing according to kanban, hence the seven classic labor “wastes”, which are useless operations created by NOT being just in time: overproduction, inventory, overprocessing, motion, transportation, waiting, defects.

Here we can see the relationship between just in time and labor productivity. Then, as Toyota embarked on its total quality crusade, it emerged that kanban couldn’t function with bad parts in the supermarkets, and hence a further element connected. Now we see the relationship between just in time, quality and labor productivity.

Getting closer to one piece flow generates higher productivity, but requires better quality. However, getting closer to one piece flow is also the key to greater quality as it allows operators to inspect parts one by one, and so on.

Early in the fifties, Eiji Toyoda visited Ford factories and was struck by suggestion system. Ford sought “great ideas”, but Eiji Toyoda saw it as a way to involve operators into thinking about kaizen. In the same period, TWI in Japan insisted through the Job Methods course in distinguishing between value added and non-value added parts of the process. We now have a third element integrating itself: standardized work/kaizen.

I’m not saying this is a historical sequence. Rather, during these formative decades, these were the problems Toyota’s production management teams had set for themselves, and in working through them, they came up with a set of principles to help learn how to increase quality, lower costs, reduce lead-time and involve team members in daily kaizen. It’s a system because these core principles feed into each other and don’t make much practical sense taken piece meal.

But what about the whole “best practice” and “standardization” idea of the Ford outlook on systems? The earliest use of “system” I’ve come across of dates back to Frederick Winslow Taylor. His take on work was that great made needed to be made rather than found, which required a system of training to best practices:

“In the past the prevailing idea has been well expressed in the saying that "Captains of industry are born, not made" and the theory has been that if one could get the right man, methods could be safely left to him. In the future it will be appreciated that our leaders must be trained right as well as born right, and that no great man can (with the old system of personal management) hope to compete with a number of ordinary men who have been properly organized so as efficiently to cooperate.

In the past the man has been first; in the future the system must be first. This in no sense, however, implies that great men are not needed. On the contrary, the first object of any good system must be that of developing first-class men; and under systematic management the best man rises to the top more certainly and more rapidly than ever before.”

In Taylor’s terms, “best management is a true science, resting upon clearly defined laws, rules, and principles, as a foundation.” Taylor’s brilliant idea was to have engineers define best practice, and then train all others to apply these best practices.

Yin and Yang

The confusion about systems is understandable because it is a case of emphasis more than nature. In both the Taylor/Ford and the Toyota systems we find a set of typical problems and typical solutions. The Taylor/Ford approach emphasizes the typical solutions – one should identify the best solutions and then standardize them across operations by using the “system” to teach these best practices to everybody.

Conversely, Toyota’s emphasis in on the typical problems – the system’s point is to teach everybody to recognize typical problems and to work out their own solutions to the problem, and so, develop a greater understanding of their work, with a side benefit of capturing more creativity and engagement.

The main point here is that both approaches are valid, but partial. For instance action learning theory describes learning as:

Learning = programmed learning + insight questioning

So the “apply best practice” and “do kaizen to figure out” approaches are not mutually exclusive, and indeed, the most effective system has to be something of both.

To answer your question then, a production system is a set of interrelated “typical problems/typical solutions” to teach employees to perform better at their jobs. The confusion about what systems are mostly comes from different interpretations by different people on whether to “apply the system of best practices to every person until they perform in a standardized way” or to “develop every person by using the system to help them understand and solve their own problems.”

This is not black-and-white. Ford has certainly integrated learning in much of its lean thinking. Toyota is not averse to standardizing approaches as it did with the “Toyota Business Practices” that standardize its problem solving methodology. In the end it all comes down to what problem you’re trying to solve. You can come up with either:

  1. A system of learning activities so that people understand interconnected and interdependent problems better and learn to solve them better;
  2. A system of standard practices to provide a common baseline to all in the organization for people to come together and learn from each other;
  3. A system of tools to optimize local situations and improve operations point by point.

It’s a yin and yang thing – none of the above are mutually exclusive and, indeed, an ideal lean system would have some aspects of the three. However, beware of taking any one of these meanings to extremes, dismissing the other two – that is a well known way of getting into trouble.


Is there such a thing as lean manufacturing engineering?

December 4, 2013
Back to top

Dear Gemba Coach,

I keep reading about lean engineering and lean design. Is there lean manufacturing engineering?

Absolutely. Actually, manufacturing engineering is a core element of lean and without it lean could never be, well, lean. This is a rather difficult debate so I’ll try to illustrate it by two gemba examples. Earlier this year, I visited Toyota’s Takaoka assembly line where four different models were assembled according to takt (no batching), ranging from the two-seater iQ to a family-sized Corolla, in sequence. The first astonishing feat of engineering is of course to have such diversity working with the same production tools. But what really impressed me is that operators moved seamlessly from one model to the other – without breaking their work rhythm (which was also, by the way, rather intense). A few months earlier I was watching Porsche’s assembly line which also has a high diversity in sequence, but where, in Porshe’s terms operators are “desaturated” – meaning by that that operators have long breaks in their working cycles, sometimes stopping altogether as machines perform this or that operation on the line.

Now fast forward to many of the plants I visit outside of the automotive world. Frequently, production cells or lines are still, to this day, dedicated to one single product and operators are moved from one cell to the next according to the day’s demand. In fact, operators will move from one cell to the next within the day as well, if the demand for products doesn’t saturate the cell that builds it – which, it turns out is increasingly frequent as catalogues grow with time as new products are added, but older products still remain in use or sold. In one such plant, they actually measured the production time lost in one day from shifting people around in one workshop and they came up with the figure of 18% of working time, although they now suspect the figure could probably be higher – this is 18% productivity right there and there, not an inconsequential figure when you’re competing with low cost manufacturing.

Learning and Lean

“Lean” as a word has always had many meanings, and not all of them compatible. As time passes, this is truer than ever. Human learning mechanisms are either of assimilating – interpreting the new idea so it fits your preconceptions – or accommodating – changing your mental model according to new facts. Not surprisingly, assimilating is more frequent than accommodating and much of what people discuss as “lean” has no resemblance to the lean I was taught 20 years ago. So let’s go back, for a second, to the meaning of quintessential leanness. Toyota’s central insight back then was that, due to your own misconceptions, your method of production adds unnecessary costs to the products you’re building.

If a product is built through a sequence of isolated cells, moving parts from one station to the other adds costs of (1) poor quality control, (2) moving parts around, a (3) low operator productivity, (4) batching most likely, (5) more capital expenditure than necessary, and all the other wastes. The same is true if each product is made in dedicated cells.

If we look at it from the operator’s perspective, we see huge halls full of idle stations, where the operator has to move between one station to the next. Then, at the station, we see batches of product that need to be built with dedicated equipment that, without the tension of pull, is usually poorly maintained. Finally, the operator is often abandoned with the product and has to handle all the usual 4M issues of faulty equipment, component issues, inadequate training, and vague assembly methods. The upshot is that every single product shoulders the burden of (1) oversized capital expenditure, (2) underutilized labor and (3) all the further logistics waste linked to large buildings and complex flows.

Capital Offenses

Ten years ago, the labor cost difference with low(er) cost countries remained significant. I recall extremes of 1 to 10 gaps, but mostly, if I remember correctly, the real cost difference (adjusted with all the issues of delocalizing) was something like 1 to 4. Now, as I discuss this with managers, this gap has reduced visibly and although they still estimate that labor can be found for half the hourly rate, it’s nowhere near what it used to be. This difference should be within reach, if only the added cost of capital misuse didn’t burden costs so.

Outside of automotive, most manufacturing engineers I come across still don’t get it, and they design equipment specific to the every new product. As a result, when you’re leaning the process after them, you have to work incredibly hard to integrate the new cell in an existing one, and, often, you just can’t do it. Also, to my surprise, once the manufacturing engineering “gets it” and understands the value of flexibility, it’s sometimes not so hard to do.

And then you hit product design issues. It turns out that much of the new product could indeed be built on an existing cell, but there is one specific feature that can’t – maybe even a testing issues requiring a whole new test bench. This is complicated further that as production means are often not maintained as well as they should be and the existing cell is not good enough for the product engineer’s new baby. He simply wants a new car, and will not accept that his child has to drive the old car.

Divas and Rats

What this all comes down to is teamwork, the ability to work across functional barriers; and more than just work, to collaborate intensely with the guys across the fence. First, production must work with manufacturing engineering, which in turn must learn to work with product engineering. Leanness is the by-product of the intensity of collaboration.

To intensify collaboration, we need to create spaces for mutual hands-on learning. Humans are humans because we are collaborative tool users (I mean, this is probably how we became human in the first place), so if you want people to cooperate, start by having them play together with hands-on stuff. Many of the lean engineering tools are about just that:

  1. Immersion in customer usage as a team
  2. Tear down of competitor products as a team
  3. Slow build of prototype parts as a team
  4. Cardboard simulation of the manufacturing cell as a team
  5. Production kaizen involving operators, but also manufacturing engineers and even product engineers.

I remember a company where the CEO had instituted as a rule that manufacturing engineers could (and indeed should) replace old machines in the plant if they could successfully increase OEE of existing equipment by 10%. What then happened is that either 10% was enough, and no need to buy a new machine, or the case was proven and the machine they ordered was very different from the one they had in mind. Why? Because 10% increase in OEE can’t be reached by simply working alone – it’s a kaizen effort than involves collaborating across functional barriers, and so better understanding each other’s issues with the equipment.

In this, manufacturing engineers have an essential role because they are the link between product design divas and production shop floor rats, and, indeed, rumor has it that in Toyota, manufacturing engineering has the greatest power in the balance.

Indeed, there is a lean manufacturing engineering, which is similar to the rest of lean – how do we work with manufacturing engineers so that they realize their own misconceptions in the way they design equipment and come to understand the need for flexibility, reliability and ease of flow that will permit the company to moderate its capital use and lean itself further.


My CEO would like to install a lean culture and has asked me to specify a few basic lean values we need to implement. Where should I start?

November 21, 2013
Back to top

Dear Gemba Coach,

My CEO would like to install a lean culture in our company and has asked me to specify a few basic lean values we need to implement. Where should I start?

Ah. Culture discussions almost make me long for the good ol’ days of lean when it was tools, tools, tools. The central irony of my daily work is that, having been trained as a cognitive sociologist, I spend my days at the gemba challenging executives on how they work with people, machines, and facilities while they were trained mostly as engineers of financiers and they argue about culture, structure, and behavior – in other words, we are mostly exchanging incompetences!

Joking apart, I tend to stay away from “culture” debates because the term itself is quite problematic, but we have to accept that “culture” (whatever this is) has become a common tool in today’s management toolkit – so you are asking a good question which, is fact rather hard to answer.

Culture, in the business sense, generally mean the values, beliefs, norms, and behaviors one can observe in the organization. The assumption is that performance is driven by the “right” individual behavior, which is conditioned by the organization’s “norms”, in turns supported by the company’s “values.” Consequently, managers seeking to reinforce “good” behavior and discourage “bad” behavior will try to influence the existing norms by communicating on the desired values – this is probably the model your boss has in mind. 

Values, as such, have two aspects to them. First is the notion that something is desired more rather than wanted less, which makes it valuable in itself. When we say cooperation is a value we mean that we’d like more cooperation, because this is good in itself, and less uncooperative behavior, which is bad. Value also has a second aspect of valuing such as how do we measure more or less cooperation? The assumption is that if someone values X, then the person will act in a way to reinforce X and avoid non-X. In this sense, what would lean values be? Let’s look at general values that have spread beyond the lean purist movement and that we can hear quite commonly now.

  1. Batch is bad, flow is good: not every one knows how to behave accordingly, but one idea that has spread out of the lean movement is that batch is bad – it creates inventory, drains cash and clogs processes. Processes should flow as naturally as possible which means that they should have (1) fewer steps and (2) be flexible. Now, neither of these two requirements is technically easy. The pressure to fraction processes in order to get a better unit price will always remain, Building more flexible equipment will never be easy. But certainly, since Jim Womack and Dan Jones started preaching the benefits of value streams in the mid 1990s, the idea has come a long way.
  2. Workplace is good, boardroom is bad: the dynamics of any large-ish organization make this hard to adhere to in practice, but few executives now pride themselves in running the company from their office and even in large, global firms, they will get on that plane and visit that plant. What they do when they get to the site remains vague, but the one has to be there, for sure, rather than stay in the executive suite and solve everything through meetings.
  3. Work-arounds are bad, problem solving is good: since the turn of the century (the millennium!) the other key idea that has made its way widely is the need to train the management line to solve its own problems by teaching problem solving skills – the “A3 problem-solving” method has spread far and wide. Again, Taylorist habits are hard to break and many companies find it easier to ask staff experts to come up with a better process (six sigma style)rather than train line people to solve their own problems, but overall as Big Data shifts local planning to even more centralized functions it is recognized that (1) standards have to be followed, but (2) local conditions are, well, local, and so local staff have to be trained to solve problems in the sense of closing gap to standard.
  4. What customers want is good, what the company imposes is bad: this is another idea that is very clearly making its way through the business world. It seems obvious when said like that, but much harder in practice. Certainly, lean’s hardcore obsession with quality is still not widespread, nor is the fact that superior quality is the result of employee’s learning curve rather than perfect processes. Hard to do in real life, but it’s become generally accepted that customers should be listened to.
  5. Engaging people is good, authoritarian management is bad: particularly in the marketing side of things, engagement (of the customer?) is now all the rage. People are increasingly seen as free agents able to pick alternatives rather than tied to a brand (or indeed a job). Surprisingly, the underlying lean notion that kaizen is good and reorganizing is bad has not had the same success. Toyota’s keystone insight was to involve all people all the time in small step-improvement in order to engage operators and develop the capabilities needed for big-step jumps when investing. This is one of the oldest ideas in lean, has been proved true time and time again, but has generally not been picked up.

I am not claiming these are the “lean values.” In visiting many companies I can see that, beyond the lean inner circle, good/bad valuations are changing even though actual practice often lags (it’s hard).

The main problem is that there is no clear evidence to think that values can be changed by fiat. The managerial assumption that changing values change beliefs and norms and hence change behaviors – and workplace tools is simply hard to back up. In sociology, culture means the ensemble symbolic codes of a society, which are its ways of thinking, its ways of acting as well as the material objects that shape its way of life. In fact, from anthropology, we learn that symbolic development of modern humans was very linked to its stone tool development. Symbols and physical tools co-develop. Values and artifacts can’t be separated.

Typically, a change in the tools available to humans, changes the scope of what they can do or can’t do (according to how well they learn to use the tool) and so will end up changing their values. Value change is the outcome of the relationship between tools and their use. Mastering the lean tools and understanding the scope of performance they open is the key to culture change. This process is brilliantly described by Art Byrne in his Lean Turnaround book where he shows how his learning curve started with a rudimentary kanban between two sites, and how much he got out of SMED once he saw the cash impact flexibility brought to the entire company.

No Lean Values

The core intuition of lean, from back in the eighties before it was called lean, was that practicing kaizen on current equipment, one could understand it better and thus know what new equipment to invest in. Without kaizen, any new equipment would go downhill and problems would be carried over in any replacement. In other terms, kaizen teaches the tool users to better use the equipment, and thus better understand its issues so that, when they invest, they do actually progress. Technical evolution can’t be separated from individual learning curves. The eighties and nineties are also replete with examples of people who tried to install “model lines” without having gone through the kaizen discipline of learning, only to watch them fail because no one knew how to deal with such tight process parameters.

I don’t believe there are such things as “lean values.” I believe that if you practice kaizen every day with as many people as you can, you’ll learn things about your business that will grow it in different innovative ways. The lean tools are various standard ways in which to practice – and support - kaizen. In this sense, we’re much closer to the modern definition of culture: the evolved human capacity to classify and represent experiences with symbols and to act imaginatively and creatively. In simpler terms, the understanding of typical problems and typical solutions that lead to creative and innovative answers.

In this sense of “culture”, installing a lean culture would mean understanding the key technical challenges of the business and getting every employee to work on these challenges in small step ways at their level, every day. With this in mind, what kind of environment would we need to create to support every day kaizen, by every one? Practicing this every day would end up in fundamentally changing the values of the company, faster and surer than by trying to “implement” new values by decree.

How do I re-size supermarkets when demand changes or to keep pace with seasonality?

October 28, 2013
Back to top

Dear Gemba Coach,

How do I calculate re-sizing supermarkets when demand changes or to keep pace with seasonality?

There are two very different ways to look at this. The most common perspective I see on the shop floor is SAP thinking with lean tools. In this sense, the question is: we have calibrated our supermarkets and kanban cards for a certain level of demand, at which point has the demand changed so much that we need to recalibrate. The assumption here is that the pull system should work the most effectively way possible and tinkered with when conditions change. In this perspective, kaizen is necessary to keep the kanban working.

And then there is the path less travelled: using kanban as a tool for kaizen. It’s a question of perspective. Let me try and clarify, I’ve recently come across a 1970s story about Taiichi Ohno visiting a Toyota supplier to whom the company was buying seventy thousand parts per month. The plant manager tried to convince Ohno the company had enough capacity and manpower to cope with 100,000 parts if need be. “Then,” Ohno asked, “do you close your operations ten days a month since we are only buying seventy thousand parts?”

“We wouldn’t do anything that silly,” the man answered. “We are building a warehouse for the excess production.” Ohno then explained that if he built the warehouse he probably would lose his contract to Toyota since the additional overhead would make his parts too expensive. The idea, Ohno said, was to have only the equipment and workers needed to produce what was actually sold. Future production increases should be obtained by kaizen. (Against all odds, Togo & Wartman).

Plan for Every Part

Although predictable lean gospel, this story struck me (the book is about Toyoda history, and this is the only mention of TPS) because it goes to the heart of the matter and it is still as relevant today as it was when it occurred in 1974. The size of a supermarket to make the flow work was never Ohno’s concern. His unique perspective was a keen sense that any unnecessary overhead added itself to the cost of making each product. In other words, it’s easy to resize supermarkets when demand increases – just increase them. Or when demand decreases, simply let them as they are.

Back at the gemba, I know a service operation that needs a stock of service parts to supply maintenance technicians over a wide area. In the first year of doing lean, they divided the parts inventory by three mostly by isolating obsoletes. They realized in doing so that a small percentage of parts were used frequently out of the total of thousand possible parts in the catalogue. Without changing anything drastic, they installed a supermarket for high runners, which improved service OTD and reduced inventory. But then what?

The next step was to go all the way to the plan per part, a simple spreadsheet in which each part in the supermarket is defined by the vendor, minimal purchasing quantity, delivery lead-time from vendor and price. The vision was a sort of Amazon same-day delivery service: how could they purchase parts as they were needed by technicians so that they could be received singly in one day at a competitive price?

What came out of this hard work was a realization that the company wasn’t too good at:

  • Estimating technician demand – the technicians often changed their mind while in the field about the number of parts they needed for one component, which made it difficult to procure and get it to them;
  • Long lead-time from suppliers – some orders to vendors could take weeks before getting to the warehouse;
  • Large packaging – many traditional industrial vendors would only sell the parts in large packages, which made the cost per part ridiculously low, but also created months of inventory of one part at any one purchase. This means that the cost per part is lower than purchasing a single part elsewhere, but the cost of the entire packet is much higher than a single purchased part (even though single purchase will be expensive), and the n-1 parts will sit forever on the shelves.
  • Bad parts and other mistakes – typically, when one opens a large packet a high number of parts in there are of dodgy quality. When one supplies parts one by one, the reactivity on quality is much better.

TLC for Inventory

The insight from this exercise was that the inventory was a living thing that needed tender loving care. So rather than adjust it when demand varied, the guys decided that they would re-simulate their inventory once a month using the plan by part to better understand how it behaved, and to learn how to better deal with specific items. The radical change of thinking here is that the monthly simulation of how the inventory behaves according to the expected demand conditions drives specific kaizen topics:

  • How do we better understand field demand (there is seasonality), and do we have a plan per every equipment in the field?
  • How can we get closer to a instant part by part supply?
  • How can we further reduce the inventory and at what immediate price?

There is no set method to recalculate the supermarket of high runners. There is a monthly scratch-your-head exercise of looking at it line by line and wondering what we’re going to try with each part. There is no set formula, no function of lead-time and packaging size precisely because we want to challenge assumptions about procuring each component, not apply across the board formulae.

The same thinking, I believe, applies to WIP supermarkets within the flow. The reason the supermarket exists in the first place (with its related overhead) is the gap to true one-piece flow:

  1. Demand surprises, where the real demand is suddenly higher than expected and we’re short of parts, or when demand plummets and we don’t know what to do with the parts on hand
  2. Insufficient machine uptime (whether because of equipment or labor availability problems), making it necessary to produce ahead of demand
  3. Slow change overs, making it difficult to shift resources instantaneously from one component to another
  4. Large batches that multiply the lead time to get a component since time of production of A is non-production time for B, C, D and etc.
  5. Etc.,

Internal supermarkets are regulated by kanbans, so the previous thinking applies: every month we look at part-by-part behavior and simulate how the kanban generates this behavior with the twin goals of no missed-deliveries while reducing the overall inventory.

Here again, there are several formulae to calculate the link between kanban cards and parts, and some are useful, but that’s not the point. The point is taking kanban cards out, reducing the supermarkets and identifying the resulting kaizen projects, such as:

  1. Better understand demand (and seasonality is part of this, we treat seasonality as a special customer which we can level through the year)
  2. Reliability of equipment in terms of quality and uptime
  3. Flexibility of equipment
  4. The internal logistics or running trains and issuing kanban cards

In other words: the usual suspects. To your question, I would not advise you to try and find a standard method to resize supermarkets according to demand changes or seasonality.

Lean Is About Leaning

I would set up a demanding monthly review board to constantly challenge how each supermarket works and push to reduce them (sure, in exceptional circumstances, we can extend supermarkets to fend off a crisis, but that is profoundly bad!). One of the main temptations of any pull system is simply to replace the existing MRP with a supermarket/kanban mechanical system without changing the underlying thinking. Lean is not a state, it’s a process: you’re never lean, you lean what there is.

Too many manufacturers put in supermarkets, kanban and trains, and think, “Hey, we’re lean now, what’s next?” Lean is about leaning, which is about having the discipline to consider the question you ask seriously on a regular basis, and use the size of supermarkets as a driver to kaizen deeper technical questions such as our understanding of customer behavior, our understanding of our technical skills and our ability to improve flexibility. There is only one way to resize a supermarket: cut it by half!

Fighting fires vs. problem solving: what's the difference?

October 20, 2013
Back to top

Dear Gemba Coach,

I hear that lean is about less fighting fires and more problem solving but I am unsure of how one differs from the other?

Good question. “Problems” in lean tend to have a very specific definition as a gap with a standard, which is quite different from the common sense of, say, Merriam Webster’s definition: something that is difficult to deal with: something that is a source of trouble, worry, etc.

In the lean sense, problems come in two main types:

  1. Problem solving: standard performance is known, and so is the (technical) process to achieve it. Unfortunately, standard performance is not met and so we need to compare standard (ideal) to actual step by step to find the gap, ask why and come up with the appropriate countermeasure.
  2. Kaizen: standard performance is met through following the standard process, but we challenge ourselves to improve performance, say by 50%, and therefore seek new ways to achieve this by examining the process step-by-step, and without any radical new investment to start with.

In real life, obviously, many situations are problematic without any standards in place, and hence you run across the lean conundrum of “no improvement is possible without standards in place.” At the gemba, I remember several cases where Toyota engineers would intervene at a supplier to solve a problem. The supplier would expect Toyota’s guys to arrive with a ready-made “Toyota” process, which they assumed would be better than their own and solve the issue.

Problem or Fire

On the other hand, the Toyota engineers would then ask: what is your existing process? Let’s first make sure this happens consistently. The supplier engineers would then get agitated because they knew, for sure, that their own process wasn’t so good, and they expected to “learn” a new, better way of doing this or that. In some cases it took weeks for both parties to agree to first run the existing process consistently and then improve it step by step in order to achieve the known potential. This is an interesting case because the known standard in the Toyota environment tells you what to expect, what is realistically possible, but not how to get there from there. Hence, first standardize the existing process and then work through problems step by step. This we understand.

But in many cases we come across real burning fires. This is quite another sort of problem: something has happened unexpectedly with potentially catastrophic consequences and no clear way to resolve. A supplier goes bankrupt without warning and it takes months to find another. The customer’s purchasing department decides that it’s going to get 5% off the price no matter what. A bottleneck machine breaks down and no idea how or why. A supplier component is suddenly bad and no one understands why. And so on.

With your question in mind, I was walking a gemba with a CEO and we tried to categorize the problems we came across as either “problem” or “fire.” Thankfully, most of the issues we came across were “problems”: we understood what was going on, but solving it was difficult so we worked on it slowly (sometimes too slowly), but we knew where we were. There were a few fires as well, such as a supplier suddenly taking a component off its catalogue without warning because of a corporate-led rationalization. A key person in the scheduling department had a bad personal problem and lost all interest in work, that kind of thing. At the end of our walk, the CEO suggested that a problem was an issue he could learn from, whereas a fire was one with no clear lessons (other than survival).

I feel he’s on to something there. The border between problems and fires is not always clear as the size of the issue matters as much as its nature, but overall we find that we have problems in areas we look at, we investigate and we kaizen, and burning fires in areas where we don’t – and simply don’t know what we’re dealing with.

Although we don’t necessarily have clear standards everywhere, identified problems with a kaizen intent tends to clean the window and at least the ins-and-outs of the situation are better understood. Issues are then problems: they can be uncomfortable and worrying, but there’s less of a sense of panic because we roughly understand what is going on. Contrarily, areas without gemba walks, with no kaizen intent, can yield real fires, with lasting consequences on the company.

Big Differences

Take unlikely, but real, dishonesty issues – I’ve personally witnessed both an employee taking kick-backs from suppliers and two employees scamming the company for cash (thankfully, not the same company). My favorite one was an intern in purchasing setting up a supplier account and paying herself for thousands of dollars of non-existing software licenses. Such problems range from the silly to the dramatic for the company, and hence I’d advocate a system of spot-audits in any company, not to burden processes with wasteful controls, but to randomly check systems to flag any weirdness.

To answer your question, a problem is one where although you might not have an immediate solution, you understand the problem space. I know of many such problems with people who are slow to grasp some of the things expected from them: we don’t know how to teach them faster, but we also think firing would make matters worse, so we soldier on. A fire is a situation where you’re caught with your pants down because you simply didn’t see it coming, don’t know what to do and have to act quickly because if not consequences can be dire.

In my experience, lean practice definitely shifts the burden from fires to burdens. In the previous mentioned company, the CEO and I reminisced of what the business was like when he took over: every situation was a crisis and management was made of heroes – people who could jump in, yell at everyone and save the day, somehow.

Today’s company is very different, rather dull in fact. It does have a few fires burning, but the CEO knows about them and can isolate the damage and grit his teeth. Most of the other issues are problems, such as how to better improve collaboration between functions, how to better control this or that technical process and how to develop people faster – but none of this are fires.

How to Turn Fires into Problems

In this particular industry, for instance, market conditions are very tough and suppliers fold regularly. This used to be a fire, but it’s now a problem. Frontline managers are asked to look for signs of financial distress and have a few approved way to help suppliers along if necessary (as well as look for replacements at the same time). Such crises never resolve themselves cleanly but what used to be a fire has now turned into a problem. It’s no longer a case of “what should we do?” but of “how can we do this better?”

The key to turning do less fire-fighting and more problem solving? Gemba visits. By being on the gemba, looking and listening and challenging people on why things happen in a certain way, or what standards are in place (or not), executives create a mental space where fires and now less likely and problem solving becomes the norm. There will always be fires, and managers have to put them out – that’s a given. But, yes, I’d agree that one way to look at lean management is to turnaround the proportion of problems to fires, and as we learn to problem solve, the number and intensity of the fires is reduced.

Product and Process Lean

October 8, 2013
Back to top

Dear Gemba Coach,

Lean product development guys tout the gospel of product focus as core to lean success. No argument from me. But ... how, if the customers are famously wrong about what they really want, do we focus on the product and still give them what they really need? It feels like we're running on two different tracks.

Absolutely, Jim Morgan recently authored a great piece on the Lean Post “Your product isn’t everything, it’s the only thing,” and we recently discussed the need to think and talk in terms of a “product centered lean enterprise.” His point is that the organization’s product (however you define that) is what brings the enterprise together and that PURPOSE = PRODUCT, and indeed, I agree: product, people, process. But you raise a very interesting point, and a difficult one.

Nothing comes out of nothing, and everything is the outcome of its growth journey. Indeed, lean came out of the Toyota Production System, which very much came out of the manufacturing shop floor. If my understanding is correct, by the time the various kaizen activities conducted in the Toyota plants came together as the Toyota Production System, the idea was to minimize the lead-time from customer order to delivery to improve quality, productivity, flexibility and working conditions. A multitude of experiments conducted by many people somehow sorted itself out into a few principles, such as just-in-time or jidoka, several tools, such as heijunka, yamazumi, SMED, 4S, and so on, and folder after folder of standards: think we know we have to be careful of if we want to retain the quality, productivity, flexibility and safety results.

And this has succeeded spectacularly. I was recently watching a Toyota assembly line in Japan where operators were moving seamlessly from assembling a small iQ to a large Auris as well as two other models without a break of pace. No process is every perfect and, certainly, the andon chord was still pulled frequently, if you tried hard you could see some muda, and why not have a fifth model assembled on the line, or more options. And, to be fair, the first thing that struck me looking at the pace of work was that even if there was no obvious ergonomic horror, the operators must be exhausted by the end of the day. The second thing that came to my mind was that the competitive advantage from the use of capital I was witnessing, compared to other production sites I know, was astounding.

Not by Kaizen Alone

Clearly, such industrial prowess didn’t occur simply through kaizen activity, but by taking into account year after year the countermeasures from kaizen activity in the development of both products and processes. Indeed, for many years, Toyota’s main preoccupation was cars that worked at an affordable price – quality and price, rather than what people commonly think of as design concerns, such as style, options and so on. To this day, Toyota’s first priority is value for money, and, to this day, millions of automobile buyers keep choosing reliability over image. The general assumption is that customers want peace of mind, cars products they don’t have to worry about and that do the job at an affordable price. Gemba lean is a great way to provide this, as quality complaints are fed back straight to the shop floor, kaizened away, and the results are included in the product design through design standards. So, for most lean guys, customer satisfaction is a straightforward (but not easy) question of making the product right according to engineering specifications.

But that is only one half of the story. If you come across the late Eiji Toyoda’s own account of the Toyota journey, Fifty Years in Motion, you’ll be surprised to find very few mentions of manufacturing at all. The fabled Toyota Production System isn’t in the book, and kanban gets a few words, mostly as an illustration of Kiichiro’s just-in-time principles in practice. Toyoda’s main concerns over the years were in engineering. First, to make the first Japanese engineered passenger car – not fabricated from U.S. blueprints. Then, to deal with a very competitive Japanese market, such as the long struggle to get to the mandatory emissions level. Finally, the challenge of designing cars for export markets – the first car Toyota tried to sell in the U.S. was laughed out of the market. It’s engine was so small it couldn’t climb the ramps to access freeways.

Hail to the Chief Engineer

Toyota survived and, indeed, thrived in these challenging times by investing on towering technical competence. On the one hand, each new model was the responsibility of a single person, the chief engineer, who came up with the overall concept of the car that would please customers: what features to include, which to exclude, what innovation to use, which standards to reproduce. On the other extreme functional specialization ensured that every engineer was a true expert on the part under his charge: deep knowledge on narrow topics. Somehow, the balance between the chief engineer vision and the depth of functional knowledge produced cars that both satisfied customers and could be made reliably and relatively cheaply.

Kaizen on the shop floor was a direct source of engineering standards all along. Toyota engineers were encouraged to “wash their hands three times a day,” Toyota-ese for spend time on the shop floor and see how their designs really worked in assembly. Uniquely in the business, manufacturing engineering became the dominant function in the company with manufacturing engineers rotating from and to the development centers and the factories, the gemba where the production system met the development system. For engineers, the problem is not just “making the product right” but also, making the right product, which involves making sensible guesses about what customers value (i.e. are prepared to pay for).

Henry Ford once quipped that if he’d listened to his customers, they’d have asked him for a faster horse. Customers are notoriously unreliable when it comes to what they’d like or not like. Which is why customer satisfaction is a deep topic of study in lean. Although they have vague notions of what would satisfy them (and even vaguer ideas of what they’re ready to pay for), customers tend to exhibit stable preferences by segment. And the one preference Toyota has systematically banked on is peace of mind.

In the lean way to develop a new product, it’s the Chief Engineer’s job to get a hands-on understanding of what customers in the target segment will prefer. For instance, Mike Sweers, the chief engineer of the latest Tundra truck defines his job as: “First, we want to keep our reputation for quality, reliability, and durability for building that indestructible truck and making it fit American tastes and the American market. I'm just one customer, so I listen to the voices of all the customers, but that experience is the reason for bringing on an American chief engineer. And because I grew up with trucks and have always had trucks, I have a certain passion around making a truck that I'm proud to drive.”

 In designing the truck, the chief engineer chooses what to change to make it appeal more to customers (according to how he understands it), and as importantly, what not to change. In the Tundra case, the CE chose to stay with the existing powertrain which he considers the most competitive on the market, but made the truck slightly smaller to give it the best approach angle. Bumpers have been changed from a one-piece exterior assembly module to three pieces for easier and cheaper change in case of an accident, and so forth. In the end it’s an engineering gamble on value.

To answer your question, we are running on parallel tracks that must be reconciled, which is the hallmark of lean’s approach to product development:

  1. Understanding what customers prefer, not what they say they want – these are two very different things. The lean approach to customer satisfaction is an exploration of value: what do customers value in all products on the market, and how do we offer them best in class so that they prefer our product. It’s very different from the traditional approach of promising to customers what they say they want (In the truck case, always bigger and more powerful) and then under-delivering on many features of the truck in use. This mindset is reflected by Sweers following comment: “Our leadership in trucks is what we call "overbuilt," building indestructible trucks and giving our customers more than they expect. There's a lot of noise about what competitors' trucks can do, and the reality of what they actually do. My friends in Dearborn like to advertise their fuel economy, but they went from first in J.D. Power fuel economy satisfaction to last this year. Because they're advertising highway instead of combined fuel economy, their customers aren't achieving what they were promised. EcoBoost is being touted as a high-tech engine, but it really doesn't offer anything more than my current V-8 does. Consumer Reports says EcoBoost gets 15 miles per gallon, Ford's 5.0-liter gets 15, and my Tundra 5.7-liter gets 15.” History will say whether he’s making the right or wrong gamble, but the worldview is very clear and specific to lean engineering.
  2. Use engineering standards as much as one can: any new product is not built in isolation. It is the heir of driving experience of thousands of drivers. It has to be manufactured on a specific line, with other products. Lean in the factory is a machine to surface problems and come up with countermeasures. Many of these countermeasures will enrich an already immense library of standards. Creativity, in the lean environment is not free because standards must be respected. As a result, engineers need a clear idea of what is fixed and what is flexible. Customers’ expressed wishes are never taken at face value because they can easily conflict with existing standards. For instance, the decision to break the bumper in three assembly pieces probably required intense discussions with manufacturing engineering to prove that increasing work content (assembling three parts instead of one) was worth it in terms of customer preferences for ease of bumper change.
  3. Frequent product releases. Lean engineering is by nature rather conservative because of its bias towards upholding standards (which doesn’t stop from true innovation, such as the hybrid engine). On the other hand, customers tastes evolve quickly and we need to follow our customers. This apparent contradiction is resolved by a frequent product release in which only a few changes are made, as opposed to the traditional approach that tries to always come up with the all-new revolutionary product that will take the entire market. Frequent product release is made possible by the relentless drive for flexibility in the manufacturing process. New products can be built on existing assembly lines, rather than requiring the construction of a new plant. New features can be assembled with existing equipment because operators are constantly trained to handle change. In fact, customer tastes are followed more finely, because lean engineers aim to please the average customer, not the early bird outlier – that is where the core of the market is.

In the end, it’s about understanding customer preferences. I was on the gemba with a firm that produces kid playground games (swings, slides, etc.). We were comparing the designs of this company with what the leader in the market, a Danish firm, offers. I learned that an important part of designing a playground attraction is the fantasy-like aspect of the object: children must feel they’re in a car, horse, etc., no matter how abstracted the design it has to click for them. As we compared various games, we realized we didn’t have a clear model of how to abstract features from a real object to come up with a working design. We also ruefully concluded that the market maker designs were probably better at it. This is the problem, in a nutshell: how do we understand the product feature well enough, and what customers prefer about it so that we offer something that they like better than what competitors offer? – even thought they often can’t verbalize it. Customer satisfaction depends on how well you grasp the science of value.

Why is it still so hard to convince executives to adopt the lean spirit?

September 13, 2013
Back to top

Dear Gemba Coach,

Why, in your experience, after all these years of preaching lean, is it still so hard to convince executives to adopt the lean spirit?

You ask an interesting and difficult question. First, from the gemba, it’s not so black and white. Most companies I come across these days have a lean initiative in some shape or form. True, these efforts are often closer to classic productivity or cost-cutting drives, but they do use the lean vocabulary and lean tools. Why isn’t that considered “real lean”?

Another way to ask this question is how come with all the lean programs under way, there are so few transformative experiences as described in Lean Thinking, such as Wiremold, Lantech or — indeed, most Toyota suppliers? My hunch is that the answer to your question lies in understanding this difference. Many companies pursue a lean program, with lean officers training middle managers using lean tools and workshops to obtain improvements. But few senior execs commit personally to the lean journey so they never realize -- in Art Byrne’s terms -- that lean is the strategy.

Asparagus Is the Key

In the generation since so-called Japanese management erupted on the management scene with Deming’s 14 points, Richard Pascale’s The Art Of Japanese Management and William Ouchi’s theory Z in the early eighties, it has become generally accepted that any self-respecting company should have some sort of participative improvement effort based on team activities. And indeed, “lean” as a movement has fleshed out this intention by opening up a toolbox of specific improvement methods to carry this program out.

Pascale pointed out 30 years ago that, in the mind of the mainstream manager, running a company means (1) having a strategy, (2) setting up an organizational structure and (3) implementing the correct control and information systems. In my personal experience of companies, this is still an accurate description of managers’ mindsets.

Executives firmly believe that strategy, structure, and systems drive their financial results. Consequently, when the results are not satisfying they challenge their strategy (search for new juicy markets and abandon dried-out ones), they reorganize (cut the “dead-wood” costs) and they implement better systems (which IT has largely opened up by integrating reporting and scheduling on a vast scale). Executives growing up hearing about lean have now added a fourth lever: (4) an improvement program (lean, operational excellence, lean six sigma, world class excellence, production system, wear pink shirts and eat asparagus, etc.) to involve their employees in local improvements.

These improvement programs are expected to deliver savings to support the strategy and sustain the bottom-line, but are rarely strategic in themselves. The idea is that strategy, structure, and systems are the core elements but since reality fights back, the improvement program is needed to get people’s buy in and reduce the unfortunate financial side-effects of restructuring, reorganizing, and system changes.

The Real Key

When my father started learning from Toyota, first as Industrial VP and then CEO of a supplier, he had an epiphany: lean was the strategy, not a useful tool to clean-up the side effects of the existing strategy. In other words, Toyota made a basic, basic assumption which is so huge it’s hard to see

If you strive at improving SAFETY, QUALITY, FLEXIBILITY, PRODUCTIVITY by involving all people all the time in solving these sorts of problems, the resulting shape of your company will be more competitive, more profitable, and generally a more pleasant place to work.

This is a very strong assumption that involves a radical shift in focus for executives. In our recent study tour in Japan with a group of CEOs my father was always impatient about general discussions of how to do lean, what lean meant for the company and so on. He kept saying, reduce your accidents by half every year, customer complaints by half every year, your inventories by 20% and look for 15% productivity improvement, and strategy, structure and systems will emerge – they will become apparent.

If we take a step back, we see how much of a leap-of-faith assumption this can be to classically trained executives. Yet, this is precisely the insight others who have succeeded at transforming their businesses such as Art Byrne at Wiremold or John Toussaint at ThedaCare have had: improve value first, the rest will follow.

Lean in this sense can be defined by KAIZEN (improve safety, quality, flexibility and productivity) + RESPECT (do so by involving every one every day in solving problems together and deepening their technical skills). Precisely what Pascale had seen in the early eighties, balancing the strategy, structure and systems of western management with the staff, skills, style, and superordinate goals of “Japanese” management.

The answer to your question, is that after 30 years of hearing about participative employee-based improvements, most contemporary executives agree they need to complement their strategies, structures, and systems with some sort of improvement program, currently a “lean” one.

On the other hand, very few of them make the leap of faith to believe that their notions of strategy, structure, and systems will result from their drive to improve safety, quality, flexibility and productivity with their employees. Those who do so, and I know several, enter this very different room in which “lean” described by Jim and Dan in Lean Thinking – and have the corresponding results. They’ve learned to learn from lean. Learning from employee’s improvement initiative is, I believe, the heart of the lean transformation.

Can a pull system with zero stock make the company more fragile?

September 10, 2013
Back to top

Dear Gemba Coach,

Can a pull system with zero stock make the company more fragile?

Sure it can, that’s the whole point – fragile, but flexible. The pull system doesn’t make the company fragile: it reveals the weak points. Top performance is about keeping a ball on top of a round hill – it needs every body’s engagement to make sure it stays there.

Bad performance is letting the ball roll down in the valley – once it’s there every one is trying to shift the blame on each other and save their own skins because cost killing is coming fast. The pull system is the architecture that lets people cooperate on reaching top performance. The two aspects that are really, really fragile are top performance and mutual trust (which translates efforts into teamwork into results). It takes years to grow a tree, but minutes to cut it down.

Here’s a story from the gemba: a company that has focused on two main topics: (1) employee safety and ergonomics and (2) on-time-delivery with the pull system in a B2C situation, so huge variations within customer segments. Over five years they’ve increased their service rate by 20% and halved their inventory, liberating tens of millions of dollars in cash. The key elements of their pull system are:

  1. A monthly simulation of finished product stocks to check that the target numbers are aligned with a very variable demand, and a weekly production planning meeting to level the weekly demand for high running products.
  2. A sequencer that translates the leveled demand into kanban cards, picked up from the production cells by a train that runs every 20 minutes.
  3. Shop stocks at every cell, so there are no WIP parts in inventory, all parts are owned by the cell that produced them.
  4. A SMED program to continuously improve cell flexibility and reduce the shop stocks (and number of kanban cards in the loop)
  5. Milk runs to suppliers which are extended step by step to the entire supply chain and keep driving the inventories of Bought Out Parts down.

After several years of this, batches have been reduced to the hour and the number of parts in the system is low, low, low. The pull system forces the company to adapt daily to market variation, whilst learning to have the right finished products stocks so as to keep production as serene as possible. This is a daily fight that engages all people, as they all share in the battle for OTD (and a participation in the overall bottom line results). They work at it very hard, and they work at it together.

Run, Forrest, Run

Now, the company gets purchased by a larger industrial group. After the dust settles, corporate decides it’s paid through the nose for the business unit, and it needs to make its money back. So, finance reevaluates amortizations, hikes up management fees, and now the unit’s profit is not so good – which is a good challenge in itself, because the company will have to lean itself further. So far, so good.

But then, the markets are slow (it’s tough all around) and the quarter’s numbers are not going to be good. So corporate fixes it by imposing a zero temporary workers policy across the board. No replacements, no special cases. As a result, some component cells lose capacity, parts are missing, on-time-delivery crashes back to where they were when they started, losing about 20 points. The business unit tries to react by frantically moving people around and asking managers to take assembly jobs (yes, they do), but, to their dismay, this produces a few more parts but increases the general unraveling of the pull system: the ball is running down the hill. The pull system makes it worse, because as some components don’t get built, they don’t get reordered, which stops preceding processes – who then start making their own decisions about what to build, and usually get it wrong, creating inventories in the process (without solving stock outs), and run Forrest, run.

At month end, there are clear savings from the zero temp policy, but at the cost of ten times sales lost (now in back orders) and an EBIT loss of three times the savings accrued. People are unsettled and disgruntled. They thought management’s core values were safety and service, and now every one is talking about profit saving and cost reduction. Operators feel let-down, and their prejudices are reinforced: this is just another company after all.

Would this have happened without a pull system? Clearly not (but neither would the results). The pull system indeed makes the company more fragile, but not so much to external changes, but to heavy-handed management action. Seeing OTD go down and shop stocks empty is a sure sign that something is going on, and usually the opportunity to kaizen and adjust resources to better fit to market. Results are delivered by the improvement dynamics of gemba leadership where execs and operators can agree on a visible situation and work together to fix it.

Fragility Is Strength

Let me say it: if you don’t have a leveled pull in place, you’re not doing lean – no arguments.  I understand that in many environments some head scratching needs to happen before we understand how pull applies, but, hey, if we can do pull in IT development projects (and we do, with kanban) we can do it everywhere.

Pull is the key to service and quality. For instance, in the factory I was in yesterday, we were looking at the last delivery of the milk run, which had a few bad parts in a case of 50. We now have to explain to the supplier that we don’t have parts in inventory – so two bad parts out of fifty are REALLY going to be a problem because we can’t replace these bad parts from two good one from the stock. Lean is fundamentally linked to the story of the water and the rocks – but also to the fact that by lowering the water and making rocks appear and solving problems together we build in the magic element of any endeavor: mutual support and morale. The very fragility of the pull system is what keeps people engaged and working together. The fragility of pull is its very strength.

How do you define respect for people?

August 27, 2013
Back to top

Dear Gemba Coach,

Can you be more specific about “respect” in lean? The term is being used in our company but I fear it sounds just like “every one has to be a leader” and the rest of management speak.

I hear you, and when touching on people matters, there’s always that risk. In the end, it’s about the attitude of the individual manager and how much he or she cares about customers and employees as opposed to how much they want to play the game to get ahead or, in Frederick Taylor’s words, to simply “soldier on” to get the job done and stay out of trouble.

“Respect” in lean, as I understand it, is rather specific and can’t be looked at out of the context of kaizen. It certainly doesn’t have the usual sense of either admiration or, at the other extreme, simply being polite. If anything, it probably would be closer to Merriam-Webster’s meaning of “an act of giving particular attention,” close to consideration. Let’s try to put back the term in the lean context, and then see what it means from the gemba.

Lean is a definite and explicit attempt to link corporate destiny and personal fulfillment. The ideal is that on the one hand by practicing lean the business becomes better able to cope with changing conditions, and on the other it does so by getting employees to participate in the system and thus discover the satisfaction of designing their own jobs and managing their own work. Yes, I know, totally management speak, but bear with me. It is the stated ideal.

In practice, lean is essentially a system to shorten the time it takes to convert customer demands into product deliveries and to do so by improving (1) quality, (2) productivity and (3) flexibility. Lean is basically achieved by a visual system of pulling work, which will reveal problems at any and every step of operations. This “lowering the water in the lake" (reducing inventory) to reveal the rocks (problems) is the background for kaizen, continuous improvement involving small step forward, many of these devised, designed and implemented by the employees who do the job themselves.

There is clearly every where, but more likely in western company, a tendency by managers to solve the problems revealed by the lean pull system by high-level re-engineering (kaikaku, it’s sometimes called), but this misses completely the specificity of lean: kaizen. Kaizen activities are specifically initiatives by operators and their team leaders to improve work procedures and equipment. Certainly, they sometimes lead to wider process-improvement activities, but the spirit of kaizen is that it provides and opportunity for employees to exercise their initiative, judgment and creativity.

The clear goal of kaizen activities is that members of a production team work together to discover ways to raise quality, smooth the flow of production, and improve their working conditions. Now, this can’t happen without “respect” from the management line. Respect in the present sense, is a word that encompasses three broad meanings: (1) making every effort to understand the other’s person point of view and taking responsibility to help; (2) developing the person’s ability to analyze and solve their own problems and 3) supporting them in implementing their own solutions – and thus, ideally, through their wish to contribute, have employees partake in the joy of creation (yes, yes, I know, again, management speak alert).

One-Second Waste

Making every effort to understand employees’ point of view is the first point where “respect” can turn Dilbertian with any manager. For instance, let’s go to the gemba and into the prototype shop of a high-tech company. On a side of the floor where prototypes are assembled and tested, is a small store of common components, a dozen of shelves, run by a lady who’s job is to supply the shop. She complains of being isolated, sitting at her computer desk amongst the shelves, and so bothered by the noise and constant going-ons that she can’t hear herself think.

What the managers also know because they live there, is that she used to sit in the open next to the shop, in the office part, but she didn’t get on with her co-workers, and so ended up having her desk moved to the store. And there lies the rub: it’s so easy to simply ignore that person because she’s generally considered as a pain in the neck on the one side and on the other, there is no obvious way to keep the noise level down other than build a complex and costly noise barrier around the store (which would also limit flexibility in the prototype shop, as shelves can be moved according to the size of the machines tested).

The path of least resistance for any manager, is to dismiss employee concerns, because they often seem small compared to the “real business issues” the company is facing. Respect, in this sense is forcing oneself to HEAR: sure, markets are tough, sales are slow, and so on, but the employee is facing a problem every cycle, and that’s their world. Respect is about actively looking for “one second waste” and seeing the difficulties people are experiencing and taking responsibility for them.

This is rather hard on the gemba, and requires the constant training of gemba visits essentially focused on that level of issues, forgetting for the moment the higher level process or business concerns, but looking for muri, mura and muda within one operator cycle – which is how the “7 wastes” of overproduction, waiting, conveyance, processing, inventory, motion and correction came to be formulated. This is also how they can be misinterpreted by managers seeking waste-reduction hits, rather than using the list to focus on work within the individual operator’s work cycle: foot motion, hand motion and eye motion.

Priming one’s outlook is essential to be actually able to discuss with operators what their real concerns are, and take them seriously. For instance, I recently heard operators complain about the fact they had to badge out at pauses for whatever internal HR control reason, and that walking to the badging point ate several minutes out of a twenty minutes work break. The manager nodded but didn’t pick it up (it’s always been like this), but clearly missed an opportunity to demonstrate respect by taking responsibility for this issue and working with the team members on how to fix it.

Yeah, Right

The second aspect of “respect” in lean is the respect for the development of the person’s autonomy to solve their own problems, which is essentially teaching problem solving. This, again, is tricky. Many people simply don’t want to solve their problems, they want their problems solved by management – period. The lady complaining of the noise doesn’t want to seek the root cause, she just wants someone to fix it. This second element of aspect involves management starting a dialogue with the employee about what the problem is, what the real root causes are and how to evaluate what could be an acceptable solution. Here again, we can see Dilbert look blankly as the pointy haired boss turn this conversation in an exercise of absurdity and disparagement (“Who’s your leader? Go on, say it!”).

The problem solving dialogue can be difficult and perceived very differently according to where one stands. The manager is supposed to challenge the employee:

  • What is the real problem?
  • What are the causes? Why? Why?
  • How would we measure a successful countermeasure?
  • What alternatives are you suggesting?
  • Have you confirmed results?

Without common trust between the manager and employee, this could very well be interpreted (and not necessarily wrongly) completely the other way:

  • What is the real problem? Yeah, I know, you don’t think it’s a problem and the real problem is I’m a slacker making a fuss.
  • What are the causes? Why? Why? What do you mean the root causes? Can’t you see the root cause is you haven’t invested in making this work station safe?
  • How would we measure a successful countermeasure? How should I know? I just work here, and you’re the ones putting everything in numbers – managers, ha!
  • What alternatives are you suggesting? Why do you want to hear that for? Whatever I say has been dismissed for years – you’re not getting me to volunteer for anything that will fall back on me.
  • Have you confirmed results? Yeah, sure, sure.

Drifting Toward Dilbertland

The third aspect of “respect” in lean is that employees genuinely feel they’ve contributed to the greater enterprise of “monozukuri”, making products together. This is why lean programs highlights “suggestion of the month”, and not “employee of the month.” The genuine lean vision is that every person should contribute their ideas to their job, and do so hands on, by visualizing a problem, analyzing the causes, picking a smart solution and being part of the implementation. The intent is that every employee experience the joy of creation and the pride of contribution: see, I made this, and they were happy with it and we’re still using it.

Here again this is complex because many employees simply might not want to be part of any such effort. The lady in the parts store shows no interest in looking at the different solutions for lowering the noise – she’s just not interested. So what do we do? Well, this is a test of our managerial ability to show respect and to take it easy, and try to improve the situation slowly on small specifics knowing we’ll never completely solve the issue, or engage the person.

Ultimately, the test of the practice of respect is whether it develops common trust. Not all situations can be sorted it out to every one’s satisfaction, but in some gembas, conversations are easy and the general feeling is that win some lose some, but every one involved was being forthright and straightforward and trying their best. Certainly, with a cynical bend of mind, mutual trust is one more item on the management speak list and I don’t doubt that in some companies “mutual trust” can hide an ugly “align yourself or else,” but that’s my point – it’s all about intent. Every person is different, every person has their own values and is free to act in any way they feel like it.

In any case, the lean ideal for respect is pretty clear: make every effort to understand each other and take responsibility for others’ problems, develop every person’s problem solving autonomy, involve every person in designing their own jobs and managing their own work and partake to the joy of creation when ideas become a reality.

Like any ideal, the bar is high, and the reality of the gemba is often different, and it’s tempting to cut corners and let the pretense replace reality. There are no safeguards against this, and, as always with lean thinking, it comes down to the people who “get it” as opposed to those who “don’t”. Looking back, one thing is very clear: kaizen and respect can’t work without another. Kaizen without respect simply becomes yet another corporate rain dance.

But, oddly, “respect” without kaizen is probably worse. Without a common sense of the problems we all need to solve for the success of the company, managers and employeed are engaged in a context-free dance about well-being at work, which can’t ever be resolved and easily drifts into Dilbertland. The intent is to align individual success with value for customers (and in doing so, company success), but that intention also hits the rigor of the gemba, and thus the discipline of learning: practice respect a bit every day, all people all the time, and watch trust grow carefully and patiently.

Why reduce inventory further?

August 7, 2013
Back to top

Dear Gemba Coach,

We have a lot of machining operations in our process, and we carry inventory. What is the best way to show employees the value of reducing inventory—and how this relates to the need for continuous improvement? Our employees believe that some level of inventory is necessary to keep parts flowing, and that they’re already good at what they do, so there is no need to aim for better.

You’re asking a deep question that goes way beyond those guys in machining who won’t accept that holding inventory is wrong. This is a question that goes to the very core of lean thinking.

Twenty years ago, when my father, then industrial VP for a large automotive supplier, invited a lean sensei from Toyota to talk to his crowd, an elderly gentleman arrived from Japan with his interpreter and asked to see the shop floor.

With all the divisional VPs around him, he went to an assembly cell and watched the operator perform several cycles. After a good long while, he walked to the workstation and moved a component box closer to the operator. After more watching, he moved it slightly to the left, before saying “yosh!” (good).

Then he returned to the meeting room and drew the lake and the rocks while the translator explained that the level of the water represented inventory, and that reducing inventory would make the “rocks” (i.e. problems) appear. Then they returned to Japan, leaving my dad to explain why the demonstration mattered to a bunch of very irate Important People. Indeed, these two basic messages were probably the most profound lean lessons. And it would take many years until we finally understood their impact.

One Second Waste

The first lesson is that all lean thinking starts at the operator’s station looking for the “one second waste.” Lean tradition is very clear: first do motion kaizen, then machine kaizen and finally process kaizen.

Twenty years later, many people continue to blur the distinction between lean and re-engineering (and I should know, having made the same mistake and written a book about re-engineering), using VSM to reconfigure entire processes before having done the gemba work of motion kaizen with operators. The critical question that we initially failed to prioritize was “What is the mission of the operator in whatever you’re doing?” Eventually we realized that understanding the operators work cycle and how they felt about their job was the key to making the correct higher level decisions. By focusing on “one second waste” you can talk to the operator and improve motion, and then you’ll realize that a good part of variability and unnecessary motion is created by machine instability and poor equipment design, so you can learn to fix that. In doing so you learn a lot about what the ideal process should really be. If, on the contrary, you re-engineer the process right away (okay, call it kaikaku if it sounds better), then you’ll find that you’ll have enshrined the same inefficiencies in the new process – and never go beyond cleaning the window into real understanding of the technical challenges of the plant. Lean starts with the operator.

The second lesson is equally important: reduce inventory. If it’s already low, reduce it again. Back in the day, we were very proud of finally having understood that (1) inventory is bad because of the cash drain on the company but (2) that inventory is the result of process performance and can’t be affected directly (as any who work in a year-end driven company will know, reducing inventory drastically is possible, but then every process stops delivering: you can’t increase the car’s speed by pushing the needle on the speedometer) and (3) that you had to resolve many problems to reduce inventory.

It took us years to fully understand the lake and the rocks. Reducing inventory is good for business, certainly, but it is the main learning driver of lean. Forcing yourself to reduce inventory regardless of its level (whether good or bad) will make problems appear – the problems you need to solve now to improve. Reducing the inventory is a learning strategy. The reason for reducing inventory constantly is not problem solving but problem finding.

In fact, as Taiichi Ohno saw early on, lean is a system of related activities, so reducing inventory has to go hand in hand with other key problem finding activities:

  1. Reducing accidents and professional illnesses: what is the main cause of accidents? What is the main cause of professional illnesses? Are we doing enough kaizen on these topics?
  2. Reducing non right-first-time: start by distinguishing complaints spotted at the customers, at final control at the end of the line, at the workstation within the line. The closer the defective is spotted to where it is created, the more specific the problem, and the more lasting the fix.
  3. Reducing lead-time: inventory is one part of the equation, but it should always be considered in the light of on-time-delivery. In general, reducing lead-time in the process will make waste appear.
  4. Reducing overcosts caused by waste: muda is typically generated by muri (overburden), mura (unlevelness) or both. Visualizing the mura created by operating conditions is key to defining the cost problems in the process and how to reduce them.

Correctly Formulating Challenges

It’s a system: tackling inventory alone will lead you to make incorrect decisions unless you look at the impact on safety, delivery, quality and cost as well. For instance, many of the most productive automotive factories were shut in 2008 ( ) – defining the problem as productivity doesn’t save you from certain death, if you haven’t looked at build-in quality as well.

The point is that the intent to reduce inventory (as well as accidents, late deliveries, defectives and costs) is essential to lean thinking, not as problem solving techniques, but as problem finding strategies. Challenging yourself on these core dimensions will lead you to formulate the problems limiting your company’s growth. Correctly formulating challenges is the key to leading kaizen in the right direction (true north) and solving problems today in a way that opens up tomorrow as well.

How can you convince the shop floor guys to reduce their inventory? Well, the truth is you can’t – not if you phrase it like this. Inventory is the safety net that enables them to deliver to customers in their current situation, and they won’t understand why you’re trying to take their breathing space away.

This is not an issue that you can solve at factory level. Inventory reduction needs to be defined as a company endeavor (inventory reduction in a sensible way, not just cut the stock and never mind what happens). Inventory has to be expressed clearly as a corporate target, with each factory regularly coming up with its own specific inventory-reduction plan. Furthermore, it’s corporate’s role to constantly explain the deeper reasons for inventory reduction: better service, greater reactivity, greater flexibility. If the CEO demonstrates this is important for him or her, workers might shake their heads, but they will accept it.

How do you ever persuade someone of doing something they don’t feel like doing? Hard, right? Nonetheless, a few strategies can help. In cases where there is no clear and immediate self-interest, adult motivation is very sensitive to both autonomy and task significance. Many people are likely to make an effort if they can see that (1) it matters and (2) if they have the (relative) freedom to carry out a plan according to their own initiative.

To answer your question, to convince your guys to reduce their inventory, you need to first reinforce constantly how important it is for customers (better service) and for the business (cash on hand) as well as help them to come up with their own local plans for inventory reduction through greater flexibility. By reinforcing both their autonomy and their perception of the work’s significance, you’ll let them make up their own minds about it, rather than trying to force them to apply SMED.

Should I use an A3 report to kick off a problem-solving effort?

August 1, 2013
Back to top

Dear Gemba Coach,

Should I use an A3 report to kick off a problem? I encourage my managers to tell me about their problems on the shop floor. They always pull something out of the air and say ‘lets work on this...’ What I would really like is for them to create some kind of A3 report that explains why this problem is happening. Any advice?

Are you pulling?

In other words, my advice is not to bother with A3 until you have a leveled pull system in place. That said, your question is actually quite complex. Don’t take this the wrong way, but I’m worried by how you’ve phrased that question. You shouldn’t have to get your managers to tell you about their problems on the shop floor. You should be on the shop floor with them pointing out what you consider is a problem. There are three aspects to this:

  1. Gemba leadership: what is the manager’s role on the shop floor?
  2. Problem finding: how can you tell what is a problem and what is not?
  3. Problem solving: how to support people in solving their own problems?

In traditional management, problems are reported up, considered at the executive level and then either dismissed as something that frontline management should deal with; or “solved” on high, with the execution of said solution prescribed down the line at the workplace.

The Gemba Is Not Enough

Lean’s approach is radically different, as executives go to the gemba to see for themselves, spot issues and then get frontline managers and workers to agree on what the problem really is. Executives fire off kaizen topics to further clarify the problem through action until it is fully understood and shared, by which time shop-floor teams usually have a pretty good handle on the countermeasure they should implement. Management remains involved, to sign off in case investments are needed, and to study carefully the effects of whatever action is taken by frontline managers and their teams.

The first skill of gemba leadership is therefore to be able to see problems without having to be told, or without asking for explanations. As Taichi Ohno reportedly said, “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 muda you have to cultivate the ability to see muda. And you have to think about how to get rid of the muda you’ve seen. You jut repeat this — always, everywhere, tirelessly and relentlessly.” (quoted in Satoshi Hino’s great book Inside The Mind Of Toyota).

Should you take Ohno’s advice seriously and follow it, a large part of your question resolves itself: it’s about confronting your vision of what is a problem and what your managers consider to be a problem. Sharing and debating both perspectives will lead you all to more observation together, and to progressively agree on problems – no A3 needed at that stage. Please, please, please, do not think of using A3 as a reporting tool so that they present what they consider a problem to you in an office!

Yet, going to the gemba is not enough – if not, Managing By Walking Around would have won the day back then. The question is: how can we tell what is a problem and what is not? Certainly, there are some glaring problems, usually around safety or delivery – but how do we go beyond the obvious?

Bear with me as we detour slightly via cognitive psychology. Nobel Prize Daniel Kahneman has shown that when faced with a complex problem we all tend to answer with a substitute problem that we know how to solve. Say I ask you what are the three most populous cities in the world? You can’t stop your mind from saying what pops into it such as Mexico, Tokyo, and Shanghai (or whatever). You’ve actually substituted the question “large cities I remember” to the original problem “most populous cities.” The real answer is more complex. In terms of cities proper (without suburbs), Wikipedia says: Shanghai, Istanbul, Karachi. Metro areas would be, according to Wikipedia again: Ahmenabad, Atlanta, Bangalore – not at all what I’d have thought.

The trouble is that not only do we substitute, but, to make matters worse, this substitution is unconscious and leads to what cognitive psychologists call “frame blindness” – the blindness to the fact that our point of view is just a point of view and not reality itself. Hence people become attached to their answers, feeling that they have solved the problem (at least partly), when they have in fact answered a completely different problem. As a result of frame blindness, it’s easy to solve the wrong problem, ignore promising options, and or lose sight of important objectives – while feeling all the time we are absolutely correct.

No A3 Needed

I’ve learned the hard way on the shop floor to suspend judgment on what the problem really is until they’ve set up a working pull system. The pull system, with its truck preparation area, leveling board, shop stocks and kanban cards will visualize the “lake and the rocks” and show where the problem occurs and when – often very different from what we’d agreed on previously.

Amazingly, this work with quality as well. Not at first, unfortunately, but as cells start working in one piece flow, each part is now examined by operators at each step of the process, and they shout out when something is not right. In doing so, we finally discover what is really wrong with the parts and what can be done to improve quality. Without one-piece-flow visualization, many quality issues stubbornly remain on Pareto charts because no one can actually see where and when they occur.

A good visual management system quickly indicates the difference between OK and Not-OK, normal and abnormal. Without it, problem finding is subject to normal cognitive biases such as problem substitution and frame blindness without recourse. With visual management, problem finding is steered by the tools on the shop floor, like a large pointer in a video game. Once the pull system is in place, it becomes very easy to get everybody to agree on problems as we can all see the pull system fail over right there, and start investigating why. Still no A3 required. And, actually, experience shows A3 or 5 Why on the wrong problem can badly lead you astray as we can see every other day in A3 reviews. Recently, I saw a complex A3 about how to make labor flexible enough to move operators more easily from one cell to another when a look at the leveling plan showed that the issue was with the lack of flexibility of the cells – not at all the same problem.

What about A3s then? Well, when you’re on the gemba, your pull system is showing you where the problem is, you’ve got a pretty good idea of what the typical problem is and what kind of countermeasure you expect, THEN A3 is a very powerful tool to develop your frontline managers’ problem solving skill. Rather than give them the answer, you’ll ask them to write an A3 to work with them on what the problem is (and what standard/indicator to follow), how to frame the problem (and how to grasp the situation with alternative factors), how to formulate the problem (which factor is confirmed and where to start the 5 Whys?), how to consider alternative strategies (and evaluate several options), how to follow through the implementations and what lessons to take away from the experience. A3 is a wonderful coaching tool so that people can be developed without having to give them the answer. But, you need to be clear about the problem first, even though your initial diagnosis might be changed by what they discover in the process of doing the A3.

To sum up, starting an A3 report is a very good way to kick-off a problem IF you’re experienced on the gemba, have established the visual management of a leveled pull system, and have some generic idea of what the problem is in the first place. In these conditions, the A3 will allow your managers to solve the problem by themselves under your guidance and without losing themselves on the way. On the other hand, asking your managers to draw A3s to tell you about their problems is definitely not such as good idea – A3 is no substitute to reporting – and you’d be better off in going to the gemba and practicing good observation and good discussion instead.

Does quality really come first?

July 22, 2013
Back to top

Dear Gemba Coach,

I’ve been practicing lean for many years and have learned to create one-piece-flow. However I still struggle with quality problems. I hear that quality comes first, but face many challenges trying to put this phrase into practice. What’s your take on this?

Safety always, quality first – these are the first values of lean on the gemba. You have a tough problem, one that I struggled with for years. I believe that you must take a new approach—that the key is to switch your mental model from “fix quality problems” to “fully understand quality causes.” Let us ignore quality systems for a second (I’ll come back to them), and think gemba.

The problem with understanding the causes of quality is that most processes are not easily visible. We know how to test the quality of the assembled product, but it’s often hard to test quality of the components or the assembly – and even harder in process industries. Imagine that you are making steel sheets, all rolled up. How can you tell whether there is a defect in the middle of a coil? Or if you’re assembling an appliance – how can you tell whether it’s going to work before you turn the switch on? This, then, is the starting point of lean’s approach to quality: let’s delve in.

First, you have to commit to be able to tell the difference between a good product and a bad product. And I don’t mean the paperwork, but the actual object in your hands. This is definitely a case of Ohno’s “look with your feet and think with your hands.” If you’re serious, you’ll find this an endlessly intriguing problem because of boundary conditions – obviously good versus clearly bad is easy to spot.

But many products are somewhere in between, and that’s when the real quality thinking comes in – what is the customer’s sensitivity range. Customer’s senses don’t usually work linearly. Recently I was looking at door frames on a construction site. The supplier doesn’t control the folding process visibly and when we looked at the inside corner of the frame, some showed significant gaps. But typically, a doorframe is not something you’ll notice much as you pass through. Nonetheless, there were thresholds: the misalignments I could see right away (having dealt with such issues often in the past on different products) and the misalignment the constructions guys could suddenly see because, well, how could you not see it. The customer might not consciously see that, but it will certainly impact their feeling about the quality of the apartment. So it’s really important to commit oneself to really understand the Taguchi utility curves of various aspects of the product. I’ve never seen one actually quantified, but just exploring the concept makes you look at products differently.


Once you’ve got a better feel for good versus bad product, jump in immediately. Don’t take “can’t do that” for an answer. Start working on how you could optimize OK or Not-OK results in the manufacturing process itself. Don’t do this on your own but start working with the operators and try to see through their eyes.

Word of Caution

I was in an equipment factory recently and we were trying to figure out how to avoid assembling defective, painted cast iron parts. How can the operator possibly tell whether there is rust under the paint somewhere (which is likely to crack later on and create blemishes on the product)? Of course they can’t, but when we asked the operators to isolate any cast part that simply didn’t feel right, we discovered that they picked up a lot of faults (some of them rust) in ways we couldn’t figure yet.

I’m not saying this is easy. I’m saying that the answer to your question is first to commit to know all there is to know about the boundary conditions between a good and not-good product and then get to work with operators to see how we can make better, smarter guesses at each step of the manufacturing process without being over selective.

Word of caution – the quality system is not likely to help you there, because the quality guys are likely to go crazy about this and, since they’re being challenged, impose hyper restrictive process rules (Design Of Experiments? Anyone?). That is clearly not lean – it just burdens the process with unnecessary costs and without learning anything about the process itself. Squeezing the supplier is rarely – if ever- an answer. We need to fully understand the problem, not make it go away through paperwork and restrictions.

The good news is that one-piece-flow helps significantly. As long as the operator can simply discard the dodgy part and help himself or herself from a full bin of the same component, that’s exactly what they’ll do – they just want to get on and make parts. With single piece flow (and I’m talking single-piece-flow, not two or three-piece flow), the operator has to deal with the suspicious part and either take the chance to assemble it anyways, or chose to call for help. Usually, guys want to do a good job, so if management asks them to shout out at any dubious component, they will. But management needs to want it.

Can’t Manage Quality

In the same equipment plant, we were walking our way back in the process and found ourselves at the inwards reception dock. The company had just made a huge leap towards better JIT by creating milk runs for their cast parts. Castings now arrived every day, not in twice a month shipments. So, the management team was standing there on the gemba around a stack of crates (the day’s arrivals) discussing the merit of milk runs until the sensei asked, “Well, are we going to open them or not?”

When they finally did (not without the usual grumbling and defensiveness about quality assurance and so on), as chance would have it, the very first part out of the box has a massive rust spot on it. The second had a small tear in it – I’m not making this up, I swear! The point is that leaning the process towards better JIT and eventually single-piece-flow is the best way to start looking at components part by part and stop thinking batches. This is the uniquely lean way to do quality.

Most quality systems are not set up to deal with that level of involvement in quality. Or when they are they become incredibly burdensome. The issue here is that many quality systems are designed to manage quality, not to develop quality maniacs. You can’t manage quality. You’ve got to immerse yourself in the theory of practice of the process. If we’re dealing with cast parts, we’ve got to start thinking in terms of materials variation, temperature controls, and design specs. No amount of paperwork is going to help with in-depth knowledge.

If I had to sum up lean’s unique approach to quality it would be TQC without the paperwork. Don’t work at batch level, focus at product level and start seeing that no problem, no matter how small, is uninteresting because we’re not trying to “fix” the quality issue, we’re trying to better understand how quality is built into the product by the process (or not). Quality and just-in-time work hand in hand. It’s a matter of attitude: go to the shop floor and work with operators to try to figure out how to visualize bad parts from good parts, bad process operations from good ones, and learn. As you do, quality will improve, teamwork will improve, and, ultimately, if you can  report back what you learn to design engineers, products will improve as well.

Can lean go wrong?

July 15, 2013
Back to top

Can the ideas be misused and can the outcome be bad for the company? Is there any way to prevent this?

Of course lean can go wrong. Any powerful set of ideas can go horribly wrong if used with the wrong intentions – just think of Darwin’s theory of evolution. The most powerful scientific theory of the nineteenth century was turned into “Social Darwinism” by a group of mean-spirited nuts, completely contrary to Darwin’s intentions, and Darwinism as a whole is still blemished by that. The same with lean, I guess. Used as a cost-cutting program (often sold as by consultants), it can indeed go wrong. It’s all a question of intent.

So let’s examine lean’s intent, typical syndromes and how to safeguard oneself against such misuse. I define lean as a set of learning activities that enable people to see the way they work with fresh eyes and improve their processes by focusing on:

  1. Muri: eliminating overburden on people and equipment, which creates accidents and breakdowns.
  2. Mura: stop-and-go variations, often created by either muri or silly planning (created demand) which strains people and equipment by creating peaks of activities and then troughs, and is a strong drain on resources
  3. Muda: wasteful activities that pollute work, demand energy without adding any value. Waste is built in any process, and is likely the results of muri, mura or both. The intention of lean is indeed to train every person to see the muda in their own work processes and come up with ideas to reduce it.

Note that waste reduction actions should NOT create either muri or mura. If they do, then clearly the thinking has gone astray and the action must be reconsidered. Kaizen is change for the better, not change for change’s sake.

At program level, the intent of lean is quite straightforward and explicit. The CEO is expected to go to the gemba frequently to learn how to:

  1. Safeguard employees – and guarantee their safety
  2. Protect customers from poor quality and missed deliveries
  3. Control the lead-time by rigorous flowing, leveling and pulling (which involves solving many muri and mura problems)
  4. Reduce lead-time by increasing flexibility
  5. Cash in on the cost opportunities reductions these activities will reveal.

The activities are carried out by employee’s involvement and engagement. Without the intent of participation of all people all the time, there is simply no lean. There might be a successful improvement program, but it wouldn’t qualify for the “lean” label.

Certain Failure

Lean can spur radical change at the executive level—specifically by fostering a type of “gemba leadership” that contrasts with boardroom leadership in two main ways. First, in lean, the locus of management is the workplace where the CEO engages in observation and discussion with the people adding the value themselves – and not with a handful of top executives looking at PowerPoint strategies and plans in the boardroom. Second, the aim of lean is to fully understand the problems we’re facing and to share their formulation across the company rather than jump at execution strategies and then pushing them through.

Oddly, even good management teams find it challenging to execute on this goal. At one great company I observed, at the debriefing after one of the first gemba walks, the management team concluded – correctly – that operational people were not talking to each other. I (foolishly) suggested creating an open plan to improve communication. These were good people, and they jumped on the idea and implemented it right away (much faster than I’d expected) without involving the people themselves. This created a big hoo-hah which the lean effort almost didn’t recover from.

In the end, the dust cleared, people got used to the open plan with modifications and the management team learned the key lesson of kaizen before you leap and went on to some rather spectacular results – but we still remind ourselves about it when we fall in love with a solution without having fully agreed on the problem first. Developing gemba leadership is one of the main points of lean and without it, failure is almost certain.

Wobbling Off Course

With hindsight, what would be sure signs that the lean initiative is getting off track? Every company is different, but I sometimes say that every lean success I see is different, but failures invariably come down to one main root cause: the CEO failed to get the “gemba” bug. Here are some of the symptoms:

  • The CEO supports lean, but doesn’t do gemba walks with a sensei. Because so much of lean is about understanding intent and the interpretation of general principles in specific contexts, the sensei-CEO discussion is essential to reaching the proper conclusions. Yes, sensei are hard to find, but that’s part of the journey. How to know whether someone who claims to be a sensei really is? My trick is to ask who is his or her sensei: I count the degrees of separation with Taiichi Ohno (My sensei is my father, who’s sensei was Mr. Hayashi, who worked for Ohno).
  • The lean program leader is not personally involved in the lean community. It’s very hard to reflect on one’s own, and the understanding of lean concepts evolves – the lean community around The Lean Enterprise Institute is the best place to test one’s thinking against other experienced practitioners. Not investing in doing so casts a serious shadow of doubt on the person’s learning attitude.
  • Consultants have sold a “kaizen blitz”. If consultants have sold a program of kaizen events, they need to show results no matter what. If there are obvious low-hanging fruit, this can be a good way to get started. In industries far from assembly, this can lead to ugly mistakes.
  • It has been decided that the leveled pull system doesn’t apply. Leveled pull is a basic anti petty boss tool: it stops workplace management from doing whatever comes to their mind, and steers everyone to a better, steadier flow of work that will show overburden and variation. If the lean program can’t figure out how to do level pull, (1) they don’t know what they’re doing and (2) whatever low-hanging fruits results they find won’t be sustained. One simply can’t claim to take JIT and jidoka out of lean and claim that it is still lean: it ain’t.
  • Someone says “you can’t make an omelet without breaking eggs.” If you hear this, run and hide – the lean effort has lost its way. It is absolutely true that people can leave the company because of lean, but they do so because they don’t agree with the changes, not because they’re pushed. Not every one is expected to get along, but it is lean’s firm intention to involve and engage every one – not force them.

Mutual trust is a key, explicit, element of lean. I have walked gembas with senior execs and we’ve looked at kaizen activities asking ourselves: “are we reinforcing mutual trust or not?” This is an essential calibration because kaizen can go astray even with the best intentions. So we question and we reflect. That is the intent of lean.

Can lean, as an approach, be blamed for its faulty interpretations? To be honest, I personally don’t think so (admittedly, I am biased as I have a dog in this fight). Ten years ago, maybe, much of lean was about reengineering processes to improve flow. But over the past ten years there have been many efforts such as John Shook’s Managing to Learn or Mike Rother’s Toyota Kata to explain the people involvement dimension of lean. These books are hard to ignore, and so, if people still do it’s on them. The engine of lean is about getting the improvement loop working:

Better results = better people + better processes

 In lean terms, this means on the one hand continuously training people to standards (on the job) to improve their competences about existing processes, and on the other involving people in kaizen to improve processes – often according to their better understanding of the gaps to standards (i.e. problems in lean’s definition). This is what I personally look for on the shop floor: can people show me examples of muri, mura, muda, and have they got a way to train employees to standards and involve them in kaizen of their own processes. If I see that, I’m pretty confident that the lean effort can’t go much wrong, and is actually likely to go right for all stakeholders.

Why aren’t the laws of lean articulated?

June 19, 2013
Back to top

Dear Gemba Coach,

Aren’t there laws of lean, just as there are laws of physics? And why aren’t these clearly articulated yet?

This is a very intriguing question and you’ll have to bear with me if my answer is not as straightforward as one could wish – my doctoral background is in “knowledge sciences” (whatever that is), and the question you’re asking is not as simple as it sounds.

There ought to be laws of lean, surely, and I feel as you do. But there is a drinking game we’ve played with LEI CEO John Shook – for every lean “law” I propose, he finds an opposite law that would work just as well. For instance, I’d say something like I feel is self-evident such as: “lean thinking is a process (how do we make this leaner) not a state (Are we lean yet?)” John counters that “lean thinking is a worldview that entails holistically grasping the dynamic (never static) relationships between process, people, and purpose and moving them into balance,” and so on. It’s hard to dispute either, but it’s also hard to come to any general conclusion.

I’ve been thinking about this long and hard and my hunch that our very looking for laws of lean reflects a profound misconception. The two founding concepts of lean were (1) to increase production efficiency by consistently and thoroughly eliminating waste and (2) to respect humanity by developing every worker to his or her full ability. The basic methodology is “the lake and the rocks” – by reducing the lead-time, waste appears. By solving the problems and eliminating the waste, the timeline from customer order to collecting cash is reduced, and hence production efficiency is improved.

Waste is created by human beings – that’s Taiichi Ohno’s core intuition. People’s misconceptions about efficiency make processes wasteful. Actually, it’s not so much that there are efficient processes versus inefficient processes in absolutes, but that circumstances change and that efficiency is contingent on people and technology. For instance, I was last week in a plant that makes a wide range of rather simple products (a few components to assemble to a casting body). Assembly of one product typically takes from a few seconds to a few minutes by a skilled operator according to the type, but the products vary in size from the hand-held variety to the several tons kind. The factory floor therefore looks like a schoolroom arrangement of single-product, single operator workstations (too few operations to make lines worthwhile and too many product differences to have standard stations).

It makes sense when you think about it. As a new product is put on the market, demand is high, so it’s easy to occupy one operator all day long building the new product. But, when the product starts to lag, or the market turns sour as it is at the moment, what happens is that an operator will do the day’s production in a few hours, sometimes less (or, conversely, several weeks of sales in a few hours of production). As a result, one operator will move from one station to another several times in the day – which is massively inefficient, as each change entails significant loss of time (up to twenty minutes to finish with one station, with clean up and etc., and starting up at the next station).

By thinking about takt time and single-piece flow, we quickly realized that if we could have an operator build enough products on one station without leaving the station and without overproducing, the productivity gain would be massive. The issue now becomes to be clever about redesigning work stations to be able to build a wider range of products, which requires a lot of collaborative head-scratching and working with the operators themselves. It’s all contingent. In a situation where demand is high, it’s smarter to have one station per product working at full speed. In a situation where demand is low, it’s worth hassling with multi-product stations so that operators don’t move around so much during the day.

Arguably, a multi-product cell is better because a larger basket of products should absorb better market variations than a single-product cell, but, let’s face it, a mutliproduct workstation is not likely to be as efficient or ergonomic that a single-product station (until we get MUCH better at solving many intractable process engineering issues). The issue here is whether we seek to (1) apply a law, as in “thou shalt produce in single-piece-flow” or (2) develop people by using single-piece-flow to reveal the kind of waste they tolerate in the systems they’ve created. Again, products are made by people for people, with people. I can’t think of any natural law that is applicable where so much people are involved. The only certain thing about statistics is they don’t apply at the individual level, and reality is contingent.

Bag of Tools

The purpose of lean techniques is to reveal waste, not to create the perfect process – which, by the way can’t ever exist since something can always be improved. The test of good visual management is to be able to see at one glance whether we are in a normal or abnormal situation. All lean tools tend towards that, from pull just-in-time tools (ahead or late compared to customer demand), to andon and jidoka tools (operation is OK versus not OK), to kaizen and standards, seeking to understand causes always in greater detail and depth. At the end of the day, the lean tools are essentially a bag of tricks to test production as it happens – the “confirmation method” essential to any hypotheses-testing analysis.

However, your question raises a deeper point. Scientific thinking appears when rather than trying to solve the problem, seeing whether it works, trying something else if it doesn’t and doing so until we’ve cracked it and we move on, we explore several distinct hypotheses in parallel and confirm them regardless of whether the problem has gone away or not -- this is the essence of set-based concurrent engineering, a unique lean engineering technique.

So far, my understanding of lean has hinged on the notion that “in order to make products, you have to make people.” In my work with companies, I have hitherto focused on (1) people development – knowing how to best use the equipment we have to produce good parts and (2) machine development – continuously improving equipment and automation to support people in producing the best parts. I had completely missed the importance of the test methods in the development of knowledge. In most high-tech companies, we find a number of test and calibration tool, but we’ve never looked at them as other than linked to the process. Recently, I’ve started taking a closer look to the development of measuring tools as well, and the impact on process understanding has been surprisingly quick and significant. Although I make TPS veterans smile with my newest discovery (it just sounds obvious to them – they’ve been practicing jidoka all along) I now look at three development programs to improve the overall process:

People development

Equipment development

Measurement development

To return to your question, overall, I suspect that seeking laws is about seeking permanence, whereas lean thinking is about seeking adaptability. Laws are reassuring because we have such trouble with accepting that things change all the time: life is not always fair, the goal posts move and there are no guarantees. There may be “laws” of lean thinking, and yes, one-piece-flow or stop-at-defect might be more effective in absolutes to any alternative. Whether this is the case or not, I believe this is a rather fruitless path to develop our understanding of lean. The question should rather be how well we master our current test methods, and what does this tell us about technical and human processes we did not see before. The questions we ask define our reality, so, in the poet’s terms, we’ve got to learn to love the questions.

Why don’t middle managers practice A3 thinking? (Part 2)

June 3, 2013
Back to top

I believe the key to make your A3 training program more successful is to make sure that it is aligned with lean’s core values – and yes, that will mean tackling your client’s senior management in order to make sure the right prerequisites are in place:

  1. Challenge: how do you phrase middle managers’ missions in terms of problems to solve rather than solutions to apply? If you haven’t got this right, none of the rest is very relevant. Are the challenges clearly expressed? How many challenges are detailed individually? You must clarify minimal job roles. A middle manager typically has operational task as well as project tasks. What are the simplest, most freauent operational task they have to perform? What is the ONE priority project they have to focus on? By clarifying a MINIMUM role,  the manager can have better results in their day-to-day, not screw up the reporting as well as have time/energy (even enthusiasm?) to focus on the problem you’ve asked them to solve.
  2. Genchi Genbutsu: having a clear and commonly understood plan of policy deployment is critical. Having senior managers commit to a calendar of gemba visits, to see what the project is doing at the value-adding workplace level (rather than disembodied reports) is the most powerful way to gain traction. This behavior shows the organization that this project is a priority, that you’re interested in their results and how they go about it. Furthermore, the gmeba visits are likely to have a strong modeling effect on the middle-manager himself or herself who (we can hope) might eventually pick up the practice.
  3. Kaizen: in mainstream management, many solutions are formulated in terms of optimization: what we have doesn’t work, so let’s break it and refurbish it optimally. Unfortunately, the same problems existing now usually carry over to the “optimized” solution, and so nothing much is ultimately achieved beyond leaving a lot of investment dollars on the table. Kaizen’s focus is on improvement – which means asking middle managers to improve the current situation rather than optimize it. This might sound like semantics, but it has a disproportionate impact on the nature of countermeasures sought, and their concrete implementation.
  4. Teamwork: most middle-managers need the most help is in developing relationships with other managers to carry their projects through. In your A3 training program, make sure this is explicitly addressed: A3 owners are asked to identify upfront who else they need to work on the A3 with. They need to be supported in creating individual relationships that improve their ability to work with others in the organization. This can be one of your largest contributions to the organization as a whole. A great place to start for this is the Job Relations training in TWI (
  5. Respect: in the end, respect is precisely what A3 training should address. “Respect” at work is usually understand as giving clear goals, holding employees accountable, treating people fairly, being polite and respectful and so on. All very good, but a far cry from the lean notion of respect. Lean respect is about asking people what problems they encounter in the way they do their job, what they believe the causes are, what should be done about it, how they would know if the problem is solved and so on. This is not about fixing things per se. This is about building mutual trust by better understanding what people see in their jobs and taking responsibility to work with them to make things better. Respect is precisely what A3 training should teach middle-managers, and what will make such a difference to the business as a whole.

As a trainer, the challenge often is to turn tables around and respect trainee’s contribution to the organization, before teaching them different. Successful training rests on understanding the current zone of autonomy of the person, visualizing what they should be autonomous on, and building the stepping stones to get there, to help them cross that river. Rigorous analysis is hard for middle managers because it goes against their incentive system as well as require information they don’t have access to. The question therefore is: how does your training program address their difficulties before teaching them how to solve problems with others.

Get the whole story. Read Part 1.

Why don’t middle managers practice A3 thinking?

May 28, 2013
Back to top

Dear Gemba Coach,

I’m a lean consultant, and have been hired by a large service organization to develop an A3 problem-solving training program for their middle-management. Why is it so hard to engage middle-managers in rigorous analysis? It’s not that they don’t understand the concepts or that they don’t feel it could help. They often just don’t seem to get it. How can I do my work here?

Are you solving the right problem? We need to start here, because while I don’t know what your client organization is like, it's crucial that your approach be based on how it looks from its middle manager’s point of view. What do they see if you stand in their shoes and look through their eyes?

Middle managers struggle with a unique set of roadblocks to productive problem-solving and kaizen. Many of the middle managers I’ve worked with were once excellent front-line managers. And now they no longer manage teams, they manage teams of teams. Once they could simply direct someone to do this or that. Now that they have to go through one or several managers and team leaders it’s not so simple. Additionally, they have to implement strategies they haven’t created or defined, often for unknown reasons. To make matters worse, these middle managers are held accountable to report and in fact control performance numbers, regardless of whether they have any real influence on them or not. Not a comfortable place to be.

Let’s try to view this problem more directly from the Gemba of the middle manager. I’ve observed three key areas that touch upon the A3 gap:  

Reporting: The first survival skill is understanding and nurturing the reporting systems. Nobody wants a senior executive to suddenly asks for a figure they don’t know—especially when that number isn’t a crucial one to their daily operations. Yet political considerations frequently place them in that position. That’s because mainstream organizations are built around their reporting system, following a (forgive my geeky metaphor) Star Trek model in which all the information flows to the control room where all the big decisions are made. This is very different from a Star Wars “Gemba” approach where you see the pilot constantly running all around the ship to figure out what’s really happening. The middle-manager is an essential part of this architecture, so Lord help him or her if she hasn’t done her reporting properly, or twisted operational arms in delivering the appropriate figures.

Project-management: The second survival skill of a middle-manager is to be able to develop allies across the board, other middle-managers, frontline managers and technical experts, to keep their projects moving.  In order to execute strategy, middle-managers are given “missions” to run, usually mid-to-large scale projects that more often than not reach beyond organizational functional borders. This requires the political acumen to develop allies who keep people working on key tasks beyond their routine roles, particularly when unexpected snags occur. Every middle-manager competes with other middle-managers for teams’ time and attention. In one smallish non-profit organizations we got all the middle managers together with the CEO (no more than six of them), they counted a total of seventy live “change” projects on top of the day-to-day work of the organization. Just counting the projects gave them pause. The middle-managers knew they were not making any headway. The CEO had no idea that he had created this situation.

Coordinating the teams they’re in charge of. Kicking the can to the next office is not a workaround for a middle-manager, it’s a survival skill to live to fight another day. In practice, this often means ensuring that whatever new rule that has been cooked up by some specialist function will be implemented. It means dealing with the ups and down of team motivation and fighting the endless turf-wars of unclear boundaries with other areas. It means deftly handling the occasional individual crises which inevitably crop up without revealing this to top management. It’s no wonder that many middle-managers feel they have put out daily fires with their arms tied behind their back.

So is it any surprise that middle managers stumble with the daily demands of clean A3 thinking and problem-solving? In a complex organization they face daily problems caused by politics, opaque reporting systems, and weak spans of control. Middle managers must manage people over whom they have no direct power, who have other more pressing responsibilities, who are naturally skeptical to new orders, and who naturally resist. I’ve seen how A3 problem-solving can help people and teams frame problems and work through them with great clarity and power. But let’s also sum up the challenges when middle managers apply this approach:

Step 1: Clarify the Problem

Consider the ultimate goal and the current situation and visualize the gap between current work and the ideal situation.

Yes, but:

I’ve been asked to implement this project or policy, I’m not sure what the ultimate goal is nor what the current condition really is.

Step 2: Break down the problem

Breakdown large problems into smaller, more concrete problems and clarify quantitatively the point of cause at the Gemba to prioritize which problem we will tackle first.

Yes, but:

I’ve been given a rollout implementation plan to apply in every department. What I need is agreement from frontline managers they will proceed with roll out, not a million reasons why they won’t.

Step 3: Target Setting

Set challenging short-term targets to get to the goal step by step.

Yes, but:

How can I build buy-in if the very first step is too challenging? I need to move carefully, and make sure others don’t find the early step too challenging, or they’ll flat out refuse.

Step 4: Root cause analysis

Thoroughly investigate the process involved in order to clarify the root cause by asking why? What is actually happening? How do you know that? Why do you think that is?

Yes, but:

Now you really want me to rile people and get their hackles up! Besides, I know the root cause, I’ve always said that so-and-so has been the problem from the start. But I can’t start grilling people like that and question their professionalism. I’ll lose them completely.

Step 5: Develop countermeasures

Draw up alternative countermeasures that address the root cause (as many as you can), and evaluate which is the most likely to succeed on a variety of factors such as lead-time, quality, cost etc.

Yes, but:

What I foremost need is joint agreement to do simple things. If I start looking into different alternatives, I’ll just confuse them all, and they’ll use it as an excuse not to do anything.

 Step 6: See countermeasures through

Set up the right (visual) reporting so that every one involved can see progress and obstacles can be tackled one by one as they appear.

Yes, but:

More reporting? Don’t you think we have enough as it is? Do you realize how hard it is to change anything to the reporting system? Oh, I see, you want me to set up a parallel reporting system on the wall – is that it? Good luck with that!

Step 7: Monitor results and processes

Evaluate both the overall results as well as the processes used and share this evaluation with all involved.

Yes, but:

I’m doing this already – we are tracking the implementation of the action plan and sharing this with everyone through e-mail. We are at above 80% on most items – but you and I both know what that means about task completion. At least it keeps senior management off my back.

Step 8: Standardize successful processes

Figure out what conditions are needed to make sure the new process will stick and share the standardized process with other people and divisions.

Yes, but:

Isn’t that precisely what we’re trying to do in the first place? Why go through all the 7 steps and not do that from the start? That’s what we’re already doing.

I personally feel that training middle-managers to A3 problem solving is totally the right thing to do in order to, in David Verbles terms, “lead from the middle”  and I’ve witnessed many successes of this first hand.

But I also understand your predicament. Let’s start by reflecting more on the challenges of middle-managers. In my experience, these are smart, moderately ambitious people in difficult jobs. They perfectly understand what A3 problem should do but, by and large, fail to see how that applies to their situation, and how it would make things better for them.

Next week: 5 keys to make sure the A3 training program connects with middle managers.

Why Are There So Many Points of View About What Lean Is?

May 4, 2013
Back to top

Dear Gemba Coach,

I’ve been interested in lean for over two years now, and can’t quite understand why after 20 years there are still so many points of view, and no apparent single message under the lean banner. What are your views on this?

That’s an interesting question – I’ve been thinking it over and the answer is both simple and complicated – it’s like asking “why can’t all scientists agree once and for all?” Taiichi Ohno, the chief architect of what we call lean thinking, was explicitly based on the scientific mindset, which has profound implications. But before we get there, let me argue that all lean views do share a number of common values or, more practically, stable preferences:

  • They prefer satisfying customers rather than following the organization’s path of least resistance.
  • They prefer going to the gemba to see for themselves rather than  reading reports in an office.
  • They prefer seeking to maximize the value-adding part of any work rather than accepting that some waste is the price to pay for doing business.
  • They prefer making work flow smoothly rather than accepting accumulations caused by the optimization of local resources.
  • They prefer pulling work at customer takt time rather than pushing work according to what the central MRP decides is best to optimize machine use.
  • They prefer developing people’s autonomy by teaching them how to master standards rather than ask them to follow procedures and let them find their way by themselves
  • They prefer encouraging individual initiative through step-by-step improvement rather than seek one-time performance jumps through reorganization or modernization investments.
  • They prefer teamwork by teaching every person to solve problems with their colleagues to requiring a show of “team spirit” by “fitting in” and keeping one’s nose clean.
  • They prefer small, flexible equipment to large fast machines.
  • Etc.

My list is by no means exhaustive, and could be expressed in a different way, but I hope that it is demonstrative – these preferences are quite marked and do define the lean field to a large extent. In any work conversations, you can fit people’s positions one way or the other quite easily.

It Depends

When it comes down to specifics, however, I agree, the answer you’ll get from any experienced lean person is most likely “it depends.” Because it does depend. For instance, I was yesterday with a Toyota supplier who was arguing with the Toyota engineers, making the case for a welding process that was cheaper and had many side-advantages, but did create a few occasional defects. The Toyota chaps were adamant that they wanted another welding process that they knew made no defects, but was more expensive and unwieldy. On the one hand, they pushed for their preference for “don’t accept defectives, don’t make defectives, don’t pass on defectives,” and on the other they had to face the practicalities of the situation – I still don’t know how this will play out.

On the other side, I remember another supplier that had put his injection presses in strict flow with assembly, using the press below 50% of its capacity. The Toyota engineers made him change his mind and told him to pull instead, going against the preference for flow – there’s a limit to how much optimization you lose in the name of perfect flow. These two examples highlight that in most practical situations lean thinking really depends of personal evaluations of the situation, and so you’ll get different answers from different people (sometimes different answer from the same person at different times).

Lean thinking is not a religious dogma, it’s scientific thinking applied to business problems, which is why it’s OK in lean that different people have different opinions. Scientific thinking is counter-intuitive. One never learns something new – that works for reading newspapers and chatting with colleagues and friends. Instead, one refine’s one understanding of the world by testing hypotheses and learning to know when they apply, by how much.

As opposed to philosophy, there is no true or false in science – there is likely and unlikely (admittedly, there can be very likely – mostly proven - and very unlikely – mostly disproved). There are no universals but only specific conditions. Similarly, lean thinking’s path to truth is not through learning universal absolutes, but, as Taiichi Ohno framed it, by getting rid of our misconceptions. Most of what we believe is neither right or wrong, it’s right in certain contexts, and wrong in others, and learning is about discovering which is which experimentally. 

Scientific method

Lean thinking

Observe a phenomenon

Plan: Go to the real place, look carefully, measure how a process performs against known standards

Develop a hypothesis to explain this phenomenon

Plan: Apply lean principles, use lean tools, to list the potential factors generating the gap to standard

Formulate a prediction for that hypothesis

Plan: Confirm these factors one-by-one until you can narrow it down to the most likely cause

Test the prediction

Do: implement a countermeasure to the likely cause and

Check: study the countermeasure, measure the effects

Refine the hypothesis

Act: Draw conclusions and refine your understanding of the process

In both approaches, the key is to actively seek where the hypothesis doesn’t fit the facts so well and progressively refine its formulation and the understanding of its conditions (as opposed to try to prove generalities). What makes it work is the commitment to study countermeasure to see how well they work in real life and so to accelerate learning. It’s a tough commitment, and requires real self-discipline. In particular the discipline to realize the first intuitive answer that comes to mind is interesting, but most likely wrong, and it needs to be refined through the PDCA process before becoming meaningful. This discipline essentially distinguishes true lean thinkers from wannabes.

Consequently, every Lean Thinker will have a different response to any given situation. The PDCA process, as with the scientific process, ensures that, through progressive re-statement of hypotheses, people will converge towards areas of confirmed agreement (more likely towards areas of agreement and areas of disagreement, which also mirrors the scientific process). It’s a collective process, just as much as it’s an individual mental effort to commit to it. Over time, you will find topics where there is agreement on a single message (one-piece-flow is about 20% more productive than batching), through repeated experiments by many people, and other subjects where every person holds their own weird notion – that’s OK, it’s precisely how lean thinking is supposed to work. The aim is to develop your deeper thinking, not fill you in with preset conclusions.

Countermeasure to Modern Management

How do we know it works? In companies I know, lean CEOs, like anyone else, work well with some of their directors, and not others. Typically, there will be one or two concrete-head directors who will refuse the gemba visits from the CEO (one way or other) and will not accept the scientific logic of making hypotheses (causes) explicit, or testing them (countermeasures), but will continue to decide according to reasoning they alone know.

Why aren’t CEOs doing something about it? Well, again, lean is not a religion and you don’t burn people for being heretics – you just try to convince them (until both sides feel that enough is enough, that is). Knowing what is what is often difficult in business, but with an extensive approach to go and see it becomes much clearer: most problems in the company are now opened to the eye, with a few areas of opacity. We can therefore see the size of the mistakes originating from these areas.

I have two specific cases in mind. One, the cost of a commercial director selling projects with high revenue but negative (in one case, very negative) margins. Another, the case of the IT director pushing solutions no one really wants. In both cases, we can actually put a $ value on those avoidable errors – and it ranges in the millions. So the gap to budget is clearly visible because now we understand why in parts of the company where the directors subscribe to lean thinking, and can contrast it with the remaining black holes.

What makes lean unique is that it is the only full-fledged alternative to the “modern management” invented by Alfred Sloan in the previous century. Lean is a full business system with:

  • A lean theory of strategy: choosing the customers one wants to pursue, accelerate the delivery flow and improve value, sell at market price, and make your margin by better managing costs.
  • A lean HR theory: customer satisfaction is the key to growth; employee satisfaction is the key to customer satisfaction; fulfilling jobs is the key to employee satisfaction; developing engagement (through kaizen), involvement (through teamwork) and autonomy (through standards) is the key to employee satisfaction.
  • A lean organizational theory: structure functions around knowledge production and pull value through value stream with a pull system; the management line solves its own problems and improves its own processes.
  • A lean financial theory: sales growth is a function of built-in-quality; cash growth is a function of reducing lead-time; profitability growth is a function of eliminating waste; capex utilization is a function of better understanding flexibility, autonomation, and technical minimum solutions.
  • A lean supply chain theory: integrate suppliers by pulling parts and innovations in win-win long-term relationships
  • A lean leadership theory: develop more leaders by teaching them to put customers first, go and see, ask “why?” and show respect.
  •  A lean managerial theory: visualize activities; formulate problems; seek root cause; study countermeasures.
  • And so on…

But this entire paradigm is one in which the ultimate aim is not getting you to apply lean rules, but to get you to deliberately practice PDCA in order to deepen your own understanding of your job, business and industry.

Lean is a big tent, to borrow John Shook’s image, and so it should be. To answer directly your question, everyone in lean has their own perspective on lean because they are expressly encouraged to do so: formulating your own hypotheses is par for the course. The clincher is whether you relate your own ideas of lean to those expressed by those who have come before, in order to seek a deeper understanding of lean, or whether you fixate on your personal understanding and dismiss everyone else’s.

Each Lean Thinker is supposed to have his or her own take on lean. But each Lean Thinker is also supposed to constantly amend their views on the basis of the deep lean tradition as well as new evidence. Learning is a collaborative activity between teacher and student. In any paradigm based on learning, the teacher has the responsibility to teach, but the student must take the responsibility to learn. As the old joke goes, how many lean senseis does it take to change a light bulb? The answer is just one, but the light bulb has to really want to change.

Why Does Our Recognition Program Just Feel So Bad?

April 25, 2013
Back to top

Dear Gemba Coach

My company has put an employee of the month program and other related efforts to reward good behavior. So why does it feel so bad?

First of all, sorry to hear the recognition program doesn’t feel good. I don’t know what the specifics of your case are, but this is not uncommon. I remember visiting a company that the CEO claimed to be completely value-driven. They talked about servant leadership and all that jazz, their company values were stenciled on the walls. And yet the atmosphere felt awful. No one would look you in the eye, everywhere you looked were grim faces, and when you talked to people, they would gripe about every problem as someone else’s fault.

I probably caught them on a bad day, but, indeed, human motivation and satisfaction at work is a topic where, as Chris Argyris pointed out long ago, the gap between espoused theory (what people say they believe in) and theory in use (what people actually do) can be large and consequential. The best intentions from management can easily have the opposite social effects. Unintended consequences are often a huge factor in this equation, which is why the first part of respecting people as human beings is to accept that to a large degree human beings are complex, often contradictory. Anything that you try to encourage people to subscribe will be affected by this dynamic.

Recognize The Problems with Recognition

Let’s return to lean basics. The starting point with recognition programs, as always, is: what problem are you trying to solve? Any manager worth his salt has a hunch that businesses or organizations are only as strong as the morale of those who work within them. Morale has to do with people’s ability to stick to their goals or with those of their organization, particularly in the face of opposition or hardship. Morale enables employees to give their best to the task at hand and has to do with such intangibles as enthusiasm, confidence or loyalty. Morale is not the same as motivation. Motivation is an individual drive to behave in a certain way, whereas morale has a collective dimension, such as esprit de corps. In this sense, employee-recognition programs are on the shortlist of classic morale-boosting measures. They’re meant to kill two birds with one stone by motivating employees through visible recognition – giving them something to strive for – as well as increasing the sense of belonging and fellowship within the company.

That’s the theory anyway. Unfortunately, like many measures directed at affecting people’s state of mind, it can easily turn into management wishful thinking. The lean take on such programs would be to start from the operator’s perspective: how does a worker look at any such effort? What would be our test method? Think of yourself faced with any proposed reward system. To buy into it you need to figure out:

  1. Eligibility: am I up for it? You need to believe you are eligible for this reward, that it indeed concerns you.
  2. Confidence: am I up to it? You also need to feel confident that what you’re asked to do is the right thing to do and that you’re confident you can do it.
  3. Trust: am I likely to be rewarded? If you do perform, you need to be confident that there will be a reward and that you are likely to get it.
  4. Satisfaction: should I care? Finally, you need to be convinced that the reward will actually make a difference to you, that you will be satisfied by it enough to care.

As you can see, it’s very easy to construe the program in radically different ways:


Buy in

Opt out


It’s easy to participate – I see what they’re looking for and I clearly fit the bill

This stuff ain’t for me, it’s reserved for the managers’ pets.


That’s what I need to do. Good idea. Sure I can.

Why would I want to do that in the first place? I could never do that.


Even if I don’t get the reward this time, I will next. Joe was rewarded, and for good reason – now I know what to do better.

Even if I did what they wanted, I would never get the reward – I know what they’re like.


Look at that, it’s really nice. Cool!

Look at that, it’s pitiful. Who do they take me for?


Compounding the difficulty, a recognition program is typically more a pat on the back than a hard cash reward . For it to work, the person giving the pat on the back must be respected by the employee. All in all, recognition programs aim to engage staff in certain behaviors, by recognizing their efforts publicly and by reinforcing the feeling of being part of a team. The risk is that they disengage people by coming across as a management raindance to reward brownnosers for playing the game well in pretending to do whatever absurd management thing top dogs have demanded as a sign of loyalty.

Many Losers

There’s no secret trick for addressing morale. Lean thinking explicitly considers that employee satisfaction is the key to customer satisfaction. The lean approach to employee satisfaction is to provide employees fulfilling work, secure working conditions and fair treatment. A large part of this comes down to managers creating the right workplace conditions. Employee’s part is to:

  1. Follow safety rules
  2. Master standardized work
  3. Call out abnormalities
  4. Be involved in kaizen efforts
  5. Make suggestions

From that point of view, holding recognition events and awards makes a lot of sense, but something as vague as “employee of the month” feels abstract—that the criteria for this is a challenge to define it in a way that aligns with desired actions. To fulfill the eligibility, confidence, trust, and satisfaction criteria, the more specific the award the better. You must also make sure that evaluation is against hard targets, not soft appreciation. Any hint of favoritism or exclusion will simply backfire and turn your award system into what you seem to describe (for instance, “employee of the month” is hard to quantify against a specific goal.)

Awards are always tricky: on the one hand they’re an excellent way to reinforce the direction you wish to go by placing role models on a podium, on the other, every award creates a single winner and many losers. If you have any recognition award system in place, make sure you fit it within a PDCA structure that checks how you’re doing against your goals in creating the awards. After each recognition event, find a way to estimate whether you’ve affected:

  1. Task significance: do people (beyond the person receiving the award) consider the activity rewarded more significant to themselves and the company, equally significant or less significant?
  2. Empowerment: do people feel empowered by the event? Do they feel that they have the autonomy to make a difference? Or do they feel disenfranchised and victims of a stifling and unfair system?
  3. Mutual trust: do people feel they belong to a common tribe, with a common destiny and trust in capable leaders? Or do they feel they are in a me-against-them zero sum game and that the only way to move forward is to look out for number one and/or curry favor with management?

At the end of the day any award system or recognition event is a celebration of belonging to the same company and sharing a commonality of fate – which is a large part of morale, over and beyond individual motivation. As such, people will interpret the award system according to their prior feelings towards the company: do they respect the management giving the award? Do they enjoy working with their colleagues? Do they feel they’re treated fairly by the company as a whole? Does the company represent a larger project they want to be part of?

The answers to such questions make a large difference to how the award system is perceived by whom it means to recognize. To paraphrase a retired general:  if leaders are competent and troops are confident then morale is good – and the award program should work as planned. If not, beware of setting up any such system.

Operator morale has suffered terribly since we implemented cell manufacturing, and the ideas that kaizens generate have been weak. Would you please share your insights on this situation?

April 18, 2013
Back to top

Dear Gemba Coach,

I am a manufacturing engineer at a company in the process of lean transformation. We started by introducing single piece flow cell manufacturing at our shop levels which has had mixed results. On the positive side, we reduced our manufacturing lead times by more than half. This has increased our rate of quality rejections, however, and our top management is not convinced that we should keep on with this. To address the quality issues, we have introduced kaizen events. But operator morale has suffered terribly since we implemented cell manufacturing, and the ideas that kaizens generate have been weak. Would you please share your insights on this situation?

In order to answer let me take a step back. One of the key insights my father learned as a Toyota supplier was that he was looking at a full system, not a point-by-point improvement method. This wasn’t easy to see at first. The improvements that the Toyota engineers worked on the pilot line with my dad’s manufacturing engineers seemed point by point. They never explained much beyond “we solve problems as and when they appear.” At the time, the name of the game was definitely lead-time reduction (ah, that lake-and-the-rocks graph!) and the goal was to achieve one-piece-flow as soon as possible.

It took a great deal of time, and help from his Toyota sensei for my father to understand how everything fit together: as he reduced lead-time, many other problems were revealed: quality first, certainly, then component supply issues, machine stability and operator morale. In a way, what you’re describing is not surprising, and that truly is good news. The hard part is that in order to crack this you need to start thinking of lean as a system, as Freddy and I tried to describe in our novels The Gold Mine and The Lean Manager.

I believe that it’s likely your quality issues, operator morale and disappointing suggestions are all facets of the same issue: not thinking of operators first. Look at it this way: what is the most de-motivating for an operator? Operators come to work to make good parts and stay out of trouble. They hate being blamed for problems they feel are not their fault. This is a real concern. We don’t want them to be unhappy at work. The key to our customers’ satisfaction is in fact our employee’s satisfaction.

Your company’s lean transformation efforts have in all likelihood caused—or revealed—existing problems. When you made the changes to get to one piece flow, you probably took away each person’s personal safety stock of a few parts. This made all the problems each operator faces all day long visible. It shone a light on the quality problems by preventing workarounds; operators can no longer just bin the part and take the next one from the heap. Because of one piece flow, there is no heap. As a result, if you haven’t been extra careful about supporting operators through the change, chances are you’ve put them in a rough spot. And if their supervisor doesn’t get it, she can put pressure on operators without realizing it, just by reacting to the sheer number of issues that come up.

One Piece Flow Discipline

Twenty years after these early “model” lines, we have now accepted the truth that kaizen can’t happen without standards. This is particularly true for operators who need to be able to move confidently from one task to the next in order to feel they’ve had a successful day. This means that they need to be confident in their ability to distinguish OK work from not-OK work in order to feel sure they’ll not be caught out. This works only when supervisors allow (require) operators to signal problems as they crop up – the basis of the “jidoka” pillar, the twin brother of just-in-time in the lean system.

In many companies I know, there are no limits to the number of ideas about how to make parts—the problem is that few of these take into account how to do so in a way that makes much sense for operators.

To keep the overall system healthy, you need to launch an on-the-job development program in parallel with your lead-time improvement effort. This work will enable operators to capture the standards required to hold to the discipline of one piece flow. This is never simple to start from scratch, but the simplest way I’ve found is to ask the supervisor to set aside 20 minutes for operator training each day. We put up a large plan on the wall, where all operators can see their “training” day in the next couple of weeks. The supervisor has to be helped with understanding the one-to-one approach of one day, one person, next day, next person.

These training sessions will happen on the person’s own work station, during work at first – we will create a special environment to train critical tasks later. But on normal work, the first priority is to clarify:

  1. Job targets in terms of quality and quantity, highlighting in particular customer expectations for the part.
  2. The breakdown of the job in work elements, and their proper sequence – each work element should correspond to one OK vs. NOK decision. Two decisions means the element is too long, no decision means you’ve gone too far in breaking down the process.
  3. The necessary conditions to do the job right (cleanliness of the workspace, calibration of tools and gauges, correct information and data to do the job right, etc.). In particular the means to check whether components are OK or not.
  4. Clear judgment criteria. In fact, the whole aim of the 20 minutes is for the supervisor to clarify with the worker the judgment criteria on each job element. Work element completion should fit with the overall task targets as well as show “one element, one decision.”
  5. The supervisor’s job is then to document the upshot of the conversations she’ll be having with each operator and to learn to create the most intuitive “standards” sheets, as well as make them live as discussions progress with the employees.

Your job is to monitor the implementation of this on-the-job training program and keep in mind that any change in the work environment is likely to affect one or several work elements. Your task then is to develop and progressively enrich your own checklist to make sure the training occurs as it should. And, in particular, that judgment criteria are constantly refined. This is essential for manufacturing engineering because you and your team will start discovering practical manufacturing issues you’d never have dreamt up in a million years. In helping operators be more comfortable with their work, you’ll be learning many things about your own work.

Quality Suggestions

Furthermore, as “training” sessions continue and operators – particularly the experienced ones – start understanding what, exactly, you’re after and how the process really works, with its real-life constraints and problems, you’ll see that the quality of suggestions will improve dramatically. To understand the operator’s world you need to step back from the machine and see that their expertise field is movement – foot movement, hand movement, eye movement. As you study this with them, you will start radically rethinking equipment to sustain lead-time and productivity gains. The three elements of lead-time reduction, quality-improvement and standardization work hand in hand.

To conclude, your kaizen program (which is mostly, I assume, a workshop based program and, as such, collective) needs to be complemented with an individual development program. And to be honest, both of them need to be sustained by a gemba “go and see” program where senior management visits the lines to see progress, hear difficulties and learn about work’s real value-adding or non value adding conditions (which would also help with your management involvement issues). To a large extent, I could summarize the lean programs we set up in companies as:

  • A “go and see” gemba visit program for senior management
  • A “dojo” style one-to-one training program for operators supported by the management line
  • A kaizen workshop program to crack lead-time issues (such as flow and layout, SMED), deep quality issues (quality in-depth analysis) or equipment stability issues (TPM)

With a pull system threading these three programs together, you can move from point kaizen to implement a full lean system in your shop.

Don’t feel too bad – this is a common mishap. If there is one thing to learn from your adventure, it is to keep in mind the wisdom of the lean tradition: motion kaizen first, then equipment kaizen and finally process kaizen. Our re-engineering habits tends to move machines around for quick gains first, but the true lean breakthrough is to put customers first by first focusing on the operators’ perspective and mission in any changes you’re considering. Great people make great parts – as well as processes.


Part2: What is the best lean way to understand VALUE (in terms of what our customers want)?

April 2, 2013
Back to top

To take up where we left off last week, let’s say that understanding value is about obsessively (and perfectly) formulating the correct customer preferences at two levels:

  • At company (or brand) level: what generic preferences should all our products reflect? A construction company, for instance, can decide that all its buildings – regardless of the customer’s architect’s requirement – will include a special effort to lower energy consumption. How could you write the sentence “Toyota = peace of mind” for your own activity?
  • At product level: each specific product needs a preference identity that corresponds to its target market. Think Lexus, which combines the drive of a Mercedes with the comfort of a Cadillac; or iQ, which is the size of a Smart with the feel of a sedan; or Prius, that seamlessly blends the consumption/pollution of an electric car with the autonomy of any normal car.

This may look easy to do, but is an illusion born of hindsight. When you are in the thick of product development, you are overwhelmed with information and glutted with opinions about what customers really want. Understanding customer value means being able to formulate customer preference statements clearly (out of all the things customers could prefer) in order to align the company’s efforts on these choices. Because these gambles have such a huge impact, your understanding of these customer preferences should be constantly challenged and refined.

But don’t change tacks too quickly. Steve Jobs, for instance, was obsessed with calligraphy, and his taste for texture was a key part of apple’s products (whether this was an identified customer preference or a bee in the genius’ bonnet, I can’t tell). The moment he left for the journey of all journeys, his successors claimed he’d gone too far and that customers wanted simpler graphics à la Microsoft. As an Apple lifetime user, I find this talk scary. Conversely, when Larry Page took the CEO job at Google, he focused on good-looking apps rather than the existing goal of rapid evolution—a choice that has succeeded (so far).

How then, in the fog of war, can you figure out what these key preferences are and how they play off in specific aspects of every product? The answer is genchi genbutsu and product takt. As Jim Collins has pointed out with his “hedgehog” strategy, business leaders tend to be selected for their staying power and persistence on clear strategies. This is great when it works, but think of all the great leaders who have driven their firms into the ground by hanging on too tightly to the wrong ideas. Where, then, should we look for confirming our ideas about customer preferences?

  • Marketing and related activities : the first place to look would be with surveys and competitor analysis to get a feel for how the entire market is moving. This is a very poor guide to actually select preferences, particularly at product level, since this information will make you a follower, not a leader. It is still however an essential part of reading the market: what is the market’s current base line and fashionable obsession?
  • Genchi Genbutsu: visit customers, investigate every customer complaint, and figure out how customers really use your product as opposed to what you think they do with it. As I writer, I’d like to think my customers actually read my books, but more often than not, they purchase the book for their subordinates to read – and these stack them on the pile of “to do when I have the time.” What does this tell me about how I should write books? Or, more to the point about what makes books sell? There’s nothing wrong with a hedgehog notion about what customers prefer (say, durability), but you also need a fox’s strategy of looking at many, many specific instances to understand what durability really means, how it plays out, and what competing preferences your customers have.
  • A takt of products: as Eric Ries points out in the lean startup, the only sure way to test customer preferences is to split a test group and test product variances. This is possible with websites, but much harder to do with actual products. So, accepting that whatever Marketing says has to be taken with a huge pinch of salt, you need to rethink your products in terms of a product stream, not a single product. The product streams implies that you release a product at a regular rhythm (or takt) and watch very carefully what gambles you’re taking with each product, and what the product’s sales curve tell you about what customers really prefer. This is a radically different approach to product release from the traditional “lets put any sexy gizmo in the new product and hope people will buy it.”

In exploring customer preferences, what should we look at? In March 2011, Toyota announced “we want Toyota to be a company that customers choose and brings a smile to every customer who chooses it.” How do we look for that? In his brilliant exploration of the aesthetics of green design, architect Lance Hosey (The Shape of Green) highlights three elements in liking a product:

  1. Attractiveness: how does your product trigger a “wow, I want it” reaction in your target customers. This is not just about B2C – I’ve seen many investment decisions taken simply on the basis of “I want it” (new IT system anyone? Large German machine?) by someone senior enough. So, clear your mind, and look at how customers react to your product at first sight: what is there to want that would make them smile?
  2. Relationship: do you remember that jacket you finally had to throw away (no wait, put back in the closet in case of…) because you’d worn it so much it has become part of you? Some products grow on you as you use them. They develop a relationship with their user that most other products don’t. As users, in most cases, we tend to rent an object to do a task (in Clayton Christensen’s terms). But with some products, this is not simply the case, as we develop an irrational feeling towards the product (some, on the other hand we have to use and we hate). So watch out for it: do customers learn to love or products, or do they remain indifferent?
  3. Effectiveness: does the product actually do the job – and how durably? Just yesterday evening I was battling with the new-fangled corkscrew which doesn’t fit in the hand, doesn’t go straight in the cork, and broke the cork half-way out. I then had to rummage around all drawers to find the old basic one that did the job. Watch how customers use your product, and how easily it does the main job – as opposed to all the bells and whistles around it.

Finally, these qualitative preferences need to be expressed in terms of quantitative performance measures – again, not the simplest task. Ultimately, I believe that understanding value is about being able to have a feel for the performance/price ratio in the customer’s mind. But, again, absolutes don’t make much sense, and people will be comparing across a product range – or, more complicated, about alternative ways to get the same job done.

I don’t believe there’s a simple answer to your question but, yet, I am convinced that there is no more important question than that. To sum up the discussion, I’d say that the best lean way to understand customer value would be to understand that:

  1. Understanding customer value is the result of constantly fitting customer experience data points against explicit preference hypotheses.
  2. Understanding customer value is a deliberate and obsessive process
  3. Because it’s about distinguishing the signal from the noise in an area where every data point carries a value judgment and personal bias.
  4. Understanding customer value is about expressing how preferences translate into specific product performance metrics, and yet recognizing that the feel of performance is not necessary the same as the metric (the feel of silence is not necessarily the decibel count).
  5. Understanding customer value is an on-going process, not a state.

Part 1: What is the best lean way to understand VALUE (in terms of what our customers want)?

March 26, 2013
Back to top

Dear Gemba Coach

What is the best lean way to understand VALUE (in terms of what our customers want)?

VALUE is the topic I find most exciting in lean.

Find the right VALUE-for-money balance and the company prospers quickly. Get it wrong and all your other efforts simply won’t matter.

To my mind, this is the ultimate purpose of all genchi genbustu – constantly challenging our understanding of what customers VALUE, and exploring how each person in the organization interprets that and works accordingly. The extreme division of labor in companies today often creates a complete disconnection between one person’s task and the customer’s final satisfaction (imagine that you’re looking at a welding operation in a tier three supplier). And the most important challenge of a lean organization is to address this. So tackling VALUE is a big question!

Let the Seller Beware

Let’s start by recognizing that customer satisfaction is a complex issue. First of all, not every one dreams the same dreams, or wants the same thing. Secondly, the human mind works at two distinct (and connected) levels.

One level is the now, which is how you feel about the product or service right now (that irritating occasional squeaky noise that drives you crazy).  The second is hindsight: at any moment we’re evaluating prior choices in terms of how satisfied we are we our life’s journey (ok, it sometimes squeaks, but what a good deal on mileage per gallon!).

Furthermore, these assessments change over time as you change over time. Asking customers about what they like and dislike is essential, of course, but can’t be taken at face VALUE. People will generally share the first thing that comes to their mind about their now experience with the product (thus falling prey the natural bias to overemphasize the first idea that comes to mind). Unfortunately this reveals very little about the true reasons for their choices.

Absolutely Happy

People have a hard time evaluating absolute VALUE, and so instead they instinctively compare satisfaction. Think about it – are you paid fairly in absolutes? Or are you happy that you’re paid better than your peers for the job you do (or miserable that you’re paid less)? That’s why I think of VALUE in terms of preferences. Not everyone has the same preferences. Wealthy people generally prefer style and status to cost efficiency. Less fortunate people on a budget choose practicality and low cost of ownership over glamour. Your challenge is to segment markets according to stable preferences.

Mind you this is a tricky exercise. For instance, I often travel with a colleague who hates paying much for airfares. He’s always willing to suffer the indignities of low-cost airlines for a cheaper ticket. I prefer easier interactions, particularly early in the morning and late at night, and I’m willing to pay for it. We do more or less the same work, work in the same peer group, have very similar social life styles; and yet we have two entirely different stable preferences, which has a huge impact on airlines.

Getting it right or wrong on fundamental customer preferences has the largest impact on the future of your company—by far. I’ve been observing the auto industry for more than 20 years, and have seen how Toyota has clearly focused on people’s preferences for durability, fuel efficiency and resale VALUE. French automakers, by contrast, have gambled on style. U.S. automakers on power. Clearly, we know now who made the right gamble. Every additional car Toyota sold in its long trek to number one was taken from one of its competitors. They chose wisely, and they had the operational capability to deliver on these preferences.

But shouldn’t we compete on all dimensions? Ideally, yes. Toyota is now saying it must also work on design and performance, and indeed a product should compete on all preferences. But we all know that at the operational level reality exists. And in fact reality resists. Choices must be made. Who wins when you are faced with a trade-off between a more stylish line or a known robust standard for a headlight? Or any other clear choice in understanding and serving your customer’s specific preferences? Which way do you go? If you want to make things that customers simply won’t buy, the best way to get there is to be unclear about the customer preferences you’re pursuing and the way you will translate this operationally into clear offerings.

[Next week’s column on VALUE will explore how to meet this challenge.]


How do we get started with lean tools in new product development?

March 8, 2013
Back to top

Dear Gemba Coach,

My company already has a deep rooted lean culture.  However, it would seem that the next evolution would be in my department, Research & Development.  Do you have any suggestions on how to take lean tools from process improvements such as kaizen, 5S, etc. to new product development?

I believe you are absolutely correct in your intuition – I strongly believe that the full power of lean can be reached through the feedback loop between product development and production process, which means developing lean thinking both in R&D as well as manufacturing, and bringing the two together. However, as always, when looking at tools, the real question is: to what purpose?

The fundamental aim of lean, I feel, is satisfaction and growth: satisfaction of customers, satisfaction of employees, satisfaction of shareholders and society at large, and growth both of the company and the individuals within it. In that respect, I believe there are three overall aims to lean in new product development:

  • Better products – products that better hit the sweet spot in the target segment, by better satisfying customers. This, in itself is never a given because, firstly it’s very hard to correctly identify what customers are really looking at in a product –- and it is usually quite different from what they say, or from what marketing thinks. Furthermore, value is a ratio of performance to price, so finding the right balance between customer benefits and production costs is never easy. My new Prius, for instance, is incredible because of the plug-in magic, so far superior to the previous one in terms of energy performance, but I can see many cost-cutting efforts that affect my interface in the car (plastics, ergonomics, etc.). So, I now have a science-fiction car as almost fully electric, which has a better engine, but that I don’t love the way I did the previous one (and so that I won’t defend as passionately). Such trade-offs are extremely difficult to master as the product is being developed and kaizen is essential to continuously learn about customer preferences.
  • Better engineers– there is no question that better thinking leads to better products. Better engineers can also ultimately lead to fewer headcount per project as much of the fumbling disappears. Many companies, however, consider that competence can be hired or fired. A key part of applying lean tools to new product development depends on the deep assumption that developing towering expertise is a fundamental responsibility of the company – not just the person himself or herself. The question thus becomes, how do any of the lean tools develop engineers’ technical competence.
  • Better processes – obviously the development process itself matters, and the aim of lean thinking in R&D is to reduce the development lead-time. However, one should be very, very wary of tackling this aim before having cleared the previous two, as many bad blunders can be made. I have seen many “lean in engineering” efforts aimed at reducing the development process lead-time (or worse, the engineering headcount) that have ended in disaster for the company. The lean strategy to reduce lead-time is to reduce rework: zero redesign. This, obviously, is incredibly hard to do and rests on better understanding the product upfront and then better cooperation between all involved during the development process. Several lean engineering tools have been specifically designed to address this issue and help engineers better see the consequences of their design decisions both on the product (the interface with other functionalities) and on downstream partners in production and at suppliers.

If we agree on the scope of lean thinking in new product development, let’s look at the question of how to apply process improvement tools to R&D. Getting started with lean in any area other than production can be something of a struggle because it’s hard to get a clear picture beforehand of the kind of issues you will need to attack. A long tradition of lean in production and many years of various experiment (with varying degree of luck), makes it easier to get started.

For instance, 5S in production can’t hurt. It might not deliver what you expected if not linked to standardized work, but it’s as good as any place to start. Conversely 5S in engineering doesn’t make any sense, at least to start with – it will, in all likelihood, get everyone’s back up with little gain. What problem are you trying to solve? That all pencils are in their proper place? Shall we draw a line on the desk for the pencil place? Worse, once you’ve pushed 5S in engineering (and management is very good at pushing silly ideas on the working stiffs), you’ve also burned the first cartridge of change, and doing the next step will be hard, hard, hard. (This is not to say, when we grow up, that some policing of files in the IT system is not helpful, but that’s stretching the idea of 5S rather far).

A Lean Vision of Engineering

After years of trial and error, here’s how I see lean programs in unfamiliar environments. We’re looking at four components:

  1. A gemba program of “go and see”
  2. Pull flow to give an architecture to progress
  3. A dojo program of on-the-job training by the supervisor
  4. A kaizen program of workshops to get people across functions working together

The lean vision of engineering hinges around the notion of “chief engineer” – one person designs the product much like a fashion designer designs a clothes collection. The chief engineer is more than just a project manager – he or she is the main architect of the product, and the person with final say in all technical debates (In the literature, originally defined as “heavy-weight” project manager – check out Chapter 9 in Product Development Performance by Clark and Fujimoto).

In lean engineering, executive management makes two critical choices: (1) the customer segment the product aims to touch and (2) the chief engineer who will design the product and get it to the market. The chief engineer has no authority over other engineers – these continue to report to their functional bosses – but still has the responsibility for the success or failure of the product (the chief engineer is not without influence – imagine what it does to a career if the chief engineers wants you or, on the contrary, refuses to work with you). Chief engineers are tasked to translate customer preferences into technical parameters. They usually design the product’s architectures, and are also responsible for establishing both the project’s milestones and how they intend to manage these milestones.

Go See

The first task of the chief engineer is genchi gembutsu: going to the gemba to see for oneself. Genchi genbutsu in engineering means first understand customers usages and conditions of use. Customers do the weirdest things with products, mostly because they don’t particularly care for the product other than it helps them do something they want to do. In Clayton Christensen’s terms, customers rent the product to get something done. This must really be understood. Genchi Genbutsu, for instance, will let the chief engineer realize that many people who drive pick-up trucks work outside and wear gloves in the winter, so all knobs should be large enough to be handled without taking gloves off.

Genchi genbutsu is not limited to customers: chief engineers also visit plants, to see for themselves real production conditions, and suppliers, to see what innovation could be used for their product (as well as get a feel for how tested and secure such innovations are). Many trade-offs occur at the gemba in terms, for instance, of feel of materials versus cost, or astuteness of some specific solutions. The first program to set up in order to bring lean thinking to your new product development is a gemba program, where you schedule visits to customers, manufacturing sites and suppliers not to put out burning fires, but just to understand what is possible, difficult but hopeful and downright impossible in terms of design possibilities.

Pull flow in engineering is nothing else than establishing a rhythm of new products and sticking to it ruthlessly.

How do we get started with standard work?

February 27, 2013
Back to top

Dear Gemba Coach,

How do we get started with standard work? The literature seems to say there can’t be meaningful kaizen without standards, but although we have procedures for everything, they seem very far removed from “standards.”  I think I see what we need to do but the job seems daunting!

Funny you should ask that.  I’ve struggled with the same question for years. In one company I remember, we asked an unfortunate lean officer to go out there and “write standards”. He was (is) a good guy, and he read the books about what standards really look like – I highly recommend Jeff and David’s Toyota Talent – and then he went at it, writing a “work standards” document for each workstation, complete with photos and all. The poor guy kept at it for almost two years and, as a complete idiot, I kept arguing he should plod on as “it would all come in useful some time.” In the end, he came close to burnout and we never did use all his hard work – I’m still contrite and embarrassed about the whole episode (and relieved this is one of the lucky cases where the guy recovered and went on to do great work afterwards).

After this awkward episode, once burned twice shy, I kind of avoided the topic, but the inevitability of it came back all the time. My sensei kept insisting, as you mention, that there can’t be kaizen without standards. The good thing about lean (i.e., the annoying thing about lean) is that you don’t choose your learning topics, so I took a deep breath and tried to take a step back to look at the topic differently. I’ve found that, when in doubt, with lean ideas that don’t quite square, start from putting yourself in the operator’s shoes and looking through their eyes.

Eight Hours of Standardized Work

What can really ruin an operator’s day? Whether on the production floor or at any sales point, visualize the person that feels they’re doing their best to do a good job every day and then they get yelled on by a customer or blamed by their supervisor for doing bad work. This is particularly painful because it is perceived as both unfair (they try hard every day in what they feel are difficult circumstances) and destabilizing because of the nagging doubt that, indeed, they might be doing the job wrong. No amount of self justification (I’m doing what I can) or rationalization (It can’t be that bad) can compensate for the anxiety created by the fear of your boss developing a bad (wrong?) impression of you. This is really, really bad.

The other point that gave me pause was one of my senseis’ insistence that the role of the supervisor was to give eight hours of standardized work to every operator – not just work standards, but standardized work! I never could connect with that because most working environments I know, from manufacturing to service, what supervisors really do is shift people around from one station to the other and tell them what to do when, not how to do it, let alone, how to do it at takt time in the correct sequence of movements. My sensei’s points were that:

  1. A worker should only perform standardized work during his/her working day
  2. The manager should give him/her eight hours of standardized work to perform
  3. When the standardized work is finished the person should stop working
  4. Any non-standardized work should be examined and questioned:
    1. Is it necessary work?
    2. If so, should this operator be doing it?

His point was that management’s responsibility was to progressively eliminate non-standardized work from the shop floor – quite a challenge.

Another aspect of the conundrum was that in any Toyota plant across the world, the routine emphasis on on-the-job training is obvious, but here we’re back to the puzzle. Since there are work standards for everything in the Toyota environment, TWI training techniques can be applied – but what do you do when there are no standards? Back to the chicken and egg problem.

Well having failed at first tackling the standards side of the puzzle, I wondered why not start from the other side. In the very same factory where we had burned one guy at writing work standards, we asked the supervisor to train operators every day – the rule was one day, one operator, 20 minutes training. The supervisor ran about thirty guys,  so this meant he should see every person for 20 minutes every two months or so. We set up a visual plan on a white board so that every operator could see when they’d be trained, and off we went.

At first, the supervisor tried to use the detailed work standards that had been compiled, but this simply didn’t do. Either the operator was an experienced veteran and he’d scoff at the procedure that didn’t tell him anything he needed to know, or the operator was a newbie and then the elaborate documents were far too detailed to use in twenty minutes. Aaargh! After a couple of months, we decided to abandon the documents and focus on the training relationship. The supervisor would have to work pen on paper to write an A4 page (no more than an A4 – this turned out to be important) as a checklist to do the job right. In the end, this check list ended up including:

  1. List the main steps to do the work
  2. OK versus NOK descriptions at key points
  3. Safety reminders

Which looks pretty much like what a classic operations work standard sheet should look like! It turned out that during the 20 minute discussions, the supervisor checked the main sequence with the inexperienced operators and whether they understood the hard parts, and would refine the OK/NOK descriptions with the veterans. To my complete surprise (and relief), folders of standard work sheets started appearing at workstations (high-mix environment), and lots of new, technical kaizen opportunities started coming up from discussions with operators. Even more surprising, a better mastery of operation standards let to discussing standardized work: the actual movements of the operator in the cell: feet, hands, eyes.

The next thing I know, I’m working in the service operation of a company with the dispatchers that tell the maintenance technician where to drive to repair what. After visualizing the first key indicators (trips with the wrong information, customer lead-time etc.) we initiate a training program in the same format. What we discover is that contracts vary from customer to customer and it’s incredibly hard for the dispatcher to know exactly what is owed for what customer. So they start establishing standards by contract type, and now they discover they need to investigate more thoroughly with the customer on the phone before dispatching a technician. In this case, they started with existing procedures, and through the 20 minutes per day system, turned these general procedures into specific work standards.

In both cases, as is described in Toyota Talent, we discover that very few key movements make the bulk of the work (in the maintenance case, three main parts make 80% of the changes). We then set up a “dojo,” a special area where technicians come back and are trained every day, not at the special cases, but at becoming extremely good at what they do everyday – with a remainder about safety on the station. With this system, the dispatching center now has a regular, technical discussion with each technician in turn – the kaizen wheel starts again. How far can we go with this? In one engineering company, the engineering head has started a row of black folders with “checklists” that he examines in the same 20 minutes a day with the engineers he manages. These checklists range from product OK/NOK to how to use the CAD programs.

The Key to Standard Work

The answer to your question, I now believe, lies not in the standard work per se, but in tasking managers with improving operators’ confidence in their own OK/NOK judgment. More than a decade ago as I was first trying to figure out the engineering part of lean, I was repeatedly struck with Toyota veteran’s insistence that no solution should be sought to problems unless the test method for that solution was formulated first. It took me more than 10 years to see how that can be operationalized at a work level, but I’m now confident that the relationship between supervisor and worker is key to establishing standard work.

As for kaizen, well, surprisingly, in the workplaces I know now that using this approach to constantly train to standards (and the on-going evolution of standard documents as tools to support operator OK/NOK judgment), kaizen topics have changed in nature and are less process-driven and far more technically focused. As a result, kaizen is much, much richer in know-how lessons. Improvements are more people-centric, and less to do about organization, and, looking back have much wider reaching impacts on work, products and customer satisfaction.

I don’t know if this helps in your specific situation, as it can be a hard sell – it radically changes the nature of the supervisory job. In my case, I have the good fortune of working with the senior management of companies, so when they’re convinced, things usually tend to happen. In any other case, bear in mind that although such a shift in approach clearly benefits operators, it’s also a huge challenge to frontline management, and they need serious help to achieve it. On the other hand, this approach can unlock the most unlikely environments. One senior manager I know at the Post Office has started asking systematically for “dojos” in his area, and the results have been spectacular, with several thousand “dojos” up and running and stunning rises in employee satisfaction numbers. In this specific case they have formulated the purpose of their lean approach as “supporting professional gestures.” Wow.

Why haven't kanban and value-stream mapping improved delivery from a low-volume/ high-mix process?

February 21, 2013
Back to top

Dear Gemba Coach,

We work with an industrial process that is mostly low volume/ high mix, with both machining of components and assembly. We respond to customer orders, but our OTD is somewhere between 70% and 80%. We’ve invested heavily in value-stream mapping and kanban, but can’t seem to improve our delivery. Any advice?

I feel for you as I know first-hand such problems can be quite intractable and frustrating – so don’t give up! The difficulty in high-mix processes is usually not so much the flow, but spotting where pull (stock replenishment) and push (make to order) interact. In such cases, a combination of kanban and value-stream mapping should help, but there are a number of pitfalls to steer clear off.

The most obvious trap is that trying to map the value streams of all components that go into the final product is like digging a hole in the sand: the more you dig, the more you find. This is the most common mistake I’ve come across. Rather than worry about the information flow in the VSM, lean teams are often obsessed with the physical flow and start drawing every process. To their dismay, they find the complexity of the full flow increasingly daunting, and the more they map, the less they see any obvious way to improve the flow – better leave it all to the MRP to sort out.

VSM can be very useful to look at the overall process and distinguish assembly, which is usually a straight FIFO flow (as would be a conveyor in an automotive plant). All components reach the assembly start, and then value is added until finished products come off the line and go to packing. The challenge at this stage is to find consistent product family and decide whether to flow everything through one product line (lower takt time, greater productivity, but much higher complexity and difficulty to teach standard world) or to create several distinct lines (higher takt time, less productivity, but lesser need for multi-competence). In general, plants tend to start with lots of small dedicated cells, and as they master the process, create lines capable of dealing with broader ranges of products, in order to improve productivity – which requires a degree of maturity in standard work training in order to guarantee quality.

But at some point in the plant, the components are machined, and this is usually hard to establish as a straightforward pull systems as some components will be runners, and some will be strangers. This is where kanban-thinking needs to be taken into account in drawing value streams.

Runners and Strangers

Ideally, all machining cells should own their own production in dedicated “shop stocks” at the foot of the machine. An internal “small train” (a tugger with wagons of shelves on wheels) can then pick up from the machining cell and bring the components straight to assembly just in time. The shop stock is made of several lanes for high runner parts, and a lane for made to order (which is picked up every time the train passes). Runners are pretty straightforward to have in replenishment kanban (pick one, make one), but strangers need to be scheduled the old fashioned way through production instructions that go straight to the kanban cards queue.

In many cases, though, plants find hard to hold all parts at the machine, and will chose to build a central market that acts as a buffer between machining and assembly. Think of it as a kitting area, where all the components are put together as a kit, so that assembly has to, well, assemble what is brought to the line. In practice, most factories end up with a mixed system of kitted main parts and kanban-driven stock replenishment runner components. The frontier between one or the other keeps shifting according to demand mix and maturity of the plant. There is no “right answer” there, only kaizen.

At this stage, VSM is an essential tool to sketch out different possibilities of shop stock vs market and how to deal with getting the right information at the right time and the right place. An easy error to make is to focus on the physical flow (and production performance) aspect of the value-stream map and sketch out roughly the information flows as dotted line from “logistics” to the cell. In fact, sorting out information flows is where the VSM is probably the most useful. To do so, lean thinkers must go in much greater detail than they often do:

  • How does information arrive from the customer?
  • How is it treated at logistics: splitting by stream, leveling by fractioning and mixing, what information goes to which process?
  • How often is the information transmitted to the process – once a week, once a day, once an hour, real-time?
  • Where do logistics customer instructions turn into production instructions (in many places, the reference numbers are different)?
  • How does the train (or forklift) driver know what to pick up where and at what time?
  • What is the picking frequency? How regular is the train?
  • How many containers are handled at each transport?

Calculating Stock

Where kanban is used is particularly important because kanban cards are picked up and moved by the logistics train. The regularity and frequency of the trains is critical to the flow of information, for instance, and this really needs to be mapped in great detail to figure it out – and know how to improve.

The key thing to keep in mind is that the more sluggish the information flow, the more parts are needed in inventory, and vice versa. If the train only comes every couple of hours, the cell can’t change its mind about what it builds within two hours. If the train comes with new kanban cards every half-hour, the demand can be adjusted every half- hour. Now, on the other hand if demand can be adjusted every half-hour, but slow tool changes at machining impose several hours long batches, no matter what happens on the demand the cell will continue to produce parts, whether they’re needed or not. The problem, of course, is that production of A is non-production of B, C, etc. so making too many of A means having a dearth of B (or keeping them in stock).

At the market, typically, the amount of stock is dictated by:

  • A cycle stock of average daily demand x lead-time to replenish
  • A buffer stock to cover demand variation as a % of cycle stock
  • A safety factor as a % of cycle stock + buffer stock.


 Figure: Lead Time Indicators

There are many smart ways to calculate these various stocks, but I find that, in practice, operators learn quickly to guesstimate what should be kept in stock – the major blocking factor remains tool change time in every machining plant I’ve come across.

The second thing to keep in mind is that true strangers need to be run in an MRP-like system with safety stocks set at 0. If they are real strangers, they do come one at a time, and the plant has to learn to produce the stranger components one at a time as well. Another option, of course would be to hold one item of all the stranger parts in stock – and to replenish it as soon as it’s consumed. This is a pretty smart way to go about it, but represents an inventory investment few plants are ready to do – particularly if you’re part of a larger group. Corporate simply won’t have it.

My point is not to go to lecture about the correct use of kanban to pull, but to point out that the most likely reason you’re floundering with Value Stream Mapping is due to too much focus on the material flow (and its performance – you know those boxes full of numbers) and not enough detail in the information flow. This, however, is where the real strength of the tool lies. Back in the day, with injection presses, I remember detailing the information flow in agonizing detail: hours of fun!


Figure: Current Operating Status

At the risk of being monotonous, my advice would be the same as ever: identify the skill you need to learn to make the tool work, and, well, work at it until it does. Tools like value-stream mapping have been time-tested in many varied settings, so if it’s not delivering the right results, don’t fight the tool – the problem lies with how you use it. In my experience, the main difficulty with the VSM tool is to become expert at capturing the information flow (which is often complex, perverse and hidden in various IT systems). Here’s a fun test: if you can’t read what 1-4-3 means in the above graph, you’re probably going to have to hone your information analysis skills some more!

My CEO has asked me to take a hard look at the lean program at our hospital – where should I start?

February 11, 2013
Back to top

Dear Gemba Coach,

I am ops director of a large hospital. We have been doing lean for several years now, with a lean office of ten people involved in many projects in improving 5S, finding beds, test circuits, and so on, but lean doesn’t seem to “take”, and our financial situation is not improving. My CEO has asked me to take a hard look at the lean program – where should I start?

I’d suggest to start by reading again John Toussaint and Roger Gerard’s book On the Mend; I’m not being flippant, they’ve come up with one of the best definitions of lean I’ve seen so far:

  • Focus on patients (not the hospital or staff) and design care around them.
  • Identify value for the patient and get rid of everything else (waste).
  • Minimize time to treatment and through its course.

And ask yourselves: are we following these three points?

Hospitals have their own specific context and they’re as far removed from an automotive assembly line as can be, so we need to be a little cautious in “applying” lean to the hospital context:

  • First, the hospital’s “product” are suffering human beings – patients are moved around, manhandled, made to wait, and so on. The product is the customer. This is difficult because patients don’t see any value in all that’s happening to them. They just want to be fixed and get on with their lives. Instead they have to sit for hours, sleep in emergency ward corridors, have needles put into them, go through scary looking machinery and generally be treated like an inanimate object. Also, the magic ingredient in healthcare is confidence. According to this Wired article ( the placebo effect is getting stronger! So, in terms of value, everything that you do in the ward that increases patient confidence is care, and everything you do (grotty looking emergency entrances, stroppy nurses, insensitive doctors, etc.) that undermines patient confidence is value destruction.
  • Second, the hospital is a very complex place where a huge number of people have to come together to treat a patient – up to 18 or 20. Each of these specialties have different constraints, different traditions and different organizations, that have to come together somehow.
  • Thirdly, hospitals I see are increasing victims of the spirit of the times in terms of financial pressure, and increasingly run by financiers who don’t understand the true nature of their costs: not replacing nurses when they’re ill is NOT going to keep costs down, but add overburden, which will lead to more mistakes and further costs. I know several hospitals that no longer have the budget to properly staff their wards, which generates both bad patient outcomes and a lot of staff resentment, but can find the financing to invest in new buildings, IS system migrations or even consultants to rationalize processes!

Facing Patient Issues

On the other hand, most people who choose to work in a hospital are determined to do good and help patients – that’s why they’re there. More often than not, they’re angry and frustrated because the complexity, the rules, and the bizarre behaviors of people stop them from doing so. Consequently, lean thinking applies very well in the hospital context, if we allow for a few specific learning difficulties.

  1. A reluctance to face patient issues: more often than not, both doctors and nurses will be in strong denial about the reality of patient care. Faced with the practical difficulties of getting things done, humans being humans, hospital staff will often (1) refuse to measure patient incidents and (2) start negotiating basic rules such as separating clean from dirty, washing hands, not wearing jewelry etc. Chances  are everyone will agree on the need for kaizen on supporting processes, but not on patient front-line issues. However, fixing the laundry is NOT going to help you either treat patients better (and hence increase reputation and revenue) or keep costs down (by reducing nosocomial infections, and so keeping hospitalization times down).
  2. A reluctance to share responsibility: the very complexity of hospital processes means that to improve any process, one has to get a number of professions to agree on their will to improve. A classic hospital game is to make sure nothing changes by using professional arguments to stop looking at bothersome issues; typically doctors will refuse to look at logistic problems, to self-measure their own outcomes, nurses will get all emotional and on their high horses at the slightest hint of criticism, logistics will explain that everything costs more and nothing can be done, etc. This is a true leadership test, both because of the number of specialties involved and because of the very set professional cultures of each of these specialties, and it takes some doing to overcome.
  3. A bias for talking rather than doing: this might be very personal, but my experience with hospital workers is that they’re always happy to discuss things, as long as no immediate action is required. Meeting are endless and repeated, e-mails are long, detailed and cc-ed widely. The amount of coaxing needed to get anyone to actually do anything is an order of magnitude higher than any other environment I know, which slows down learning considerably as they often consider that talking is learning. Hmm.

As a consequence, most lean programs in hospital actually solve some issues, such as more reliable returns of lab tests, greater productivity in sterilization, and all sorts of logistics issues, but still the costs keep creeping up, patients are not better treated and every new project requires just the same amount of persuasiveness to get going: it’s kind of daunting.

Where to Start

What can be done? To begin with, I’d suggest to start with kaizen in each specialty, before touching cross specialty issues. Rather than try to fix logistics problems across departments, how about attempting to develop the kaizen spirit of each department head. This requires a change of mindset from the management group:


Rationalization of processes projects across the hospital


Patient-focused PDCA by each of the department heads.

It’s not that hard. I was recently visiting a mid-sized hospital, and discussing surgery management issues with the doctor in charge. He had identified overruns in time in surgery as an issue both for patients (usually because something went haywire) and for the overall cost of his unit. He realized that one or two more patient per theatre per day would have a dramatic impact on his costs. The problem, however, seemed impossible to tackle because of unavoidable variation from one patient to the next, and from one surgeon to the next. This is a typical case where stricter rules simply won’t help, and incentives will bias the system to sloppy work, so we need to be careful. On the other hand, this is a typical case where lean thinking applies naturally:

  1. Formulate the challenge: patients should be out of the operating theatre at the scheduled time – each doctor being ask to set the scheduled time, so the challenge is more about developing surgeons on being more autonomous with their own scheduling.
  2. The PDCA is about developing the leadership of the doctor in charge of surgery – NOT forcing a new “process” on surgeons.
  3. Define OK versus Non-OK to specify finish operation in time. In this instance, to start with, within ten minutes can be considered as OK to start with. Also complications are difficult to see at surgery because they will be spotted in the wards (and we’re back to the cross-functional cooperation issue), but re-intervention is fairly clear: if a patient needs to be operated on again, this counts as NOK.
  4. Visualize the schedule and measure every day the ratio of OK (on time) against NOK (more than ten minutes late) as well as counting re-operations.
  5. For each NOK situation (as appears from the visual board or screen), the head surgeon can slip in the operating theatre and practice GOOD OBSERVATION and, later, GOOD DISCUSSION, to practice genchi genbutsu and try to get a sense of what really happens at the patient.
  6. Agree a challenging NOK reduction target, such as -50% late finishes, and -50% re-interventions.
  7. Through either workshops (all people for a few days) or quality circles (a few meeting for an hour every day), start listing possible factors of late finish and get agreement on the problem. Agree on ONE action – not more.
  8. Try and measure, try and measure. Then move on to a SECOND action.
  9. Draw conclusions and change the process when relevant.

It’s essential that actions should all be within the scope of the surgery: no involving outside sectors, at least at first. On the other hand, doctors can use check-lists, better coordination, better allocation of patients, better scheduling of patients (difficult patients up front, rather than at the end of the schedule – yes, if something goes wrong it throws everything off, but at least minds are fresh and problems can be seen early), and so forth. As the exercise develops, some notion of takt time can be introduced, as well as value streams and leveling (long, short, long, short) and on and on.

Back to your question: how do we assess a lean program? One, by its overall results of course, but I’ll allow that in a hospital this can be tricky. The underlying question is how do we define OK versus NOK lean activities?

This is probably very personal, but in the context of a hospital, I fell that an OK activity is defined by department head taking on board a PDCA cycle on a patient-focused topic. In a ideal situation, every department head is currently working with their staff at conducting a PDCA cycle in their area, on patient-driven issues. I’m fully confident that if this milestone is achieved, cross-functional kaizen will happen naturally and succeed far more easily.

With this target in mind you can now look at your hospital differently: how many area managers are we looking at? How many of them are truly conducting patient-centered PDCA (and I’m not even suggesting doing it well or successfully!)? The resulting ratio is a ready-and-ready assessment of your lean program – that begs the question: how do we get from where we are to all department heads involved?

Sure, when we grow up we can have proper hoshin kanri, value stream maps, Supervisor Standards, and so on. But to start with, let’s first focus on patient care and introducing staff to the excitement of the kaizen spirit. The biggest room remains the room for improvement!

(Editor’s note: Our latest book is a how-to field guide for healthcare leaders who want to make real and sustainable improvements in healthcare delivery using a hospital-proven improvement methodology for entire value streams. Please feel free to download excerpts and templates. )


Would you have a few tips about coaching on the gemba?

January 28, 2013
Back to top

Dear Gemba Coach,

Would you have a few tips about coaching on the gemba?

Um. Yes, don’t touch any parts or machinery and don’t do anything yourself. Beyond that … coaching, in principle, is fairly simple. It can be boiled down to five questions:

  1. What are people trying to achieve?
  2. What skill(s) would best serve them to achieve their goals?
  3. How should I teach them these skills?
  4. What difficulties are they experiencing in executing the skill?
  5. What exercises can I give them to overcome these difficulties?

From what I’ve read of traditional coaching environments, in sports or in music, the game is usually set and the challenge is how to play it well. Lean coaching has the added twist that you need to define the what before the how. In my experience, this is the trickier part. Before we get into how we play the game, we need to define what the game is.

My first tip is no tip at all, really, but a reminder that people are people and they do things for other people (internal or external customers, bosses, community, taxman, etc.) with people. It sounds like a motherhood, but understanding what fires up people and drives them is personal andis key to successful coaching. The alternative is to impose goals without meaning (improve productivity, reduce inventory – uh, why?).

Lean Coaching for Executives

I begin executive coaching by asking myself the question: “what is it they’re trying to prove?” The CEOs I know are rarely in business to make money – they’ve got pretty unique and personal motivations for growing their companies, and profit is both a means to further their ambition and a way to count the score but not an end in itself. And yes, this is self-selecting as well as I’ve never been able to work with financial managers who see profit as the goal and accounts as the main tool (my experience with companies taken over by financially managed acquirers has not been good). CEOs I work with are out there to prove something, and it takes time to put one’s finger on it:

  • I will show them this new technology makes better and cheaper precision parts with lower environmental impact
  • I can have a diverse firm and make money
  • I can to radically reduce the energy consumption of a new condominium without increased cost
  • I can turnaround this business – look at how badly it’s managed
  • I can sell globally and to establish selling partnerships on every continent
  • I can build the dominant product in the industry
  • I can replace metal engine parts with plastic parts
  • I can improve cooling performance
  • I can build lineside equipment to have both productivity and protect workers from harm
  • I can create a more congenial working environment and hit profitability objectives
  • And so on…

Any of these motives, and I’ve listed them randomly thinking of the people I know firsthand, require running the company well and profitably, of course, because if you fall into survival mode there’s little chance to prove anything. But as a coach, I’ve found it essential to capture what exactly is the bee in their bonnet that gives managing its meaning.

Sometimes, the guy tells you upfront what he’s all about, and you’ve got to be able to hear it, and sometimes you have to work for years with a person before this gets clearer. In any case, one of the keys to being a successful coach is to try hard to find out what makes the person run, the source of their internal tick tock, because they’re going to do the work, not you.

The next step is then to figure out what conditions need to be created for the person to prove their point. In this, we are fortunate with lean, because the system itself gives us as great starting point. Let’s start by:

  • Focusing on customer satisfaction
  • Spot defects, stop and fix them, think deeply about why?
  • Pull work through the flow just-in-time
  • Involve workers in modifying their workplace and standardize their work

No ifs and buts, that’s lean, period and if the person you coach starts arguing with any of it, there’s no point going further. Lean is a system and, as a coach, this is your value added – so in order to help them achieve what they want, they’ve got to let you help them by doing lean. When they start playing around with these principles on the gemba, they’ll start to see, usually quite quickly, how lean thinking reveals their current situation, and how they create their own misery by doing many things that detract from their goals, every day. At this stage the coach’s problem is twofold:

  1. Link the lean principle to business results to the exec’s ambition
  2. Demonstrate how the principle applies in the current situation in order to bridge the disbelief gap

For instance, just-in-time is rather straightforward, but how does it apply to constructing a building (long projects with a multiplicity of trades)? To making precision parts for luxury watches (huge diversity, low volume, all-over-the place demand variations)? To getting patients in and out of a hospital ward? There is no other help than experience, because as a coach you absolutely need to figure out:

  • In which case you find yourself: high-volume low-variety short processes differ markedly from low-volume high-variety long processes; controlled processes differ from less controlled ones; equipment intensive operations differ from manual assembly, and so on.
  • How the problem can be framed: for instance, it took us literally years to figure out in the construction business that pull meant focusing on the relay between trades in a building: as trades do the work one after the other, but with very different speeds they tend to walk all over themselves, and pull means having each specialist pass through the apartment, in sequence at a takt. Obvious (if hard to do) with hindsight, but hard to see at first.
  • What is the context like: industries have cycles, companies have morale ups and downs, people have mood swings, and there’s always a new fire burning somewhere. When I started out, getting into an argument with a union leader whilst wage negotiations were going on was not the smartest thing I’ve done. Context should not stall work, but it does matter to the people living there, has to be acknowledged.

All Ears

To my mind, the “what” part of coaching is all about an on-going discussion at the gemba about the deeper questions the executive is addressing and how the lean principles work out in his or her specific situation. There is some teaching in it, certainly, but also a lot of listening to, progressively, create a clearer idea of what we’re trying to do and why. I’ve met many consultants who dismiss this sort of talk as too abstract, or beyond their remit, but then they find that even when they succeed at correctly implementing whatever tool they’re peddling they struggle to interest their customer in the results, or the follow-up. They’re out to prove their idea (better flow improves productivity) rather than help the client prove his or hers. Tall order.

Then comes the how part, and we all know that any skills coaching feels like two steps forward, one step back, two steps forward, one step back. We can’t just open heads, put in a new chip, and watch the robot perform differently. People have to learn how to do anything, and, from the coach’s perspective this is more akin to pottery (once more round the wheel) than to architecture (I’ve designed it, someone will build it).

The trick to teaching how to do something is to hang on to “NOT GUILTY”:  they try hard, but invisible (sometimes imaginary) impediments stop them from doing the task successfully. It’s terribly easy to confuse will problems (they’re not trying hard enough) with skill problems (they’re missing one critical element) – usually because when people fail to progress quickly, they feel deflated and it shows. Conversely, skill difficulties can be hidden by over-cheerfulness and go-get spirit. In general, emotional arguments hide specific difficulties with the job at hand – which doesn’t make it easier to keep a cool head and look beyond the tantrum to see the real problem. As a coach, the idea is to:

  1. Visualize the ideal performance with your inner eye
  2. Spot the specific difficulty the person is having (they’ll tell you – just listen)
  3. Explain that (though sometimes they won’t want to hear it)
  4. Spell out a simple exercise to practice overcoming the difficulty.

Certainly, repetition makes perfect, but repeating a mistake can be tiresome, so it’s well worth to take a step back and focus on dismantling barriers before moving on.

Again, this is about being aware of case, frame and context. The production manager might well be trying to implement pull but he’s struggling with his leveling board because he has many references in a cell but his CEO has told him to do a model line and prove the concept on one product (which means isolating one reference from others), the logistics director will not release information to establish a leveled plan, and he’s just had a new baby so he’s sleeping two hours a night. The argument at the leveling board can easily become heated because the poor guy is just out of it and he is unlikely to tell you that he’s understood what you try to teach him, but his bosses won’t let him do it.

I know it sounds twee, but to be a successful coach, as my British colleagues used to say, learn to relax and enjoy your problems. Because, to use another aphorism, the juice is worth the squeeze. The juice is watching people realize themselves in their work. The squeeze is to constantly shuttle from the larger question to the specifics of the situation, big picture, back to details, details, details. This, I find is how both the coach and the learner learn collaboratively and, as they do, change the world (okay, in small ways, but still).

As you get them to zoom into the specifics of the situation and then zoom out to the BIG questions and back, you’ll hit many setbacks both because reality exists and reality resists, and because people are people and tend to want contradictory things. As you hit trouble, take heart from another sporting experience: don’t dwell on lost points, worry about the point being played now. As a coach, your objective is not to obtain results – that’s the person you’re coaching’s role – but to keep them fighting. We humans absolutely hate losses. Hate them. But, in order to learn, we’ve got to own up to our mistakes and analyze them. So make it easy for them. Tell them not to worry about what went down, but focus on the next play and how to move one step further towards proving what they have to prove.

How is lean strategic?

January 21, 2013
Back to top

Dear Gemba Coach,

I’ve been told by my senior management that there is no strategic vision in lean and they don’t see how to integrate the lean initiative to the strategic plan. I’ve not found any reference to lean and strategy in the literature. Any advice?

Lean is a business strategy would argue Art Byrne, the CEO of Wiremold (a company that was valued at $30 million and was sold ten years later for $770 million) in his great book The Lean Turnaround.

But, yes, you’re right, there’s not much “strategy” in the markets/technologies/footprint sense of the term in lean, although much of lean thinking is strategic – but in a different way. Strategy is traditionally about defining where you want to be, devising a way to go from here to there, and then planning how to execute the change. I’d argue the same elements appear in lean thinking, but in a different way: lean strategy is a learning strategy, rather than one based on defining future states upfront. Strategy in lean is expressed as “challenges” we have to overcome.

Our current form of capitalism is based on creative destruction: owners invest in a venture, mostly in terms of equipment and structures, and keep doing so as long as the financial returns are worth it. Typically, marginal returns on investment will diminish and then the question is whether to re-invest or to move on to a new venture. Hollywood is a past master of this: when one film is a hit, movie execs will immediately invest in a sequel, and then a third installment as long as box office numbers are good. They’re going to reinvest as long as they can milk the idea. The same thinking applies in any industry, where most strategic decision-making is about cutting losses (which is counterintuitive and painful), when ROI is no longer what it should be, and moving to juicier schemes.

Where Strategy Starts

In the early days of lean, Japanese gurus such as Masaaki Imai argued right from the start that kaizen was a different strategy. The fundamental idea is to fix problems now to (1) keep ROI from existing investment and (2) learn to better define the next generation of investment. This approach is in fact strategic and takes you to very different market positions. But it’s strange, and it starts at the gemba.

How can strategy start at the gemba? I’ll illustrate with a company I know, where the CEO of a small manufacturer of machine tools for a large industry started lean some months ago and almost never got off the ground, because he stumbled on the very first step: protecting customers. On the gemba, looking at a machine that was being prepped for a large mainstream customer, he started asking whether the problems of the installed base for this machine at the customer would be solved with the new equipment. This opened a Pandora ’s Box of issues. It turned out that this customer, a major corporation, had been complaining so much about the installed equipment that the technicians in the company had started dismissing it as bad-tempered noise (they’re still buying our machines, aren’t they?). The engineers felt that the machines conformed with the contract—so what was the client making such a fuss about? Intrigued, the CEO did his genchi genbutsu at the company, and witnessed firsthand all the usage problems the customer was complaining about.

Two main kinds of concerns appeared: (1) a fundamental issue of rework from one of the high-tech elements of the machine and (2) general issues of user-friendliness to the operators using the machine every day. They still purchased the machines because they felt competitors were worse, but were very frustrated by the total lack of interest they got from any of their machine suppliers.

Over the following months, the CEO tackled three difficult changes in his own company. First, he asked his engineering teams to fundamentally change their attitudes to customer complaints, take them all seriously (by doing full A3s on each) and start thanking customers for their complaints. Second, he started a project with his key designers to rethink the integration of their machines in the flow of the customer’s operation; in doing so they started rethinking radically the direction taken by the new designs for the next generation machines. Thirdly, he realized that on the key high-tech component they had been so busy fighting fires (as well as starting a venture in India) that innovation had almost disappeared from the company’s scope. In our latest conversation, he was wondering whether his current company could actually do both and was considering creating a high-tech start-up company to focus on this key component and return to pure play innovation, which would later be plugged in to his existing products.

Now, I don’t have a crystal ball and have no idea whether he’ll succeed with any of this, but these issues are clearly strategic. Rightly or wrongly, he decided his products would be standards at large customers, which means increasing the installed based within existing corporate clients rather than selling more to smaller unknown customers: this is positioning the company on its markets. Secondly, he started formulating a new vision of future products, which has to be strategic as well. Thirdly, he refocused his thinking on key technologies and the kind of investment necessary to sustain innovation: strategy again. Finally, he’s hoping that margin gains from kaizen will generate the necessary cash to be able to implement his new strategic ideas. Early signs are promising on this front.

Two Levels of PDCA

Solving problems now, in this case, doesn’t mean fixing the issues and moving on, but rigorously applying two levels of PDCA. Firstly, PDCA at the machine issue level, in which the CEO gets personally involved in the “check” by confirming technical solutions that his engineers have put in place. Secondly, a strategic level of PDCA as the CEO is now exploring unchartered territory, he tries to formulate clear hypotheses and looking for confirmation or contradiction on the market. He is familiarizing himself with his key challenges and exploring possible solution at the gemba.

Lean strategy is a learning strategy: solve problems now to define investments for tomorrow. This is the opposite of what is usually thought of as strategy: figure out tomorrow’s future state and abandon what you do now to invest in getting there. These are two radically different ways of thinking strategically. The latter is vision driven, the former is gemba driven. And these two ways of strategic thinking do lead to very different kinds of solutions.

I realize this doesn’t quite answer your question and won’t help you much with your senior management, but thank you for asking this question, as I feel the underlying debate is a deep one we should probably have within the lean community. Strategic vision in lean is driven by gemba (at customers as well as our own shop floor) and kaizen. Maintenance and innovation kaizen are the key to explore the great challenges that confront us. It also offers the hope of a more flexible, less destructive form of capitalism where ROI is sustained by kaizen and where new investments better fit the facts of the market.

Why won’t senseis ever give a straight answer?

January 13, 2013
Back to top

Dear Gemba Coach,

Why won’t senseis ever give a straight answer?

How many lean senseis does it take to change a light bulb? One, the joke goes, but the light bulb has to really want to change.

Senseis don’t ever give straight answers because one, that would not help you develop, two, they often can’t answer the question in the terms you’ve framed it, and three, when they do give straight answers (or direct instructions to “clean the window”), you won’t like it any better. The sensei’s job is not to give straight answers, but to point to muda and ask “why?” until you start to see the muri or mura that creates the waste, or to stand you in a circle until you get the point of view of the operator.

Senseis don’t worry much about the immediate problems of production: that’s the responsibility of the person experiencing the problem. They worry instead about reinforcing the attitude of “customer first” and about developing the technical and teamwork skills of the people in front of them so that they will improve the capability of the processes they own.

It’s helpful to keep a few distinctions in mind concerning this topic. First of all, lean senseis are often Japanese (or trained by Japanese), and my understanding of Asian  tradition is that the onus for learning is on the learner. The teacher is good enough to demonstrate his or her knowledge, and the learner has to make the effort to, well, learn.

In the west, somehow the onus has shifted to the teacher, who is expected to interest students, to convince them, to keep them in the classroom and so on. It’s also important to note the difference between classroom learning and gemba study.

On the gemba, my challenge is to show: I have to find a demonstrative case in the messy reality that surrounds us, and to hold my student in front of it until they see (an extreme form of this being the infamous Ohno circle). I can’t see for them – they have to make the intuitive jump. The relationship is clear: they have to do the work until they’ve convinced me they have seen what I wanted to show them. In a classroom, on the other hand, I have to explain, and continue to explain until they feel they’ve understood or just had enough. It’s a very different teacher-student relationship.

Simplify to Amplify

One thing my father teaches is that lean progress is propelled by the two feet of improvement and involvement. Explaining more might help people make quicker progress on the improvement side. If you’re good at explaining, they’ll do whatever and we can all move on. However, this is not very engaging. Not giving the answer, on the other hand, is frustrating but very engaging. In his brilliant book Understanding Comics, Scott McCloud argues that comics are ingenious because they use amplification through simplification: they provide just enough information for you to fill in the meaning. One reason comic strips are so engaging is that from one drawing to the next, you get to fill in what happens—an action McCloud labels “closure” (and in fact breaks down into six subcategories). If the author draws an axe in one box, and a scream in the other, you get to fill in the murder – your mind can’t help it, even if it’s often unconscious: you’re involved, not by the literal representation but by the absence of it. In the same way, on the gemba, people get drawn in not by the sensei’s answers, but by the absence of them, as the mind struggles to fill in the blanks.

The second part of the problem is that intellectual “understanding” is a far cry from competence. Understanding how someone can ride a bike has little to do with the physical experience of riding the thing oneself. Again, in the western tradition of teaching, the student needs to be reassured by all the theory to finally start with the practical experiments. The Asian tradition is more the other way around: by grappling physically with the problem, you get to build the internal scaffolding that makes you reach for the Aha! moment.

One real drawback from the “intellectual understanding” approach is that we now have many people doing A3s, or setting up obeyas, or conducting kaizen with very little notion of what real problem solving is about (are we solving the right problem? Are we solving it in the right way?). Part of the problem is that having intellectually understood the tools, they can’t see they’re missing out on the activity. They can talk the talk, but don’t realize how far they are from walking the walk.

Thirdly, senseis don’t ever give straight answers mostly because the questions themselves are largely flawed: they can’t answer the questions framed in the terms they’re being asked. Imagine you’re in front of a technical process in the plant that has never been stabilized and creates a great number of defectives. You can see that they’re using the machine wrong by a number of giveaway signs, but how could you possibly know exactly what is wrong with the process? What you can tell, however, is that they are discussing the machine at such a general level they’re not very likely to find the real problem. This is not consultant BS, but actual experience of mine. So, the answer is, “set up a paper board next to the machine and write up exactly what happens every time it produces a defective.” This invariably works if done seriously because, in many cases, the machine’s technical issues are created by the conditions in which the machine is used, which the team on the gemba will discover by themselves. Although this will improve right-first-time and develop the people’s own understanding (and teamwork), this response does not answer “is it the whachamacallit or the thingasomething that is going wrong?” In your terms of your question, it’s not a straight answer. But then again, it is.

Dueling Senseis

Finally, in some cases, senseis do give straight answers, except that nobody likes that. The sensei is watching your semi-automatic assembly lines where operators work loading and unloading machines with three or four parts between stations and he says: “force one piece flow” – not three or four parts flow: zero or one. Or you’re in an injection and assembly cell that produces one to two percent scrap and the sensei says “set up a red bin and ask the supervisor to come observe conditions at every defect.” These are pretty straightforward answers, I would say, except that no one likes them or believes they have the resources to do so. In this case, the sensei is not solving your problem, he’s setting up the observation tool for you to solve the problem. But, as with the church officials who wouldn’t look in Galileo’s telescope for fear of what they might see, on the ground, they are many reasons for NOT doing what the sensei says, and so, refuse to learn.

Are senseis always right? Absolutely not. The first thing Taichii Ohno teaches us in his seminal book on workplace management, is that we’re all wrong at least half the time. You have not done real lean until you’ve witnessed “battle of the senseis”: two senseis with radically different ways of approaching a gemba problem. But we all get the sensei we deserve.

I would not worry too much about sensei’s style, every teacher has his or her own. Overall, I would answer the question with another question: “how do I find the right sensei?” Finding one’s sensei is an essential part of the lean journey. In the Wild West, it was easy enough to set up a sign saying doctor, or judge – who could tell the difference? In current settings, any half-trained consultant can call himself or herself sensei – how can you tell the difference? You can’t, but your local Lean Community will. Real senseis are rare, expensive, and generally a pain. They don’t tell you what you want to hear to solve your problems in the way you’d like. They know that the solutions to problems don’t exist in the mindsets that created the problem in the first case. They will look for areas where you will learn to change your mind by yourself.

So how can you tell a real sensei from a self-promoted one? You can’t. No real sensei will actually claim he’s a sensei, which doesn’t help either (those who have “lean sensei” on their résumé are, at best tasteless, at worst snake oil doctors). But your lean community will know, and the Lean Community at large around has a pretty good idea as well. Again, this is an engagement issue. Finding the right sensei is your responsibility and part of your lean journey.

Why audit standard work? And what is the best approach?

January 1, 2013
Back to top

Dear Gemba Coach,

Can you help me determine the best way to conduct audits of standard work (SW)? The Toyota Way Fieldbook describes a layered SW auditing system.  Team Leaders audit each of their five-member team members at least once per hour (40 audits/shift).  A group leader may audit one of these 5-member teams under their span of control at least once per hour (8 audits/shift).   The frequencies follow suit as you go up the organizational hierarchy.  What auditing frequency have you seen to be most effective?

To start with, I’m a bit uneasy about the term “audit” itself. Auditing means the structured evaluation of an activity (check is a looser term), and the question I’d have is: to what end? What is the problem you’re trying to solve?

Before getting into specifics (which I will), let’s explore a few questions about standard work itself. I’m assuming that you are keen to have standardized work implemented correctly, and so have concluded it needs to be checked frequently – no debate. Coincidentally, I was discussing with a Toyota senior exec who mentioned that his boss from Japan insists on six main points:

  1. Going to the Gemba to see problems, which also involves creating an atmosphere of calling things as they are and not hide issues.
  2. Establish standards if they’re not in place, as this is the starting point of kaizen.
  3. kaizen day after day, even the smallest things – which is very hard to keep going.
  4. The accumulating of kaizen creates the basis for larger changes in the year, which leads to innovation.
  5. Develop people: problem solving offers opportunity for people to think every day, and one shouldn’t give them the solution but guide them in deeper thinking.
  6. Encourage teamwork, which is far more effective than working alone.

These are great points because they question the intent behind every action: are we doing this or that for the right reasons? In a spirit of respect (in the Toyota sense)? What exactly are we seeking?

So let’s think ourselves back to the Gemba in a five-operator cell and ask ourselves the question of auditing standardized work with these six intentions in mind.

What Is the Purpose?

First, as I said, I’m uneasy with the term audit because, in our culture, it implicitly involves calling someone out. How do you feel when you are about to be audited at work? Do you feel relaxed and eager because finally someone is going to look at how you work and help you solve your problems? Or are you anxious and apprehensive because some know-nothing auditor is about to focus on unimportant details, miss the obvious, and blame you for not following procedure correctly, regardless of context? The whole point of going to the Gemba is to agree on problems in order to work together to resolve them. The difficulty here is that management should make people feel comfortable to disclose unfavorable information rather than conceal it. This kind of trust doesn’t come easily to human beings and it has to be fostered carefully – it takes long to nurture and can be destroyed with one wrong word.

What are you seeking in auditing how people work? This is the first question you must face – I know, I know, work isn’t like that and there’s always pressure to get things done rather than spend time questioning motives, but I’m afraid it really does condition every thing else. When you find an operator NOT respecting some standard or other – how do you plan to react? Do you intend to correct him or her and move on? Or do you want to find out why they’re not following the standard. Chances are, they have been taught, they want to follow the standard, but something stops them: maybe the equipment doesn’t behave as it’s supposed to? Maybe one specific movement is awkward or painful? Maybe both, such as a machine command slightly out of reach for a shorter person, which is then not pressed properly, and so on.

The purpose of checking standardized work is to check understanding of the standard and discover individual difficulties in order to resolve them through either individual training (to help the operator deal with the difficulty) and/or kaizen (to take the difficulty away).

Before we worry about auditing frequency, I’d start worrying about whether we know how to teach group leaders and team leaders how to correctly react to the problems they identify. Trust is a fragile thing, and the Taylorist tradition of just telling people to follow the procedure is strong in most shop floors. At this stage, I’d suggest that you step back from your question and reflect on what, exactly, you guys are planning to do and how do you intend to achieve it. If, as is often the case, the main concern is control of the work cycle to guarantee productivity, I’d argue for a rethink.

Where There’s a Will

The second point is establishing standards. Standardized work is very precise and specific to repetitive work in stabilized work cycles. In my experience, not that many operations have the right conditions in place and establishing standardized work is hard simply because work standards are not stabilized (the operator keeps being pulled away from the work cycle to do this or that). Stand 20 minutes in the “Ohno circle” and watch what is really going on (20 minutes is a good time: it’s long enough for people to start really looking as opposed to be skimming the process thinking about all their other worries).

In fact, in most non-automotive factories I’ve visited, basic operations standards (what operators need to do to make the product) are far from clear at the operator level. In other words, we have no firm place to start kaizen. For years I’ve made the mistake in assuming work standards should be in place before starting to work with operators, so some poor lean guy or manufacturing engineer got the job of clarifying all work standards – a difficult, lonely, and ultimately unrewarding job.

One day, by looking at the problem from the operator’s perspective in one plant, we realized that the issue was not the paper itself, but the collective will to follow standards. Each operator felt they knew best. We then established a “training” plan where group leaders would spend 20 minutes a day looking at one job with one operator and write the work standard together (sequence of steps, safety, key points, reasons for key points, etc.). One day, one person. As the plant started to do that, a library of work standards build up progressively and operators started comparing how they worked and discussing and exchanging practices.

At which point, the plant manager discovered that the number of opportunities for kaizen was exponential, which leads us into the third point you need to consider: what is your capability for kaizen? You’ll find that if you check processes with the intention of discovering problems, EVERY time you look at a work cycle, you WILL uncover a difficulty for the operator making it hard to follow work standards – and even surer the standardized work. In order to continue to build trust, you then must be ready to follow the third point of kaizening the little things, every day.

kaizen Capability

As this is not so easy because in most cases our capacity for kaizen is not infinite, you must think about it before setting a specific audit frequency. In other words, do you have the kaizen capability to conduct small improvements after EACH audit? The only way to keep this rhythm is to train team leaders to be autonomous in supporting kaizen, but, again, this is not a given and a challenge in its full right.

Which leads us to the fourth point: what is the larger change you’re trying to lead? One obvious one with a huge impact on work standards, for instance, is greater flexibility to accelerate flow. More frequent changeovers means more frequent switching from one work standard to the next, which entails more training and more checking.

The stone mason has a different outlook whether he believes he is cutting a stone, making a wall or building a cathedral. People will accept better the rigors of training and checking the detail of work standards if they understand the overall intent of the plant.

In the Toyota plant I previously mentioned, one challenge was to accelerate takt time changes in order to stick closer to difficult market conditions. Team members understood that, and the impact on changing standardized work accordingly, and so retraining, re-checking and doing more kaizen. Then, the plant prepared for a new model introduction, and again, the team members understood why all what had been done on work standards had to be done again. If you can’t share with your people your wider objectives by being on the shop floor and demonstrating personal interest in their progress, they won’t take kindly to work disruptions involved in the three previous points.

Because, point five, our aim is to develop people. Outside of Toyota, work standards are often felt as an additional constraint to getting the job done. People are more often than not abandoned with iffy equipment and unclear instructions and figure out by themselves how to make the parts and go through the day. Procedures are a necessary evil. The challenge is to get employees to want to do a good job, and consequently to want to adhere to standards because they themselves feel it’s the best way to succeed. This means people should (1) want to get it right and (2) trust that the existing standard is the way to get it right. problem solving is the key to spreading this understanding as in most cases, the most obvious reason the problem occurred in the first place is that some standard or other has not been respected.

I vividly remember failing to solve intractable quality problem on one part for Toyota at a supplier’s until one engineer arrived from Japan, got us to pull out all the technical documentation we had on the machine (a challenge in itself as the equipment had been there for years and the plant had changed hands at least twice since), and then, as we read through it line by line, ask us whether the ground was exactly plane (as it said in the documentation). He then got us to redo the ground and – lo! The machine started working without defects. He then asked us to figure out “why?” It was both instructive and embarrassing. Basically this guy had flown all the way from Japan to tell us to RTFM (read the ******* manual) and level the floor. It turns out he knew this was a classic problem with this kind of machine, and could have told us in a phone call. But he was making a more general point of teaching us to solve problems by first starting with standards. As a fledgling lean coach, I really took my lesson that way, and whenever I’m faced with a difficult technical problem I start by asking the team: where are your standards?

So let me return to your question, which reminds me: The Toyota Way Fieldbook: a classic! (If any of you have not read it yet, stop everything and read it now!) And a great source of inspiration. Constant checking is definitely an important part of lean practice, and every Toyota plant I’ve visited has its own system of “auditing.” I’ve asked Jeff Liker what exactly he had in mind and he told me that they were describing the system that was used for auditing at NUMMI during a year when one of their top priorities was group leader development.  NUMMI’s management had discovered weaknesses in the group leader role because of a lot of churn.

They set up a story board (kamishibai) that had instructions for a standard work day and a separate standardized work auditing board. The group leaders checked one process per day, actually per shift, since there were two shifts and two GLs.  The assistant manager the group leaders reported to in an area would go around and audit one job per day for each group leader--not necessarily what they audited, but one of the jobs they had audited recently.  If he found a discrepancy between his audit and theirs, he would have a coaching discussion about that. One job per hour does seem rather extreme.

You may have heard of “kamishibai” boards: visualizing the auditing activity by placing cards with audit questions on a board and establishing a schedule of audits, and so forth. Certainly, advanced plants will have the team leader check the standardized work of every person in the cell at least once a shift and audit more deeply one job per shift as well. However, we must bear in mind that whatever Toyota does is contingent to one plant, and one situation. Copying this or that Toyota practice without giving it some deeper thought usually leads to tears.

So let me answer the question with a question. What is the set frequency for your senior management to check the auditing system?  What is the big change your leaders are after? Have you collectively agreed on the mode of kaizen to support this change? Have they committed to checking the progress at the Gemba regularly? Auditing frequency should not be set because this or that Toyota plant did it like this at some point in its history. It should fit a management purpose and should be constantly checked and modified according to how well it helps you reach your goals. The answer to your question lies in following the full PDCA auditing corresponds to: what was the plan? Are we doing it? How often (and how) do we check? What are the conclusions we draw from this?