Column Archive: 2012


Why isn’t there more emphasis on lean engineering?

December 17, 2012

Dear Gemba Coach,

Why isn’t there more emphasis on lean engineering?

That’s an excellent question. I was recently wondering the same with James Morgan, the co-author of The Toyota Product Development Process , who is now a senior engineering director at Ford. We share the understanding that at the root of every corporate revitalization (Ford, Apple, etc.) we find the product, the product, the product. Why managers don’t seem to get that is a mystery to me.

In point of fact, if I had to sum up 20 years of practice in one piece of advice it would be: “focus all your energies on making the best product you can, and let everything else take care of itself.” On the gemba, I believe that the very first step of lean is quality first, safety always. When I help CEOs with lean transformations, the first port of call is looking at customer complaints to see firsthand what customers tell us about the product. Furthermore, I don't believe in processes in the abstract. A process only makes sense if we understand what the product does for customers, and how the process delivers this value.

The results are there to prove the point. To prepare for my webinar and workshop on “the business case for lean” I asked several CEOs to sum up their results over the past three years: 61% sales increase, 62% cash improvement, 74% margin increase for one. Plus 93% turnover with 173% EBITDA improvement for another while maintaining its cash position regardless of sales growth (total inventory was reduced from 600 days to 80). And this with industrial companies working in France where industrial activity is in free fall. Lean being lean, neither of these CEOs feel very successful day to day – “problems first” does tend to cloud the view – but the results are amazing. Such results are possible, however, because they did not start by improving productivity or cutting costs. Rather, they started by improving their products and selling more (in both cases there was no additional sales push, indeed, in the second case, which is high-tech metallurgy, there isn’t even a sales structure). These examples are not lucky flukes. They reveal the potential of lean if one fights the right battles, first defined by Toyota as “in order to make things, you’ve got to make people.”

Lean Engineering's Promise

Engineering is the largest piece of this equation. Engineering is where both customer satisfaction and costs are largely set. Sure, production can either enhance both with kaizen by mastering processes and eliminating waste, but structural success of a product and its production costs are determined by engineering decisions and skills. Toyota did not take the number one spot on the podium solely by reducing its manufacturing costs. It took over a market dominated by historical giants by offering cars people bought. In this sense, the promise of lean engineering is even larger than anything we’ve ever done on the shop floor. So, indeed, why so little material about it? I suspect there are three main reasons for the lack of interest, despite the mammoth potential gains.

Firstly, it’s easier to look for a lost key under the light because there, we can see. Since the publication of The Machine That Changed The World (which does go in-depth on the engineering aspects to Toyota’s success) books about lean manufacturing have increased exponentially as the field developed. On the engineering front, after Durward Sobek’s breakthrough PhD thesis (to my knowledge, still unpublished) and Jeff Liker and James Morgan’s seminal book, the few lean engineering books (with a few notable exceptions, such as Michael Kennedy’s work) that I’ve seen aren’t about how Toyota does engineering, but more about how to apply known lean manufacturing principles to the engineering field. This has had the unfortunate effect of focusing efforts on “optimizing” engineering resources (read headcount reduction in engineering) by “lean” project management, rather than learning how to make killer products.

One common explanation is that shop floor processes are easier to see than engineering processes, which is true to a point, but I really believe it’s a matter of focus. When the CEO decides to focus on his or her products, the lean techniques are there precisely to, as usual, visualize activities, formulate problems, seek root cause and study countermeasures. Essentially, you find what you seek, so if your problem is reducing engineering headcount, you’ll achieve that, and probably break the company in the process. Conversely if you seek to design product magic for customers, you’ll probably do so as well, and grow the company accordingly. A large reason of why there is not more research on Toyota’s lean way to design products is that there is little demand for it.

A second part to this answer was driven home by Dan Jones who pointed out to me that although Toyota is seen unequivocally as the world master and exemplar in process mastery, it is not so in product development because most people confuse design with style. Toyota cars have been historically rather boring to look at and no one would spontaneously think of it as the furthermost product development company (as opposed to, say, Apple). I won’t dispute the fact that Toyotas are not the most exciting cars to look at, and yet, as Jeff Liker often points out, Toyota is still the unrivalled master of value for money customer surveys.

Understand Value

The deep lesson Toyota has to teach us is that the foundation of its ability to deliver value lies on its skill at understanding value. The issue is to correctly spot what customers are willing to pay for rather than what they say they like – and experience shows these are two very different things. I have the good fortune of knowing the French counterpart of Toyota’s chief engineer on the Peugeot-Toyota joint venture in Kolin and he has become a die-hard fan of Toyota’s lean approach to engineering which he has captured in a nutshell as “people build great products, not systems or organizations.” From an engineering perspective, we currently believe that Toyota has three things to teach us:

  • Understanding value from the point of view of customers: customers want everything and nothing according to when you listen to them and who you talk to. Toyota has a unique way of narrowing down the value proposition to hit the sweet spot where the core of the target market for a specific vehicle finds something competitors don’t offer. This is largely done through the chief engineer function where one individual (think of it as the designer) is asked to formulate a concept for the product that will be the best fit-to-fact on customer value for the targeted segment. This is more an art than a skill and it requires both technical mastery and openness and insight in customer usages and preferences, and is developed over a lifetime. Few companies have singled out the chief engineer function, and fewer companies deliberately grow them. And yet, this is one key aspect of conceiving products customers will fall in love with.
  • Feeding back production experience into engineering design: through the use of standards and checklists, Toyota has the unique ability to capitalize on production experience at the design phase, and thus come up with robust designs. The impact of this know-how is huge. First, customers experience far fewer problems with new products because there is less wild, untested innovation in them. Secondly, the development process is far less costly because fewer mistakes in the early phases need redesign in the later, more complex phases (cost increase as changes are made later: after tooling, changes become very, very expensive).
  • Capturing innovation value from the supply chain: by squeezing suppliers relentlessly, many producers shoot themselves in the foot as, in modern supply chain, much of innovation capability lies with suppliers. I’ve personally been on the gemba of an automotive supplier who came up with a much loved customer feature, but who was pressured so brutally on costs by the OEMs that they had stripped their engineering department to the bone, and as a result, had endless problems to stabilize the innovative product – which meant disappointing customers as well as final assembly muda (by rejecting parts in percentages). Toyota’s fine distinctions in relationships with their suppliers and collaborative approach with key partners enables them to innovate robustly, and continuously as suppliers come up with credible suggestions for new features or improvement to existing ones.

More Work to Do

As to the feeling that Toyota is not an innovative company, all I can say is that I recently drove the new plug-in Prius. Maybe it’s just me, but unplugging the car from the main, driving around in heavy traffic all day with an overall gas consumption of that of a motorcycle – and this in perfect silence – was a very emotional experience. I started fantasizing of a town where every car would be like that: a different world. Toyota has, in actual fact, produced a string of killer products, from the Lexus (the drive of a Beamer with the comfort of a Caddy) to the iQ (the size of a Smart with the feel of a sedan). I remain that convinced the company is as strong an exemplar for engineering as it’s been in manufacturing.

Yet, probably a deeper and more lasting reason why lean engineering isn’t taking off as lean manufacturing has, is Finance’s current dominance in management thinking. I’ve seen what happens when a finance guy gets the top job in a company, or, indeed, in a plant. I’ve lived through excellent companies being purchased (for their cash and EBIT results) by finance-driven equity firms. All your average financial manager cares about is reducing costs. Separating revenue (a marketing problem) from costs (an operational problem) is the kind of nonsense that already drew pages of scorn from Taiichi Ohno, but that has become implicitly accepted as obvious in most companies I come across. Revenues and costs are generated by the same physical processes and splitting one from the other simply leads to dumb mistakes. Furthermore, return on investment thinking frames every issue as a project, and completely disregards the fact that both revenues and costs are created day to day by how people tackle commonplace situations. Results are made in normal conditions, not exceptional ones. What is more, looking at numbers leads financiers to completely dismiss exceptional losses (it wasn’t supposed to turn out that way) even when these so-called “exceptional” costs threaten the very life of the company or society as we know it (I’m not being hysterical: look at how quickly the great crash of 2008 has been dismissed as a rogue event by the financial world).

To be honest, it’s unfair to blame financiers for doing what society rewards them for. The blame lies with the rest of us. Until we come up with a robust, viable, alternative to financial thinking and prove that, in Tom Johnson’s terms, “profit beyond measure” is possible by making products for people with people (and in a more people-friendly way) the situation is unlikely to change, no matter how much we bemoan it. So thank you for your question, which I’ll take as a call to action. The short and the long of it is that there isn’t more about lean engineering because we, the lean researchers, haven’t done enough.

How do I convince senior management to visit the shop floor?

November 30, 2012
Back to top

Dear Gemba Coach,

How do I convince my senior management to get interested in our kaizen projects? In fact, how can I simply convince them to visit the shop floor?

Good question. Let me ask you back, how do you convince anyone of doing anything? Particularly when you can’t force them?

Senior managers are usually busy people who have achieved their rank by the force of their personality: they’re the guys who get things done, not the guys who take lessons from time wasters. In order to convince a senior executive to accompany you to the Gemba to look at kaizen efforts, you’ve first got to convince them it’s in their own interest, which means showing them: (1) that it’s relevant to getting what they want, (2) that it will get them what they want (as opposed to spending time on something else), and (3) that the experience will be satisfying.

In other words, before you consider ways to persuade them to visit your Gemba, ask yourself if your request considers their Gemba. Most lean officers I meet are intent on discussing their own issues. They want to talk about how various waste impacts the company, and complain that no one cares.  How many times have I have heard lean officers gripe about purchasing policies that systematically give the job to the lowest bidder irrespective of the resulting impact on the process—even when the supplier doesn’t deliver on time or produces poor quality? How many times have I heard that producing large number of products in advance for a product launch not only fills in entire warehouses of inventories but most often create large numbers of obsoletes? The stories of glorious waste are endless. How come senior execs are not interested in stopping such kind of wanton value destruction? Shame on them!

In doing so, the lean officers unknowingly adopt the same posture as the people they despair of convincing: it’s someone else’s fault. THEYdon’t get it.

The Transylvania Price

The kaizen way of looking at this problem is to take responsibility for it. To say that execs don’t get it because WE don’t know how to make them understand. This means that the first step in getting anyone to understand anything is seeing through their eyes and talking their language. In this case, what is a senior manager’s language? Budget.

Modern companies are built, by and large, on the model developed by General Motors under Alfred Sloan: (1) manage by numbers; (2) manage by objectives; (3) manage portfolios of activities and (4) delegate. Starting with the plant manager, a senior line exec will: have a budget to make, be incentivized on reaching certain key numbers, be asked to implement a range of activities, and be expected to delegate these activities effectively.

In this framework the purchasing manager’s stand makes perfect sense. She’s got to reduce the overall cost of purchased parts by so much every year. She’ll get a bonus only if she achieves this, and she’s got a number of higher-up initiatives to implement. A few years ago, for instance, the purchasing manager from a large OEM had a clear objective from her CEO: 30% suppliers in low-cost countries, or else. Not surprisingly, at site level, they often wondered why corporate forced them to replace their good suppliers (with whom they had a long standing relationships) with some unknown Transylvanian guy who couldn’t deliver a part on time (and for that matter couldn’t even make a good part). Well, it might not make sense for the site or the business, but it certainly does for the purchasing director’s bonus.

I suspect, from your question, that you are a lean officer. So here’s the first question you should consider: how good are you at reading a budget? Before you meet with a manager, have you studied their budget? Can you examine line-by-line cost items and think: aha! This doesn’t make much sense…why? Can you identify what hasn’t changed in the past three years and suggest an explanation? Becoming a lean virtuoso won’t help you much if you can’t talk to managers, end of story. And learning to speak means learning their language. So: how much finance training have you gone to? Are you ready to kaizen yourself before preaching to others? Learn to read a budget.

When you do, you will discover that most managers have a specific ways of hitting their budget numbers. They try to think how to manage the top line by very global reasoning. They will look at purchasing costs, for example, at a very global level and think, “Hey, if I outsource half of these parts, I’ll get a better price on them.”

Or they’ll analyze labor costs and say, “Hey, I forbid them to hire temps, I’ll reduce the labor cost by so much.” When looking at the numbers, such conclusions are reasonable in the world of finance…but not always in the nitty-gritty day-to-day grind. These products have to be delivered in order to be paid for and for the cash to come into the till. And many of the cost-based strategies have unintended consequences that create large real exceptional costs. Outsourcing parts means losing critical part knowledge and creates exceptional costs in dealing with suppliers, and related problems. Later on, when we renew the product, having outsourced the part can create engineering issues because no one knows much how this part behaves any longer, and so on.

It’s All about Performance

Management is like a kind of lottery. As a manager, you are praised for your bold actions, but never asked for the check mechanism, for the test method. At review time it has either worked, or not. You either get rewarded, or punished. You’ve bought the ticket, and hope for the lucky payout. The second survivor’s skill for a manager (after: “Sure, boss, I’ll do it”) is to explain that the numbers couldn’t be hit by circumstances beyond your control (and someone else’s fault): it snowed in the winter, so we had delivery problems, and people took their holidays in the summer so we had quality problems because of all the temps, and so on. As a lean officer, your job is to be able to show that exceptional costs are not exceptional – they are the direct results of some policies.

As Orry Fiume, the retired CFO of Wiremold (see Lean Thinking) insightfully explains, productivity is the relationship between quantity of output vs. the quantity of resources used: it’s a physical equation, not a financial one:

  • Sales $           =          Quantity x Price
  • Material $       =          Quantity x Price
  • Labor $           =          Quantity x Price
  • O/H $              =          Quantity x Price

The trick is to discuss the budget number by going back to the physical quantities that underlie them. You want to increase the top lines? Where are these sales going to come from? Are you going to sell more to existing clients? Which ones? How can you do this with 30 quality complaints a month? You want them to renew their product range? How can you do this if the new product release is six months late? And so on.

Lean is about performance. As lean guys, we often follow a set of physical performance indicators, such as:

  • Accidents
  • Customer complaints
  • On Time Delivery
  • Internal PPMs (bad parts per million)
  • PPH (parts per person per hour)
  • OEU (overall equipment utilization)
  • Suggestions per person
  • Days of Inventory

The trick is then to relate this to budget line numbers. Reducing complaints will both affect the top line and reduce the exceptional costs of dealing with complaints; Reducing PPMs will reduce material costs and labor costs, and so on.

The difficulty, of course is that there is no mechanistic relationship between our performance indicators and the budget lines, it’s mostly a matter of debate, discussion and, in the end, experience and good judgment. Still, this is a discussion we can and need to have with executives. We need to get to discuss the physical drivers of their budget lines. Which brings them to the shop floor.

Most managers are quite smart. When you’ve showed them a kaizen which impacts performance sustainably, and that you can relate to one of their budget line items, most of them will get it, and to your surprise, ask for more, quicker. Now you can work the deal by saying: “Wait a second mate, sorry, but quicker depends on your presence on the Gemba to discuss with your supervisors about why they don’t give you more quicker.” I’m not saying this is an easy conversation, but it IS a conversation. This is the starting point of the relationship. What we’re trying to build is an ongoing debate around:

Budget lines <—> performance indicators <—> kaizen activities

 

Although this graph should really be:

Budget lines <—> experience and judgment <—> performance indicators <—> experience and judgment <—> kaizen activities

Show Me the Money

I have to confess that I’ve not faced the issue of getting managers to go to the Gemba for a long time. I find that managers are actually rather quick (sometimes too quick) at figuring how what they’re doing affects their profits when you know how to point it out.

But it is also true I spend more time discussing budgets than lean with senior managers on the shop floor. We constantly try to figure out how our practices affect our performance and how this translates into our budget numbers. I’m not saying that this is an easy skill to acquire, and I’ve sweated over it (still do), but I have found that when you do that, the issue of going to the Gemba disappears: they’re hooked the moment they see how it pays.

No silver bullet here, the answer to every lean question is work, and more work. And, as ever, kaizen starts with us. So let me circle back to the key issue here: how much time are you investing in learning to speak manage-ese? Learn about budgets, and learn to show how exceptional costs in budgets can be avoided by targeted improved performance, and the chances are that bringing your senior managers to the Gemba won’t be a problem any longer – so you can discover the next level of problems!

How can we reconcile the lean principle of respect for people with our disrespectful atmosphere?

November 26, 2012
Back to top

Dear Gemba Coach,


I appreciate your frequent discussions about the value of respect in order to be lean. Unfortunately my company has embarked on a lean program that is anything but respectful. Competent people are stigmatized as “concrete heads” whenever they disagree with anything the lean coaches come up with, even when their prescriptions make absolutely no business sense. What used to be a good atmosphere for work is now poisoned by resentment and distrust. How can that be compatible with the “respect” message of lean?

Ouch. I wish I could say you’re in a unique situation, but unfortunately, I have heard of many firms where this does happen, and have even seen a few during Gemba visits. So you’re probably observing something very real, and I’m sorry that you have to go through it.

Let me start by clarifying “respect” as I understand it, and then see if we can diagnose what is happening in your case, with possibilities for countermeasure, no matter how remote. In lean, respect means “respect for the development of the person to his or her fullest ability” (at least over here in Europe). This doesn’t necessarily involve being polite (although this is independently good, I guess). Respect is mostly about the boss’ good intentions towards you, even if somehow this intention is shown awkwardly. One inside Toyota joke is “my boss has shown me too much respect today.”

Regardless of whether Toyota still remains an exemplar for the lean movement, I find the company endlessly impressive for something it emphasizes to this day: when its executives discuss production issues, they always talk about operators. “What is the mission of the operator?” “What is the standardized work?” (which is not to say the procedure, but the “how” of operator movements to succeed at the job), “What are the difficulties of the operator regarding his or her job?”

This may sound obvious to you, but believe me, I’m on the shop floor constantly with CEOs, figuring out how to lean their company.  And while its relatively easy to involve frontline management, getting them to see operator’s difficulties remains a real challenge. Recently I was in a construction site where the CEO was looking at the “problems, cause, countermeasure, status” list that every project manager has to update on a daily basis. I was reminded that the need to see causes from the worker’s eyes is always a struggle to explain.

For instance, in this renovation project, operators had demolished more of a wall than they should have (which creates rework in having to rebuild unnecessarily). The project manager had written “incorrect reading of the plans” as a cause. On the Gemba, walls to be demolished were marked with a large blue “D” without any visual indication of where to start or where to stop. A long discussion ensued about the fact that once the worker starts hitting a wall, they keep hitting: knowing when to stop isn’t intuitive and has to be clarified. Out of this conversation, the CEO and the project manager came up with the idea that they could ask the worker to spray demolition areas, thus confirming in advance what to hit and what to spare. In this case we see that the tool (spraying) is at the heart of an activity (learning to identify where to demolish and where not to), which is essentially development of the worker.

Trawling for Files

This experience drove home the point that that taking the value-adding perspective is possible, but never easy. You have to work at it. LEI CEO John Shook opened my eyes to this approach when we were discussing Toyota’s sense of  “respect.” He emphasized that respect was all about removing the difficulties that keep the operator from doing the job properly. Take note that this does NOT mean adding more control, more checks, more training. This is not to say that controls, checks and training are not a necessary part of achieving quality, of course. But they are still wastewaste that should be seen, and which needs to be understood at a root cause level, so that eventually the need for this wasteful activity can be eliminated.

Failing that, weird things happen. Recently I was in an aerospace factory watching a lady assemble high-tech parts. I stood there for about 40 minutes during which she assembled seven products. The actual work took a matter of minutes. She spent the rest of the time trawling for files on her computer to find the right paperwork, walking across the room several times to get printed sheets out of the printer across the hall, filling in the traceability forms, disappearing for several stretches of unexplained time, and so on. Meanwhile, her bosses were busy doing “lean” by building line-side feeders – which held several days of incoming parts. From the lean perspective, this is disrespectful in two ways. First, the operator is there to add value not do paperwork. Second, the outrageous layer of cost added to the product is endangering her job – if I’m going to be that inefficient, better do it in Asia.

This takes us to a wider implication of respect: beyond solving immediate difficulties for operators, the role of the leader is about creating a sense of peace-of-mind so that operators can focus on the work at hand and not worry about what will happen to them next. The fundamental lean deal of “mutual trust” goes something like: you contribute through your ideas to productivity improvement, and in exchange we do everything we can to create a safe and serene working environment. Part of “respect-for-humanity” is accepting that people are people, quirks and all, and that pressure on their personality is muri: overburden. I remember coming across the presentation of an ex-Toyota engineer who defined performance as the sum of personalities x competences x motivation. Personality is a plus, not a minus in the lean ideal.

Learning to Learn

What is it then about the “concrete heads”? Are some personalities incompatible with lean, or at the least, the core value of respect animating this approach? Lean is based, to cite John Shook again, on learning to learn. Performance increases when competent people coordinate better to come up with leaner processes and, in the process, improve their abilities. Leanness of processes is nourished by constantly improving individual know-how, skill and judgment. Consequently, experienced people who refuse to learn are a problem, and will feel pressured. That’s is true. Usually, they leave on their own accord. Ideally people should not feel pressure to achieve specific things but to learn.

In practice, how can you distinguish one from the other? The boundary is quite clear – the lean program requires of you one of two things, either:

  • Apply “best practice”

Or:

  • Participate in learning events.

Simply applying best practice is not lean. It’s straightforward Taylorism. That was one of Taylor’s big ideas: get an engineer to observe workers, figure out the “one best way,” and then get everyone else to apply it. This approach can achieve gains to be sure, yet they are limited. This practice completely ignores the fact that other workers might be operating in different specific local conditions. Taylorism is just dandy when we’re talking about moving a coal heap, but as soon as the job is more technically demanding – let alone knowledge work – the “best practice” idea is destructive of local knowledge and judgment, and many competent people will fight compliance with good cause (which is what seems to be happening in the case of your firm). Best practice thinking is NOT lean thinking.

In contrast, lean thinking is about participating in lean events, using the lean investigation tools, to figure out how to improve performance locally. Good practices from other areas are investigated, certainly, but as a source of inspiration rather than a recipe to be blindly followed. In lean jargon this is called “yokoten” which Jeff Liker once explained to me as “copy + kaizen.” The point of lean learning events is to engage people in solving their own problems and, by seeking root causes, deepening their own understanding of their job and how to better satisfy customers. The lean deal is that no one will ever force you to apply any practice you’re not comfortable with (after all, you’ve got good reasons), but you will be expected to participate in the learning events and draw conclusions on how you do your job, yes.

I have met many middle managers who were dismissive or clearly resistant about participating, running, or even drawing shop-floor conclusions from learning events. They said they were too busy with the here-and-now crisis, or felt that their authority was challenged by workers expressing their opinions or difficulties, or that some managers simply refused the learning effort.

When you encounter resistance, the first thing is to ask is whether you are facing  good people resisting applying “best practices,” or are they resisting participating in the learning events? It gets tricky of course when people feel the learning events are not producing smart results, and that is absolutely a fair game for discussion. More than that, this question calls for conducting the Plan (figure out the problem) Do (the learning event) Check (try it for real, see if it works) Adjust (if it’s silly) or Adopt (if it works) cycle of lean.

Ultimately, the difference from crypto-Taylorist lean programs and respect-for-people lean programs comes down to the CEO’s intentions. If the CEO has bought into the fact that they need to personally:

  1. Go to the Gemba
  2. To figure out how company policies create difficulties for people that stops them to add all the value they could
  3. Ask people to tackle problems one by one to get them to learn
  4. In order to study their initiatives and draw policy-level implications to lean the entire company, so that the CEO can learn from all staff’s initiatives

Then the chances are the learning cycles will occur in some form or shape. On the other hand if the CEO has delegated the task of writing all the best practices (or worse, carving them in stone through IT workflow systems) to a specialist group and then making people apply the new rules through the lean program “deployment,” then, yes, this will both destroy mutual trust and not get business results (actually, often worsen business performance).

Deal with It

Unfortunately, influencing the CEO is seldom an option. They are the way they are and we have to deal with it. What you can do is get fully involved in the learning events part of the program and use your experience to leverage the competence around you and come up with clever answers to the question asked. If you’re in a “apply the best practice” theory, you can also try to steer the debate to value – what are the real hard cash results expected from the action. Lean tools tend to steer the debate towards more rational answer. Counter-intuitively, the antidote to silly lean is more lean: learning to use the lean tools properly to come up with sensible countermeasures. For instance, the purchasing manager of a division successfully changed the “apply best practice” approach of centralizing all supply chains based on poorly thought out VSM precisely by drawing out lead-time analysis and asking for value.

My yardstick for a successful event is whether the analysis has led to deeper technical thinking, and whether the participants better understand their own technical issues. This often hinges on obtaining the trust of the most technical competent people, who are not necessarily the most open characters – after all, they know what they know, so why should they accept to be challenged or even listen. On the other hand, kaizen workshops dealing with non-product related issues (internal organization, office, etc.) are often a distraction – where the non-technical minded can rule because knowledge doesn’t matter that much. Solving our real problems together is also a good way to generate mutual trust.

There is no easy answer to your predicament, other than learning to own the lean tools by using them yourself, and in so doing to come up with sensible countermeasures. And in the process, beat some sense into the program!

How do we mid-level managers convince the CEO and senior management that adopting lean practices is worthwhile?

November 2, 2012
Back to top

Dear Gemba Coach,

Thanks very much for your insights during the recent webinar on the business case for lean.  The webinar was particularly useful for us because it raised many questions to investigate and provided a lot of common sense insight.  I am an administrator taking lean certification training at a primary care network. How do we as mid-to low level "operators" convince our CEO and senior management that adopting lean practices and thinking are worthwhile in our context?

Thanks for the kind words on the webinar, and the question. As I said during the webinar, my experience is that you can’t. Now I’ve been saying this for years: as a mid-level manager, you can’t convince the CEO and I’ve gotten a lot of flack for it because people tell me it’s too easy a response and that if it’s true it’s really depressing, and we might as well all go home. I accept these two criticisms and will try to make amends by going further into the fundamental problem, and try to convince you that accepting the lay of the land is not depressing, but opens up a different field for action and lean success.

First, we need to back up a bit and clarify the difference between doing lean, which is running kaizen events and applying the lean tools, and becoming lean, which is transforming the organization to better care about patients with less waste of resources by involving all health professionals, from doctors to janitors. The CEO really matters because when they’ve figured out how to become lean, then they know how to do lean in a smart way and get the results. If they haven’t, the workshops will lead to random improvement, high expectations, and the usual disappointments we’ve seen time and time again in the past 15 years. As my father, my sensei Orry Fiume, his boss at Wiremold Art Byrne, Pat Lancaster from Lantech, also a Lean Thinking case, have taught me, becoming lean happens when the CEO sees that lean is the strategy, not a tactic to implement his or her strategy (that’s the best case when they do have a strategy), or a bunch of tools to somehow “improve” the organization. This why the CEO is key, and impossible to convince: how will you, a middle-manager, be in a position to convince their CEO they should adopt a new strategy? Not likely. They’re the CEO because the shareholders have entrusted the company to their care, and your job is to help them execute the strategy they’ve picked – not the other way around. That may be a bitter pill to swallow if you see the lost opportunity as the CEO ignores the lean promise, but, hey, better deal with it upfront and relax about it. (Don’t stop reading right now, in the second part of the column I’ll go into what can be done).

Lean Strategy Explained

What does a lean strategy look like at the CEO level. In my father’s terms, a lean strategy is understanding the typical problems and typical solutions of your business. It’s NOT copying Toyota, it’s using the Toyota Production System to develop your lean thinking which is constantly to clarify what are your key challenges (typical problems) and key worker–level kaizens to improve on these challenges (typical solutions).

For instance, I mentioned the CEO of the construction company during the webinar, and a shortlist of his typical problems:

  • Leveling order intake
  • Improving right first time and quicker mistake detection and correction
  • Better hand-off between trades and quicker rotation
  • Better supplier selection
  • Greater attention to customers.

There are a few other items on his strategic list such as:

  • Reducing the work content of every new construction through better engineering choices
  • Innovating to reduce the energy consumption of every building
  • Maintaining a healthy pipeline of motivated project managers,

There aren’t that many more. Overall his strategy is centered on five to 10 “must do, can’t fail” challenges, and the experience to know how, exactly, these challenges express themselves on the Gemba. In front of each item on the list the CEO is constantly on the Gemba pushing his guys to find smarter and smarter detailed, operator-level solutions to these generic problems. And this is where the lean tools are so precious as they frame this conversation.

Lean for the CEO

For a CEO, a lean transformation has typically three phases, each equally hard in different ways. First, digesting the lean thinking literature and using Toyota as an example to figure out what the main challenges are; second, when these have stabilized, work relentlessly at sharing them on the Gemba with workers and actively look for local solutions and think of their impact; and third, after doing this a few years, revitalize the approach by reformulating the challenges or seeking new ones. Trust me, it’s hard – and unless your CEO is eager and willing to go down that path, the whole lean language doesn’t mean much beyond delegating others to do some “improvement.”

The first phase is particularly challenging as this goes against the grain of executives with bright ideas that rank-and-file have to execute. Here the CEO has to work at figuring out exactly what are the typical problems constraining growth and holding the business back. Rather than do this at the strategic thinking level, the CEO entering the lean world needs to do this with a sensei on the Gemba. Again, that ain’t easy. This is where lean tradition can really help. For instance, in the healthcare field, follow in the footsteps of the one man who has a proven lean transformation, John Toussaint, M.D., and who has written a seminal book about how to apply lean hospitals: On the Mend. In the book he outlines perfectly the discovery method for healthcare:

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

Now this seems pretty straightforward, but when hospitals “do” lean what do they typically focus on? Cost reduction, bed utilization, IT planning systems, and probably a training program for all their ward managers to teach them about lean. In other words, they hope the lean tools will help them solve their issues without challenging their understanding of their challenges (I’ll give the game away: it won’t). Where is the patient? Where is the value? Where is the lead-time? A CEO keen to become lean would start by the emergency ward and simply look at how patients are treated there and ask himself or herself: are we focusing on the patient here, or are we “optimizing” hospital resources? She would go into a treatment room and ask herself: is all here adding value to the patient or are all those shelves and stuff stacked here because I can’t get them delivered just in time from my central logistics? She would look at cardiac arrest incidents and ask herself how long it really takes for a team to reach the patient and save a life? These are the hard questions you need to ask yourself at the CEO level until you’ve figured out, slowly and carefully, which questions exactly apply to your hospital.

As the questions accrete, it becomes easier to focus on specific operator behaviors that create the problem. Mostly, we’ll find that worker-level actions are the echo of some policy somewhere along the line. Nurses keep their own reserve of critical supplies (and thus creating obsolete and hygiene risks) because they’ve been caught out too many times with late deliveries from central stores. Doctors turn out late to surgery because they’re know every one is never ready on time, so why bother, and so on. And as this becomes clearer, we can then work on behavior-improvement activities, using all the tools available in the lean tradition: spot measurements, kaizen workshops, checklists, dojos, etc.

Actions for Lean Managers

As a middle manager, we’ll agree that you’re unlikely to get your CEO to take that plunge. So what can you do? Well, you can get promoted. I’m not kidding, you can start by using lean thinking to improve your own activities and earn respect and progressively be listened to.

I’ve known for years a guy who’s been a lean maniac in healthcare. He used to work with a large consultancy in hospital contracts, and decided that the only way to really change things was to be part of the hospital management. He got himself hired as improvement director of a hospital, but ran into same old, same old: no one would listen. He finally stopped trying to convince anyone of “lean” and started doing his job. He narrowed down his job to working with the few managers in the hospital who seemed open to improvement. In the end, this came to (1) starting surgery on time in the theatres, (2) patient welcomed at admissions, (3) on-time delivery of sterile material.

It doesn’t sound like much, but in each of these cases, he was able to both show significant results (a 20-minute improvement of time of first incision in the operating theatres has a huge financial impacts) and nurture relationships. Progressively, the COO gave him more portfolios and greater responsibilities (not necessarily a “gift”), and as he did so, he also started being cautiously curious about how this chap solved problems with counter-intuitive solutions. Two years later, the COO went to a lean conference on his own and came back as if he’d seen the light. How do we do this lean stuff of yours? he asked.

You can lead a horse to water, but you can’t make it drink. You can’t convince powerful people of anything, they have to convince themselves. What you can work on, is to have greater credibility because of your results, your relationships, and your good sense. The answer to your question is to stop trying others to do lean, and commit to become lean yourself, in your day-to-day job, with your own staff. In the construction company I mentioned earlier, no one knows they’re doing “lean.” Only the CEO reads the lean books and goes to lean conferences. Managers only know they have difficult problems to solve and have to involve their shop-floor workers to solve them.

You can’t convince your boss to do lean, but you can become more convincing yourself by doing lean rather than talking about it. Few consultants ever get lean because they’re always thinking about getting others to apply it, but not them. As a result, their own learning curve stagnates. Don’t fall into that trap. Lean yourself before you try to lean others. In Art Byrne’s words: “Don’t just do lean; be lean.”

What would a lean transformation mean for the IT Department? What benefits would it create for the company?

October 28, 2012
Back to top

Dear Gemba Coach

We’ve asked our IT department to be involved in kaizen events several times, but it is always very slow to deliver what is asked.  What would a lean transformation mean for this department? What benefits would it create for the company?

To be honest, my experience in lean IT is limited and there are many folks who’d have better answers – for instance, if you’re interested, the Lean Global Network organizes a Lean IT Summit in Paris at the end of November (http://www.lean-it-summit.com/). Nonetheless, what you say sounds awfully familiar. In years of studying lean turnarounds, I’ve seen lean efforts run afoul of IT departments in two main ways. First, in leaning value-production processes line managers and their teams often need to change the supporting IT processes, and this turns out the be quite a challenge. Secondly, and with greater overall impact, many products now have a software component either in the product itself or its integration, and improving the product’s quality has software impacts, which involves the IT department software design’s side.

The three main ways I’ve seen lean efforts require IT support are, obviously, the MRP, and especially the handling of the product options in the system; secondly, changes to the procurement system; and thirdly the quality reporting system. Moving from work orders generated by the system to pull has a huge IT impact, not surprisingly. The focus shifts from running the plant with the MRP (by telling each production cell what to produce when in real time) to using the MRP to create a level plan at the pacemaker process and then pulling production with kanban cards.

It’s surprising, but I have to say I’ve never seen a case of IT involvement in that change. Line managers grumble and complain, but in the end, find it easier to just do it, and somehow cope with the system as it is rather than go through the hassle of explaining the changes to the IT chaps and then waiting eighteen months for a new system that probably won’t do what was needed. Bear in mind that production and logistics staff are often learning as they go as well so their requirements for IT keep changing as their understanding improves and become increasingly puzzling. It’s hard to blame the IT managers for shrugging their shoulders and letting the dust settle before they try to seriously get their minds around the issue.

Yes, in some cases this creates unnecessary work and duplication of effort – particularly when the product has many variants and many steps, in which case the product/process matrix can be a real headache – I recently saw a German team spread huge sheets on the floor just to make sense of it. What tends to happen is that logistics people first start calculating by hand, then on a spreadsheet, then automate the spreadsheet – and at some point, this gets fed back into the MRP system, but more often not and somehow things get along fine. The unexpected benefit of not being to solve leveling problems through the system is that it forces operational teams to take control of their processes back from the systems and ask themselves deeper questions no one has asked in a long time. Once it’s set in the software, the process is usually both inflexible and hard to change, so doing it all by hand is not necessarily a bad thing.

This is trickier in the case of procurement where you have to work with the MRP – there is simply no other way. But here again, I’ve seen procurement departments extract high runners by hand on excel sheets and start sending hand-drawn leveled plans to their main suppliers for the high running parts independently of the system. As a supplier what you then get is an overall idea of what the customer company’s production plan is (which, for many reasons it won’t achieve perfectly) and then the usual variation-ridden call off from the system. Over time, though, as production learns to level and stick to the plan, the variation is reduced, the call-offs are closer to the plan, and somehow the issue disappears. Yes, the lean ideal is to switch to a lead-time based MRP system but I have never personally seen one outside of Toyota.

Software’s Hard Problems

Other than scheduling and supply chain, the other IT topic critical to any lean effort is the quality feedback system: how field quality, warranty results, customer incidents, final inspection ppm, in-process ppm, supplier ppm, etc. are recorded and displayed. In many cases, the system simply isn’t there. In others, it expresses quality issues in cost terms (the dreaded “cost of non-quality”) and reports it as such. Building a robust quality reporting system is a key part of any lean effort and can’t be done without IT.

My own preferred solution is a web-based system that can be consulted easily by anyone. Such systems can usually be developed out of the IT mainstream, and so again, lean transformation doesn’t collide directly with IT. At the end of the day, lean transformation in the IT department would probably help tremendously (well, maybe), but I’ve not – so far – have had occasion to find out. On the other hand, IT is rarely a direct step in producing value so, perhaps, we should not worry too much about it.

Software, on the other hand is often a key part of many products as they increasingly carry electronics-dependent functionalities. Software delivers value. Unfortunately, software is also the source of much waste. The three main issues I’ve encountered with software delivery have been:

  1. Product robustness – the moment electronics are involved, many of the products failure modes are linked to software glitches. Whilst it doesn’t matter that much for word processing or web pages, having to turn off the device and switch it on again to work around a bug can be seriously annoying and occasionally dangerous. Toyota’s main PR vulnerability is now linked to the software in its cars, from the braking system to unintended acceleration and so on.
  2. Product performance – many product functionalities now completely rely on software, and software is both rigid in terms of coded application and fast moving in terms of innovations, which creates massive headaches for the product development engineers. On the one hand, they need to deal with the legacy, and on the other, they need to keep up with innovative code. As a result, software projects can be complex and confusing in terms of both goals and execution.
  3. Release delays – software project delays are thought to be inevitable in software applications, but can badly impact product SOP and launch when the software drives a specific feature, particularly in complex products.

There are two lean techniques I’ve seen successfully applied to software development. The first is automated testing and the second is kanban. Automated testing is about using separate software to  continually run tests on the software as it is being developed rather than batch all testing at the end of development. This is the equivalent of an andon system for software development. A separate program runs the program being tested, feeding inputs and checking outputs against expected results. Automated testing is hard to introduce in the development department: developers have to be trained, management has to insist they take the time to do it, and legacy code is always an intractable issue, but the benefits are considerable both in terms of product robustness, and time and money savings. A further benefit is that engineers improve their coding skills as they  by writing  test programs before  developing the product code.  This  can be an entry point for setting coding standards – although I have yet to see a company succeeding on that front.

The second lean practice for IT is kanban – yes, kanban. In a software factory, kanban is actually quite simple and brutal. You set up a board with five columns:

New project

Analysis

Development

Testing

Customer OK

Validated learning

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Then you create on a number of lines corresponding to how many projects you believe your team can develop in parallel. As Karen Martin points out in her insightful book The Outstanding Organization “switchtasking” from one task to the next takes an average of 25% to 50% longer. Worse, without the discipline of finishing ongoing projects before starting new ones, it’s easy to completely boggle the process at one stage and work very hard without ever delivering.

Should you be interested, much about kanban in IT settings can be learned in David Anderson’s seminal book kanban. From personal experience, I insist on adding a further column after the customer’s sign-off of the project: are we sure the software is doing what the customer wanted it to do. At this stage, the customer has agreed that the software is up to specs – no worries. But we’ve discovered on the Gemba that this doesn’t mean the customer is happy with it. Particularly when you’re trying to integrate mechanical and electronic components, lots of tricky things happen, and very often the engineers are unclear in their demands on the development team. As long as the software team sticks to “delivering the specs” works gets done, but everybody is frustrated: product engineers are never happy, coders feel underappreciated. The key is to realize how different the coding and designing worlds are and focus special efforts on understanding each other. The “validated learning” (not to use the Toyota-ese term “hansei”) is about making a genuine effort to find out if the software actually satisfies the engineer, rather than simply make do.

Could your IT department benefit from lean thinking? Certainly. I remember coming across an HBR article last year (Why your IT project may be riskier than you think) listing companies that went into bankruptcy because of failed IT projects the paper described as “black swans”:  world changing events that are rare and unpredictable but, with hindsight, not so unlikely. From any one’s experience of IT, lean should help – but I’m not sure that’s the priority compared to leaning the main value flow. After all, IT remains a support activity, and one of the tricks of lean is to go all in “must do, can’t fail” in Karen Martin’s terms, and get right customer value activities before worrying about the rest. Rather than go for lean transformation, I’d focus on key practices such as:1) working harder at understanding what customers need rather than what they ask for, 2) systematizing automated testing and 3) using kanban to level and manage development projects. It might sound like a humble scope but I truly believe that core practices can leverage large benefits if management sees the scope for improvement opened up by kaizen.

Do lean-minded finance professionals make a difference in appraising lean initiatives from other investments in their companies?

October 19, 2012
Back to top

Dear Gemba Coach

Good webinar, thank you. I would like to ask lean-minded fellow finance professionals if they make a difference in appraising lean initiatives from other investments in their companies,  e.g. different project and investment appraisal techniques, hurdle rates, etc.?

That’s an interesting question and I’ve been thinking about it -- but not sure I’ve come across many such cases at the Gemba. I’ve been in debates when there was a clear choice between purchasing more equipment --typically, injection presses -- to alleviate bottlenecks. Upon further investigation, it was shown that the existing presses were poorly utilized, as we discussed in the Q&A during the webinar on building the business case for lean. This actually occurs quite often. In this case the choice is between (a) buying more kit and (b) investing in TPM and SMED workshops to get more out of the equipment we already have.

In this case, yes, there is an appreciation difference, particularly with companies new at lean. If I buy an extra press, this comes out as an investment which will increase my balance sheet and that I can depreciate. This seems to be a no--lose scenario as my company is now “worth” more and the cost is “minimized” through the depreciation calculation (I have to confess I never got my mind around it). Now, from a cash is reality point of view, this is pure nonsense, and indeed can even become a “black swan”. I have personally seen two companies driven to bankruptcy because they bought cheap a lot of equipment (from other companies going down) they didn’t need and couldn’t use, and then could not recover from the cash drain. So, a black swan: an event with a catastrophic impact that wasn’t predicted at the time but, in hindsight, is perfectly understandable. Humans seem to have a blind spot for that, and as lean guys, committed to respecting the fact that humans are, well, humans, we need to keep an eye out for that.

Vanity, Sanity, Reality

On the other hand,  investing in SMED and TPM, which means investing in developing your people, you’re not buying anything that can go on the balance sheet, so it’s a straight cost. Worse, it’s a cost that can lead to a reduction of inventory which will both reduce the balance sheet AND impact negatively the profit in the early phases. Of, course, from a lean point of view, you’re doing great by considering your people are your most important assets and investing in them, and by strengthening the cash position of the company is better use of existing equipment and inventory reduction, but it might not play like this in the numbers. Again, sales are vanity, profit is sanity, but cash is reality.

Your question, however, raises a more troubling issue. I’ve discussed this with one of my senseis, Orry Fiume, who was CFO of Wiremold at the time of its lean transformation Jim Womack and Dan Jones described in Lean Thinking. He points out that the question assumes lean is seen as one tactic out of many, not a fundamental strategy for the business. His point is that once you understand lean as a strategy you realize that it affects everything the organization does.  There is no such thing as investments in "lean initiatives" and "other investments."  Every investment needs to first be assessed as to how it supports the Lean Strategy. That question is not a financial one but a strategic one.   And if the answer is "it doesn't" then why do it?  If it does and you are faced with multiple investment opportunities choose the ones that move the strategy forward the fastest.

Which is, I guess the whole point of the webinar, and what we’ll be discussing in the workshop on Nov 6, 2012: how to build a strategy around lean concepts:

  • What is our growth engine?
  • How do we build the cash machine?
  • Can the growth engine and the cash machine be sustainably profitable?
  • How do we squeeze capital expenditure to right size it?
  • How do we use the lean “learning to learn” system to develop every employee in the company?

Reconciling Lean and Lucre

Now, Art Byrne, who was Orry’s CEO at Wiremold, writes fun pages in his book Lean Turnaround about how he had to twist Orry’s arm to participate in a first kaizen event. As a traditional CFO at the time, Orry didn’t see how shop-floor activities could possibly be a good use of his time. He even meticulously recorded all the costs items of the event! Orry came out of his first Gemba kaizen transformed and went on to not only support lean as a strategy, but to change the way financial information was presented in order to support the lean strategy. Orry is co-author of Real Numbers and a founder of the lean accounting movement.

In lean thinking, the test method is essential to the design of options, so having a debate about “investment” is going to be judged is absolutely spot on. Personally, I whole-heartedly agree with Orry, when the company starts making noises such as “how can I justify back training people or conducting improvement workshops?” I usually just stop talking to them. When I still thought I could convince them, I tried to argue we should first get a local gain from every workshop, and then multiply that gain to every similar cell to get a feel for the opportunity potential, but I fear this is a fight I now walk away from.

Which is wrong. The question your asking is absolutely the kind of questions we should be discussing and debating within the lean movement, and thank you for asking it. I currently know of no obvious way to get senior managers to see beyond the tactical potential of lean, but we need to keep discussing this until new ideas appear and new voices are heard. One thing I’m certain of is that until we can reconcile Gemba-level lean and making-the-numbers attitude, the full potential of lean will remain untapped.

Why do we need to discuss making the business case for lean?

September 28, 2012
Back to top

Dear Gemba Coach,

I saw the invitation to your October 10 webinar on Making the Business Case for Lean.  I wonder why we even need such a discussion. Isn’t making the business case a fundamental competency for any manager or executive leading a lean transformation? Why do you even need to discuss it?

Granted, maybe the term “ROI” is not the best choice – I’ll try to clarify what I see on the Gemba and what I have in mind. I was talking to a group last week about “lean strategy deployment” (the topic of Pascal Dennis’ great Getting the Right Things Done) and it was obvious the group was confused about whether we were discussing deploying a lean strategy (e.g. a strategy crafted with lean thinking) or a strategy for deploying lean (e.g. deploying a lean program). The distinction is not trivial.

Many companies that I know have a traditional strategy; and they also try to deploy lean tools. Or the other way around. I was graciously invited to visit the Porsche plant in Stuttgart early on this week, and fear I may have irritated my guests by suggesting they were deploying a lean strategy in a non-lean way. I observed that they were doing tremendous lean work on reducing work content for every car, but there was little sign of Gemba activity on the line (kaizen happened in meeting rooms, they explained).

In any case, at the end of the strategy deployment talk, a lady shared her experience with lean. She’d been a lean officer for a large American company, had fully invested herself in the lean effort and believed she really understood what lean was all about. And yet management still closed the plant. Now, I’ve not come across this company’s lean work, so I have no opinion on how “lean” it is. But I know a number of lean consultants who chose to do so after something similar happened to them. The question to be asked is why do plants that make lean headway and realize savings still get shut down?

Don’t Show Me the Money

I believe that framing this issue as one of savings dooms one to lose the argument in the first place. Any lean officer worth his or her salt knows how to calculate savings, but the issue is that savings – no matter how large - are simply not that convincing to senior management. One of the best plant manager/production manager teams I know has continuously lean-ed its plant and delivered a 3% to 4% transfer price reduction per year every year for the many years I’ve known them, while improving their contribution margin and reducing inventory, most of it through operator driven shop floor kaizen activities and engineering involvement in kaizen. How lean can one get? Apparently not enough:  when the plant manager retired this summer, corporate, in its wisdom, named the plant’s financial controller plant manager over the head of the production manager. The savings alone were just not that convincing (or else we’d have to assume that savings are produced by finance?).

The retired CEO of another company I know has been just as frustrated by the failure of others to see lean strategy as more than savings. He got into lean because of a large world-wide lean program pushed by the holding company with a top-notch consultancy. They ran 14 16-week projects with an internal lean team to aggressively attack cost and then … simply stopped. The savings were impressive, the management team agreed, but the projects were not helping them solve their company’s deep challenges. They feared they were damaging the common trust relationship they had worked hard at building up with their workers.

In the end, they didn’t abandon lean, but switched to the orthodox method of working on the Gemba with a sensei and started pulling their factory with short, operator-focused kaizen events to solve spot ergonomics, quality and productivity issues that appeared as the water was reduced in the lake. Five years later, even though the CEO retired when the company was taken over by a U.S. competitor, the three plants are still continuously evolving, still improving workstations, fixing quality issues and reducing it’s supply chain lead-time. The point is the CEO himself says that the savings, even with big numbers, simply didn’t convince any one on the leadership team they should change their way of thinking.

This is what the webinar and follow-up workshop will address: lean officers generally know how to calculate “savings” (although how do you calculate savings from 5S?), but although the ROI of such programs (savings versus the cost of the lean activities) might be good, top management seldom jumps up saying “I must understand this lean stuff, and start devising a lean strategy for my company.” And yet that is precisely what is needed for lean to become transformative. The French car OEM PSA has had huge lean programs both in manufacturing and engineering, but it’s still shutting down its large historical plant in Aulnay – whilst Toyota in Valenciennes (same country, same labor rate, same culture) is investing in increasing capacity. There is our real challenge.

The CEO’s Perspective

So how come savings are not convincing? I’ve been discussing the issue with CEOs for the best part of a decade and what they tell me is that:

  • Savings may look impressive, but it’s often hard to see the impact on the bottom line – so many other factors and events occur in a company, that lean efforts, even when successful, tend to get lost in the noise. I look monthly at the business results and operational indicators of several companies I coach, and it takes us three to four years to get a feel for the cross impact of events versus internal factors on the numbers shifting up or down.
  • Savings are not that believable. I just had a case of this when a business unit manager presented to his CEO a cost reduction of 6 to 11 percent across product lines, and the CEO just looked at him doubtfully – “are these real numbers?” he asked. I’ve seen what the guys do at the shop floor level, so I tend to believe the BU manager, but still, I can see the problem. The CEO was not involved in any of the initiatives himself, has not theory to explain the cost reduction, and just can’t get his mind around the numbers – they don’t fit with his worldview of the business, and can’t be explained through traditional financial control.
  • Savings are rarely sustained. I mean swear to me that as you return to the Gemba a few weeks after a workshop, you’re not holding your breath wondering whether any signs of the improvement will still be there.

 Two Approaches Explained

My basic argument is that as long as lean thinking is not adopted by management and as long as it keeps being driven by a staff group of lean specialists, it can’t be transformative no matter how impressive the savings shown on the PowerPoint. I may be extreme here, but I do believe that as long as the lean initiative is a staff-driven program, it’s not much different from a classic Taylorist program with lean labels - and I’m not dissing that, it can still deliver 3% to 4% compound productivity, but it’s not transformative. To be transformative, lean thinking has to be taken up by the CEO himself or herself and then driven through the line to transform the people. I’m not claiming any originality in this – it’s how I’ve been taught by my father who was an automotive supplier CEO and what other CEOs say, such as Wiremold’s Art Byrne in his wonderful book The Lean Turnaround.

I’m not claiming either there is no place for a small staff lean office – of course there is, as lean expertise is essential to support line manager’s efforts at kaizen and teach them how to use the tools correctly. But the drive should come from the top through the line in order to not just change shop floor practice according to lean policies, but to change policies according to the discoveries occurring in kaizen events. As John Shook splendidly put it, lean is about learning to learn.

I understand that some people might be upset by this message, and I think it’s great if we can have some controversy back in the debate to stir things up. I’m not claiming any universal answers, I’ll just bear witness to the work I see in companies I know in order to compare experiences with participants. In the webinar and workshop, I’m essentially going to distinguish a savings “ROI” approach to lean and a company-value, financial (sales, cash, EBIT and capital expenditure) approach to lean transformation. I hope you’ll all enjoy the talk, and more importantly, all disagreements are more than welcome!

 

(Learn more about the business case for lean at a  free webinar on October 10, 2012, and in-depth at the full-day workshop on November 6. –Ed.)

 

 

 

 

How Do the Problems of Continuous Improvement Professionals Differ from Those of Line Managers

September 7, 2012
Back to top

Dear Gemba Coach,

How do the lean-related problems or responsibilities of ci professionals differ from those of line managers or business unit managers?

That is a profound question that links back to one of the fundamental differences between lean and traditional management. The difficulty here is one of unspoken management assumptions, and hence hard to tackle precisely because they are not in the conversation to start with. I’ve addressed this issue before, so please bear with me as I try a different tack.

One underlying point here is how we understand “science” – yes, yes, I know, it sounds far fetched, but still, here it is. Taylor didn’t call his method to improve productivity taylorism, he called it “scientific management”. He analyzed and synthesized workflows (sound familiar?) in order to come up with the “one best way” that would then be applied by the workers. His approach of science was indeed empirical, as he studied the most effective workers, but what he sought was answers. Seeking answers from empirical research reflects the thinking framework of a Newtonian, pre-relativistic vision of science. In Taylor’s days, the universe was a huge machine that scientific research would uncover piece by piece, until the full works would be mapped and revealed in its full glory.

Consequently, mainstream management, developed on Taylorist principles thanks to Ford, GM, Bell and so on during the 1930s, has staff people (such as ci professionals in our modern terms) come up with answers which will then be taught (or forced) upon the line workers. In this representation of the enterprise, a senior manager delegates his or her productivity problem in two ways: first they task their staff specialists to figure out the most productive way to work and they task their line management to apply these most efficient processes. They don’t need to get into the details because they’ve delegated research into productivity to staff teams and they’ve delegated execution to line teams. I’m not knocking it, mind you, as this has given us (according to Peter Drucker) 3% compound productivity per year since Taylor’s days, but we can all see the current drawbacks in terms of huge waste.

Oddly enough, the original lean thinkers within Toyota also thought of their Toyota Production System as the application of scientific thinking to production. But we’re talking a different vision of science by then, one that values the questions more than the answers. In our current understanding of what science is, regardless of what pop magazines keep flogging, the role of scientists is to focus on the right questions – where answers are seen as gateways to new questions. Here’s how it works.

Improvement to measurement devices, usually because people are trying to answer an existing question more precisely, generates more questions. The difference between 99.5% and 99.9% right first time seems pretty tenuous, but if your measurement system is more precise, 5,000 ppm. is rather different from 1,000 ppm., and the boundaries now not so clear. The questions arising by trying to understand the gap between 1,000 ppm. and 5,000 ppm. will be very, very different than those from the gap between 99% OK and 100% OK. More precise instruments often lead to some serendipitous discoveries. For instance, say you’re making concrete walls for construction. Concrete walls typically require rework to hide the bubbles in the concrete. The question asked by lean thinking is: why the rework? There are many factors: the vibration of liquid concrete (where it occurs in the wall, and at what time of the day – when the guys are close to finish, they typically go faster, which creates bubbling), or the mix of stones and sand in the concrete mash and so on. This will lead you to formulate your theory of making right-first-time concrete, and only open up more questions, which then need more precise measurement: how do we measure vibration speed? How do we measure stones and san mix? At each stage the answers could be rigidified as a procedure, but that would also lock us into a quality level. Continuous improvement is about asking further and further questions. On the Gemba, there are two types of questions:

  1. What happens when we try to be more precise – add a decimal point to whatever our measurement currently is? Whenever we do this we realize that our mastery of the process needs refining.
  2. Do we correctly understand the physical fundamentals of the task? Whenever we ask this question we often discover how fuzzy our mental models are in the core understanding of what the process does.

Lean tradition is all about loving the questions, more than the answers themselves. Answers are opportunities for more questions. This can be frustrating when you’re an operational guy with deadlines and objectives and just trying to get through the day, but it touches rather fundamental assumptions about human beings. We’ll all agree that quality work depends on how much attention is paid to the task at hand. The closer the attention, the greater the quality. Conversely, loose attention usually causes sloppy work. There are two widely differing theories of how to support attention:

  1. Incentives: basically the carrot-and-stick approach of rewarding people for keeping focused and producing good work, and punishing them (or at least, blaming them) for not paying enough attention and performing unsatisfactorily.
  2. Questions: challenging people with specific questions about how to solve small or large problems in how they do their work keeps them interested in the work and focused on details, and their success as they progress on these challenges is motivating and compensates for the drudgery of day to day work.

This is not to say that recognition and rewards don’t matter, of course – everyone needs both sources of motivation. What lean practice has achieved is hit upon a source of intrinsic motivation. Forgive the jargon, but for half a century now social science has showed that extrinsic motivators (pay, status, etc.) has the main drawback of reducing the person’s interest on the task at hand and needs to be constantly fueled by more carrot (or more stick).

Since the 1960s companies and researchers alike have been searching for sources of intrinsic motivation – people driven by the enjoyment of the task itself, not the rewards the task brings – but although this sort of motivation is very obvious in some cases such as sports, science, start-ups, etc. it’s usually very hard to reproduce at an organizational level. Lean’s practice focus on question has two effects: first, people accept the need for standards and subscribe to them rather than fight them, since standards “clean the window” and remove many variables from the situation at hand, and secondly by focusing on kaizen, they naturally perform better on the task at hand. In order to keep fueling this form of motivation the issue is to keep supplying people with interesting kaizen projects, and to recognize and reward kaizen efforts as well as overall performance.

Through questions, lean management shows respect-for-humanity: respect for the profound need for autonomy and involvement in the organization of our own workplaces as well as the reality of the joy of creation. People are not just carrot-and-stick robots to command and control: they matter.

This distinction is at the heart of the understanding of staff versus line roles:

 

Staff

Line

Taylorist

Gives answers and makes line apply them

Ask questions about applicability to local conditions and gets on with so-so work

Lean

Ask questions and helps with the problem solving process (PDCA)

Finds local answers and proves the validity of answers by showing improved performance

In the lean perspective, the continuous improvement staff role is very different from their line counterpart’s role. It’s hard to keep to the discipline, mostly because of the pressures of business and every one’s deep taylorist conditioning, but in ideal conditions CI officers are barred from bringing direct answers (explaining general principles is fair game). Their role is to:

  1. Master the investigation (kaizen) tools and teach them to line people so that they can themselves understand their own problems. This is like really understanding how to build a microscope (such as SMED, 5S, 4M etc.) and teach the doctor how to use it, so that the doctors understand the bacteria they’re looking at by themselves, not by reading a report.
  2. Master the general principles of lean in order to explain what kind of countermeasures we look for and what kind we need to avoid according to higher level challenges and principles.
  3. Spur an on-going flow of questions through the organization of Gemba visits, learning events and so on. Questions are motivating, but they’re also tough to face in high pressured environments, and the CI officer’s role is to keep challenging operations with the right questions to make line people progress.

Line’s role is completely different in terms of mastering standards and using the kaizen tools (taught by CI officers) to find their own local answers to the questions, and integrate these answers on their existing standards. Line managers have to manage teams and develop them in better using their work environments. This means:

  1. Making sure safety procedures are applied
  2. Achieving performance objectives
  3. Creating the proper conditions to achieve performance objectives by using 5S and TPM tools
  4. Developing work standards and training employees one by one to make sure they can perform at their job
  5. Supporting kaizen efforts (workshops, suggestions, problem-solving)
  6. Solving individual problems and taking care of team spirit

In an ideal world, line managers should be autonomous in asking the questions themselves, but this is often wishful thinking. In real life, operational managers are often beset by problems and pressures and just want to get the job done. Getting the job done by working correctly to standards is already a tall order and a great step forward for the company. Experience shows that mastery of standards is linked to kaizen efforts (in order to understand the why and wherefore of the standards). But it’s a lot to ask for a line manager to keep on exploring new questions, particularly when these don’t have any operational answers.

This is the essential (and often ingrate) role of a good CI officer. Back at the Gemba I know an automotive company currently being squeezed by terrible market conditions, customer pressure, technology shift and financial management. The CI relentlessly uses the lean tools to uncover huger wastes that were hidden by good results in the previous good times. He is rarely thanked for his efforts as most of the problems his questioning reveal are scary-huge, often deeply ingrained in the make-up of the company and have no immediate solutions. For managers busy paddling hard just to stay afloat every day, this is not always welcome. Nonetheless, though his persistence and patience, the company is improving and slowly solving its own problems. The previous CI officer, contrarily, had all the answers and kept hammering this in every one’s throats with little success – and kept complaining no one was listening.

Without a good CI officer, companies doing well get complacent and those doing poorly tend to stay locked in their mistakes. To answer the question specifically, the Continuous Officer’s role is to ask the most insightful questions through the most precise analysis tools, and then check that the kaizen move in the right direction whereas the line manager’s role it to strive to reach daily objectives by creating the right material and team conditions, and striving to answer the questions with his teams by experimenting on the job. In the poet’s words, the key to being a great CI officer is to learn to love the questions themselves.

 

How Should We Relate Lean Projects to KPIs in a Large Company?

July 26, 2012
Back to top

Dear Gemba Coach,

I am working as a lean expert in a European multi-national with more than 25 manufacturing sites worldwide. We have started a continuous improvement process with dedicated lean experts at each site. Until now our focus was on lean training. We link projects to a site impact-priority matrix. Management wants the improvements projects to be linked to key performance indicators (KPIs) such as on-time delivery and cost of quality. And they want these KPIs identified, and that we report our progress on how the projects are impacting these KPIs on a monthly basis. Could you guide me on how this can be done?

Tough question, but it can be done. I know a CEO who is an experienced hand at lean turnaround and had worked with a sensei for many years before—but his experience should give you hope.

So how do we do it? First, let’s take a step back and think about lean programs in large, geographically dispersed companies. Let’s be clear about recognizing that broader goals at every level will have components of explicit business results, as well as organizational capabilities.

I believe that the core lesson of Toyota is to shift from JOB = WORK to JOB = WORK + KAIZEN. In other words, everyone, from the CEO to the operator, must factor in the education aspect (learning) of any job as well as the execution part (getting the job done. People at different levels will have a different mix of emphasis. At the CEO level, the lean job is mostly education (with some execution for Very Big Decisions). At the operator end, it’s mostly execution with some education (dojo training to standardized WORK and participation to KAIZEN events). The following chart might help:

Middle managers have the toughest challenge with this complex mix. Their responsibility in terms of lean means taking care of both the education system and the execution system. The big risk is to follow the path of least resistance and treat the lean program purely as an execution system, whereas it clearly is an education one.

How to Start

How did the CEO I mentioned handle this challenge? Let’s start with the execution system. The CEO started by defining five operational indicators that related directly to his P&L challenges (the following are an illustration, and not exactly how the company defined its KPIs, but close enough):

  • Accidents: he believed strongly that people don’t come to WORK to get hurt and was his first priority (every accident across the world is reported to him immediately)
  • Customer complaints: which reflected how customers felt about the product, and was a strong lever of sales
  • On-time-delivery:  to measure service to customers, and again a strong lever of sales
  • Days of inventory: a direct measure of cash
  • Productivity: measured as direct heads per site. There is no really good measure of productivity, so the assumption was that each site had a more or less stable volume and that reducing the direct headcount while improving OTD should mean productivity improvement

On a monthly basis, the head of the lean program would track the historical evolution on each of these indicators against a target curve of reducing by half in eighteen months.

The important point on the execution front is that each plant manager was held directly accountable for the improvement of the plants according to these indicators, whether he or she chose to do lean or not. Every month, the lean office produced Pareto charts corresponding to each showing how plants stood respective to each other on the operational performance.

On the education front, the group lean manager created standard KAIZEN workshops corresponding to each indicator:

  • Safety risk analysis (accidents)
  • Quick response quality control from firewalls and red bins (customer complaints)
  • Production plan leveling (OTD)
  • Pull system and SMED (days of inventory)
  • Single-piece-flow layout (productivity)

Each plant has a dedicated, full-time lean manager whose job was to run a program of workshops, at the steady rhythm of one workshop per month (some did more, some did less). The key aspect of the lean manager’s role was that he or she was in no way held accountable for the results on any indicator – this was clearly the plant’s management responsibility. The lean manager’s job was to run enough workshops (and run them well) to educate plant staff to WORK with operators to achieve the required results.

The trick here is to make sure that the “lean managers” are not implicitly tasked with getting results: their job is education, and they should be good at this, but that’s as far as it goes. Plant managers must achieve results.

The CEO reinforced this by making a commitment to visit every plant (about thirty across five continents) at least once a year. During these Gemba visits, the CEO asked the plant manager (and not the lean manager) to show progress. Making sure the program of training was on track in the plant was the job of the Group lean manager, not the concern of the CEO.

Gemba Walking

The other specificity of this program was the CEO’s personal interest in what happened at operator level. During his plant visits, he would walk the Gemba and ask to see how the operators were affected by the changes and how involved they were with the improvement actions.

On the other hand, the group stopped all classroom lean training. No one was expected to “talk lean” or to know about lean. Education occurred hands on, through the KAIZEN workshops, and the plants had to solve specific problems to improve the indicators. Through their Gemba visits with the CEO’s sensei, the CEO and the Group lean manager established a list of key generic problems/generic solutions, which were progressively spread across the board.

Not all plants had results. A few never moved at all. A few showed spectacular improvements. But overall, the entire group of plants started moving, proving once more that lean results are obtained by the dynamic of lean, not simply “respecting standards” in a rigid way. The company went through two eighteen months cycles and was sold as it was beginning its third.

If I reflect back on this experience, I would say that you’re moving in the right direction, but beware of doing so without a sensei. Your CEO needs to understand why taking cost of quality as an indicator is a bad mistake as opposed to customer complaints (sales) and ppm (EBIT).

Remember that lean is a practice, not a theory and much lean know-how takes shape in the form of passing on a lean tradition from sensei to deshi. So, with so much at stake, it’s well worth finding a sensei that can help you clarify the high-level principles as well as guide you in the nuts-and-bolts specifics. If your CEO is not personally driving your efforts on the shop floor, it’s unlikely that a more KPI-focused program will have better results than the previous one.

 

Are Lean Managers Teaching Or Just Controlling?

July 18, 2012
Back to top

Dear Gemba Coach,

I hear what you lean guys are saying about, learning, “kata” and the role of managers as teachers. But in my years at Toyota I was never taught much. I learned a lot, but what my manager would mostly do is check the details of what I did and ask a lot of questions. I felt that it was very controlling.

Thank you for your remark, which certainly echoes what other people who have worked for Toyota comment on. Not having worked there myself, I have no definite idea on how much control is involved in Toyota’s management culture, but, from the outside, I do suspect it’s quite an important component. Let me try to respond to your thought by investigating the relationship between teaching and controlling.

Let’s say that at the Gemba, performance is the outcome of the “best” process being performed by the “best” people. Since nothing is ever perfect, the “best” process is sought by constant kaizen, and the “best” people are developed by on-going training. The virtuous circle sought by lean management is that on-the-job training fosters ideas for kaizen and process improvement, and kaizen efforts are key to learning and individual progress in understanding the nuances of the job and how to hone one’s skills. (The opposite is a vicious circle in which a lousy rigid process punishes and demotivates people, so they do their job badly which, in turn, worsens the process further and so on).

The central point is that performance is the outcome of a dynamic relationship between performing the job as best we know and improving the process. The best process in the world won’t deliver the results if the people aren’t skilled enough to handle it, and the best in class people can’t succeed in a broken process. You need both.

Everyone Matters

Let’s reflect more on the training aspect of this dynamic relationship. Most of our mental images about teaching are from our memories of school or the experience we have teaching our own kids: lessons have to be learned. Kids are supposed to “learn” as their full-time job and play the rest of the time. They don’t work, as we do, at repetitive actions that need to be executed for a specific result. They’re also a lot more tolerant and less set in their ways than adults.

Adults, on the other hand, typically have a job in which they need to successfully carry out a task, very often a repetitive one – even though maybe, being an operator on a production line is rather extreme in that respect. But your executive assistant (should you have one) will need to repetitively organize your diary, deal with people seeking to talk to you, organize your travelling, open the mail that gets to your office, plus all sorts of added ad hoc tasks. Even as an executive, succeed for the company as a whole to perform. Indeed, a key aspect of “respect” in the lean sense is recognizing that every single person in the company matters and contributes to overall performance. But where is the learning in that?

Contrarily to common wisdom adults can learn, will learn, and also enjoy it – but adult learning is very different from kids’ learning. Adults have a solid baggage of experience, busy lives with little time to spare, and, yes, admittedly, less flexible minds. Where do we start?

Start Here

First, what do adults learn? Adult learning is goal-oriented. Adults find it extremely hard to pick up an entirely new skill, and they seldom succeed at it (as my woeful attempts to pick up the guitar in middle-age have shown). On the other hand, adults will focus on a specific skill that they feel can help their job, and try hard to improve that – and even enjoy it. Consequently, as a manager, if you want your staff to learn on the job, you need somehow to define the purpose – the goal of the learning effort. Failing that, they’ll choose what they individually feel they’d like to learn, which is rarely what they need to learn. If you’re not aligned on this, much unfortunate misunderstandings and conflicts will later arise.

I was recently visiting an engineering department where the department head wanted to teach a younger engineer how to anticipate plastic deformation in the molding process (something to do with calculating the differential shrinkage in the cooling process). The engineer wanted to learn new functionalities in the design software. This conversation was not going well.

A lean approach to managing and teaching would have helped. The lean way to align intentions is to define with the staff an indicator that reflects the purpose of the job we’re trying to do as best as possible. This is never easy and should not be taken for granted. For example, counting customer complaints is not the same as counting bad parts at final inspection. Counting customer complaints is about learning to respond better to customer’s dissatisfaction, whereas counting rejects at final inspection is about improving the process’ right-first-time capability. Both are linked, of course, and both are most likely necessary, but the intent, and therefore the learning goal are very different. In the previous case, the engineering supervisor had not worked out with the engineer a specific target of scrapped parts for the project, and was having a hard time grabbing the guy’s attention.

Now, adults legitimately are interested in what they’re interested in: you can’t pick for them what should interest them, and chances are they’ll be interested in very different things from what you’d like them to be. As a result, frequent discussions about the indicator you’ve picked, how it behaves, why, and what people are doing about it are key to foster interest. Yes, this is certainly controlling behavior, and it can easily backfire if you fail to align their interests with yours. But, ultimately, sharing purpose is about constantly repeating the conversation about “How are customer complaints?” “What is the OTD?” “Are we reducing lead-time?” and so on. This will never be “acquired,” or “ingrained,” or “become part of the culture.” It’s a conversation that needs to happen, always.

When Practice Doesn’t Make Perfect

Second, how do adults learn? Mostly by practice. Practice, however does not mean mindlessly repeating the same task until you get it right. Practice means having a clear idea of the right outcome versus all the wrong ways of doing the job first. And secondly, having an understanding of what you’re trying to do in order to steer the practical action towards the desired result.

Learning occurs through the process of shuttling between abstract thinking (the toolkit of rules that can be applied in new situations) and data mining (dredging detailed information from our vast store of specific knowledge). As we grow older, we get worse at remembering all the details, but we get much better at seeing and using patterns. Essentially, learning comes from modeling a situation time and time again until the back-and-forth toggle between principle and specific generate new insight/competencies (both appear together).

Practice, as such, is hard to do without someone who micro-corrects the activity towards the relevant detail of where something goes wrong. On their own, people can repeat the same activity for years, stumbling on the very same problem without seeing the relevant detail. This is why musicians or athletes keep getting coaching even though they’re at the top of their game. The coach’s role is both to correct the micro-step (pull your wrist in) and to steer discussions on the high-level rules (hold a mental image of the chi flowing through the universe). This, again, is very controlling.

The engineering department head was trying to go through his junior’s calculation and point out hidden assumptions. The younger engineer felt he was being picked on unfairly and was so busy brewing internally, he wasn’t hearing anything much.

You Are a Role Model

Which leads us to the third question: why do people learn? Teaching through practice is in fact very controlling. This is tricky because, in order to learn, people also need to feel their efforts are self-directed and that they can learn in their own way at their own pace, for their own reasons.

Acquiring practice requires both drive and determination. You have to want to put yourself through a regimen of repeated attempts and constant criticism from your teacher. Why would you do that to yourself? And at work on top of it? The third component here is role modeling. In a work environment, in order to put up with the controlling dimension of teaching, employees need to accept (consciously or not) their manager as a role model. This is not an unrealistic expectation as most people compare themselves with the reference group of others who occupy the role to which they aspire, and so it’s not unrealistic to expect employees to look up to their manager for guidance in values and behavior. The difficulty is to translate this into acceptance of narrow teaching on specific skills.

In order to create the conditions for adult learning, the manager must ask himself or herself why his or her staff would accept detailed corrections about how they do things. In the case I was witnessing today, the young engineer clearly – rightly or wrongly (I don’t know them well enough to have an opinion) didn’t look up to his manager. As a result, he was simply being subservient in the conversation, and not taking much in: he wasn’t learning.

The lean management framework attempts to address this difficulty by stating explicitly that the frontline supervisor’s job is to give eight hours of standardized work to the team members. People are required to learn the standards, and, furthermore, the emphasis on work standards and kaizen creates a working environment where detailed investigation of work and confirmation is expected. But still, the question remains, what does it take for a manager to be accepted in this role by his subordinates. Technical competence? Empathy?

A Right to Succeed

Ultimately, acceptance hinges on intention. People will be tolerant of many faux pas if they are convinced that the manager truly means well and that he or she has the development of staff at heart, and is not simply squeezing the lemon to get all the juice. In the lean framework, this is the value that we try to convey through the various dimension of “respect”: every one counts, and every one has a right to succeed – which means that managers have to listen and work hard to take away all barriers to doing the job right (mainly muri, mura, and muda).

Ultimately, real teaching (as opposed to telling just so stories) is quite controlling: it’s about checking how the student is doing and then stopping and correcting him or her as they go so that they actually learn from their mistakes (saving it for the end of the process and dishing out all mistakes at once is a far less effective way of teaching). Furthermore, teaching also involves picking the topics people need to learn, not want to learn, which is controlling as well. In the end, the real difference is not the act of teaching or controlling itself, but how it’s perceived by the learner: is it for your benefit, or theirs?

Can Lean Boost Sales?

July 11, 2012
Back to top

Dear Gemba Coach,

Every one says that lean is not just about cost cutting. But I fail to see how lean techniques can influence the top line. How can lean help in this area?

I was on the Gemba yesterday in a service company that has recently lost several large contracts in a bruising competitive bidding process. We’re still trying to figure out how customers can expect the required service at the offered price and believe they will be disappointed with the purveyors they’ve chosen on price alone, but that’s what happens when purchasing gets the upper hand at your customers. So although there is hope these customers will come back, in the mean time there is a huge gap in the sales budget.

The company’s CEO immediately reacted by identifying a group of customers not targeted before. This company services large companies, and is now looking to interest smaller, more independent outfits. Half a year into the pivot, we were looking at the sales figures and although the company has succeeded in avoiding a loss, the sales numbers are not growing nearly as fast as needed to recapture lost gain. This is a classic situation for using lean techniques.

Lean Sales Strategy

First, the CEO asked the sales team to visualize on a large chart the budgeted sales for the month, and then visualize by blocks of types of customers. In this way, yesterday they were discussing the gaps between budget and actual (some are more, some are less) and the immediate reasons for this. It was an interesting moment for me, personally as I’d never been part of a discussion using lean tools directly in a sales environment before. And fascinating, because after the usual initial reticence (sales is different, not everything can be predicted, etc.) they started looking more deeply at what they where doing and asking why?

It’s true that lean techniques are mostly concerned with engineering, production, and supply chain management, and there has been little written about applying lean to sales and marketing. Yet I have no doubt that a case can be made that kaizen applies everywhere. None the less, lean is concerned with increasing sales and, to some extent, this goal takes precedence. Toyota did not become the world’s largest automaker by reducing costs alone. In a mature market, every car sold is a car taken from the competition. Toyota succeeded in becoming number one by steadily increasing sales and market share. The question is: what is the lean strategy to increases sales sustainably.

A lean sales strategy hinges on customer satisfaction. The aim is to make our product a standard in our customer’s household or business. Our product should be the one that all other brands are compared against, so that the decision to buy a competitor’s product should be questioned. Since repeat sales are generally easier to realize (i.e. cost less per sale) than acquiring new customers, the lean strategy is to make sure that anyone who buys one, will continue to buy. In effect, the worth of a customer in these terms can be computed as the dollar value of the product or service multiplied by the number of times the person is likely to purchase the same product in their life-time.

Forgetting the First Step

In the previous company case, the CEO also started a war room where two questions were posted on the wall:

  1. What is the key to winning the trust of small independent customers?
  2. What level of delivery could be done at the bidding price for the large customers?

As many experiments were conducted over the months since the contract loss, some answers started to emerge – for instance, it appears that independent customers are very sensitive to initial response time – the time it takes to give them an answer, not the time it takes to actually do the job, which clearly large customers are not. On the other front, the management team realized that as large customers had traditionally looked for always more service, the offer had been enriched with many side services which could probably be pared down for a stripped-to-bare-bones service.

In short, we were having a discussion about value. Specify value is the first principle of Lean Thinking, Jim Womack and Dan Jones’ cornerstone book that launched the lean movement. Yet, because this is hard to do, most practitioners skip that first principle and move on to flow: aha, this we can do! Yet, value is what it is all about, and what supports sales.

Making our product the standard for our customers relies on both manufacturing and engineering. Not surprisingly, one function that emerges strongly in a lean company is manufacturing engineering as the arbiter between engineering designs and manufacturing capability.

Total Worth

In manufacturing terms, customer trust is gained by:

  • Zero defects
  • 100% on time delivery
  • Regular price reduction or value increase (adding new features for the same price)
  • Show of good will in any after sales service;

Many industrial managers will complain of the cost of getting it right 100% for the customers, which can involve special transports, extra 100% quality inspections and more. However, if we measure the customer by his or her total worth, we see that the price of 100% right is not that high relative to the customer’s worth; and as long as we don’t slap ourselves on the wrist by paying for anything less than 100% right, we’ll never fix our problems.

Truly putting the customer first in manufacturing goes a long way towards making the product a standard in the customer’s environment. However, it won’t help much if the product is not designed fit-for-use.

Specifying value

How can we design products so that they become a standard for the customer? One way of looking at a product or service is that it solves a number of problems for the customer. As Marketing guru Ted Levitt once put it, “People don't buy a quarter-inch drill bit, they buy a quarter-inch hole.” One can therefore list the problems our product solves for the customer. A teapot will solve the problem of brewing the tea, solve the problem of letting the tea getting cold, and solve the problem of serving the tea. Many teapot designs don’t solve the problem of not burning yourself when you pick up the teapot and not spilling tea when you serve it.

In effect, the more problems you solve for the customer (including aesthetic sensibilities: a teapot can also solve the problem of looking decorative on the kitchen shelf), the greater the chances of creating a standard against which all other teapots will be compared. The temptation would them be to look at all the problems you can think of and try to solve them all at once, and thereby creating the “killer app” that is going to take all the market away.

The manufacturing side of the previous company had long focused on the value its products provided to its customers (the equipment being the basis for the service business). Being adept of lean thinking, the product business unit manager had first focused on customer quality and complaints. After cleaning up an impressive list of issues (and doubling sales in the process) the fundamental questions started to be addressed: what value the product truly provides to the customers? In the end, the team more-or-less settled on the idea that beyond all bells and whistles, the product delivered measurement and distribution. Kind of like saying that what makes a great car is essentially the engine and the gearbox (of course, you need the rest but that is where the customer difference lies). So, in the end, value was specified as measure, distribution, and cost of ownership.

The upshot is that the engineering team then focused on improving the measurement system to a point well beyond current market specs – which, once successful (difficult project, lots of mishaps, took too long, and so on), delivered a spectacular increase in sales. Over the entire period from (1) fixing quality issues relentlessly and (2) improving the “core” function, market share almost doubled in a mature, saturated market. The fascinating part from a lean point of view is that customers had never asked for this improvement. Marketing had not believed in its market impact until, grudgingly, it was impossible to deny after the fact. The gamble was made by engineers trying hard to figure out what customers really sought.

Delivering value

In the process of seeking value, the engineering team had to resist marketing’s call for the new product that would take all the market by having all the right features. The hard issue was to learn what exactly customers would buy as opposed to what they said they would (in cognitive terms, customer’s “espoused theory” is often very different from their “theory-in-use)

The lean approach is not about gambling all on the next brilliant product, but learning to narrow down value and deliver it. Rather than make a huge gamble on coming up with a new product that will solve all customer problems at once, we can commit to a new product release at regular intervals – say a product renewal “takt time.” At each takt, we vow to solve more customer problems than were considered last time. In this way, we can progressively enrich the product – occasionally transforming it radically along the way (at some point, by solving point by point problems some “killer app idea might emerge.) In doing so we will progressively extend the list of problems the product solves for the customer but without ever making a huge intuitive leap into what the customer might want in the future;

This progression is consistent with the lean idea of innovation: solving today’s problems with tomorrow’s technology, rather than using today’s tech to try and solve tomorrow’s imagined problems. Furthermore, this approach to innovation also dovetails with manufacturing inasmuch as some problems we solve for the customer can have their root cause in our own manufacturing processes. Customer complaints are the most accurate source of potential value. By examining complaints at the customer’s Gemba and from the customer’s perspective, we can discover customer usages or preferences we had no idea about.

Question Product Strategy

In serious lean transformations, the first P&L line affected is sales. Delivering on time in full makes the backlog disappear (which increases sales mechanically) and halving customer complaints has a much quicker effect on reorder sales than people often anticipate. Cash is the second financial figure to show dramatic improvement as inventories go down (not at the expense of on-time-in-full delivery!). And finally costs come down as smarter solutions are found to sustain the lead-time reduction and eliminate waste.

The top line in the P&L continues to increase sustainably if customers start using our brand for all the similar products they use – they consider our product to be their standard. To do so, we have to constantly reduce the cost of ownership until the value-for-money ratio becomes unbeatable. Five out of ten vehicles Forbes estimates will make it past the 200,000 Miles are Toyota or Lexus (http://www.forbes.com/2010/12/08/most-reliable-cars-2010-business-autos-reliable-cars.html).

Not surprisingly, even in a year of horrid negative PR, three out of five Toyota and Lexus owners remain loyal to the brand when they buy a new vehicle, according to the J.D. Power and Associates Customer Retention Study released late last year. This is what fuels sales sustainably.

To achieve this we look at who we sell our products to predominantly, and we impose on ourselves a rhythm of product improvement by solving a few problems at a time for our customers. This might mean down to earth cleverness or dazzling (but validated) new technology. The point is that as we do that, the gaps with competitors increase because by the time they decide to catch up, they won’t have followed the same learning curve, and will have to pay for the increase performance or new features in hard cash.

Using lean to increase sales means taking a hard look at our product strategy and asking the question: “how can we improve products in order to sell far more to existing clients” rather than “What new product can I come up with to take the entire market?” The latter question involves working with both manufacturing and engineering to come up with a product that will establish itself as a standard for customers in terms of both conception and delivery. If you have no sales challenge for your lean effort, chances are you’re not putting customers first. In lean we expect sales to increase sustainably by building a basis for customers’ trust, and earning their loyalty – in terms of hard cash.

The challenge for the service operation is now to correctly specify the value of its offering. Surprising as it sounds, this is not an easy task and few companies are actually clear on this – yet it remains the first step of lean thinking.

How Can Our Back Office Sustain Lean?

July 3, 2012
Back to top

How Can Our Back Office Sustain Lean?

Dear Gemba Coach,

The improvement program at the back office of the bank at which I am a lean facilitator is slipping. For the past several years, we have improved operations by visualizing daily performance, conducting daily briefs and teaching team leaders to solve problems. We have progressed visibly in quality and productivity. Recently however I am finding our lean progress harder to sustain. Teams that were doing great slip back and we seem to have to constantly regain lost ground. Is there a way to make lean more sustainable?

There is, and it involves the question of whether you are pulling—but let’s spend a moment framing this challenge.

Sustainability is and will always be an issue in lean because of the human factor. We not constructing a mechanical organization that runs like Charlie Chaplin’s clockwork factory (and God help us if we were!); rather, we’re coaching a football team. And as any fan knows, a team’s performance is, by nature, hard to sustain over time, because it depends on the players, the coach, and the circumstances. The same types of challenges apply at the Gemba.

Our lean lenses can help us analyze this challenge with more rigor. Basically, we can identify three specific workplace diseases that produce waste and which eventually arrest lean progress. They are:

  1. No confirmation: a failure to understand clearly the purpose of the job you’re asked to do. People need to be able to confirm bad from good (as opposed to blindly follow procedures) and to have some autonomy to make smart calls in different conditions.
  2. Overburden: are you certain that workers are in good working conditions without having to deal with any unreasonable barriers such as too much work, too many interruptions, hard to handle software, unclear processes, arbitrary managers and so on?
  3. Unlevelness: every day chaos as work is done in fits and starts, long batches and last minute panics, too many procedural changes, and all the various forms of instability that stop one from getting a grip and thinking clearly.

The lean approach towards this is not to create the perfect process, but to strive constantly to improve the conditions of the working process. This is an important distinction. Performance is not delivered by designing and then tightly controlling the perfect organization (sorry to pop your Taylorist balloon), but by generating positive dynamics through engaging in daily problem solving. People will naturally function better as a team even individually when they are in the habit of working together to solve problems. Solving problems together stirs a pioneer spirit in even the most administrative back office where the main task is data copy, as well as the craftsman’s interest for the job, no matter how narrow and repetitive. The point is that people will be interested in what they do – whatever it is – if you keep them interested.

And there’s the rub: how can we develop the kaizen spirit in a sustainable, generative, continuous way? How can we keep back office teams solving problems together day in day out, when they’re sitting in a basement doing apparently pointless repetitive jobs, such as checking credit applications or routine IT maintenance tasks? Experience shows there are three key ingredients to keep the PDCA wheel turning:

  1. The manager’s attitude: time and time again we see that managers who are engaged with their workers produce greater lean success. If the frontline manager is genuinely interested in improving performance BY working with her teams to solve local problems and to involve every brain in the room in finding local knacks to make work easier, then people will continue to engage in problem solving and progress as a team. I’ve been visiting some companies for half a dozen years, and the lean teams that sustain success are always proud to show me how they’ve changed this or that to continue to improve their performance. And it comes down largely to whether the manager “gets it” or not.
  2. Improvements must benefit the team: in some cases, I’ve met with managers who do “get it”, but have failed to get their departments to accept that change is a normal part of the job. These guys work very hard at problem-solving, but experience recurring slip-backs and need to be re-motivated again regularly. At first, I believed naively there was some fault in them, that they lacked some kind of leadership trait I could not see. But then I realized it doesn’t have to do much with them as managers, but with their higher ups. In some organizations, workers are moved around all the time and/or the pressure for productivity is relentless. As a result, whatever improvement made on a local station won’t benefit the person who had the idea because either this worker is pulled somewhere else or management will take all the benefit and never give anything back.
  3. The team must also trust its own ability to solve problems. Some well-meaning managers solve all the “small issues” in order to focus the team on the large problems. This seldom ends well, as all the people learn from this is reliance on the manager. Motivation stems from success. In order to keep motivated, teams must regularly experience successes on their own terms. As a manager this means cherry picking problems so that they are both challenging (a bit) and solvable.

Unfortunately, many frontline bosses consider that their job is to tell people what to do when—and when. They use this limited power to (deliberately or not) reward the people they like with “plum” jobs and punish those they don’t with the nasty work no one likes. The problem is that nobody who works for these bosses cares about kaizen because it doesn’t change the fundamental unfairness of work.

Enter the pull system. Let’s go to a glamorous back office where people are supposed to check movie and TV production projects for approval for grants from a large foundation. At the Gemba, the work isn’t so glitzy: a team of people work in crowded offices making sure the administrative part of the folder is correct before passing it on to the decision makers. They are organized by “specialties” and are asked to track their response time. Since work comes in irregularly, when response time of one person increases beyond the three-week target, the head of the office is supposed to go and help this worker solve problems. This often comes down to giving that extra file to someone else. Some times it’s the last in the queue, some other times it’s the tricky case that we’d all like to get rid of. There is nothing particularly bad in the way this office works, nor anything especially surprising. There are files stacked all over the place, and frequent people dramas and breakdowns, which is surprising because the department head is a caring gentle soul who genuinely tries to help his staff.

One day, the department head switches to pull. He creates bins with three vertical slots and a central waiting queue. The idea is that files are opened by his assistant and put in the central stack, and from then on into one of the checker’s “three slot” bin when there is an empty slot. At first, they all argue against this because they are so specialized no one could possibly do each other’s job. So they have a working session to isolate the really specialized cases, but they quickly agree that it could be interesting to look at other files as well. In two weeks time, the inventory is down to zero (which is problematic because it shows there is one head too many) and the extra time is used to focus on many improvement projects that had been put on the side-burner for lack of time.

What happened? Pull system magic. The pull system takes away from the manager the decision of what to do, so that he or she can focus on how to do it.

In a back office situation, the pull system also evens out the workload between employees, which, it turns out, is a huge benefit to them. Evening out the workloads liberates time to solve problems, problems that are now highlighted by the pull system (when someone’s bin gets clogged up). People now see that solving problems will help them improve their performance, not some abstract group performance (careful there: we don’t measure individual performance, only team, but now every person can see their contribution to the team).

One further overburden issue is that, fairly often, the best worker gets the hardest cases – and so is “punished” in terms of performance for her competence. The pull system will highlight this and help people deal with the situation better.

Finally, the pull system creates a working environment with strong incentives for the manager to keep solving problems – if he or she doesn’t the situation will quickly revert to what it was before and every one will notice.

The earliest paper I’ve found on lean is a 1977 piece by Sugimori et al called Toyota production system and Kanban system materialization of just-in-time and respect for human system. Quite a mouthful, but there you have it: JIT and respect go hand in hand. Over the years, I’ve found that a pull system tends to be the best (or least worst) answer to the sustainability question. And even so it doesn’t sustain itself by itself, since someone has to ratchet up the level of Just in time to lower the water in the lake, make the rocks appear and keep people interested in solving problems.

I haven’t come across one situation yet where pull is natural. Every one has their reasons to explain (honestly) that pull won’t work in their special case. With back-office work, I’ve found that visualizing a central queue of files and dispatching regularly to individual queues is a good place to start, but you’ll probably have to make your one up as you go. My father’s sensei’s advice was: “don’t interpret just-in-time at your convenience.” Start from there, and see where it gets you – my bet is that any pull system will make kaizen more sustainable than none.

Can you help us define the role of team leader?

June 19, 2012
Back to top

Dear Gemba Coach

My lean team is creating a team leader role, and we are struggling to define this function accurately, not to mention that we are having trouble finding our places. Any advice?

I’d have to know more about your specific Gemba, but this is a frequent problem. For discussion’s sake I’ll assume that you have assembly cells in place and have stabilized teams in zones. As I’ve said before, the pre-requisite to team leaders is, well, teams. This may sound obvious, but I’ve seen far too many companies miss this step and then struggle with an organizational role that doesn’t make much Gemba sense.

As a first step, check to see if stable teams are clearly assigned to defined zones. This, in turn, means that you’re clear on your product/process matrix and have specified the value flows so that:

  • You have a team of people who always work together and 
  • Makes a stable basket of products
  • In a defined zone where they run a set number of processes

When I visit plants I often observe operators who are constantly moved around during the day or the week. There are generally two main reasons for this. First, the MRP runs the plant and routes products through the processes according to its parameters, rather than value streams. Second, changeovers are difficult or dependent on setters and so on, so teams are not autonomous in changing production. As a result, shop-floor management, in an attempt to optimize the hourly cost, will tend to move operators around the shop to do work rather than solve the fundamental problem of giving eight hours of continuous work (with different products) to a stable team of operators.

Again, before we figure out what we need from team leaders, let’s explore what we expect from the team, and the team members themselves.

Start Here

As a very basic starting point, you should make sure that your shop floor organization guarantees that every person will be able to perform eight hours of standardized work in their shift.

This doesn’t mean that they have to work on the same part all shift long – or on the same station. For instance, the team can do part A for two hours with each member following standardized work for his or her amount of work, and then the team can change to part B using a standardized tool change sequence, and then they can produce part B according to the standardized work for part B. Although not always easy, within the shift, team members can also rotate around the cell, but still they move from following one standardized work to the next.

Once you have gotten to this point, you can start looking. If you stand for half an hour in one spot of your factory, you’ll probably see that you’re asking operators to do many wasteful tasks, such as deal with defective products or components that they have to identify and pull out of the process, produce too much of a component that is not immediately needed, do extra jobs that don’t add immediate value. You’ll also see that these wasteful activities intertwine into each other and result in wasted labor hours and unused machine capacity. This is not good for you, and it isn’t good for the people themselves either because it stops them from doing their job: producing good stuff at a regular pace.

Operators are constantly asked to do many other things than their main job. They’re often asked to fill in paperwork, control parts, do 5S, deal with some machine problems, and so on. So even at operator level, defining the person’s role can be tricky. I was discussing this issue recently with a Toyota plant VP and he told me they faced similar issues and were trying to clarify each employee’s minimum role. If we forget everything else, what is the minimum job this person has to perform?

At team member level, what they came up with is that the operator must, at the minimum:

  1. Follow standardized work.
  2. Conform to safety rules.
  3. Call out abnormalities.

Then, the role can be stretched with a fourth point:

      4. Reducing waste in the cycle time.

Now, as we all now, these points are neither simple nor immediate in most working environments. If you’ve tried to build parts for any length of time, you’ll find that standardized work is often hard to follow (some points are easy to miss, some specified actions are hard to do), safety rules easily skipped when you’re busy getting the work out, abnormalities easily missed as you’re flowing in the routine of repeating an operation again and again, and so on. In order to be able to succeed at these 3 (then 4) roles, team members need support: this is where the team leader comes in.

Team Secretary?

The team leader is an operator, not a manager. He or she will, in the course of a day, make some parts – replacing breaks, for example, or replacing missing people, or simply helping when the cell is late on schedule. Because this role is undefined, the temptation will be to off-load work from operators and from management on team leaders, who find themselves swamped with all the paperwork the ISO system can invent, and dealing with HR policies and so on. Team leaders hate that, and if they’re being perceived as the team’s secretary, they lose all credibility with the other team members. What then, should the team leaders’ minimum role be?

  1. Support every member in carrying out standardized work
  2. Support every member in conforming to safety rules
  3. Support every member in spotting abnormalities
  4. Involve members in looking for waste in their work cycle
  5. Watch out for upsetting fluctuations in the course of the work

The team leader can then be stretched with a sixth point:

6. Re-balance the line to the takt

For instance, the team I mentioned showed me how a team leader was helping one operator on the line who had caused several quality problems without realizing it (spotted further down the line, a big no-no on a Toyota line). The leader was told by his group leader there was a problem on this station, and they’d narrowed it down to one shift and thus, one person.

The team leader then spent time going step-by-step through the standardized work to figure out with the member where something was going wrong, and couldn’t see anything. The operator was following the standardized work as he’d been taught. But still, he was creating problems. Eventually, the leader realized that the operator being unusually tall, at some stage of the process knelt on the supporting platform rather than stand. This changed the angle at which he used the screw gun, and created the problem. They then worked together to create a specific standardized work sequence for this person that took his own individual problem into account.

If you watch a Toyota line for any length of time, you’ll see, most of the time, the team leader respond to andon calls to:

  • Confirm with the operator whether the abnormality the person spotted is a defect or within acceptable parameters.
  • Help the operator when he or she is struggling with the line pace, and teach the correct way of following the standardized work.

The additional aspects of this minimum role are harder to see when walking through the plant. This minimum role is already quite challenging, and team leaders can be expected to succeed in it if they get the corresponding support from their group leader – the first level of management (often called managers or supervisors).

Their minimum role is then specified as:

  1. Making sure the standardized work exists and is followed
  2. Making sure safety rules make sense and are respected.
  3. Making sure abnormalities are visible and called out.
  4. Making sure operators are involved in waste-seeking in their work cycle.
  5. Supporting team leaders in dealing with fluctuations.
  6. Correctly balancing the line to the takt (given by the pull system).

In a lean environment, this last point is absolutely essential because we know that the most cost-efficient way to produce is to make sure production pace follows sales pace. The lean logic here is:

Sales pace determines production pace

Takt time levels out variation from short-term sales fluctuations

Takt time determines the amount of work per work station

Standardized work

What’s the Purpose?

This is how the conditions for standardized work are maintained throughout Takt time changes and product changes. As we can see, this angle of view also determines the “autonomy” the team should have. Autonomy in the lean sense means being able to follow standardized work (safety, quality, and cycle-time) autonomously, being able to carry out tool changes autonomously, and being able to improve standardized work autonomously. A far cry from self-directed teams, but, I’ve found, already a tall order.

Having said all of this, I completely understand your problem and empathize with your situation. Most Toyota practices have evolved organically from long struggles to improve automotive lines, so in many cases Toyota has already established pre-requisites for other reasons. Still, if one wants to lean one processes, following Toyota-inspired principles remains the best bet.

So, yes, in every plant I’ve worked with, at some point we take a deep breath and jump into the team leader issue – and it’s pure magic. But like many other lean tools, this needs to be put in the context of standardized work and kaizen. To answer your specific question, my advice would be to figure out what the minimum role of your team leaders should be: the purpose of their role – what they’ve got to get right if they have to forget everything else.

Kaizen and Innovation

June 12, 2012
Back to top

Dear Gemba Coach,

Can kaizen stifle breakthrough innovation?

Are we talking about just any kind of breakthrough innovation? Or successful breakthrough innovation? Hopefully, kaizen will stifle the former and sustain the later.

First, we need to distinguish what kind of Gemba conditions we’re looking at. Every situation is different and specific, of course, but for argument’s sake we can broadly distinguish market-creating innovation from mature markets innovation. When a new technology creates a market whole piece, such as we’ve seen with Microsoft in its heyday, Google or Facebook, or the recent run of killer products from Apple, this is clearly a case of having a revolutionary vision, working hard at making things work, throwing it at the market, and hoping that it will stick, which is essentially about letting creative destruction do its work of picking the winners from the losers. In this case, breakthrough innovation is clearly needed, and adhering too strictly to the rather “100 times 1% than 1 time 100%” kaizen attitude is probably not helpful. Having said that, I’ve talked to Google execs, and although they propose new services frequently (breakthrough), they also have huge problems stabilizing their new offerings and fixing the glitches or adjusting to customers usages, which calls for kaizen. Indeed, Google has invested massively in creating a testing culture that is very close to Toyota’s approach to andon, for precisely that reason. Still, industry-creating environments clearly require bold moves and risk taking, no debate.

But most companies I come across operate in very different settings. They’re usually in mature industries, where technologies and competitors are well established, and since reality exists and reality resists, coming up with a completely new way of doing things would require a fundamental research breakthrough, or someone having the kind of genius idea that we don’t see every day. Certainly, there are regular reports of some such large companies giving employees “free thinking time” hoping that they’ll come up with breakthrough ideas, but the actual effectiveness of these practices is still unproven (yes, I’ve heard all about the Post-It example, again and again: any one know a second case?) and not very practical in medium size companies that tend to be typically stretched for resources.

In my Gemba experience (and I claim no industry-wide research insights), in such companies product innovation questions are usually posed in terms of “new product releases.” A typical industrial manufacturer’s engineering department is under pressures from all sides:

  • Marketing wants the new product that will enthuse the sales force.
  • Key accounts want specific new features for their largest customers.
  • Service wants customer complaints fixed.
  • Management wants cost reductions.

Restricting Innovation to Foster Innovation

When it comes to new products, marketing will typically have identified all the new features in competing products and specify them in the “new product” in the hope that this new baby will take the entire market. Unfortunately, engineering life is never easy and new technologies are hard to master, or new features rarely work well first time around: engineers need to learn to do it right. I’ve personally witnessed a few new product introduction disasters caused by:

  • Misunderstanding customer usage, such as when the manufacturer of heating and plumbing widgets comes up with a great new product which no installer buys because it involves learning a new set of installation procedures (without a significant cost incentive)
  • Technologies not yet mastered, such as when an industrial equipment manufacturer introduces many new electronics-driven features which then glitch frequently.
  • Misunderstanding customer preferences, such as when marketing pushes hard for specific options for its key customers, which they never bother to purchase, and so on.

For instance, as we speak, in a company that makes testing equipment for the pharmaceuticals industry, the CEO refocused from adding bells and whistles to his current machines to testing for one aspect of the drugs that his customers where asking for and his current machines couldn’t see. Rather than push this through the engineering department, he asked his two best engineers to set-up a separate “skunk works” office and come up with something.

At first, they played with many new technologies until the CEO restricted innovation again by asking them to jury-rig a machine from elements already existing in industry. They grumbled, but they put together an ugly looking contraption that sort of did the job.

And then the light came on.

They realized that they could kaizen the brute they had into a smart new product. It’s too early to tell yet whether customers will actually buy it, but the unexpected consequence of this effort is that it has led the engineers to challenge two of the core technologies (one in software, the other in mechanical movement) the company currently uses. In this case, kaizen is unexpectedly fostering breakthrough innovation – the company has now a joint-venture with a local university to make these ideas work.

Purposeful kaizen

From the lean perspective, innovation for innovation’s sake is not taken for granted. Our aim is to create products that are leaders in their markets because they become a standard for customers (the default option and customers have to justify internally when they want to switch to another product). So lean innovation needs to:

  1. Serve a specific market purpose: what problem customers are experiencing now that can be solved by new tech.
  2. Be reliable: if we use this new tech, how do we guarantee that it will work reliably when the customer uses the product.

Both of these criteria are, in practice, extremely hard to uphold, particularly when you have scarce engineering resources already stretched by day-to-day work.

Clearly, an obsession with kaizen will hinder casino-like innovation. Clearly as well, uninspired leaders can hide behind kaizen to argue against every kind of innovation. But just as clearly this is not the lesson Toyota taught us. The Toyota Way rests on a spirit of challenge, courage, and creativity. So, once again, we’re down to the attitude of the company’s leaders. If the leader understand his or her customers well and is determined to improve his or her products on one aspect at a time, and to use new technology to do so, carefully and safely then kaizen can lead to breakthrough innovation, just as Toyota has shown us with Lexus, Prius and now iQ.

As John Shook often points out, the key is purpose. Direction-less kaizen has indifferent results and can, in the extreme be stifling (as well as confusing and distracting as many companies have unfortunately found out in conducting kaizen blitzes). To deliver it’s full power, kaizen needs strong purpose expressed as clear improvement dimensions and constant challenge to keep the improvement pace. And then, out of the thousand kaizen ideas, a few will open doors you never knew where there, and lead you into a completely different room – true innovation.

Real lean vs. fake lean

June 6, 2012
Back to top

Dear Gemba Coach,

I am a lean consultant who is totally dedicated to applying the lean principles. Unfortunately most lean gurus who I encounter seem to look down on our work. They argue that consultants like me don’t do “real” lean.  Where do you weigh in on this? Are they being too snobby? Should I work to be more authentic in my practice?

This is a very good question, but rather above my pay grade, and typically, this is why we need senseis. Have you got one?

You see, this question touches upon several different principles of lean practice and lean learning. And ultimately much of the answer depends on your personal point of view. First, let me latch on to the idea of applying lean principles. On paper, this sounds clear and simple. The rub is that lean is a practice, as my father keeps repeating, and not a theory. This means that “applying” the principles can be problematic.

I can’t count the times when I’ve been working with guys at the Gemba in a new situation (or, occasionally, in an old situation, which is really embarrassing) trying hard to apply a lean principle such as, say, flow, or stop-at-defect. And when I’ve shared our efforts with my father (yes, I know, my father is my sensei – sigh!) he’ll roll his eyes and wonder what possessed me to advise this or that. But I’ve applied the principle, I complain.  And then he’ll ask if I’ve noticed this. Because, in this case, the principle applies completely the other way around.

The issue here is that lean principles and goals can’t just simply be “applied,” they are interpreted, and there is usually a great need for wisdom in their interpretation. So-called “real” lean is in fact far more of a tradition than a theory. That’s why it’s so important to have a connection to this tradition and to seek to inscribe oneself within its bounds, as opposed to interpreting it as feels more comfortable. That’s why senseis are so important.

Fake Lean

Recently, I was struggling with a completely new environment with managers who were obsessed with productivity (of course). I didn’t quite know where to start, and asked my father, who said to start as we always do: accidents and customer complaints. We did that, which uncovered a number of findings, which led to kaizens to improve operator ergonomics. I had told the managers that they should see productivity results show up as they improved the ergonomics of their working cells. When this did not happen, I couldn’t figure out why and discussed it again with my father. Are the operators stabilized in one zone, he asked? Or are they moved around across the plant for flexibility’s sake? I went back to the Gemba to check, and of course found out that operators could be moved from one station to another within the day according to the MRP- calculated work orders. As long as a team of operators doesn’t “own” a cell, and doesn’t see that they’ll get the benefits from their own kaizen efforts in their own workplace, they’re unlikely to get involved. Furthermore, productivity simply won’t progress as long as operators are isolated across the shop because any time won on a single operation cannot be reorganized in a way to gain a full person, and make real productivity improvement. Ohno, in The Toyota Production System, had explained long ago that reducing half an operator’s workload was not productivity until we could take the full person away to another job.

Upon reflection I realized that I had been befuddled both on the “respect” front (involving operators in the success of the improvements) and the “kaizen” aspect (real productivity). This “practical wisdom” for fault of a better term can only be learned through practice with a teacher. This a core issue to lean, and is why lean remains fundamentally interpretative and linked to people. Principles can be codified and are a good place to start, but without the correct interpretation, they lead to nonsensical solutions more often than not. The sensei’s opinion is the obvious test method to know whether you’re doing “real” lean or “fake” lean. And again, what can appear as nuances of a principle can end up with radically different results when you end up applying it in practice.  

But what if you haven’t got access to a sensei? I’m often asked this question, and never quite sure what to answer, beyond: looking for a sensei is part of your lean journey. I realize how frustrating this answer can be, so I’ll go out on a limb and suggest some possibilities.

If you work as a consultant in production, whether manufacturing or services, then I’d say the test method is pretty straightforward: do your clients learn to see muri, mura, and muda and to reduce them?

  • muri, or overburden, means making people or equipment work in unreasonable conditions. In the case mentioned above, because of my lean experience, I could see right away that operators were constantly picking up crates. This is overburden. The managers themselves considered this as normal, and inconvenient at most. But from practicing seeing with “lean glasses,” they progressively learned to see the muri for the disaster it was, and so, start doing something about it.
  • mura, means any form of stop-and-go. The company in question had attacked its productivity problem by investing in many large machines. They then set up incentives for running rates of the machines. Consequently, the people at the Gemba would wait until they had enough material at hand and then run the machine as fast as possible. This is typical mura: slow, slow then fast, fast, then slow, slow. In service, mura is everywhere since customers tend to want to do the same thing at the same time: have a meal, check out from their hotel, pick up the rented car. If mura is not taken into account, it will create both muri and muda.
  • muda, better known as the “wastes” of overproduction, correction, waiting, motion, transport, inventory, overprocessing. Unfortunately, muda is often interpreted from the manager’s point of view as a drag on productivity. In the lean tradition, muda are non-value-added operations imposed on the operator. Respect for the operator means that he or she can do as much value-added work without overburden. So wasteful operations are not respectful. When you hear about the “eighth” waste (wasted creativity), you can be certain we’re talking about the managerial perspective, whereas the real challenge is to look at work from the operator’s point of view. 

All in all, if you work in a production environment and as result of your consulting, frontline managers develop a greater sensitivity to muri, mura, and muda and find specific good ideas to reduce these (muda is usually the result of a combination of muri and mura), you can be confident you’re doing something right.  In my experience, a lot of muri can be seen at the preparation and planning stages and can be avoided proactively. mura is more about eliminating fluctuation at the operational level. muda tends to show up when the process is in place and seen by variations in output which can then be analyzed in terms of muri and mura of the system. I’ve been taught that management’s role is to continually self-examine operations in order to provide and improve a flexible system and connect the workforce to the customer.

Non-production Lean

But what if you’re not in a production environment? What if you try to apply lean in a completely new setting, such as IT, where there is no lean tradition? This is a discussion I recently had with Steve Bell, co-author of the great book Lean IT: Enabling and Sustaining Your Lean Transformation. We concluded that it’s tricky, but the spirit of PDCA still applies, and your question is still totally valid: how do I test my ideas?

In developing lean beyond the original field of automotive production, its pioneers such as Jim Womack, Dan Jones, John Shook, Jeff Liker and others have consistently tried to test their ideas in two ways:

  • Testing the “Toyota-consistency” by discussing the idea in question with senseis, and listening carefully to their reactions. Typically, senseis will not want to have an opinion outside of their area of expertise, but they can’t help reacting to any new notion. Their reactions are often based on Toyota tradition and not necessarily easy to specify, but it’s the intent to understand that matters – our collective will to recognize that Toyota has opened a different management path that we need to capture that counts.
  • Testing the idea in real-life by experimenting live with your clients, and making sure that they understand clearly what is being tested (Plan) and how we’re going to do this (Do) how we’re going to test it (Check) and what kinds of conclusions we can expect (Act).

I’m not sure whether this answers your question, but from talking to the gurus over the years, I can tell you that what really gets their goat is applying lean without the PDCA spirit: the certainty that such and such principle applies and that’s that. Lean is not a religion, its applying scientific practice to the realm of business. Whenever I pontificate about any lean topic, or worse, consulting success, which is frightfully easy to do, I find that they just stop listening. On the other hand, the lean gurus I know are always ready to discuss ideas and experiments and debate against real life experience or Toyota traditions. On balance, I’d argue that lean gurus don’t especially look down on consultants or their work, but are unimpressed by the cookie-cutter approach of most consultants. If there is one common theme that binds all “real” lean practitioners it is turning the PDCA wheel. I’m willing to bet that if you frame your questions in that way the lean gurus will be as patient (and forgiving) with you as they’ve been with me!

How do you suggest we should do lean in a foundry?

May 22, 2012
Back to top

Dear Gemba Coach,

How do you suggest we should do lean in a foundry?

The glib answer could be: just as anywhere else – but I’ve done a couple of Gemba walks in foundries and I have to say that I find the environment somewhat daunting. The foundries I’ve seen vary considerably from one another, but one thing for sure: it’s a demanding process. On the one hand the process is quite heavy going – it’s physically demanding, dirty and, well, hot – and on the other precision casting require a sophisticated handling of technical parameters.  This is definitely a case where I would recommend both 5S and a robust six sigma program. One place I would not start is what I’ve seen on a few occasions: kaizen events to eliminate waste by reducing operators’ walking distances. This is not negative, as such, of course, but is unlikely to deliver the hoped for results.

Like most process industries, foundries have large equipment and relatively few workers spread around the place – although I’d have to distinguish the pattern crafting part of the operations from the actual casting side of things. Lean experts coming from an assembly work tend to start with a “seven wastes” perspective and immediately show that operators and parts are moved around quite a bit, which is sheer waste. This is certainly true, but has an element of a solution looking for a problem, like looking for the lost key under the lamppost because the light is there. If you’ve considered starting by cutting headcount costs by reducing operator movements, I’d suggest you take a step back and, well, think. The question, as always, is “what is the problem we’re trying to solve?” and hence, how do we see our real problems as opposed to what is immediately apparent.

The issue with wearing lean glasses in any new setting is that wastes will jump out everywhere, but I don’t have any experience base to distinguish real problems (with a high-pay off potential on sales, cash and bottom-line) from mundane issues (indifferent as regards sales, cash, and the bottom-line), no matter how “obvious” the waste might be, such as operators walking all over the foundry for very little apparent value-added time. For what it’s worth, I do have a standard or sorts to approach lean in an unknown environment:

  1. Safeguard the people
  2. Protect customers
  3. Control the lead-time
  4. Reduce the lead-time
  5. Eliminate costs at the source

 

Forging Ahead Safely

How would that standard apply to a foundry? To start with, we have to accept that a foundry is an aggressive working environment. Those I’ve visited tend to be dark, dusty and filled with very hot objects. I rarely recommend starting a lean initiative with 5S because of the many disappointments with this over the years, but this is clearly a case where a 5S drive applies. The problem we’re trying to solve is not cleanliness per se, but involving operators in improving their own working conditions. Many kaizen workshops tend to be structure heavy with one or two “alibi” operators. In this case, we should think of a workshop plan by and for operators. The idea is to organize events so that every operator of the foundry has participated at least in one event in the year. There is no need for more than one facilitator per workshop, and the idea is to use the 5S methodology with a special focus on safety.

As a plant manger, as you progress through this plan set aside a small budget for “cleaning up” each area touched by the event – fixing what is clearly broken down, a coat of fresh paint, maybe – this should be running costs, not investment. Overall, getting a foundry spick and span is a daunting task, so we break it down in kaizen steps: the ideal is that over one year, every part of the foundry has been spruced up and every operator has participated in the effort to improve the working environment. As a plant manager, you can make a point of showing up at the end of the workshop and personally agreeing to what is feasible and what is not. You’ll find that this will considerably benefit your relationship with your workers.

What’s Kilning Delivery

Protecting customers is of course about quality and delivery. Before we tackle the quality issue, let’s start with delivery. Many manufacturers I know keep complaining about the poor delivery performance of their cast parts suppliers. This issue is not specific to foundries but tend to touch every flow process business, where the batch mentality still rules (mostly because of the difficulty and high perceived cost of change-overs). To understand delivery issues, the first step is to create a group to handle a weekly production plan based on understanding real customer demand. The trick is separating high-volume parts (even in a low-volume environment, you can safely bet that less than ten percent of all product references will account for more than 50% of total volume) from low volume ones, and then schedule the high-volume parts every day. This might (or might not) put a strain on the process flexibility, but it will have the merit to clarify your understanding of real demand. What I usually find is that if you focus on making the high-demand parts every day to a leveled schedule (since they’re high demand, demand variation is overall lower), it leaves ample production time to produce make-to-order one-offs as well.

Secondly: quality. Quality in any process industry is a matter of finding out which are the right parameters to focus on. This is by no means obvious, and certainly six sigma will help. To get started, you can task a technical group to set up SPC tracking of key parameters not, at this stage, to reduce variation, but to figure out which parameters have the greatest influence on quality. Sure, temperature control is important. Certainly, sand quality matters. But this can be true of any foundry. The challenge is to figure out what parameters matter in your specific foundry, and this is by no means obvious.

EPEI vs. MRP

Once you have a better handle on working conditions, quality and delivery, you can start on the next phase, which is controlling lead-time. In the cases I’ve seen this comes down essentially to two key problems (1) getting the right rotation of products through casting and (2) getting patterns in time from crafting. The lean tool to understand crafting programming is Every Part Every Interval (EPEI): the set sequence of parts production so that the lead-time of any individual part can be known. This goes counter to the MRP logic of programming parts according to calculated instantaneous demand, but is hugely helpful in settling down the process and seeking “economies of repetition”. Exploring Every Part Every Interval will also lead you to much better understand how various parts you produce behave, from the high runners to the occasional repeater to outlandish exotics.

Pattern making remains in many cases a craft operation and I’d start there with straightforward production analysis boards to see whether we’re making patterns at the expected rhythm in order to control the overall lead-time. If handled properly by checking the boards several times a day and discussing comments with the pattern-makers, the various causes for production loss should become visible, and highlight the many opportunities for kaizen.

Once lead-time is under control, you’ll have a better idea of what value streams are going through your foundry, and how different parts behave with different lead-time conditions – these different parts need not be treated the same in terms of scheduling – high runners can be pulled, and make-to-order programmed, for instance. Once your management team has clearer ideas about how to handle these value streams, it’s time to bite the bullet and reduce lead-time. In casting, as with most flow operations, this is a matter of increasing the frequency of change-overs – which, in turn, means single-minute exchange of die (SMED), no two ways about it. At this stage I don’t know any other way than finding a local SMED consultant and setting up a robust SMED program with the aim of systematically reducing the Intervals of the EPEI – this will highlight many shortcomings and deficiencies of your technical process, but there’s nothing doing – no pain, no gain.

But what about cost reduction? Keep in mind that the full lean principle is cost reduction by waste elimination. Obvious wastes, such as operator movements backs and forth, are not necessarily high potential wastes, such as poor scheduling. The previous exercises should keep you busy for a couple of years and, more importantly, should lead you and your team to a more detailed understanding of what they key wastes occur in your operation as a result of the way you currently run things. I have no doubt that as you get more expert at recognizing the wastes you create you will also find countermeasures to eliminate these wastes and your costs will come down. I realize there’s something of a leap of faith in this statement, but your costs will come down.

Lean as usual you might say - maybe.  However, the foundry remains a rather extreme environment where people’s involvement is critical, so before you roll out the plan, let me back track to the essential point of starting with a 5S/safety workshop for each operator team and a six sigma project program for technicians. The immediate aim is to get people working together in taking ownership for their physical and technical environment, and work improvement strategies from a basis of teamwork and shared challenges.

It seems that lean these days is all about learning and coaching. What about the good ol'-fashioned just-in-time stuff of the earlier days?

May 2, 2012
Back to top

Dear Gemba Coach,

It seems that lean these days is all about learning and coaching. What about the good ole-fashioned just-in-time stuff of the earlier days?

Touché – and I plead guilty. The other day I was on the Gemba of a plant that makes industrial equipment and had exactly the same discussion with the plant manager. This fellow has an excellent, intuitive grasp of respect and a deft touch with people. He’s really good at getting people to work together and has a gift for fostering both change and goodwill. But his corporate management is asking for immediate productivity results, by the book and by the numbers. Hmm.

Now, in a low-volume high-variety business run by an MRP, quick productivity results are hard to find. There is no high-runner cell with ten operators that can be quickly kaizen-ed down to five. There are a lot of grinding, turning, milling machines, a monument of a paint shop, a few craftsmen-like assembly stations, and many operators milling about according to where the supervisor needs them. Not surprisingly, on-time-delivery is a struggle, and productivity is poor. This is not seen as a problem since the margins per product are high, but we all know what senior execs are like when it comes to productivity figures (and their own bonuses).

To make matters worse, in a high-variety environment, any increase in volume means an increase of one part or component missing, which requires a schedule change, leading to less OTD and productivity … so we won’t be saved by volume. That sucks. The strategy then, is to ship on-time-as much as possible, in order to get cash in hand from the customers and pacify corporate with cash and bottom-line. But how?

Not with Safety Glasses
We need to look at the same situation with several different pairs of goggles. One, the respect glasses, reveals how everything we ask operators to do that does not add value or does not contribute to shipping products is a lack of respect. Guys are here to work, not to fill in paperwork or recount kanban cards. The more focused their work, the more productive, and the more likely we are to ship on time. But how can we focus on the right problems?

We use the other pair of glasses: the just-in-time system, and a view of the entire factory as if it was a mechanical engine. We were looking at the value-stream maps his team had been doing, and they had the usual flaw of detailing the material flow and sketching the information flow as an afterthought. value-stream mapping (VSM) is part of a lead-time analysis, not a process analysis. So two critical aspects of VSM are:

  1. The number of references made on each machine, since production lead-time is calculated as the time between the last part of A from the previous batch to the first part of A from the next batch (with batches of B, C, D, etc. in between).
  2. The frequency at which information is updated in the information flow: once a week? Once a day? Every hour? Whenever something happens, and so on.


The main problem of a high-variety environment is that although everyone is busy working, they’re usually working on the wrong part. As we walked the shop floor we checked the work orders: either ahead (parts needed for next week, aka overproduction), or late (parts needed yesterday, aka waiting). So we tried to look at the production process as a dynamic system of information converted into action, and then into parts. What tells who to make what when. The more frequent – and the more regular – the update, the better chances of making the right stuff at the right time.

Want Fries with that kanban?
Developing the dynamic vision of just-in-time is by no means intuitive, and it requires learning the techniques and discipline of a pull system. For instance, they’d set up a vague form of kanban with a launcher that had many, many cards in it. Now, any restaurant works with kanban. The front waiter takes the orders when people sit down, and then puts them in front of the cook to make in the same order. The cook picks up each order and either (1) it’s a today’s special so she takes it from the supermarket of ready dishes or (2) it’s à la carte and she makes the dish from scratch. Then it’s shipped. Like a complex product, a table has to receive several different dishes at the same time, but hey, restaurants mostly get it right – so why not factories?

Back at the Gemba we looked at the launcher and we calculated that the machining team had orders for the next three days. This is massive overproduction of information, and leads to a number of problems. First, how likely is it that the kanban cards of three days in the future truly represent what will really be needed then? Secondly, with three days of cards ahead of you, how tempted would you be to pick and chose the ones you feel are urgent, or easier to make? Thirdly, and this is where just-in-time dovetails with involvement and engagement, with three days of work ahead of you, how determined would you feel to get the work down rather than have another smoke before changing the tool setting once more? How involved would you feel with the company’s determination to ship to its customers?

There is a sly underhand trick to pull: it completely changes frontline management’s job. The supervisor can no longer decide what to do when; she’s got to follow the cards, just like the cook. The supervisor must now focus on doing the job right, much like the cook again. Some supervisors will love it, feeling liberated from self-defeating decisions, and some will hate feeling technically challenged and losing petty boss’ power.

Furthermore, this also means that information management and material handling is taken away from the operators’ job and given to a specific logistic function: the train that delivers parts and picks up cards, cards which then need to be sorted and redistributed. When this happens we suddenly realize quite how many tasks operators have to perform that have nothing to do with making parts.

The difficulty, of course, is to walk on two feet – to hold the two different visions – just-in-time and respect-for-humanity – at the same time and slowly learn to figure out how they converge. This was, I believe, already the point of the very first paper on lean published by Toyota veterans back in 1977, although at that time much of the paper was devoted to calculating kanban cards. We’ve learned the hard way that respect is as important as kanban, but maybe we’ve now overcorrected. Without both a system-level and card-level understanding of JIT, respect becomes wishful thinking and will not satisfy any of our stakeholders: neither the operators (we’ll “respect” them on the wrong topics – they’re not fooled that easily, involvement comes from sharing the company’s objectives) and neither corporate. Never easy, but let’s face it, never boring either!

What's the difference between model lines and kaizen events?

April 26, 2012
Back to top

Dear Gemba Coach

We used to do six sigma and are new to lean. Some consultants talk to us about model lines and others about kaizen events. Can you clarify the difference?

That’s a difficult question, and I’m not sure I have all the answers. The various formats for “doing” lean emerged from the work Toyota was doing with its suppliers in the eighties, and the way that consultants interpreted it to sell projects to customers. What we’ve learned since is that the challenge is to become lean, rather than to implement lean, and so the various consulting formats don’t necessarily apply to every business. Let me recount what my father and I have learned from his experience of becoming lean under Toyota’s guidance back in the 1990s.

At the time, Toyota was toying with the idea of developing suppliers in Europe as they’d done in Japan. The situation was rather different. In Japan, many of their suppliers were part of the keiretsu. Many of the supplier’s managers were ex-Toyota employees, and Toyota was a dominant customer of most of their target suppliers. Not surprisingly, the suppliers were, if not eager, at least open, to learn more about TPS and the Toyota Way. In Europe, Toyota was starting its first European plant in the UK, had no pre-established relationships with supplier’s management, and usually represented a very small volume in any one supplier’s plant.

My dad turned out to be a natural candidate because as a Renault top executive he’d previously developed a long-standing relationship with Toyota TPS experts, and now that he was Industrial VP of a supplier, it made sense to start with him and a few others. As far as I remember, Toyota did start with a model line. They focused on one part, the light indicator, in one factory and invested quite a bit of resource in turning this production line into a lean showcase: one or two Toyota engineers visited the line on a monthly, sometimes weekly basis to spur kaizen. From my notes at the time the big fights were fought over quality and flexibility. The aim of the Toyota engineers was to turn the usual long-changeover, long-run, production line into a flexible cell which would produce five containers of five parts and then change reference. This had many technical and ergonomic implications as it meant modifying the machinery so that the lady operators on the line were able to easily (because of the number of changes) make the change. When the work started, tool changes needed a specialized setter who could not be available for such a frequency of changes. More frequent changeovers also created more frequent quality problems, usually at the setting stage which needed to be resolved.

Over the course of two years, the line evolved into a real “model” for all the TPS main principles: single-piece-flow, small batches, standardized work, andon, etc. As corporate level VP, my father visited the line regularly with a very senior Toyota guy who had learned TPS working directly with Taiichi Ohno. The line made considerable improvements, and it was then assumed by my father and his CEO that the trick now lay in “deploying” what had happened on the model line. So they sought to devise a cookie-cutter methodology they could then apply across all the 70 plus plants of the group. The idea was that a 5-day “kaizen event” would be sufficient to introduce the key principles of lean to any new cell and then local management could pick it up from there. The logistics of it seemed daunting, but hey, we’re talking about automotive and these guys don’t scare easy. Did it work? Well, something happened, but it’s hard to evaluate what with hindsight because of a huge wrong assumption.

Lean Laboratory
The question Freddy and I asked ourselves much later was: what was Toyota after? They never asked for any compensation for all the time and effort during the project. Sure, they secured supplies at their standards from that line (in plain English, they colonized the line), but at a huge expense. Did they really intend the “model” line to serve as a replicable model that could be copied-and-pasted across the supplier? We don’t think so. Having talked it over for hours on end, we’ve come to see two large benefits to Toyota’s involvement:

  1. 30% total cost reduction (shared half and half) on the new product: sure there were productivity gains during the kaizen effort on the existing line, but nothing like the engineering impact of the learning from the kaizen on the next generation product. That was massive, and Toyota got out of it a 15% price reduction on the new product, with a supplier happy about it since they increased their margins as well: classic lean win-win.
  2. My father’s education: with hindsight, we also believe that Toyota was not trying to develop the supplier as a company, but to educate my father, who, as a senior executive would then have a disproportionate impact on the company. The “model line” on which the local engineers sweated so many tears was only a support device to get my father to learn first-hand the lean principles. And, as it turned out, the plant’s plant manager refused to get interested, and the plant never became lean, but the company as a whole did.


The model line, in this sense, was not about creating a “model” that could be replicated everywhere else (which we really believed at the time), but a laboratory to show my father how far they could take lean concepts, and with what impact both on the product and the process. To be fair, the deployment efforts did pay back because of the sheer gap of process knowledge, but the company never acquired the kaizen spirit underlying the TPS. It progressed, but then when my father left the company to become CEO of another automotive supplier, all progress stopped.

By that time Freddy had a well-established relationship with his sensei, and they no longer did a single model line. They visited various plants, and each time the sensei highlighted one specific issue. My father’s job was then to figure out a kaizen event with the plant manager to address this issue. It wasn’t that hard because most typical kaizen tools were well-known by then: 5S for visual management, flow-and-layout for productivity, SMED for flexibility, QRQC for quality issues, TPM for OEE, and so forth. But, yet again we missed the point—we were still obsessed with deployment, despite the fact that my dad had moved on from a tool-based program to a roadmap-based program. He was still trying to “deploy” lean. Again, with hindsight, we now see that the sensei was highlighting specific issues and was expecting specific responses from the plant’s management, in order for them to learn, and again, educate the CEO.

Lean Practice Basics
Rightly or wrongly I now believe that lean is about learning, whereas Taylor-ism is about deploying. six sigma projects involve a team of “experts” who will DMAIC a situation, come up with a solution and get the natives on the floor to execute. Lean, on the contrary is about learning-by-doing: specific events, whether model lines or kaizen events are designed to get local employees to learnt o solve issues and to educate senior management. The basic lean practice, I have learned is:

  • Visualize activities
  • Formulate problems
  • Seek root cause
  • Study countermeasures

The emphasis is on studying countermeasures: catch people doing something right, and more importantly, something they’ve not done before, check it, and learn.

To answer more directly, in this perspective, model lines serve as learning labs to see how far you can take an activity by applying all principles of lean in one area, whereas kaizen events are about tackling one typical issue repeatedly across various situations until one gets the hang of the typical solution, and a deep-felt intuition of the underlying principle.

Both model lines also illustrate a deeper aspect of lean, the spirit of challenge, facing one’s problems with creativity and courage. What we’ve learned is that rather than seeing both exercises as the consultant’s way to apply lean to whatever hapless team they’ve got their hands on, model lines and kaizen events are about striving to be better. Lean is not about pushing people to apply a process – it’s about giving them a faraway star to shoot for, getting them to build an ideal, and then see the gap with what we have and stretch themselves to figure out how to get there.

In other words, lean is about developing leaders, not followers. To develop followers, you will formulate a set methodology and get people to apply it, regardless of impact, by doing the P (Plan) and D (Do) of the PDCA. But to develop leaders, you get them first to do a kaizen to seek that frontier, that place where we perform better and then conduct a full PDCA cycle with check and act. To develop leaders, one shows them how far they can throw their javelin, and then ask them to figure out how to throw it that far every day, every hour, with every person. So both model lines and kaizen events are about making a special effort to see how good we can be if we try, so that we then figure out how to be this good every day, and then go further. Continuously.

Management has a bad case of investment loss aversion. What can I do?

April 18, 2012
Back to top

Dear Gemba Coach

I’m in something of a situation and wondered whether you would have some advice. After turning around a facility with lean techniques (essentially creating small autonomous cells by using old equipment), I’ve been asked by the company to take over the corporate lean program. The company’s investment plan favors large high-speed equipment, which I’ve come to see as “monuments.” And yet I’ve been told in no uncertain terms by senior management that I can’t denigrate past investment commitments or cast doubts on those which are currently planned. I personally believe that large centralized machines are one of our biggest roadblocks to leaner processes. Yet I don’t know how to respond to my superiors. What do you suggest?

Tricky, and I’d rather not add to your troubles but you might be in a worse spot than you think. My top-of-the-head advice would be to toe the party line and live to fight another battle. This issue is not the one to make into a “cause célèbre,” it’s not worth becoming a lean martyr over. I have seen this type of battle many times, and, actually, such stories are common in Toyota’s own history of developing lean. Taiichi Ohno didn’t have a particularly easy time of getting his ideas across and he was challenged consistently. TPS evolved due to his perseverance AND Eiji Toyoda’s backing when it came to a crunch. But let’s examine the problem in more depth.

The unfortunate fact is that large companies, and to some extent societies, get stuck with the irrational choices of their leaders that keep committed to a course of action even when it’s long been proved to be a losing option. Wars are fought to the bitter end even when the outcome is certain. Companies go into bankruptcy without ever challenging their strategy. People keep making the same choices out of habit and consistency, seemingly indifferent to the outcomes (they’re not, actually, it stresses the hell out of them), and it usually takes a new team without the same commitments to change tacks. Companies are not democracies, and as long as the same management team is in place, management will place a premium on its consistency.

You Lose
From senior management’s point of view, this is like a Siberian dilemma: imagine you fall in the water in well-below freezing weather. You’ve got the choice of staying in and dying slowly of exposure, or getting out and freezing to death on the spot. For a management team it actually makes (kinda) sense to drive the company into the ground by sticking to their guns: they’ll get fired later when the results are not there, rather than get fired right away if they admit to having made a monumental misjudgment.

And so, in practical terms, I don’t have much advice to give other than not push this head-on. Try to be a wiser man than yours truly and don’t argue about solutions. The trick is in trying to attack the underlying logic of these choices, rather than the forgone conclusion. If it comes to a fight, you’re likely to lose out because the other, more powerful side simply can’t afford to let you win. This is how so many lean officers end up isolated (everyone else naturally aligns with the top dog, even if they understand the underdog’s case), bitter, and cranky. So, not much in the way of advice, but I might have a couple of Gemba suggestions.

4 Suggestions
First, accept that the issue you’re facing is part of lean, not something extraneous. The first chapters of Taiichi Ohno’s seminal book on Workplace Management are: (I) “The Wise Mend Their Ways” (as in: “the wise should not hesitate to correct themselves”) (II) “If Your Are Wrong, Admit It,” (III) “Misconceptions Reduce Efficiency,” (IV) “Confirm Failures With Your Own Eyes,” (V) Misconceptions Hidden within Common Sense, (VI) The Blind Spot in Mathematical Calculations, and so on … you catch his drift. I have an old Toyota document retracing the evolution of kaizen at the Takaoka plant that states explicitly REFORM OF MANAGERS MIND as the goal of the kaizen process. So, rather than prove the rightness of your ideas, you could reframe your role as “reforming managers’ minds,” which opens a different box of questions: what does it mean? How do we do that? How do we know we’re progressing? etc.

Second, be better at the lean officer job. Again, Ohno is an excellent guide. If you follow his advice in the introduction of The Toyota Production System: “all we are doing is looking at the time line from the moment the customer gives us an order to the point when we collect the cash. And we are reducing that time line by removing nonvalue-added waste.” And so, define your lean program as a lead-time reduction program, and things will look different. For instance, a monument may not appear as much of a problem if you’re not careful with lead-time on a VSM. But if you focus on lead-time analysis you can visualize that the lead-time for a part is the production time of that batch PLUS all the non-production time when all other batches are being produced. In this sense, a fast machine that makes all the references might be a plus in terms of production time, but the fact that all parts have to go through it also means that the non-production time for A (the time it takes to make B, C.. etc.) can be huge. So, define lead time as the time it takes to make the last A part of the batch to the first A part of the next batch. By framing the problem in this way systematically, you will eventually make your colleagues start seeing the problem with monuments, and so let them get to grips with the issue themselves. You can lead the horse to water, but you can’t make it drink. Rethink your job in terms of making them SEE the lead-time (and hence cash drain) cost of monuments.

Testing Investments
Thirdly, focus on the problem at hand. Other than their purchasing and maintenance expense, the main industrial problem posed by monuments is their inflexibility, which leads to (1) large lot size – and hence, stocks and cash drain; (2) low utilization, as small lots can’t be fitted in and since the equipment and change-over is typically difficult and takes time (3) and the larger and more complicated the machine is, the harder it is to maintain and keep running. There are no two ways around this: you need a vigorous, old-fashioned SMED program. This is also your best bet to get people to change their mind by being regularly confronted with the difficulties caused by the equipment. The trick is not to think in terms of one SMED exercise or two, but in terms of program: we’ll study one film per week. In one company I know, they have a monthly rhythm of flow-and-layout workshops, and the manufacturing engineering director always sends one or two of his engineers to participate. It’s amazing to see how quickly machine designs are changing in practice. People change what they do before they change their minds.

Fourthly, out of the previous work, formulate a test method for further investments. This is perfectly legitimate. Many investments are done on the basis of some ROI calculations and the fact that someone WANTS the machine. From the way current equipment operates, you can start formulating a one page checklist of what the next solution should fulfill to satisfy the people who use them: the plant managers. This is a neat lean trick which tends to considerably slow down irrational spending by getting people to think a bit further about what they intend doing without challenging the shape of their technical solutions – you’re not arguing against them, you’re helping them make the correct decision.

No debate that, from a lean point of view, you are absolutely correct; sometimes, doing things long enough we forget the early, basic lessons and yes, one of the keys to lean is to move from specialty shops to multi-process cells, as you’ve done. But I’m willing to bet you didn’t reach this conclusion right away. So rather than discuss conclusions, ask yourself how you can take others through the same learning. Most of my research work has been predicated on the idea of reproducing Toyota’s learning curve rather than trying to apply its current solutions. So, take it on the chin and face it: your job is precisely to change manager’s minds. Once we’ve stated it that way, we’re back in the lean world: what is the plan? How are you going to do it? How will you check? What actions will you draw from it to change your mind?

Should I Use Lean for Headcount Reduction?

April 10, 2012
Back to top

Dear Gemba Coach,

My company wants to reduce its fixed costs. And as part of this my management has asked me to apply the lean techniques we’ve implemented in production to reduce headcount in engineering. I’m uneasy about doing this and wondered where I can find out more about lean in engineering departments.

Pull the andon chord! Stop the presses! Hold your horses! Think again! I realize it’s hard to ask one’s management to reconsider, but in this case it is worth expending some political capital to do so. Tell them that “reducing headcount in engineering” as an objective is going down a dangerous slope which might cost the company dearly if it’s not examined very, very carefully.

I’m not saying we should not be seeking productivity from engineering. As Orry Fiume once put it succinctly PRODUCTIVITY = WEALTH.  The question, however, is to understand more fully what kind of productivity we’re seeking. In manufacturing, quite clearly, productivity is about increasing output and decreasing headcount. In lean, real productivity is even more specific since it’s about reducing headcount to produce the same number of products. As Ohno first noted (in the original Toyota Production System book), increasing output with the same number of workers doesn’t mean the sales are there, so it might be overproduction rather than productivity. And, improving efficiency by a fraction of a worker is not productivity because the person is still there. So productivity efforts in production comes down to reducing headcount while producing the same amount of products.

Engineering Value
Not so in engineering. The question to ask yourself is: what does individual productivity mean for an engineer? In product design or development, the issue is smarter solutions, not quantity of work. In other words, productivity is about shortening the lead-time to reaching the right solution. Increasing an engineer’s productivity is not about making him or her work longer or harder, but supporting her in reaching the right conclusions sooner. And back at the Gemba, I’ve seen time and time again what applying cost cutting ratios to engineering departments can produce in terms of overworked engineers and terrible, terrible product decisions. As Jeff Liker points out, for a number of reasons, the moment your engineers are staffed at more than 80% capacity, your engineering department starts burning out, and your company will pay the high price of consequences on the market.

Let’s backtrack and think this through from a lean perspective. The overall aim of lean is complete customer satisfaction and complete elimination of waste. So what kind of waste are we talking about in the case of engineering? And how do we go about eliminating this kind of waste?

It’s often said that engineers cast the largest cost shadow because they have such an impact on the product, the manufacturing process and the entire supply chain. But engineers also cast the longest shadow on sales: great products sell themselves. The first and foremost aim of any company should be leading products. Indeed, Toyota didn’t transform itself from a near-bankrupt small town Japanese car company into today’s leading automotive manufacturer by simply reducing costs. It did so by designing and building cars people wanted to buy! In a saturated market, every car sold had to be taken away from one of the big 3 models—not an easy challenge. Toyota cars were not just cheaper. They were also better (no matter that the entire industry found them uglier as well, people bought them for their own reasons).

Right Product, Right Audience
The first waste we need to tackle is the waste to the customer: what are the cost of use and cost of ownership wastes that the engineering department creates through its technical choices? For instance, I was recently part of a post-mortem discussion about why a new product that was supposed to make a killing on the market turned out to be a spectacular failure. The product was a piece of a kit used by installers that work on heating systems. The new product is objectively better from both cost and performance point of views, but it’s harder to use and install, and necessitates new training for all the technicians. In this case, engineering made a cost/performance/usability trade-off that the market simply did not appreciate. Technicians preferred using their old widget, known products, rather than switch to the new one. Another way of looking at it is that the incremental gains of the new offering were not spectacular enough to compensate the switching cost.  The company is doing fine and, in this instance, recovered well selling it’s old range, but in terms of engineering productivity this was a disaster as the engineering teams could have been working on something else instead.

The lean way of attacking this issue is the “chief engineer”: a heavy-weight project manager whose first role is to synthesize all known information of customer preferences, formulate a concept of the product, and translate this into engineering parameters. One classic Toyota story is that of chief engineer Yuji Yokoya being tasked with designing the new minivan model for the U.S. market. He chose to drive in every state of the U.S., northern Mexico, and Alaska to understand real customer usage conditions. Amongst the many things he learned, he realized that Americans will drive much longer distances with their kids than Japanese drivers ever would, and so the interior design of the car would be essential: "The other thing that really hit home is what I call the kid factor," Yokoya said. 'It's the kids who occupy the rear two-thirds of the vehicle. And it's the kids who are the most critical and the most appreciative of their environment" (to get the full story, read Andrea Wielgat’s great piece in Automotive Industries, March 2003). Yokoya concluded the Sienna would be defined by its convenience, flexibility, and interior comfort.

In this case, Toyota engineers also did a lot of kaizen. "The goal was not to slash costs," a manager clarified. "The goal was to achieve greatness at a great price and that meant rethinking, refining the entire development and manufacturing process."


And so the first source of engineering productivity is hitting upon the right product for the right audience. If you don’t get this right, anything else is irrelevant.

Justifying Costs
The second shadow of waste created in the engineering department is the actual cost of the product, first in terms of purchased parts and materials (about 70% of most assembled products), second in terms of capital expenditure to by the production equipment (huge fixed costs!) and third in terms of labor content itself. Think about it. Every time an engineer uses a new screw in the product, he creates a full supply chain: a supplier has to be identified, the parts have to be procured, stocked, etc.

The lean approach to this aspect of the cost shadow are engineering standards. In the lean world, each engineer is supposed to keep his or her book of knowledge with what he or she knows about technologies, processes, suppliers and so forth (for more on this check out an earlier column: engineering checklists).  The French counterpart of Toyota’s chief engineer in the PSA/Toyota joint venture vehicle confessed to me that he was astonished to find that the chief engineer remembered issues with models long before his time, which is how he learned about each engineer’s responsibility to keep their own paper or computer files of validated learning: “standards” learned from empirical experience in previous development.

The most obvious place to start with this is a standard parts list for non-critical items. The idea is not to impose on engineers a rigid control stifling their creativity, but to have them justify when they want to use a part outside the list: it’s not forbidden, but it has to be explained. Reducing the number of parts used has a dramatic effect on the whole supply chain. Similarly, reducing the number of technical processes used where we can enables us to re-use old equipment and can reduce capital costs by a sizable fraction. Again, there is no point in constraining engineers, as complete customer satisfaction comes first, but to develop thoughtfulness about the impact of engineering choices on the rest of the Value chain.

Milestones Into Millstones
Thirdly, a further form of waste can be seen in project issues that contribute to blowing milestones and consuming more man-hours than expected. One key target of lean development is “zero engineering changes after tooling” – as engineering changes late in the process can be incredibly wasteful in both capital (re-doing tools) and costs (engineering man-hours). Most engineering projects I come across have horrors stories about poor upstream decision-making with large consequences downstream. I’ve come to the conclusion that the best way to get your project to burn down in flames and crash is to answer any engineer’s request for an early management decision. What I’ve seen time and time again is that when an engineer asks for a spec-based management decision, he or she is usually facing a problem they don’t fully understand or don’t know how to solve. Rather than say upfront: I don’t know how to do this, they substitute to the problems solutions they are familiar with, and ask management to commit. As you can imagine, this rarely ends well and all sorts of delayed bombs go off as the project nears completion.

The lean approach is to decide as late as possible, but try to spot critical issues before drawing. The idea is to lock onto the few technical challenging problems and develop several alternatives that can be evaluated with all the stakeholders of the Value chain. One way of visualizing this is to draw circles corresponding to engineering, marketing, production, purchasing, logistics, etc. and try to find which solution best (or least worst) fits within all the circles. Such “set-based concurrent engineering” is a core lean practice that is nonetheless difficult to learn as it requires enough upstream resources to develop solutions that won’t be used (in practice, that’s not quite true as many aspects of the discarded solutions are still used in the final development).

There are many more techniques in lean engineering of course (target costs, slow builds, supplier integration and so on), but the point is always the same: lean engineering is about creating a learning structure and learning events to help engineers better understand the consequences of their technical choices beyond their immediate development problems. As a result, headcount may – or may not come down. This is an outcome issue, not terribly relevant to the problem at hand: developing great products for customers at an affordable cost. In any case, whether engineering headcount increases or decreases, the objective of reducing engineering headcount to reduce fixed costs is plain silly. This is like saying that you aim to reduce yeast in baking bread because you’re using less flour. Engineering’s total percentage cost in the company’s P&L is rarely huge and, using engineers to reduce non-quality costs would be a much sounder effort.

I realize this answer might not help you much, but I can’t of any other way to go – this is a critical-to-company debate and if your management is going down that road, it’s a battle well worth fighting, as all your jobs might be at stake. I’ve witnessed first had what a poorly designed product can do to a business, and it ain’t pretty. As always, the entry point into lean is about getting agreement on the problem you’re trying to solve, rather than implementing the known solution. Hope it helps some, and don’t hesitate to continue this debate as this is an incredibly rich and sensitive topic we still have so much to learn about!

How Do I Address Resistance From Middle Management?

March 27, 2012
Back to top

Dear Gemba Coach,

Why does middle management resist lean transformations; how can they be brought on board?

That’s a good question and one I was discussing a few months ago with the CEO of a company that is in its fifth year of lean transformation. This company is an interesting Gemba to tackle the question you ask. Two years ago, the same CEO wowed an audience of lean practitioners when he presented his transformation efforts at a Lean Summit. In an industry struggling through its worst crisis in 20 years, his firm is doing well. It’s profitable, has been hiring new people steadily and the level of internal conflict has come down noticeably from the bad old days with the previous management style.

The gist of the lean effort has been the CEO’s commitment to his Gemba (he spends two full days a week walking various workplaces) and a strong focus on grassroots problem solving. The CEO focuses on teaching everyone a simple approach:

  1. Remark: is the process visual enough and can frontline managers see problems at a glance. Do they know how to formulate what they see in enough detail and can they share this focus on specifics with their teams.
  2. React: teach managers not to put problems aside in order to keep on working, but to react appropriately to issues they come across. The CEO works with his hierarchy to try and distinguish clearly good/bad reactions, particularly when dealing with subcontractors or other functions in the company (ie: start by sweeping your own porch before blaming someone else).
  3. Reflect: develop the ability to ask why beyond the obvious and seek the root cause of the problem, mostly by examining what we’ve done that might have created the situation in the first place.


Although results are there, very visibly, and no one discusses that, it still ain’t easy. The CEO gets a real kick out of discovering creative ideas put in place by his best people to solve old problems in new ways. I find his results impressive. That’s because the majority of Gemba visits are about repeating for the umpteenth time the basics of 5S, or noting that the team does not keep up the minimal rhythm of one problem detailed every day, or pointing out that “the supplier screwed up” is not a satisfactory expression of cause.

Challenging Is a Challenge
Although moments of truly innovative thinking on the Gemba are rare, these walks are well worth it. The one person who learns most from the Gemba is the CEO – by spending so much time on the shop floor he has a pretty good idea of what’s going on in his company, which helps him delegate a lot more decision making, in particular to his direct reports. The direct reports themselves have been considerably developed and gained both in autonomy and involvement, BUT, and here we go, although they have picked up the “go and see” of their chief exec, they still haven’t clicked to challenging, asking why, and showing respect. They spend a lot of time at the Gemba, but are still mostly solving problems for their direct reports instead of asking questions (although the CEO says this is changing a bit, albeit slowly.)

And, to your point, the middle managers clearly still resent the questioning practice. Resent is probably too strong a word. They see it as the CEO’s pet theory which they indulge with more or less good grace. Some find it downright infantilizing, others see some worth to having technical discussions with their senior management, but all attribute the success of the company to their hard work (correctly so) and are convinced that if they were let alone to just get on with things, the company would do even better. This second opinion is proved wrong whenever, for whatever accidental reason, the CEO stops regularly visiting an area of the company. In less than three months, the old demons of burning fires and blame games start reappearing, as well as the negative impact on the numbers. In this company, the economic value of lean practice can be seen quite clearly.

To sum up, here’s a company where the CEO is living lean as you’re supposed to, and where lean has the expected results, both in terms of financial results, business performance in terms of hiring in a depressed industry, and people involvement. And yet, as you point out, the middle managers, who are the actual basis of all this progress, still resist. It’s all the stranger since this is not a company where it’s felt that middle-management is bureaucratic and low-value added. Not at all. Company-wide results are clearly attributed to middle-management efforts.

Roots of Resistance
This question, I believe, touches the core of 1) what makes lean like the scientific method, 2) why it’s so successful, 3) and why, regardless of its success, so few senior managers really adopt the practice and stick to it.

I could be wrong, but I’ve come to believe that middle-managers resist the lean techniques because they’re being constantly second-guessed by their hierarchy in front of their subordinates.  The Gemba visits break down the hierarchical frontiers as the entire line from CEO to operators discuss problems formulated and solved by middle-managers. This challenges:

  • Their intuition, as the first answer is mostly wrong and practicing asking why and then why again is extremely hard. Mostly it stops with the conclusion that the middle-manager is thinking globally and hasn’t actually spent enough time looking at Manpower, Machine, Material, and Method on the specific case: something operators know well enough, but that often throws middle-management who are convinced their role is to solve process problems.
  • Their position, as in real-life middle managers spend their time telling others what to do without being particularly good ad explaining the why or how of their orders. With the Gemba visits, they have to detail their thinking and are often found wanting (actually, always, since the practice of challenging is about thinking further).


Not surprisingly, for any executive, it’s easier to stay within the boundaries of setting objectives and letting people get on with them in whatever way they wish, or, on the opposite side, giving orders and expecting them to be followed without discussion. In a company practicing lean, the hierarchical levels are very clear, but they are built on respect: every issue is open to fact-based discussion at any time. As a result, far fewer “decisions” are being made, and policies evolve from repeated experiments and explorations – it’s a very different kind of environment (which is also why they perform better). This is very challenging to a middle-manager because of the expectations both of technical competence and openness to discussion with their teams and colleagues.

All Aboard?
Can anything be done about it? I doubt it. I suspect that resistance to deep thinking is simply part of human nature. I also suspect that what makes lean firms great are those unique moments of pure sunshine when a team goes beyond it’s default nature and comes up with something new, something no one had thought of before. If we accept that middle-management resistance is par for the course, what can be done to mitigate this? It’s in no way perfect, but, beyond saying “well done” during the Gemba visits, a couple of social events can be organized:

  1. Problem-based training: At first training is a blunt instrument because we’re never quite sure at which level of detail or specificity it should occur. As the senior management get more experienced with the Gemba walks, they also start to see some situations crop up time and time again. Middle managers can thus be trained at how to handle specific work situations, in order to be less discomfited when they’re being challenged and have not done the obvious – this is particularly important for middle managers joining the firm from other companies.
  2. Get-togethers: regular, short (less than half a day) events where middle-managers are brought together to discuss a theme. In the previous case, the CEO will chat to groups of middle-managers highlighting specific problems he’s come across during his walks (mainly safety issues) and asking all to be particularly careful. The idea is to make middle-managers realize they’re not on their own, but part of a network of people striving for the same results.
  3. “Show-and-tell” presentations: asking middle managers to present regularly to their peers their problems solving efforts (A3s come in really handy) both to valorize the person’s work and to share information across sections. In technical firms, such a “university” set up (say, a 20- minute presentation once a week or a fortnight) can be the only moment where specialized people hear in depth about technical issues encountered on some other aspects of the product. This, it turns out, is an essential basis to teamwork.


I’m sure there are many more countermeasures, and these are just three I’ve come across that are relatively low investment and high payoff. In any case, the issue remains, and, I suspect, always will. We need to accept that middle-management will resist being put on the spot and will be brought on board personally, one person at a time. There are some encouraging signs at the firm I was previously discussing. Young hires that are now starting to get to lower level management echelons are fare more positive about the Gemba-style questioning than their elders. There was a touching scene recently where a newly minted manager told the CEO how his own father had berated him for not realizing how lucky he was to work in a firm where the chief executive was so involved with product issues and so easily approachable. The kid just shrugged it off, but did acknowledge that this firm was different from anything his friends in other companies described. It even sounded like it was a good thing.

How Do I Reduce Buffers To Zero?

March 20, 2012
Back to top

Dear Gemba Coach

I run an assembly line for service station equipment. Our product is customized for each customer so we have a huge variety of options. My line is organized in segments (hydraulic assembly, wiring, etc.) with a buffer between each section of the line. I’ve long tried to reduce these buffers but haven’t found any good way to do it. Our lean consultant wants me to reduce the buffers to zero so that we have true one piece flow – should I do it?

Is he crazy? Or is it a case of lean misunderstanding? Is the consultant arguing for zero buffer tomorrow or is he - I’m assuming the consultant is a he - saying you should have a plan to progressively reduce the buffers? These are two very different statements, and as most conflict grows from misunderstanding each other’s intentions, it’s important to check. To be blunt, if the consultant tells you to take out the buffer right away, don’t even think about it. If, on the other hand, he wants you to have a plan to reduce the buffers say, by half, then by half again according to a monthly (or quarterly) schedule, then he’s got the right of it and he just wants to keep you thinking more deeply about the underlying causes of the buffers.

There is no debate that “zero buffer” is the lean ideal. We constantly seek true one-piece flow because this is the least wasteful way to produce and seeking to do so will reveal all the mura (un-levelness) and muri (overburden) generating muda (waste).  On the other hand a buffer-less line tends to stop and start constantly because there is nothing in the system to absorb variation of any sort. I remember visiting the Smart car assembly plant many years ago – it was beautiful and kind of crazy. It was like looking at Ford’s Rouge dream come alive. The facility had been designed as a huge X with suppliers integrated on the production line into one huge moving conveyor. I don’t know where the plant is at now and whether they’ve changed the model, but at the time, one of the suppliers had two major gripes about the arrangement.

The first complaint was that every time there was a problem somewhere down the line at assembly, the supplier upstream would have to stop since there was no real buffer. mura down the line imposed high waiting waste on the upstream process – which went straight on to the supplier’s books. The supplier was paying an extra cost that led to tough price negotiations with the customer, and no real way to solve the problem at the supplier level.

The second complaint was unexpected but just as sensible. Since all personnel, suppliers and customers, worked and socialized together on the same location, information about wages got around and it turned out, not too surprisingly that the OEM paid better – which created a lot of discontent within the suppliers’ personnel. Now, that one, has to be a new form of waste, right? It’s obvious with hindsight, but who would have thought of it?

The Normal Abnormal
Buffers are the reflection of real variation in the process. If you take out the buffers without taking out the causes of variation, you simply end up with a process that works in fits and starts. If the process works in fits and starts, you can’t work with your people to develop standardized work, and so even kaizen becomes difficult. You lose productivity both from the non-repeatability of the job - operators are productive when they get into their “zone,” the effortless repetition of the right movement – and from the improvement ideas that originate from seeing abnormal situations hindering standardized work. If every day has “normal” abnormal situation, it’s hard to whip up the motivation to tackle them, particularly if it’s all causes by the overall system.

Back at the Gemba, we therefore need to study the causes of variation underlying the buffers. To do so, we don’t need much more than spending lots of time on the shop floor and look out for the 4Ms: Manpower, Materials, Machine, and Method.

In manual assembly lines, operators are likely to create two broad types of variations. Firstly, particularly when they’re new on the job, operators might work slower than the required cycle time – this slows the line and starves the next process. The buffer helps to compensate, because the person in the next process can take WIP from the buffer and not have to wait. The second variation will typically be a mistake or a quality issue, which needs to be corrected. Same thing, if it’s spotted at the next process, the operators can put the bad part aside and help themselves to a new sub-assembly. In lean, the way to work with operators to reduce these variations is andon. The operator calls the team leader to help when she’s late on the cycle or when she has a doubt about the assembly. The team leader intervenes to stay within the allotted time, or if there is a real problem, stops the line to get managerial attention and tackle the deeper issue. In general, the response to the andon call will be training of the operator by the team leader.

In my experience, missing parts tend to be the most frequent reason of putting a sub-assembly aside and pulling another one from the buffer. Along the line you usually find another space – not a buffer – with machines waiting for specific components. Most production lines now have their main components in some sort of kanban system with double bins, and so on. But this doesn’t solve the problem of specific parts needed for customized items. Keeping every kind of component in stock can be very costly as specific parts tend to run in thousands, and as suppliers of these parts are unlikely to be happy to ship them one by one. There are many debates there. The first one is that purchasing must understand that ordering one component might be more expensive both in terms of part price and transport cost, but still cheaper than purchasing a thousand at a lower cost per part. The thousand components will need to be stored somewhere and will drain cash until they’re used, which can be months. The second issue is that not keeping special components in inventory means relying on the MRP driven process to deliver exactly in time. This is okay, but in many cases, the supplier’s lead-time is longer than the customer’s expected lead-time, which leads to all sorts of problems. In general, between high runners in fixed quantity stock replenishment kanban and true exotics which will be ordered, well, on order, it’s useful to create a category of components where a small stock is replenished in variable quantity every time it is used. It might be more costly per part, but the overall cost is much lower.

Look Out for Tricks
Machine mistakes, slowdowns or breakdowns are also a main cause of variation. The andon concept originated from Sakichi Toyoda’s automated looms, and the principle applies to equipment as well as to operators. The key here is to have a local support structure that reacts quickly to every machine abnormality rather than waiting for serious breakdowns. This is by no means easy as most plant managers I know tend to be stingy in technical resources, and as many maintenance specialists I know are only interested in saving the day, but not keeping machines running sweetly. Oddly, although “standardized work” has spread quite widely in the industrial world, the Production Capacity Sheet which is one of the three core documents of standardized work can hardly be seen anywhere. This sheet records the maximum capacity for parts processing, with the time spent on manual work, the machine’s automatic operation time the time spent in changing tools, etc. Each supervisor can use this sheet to make sure that their equipment functions normally every hour of every day.

Finally, we come to Method – probably the trickiest source of variation when you’ve got many options. On a multi-model line we usually find that not all products are assembled according to a standard process – which means that if product one has the assembly sequence ABCD, product two might be assembled according to ACBD – which would mean to move the product ahead on the line to C station and then back to B. You probably deal with this every day, and chances are this leads you to bunch similar sequence products together. But then, you’re batching.

The issue is working with engineering to create a set sequence of assembly. But unfortunately, that’s not enough. When you look into the process further, you will realize that even though you have a set sequence for all products, there is a balancing problem: not all options require the same amount of work at each station. This is hard and can be attacked by three angles: balancing the sequence of products on the line, creating areas to externalize variation from the line when there is an extra load of work, and using team leaders to step in and help with some products. Neither of these activities is easy, and all rely on the supervisor’s superlative understanding of the detail of work on the line, product option by product option.

At the end of the day, you’re facing a difficult teamwork issue. Teamwork between engineering and production in order to design the product so that different options will create the least possible mura. Teamwork between your supervisors and operators so that they work every day at solving all small assembly issues in order to aim for standardized work. Teamwork with technical departments to solve quickly all machine issues.

By all means, have an ambitious target in terms of reducing the buffers, but don’t take them out on a whim. In this case, going to flow first requires building the organization’s capability to do so, which, in turn, rests on daily problem solving to build teamwork between the various stakeholders. In other words, this is an excellent lean project – no qualms about it. But it is also a very challenging one that will surface many deeper technical issues, and it’s worth going there with open eyes, step by step in true kaizen fashion.

Why Is It So Hard To Sustain Lean Gains?

March 13, 2012
Back to top

Dear Gemba Coach,

Why is it so hard to sustain lean gains?

The quick answer is that lean gains are simply unsustainable by nature. If I had a dollar for every visit to the Gemba where clients and I had to acknowledge that we’ve slipped back …

Let’s start by defining the problem as a gap between achieving gains and then sustaining them. I believe that gains are achieved once we have an alignment on three key areas:

  1. Having properly defined the business challenge (what are the few overall problems we need to solve and become really, really good at to succeed on today’s markets).
  2. Having broken it down into specific kaizen topics (sometimes all the way to actual repeatable workshops, not so much to solve the issue but to educate middle-managers and seek new answers to old questions).
  3. Driving teamwork so that functions cooperate in working on these two areas.

In terms of sustainability, I think I can now distinguish two different kinds of slippage: (1) we lose focus and the entire effort is in jeopardy or (2) we hit a setback on a specific point and don’t have the knowledge and/or energy to fight back.

Loss of focus mostly occurs when the company engages in strategic maneuvers. For instance, I currently follow two firms that have just been purchased. They are finding that the integration process is a huge challenge to lean work. First, people’s roles are redefined, which creates a lot of uncertainty and politicking. Second, organizations are changed, footprints redesigned, which creates more political wrangling. Third, such large shifts often involve ERP software or reporting, changes, which are enormously time consuming. It’s never fun to be acquired, of course, but from a lean point of view, being the acquirer is also hugely distracting, for the same reasons in the reverse – you’re now poking your nose into every one’s business in a much wider perimeter.

Sure, it’s hard to keep focused on kaizen when you’re fighting for your job, but that’s not the biggest issue. Increasingly, I find that real lean gains (that show up on the top line and the bottom line) stem from teamwork. Increased sales from better product quality are built on engineering and manufacturing working hand in hand to solve technical issues. Surging cash from reducing inventories while improving on time delivery come from planning, production and procurement working better together. Lower costs are mostly an issue of production, engineering, and purchasing looking for smarter assembly solutions and so on. Teamwork, in the lean sense of functions solving problems together, is not a natural state in any organization and requires constant effort from the top to get people to work together – with the occasional banging of heads until they talk to each other. In an environment where individual futures are in question and boundaries are changing without visibility, such teamwork is incredibly hard to maintain. One company I know had spectacular cash improvements year after year from the great teamwork effort of the operations, purchasing, and planning department heads – and lost much of its improvement in the year the company was purchased, only to recapture lost ground slowly as they refocused on working together as opposed to pursuing individual survival strategies.


Stuff Happens

The other frequent form of not sustaining lean gains is the setback. The main point of posting indicators at the Gemba is to facilitate the “no retreat, no surrender” discussion between management and workers. Stuff happens, and that’s a fact. Actually, reversal to the mean happens, and that’s a fact as well. I was recently in the shipping area of an automotive supplier where lean workers proudly showed me that they’d finally achieved one week at 100%. They got rather upset because I warned them they would be unlikely to maintain this performance because they had achieved it through effort (good) but they had not yet changed the process, meaning they should be mentally prepared for the rubber band to pull back, which it did the following week. Something always happens: a machine goes down, a supplier goes bust, customers change their mind, people call in sick and so forth. The trick here is to maintain the constant effort to not accept slippage. And this has a lot to do with respect.

kaizen, whether in the problem solving form or the improvement form is about getting a team to see its problems and work hard at trying new ways to come up with better and better countermeasures. Success is nice, but work is hard, and when the topic IS difficult, kaizen can be particularly frustrating because it’s a case of going back into the ring to get hit again and again until you’ve cracked it – staying power matters more than brilliance. Why would people do it? A few maniacs will tackle the issue for the thrill of solving it, in the spirit of mountain climber George Mallory who, when asked “Why do you want to climb the Everest?” answered: “because it’s there.” Most people aren’t built like that, but they will climb mountain, cross deserts and sail oceans for a leader they respect. In other words, they’ll stick to kaizen when the going gets tough for you. If you show them respect: if you make the effort to understand their constraints and to share with them what you’re trying to do and demonstrate that you can help them help you by taking obstacles off their path. There are many things you can do as a senior executive that don’t involve investment to clear barriers from people’s path so that they can experiment with their ideas and come up with innovative solutions.

As I noted, lean gains are unsustainable by nature. Any company works, after a fashion: put equipment and people in any one place, and they’ll produce something. The ball rests naturally at the bottom of the bowl. Sometimes this is enough to make a profit, until there’s a crisis or a new competitor drives you out of business. Lean, on the other hand, is about constantly stretching oneself to push the ball the higher up the slope that we can, and of course, like in the Greek Sisyphus myth, every stumble brings the ball back down again. Lean is about exploring what is possible in order to discover the satisfaction frontier for customers (what makes them SMILE) and the productivity frontier for operations. There is no steady state. Lean gains are generated by constant lean effort.

Lean practitioners and their bosses often find it difficult to forego the Taylorist myth that processes are “broken” and can be “fixed.” In this worldview, a process improvement team should have sustainable results because, having carefully analyzed the process, it has come up with a better mousetrap which it will implement and will perform better for now until judgment comes. But does that really square with what you see at the Gemba? Have you ever seen a process walk the shop? Is it real if you can’t kick it? What I see is people working with equipment trying to follow set sequences of steps and constantly fighting with the entropy of whatever new problem the world throws at them. process performance comes from cultivating individual ability to spot issues early and tackle them more than process design. I’m not saying that process design doesn’t matter, and certainly having less complex flows and more flexible equipment help, but if there’s one Gemba lesson I’ve learned the hard way (mostly by ignoring it and kicking myself for having done so) is: motion kaizen, then equipment kaizen THEN process kaizen.

process performance is the outcome of individual competence (mostly the ability to do the job in unforeseen circumstances) AND teamwork (the ability to work together across barriers).  Lean gains are hard to sustain because both these drivers are in constant flux. One way of looking at this is visualizing individual competence and teamwork as two stocks that deplete naturally by attrition and need to be constantly replenished. The replenishing mechanism is, of course, kaizen. Through kaizen, people are challenged both individually in trying to solve new problems or do things better than before, and as a team in making greater efforts to work together.

Designed for Teamwork

How can we sustain lean gains then, knowing that companies will restructure and operations will go wrong? What you first need is a defensible position: a kaizen event that the company, as a whole, acknowledges is directly link to its effectiveness. In the automotive company I previously mentioned, they’ve narrowed it down to three events:

  1. Flow and layout workshops in assembly
  2. SMED for the injection presses
  3. Target cost workshops in engineering

These kaizen events are specifically designed for teamwork. For instance, the flow and layout workshops ALWAYS involve manufacturing engineers because the purpose of the workshop is not to make instant productivity but to increase the company’s ability to be more productive ongoing, which is about getting production supervisors and manufacturing engineers to better work together.

Of course, the company does many other lean things such as pull system, dojos, etc. but the core agreement is that the schedule of events will take place. This is no kaizen blitz. These events are formal workshops in which the same issues are tackled time and time again to change minds about the real sources of productivity (they’re “katas” to use Mike Rother’s terms). The aim is to increment the number of repeated cycles at looking at the same typical problems until we find breakthrough solutions.

Having this stake planted in the ground, it’s possible to fight the real sustainability issue of management attention. The workshops deliver global gains as long as senior management stays committed to go and see and to practice the cycle of:

  1. Visualizing activities.
  2. Formulating problems.
  3. Seeking root cause.
  4. So we can study countermeasures.

Real company-wide gains occur every time a senior execs has an “aha!” moment by seeing what one of the kaizen teams has come up with and changes his or her mind. Whenever the CEO changes his or her mind, consequences WILL follow.

Lean gains are the result of a dynamic of constantly striving to kaizen and to understand how the countermeasures coming out of kaizen impact our wider challenges. There is no steady state where lean gains are achieved and we can move our attention elsewhere. There are no “gains” as such, just moving the ball higher up on a slippery slope, where it takes constant creative effort to keep it there. Yes, overtime, some competences and shared practices are acquired. And no, it’s never stable, as you’ll see at every upper management change: new exec, new learning needs, and new educationprocess.  The trick is to be clear on:

 

 

Main business challenges

Who should we develop?

kaizen practice

Does it work? If not, why?

Should we change something?

1

 

 

 

 

 

2

 

 

 

 

 

3

 

 

 

 

 

 

Because no one (none that I know, for sure) can either foresee or control larger events, the one thing you can do is stick to your regimen of training. Just as you can’t control the state of the economy but you can commit to your morning jog, you have to accept you can’t control strategic maneuvers or anticipate every operational setback, but you can commit to a program of regular kaizen events (read: learning practice).  You’ll find that if you’ picked wisely which event to focus on (an event that makes you better and better at your trade), maintaining the steady practice of stretching understanding and teamwork will maybe not stop you from falling back down the mountain when you misstep, but will hold you pegged so that you don’t scramble all the way down to the bottom: Sisyphus’ lean curse can be defeated like everything else, through regular practice.

Can Hospitals Reap the Deeper Benefits of Lean?

February 29, 2012
Back to top

Dear Gemba Coach

As Health Systems globally wrestle with skyrocketing healthcare costs, many hospitals are jumping on the lean bandwagon, hoping this will be the silver bullet that delivers improved outcomes at lower cost. Is this a valid justification for implementing lean in hospitals, or is the cost-saving rationale as a driver of the process doomed to failure?

Thank you for this thought-provoking question, although I’m a bit at a loss on where to start to try and answer, as I’m not sure we have the same understanding of “lean”. The lean ideal is indeed the complete elimination of waste, mainly to improve customer satisfaction and, yes, to get costs down – but experience shows time and time again that considering costs without putting customers first lead to bad, bad mistakes, all the more so when your customers are patients. Furthermore, to some extent, lean will indeed remove obstacles that hamper workflows, but as with costs, this is largely an outcome more than an input. Workflows are the result of what people do, particularly in a hospital where so many different professions and specialties are involved in treating one same patient. One of the foundational principle of lean was expressed by Kiichiro Toyoda’s belief that: "the ideal conditions for making things are created when machines, facilities, and people work together to add value without generating any waste."  As a result he conceived the methodologies to eliminate waste between operations. The Taylorist worldview (of people as essentially cogs in the machine) still rules and we tend to assume that the best way of achieving this is designing a better process and making people apply it. In lean, the Gemba has taught us different: the challenge is indeed to make people, machines and facilities work together to see the waste they generate, understand the causes and progressively increase their value added.

Keeping these points in mind rather changes one’s perspective regarding your question. A couple of years ago I did a Gemba walk in a large hospital. We started with a difficult discussion about the dismaying state of disrepair and general shoddiness of the emergency admissions. From working for years with health professionals I’ve come to accept there is a secret ingredient to treating patients successfully: trust. Increased trust heals patients. Less trust makes them sick. The first impression of the emergency entrance has a disproportionate effect both on patients’ trust and staff’s expectations of themselves.

As we argued, the full story came out that the hospital’s top executive had 1) invested massively in a new facility to centralize testing and sterilization and 2) the cost improvements were late in coming and so 3) there wasn’t a dime left to hire more cleaning personnel or pay for a coat of paint. Then they went on trying to convince me that the new modern facility had been designed in order to improve the workflows. They truly believed they were leaning the previously complex process by simplifying it. In actual practice, they were making the situation worse by throwing investment money at an issue without first understanding it.

So we walked the wards, looking at everything first from the patient’s perspective, and then from the nurses’ and doctors’ point of view. As we did that a thousand and one details jumped out, mostly about procedures not followed (for good reasons on the spot, but the procedure is there for a reason, it’s a hospital!), and of equipment looking dodgy (again, no money, but hey, it’s a hospital) and everywhere we heard stories of overworked understaffed wards (headcount reductions because of the financial situation, but… well, you get the idea). So, certainly, many problems are created outside the hospital’s control, but how about starting with the issues the hospital can fix (even if its management often doesn’t want to)?

Where do we start? Hospitals are so huge and complex. Ideally, we’d start head on with patient mortality – where it matters most, but in this specific case, it was politically untenable. The hospital Quality and Continuous Improvement director chose to start on a few issues he felt he could tackle:

  • The general state of admissions areas and waiting areas for patients
  • The working conditions in the treatment rooms
  • The first incision in operating theatres

In these three cases it turned out the issue was not the process, but indeed how well professionals worked together. On the general maintenance or admissions area, improvement was a matter of talking to the ward managers about getting their teams or sub-teams together and seeing issues. They immediately had ideas to improve the situation, but every conversation started with a request for a budget. After some back and forth, it was decided that they would first do what they could on zero budget and, as a result of their improvement efforts, come up with a shopping list of things they really needed to replace. No magic bullet here, but over time, many areas of the hospital improved visibly. Staff learned to look at their environment with the patient’s eyes and organize themselves differently. The Quality director fought for small budgets where they were needed. As this process went on, trust was rebuilt and people realized they could do far more than they’d expected, even on very tight budgets.

As this first issue progressed, the poor state of treatment rooms became increasingly apparent, but there, the same method hit against the wall of “too much stuff, not enough staff.” Every storeroom was overflowing and made space control very difficult. The quality director’s challenge was “zero out of date” and teams tried hard. They also did their best to empty all surfaces to clean them thoroughly, but again there was so much stuff piled up that it was near impossible. As they looked into the matter it became apparent that the external platform hired to reduce the logistics costs did so by delivering wards from one week to two months of consumption of consumables. The challenge became “everything every day.” Now, this does sound like process improvement but in truth it was again nothing but a big teamwork issue and political fight, the logistics director simply not wanting to hear about it. She dug in her heals and flatly refused to see the huge waste she was creating by the method she chose to supply wards. Here, you see the core of the lean transformation, when each professional learns to see the waste they generate on upstream and downstream processes and start making a genuine effort to understand their colleagues problems.

In this case it became apparent that the key to treatment rooms control was not within the wards control but with logistics. It was a case of what you’re saying: outside the ward’s control. Yet, still way within the hospital’s control. In this case, the quality director had to confront the fact that the main barrier to progress was his own relationship with the logistic director. I don’t know where they’re at now, but last time I visited there were hopefuls signs of progress. It was still incredibly slow. Logistics continued to consider that ward problems were ward problems and logistics, logistics – which is exactly what happens when you lose sight of the patient and start considering costs as if they have an existence of their own and not respective to a purpose.

Which brings us to getting operating theaters started on time, an issue you’ll agree has a huge impact on overall costs since it impacts operating theatre utilization. On the basis of these previous experiences, the quality director now realized it was first a question of relationships, with surgeons this time. Rather than address this head on, he started by asking nurses to simply monitor on a visual form the daily hour of first incision and involved a few willing doctors in analyzing reasons for delays. This, again, proved to be an eye opener. With very few exceptions, few surgeons behaved as the late-because-I-was-playing-golf stereotype would suggest. What did happen is that very few trusted the planning system because of all the changes, rescheduling, double reservation and so on. Again, the hospital had tried to modernize its scheduling system by taking it out of the hands of the ward matrons and creating a computer system in that every one could access with their own priorities – including the medical secretaries. The result was absolute chaos. After months of failed experiments, they finally agreed that one matron would become a “master scheduler” in lean parlance – she’d handle the computer, come up with a proposed plan for the coming week and check with each surgeon in term with a “one amendment rule”: you could change one slot but not to (other than for patient issues). The completely surprising upshot was that surgeons were by and large happy with the proposed schedule so long as it didn’t change so that they could plan the rest of their week. This work led to gaining half an hour of operating theatre utilization per day.

Now, these examples are unique to this hospital and one of the frustrating aspects of lean is that there is no cookie cutter approach, no matter what consultants would like you to believer. This is the magic of the Gemba – you have to take each case as it comes, with fresh eyes and open mind and try to figure out what is specific about the new situations even when you’ve seen it all before.

What I’m trying to say is that, effectively, you are right, if you try to remove obstacles that hamper workflows in such complex systems you’ll soon hit upon barriers over which you have no control. Agreed. But I don’t believe that’s what lean is about. Lean is about getting people to work together to look at their own workspace and try to see the wastes they create for their patients and their staff, and figure out the deeper causes without guilt or blame: most causes are technical decisions that might make sense in isolation but have unforeseen cross-impacts on others. In an environment as complex and interconnected as a hospital, understanding the ins-and-outs of technical choices is a key issue, and not an easy challenge.

So how can we work at making machines, facilities, and people work together to add value without generating any waste? The first step in healthcare seems to be building better relationships by going to the Gemba and discussing what the ideal should be. Healthcare is vocational: doctors are there to cure people, nurses there to care for patients, and usually they’re more than happy to talk about eh gap between what is and what should be. Once a clearer image of shared success emerges, it’s then a matter of trying things until we find pragmatic solutions for problems. No magic bullet there either, as often every new idea hits a new constraint for someone no one had foreseen, but the revitalizing part of this work is seeing how many people you’d not thought of start putting their shoulder to the wheel and helping – I can’t tell you how much hope I get from seeing this time and time again.

But all of this requires a radical change of mind at the top. Rather than look for that silver bullet, for that brilliant new system-level design that will make all our problems go away, we must start getting interested in the “one second of waste” to use Tracey Richardson’s great image (http://www.lean.org/a3dojo/LatestColumn.cfm#tabAnchor) - all the small pebbled that get in the way of every operator doing there job well. I know it sounds incredible, but it’s by focusing on real work by real people that we will start to understand how all of this adds up into gigantic waste. On the other hand, most system-level solutions I’ve witnesses such as the centralize lab facility of the new theatre scheduling computer system never quite hit the spot (I’m not arguing against computer systems per se, and I’m a huge fan of patient records information and so on).

As my father is fond of saying, practicing lean is practicing helicopter thinking: we must constantly go from the most detailed (and landing a helicopter is particularly tricky) vision of the Gemba to the high-level picture of the purpose of our processes in terms of what our products do for our customers and how we deliver it to them at the minimal cost. Lean starts with getting senior executives to realize how great a teacher the Gemba can be and improving working together by solving specific issues across functions before worrying about fixing overall processes. In doing this, they’ll discover there is much, much they can accomplish within what is in their control by involving every one, every day.

Lean and Forecasting

February 22, 2012
Back to top

Dear Gemba Coach,

I’m in charge of the forecasting department in my company. My colleagues in production have been doing lean for several years and complain about my forecasts, particularly when it comes to what they call leveling. I have come across your column on lean.org and wondered if you could help out with some advice on how to forecast in a lean way?

Wow. Interesting and difficult question. There are a number of angles to this question, so let me attempt to clarify the topic somewhat. First, there are many different beliefs among lean practitioners about the reliability of forecasts (contrary to common opinion, experienced lean practitioners do not believe that all forecasts are wrong). Secondly, this issue translates into determining how to turn forecasts into leveled production plans and who owns or manages the inventory of finished products to absorb customer demand variations. Thirdly, there is the simple challenge of learning how to improve the exercise of doing forecasts themselves.

Please bear with me for the lengthy response to your question—but I must point out that there are many facets that are covered here. I guess the main point is that, in lean, surprising as it can be, we don’t try to forecast accurately. We try to have a robust ballpark idea of where the total volume of the market will be and then adapt our production processes to be flexible for last minute mix changes. Overall volume is about capacity planning (which doesn’t need to be detailed, but has a huge impact in terms of capital costs) whereas day-to-day mix requires production flexibility. Robust ballpark figures enable us to calculate takt times (which can’t always be changed easily), but on the other hand detailed day-to-day forecasts don’t help as we’ll try to follow real-time customer demand. This is the main change of emphasis for forecasters: better overall volume forecasts, and less detailed predictions.

In this sense, lean thinking assumes that volume can be forecasted quite reliably, but not mix. This means, for example, that from one year to the next, we can make reasonable assumptions about how many people will buy coats for winter in any given town. We can have high-level models of what percentage of the population will renew their coat. If we know people buy a coat every two years, this means that 50% of the population will buy a coat this year (with cars, for instance, the market is estimated at 10% of the total automotive park a year). Such estimates can be easily tested by traditional forecasting methods from historical data. The assumption is reasonable because it reflects an underlying process: so many people will purchase so many coats.

Predicting the Future

On the other hand, what is extremely hard to predict is what kind of coat will they buy: will the fashion be dark or light? Short or long? From historical data, we can tell that people will buy a certain amount of short coats every year, and a certain amount of long ones, but there remains a sizable portion of coats where long/short is decided on the spot according to the vagaries of fashion. This is very hard to forecast, unless you know someone with a good crystal ball.

The other thing you need the crystal ball for is knowing exactly when it’s going to get cold and trigger the coat-purchasing action. If cold hits suddenly in early fall, and you don’t have the coats available for sale you’re going to lose sales you’ll never recapture for the entire season (and which will lead you to unreasonable rebates later on to try and flog the stuff you’ve finally brought online). Conversely, if you get into the season with a huge pile of coats and cold days come late, fashion might have moved in an unpredictable way and you find yourself with a pile of coats people won’t buy (again, unless you discount them). Not fun.

So the lean assumption is that total volume is fairly predictable (worst case, predict what sales volume was last year), which makes sense because of the law of large numbers (the results of large samples are more trustworthy than smaller samples, because large samples have less variations than small.) Yet specific demand for options or models is very hard to predict from one day to the next. As a result we can separate forecast in an overall envelope, and then project the lowest quantity purchased for each option or model, and accept that there is an unpredictable part as a percentage of the whole. Not comfortable if you are a forecaster, but fact of life.

As a result, one can identify a few things that a lean forecaster should be very good at. First, tracking overall volume and producing as accurate as possible estimates of minimum, maximum and average expected total monthly volume. This is the basis of capacity estimates for the coming period. The second is to pick up and respond to rapid signals from the market to make educated guesses about the mix. The best forecast for the weather remains to predict yesterday’s weather and minding the signs for a sea-change. The forecaster needs to learn to identify the proper signs of immediate change and try to make short term guesses, not long term.

MRP Pain

Now to scheduling. The big, big lean change is that we learn to see that most variation is created demand, as opposed to real market demand. MRP systems start scheduling by looking at customer orders, seeing what is in inventory, checking the level of safety stock and then producing a work request by the magic formula of CUSTOMER ORDERS – inventory + safety stock. Then it looks at batch sizes (in the system), capacity (in the system), and then produces a work order which gets sent to the shop floor, where it is then adapted to the issues of the moment. The magic formula turns out to be a great multiplier of variation. Suppose the customer is not ordering so much today, the inventory increases from yesterday’s production, so the calculated demand lowers, which is sound enough, except that the effect is not felt right away because of the batch sizes and the queue. Now, tomorrow, the customer orders double: the average, plus what he didn’t order yesterday. This creates a peak in calculated demand, just as production was reducing the production of these parts and so on. Daily pain.

The biggest difference with the lean model is that the planner will own the finished product stock. The planner now has to make trading decisions. The idea is to propose a production plan where the quantities of As, Bs and Cs to pick up from one line are the same every day for each day of one week. This means that the finished goods stock of As, Bs and Cs absorbs the natural variation of customer demand and buffers this information towards production: you stop adjusting production to every variation of your inventory. Essentially, as long as the inventory doesn’t hit the MAX alarm level or the MIN panic button, it’s left free to vary randomly. The trick lies in estimating correctly the correct MAX – MIN bracket to hold in stock, and this can be adjusted from one week to the next.

The question now becomes very different: it’s no longer about how many parts do I need to replenish, but how quickly will I get parts to replenish. The scope of inventory variation depends both on customer real variation, but also on replenishment lead-time, which means reducing batches. With smaller batches on the same cell, I can have a higher safety cushion with a lower overall inventory. This is classic lean stuff, but the trouble is that customers use MRPs as well, so many customer order fluctuation are also created demand. More pain.

So the third thing a lean planner has to be really good at is creating a stable, level weekly plan where it warns production that it’s going to pick up the same amount of As, Bs and Cs per day for every day of the coming week (barring holidays, shorter hours on some days and all other stuff one learn to work into the plan). In essence, it allows production to have a takt time by averaging the customer demand. Whether production chooses to make this in huge batches and hold huge stocks or in smaller batcher and have lower stocks in production’s problem, but what it doesn’t mean is that you need to physically distinguish inventory owned by logistics to cover customer demand from inventory owned by production (and kept in production area) corresponding to the batch size. With the pull system, planning is telling how much it will pick up in the day, and now logistics will come and withdraw a few boxes of As, Bs and Cs every half-hour: fractioning and mix, but this is a production issue, not a planning one.

The surprising upshot of this mental shift is that you will need less planners in terms of brute force, but will become desperate for a really good “master scheduler” to create the volume forecast and the short term leveled production plan. This is more a matter of skill and judgment than massive calculation and sophisticated software.

Don’t Forecast, Understand

None of this is easy as it requires a few serious mental makeovers. As always in lean, the key to these issues is to deeply understand the problems we’re trying to solve:

  • First, we’re not so much trying to forecast as to understand our market. We need a model of the overall market consumption (what are the drivers) and so we need to get better and better at understand what moves a market and drives seasonality, such as it is.
  • Secondly, we need to make short-range guesses in terms of which specific product customers will want now! This means working hard at improving the early warning system and having real-time information about what customers are doing right now. For instance, if your customer is also a business, its own production plan is not a state secret. Rather than forecasting on the historical data from customer orders through its MRP, you’ll better use your time by getting to know your opposite number who schedules the customer’s work plan and understand what they aim to build in the coming week. If you’re working B to C, then, same thing, rather than focusing on what’s held in the warehouses, you need to get real-time point of sale information to figure out what customer preferences are right now.

By understanding the overall volume and the immediate mix trend, you can then figure out the max/min tunnel for your key products and use your finished good inventory as a “shop” – improving your trading decisions of how much variations (hence inventory levels) you allow for, and when you hit the panic button (as in stop building more, or build some more immediately). You can measure your skill as a planner at (1) On-time-delivery, (2) inventory level and (3) the number of times you ask production to make an extra effort to save the day.

  • Thirdly, you need to constantly improve your ability to give production a leveled schedule (the same quantities every day) and not panic on Thursdays and yell “forget the plan, I need more Cs”) – this ability is of course linked to the two previous points, but, per your question, your production colleagues will LOVE you if they now can work with stable schedules.

Well, love you, maybe not. The whole thing hangs, of course, on production’s ability to produce in small batches – to improve its flexibility, so that it can react swiftly to mix changes and solve your inventory problems (and theirs). Which often comes down to … relationships.

  • There is a fourth skill you need to improve as a forecaster and planner, which is the quality of your downstream relationships with your internal customers and your upstream relationships with your internal suppliers. To lean the process, you need to get better, fresher information from the former and more flexibility from the latter. This is not a small challenge as they often won’t understand what you’re after.

Most conflicts, I find are born of misunderstandings of intentions – there are two aspects to your question: sure the technical side of “lean” planning and scheduling, but also, the realization that forecasting, planning, and scheduling are essentially teamwork jobs and that we need to repeatedly discuss issues across functions, in order to share a common understanding of (1) what we intend to do and why, and (2) the practical barriers that always come in the way. In most of the firms I can think of that have been successful with lean, the planner (master scheduler in our parlance) often becomes one of the most important people in the firm: he or she is the helmsman of the ship!

How should I assess the success of our lean progress?

February 14, 2012
Back to top

Tricky problem. I’m not sure there’s any real way of assessing lean progress, although most corporate programs will try at some point or other. About 20 years ago, my father was one of the first to develop “roadmaps” for lean. These resources identified dimensions for lean progress, such as quality or just-in-time. They settled on five levels and then did a mammoth job of identifying which exact practice should reflect, say, level four on just-in-time. I’ve still got the original roadmaps somewhere and they spawned an entire consulting industry of implementing lean by following the level-by-level applications of all the tools and practices. In the end, it turned out that although the roadmaps were useful to clarify what the company was learning with Toyota’s tutelage at the time, they were a poor guide to lean progress. Since then, I’ve seen many “roadmap” driven programs which keep lots of people very busy, but without much to show for it.

Management loves roadmaps and assessments because these exercises are very reassuring. They show where we want to be, where we are, and the milestones to get there. This plays into what management does: find the solution and execute. And yet … we’ve learned (often quite painfully) over the years that lean is a learning system, not a management method: you train and develop people, and as they become better at what they do, performance improves. There is a dotted line (as opposed to a straight one) between managerial action (training and developing) and results. And while the results are actually greater and quicker than by the traditional management direct action approach, many executives are profoundly uneasy with the model of training and trusting as opposed to directing and controlling. This is a very old story and not about to change any time soon. As a result, I don’t believe there’s any way of assessing lean level or lean progress in pure learning terms, which is always tricky. What we can assess though are (1) financial results, (2) performance progress and (3) lean efforts.

Get Physical

Here’s the most important thought regarding this: ultimately, the aim is not to implement lean but to become lean. And this should appear on the P&L in terms of increased sales, better cash flow, increased profitability and lower relative capital expenditure. If you’re not aiming for significant results at this level, you’re probably doing something fine such as operational excellence, six sigma, or world-class manufacturing, but it won’t be lean. In Art Byrne and Orry Fiume’s terms: lean is a business strategy, not a manufacturing tactic. If that point is missed at the outset, you can evaluate progress all you want, you’re unlikely to transform your company’s position on its markets.

As Orry also points out, financials are nothing more than a price multiplied by a physical quantity, or a cost multiplied by a physical quantity. They are indicators based on actual performance and are subject to all forms of adjustments. Which means that improving the financials starting at the P&L makes about as much sense as trying to accelerate your car by turning the speedometer needle. If you want better results, you need to improve physical performance.

And physical performance is relatively easy to assess. On a monthly basis you can track specific physical indicators that reveal whether you’re better, equal to, or worse than you were at a fixed point (say end of year figure last year):

Indicator

End of Y-1

Current month

Better

Same

Worse

Accidents

OTD

Customer complaints

Internal ppms

Days of inventory

PPH

OEE

Suggestions

Absenteeism

There is no direct one-to-one relationship between any one indicator and the P&L. But by examining the financial numbers and then studying your performance indicators, and seeing how they correspond, you’ll build an understanding of what goes on in the company and how relatively well you’re doing site to site.

Which brings us to the third part of the assessment: how hard are we working to obtain these results? I’ve just come across this issue in a company that was recently purchased (partly because of its spectacular lean results under the previous CEO). The new owners have a very traditional cost-reduction “lean” program based on the usual mish-mash of spot kaizen workshops and the purchased management team is scratching its collective head to figure out a way to explain what they’re doing, how they previously had results, and why the new system is not delivering. For what it’s worth, we’re come up with five dimensions of effort:

  1. Following our customers: how hard we try to satisfy customers now by solving their usage problems and develop new offerings that do so better
  2. Accelerating flows: essentially about reducing lead-time end-to-end
  3. Developing people, specifically by stopping at defect and solving problems rather than working around issues (this includes working with suppliers)
  4. People involvement: what efforts do we make to involve employees in improving their own workplaces
  5. Gemba focus: how much time do we spend at the workplace to go and see, get people to agree on their problems, train and think deeply about our issues

I’m not claiming this is universal—it’s simply what one company came up with. It’s worked well for them—and in fact they’ve been using it with their suppliers. On each of these dimensions we self-assess effort on a one-to-five scale: for no effort at all to main effort. This is the assessment grid we came up with:

The list is clearly not exhaustive, and should be thought widely as applying to, say, engineering teams and suppliers as well as to production. I accept that it’s kind of silly to even try to reduce lean to one page, but one good point of this assessment is that it reflects the system nature of lean: if you draw a radar chart of your score you’ll soon see how balanced your vision of lean is and we all know by now that focusing on one aspect and ignoring all others simply does not pay.

Assess Learning

I’m not fonder of assessments than I was before. I still believe these are dangerous tools that can become bureaucratic exercises that can get in the way of deep thinking; and they can lead one to become grade-focused and miss the point of learning altogether. On the other hand, one-to-five self-assessments of efforts can produce tangible benefits to managers trying to clarify their overall lean work. This grid might help you reflect on how hard you’re trying. Be warned: this was conceived as a self-assessment, not a third party audit.

Personally, I try to assess learning: what do we understand now that we didn’t before. But I’m fully aware this is too subjective for management. Still, the question remains, lean’s aim is to develop deeper understanding, which in turn, generates better results. I don’t know whether this will help but these are my personal guidelines to evaluate thinking progress:

DATA + CONTEXT = FACT

FACT + UNDERSTANDING = KNOWLEDGE

KNOWLEDGE + RESPECT = WISDOM

Ultimately, results are obtained more by solving the right problems than by solving problems right. The tricky part of lean is that the right problems tend to be the most difficult (or where we know the least), so we rarely solve them well (which terrifies traditional managers), but, on the other hand, as we doggedly keep on trying (and often failing), the situation changes and the company improves radically. In the end, I can’t think of any assessment that evaluates whether you’re focusing on the right problems other than spending time with a sensei at the Gemba.

Five Whys

February 7, 2012
Back to top

Dear Gemba Coach,

I’m a lean coach and teach A3s in my company. Every lean book mentions “5 why,” and I can see the power of it in theory but I struggle with it in practice. Any tips?

First of all, pat yourself on the back for admitting that you find “5 why?” difficult. I’ve been doing Gemba walks two or three times a week for longer than I care to remember and can’t recall more than a dozen instances of truly insightful “5 why?” analyses. I clearly remember the last case, a few months ago, in a company that manufactures industrial equipment. The production team was trying to understand a recurring quality problem and finally hit upon the fact that two core elements of the product were not interacting as expected. A member of the engineering department was part of the problem-solving group, and he accepted to take back the issue to his colleagues, where it finally revealed that an opinion commonly held by all engineers was false: they had the wrong mental model about how their product worked. Consequently, they experimented until they fixed the issue on this specific product and are in the process of checking all others. As you can imagine, several planets have to align for this sort of problem to get resolved. First, production doggedly continued to pursue a quality problem it had previously given up on; second, it got engineering involved (such teamwork is never a given, not in this company or in any other I know); third, they rigorously tested factors until narrowing it down to the one they previously thought could not have an impact; finally, they kept asking “why?” until they concluded that their thinking about the physical interaction of components was wrong. It was a truly magical “lean moment” but, on the other hand, it doesn’t happen that often. Many “5 why” exercises I’ve witnessed, remain superficial, run in circles, or end up with changing the process without having first understood the problem (and thus investing on a solution and later on finding out the problem persists).

Let us apply lean thinking to “5 why”: what is the test method for a proper “5 why?” analysis? process performance gaps are an indication that you are controlling the wrong set of parameters – if you know what parameters affect process performance you fix the problem quickly, it’s a matter of turning the dial back to its standard value. In many cases however poor process capability stems from the fact that we simply don’t know what the driving parameters are. A successful “5 why?” analysis is one that leads you to discover the proper controlling parameter. In Ohno’s classic example (From his book on the Toyota Production System):

  1. Why did the machine stop? There was an overload and the fuse blew.
  2. Why was there an overload? The bearing was not sufficiently lubricated.
  3. Why was it not lubricated sufficiently? The lubrication pump was not pumping sufficiently.
  4. Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
  5. Why was the shaft worn out? There was no strainer attached and metal scrap got in.

We can see him shifting from the demand on the machine to the lubrication of the bearing, to the working of the pump, to wearing of the shaft, to the protection of the shaft: in order to solve the problem, we no longer control the overload of the machine, but the inflow of metal scrap in the pump. This classic example also demonstrates why “5 why?” is so tricky: in the same situation anyone with less intimate knowledge of the workings of the machine could have answered differently and taken the “5 why?” to a completely other conclusion. The test measure of a successful “5 why?” analysis is when it has led you to change your mind about what driving parameter to control in order to deliver process capability.

This, in turn, reflects exactly the kind of deep thinking the “Thinking Production System” is supposed to develop. Most technical problems are multi-cause, multi-impact (anything simpler can be solved simply by looking at it). Toyota-style problem solving is about learning to turn a multi-cause multi-impact problem in a one-by-one cause-effect problem by identifying which cause (of all potential factors) is responsible for the largest impact (of all potential impacts). Developing the knowledge to correctly substitute the right cause-effect model to a multi-cause/multi-impact situation is, in effect, wisdom – and requires hours of practice on narrow technical problems. This kind of wisdom allows you to then start the “5 why?” analysis at the right place. If not, who knows where you’ll end up. The key to a successful “5 why?” is a correct grasp on the current state. Without a narrow, specific description of the current state, asking a series of “why,” is likely to lead you… just about anywhere.

A lot of hard work needs to be done before embarking on the first “why?”: potential factors causing the problem have to be identified and tested one by one:

Factor

Impact

Confirmation method

Confirmed (Yes/No)

 

 

 

 

 

 

 

 

As Art Smalley described in the paper we wrote together (The Thinking Production System), in his first problem solving in Ohno’s engine plant he had to test over ten factors before hitting on the fact that the machine was producing defects because the lubrication liquid was contaminated by bacteria. When he proudly announced his findings to the supervisor (after arduous work to figure it out), the supervisor simply asked: “why was the liquid contaminated?” Art had the correct factor to grasp the current state. Now he had to figure out the root cause.

In my experience it takes a definite maturity for problem solving groups to actually stay the course and do the cause search properly. In most companies, the group just wants to “fix” the issue, and find the first way they can to make the problem go away. “5 why?” has a completely different aim: developing the technical expertise of the people conducting the analysis by finding the correct root cause. The companies I know who are getting there tend to speak less in terms of general processes and more of narrow, specific technical expertise. They come to see that:

  1. The leanness of your processes is a reflection of the technical skill of the people in the process: more skilled people can run a tighter ship, and on the other hand, leaning a process without the necessary skill just leads to a well designed poorly performing process;
  2. “Lean” is not a thing in itself but a method to develop towering expertise and teamwork (to take Jeff Liker’s terms in The Toyota Way to Lean Leadership), which, in turn leads to better judgment, leaner processes, and sustainable results.

Many managers I meet are uneasy about this. They like the straight line of fixing a process: they can ask (change this) and see a direct result (or not, more likely). The dotted hand of training people and then seeing results improve, although experience shows that it is more effective time and time again, is harder for many managers: it takes a leap of faith in people’s autonomy and attitude they seem unwilling to take. Yet, we all know the economic value of common trust.

To answer your question it’s hard to have specific advice on how you conduct your “ why?” so remote from the Gemba other than reflecting on your expectations of what the “5 why?” analysis is and does. To correctly practice “5 why?” you must first master:

  1. Having a clear mental picture of how the technical process should work
  2. Being able to identify correctly the point of cause where the technical process is misbehaving
  3. Listing the potential factors of this variance and testing them one by one until you can confirm the main cause-effect relationship
  4. And then asking why?

“5 why,” cannot be practiced at a generic level – it’s a practice to develop deep, narrow-specific knowledge and makes little sense if divorced from the actual technical process it’s being applied to. The greater the expertise, the most relevant the five whys; the lesser the expertise, the more dubious the five whys. I am not saying you shouldn’t practice “5 why?” at every opportunity, it’s a great way to get people to think further than the immediate work around, but that you should accept that the outcome of the exercise is very linked to the depth of technical understanding of the people carrying it out. In effect, the first step to conducting a “5 why?” analysis is to estimating the expertise level of the people in the group and, if necessary, inviting in more knowledgeable people to steer the discussion.

Like any lean tool, “5 why?” is a practice and can’t be taught other than by repeatedly going through it. It takes about 10,000 hours to master any skill, so don’t let yourself be discourage and keep practicing it at any opportunity, but try to keep the ideal in mind - better understanding cause-effect relationships in technical processes – in order to get the full value of every “why,” you ask.

Gemba and Quality

February 1, 2012
Back to top

Dear Gemba Coach,

We’ve made good progress on quality with Six Sigma, but we’ve reached a plateau. I’ve met a lean consultant who tells me I should spend more time on the shop floor, but I fail to see how it would improve quality?

Good question. The link is not immediate and many who have tried “management by walking about” have been frustrated by the lack of visible impact, beyond initial low-hanging fruits. Let’s take a step back. Things improve if there is some sort of improvement – learning  mechanism in place, right? We don’t go to the Gemba open eyed, just to “see” what’s going on. This is more like industrial tourism, and it gets tedious and is annoying to the staff. Gemba walks are all about checking that our improvement strategy is being implemented at the right pace to get the intended results. Going to the Gemba is about checking (1) clear control points (where do I see that results are forthcoming) and (2) how good the improvement process really is (are people filling out the paperwork or really thinking deeply about their issues).

Quality is a difficult topic, and there are a variety of improvement mechanisms to implement in order to break the common barrier of rejects accounting for 2% to 5% of sales. I remember once showing a sensei our efforts to get quality rejects under 1% of sales and he just said: “add a zero.” It took me a while to figure that the challenge was to move from 0.9 % to 0.09 %. Let’s take the issues in sequence.

3 Duties

First, quality defects still reach customers. This means that someone either during the process or at final inspection made a mistake (an honest one) and packaged a defective product to ship to the customer. This is a basic containment issue. They didn’t see there was something wrong with the part. As employees are NOT GUILTY, going to the Gemba is the way to step into the cell and ask oneself: would I have spotted that bad part? The chances are there is nothing there to help you in terms of:

  • Constant training of operators in observation
  • A reaction system that encourages them to signal doubtful-looking parts.

Within the lean framework, frontline workers have three basic responsibilities:

  1. Follow standard work and work accurately without mistakes in quality and safety
  2. Report any abnormality to a more senior person
  3. Participate in kaizen and teamwork activities, and propose kaizen.

None of these missions are easy in themselves, and, at the Gemba we ask ourselves whether the organization we have in place helps or hinders operators to fulfill their responsibilities.

Melding Observation and Action

On the quality front: how often are operators trained to Deming’s Quality 101 principle of distinguishing a bad part from a good one. This is by no mean simple as many bad parts at customers were tested but allowed to go through because they were considered “borderline” by the line. Defining and teaching boundary conditions is an essential job of the quality department, to help value-adding staff to see the difference between a bad part and a good one. One key role for management on the Gemba is to ensure this process is in place and working properly. Ahem.

Secondly, what can an operator do if they have a borderline part? In most industrial companies I know, not much. At best, put it aside and never hear about it again. The “andon” system in lean blends observation and action. When an operator has a doubt about the part (it feels wrong) they pull on a cord which calls their team leader (a more senior operator, but not a manager) who knows enough of quality standards to decide on the spot whether the part is okay or not and whether something obvious can be fixed in the process (operator not following the standard).

The team leader has about one minute to make that call until the line stops and frontline management comes running. To achieve this requires: (1) rigorous and constant training of team leaders (who, in fact, train operators on the job through responding to the andon calls) and (2) the management structure to sustain this, with, in particular, quick managerial and support service reaction to problems which can’t be fixed in under one minute.

This is not a walk in the park, and Gemba presence is essential to implement such social systems. Most companies I know look at quality issues from the management perspective: once we have an acknowledged problem, how do we coordinate departments to solve it. The specificity of the lean approach is to look at quality from the operator’s perspective, and understanding this often necessitates hours, days, weeks, months, years on the Gemba before it becomes second nature.

Secondly, once we’ve taught the process to spot bad parts and stop them, we can wonder what created the bad part in the first place. This is what Six Sigma projects tend to target. Here again, presence on the Gemba is essential to see that the improvement mechanism is in place and works properly. Once it’s clear the problem goes beyond the cells’ ability to improve because it involves either maintenance, engineering or purchasing (many quality issues are caused by poor quality components), the company needs to have a system in place which controls the response lead-time between spotting the problem and resolving the problem (i.e., it never shows up again).

This is far from obvious. Most people are overworked and technical departments tend to make their own priorities. What comes from the shop floor is taken into account, then fitted into a queue somewhere and treated when there is time. This makes sense from the department ‘s own priorities, but the upshot is that value-adding processes are often left with binning bad parts for months. Management’s role at the Gemba is constant checking the technical problem-solving process and controlling the lead-time.

Engineers Have a Role

Quick response is all the more pressing in that, like a murder mystery, the longer investigators take to get the scene of the crime, the higher the chances of the real culprit to go away. If the machine is not stopped at the precise moment it made a bad part and if technical people can’t inspect its condition right away, finding the root cause of the problem is unlikely. Without root cause, the remaining answer will be to replace this or that which looks out of condition when we finally look at the machine, and invest in newer equipment - not very lean.

Managing the problem solving process has a further impact – it should feed into another learning mechanism: getting manufacturing engineers to better understand their machines so that they continuously improve their capability. One exercise I ask manufacturing engineers to do before they design the next generation machine is to improve availability and capability of the current equipment by ten percent in one week, as a “workshop.” They grumble that what’s the point since this is exactly the machine they’re going to replace soon. The point is, of course, that they understand the downtime, slowdown and quality issues of the current technical process well enough not to reproduce the problems in the next generation machine.

Finally, the root cause of many quality problems is in the very design of the product. Engineers tend to solve functionality issues – it’s hard enough to get the damn thing to work as it’s supposed to. Most of the time, they’re simply unaware of the difficulties some of their technical choices create for the rest of the process. A learning process that teaches engineers how to design quality into the product is worth several points of EBITDA.

Spending time at the Gemba doesn’t affect quality in any direct way – no manager is going to start making or checking parts. Just walking around and shaking people’s hands won’t improve quality either. However, quality will improve as the result of several improvement mechanisms kicking in:

  • Improving the ability to spot a bad part by looking at it (or testing it)
  • Reacting quicker to bad parts so that they are taken into account and the conditions of making the bad part can be observe and dealt with at team level
  • Reacting quicker from a technical point of view to keep value adding staff in success conditions and to observe better what went wrong with the process or equipment
  • Improving the integration of what we find out in the design of new machines and equipment
  • Integrate what we find out in the design of the next generation of products.

None of these processes are easy, and people will resist the learning part as they just want to deal with the issue and move on to the “real work” of making parts, purchasing machines, CAD designing parts and so on.

The “A” Team

andon is a tool to embed learning into the day-to-day job. The operator pulls the cord when they have a question. The team leader answers. If the question is harder than it seems, the entire hierarchy gets mobilized sooner or late. The same sort of thinking can be applied to manufacturing engineering and product design. This is definitely a management job.

How can more Gemba presence improve quality? You can draw a clear picture of the learning mechanisms that should be triggered by every operator’s doubt. You can then stand on the Gemba and watch whether the improvement mechanism does kick in, and is followed to the A of the PDCA. When its not, you can grab people’s attention and repeat, repeat, repeat until they finally change their glasses and adopt a lean set.

Operator’s responsibilities are making parts according to standards, notifying abnormalities and proposing and participating to kaizen efforts. Similarly, management’s responsibility is to go and see at the Gemba whether people do what they’re trained to do, to point out abnormalities, and to keep the impetus on problem solving until issues are fundamentally solved. This will improve quality.

Which is best for a lean environment, a U-shaped cell or assembly line? Why?

January 25, 2012
Back to top

Dear Gemba Coach

Which is best for a lean environment, a U-shaped cell or assembly line? Why?

This is a question that comes up quite often – and the pros and cons of cells versus lines have been discussed at length, so let’s look at this from another angle: before you kaizen your existing operation, what is the problem you’re trying to solve?

Whether in a straight line (I-cell) or a U-shaped cell, lean thinking highlights two fundamental problems: ease of use and flexibility. The first issue is that operators have to be able to work safely, intuitively, and keep to quality and takt time requirements. The second is that operators have to be able to deal with continual change in terms of mix, volume, and new product introduction.

Issue number one is to keep the operator working in a strike zone, to use a baseball expression. Imagine a window in front of each worker where all the work happens. To visualize this, start by looking at feet movement (steps and rotations), then hand movements (stretching, turning), and finally eye movements. The operator should be able to do the work without ever moving his or her hands away from this strike zone.

Typically, in assembly, operators have to deal with a number of components they’re putting together, usually with some mechanical help. The problem is then to fit all components in front of them within the strike zone. Keeping takt time stable often involves stability of volume, but with great flexibility in mix (fractioning and mixing orders for heijunka). In this case, the shelf of components in front of the operator can expand rapidly if different products use different components. Since the strike zone cannot be expanded, this means using very small containers to hold all components in front of the operator. The team member is autonomous if he or she can build product A or product B according to how the kanban cards pull, and without needing any outside help to change over his or her workstation.

Assembly Line

Small containers of parts (they start being small enough when you can’t buy the containers in industrial catalogues but have to go to the supermarket for Tupperware instead) impose frequent resupply, and hence a “small train” or tugger. Very quickly, you’ll discover that the effectiveness of your workstation is directly driven by the tugger’s regularity, as any deviation will create parts shortages on the line. Consequently, one key problem to consider when organizing the cell is the train route.

In assembly, according to work content, operators will typically work within a defined area (defined by the components supply system) in front of them. If volume goes down, you might take a person out, and the zone will be larger (more work content). If volume goes up, the team leader might want to step in, making the operators’ work area smaller. In any case, having them work in a “U” doesn’t necessarily add any value – foot movement is essentially defined by the component shelf, and operators have to be able to pass on sub-assemblies from one hand to the next, as in a relay race. All in all, in assembly work, it usually makes sense to have a straight assembly line rather than a U-shaped cell. It’s also a cell – five team members, one team leader, etc. – but shaped as a straight “I” in order to make it easy for the tugger to supply work stations frontally by passing at the back of the station. This also makes it easy for operators to work laterally without having to ever turn around (definitely out of the strike zone).

Machining cell

In machining, however, operators deal with equipment that has its own run time. A typical cell will have several consecutive processes, and, to keep work intuitive and safe, we don’t want to have the operator tied to the machine as it operates. In order to avoid wasting the operator’s time, he or she needs to be able to place the component, start the machine working and then move on to the next task while the machine processes. In this configuration, the operator will be walking somewhat around the cell, and it then makes sense to have short circuits. These kinds of operations usually entail less components, so the tugger is not so much of a worry, and we can start thinking in terms of U-cells rather than lines.

The key here is that in order to work continuously, the operator should be able to place a part, move on to the next machine and withdraw the machined part and seamlessly place it in the next process. Automatic ejection of parts is a key component to make this work. The second issue is that, as with the assembly line, the cell should be changeable autonomously (without requiring outside help) and easily. So the next big problem is how to design machines that can be changed, by the operator(s) alone (without specialized changers) and without creating greater walking distances in the cell. This tends to be quite a challenge and requires many PDCA loops to get it better. Last week I was in a factory where manufacturing engineers are working on new ideas for protective casing to let parts and people flow freely – and safely – and, well, it’s not easy. The biggest room remains room for improvement.

A U-cell is therefore better adapted to using in-out automated equipment. First, the operator should be able simply to push parts from one process to the other (no carrying). Second, the cell should be able to handle well the product mix (easy to change). Finally, the cell should be designed to handle volume changes too. If the cell is composed of two rows of machines face to face separated by about 1,20 meters, when demand is high, each operator can take care of one workstation, and when volume is low, one operator can take care of the entire cell by walking from one process to the other in a standard circuit.

Understanding the Problem

With these generic problems/generic solutions in mind, we can now look into the real problem: how are you going to get your people to figure it out. Just the other week I came across a fascinating example of kaizen at the Gemba. The plant manager of a plants making car seats just-in-time, used the “pull” concept to improve the labor effectiveness of his assembly line by about 10%. Now, just-in-time plants are incredibly demanding as the OEM assembler expects seats to arrive for assembly in sequence throughout the day with a total lead-time of something between three to six hours. The pressure is relentless (if the seat is late the automobile line will stop) and the variety of seats is huge, so they need the information in order to build. There is a small buffer of finished seats waiting to go into the trucks for the five-minute drive across to the OEM’s line. Historically, just-in-time sites consider they don’t need to pull more rigorously because they already are pulled by the customer to a manic degree. But what this plant manager realized is that his frontline management kept trying to keep buffers filled at all times, and so created stop-and-go on the production line: early stoppages when a customer variation meant no more work, or rushes the moment the line started pulling again. This, in turn created overburden on employees (during the rushes) and quality issues with the seats, which generated more instability.

Working with the company’s sensei, he started a series of workshops and then kaizen efforts to pull more rigorously on his final buffer. In the end, they placed a mechanical stop on the buffer’s conveyor that pulled seats EXACTLY at takt time. This simple device stabilized the entire flow downstream, with all related benefits. But this is not the point. What the plant manager highlighted is the work he did with his middle-managers and frontline managers so that they themselves understood the problem. First they had to change their mind about what they measured and start worrying about in-process seats (between supplier and customer) rather than just trucks (if the truck is not complete, the customer line automatically blocks unloading). Then they had to understand the impact of their decisions on the stability of the assembly lines. Finally they had to work with team leaders to manage takt more rigorously at line level.

He is definite that if his engineers had come up with the technical solution, implemented it and he’d have to then get everyone to work accordingly, he’d have failed. He feels strongly that his site is already under enough pressure from the just-in-time situation without needing further tension from unnecessary conflict. In the end, his investment in time and effort has paid back further than he anticipated, and he is now thinking about working further with his own suppliers.

So, rather than worry yourself about what is the best solution in general, how about investigating how you’ll explain the problem to your line managers and team leaders so that they can come up with their own solutions. Line or cells are responses to technical drivers and there can be no once-forever right solution, as the situation changes all the time. However, if people have understood what they’re trying to get right - creating an environment where the operators can work safely and seamlessly at takt time whie changing all the time – they will start exploring and discover better and better technical solutions.

 Believe that lean is about kaizen + respect. kaizen is about improving the lines and respect is about creating an environment where people can succeed at their work, work safely, and have an input on how their work environment is organized. Technical solutions about how to have the “best” line have been around for decades, and I’m certain your engineers will know many of them. The issue here is respect. How do you get your group leaders, team leaders, team members and manufacturing engineers to work together on a shared problem in order to design the lines that best satisfy them all. That’s the real challenge.

Should we plan according to what we can do, or the other way around?

January 18, 2012
Back to top

Dear Gemba Coach,

Should we plan according to what we can do, or the other way around?

The big idea behind takt time is that you adjust production plans to demand, rather than plan delivery according to production requirements. A core idea in lean is that sales pace = production pace. At the Gemba this is often impractical, for a number of reasons. First, sales volume tends to vary from one day to the next whereas efficient production requires some degree of stability. Second, even if the overall sales volume is relatively stable, sales mix will vary from one day to the next, and production is rarely flexible enough to deal with such variations.

In assembly, for instance, one line or cell should be able to make any product at any time, and ideally follow exactly the sales pattern: one sold, one in the queue, one made. But when you go down to the shop floor, you find out that’s rarely the case. Most production cells are set up so that every product change requires emptying the component racks of the parts for this product, and refilling the racks with parts for the next product. There is no tool change as such, but production change is still disruptive because of component changes.

Years ago, I once asked a Toyota engineer why he was insisting so much on really small containers at the workstation – I couldn’t see what the possible gain in inventory was at the level of halving a container that was already quite small. “It’s not about inventory,” he answered, “but takt-time. Ideally I want to produce products exactly according to takt time, which means that I wont produce two same products in a row. The operator needs to be able to switch from one product to the next seamlessly, so they need to have all components of all variants at all times in front of them. Since space is limited at the workstation, this implies very small containers to fit them all within easy reach of the operator.”

Pressed to Be Lean

Similarly, one step further on the value-stream map (VSM), at the press, changing tools at every product is simply absurd. Assuming we’re willing to invest 10% of Overall Equipment Effectiveness (OEE), which is already a lot,  in tool changes, a 15 minute tool change implies batches of 150 minutes of production (roughly, ten times the changeover time). If the press makes a part a minute, this means a batch of 150 parts of the same product. In many plants, press changes are closer to 45 minutes than 10, so it’s not unusual to find batches of 450 minutes (a full shift) or of an entire day.

Say the process is relatively simple, as with one press operation and then a simple assembly of adding a few components to the pressed part. Let’s assume that one press handles two high-runners, A and B, and three or four low runners, C, D, and E. After years of wrangling with the press shop about reducing batches they’ve accepted no longer to run the high runners once a week but twice. Allowing some time for changeovers, they run As on Mondays and Wednesdays, making 2,400 parts in six shifts, Bs on Tuesdays and Thursdays, making 2,400 parts as well in six shifts and make the X part (C, D or E) on Friday in three shifts – overflowing on Saturdays if need be.

In this situation the argument will be to plan the entire value stream (press + assembly) as the following:

 

 

Monday

Tuesday

Wednesday

Thursday

Friday

A

1,200

0

1,200

0

0

B

0

1,200

0

1,200

0

X

0

0

0

0

1,200

Lean? Not so. Regardless what the press shop’s flexibility is, the demand for A is 2,400 parts, for B 2,4000 parts and, for C 400, D 400 and E 400 parts as well. So if we level the demand across the week, we end up with the following production plan:

 

 

Monday

Tuesday

Wednesday

Thursday

Friday

A

480

480

480

480

480

B

480

480

480

480

480

C

80

80

80

80

80

D

80

80

80

80

80

E

80

80

80

80

80

Total daily demand is 1,200 parts whereas the press has a capacity of 1,350: 150 minutes are available for changeovers. If tool changeovers are 40 minutes, they should just about make it. But the moment one changeover takes, say, an hour, they start losing parts and won’t be able to fulfill the demand – plus all the extra hassle of doing four to five changeovers a day instead of one.

Press shops being what they are, whatever the production plan, they’ll stick to what they’ve agreed: run 1,200 parts of A on Monday, push them into the WIP warehouse and let assembly do what it will.

SMED Metric: Rabbit’s Foot or Chicken Leg

This is where lean kicks in. In the future state of the VSM every process owns its production. The press owns its inventory, so the parts hotel in the warehouse is shut and the press gets to keep all parts it produces. In this case, what the production plan tells the press is that it will come and pick up 480 parts of A, 480 parts of B, 80 parts of C, 80 parts of D, 80 parts of E at some point during the day according to how kanban cards flow in the pull system – regardless of how the press shop chooses to schedule its production.

This lean production plan doesn’t tell the press shop what to produce. It lets the press shop know what its responsibility is. At the press’ supermarket, the press shop has to make this number of products available every day of the week. Now, clearly, if it decides to produce 1,200 parts in one run, it means that at the end of Monday’s third shift, it will own 720 parts of A in inventory – and its parts supermarket needs to be large enough to accommodate this.

As you can expect, this will be a big fight as well as create the incentive for the press shop to get its changeover time down to the level where it can produce every part every day.

In fact, even producing once a day makes you carry huge inventory. Let’s consider that by improving the assembly line’s workstation, we can now produce parts in batches of one half hour. The pull system’s tugger can run through the press shop to pick-up parts accordingly every half hour – which means 45 pickups across the day’s three shifts. Since A and B are the two high runners, the train is likely to pick up some A every hour or so, and some B as well.

To follow the train’s pull ideally, the press shop should produce in 20 runs of 60 parts. This would mean 20 changeovers to be done in 150 minutes: 7.5 minutes per change over. SMED (single minute exchange of die) legend Shigeo Shingo is said to have walked through press shops with a rabbit’s foot and a chicken leg in his pockets. If the change-over was below the 10 minutes line (single digit), he’d pull out the rabbit’s foot. If not, you got the chicken’s leg. Changeovers of 7.5 minutes are not impossible – I’ve seen a 4,500 ton press, as large as a house, changed in five to seven minutes in Toyota’s stamping shop. But it’s quite a challenge. It’s lean.

All this to say that the leveled weekly plan is established according to averaged customer demand day per day. We average customer real demand over three weeks, and then we divide this by the number of worked days. This gives us how many parts will be picked up from the supermarkets in the VSM any given day. The steps in the process may not be flexible (or willing) enough to be able to build at that rhythm. They might have to build once every couple of days, or even (shock, horror) once a week. No matter. The shop’s abilities should not restrict the production plan. What is planned is their responsibility for the number parts to be made available on each given day. How they do it is a different debate.

Legend has it that Ohno’s last words were “no kanban.” Until all steps in the process can produce according to a perfectly leveled, fractioned and mixed schedule, we will have to batch, and so, to pull. Our capacity to do so should not affect the plan. On the contrary, the leveled production plan is there to tell us what we need to have available in our little cell’s shop, every day.

How Do I Plan for the Long Term?

January 11, 2012
Back to top

Dear Gemba Coach,

I don’t know how to plan for two or five years out. As a plant manager, my requirement is to be able to look at the next 12 months. And to do this I rely on guidance from a familiarity with lean policy deployment. Yet I worry that my skills in leadership are lacking because I don’t have a clear sense of how to conduct this long-term planning. How do I look ahead for the long term?

If you’re asking whether you need a long-term Vision to succeed at lean transformation, I believe the answer is … no. What you do need however is a clear North Star. Let me explain.

Recently I was on the shop floor with a company that manufactures industrial equipment. Over the past five years they’ve doubled their volume without increasing headcount or investment. Yet their lean transformation has produced mixed results. Among the many positives: they’ve reduced their price (it’s a transfer price) by 4% to 5% per year, and improved quality dramatically. They’re getting something right, obviously, which shows in the EBITDA figures. Yet these advances have produced new problems. With the demand increase their customer lead-time has been growing steadily and they have failed to respond to date. The benefits of higher demand have made them reluctant to challenge the organization to reduce lead-time.

They have what might be called a good lean problem. They persistently and steadily deployed a lean quality policy (applying many elements of jidoka and flow), deployed a lean cost policy (through engineering work and flow – though not leveling), but are balking at deploying lead-time reduction. In other words, although they have learned the hard way that increasing customer satisfaction in quality and cost pays, they’ve not naturally applied this to lead-time as well.

When we investigated this problem more deeply we uncovered an important belief: their senior executives couldn’t accept the idea that working hard on quality and cost had actually boosted their market share (from less than 40% to over 65%) and increased sales. They were suspicious of this because most of their market visions have been proved false in the past turbulent years. So they were skeptical that their dogged work had delivered.

The Fab 5

The best reply to your question that I can think of can be found in George Koenigsacker’s book Leading the Lean Enterprise Transformation. He states clearly that you get spectacular result if you simply seek to:

  • Reduce accident rates by 20 percent each year
  • Reduce errors and customer complaints by 20% each year
  • Reduce lead times by 50% each year until you get to daily production cycles
  • Grow enterprise productivity by 15% each year

And this is what the North Star is about. There are five fundamental performance drivers that must improve whatever the circumstances, which are:

  • Quality
  • Lead-time (both to customers and internal)
  • Cost
  • HR development
  • New products

That’s all there is to it. Your enterprise will be transformed, and your results will be dramatic if you learn do what it takes to develop your firm’s capability to hit George Koenigsaecker’s numbers every year by applying:

  • Visualization of processes to reveal problems
  • Problem solving and kaizen to increase every individual’s capability
  • Process capability by adopting and maintaining smarter standards.

The interesting thing about building the company’s vision around such a North Star is that it doesn’t require a crystal ball. You don’t need to know whether the market is going to boom or bust. You don’t need to anticipate that your best engineer is going to defect to your main competitor. You don’t need to worry about what new thing politicians are inventing to stop us all from working serenely. You use the vision the other way around. You set yourself to reach these targets every year for the next ten years – taking into account market circumstances. THAT is the vision.

Once you’ve committed to these goals, and have found a sensei to help you learn the lean tricks to move forward on visualizing processes and developing people’s autonomy in Problem solving, then the long-term vision emerges as a result of facing the challenge. More often than not, results appear before the long-term strategy is set. When people see the incredible payback (of the two companies I know well who started lean this January, one has already saved $1 million in labor costs and the other has doubled its cash) they then commit further to the approach. After a couple of year of facing the Safety Quality Lead-time Productivity New Products challenge in turbulent market, PDCA cycle after PDCA cycle, usually a long-term strategy emerges as senior management learn to draw the right lessons from their markets. This makes further transformation easier.

Lean and Sales

There are three main barriers to adopt the North Star approach. Firstly, many managers simply can’t see how working on the five drivers will actually improve their financials – they can’t believe that waste in their processes could amount to millions of dollars. Secondly, they don’t believe that such changes are possible in the current context of their company. Thirdly, they rarely have the management gumption it takes to stick with 20% improvement per year BY developing people, not just WITH developing people.

I have to confess I’ve often been puzzled by the first point myself until I figured out that it’s not about the Process, but about the PRODUCT. The essential link here is between lean activities and sales. One thing we know is that sales are driven by:

  • Market share (the bigger, the better)
  • Reputation of the product

That’s not surprising, if we look at it from the customer’s perspective. We’re all loss averse and in choosing a product, more often than not, we make the safe choice. The dominant product on its market is a fairly safe choice: we’re surrounded with people who’ve made the same purchase. The product reputation is the other indicator we have about the product’s value (usually, we don’t know much about the product itself, we’ve got other things to worry about, so hearsay is as good an indicator as any other).

So, if you reduce quality complaints by 20% every year, if you reduce customer lead-time by the same amount every year, and if you keep a fair (market based) price – chances are your reputation will increase, which leads to greater market share, more sales and so on. Oddly, in my experience the early improvements in EBIT don’t come from cost reductions per se, but from sales increase. Similarly cash gets better quickly as lead-times (and inventory) are reduced, which helps with delivery performance, and, again, more sales. As a rule of thumb, half the lead-time, twice the growth.

The staggering amount of waste carried in costs of rework and overproduction usually becomes visible in the second year as people better understand the implications of the lean activities they’ve carried out so far. By and large, it’s much easier to carry out a lean transformation if you’ve already done one simply because you KNOW (as opposed to hope) that by following the North Star, results will come.

The second barrier is that people don’t believe the company can change its own culture. For instance the managers of the industrial manufacturer struggling with lead-time don’t believe they can get sales, production, logistics and purchasing to talk to each other sensibly in order to fix the causes of long-lead-time.

This is the beauty of the pull system. Once you’ve committed to pulling, issues will crop up one at a time and you can progressively build the working relationship across functions. By committing to reducing lead-time by 50% (or even 20%), and adopting JIT tools, you’ll uncover problems that involve each of the actors and force them into aligning on one simple objective: customer delivery on time (of only good products).

So, here again, don’t worry about the overall vision. Aim for 100% on time delivery and pull! The vision will clarify itself as people learn to solve problem after problem.

Yes, I am saying that you don’t need a long-term strategic vision to transform your company. You need to commit to improving Safety, Quality Lead-time, Productivity and Product development and then scratch your head with your teams and roll up your selves and GET IT DONE.

When I first studied lean I repeatedly ask the Toyota engineers working with a supplier to give me their roadmap, their Ariadne’s thread so that I understand what they were doing. They didn’t have one they kept telling me. They solved problems as they appeared. I now believe them. They didn’t have a preconceived idea of what problems they would encounter. They were committed to the North Star and to keep digging at it by kaizening problems away. Forever.

Which is the core issue. We might not need a “vision”, but we do need relentless commitment to achieving the North Star challenges through repeated kaizen, whatever the circumstances. The market crashes, and volume plummets, use the down time to do kaizen. The market booms and volume skyrockets, hire the people you need to keep doing kaizen. Improve. Improve again. I’m willing to be that as you do this you will develop a real long term vision, but the real difficulty is refining our understanding of the challenges year after year, and never dropping the kaizen ball.

The information about this is all around. It’s in Lean Thinking. It’s in George Koenigsaecker’s book. It’s in every workshop conducted by Orry Fiume. It’s in The Gold Mine and The Lean Manager. The real difficulty is recognizing it as we read it. We are so conditioned to the traditional worldview of strategic vision followed by execution that it’s hard to buy into the idea that improvement, year after year, will deliver massively more than the Grand Plan. Physician: heal thyself. Lean expert: have faith in lean thinking!