Column Archive: 2011


How Do We Sustain A3 Thinking in our Organization?

December 12, 2011

Dear Gemba Coach

My firm has been investing a lot of time and energy this year in teaching A3 thinking to our staff.  The workshops have been going great, but how do we keep this work going when people return to their daily work? How can we “pull” A3 thinking through the organization after the formal training is over?

Some time ago a CEO I know decided to train all his middle managers in A3 problem solving. The company had been doing lean on the shop floor successfully for years, and yet middle management continued to resist this lean approach and kept complaining about kaizens. And so the CEO asked his HR department to develop a mandatory three-day A3 training program for all middle-managers. While doing the Check of this work, we found that the results were disappointing. Most of the evaluations for the sessions were positive, yet there was only negligible change in behaviors.

As I said then, and will repeat now, it would be wrong to draw the conclusion that the training was a waste of time. I’ve been observing lean transformations for longer than I’d care to admit and I’ve come to terms with the feeling that you’re always failing with what you are doing right now—even though you might be succeeding over all. At least 50% of the time I visit the Gemba to observe people working on 5S, red bins or pull systems (just to name a few), I get dispirited: the 5S has gone to the dogs and needs to be restarted, or the red bins are no longer being treated with the respect they deserve, or the pull system is down again. And so on. This, I’ve painfully come to accept, is normal. We’re not constructing a building. We’re training a team. A team of people, which means that we will have ups and downs, none of which means that we aren’t making progress. Especially when we keep in mind the main thing: what we are really doing here is beefing up our firms problem-solving capability. Short-term stumbles are fine as long as we are clear on our long-term goal.

Learning to Learn

Again, the real issue here is developing an awareness of the real purpose of teaching A3 thinking. One way of saying this is the capacity for reflection, learning from doing, hansei. There’s a great story in the new Jeff Liker and Gary Convis book The Toyota Way to Lean Leadership (which I highly recommend for sharing a missing piece in our collective understanding of lean.) When A3s were introduced at NUMMI, where Gary was plant manager, he was deep into trouble-shooting at the time. He was asked by a new Japanese president about the rate of progress on the machine capability front. He also asked the engineers to present an A3 report on any downtime of more than 30 minutes to him and Gary. At first Gary did not realize that the aim of the exercise was not so much to look at the solution, but to check whether the engineers correctly understood the problem, whether they started to ask themselves “why?” At the time no one had heard of A3 thinking. It was just presenting problem solving on an A3-sized piece of paper.

At first, the sessions are something of a bloodbath as the president challenges, redlines, questions every part of sloppy thinking. Gary watches on, vaguely amused to see his engineers backed into corners by their president on issues they should know better. And then the president pointed out that he is the one who let his guys show up with poorly prepared reports. Gary then realized he didn’t know how to train his engineers to make better A3s. And so he started working with them before presenting to the president. This is how HE learned to write A3 reports.

The story stayed with me because it’s so similar to the story in Managing to Learn about how Porter and Sanderson interact, which highlights another critical aspect of teaching A3 thinking. There are two key aspects to A3 thinking: the problem-solving and the relationship. And for some bizarre reason we obsess with the former and keep being blind to the latter.

Why A3s work

This misdirection was certainly present at the company I referred to earlier. As a result, I told the CEO to ask specific managers for A3 reports on narrow technical topics, and reviewing them together. And all of a sudden something radically different happened to these A3s. They began to rapidly improve in precision and depth of thinking. Now, the CEO can’t personally review every A3, but having him work closely with these individuals helped everyone see the problem differently. Our issue was no longer teaching A3 problem solving to every middle-manager, but establishing productive coaching/mentoring (Porter/Sanderson) relationships within the management line.

They key here is understanding what A3s produce and why they work. There’s no value in nicely prepared forms. The real value exists in deepening the thinking behind the report. This enables everyone to: (1) better frame the problem, (2) seek root cause (3) explore alternative countermeasures and (4) study these countermeasures so that (5) you can understand the problem even better and deepen your knowledge of the situation.

This deep thinking is very hard. Daniel Kahneman, who was awarded the 2002 Nobel Prize in economics, has recently published Thinking Fast and Slow, where he explains elegantly that we operate with two distinct – albeit related – reasoning systems: System 1 and system 2.

  • System 1 is intuitive, automatic, fast, with no effort or voluntary control and explains most of what we do all day long, how we respond to immediate situations and to a large extent the opinions we hold about ourselves and the world.
  • System 2 allocates attention to mental activities requiring effort and complex computations. System 2 is about thinking things through, making touch choices and requires heaps of concentration.

We mostly rely on system 1. Coming up, say, with an after-the-fact rationale to justify the positions derived from intuitive reasoning. On the other hand, deep thinking, such as required to solve difficult engineering problems requires system 2. And this is hard to access, tiring, and, well, not that natural. I once coined the phrase “Law of Least Mental Effort” in an attempt to describe the fact that real thinking is hard and rare.

People will naturally rely on system 1 to write their first A3. Just write whatever comes to mind on the page, and you’re done. Which is exactly what Porter first does in Managing to Learn. However, the A3 only becomes interesting (and fruitful) if you engage system 2 in writing it, but that’s hard, hard, hard. Which is why Sanderson gets involved.

The role of the boss or the sensei in A3 writing is to make sure that (1) system 2 is plugged in, which brings all kinds of motivational issues; and (2) that the thinking sticks to facts and doesn’t deviate into philosophy (system1 corrupting system 2). It’s tough, and relies largely on a relationship where the learner accepts to be taught, just as much as the teacher accepts to have the patience to teach.

Now the beauty of this is that repeated conclusions by system 2 will be eventually inscribed in the intuitive working of system 1. The chess master can say check in three moves at a glance because she has practiced for years and can recognize the obvious strong move automatically by now (so that it looks like intuitive magic). Similarly, the machining expert can take a sniff at your machine and ask whether you’ve checked for bacterial contamination in your cooling liquid. They weren’t born with this knowledge. By practicing system 2 learning years on end, it has become inscribed into system 1.

I realize this might not be a very satisfactory reply, but I suspect that there is no good answer to your question: I doubt that you can get there from here. The key is to look at A3s as a physical support for managerial relationships based on expertise and teaching. In most companies I know, this isn’t a satisfying answer because managers have been chosen for their generalist “get it done” skills, not for their technical experience.

So where to start? I’ll confess that I don’t know exactly, but suggest you start from the top and work downwards. On the emotional front, having your A3 reviewed by someone two or three paygrades above you has a strong impact, and you can then teach the immediate managers to make sure the A3s stand up to be looked at seriously as per Gary’s story. I know a few CEOs who’ve started with this and it’s not pretty, but the results in terms of depth of thinking are surprisingly good.

In practical terms this would mean looking at the chain of teacher/learner relationships and organizing set times for A3 reviews with the most senior people possible. Even if they don’t have the necessary technical expertise, they’ll bring in another perspective and, on the other hand, learn something as well. More importantly, their time is money, so the writer of the A3 will have concrete evidence of how important this is. At the end of the day, in lean, we develop people in order to develop products.

Is There a Right Way to Teach A3?

November 8, 2011
Back to top

Is There a Right Way to Teach A3?

Dear Gemba Coach,

We’ve been teaching A3 problem solving to all our managers, but so far I fail to see any clear improvement of our problem solving ability. Is there a right way to teach A3?

First of all, allow me to be blunt: A3 is a technique to present reports, not to solve problems. A3s are not specific to lean or Toyota, and they’ve been used in Japanese companies where they co-evolved with fax machines during the 1980s, largely because it’s faster to handwrite than to type kanji characters. A3s were the largest pieces of paper one could fax, and the idea was to fit a full report on one faxed page.

At the time that these reports emerged, 8D problem solving (Plan; use a team; define and describe the problem; develop and verify an interim containment plan; determine, identify and verify root cause; choose and verify permanent corrective actions; implement and validate permanent corrective actions; prevent recurrence; congratulate your team) was popular in quality assurance and in automotive in particular. So before long 8D-structured A3-sized reports started appearing back then.

Now don’t get me wrong: presenting a report in an A3 page, and a structured format reflecting plan-do-check-act (PDCA) in various forms is a hugely useful skill, and one with many positive impacts for a company where doing so is widespread. It helps the people preparing the report to think clearly and sort their ideas, and it helps to communicate what they think to others. This is a clear and powerful way to help people understand what others have in mind. My father’s criteria for a good A3 report are that it should be read and understood in less than one minute.

Good Teacher, Good A3

If A3 is just a report presentation tool, why is it so often confused with a problem-solving tool? The confusion is easy to make because the structure and format of A3 is a great teaching tool for training someone to solve a problem. As John Shook has brilliantly illustrated in Managing to Learn, when you want to coach someone on problem solving, the A3 format is a great tool. The story in this book shows the path—one path—of what goes through the mind of both the learner (who is creating the report) and the teacher (his manager providing coaching.) The manager’s main problem can be summed up in terms of: “how many times can I ask this guy to rewrite this box until he either gets it right or gives up?”

One enormous benefit of the A3 format is the way it takes someone through the steps of solving the problem rigorously, thereby avoiding loose and vague generalizations. Unfortunately, this only works if the teacher has a pretty good generic idea of what the problem really is, and what kind of solution they’re looking for (and is open minded enough to be ready to be surprised by a creative solution). In effect, in order to correctly use an A3 as a training tool, the coach needs to already know how to solve the problem (not necessarily in detail) and be able to specify both the problem definition space (this is not a machine problem but a materials issue) and the acceptable solution space (less reground I the mix). Rather than lecture, he or she will steer the learner to discovering answers by themselves.

Does the A3 format and structure help to solve problems without expert guidance? Unfortunately, not that much. Even so, I recommend that you put your thinking in an A3 format as you struggle with a difficult problem. This will help you to:

  1. Clarify your own thinking and,
  2. Share it with others to hear what they’ve got to say.

Just remember that the format itself in no way guarantees that:

  1. The problem is well understood and astutely framed and,
  2. The proposed solution addresses the problem and is clever enough to be easily implementable at the lowest cost.

Problem-solving is a skill in itself which needs to be honed independently of formats and structure, through old fashioned experience. It really comes down to a thinking process that can be stimulated through any number of useful tools. Here are the essential components of knowing how to solve a problem.

1. Observation

Probably the most important part of solving any problem is like in any crime novel investigation: powers of observation. Reality is messy, and the primary difficulty with problem solving is distinguishing what is relevant and what is not. The deeper you look into a problem the more you will see aspects that appear to be not quite right (parameters not in standard conditions). A few have a huge impact; most are inconsequential at best. As one gains experience, one learns to focus on the really important features of the problem and ignore the more distracting though superficial aspects. For instance, in most work problems, other people’s moods and attitudes tend to be seen as major drivers of the issues where in fact they are side-effect of the problem itself, and, as such a distracting irritant, but certainly not a cause.

Learning to observe is a skill in itself. It means looking at a situation for hours, going through several cycles, and picking up what is right and what is not. In practice, it’s very hard to do one one’s own, without a more expert hand to point and guide. If you’re serious in teaching problem solving, the first step is to go back to the Gemba and spend hours teaching people to distinguish normal conditions from abnormal situations – and their impact.

2.  A Library of Typical Cases

Diagnosis is essentially the skill of drawing from one’s observation, and knowing the right “typical case” – essentially putting the right label on the right problem. To be able to diagnose correctly, one needs to have seen hundreds of different cases, and be able to sort through them in typical schemes. For instance, there are many different kinds of lead-time situations: directly to customer line, through a distributor, high runners, promotions, one-offs, seasonal demands, etc. If one is setting up a pull system, each of these different forms of lead-time corresponds to a typical material and information flow, which is necessary to know to complete the lead-time analysis. If not, one risks lumping it all together and fundamentally diagnosing the wrong situation.

Beyond observation, problem solving requires a deep knowledge and understanding of what the typical situations are, what their boundary conditions are (symptoms that either fit or not) and how to correctly sort the current situation in one of these cases. This might not be the whole diagnostic, but it’s certainly the starting point. Without this step, messy situation remains incomprehensible, regardless of the number of Pareto charts one builds time over time.

3. Self-Monitoring And Self-Checking

Finally, effective problem solving requires constant monitoring and checking from the problem solver himself or herself: am I making the correct diagnosis, am I picking the right solution? How can I verify this? Lean tradition insists on confirmation at all steps, but that’s neither intuitive nor easy to do. We’re usually all eager to prove the first solution that comes to mind is the right one and implement it right away.

What I come across more often at the Gemba is problem solving sessions where people rush to quick solutions. Once they’ve identified the “problem”, people find a way to completely change the process so that this problem doesn’t occur anymore. Left to implement such “solutions” they discover that their bright idea is in fact creating other unanticipated problems, and often the original problem is not even solved. problem solving is about solving problems without changing the process first. If, through the problem solving, a case can be made to change the process later on, so much the better. But that’s improvement, not problem solving. Experienced problem solvers know that they’re just as tempted as anyone else to jump to conclusions and fall in love with their own solutions and they know enough to be watchful and critical of their own path of least resistance reactions.

The key challenge here is suspension: not considering the problem understood or solved until either diagnosis or solution has been confirmed. This is probably the most demanding aspect of problem solving, as it requires rigor, and an open mind.

In my experience, teaching problem solving hasn’t much to do with teaching A3s. It’s all about:

  1. Observing, observing and then observing some more: observing can be just watching, or being active such as counting bad parts.
  2. Separating cases: Manpower, Machine, Material, Method has to be one of the most underestimated problem solving methods in the lean toolbox. Just clarifying whether the issue is more one M than the others forces problem solving in different directions (notice that Milieu is kept separate because it’s all about environment variables and not so useful in problem solving – if need be first attack milieu through 5S, and then go back to 4M).
  3. Find a domain expert to discuss your findings with: an expert might not be able to identify the problem or solve it, but will certainly teach you a lot by reacting to your own observations and assumptions. In this, A3 reports are a huge help because they can explain clearly and succinctly your thinking to others with relevant experience.
  4. Think of two or three distinct solutions to the same problem: the discipline of coming up with alternative solutions is both a test of creativity and a good check of understanding of the problem. Distinct and valid solutions demonstrate the problem space has been thoroughly understood and explored, and make it easier for others to get on board with the proposed countermeasures.

Don’t read me wrong, I’m all for A3 training. I believe that knowing how to write A3 reports is an essential skill for all managerial ranks. Much like the Internet IP protocols, formatting the information in a common, synthetic format is of enormous benefit to the information flow in the business, and will eventually lead to better decisions and better solutions. However, your observation is essentially correct: don’t expect an immediate improvement in problem solving skills by mass training to A3s.

Writing an A3 report is a great tool when coaching someone to solve their own problems. But the problem solving skills essentially rest with observation skills, a memory for specific cases and the experience to correctly categorize, and the ability to confirm one’s assumptions by discussing with domain experts or testing ideas through local experiments. If I’d have to pick a problem solving teaching tool, I believe I’d choose Ohno’s circle (stand and watch, just a bit longer), and 4M analysis, again and again.

Engineering Checklists

October 20, 2011
Back to top

Dear Gemba Coach

How do I apply standardized work to product development?

This is an intriguing question and I don’t know if I can answer it directly. Standardized work is a very specific tool to address human motion and create production sequences with the least muda possible. I’m not sure the concept translates well in engineering. What is key to lean development processes is the notion of “standards.” Indeed every engineer I’ve come across who has worked with Toyota as a partner or a supplier has been surprised at how rigid Toyota engineers can be about their standards – refusing to even considering side-stepping a standard regardless of how good the argument. Equally surprising – and confusing – to observers is what constitutes an engineering standard and how it comes into being.

To return to your question, in assembly, the “standardized work” tool is derived from the Operation Standards Sheet, the basic job instruction tool about what specific standards must be met in order to achieve standardized work. In engineering work, I’d say that the equivalent of standardized work sheets would be checklists. As a tool, checklists are the concrete manifestation of two aspects of lean product development: hansei moments and development standards. hansei occurs throughout of the development process as the time to take a deep breath, get together, and reflect deeply about what we’re doing, the mistakes we’ve made in the past, the mistakes we might make doing now, and where we’re going with the projects. In development, eliminating waste has a lot to do with avoiding bad mistakes that are wasteful later in the project, at the customer’s, in manufacturing or supply chain. One such mistake could be using in our development a rare material with a huge price volatility on the market, which would impose a profit variation according to market condition during the sales life of the product. Without a moment of pause and reflection such very costly mistakes are easy to make if one is exclusively focused on solving the immediate engineering problem.

Upside Down Perspsective

Engineering standards have many aspects, such as: shared components across products, standard product architecture, standardized manufacturing processes, standardized supply chains, test plans, design strategies and so on. In fact it often seems to outside observers that the entire development process within Toyota is steered by checklists and standards. To most engineers I know this sounds rather scary. Every company has its internal standards and engineers are supposed to follow them but they know that thankfully, they don’t. If they did, products would never get off the ground, and certainly never please the customer. Internal procedures are usually written by desk jockeys who know nothing about the real work of engineering and spend their time dreaming up impossible solutions to complete AMDEC analyses and so on. The key to good engineering is creativity, and it is a well-known fact that company standards are a huge barrier to innovation.

Here’s the conundrum: standards as we know them are a major impediment to clever engineering and yet they are the basis of lean product development. How shall we resolve this paradox?

As is often the case with lean, let’s turn our perspective upside down and look at standardization from the engineer’s perspective. Checklists are not all bad. In fact they’re often darned useful – not to tell us our work but to make us spot things we usually forget. Also, checklists can be a huge help to remember details in processes where we have a general idea, but can’t quite recall the exact phrasing. For instance, as a lean teacher, I have a book of standards. I carry around a banged up moleskin notebook where I’ve drawn and pasted in a variety of formats, explanations, definitions and so on. As a case in point, I have formats for the three basic documents of standardized work: the Standardized Production Capacity Sheet, the Standard work Combination Table and the Standardized work Chart. Now, with practice, I can probably redraw them from memory, but it’s still useful to check back when a specific question crops up.

Checklist Topics

So rather than a corporate handbook everyone is required to apply, laying down the law of thou shalt and thou shalt not, imagine that every engineer is offered that moleskin notebook on the first day at work and asked to behave as any inventor or artisan and fill it with their own sketches and ideas and, yes, standards. Any engineer worth his or her salt would be unlikely to write down the obvious (what is usually in the handbook). Instead, they’d start scribbling about quirky or interesting aspects of their job. Out of hand, one can think of:

  • The various technologies to perform a given function and their description. For instance, my own notebook holds various ways of conducting introduction-level kaizen – they all do more or less the same thing, but in varied ways.
  • The lead-time involved with each of these technologies. Some solutions are quick to implement, other take longer. Local sourcing might be more expensive than purchasing from the interior of China, but might also mean a shorter lead-time. Some solutions will be less capital intensive then others, and so on.
  • Production costs after ramp up. Engineers tend to be familiar with prototyping costs that come out of their pocket, but not normal production costs on the line. None the less this is critical knowledge inasmuch as the two are not necessarily close.
  • Schematics on the physical behavior of parts, as well as trade-off curves to express the scope of possible solutions (by example, maximum power (kw) vs; engine displacement (cc)).
  • Competitor’s technical solutions to specific problems. When opening up a competitor’s machine a few weeks ago we noticed that all cables were the same length, some of them tightly folded and clipped when all the length was not needed; We wondered whether the standardization gain on one single cable balanced the added cost of using longer cables than necessary.
  • Latest performance details of our technical solutions. Just a few days ago I was discussing with engineers designing automated test machines about the ratio of false positives tested by their machines (OK parts the machine considered defective – you run it again through the test machine and it turns out ok, sort of a blood test telling you you’re ill, but doing it again, you’re fine). They all agreed it was a serious issue but could not agree how much of an issue and had no data on hand.
  • Main suppliers across the world – who makes what where?
  • Key points to check on any drawing, consistency checks, known problems. For instance, during a design review session of a casted part, the manufacturing guy pointed out the designer had drawn different width of the casting. In the painting process, he explained, the part would go through an oven where areas of different width would heat differently, and create paint defects. Equal width across the part was essential to keeping the paint defect down.

And so on. Topics for checklists are endless. Essentially there are the checklists you draw to yourself to avoid making a mistake (check to turn off the headlights before turning your back on your car) or the checklists you keep about unfamiliar or interesting processes just to think about them and use them if they come up. In essence there are DO THEN CHECK checklists and READ THEN DO checklists. The point here is that the checklists in the engineer’s moleskin notebook will reflect his or her interests and quirks. How can that possibly become a “standard?”

Shut Up

From the engineer up, the main lean idea is yokoten (copy and improve) as opposed to apply best practice (execute and shut up). If maintaining the checklist notebook is the engineer’s individual responsibility, chances are that his book will look like mine: my own ideas are very few and far between. Most of what is in my book I have pilfered from more advanced person. Much like a student cutting up textbooks, in most situations one doesn’t know better than one’s betters – we’re all pigmies standing on the shoulders of giants.

And when we do know better, we’ve usually had to prove it. Standards are not cast iron rules – they are agreements that this is the best way to do this or that. Consequently, any one is free to challenge the standard at any time, but it means convincing others than your way is better; This does happen, but it usually requires quite a bit of work and being rather certain of one’s own facts. In actual practice the standards notebook will be filled with other people’s knowledge – precisely because the person feels it is his or her responsibility to guarantee it’s the best known knowledge. With the corporate handbook, on the contrary, everyone assumes that they know better in practice, and are wise to ignore it and follow their gut feeling.

This doesn’t sound like much of a way to enforce standardization, but in practice, it is. For instance, the engineering team leader’s folder of standards will have a great impact on how every junior member of that team learns their jobs and what technical decisions they make. The team leader will feel increased responsibility to have the best standards in his or her book inasmuch he or she now has to (1) pass on this knowledge to others and (2) work with other experts from other fields. This, in effect, is exactly how the scientific community proceeds.

Ultimately, knowledge is personal because no one can learn from you. Many knowledge management systems have echoed the corporate dream of taking the person out of the equation. Never works. Lean, on the other hand, is about achieving objectives THROUGH the development of people. Knowledge remains personal, but it is shared. Which makes for a good definition of what is a standard: shared knowledge.

The next step is moving from a personal standards folder to a product standards folder where all the checklists and knowledge pertaining to a specific product will be collate. On the Gemba, the way I do this is simply ask development teams to start a new folder and throw in everything they know about the product – from PDCA experience: one sheet per knowledge item, which can be as simple as NEVER DO THIS written in large letters on a single sheet), until it progressively builds up into a checklists handbook.

Accelerating Product Development

The key here is to build up a representation of what we can change in the product design and what WE CAN’T – at least not without a major investigation project. The idea is that there is enough space around standards to find improvements that you don’t need to start by challenging what you actually know from experience (a bit silly, right?). The ultimate goal is that the product is so well constrained by checklists that a novice engineer should be able to design it fully without making obvious mistakes. These kinds of standards are essential to accelerating the product development process and to focusing on truly innovative areas, rather than fiddling with redesigning every door lock.

In practice, I don’t quite see how the specific tool of standardized work can apply to engineering. However, what we do know is that in order to learn any discipline, a person needs:

  1. A way to self-monitor his or her performance
  2. A way to self-monitor how they go about it
  3. Room to experiment
  4. Coaching by an expert.

Checklists provide self-monitoring about how we perform task. Checklists are about (1) knowing when to take a step back and, well, check and (2) making sure we’ve followed all the best known steps to succeed at a task. So if there is a tool that is close to Standardized work in the product development field, I’ll argue it’s a humble checklist. The hard part is convincing your engineers that using and maintaining their own checklists will make them better engineers. Just like pilots take pride in their discipline in following checklists both for pre-flight routines and for emergency situations, we must somehow make engineers feel proud in demonstrating they’ve used the best knowledge available to solve the technical problems that confront them daily.

Are lean principles universal?

October 3, 2011
Back to top

Dear Gemba Coach,

Can we really consider Lean principles as Universal? I am currently working on a case study about the tea industry. What we have is a very seasonal, perishable product supposed to be available in various format (tea bags, caddies, pouches). The suppliers being all in Asia the lead times are what they are and I do not even talk about EU regulations imposing all kind of constraints. It is indeed easy to implement a "lean island" with no connections with the upstream partners. The result is huge level of inventory to cope with the unpredictable shortage, price increase, port disruption and new regulations.

One of my students works in a teabag factory and he kept asking the same question throughout the course. In the end, I never got around to visiting his Gemba, so I don’t know for sure, but thank you for your question, it’s made me think hard about it again: how universal are lean principles? Or, put it differently, which part of lean is universal, and which is specific to Toyota or to the automotive industry. I’m certain that every author will have a different take on this, but I’ll give it my best shot.

There is a secret to the shopfloor,” claimed Taichi Ohno, one of the founders of lean, “just as there is a secret to a magic trick. Let me tell you what it is. To get rid of muda you have to cultivate the ability to see muda. And you have to think about how to get rid of the muda you’ve seen. You must repeat this – always, everywhere, tirelessly and relentlessly.” If there is anything universal about lean, I believe this is it: going to the Gemba and scratching your head to see the challenges and working with the people to figure out how to solve problems locally and improve step by step. Whether you’re in the tea industry, healthcare, or banking – surely this applies. It’s a practice, a perspective, an “angle of view” as one could call it. An attitude. It’s dependent of you, not of the situation.

But clearly, there is more to lean than just looking around for muda and thinking how to get rid of it. What about all the other stuff? For starters, there is muri – overburden – and mura – stop-and-go, the two main drivers of mudawaste. Again, looking in your mind’s eye for muri, mura, muda is universal: anyone can do it anywhere. In many cases, you feel there’s not much you can immediately do about it, but it will certainly start you thinking about new ways to see problems.

What about flow, pull, cells and all that stuff then? Before we address this, I’d go a step further in learning to see the shop floor. Again, these are universals inasmuch as these questions can be asked in any situation, even though the answers might not be immediate or obvious. The four key questions I’ve learned to ask, time and time again, are the following:

  1. Are we protecting our customers? Do we have the firm intention to reduce the number of complaints and to deliver on time. In business, this is a universal question, although in some cases such as education or medicine and any other collaborative work (the teacher and the student need to collaborate in order to succeed at education), complaints can be difficult to analyze. Still, zero complaints and zero late deliveries can’t hurt whatever the situation, and figuring out how hard we’re trying to protect the customer is a good starting point in any case. When I visit a Gemba in an industry I’ve never seen before, this is my starting point.
  2. Do we control our lead-time? Again, I believe this question is universal: all operations are dependent on some process or other, and all processes have a lead time from customer request to delivery, and from work order to the finished activity. Controlling the lead-time simply means the process is understood. A variation in the lead-time means there are unforeseen, uncontrolled events in the sequence of work. For instance, writing a book (so many pages, etc.) should be a controlled process but experience shows that publishing one has a highly variable lead-time, because so many outside events impact authors, editors and publishers. In essence, trying to better control the lead-time is the key to better understanding the process.
  3. Can we reduce the lead-time? Reducing lead-time gets you square into lean proper. In trying to explain what Toyota was doing, Ohno responds in the Foreword to his book on 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 the nonvalue-added wastes.” I’ve learned the hard way that trying to reduce the lead-time before controlling it leads to very unhappy outcomes, because better understand the process before fiddling with it. Yet, certainly, reducing the lead-time is clearly when the improvement work because bona fide lean. And I believe that reducing the lead-time – albeit not easy – is universal.
  4. Can we reduce costs by eliminating waste? Experience shows that as you find ways to reduce your lead-time, your costs go down, simply because you focus on the nonvalue-added activities and how to remove them from daily work. My experience is, in various industries that if you reduce your quality complaints by half and cut your customer lead-time by 20%, you increase sales by about 20% to 30% (if you can follow up on that kind of growth) on the same overhead, so your global productivity (sales/person) increases and your costs go down.

Now, I’ve worked in healthcare, in automotive, in banking, in pharmaceutical and aeronautics industry and so far these questions have always applied: they’re not linked to a type of activity, but to a way of asking questions and challenging oneself. If there is one overall universal principle of lean is that of hansei: self-reflexion and self-study. This has nothing to do with business and all to do with human nature. Redefining one’s job as work + KAIZEN will always pay.

Those are the questions, but what about lean answers? What about just-in-time, jidoka or standardized work and KAIZEN? This is a trickier area because every industry has very specific processes and clearly automotive techniques will not apply across the board. Still, I’ve found that looking for some generic improvements always deliver. In particular, when in doubt:

  1. Improve your level of just-in-time: every company works at its own level of JIT. For instance, one industrial equipment company I know is at the four month level of just-in-time. When they get an order, they tell their customers they’ll deliver in four months, and they mostly do. The reason is they’ve decided to subcontract all assembly, so they wait for an order to come in, do the engineering work and then farm out assembly. Upon reflecting on the JIT principle, they’ve slightly changed this policy by ordering from their supplier a new base machine every time they’d sold one – taking the chance the customer will purchase a run-of-the mill model which they can customize later on. In effect they are stock-replenishing their equipment, which has shaved one to two months off their customer lead-time. In the year they did this, their sales grew by one third as did profitability simply because they slotted in more machines during the same year. They moved from a just-in-time of four months to a just-in-time of two. As you can imagine, the area for opportunity is endless.
  2. Improve your degree of stop-at-defect: the tendency is always to put problems aside in order to get on with work and catch back later. Stop at defect is relative since if you apply it too rigorously, then nothing ever gets done. One the other side, it’s always possible to notch up stop at the defect. The same machine company decided, at the same time as they improved their just-in-time that they would try a rudimentary form of stop-at-defect. On an A4 sheet of paper, they list a “NO GO” set of criteria that mean that the machine won’t be sent to the customer if these items are not checked. In the past, the machine was sent at the requisite date and then all problems were sorted out during the installation – which made some customers really frustrated and angry. So now, not only the company is under the pressure of faster turnaround, but also the CEO personally stops some machines if he feels the NO GO is not cleared. This is far from comfortable, but it has highlighted some deep technical problems and changed the engineer’s attitude to listening to their customers. As a result one of the additional machines they sold was purchased by their harshest customer, who suddenly found engineers willing to listen to his complaints and ready to work on them.
  3. Involve operators in improving their own workstations: in any work environment, the first place to start is with avoiding accidents and improving working conditions. As the only people who really know what goes on are the operators themselves, getting frontline workers to improve the ergonomics of their own workstations seems to apply in any industry, whether with nurses in healthcare, assemblers in electronics or software ergonomics in IT, exploring detailed work is always reach in learning. The tendency of many companies is to apply corporate standards. The machine company took the problem the other way around and started writing standards from scratch as the result of problem solving efforts. The project managers are asked to have their own standards folder in which they inscribe their conclusions from their own KAIZEN efforts. The upshot of this approach is that visualization in the workplace and standards are build from bottom up and respected because they are well understood.

I can’t say whether it makes sense to implement a “lean island” in the tea business – if it looks silly to you, it probably is. What I’ve found from exploring many lean attempts in many situations is that the typical problems of lean are generally relevant (universal?) just as the typical lean solutions are generally useful (universal?) However, I’ve also learned to be extremely cautious with copy and paste. People come up with leaner processes when they’ve come up with a deeper understanding of the specific technical problems in their own work.

How far can lean concepts be applied outside of the automotive industry? Hard to say. For instance, the CEO of the construction company I mentioned in a previous column recently showed me an application of yamazumi in housing. In order to accelerate the flow of work through the building, two separate trades decided to share some of the burden in order to balance the overall workload. Knowing the industry I was simply amazed – I never thought it’d be possible. The company’s management immediately wanted to generalize the practice, but I held them back. I pointed out that these two specific contractors knew each other well and were technically skilled enough to do this, but if they asked their other contractors to do the same, they’d probably enter a sandpit and endless trouble, as well as a poor result. The fundamental problem, I argued, was to develop other pairs of contractors with the same understanding of the overall flow of work to be able to come up with these kind of solutions by themselves: making people before making buildings.

Which is what I was told all these years ago by the very first Toyota engineers I watched performing KAIZEN. There is only one golden rule: we make people before we make parts. This requires a spirit of challenge, open mind and teamwork, as Pascal Dennis phrased it in his great lean novel Andy and Me. Every industry is different, but all human beings share the same capabilities and potentials – that is universal. As one sensei once told me, the biggest room is the room for improvement.

Should we have our own TPS "house"?

September 21, 2011
Back to top

Dear Gemba Coach,

My management wants to build our own version of the TPS (Toyota Production System) house in order to standardize our lean approach. Do you have any advice on how to do this?

Actually, on this specific question, I do: don’t do it. I’ve seen many lean “houses” over the years and just by googling “TPS house” you’ll probably find more. In my experience, such efforts are about implementing lean in the company, not helping the company to become lean – and rarely pay off. There are two main issues to consider when adopting the TPS house: firstly, how and why it actually came up within Toyota and secondly how these concepts translate out of Toyota and in your own organization.

As John Shook has pointed out, one should not confuse the Toyota Production System and Toyota’s system of production: TPS is fairly different from what Toyota actually does on its production lines. It sounds fairly close, you’ll say, and I have to agree.  TPS shows the way to perfection, the True North. Toyota’s system of production is the set of actual practices that Toyota has in place right now – which evolves according to events and local competence. Any Toyota plant is only as good as its plant manager.

The ambiguous term “system” has also caused a lot of lean heartache over the years. Bear in mind that we all tend to interpret what we see from our own pre-existing perspective. Understanding any artifact from the point of view of its creator is often difficult, as can be experienced when we look at any new piece of art or technology. Our traditional industrial perspective is clearly Taylorist. We’ve been brought up to believe that if we design the right process and we apply it across the board, we’ll get the right results. Logically, it’s easy to interpret the concept of “production system” as a set of processes that need to be standardized across all operations. In this mindset, lean means replacing our existing processes by “leaner” processes – and it makes sense to systematize these lean processes in a roadmap, house, manual, etc.

Never-Ending Homework

When Toyota pioneers dreamed up their system, they were working from a very different premise. Their obsession was kaizen, not systematization of processes. From this perspective, a system meant “a set of interrelated activities to improve quality, cost, lead-time, and productivity.” It was NOT a set of actual production processes, but a box of homework exercises that, if practiced assiduously, would lead to improved processes. There is no such thing as a lean process: opportunities for further kaizen can always be found. The activities summarized in the “system” give a clear direction for the next step of kaizen:

  1. Customer satisfaction -- Oddly, but quite revealingly, this aspect often disappears from adapted houses. The first exercise to work on in order to become lean is to improve customer satisfaction. To start with this means striving to deliver good parts on time: no quality complaints, no late deliveries. Sure, this can be achieved by holding a inventory and lots of quality inspection, which is exactly what Toyota engineers do when they’ve got a doubt about a process: they put finished goods inventory and add inspection operators, with the explicit aim to kaizen it away. For any company, asking oneself what would customers complete satisfaction look like is the key to getting everything else right.
  2. Jidoka -- The Jidoka pillar is probably the most original part of TPS and the hardest to understand, because it blends a certain understanding of quality with a vision of the relationship between human work and machine work. To take one aspect of it, the homework exercises are about built-in-quality. No step in the process should accept bad parts, make bad parts or pass on bad parts to the next step. The basic exercise is to stop whenever any defect has been identified (by either the operator or the machine) and investigate until the cause of the defect is found and eradicated. This will lead you first to eliminate human errors, due to not following standardized work, then to work with manufacturing engineering to eliminate causes of defects in the way machines are designed and finally to improve product design so that less defects can occur, at which level one can accurately speak of “build in quality.” There are a number of technical tricks to do so, from andon to poka- yoke, but the main idea is to practice the activity of “stop and investigate at every defect” in order to learn about what causes defects.
  3. Just-in-time -- The favorite pillar to most industrial companies, JIT is about learning to deliver exactly what has been ordered exactly when it has been ordered and in exactly the right quantity. The emphasis is on “exactly”; no less, no more.  Now, this turns out to be quite a challenge, because production systems are usually conceived to be kept running (for labor cost and equipment payback considerations) regardless of technical issues or part shortages. Forcing oneself NOT to produce more than immediate demand BUT not to accept to produce late is very demanding and mechanically involves reducing batch sizes and stabilizing processes. THERE IS NO JUST-IN-TIME process in the abstract. Or, more to the point, every process has its level of just-in-time: month? week? day? hour? You start with what you’ve got, level the plan, reduce the batch size and fight each production loss until you increase your level of just-in-time.
  4. Standardized work and kaizen -- Involving operators in designing or redesigning their own work stations has been a Toyota obsession from very early on. Indeed, in the first published paper about TPS, the authors highlighted two major distinctive features of the production system: just-in-time production and respect for humans, meaning that workers are allowed to display in full their capabilities through active participation in running and improving their own workshops. The underlying mechanism to do this is to practice standardized work and kaizen relentlessly.

Housing Bubble

There is not ONE version of the Toyota house, but several according to when and by whom it is drawn. Some place heijunka along with standardized work and kaizen on the base. Others insist that there should be a further basic step of “stability.” The French plant came up with 5S, TPM, and problem solving as a base below standardization and kaizen. Since Fujio Cho formulated the Toyota Way 2001, 10 years ago, some houses now have kaizen and respect as their basic pillars, and so on. I’ve just seen one with “finding waste and problems” at the top and “visual control and flexibility” as the base. All equally correct.

The point is that the Toyota Production System house is Toyota’s – not your company’s, and appropriating is through making your own is likely to 1) not make much sense culturally and 2) induce misunderstandings you’ll later rue. Use the TPS house as a way to explain what lean is about and how Toyota does it, by all means – we certainly all refer to it frequently, but don’t try to design your own – that’s missing the point.

The point of the house is that certain activities can be performed independently of industry or job, whether in engineering, production, purchasing (maybe even sales?), etc. For instance, getting to the next level of just-in-time is pretty much like saying: lose weight by walking faster and exercising more often. Fair enough. The details of how Toyota actually practices this are very industry specific (there’s nothing quite like automotive) and Toyota specific. They can inspire, but copying the results of years of practicing just-in-time or Jidoka improvement will NOT deliver anything for your own business. At best, you’ll invest in implementing stuff on the shop floor no one will ever know how to use properly.

On the other hand, it’s hard to fight city hall, so if management wants it, you’re going to have to comply sooner or later. In this case, I’d suggest:

First, try to get the management group to formulate clearly what they want out of their lean efforts – the test method so to speak. For instance, if we take Art Byrne’s list from Wiremold (in Lean Thinking) this would be something like:

  • 100 percent on time delivery
  • 50 percent defects reduction every year
  • 20 percent productivity gain every year
  • 20x inventory turns
  • a visual workplace utilizing 5S

Getting agreement on something like this and getting this on paper is key to your success and can rekindle the deeper argument of how to become lean.

Second, stay as close as you can to the basic TPS house seen as improvement practices:

  • Customer satisfaction must be improved on quality, cos,t and lead-time
  • Start with safety and morale
  • Just-in-time levels must be improved from month, week, day, hour, minute etc.
  • Jidoka must be improved by better visualizing problems and responding right away rather than working around them
  • Workstations must be improved by getting operators to standardize and improve constantly how they work.

DO NOT try to fit all tools and practices to help people make sense of the “toolbox.” This is a common mistake and its incomplete, confusing and encourages precisely the wrong kind of thinking.

  • Third, as your company is taking its lead from Toyota by creating its own production system, make sure to insist that the “system” formulation is never permanent in Toyota, but subject to rethinking and evolution. The “Toyota Way” was termed the Toyota Way 2001 to explicitly make the point that this was what Toyota thought in 2001 but that it should be seen as a signpost on the journey, not the ending.

The one consistent feedback on translating TPS into other companies is that first, companies pick and choose which aspects they think will work for them, and ignore the others. You can see this easily by comparing how often just-in-time is attempted or written about to how rarely Jidoka gets mentioned.

Secondly, firms will “adapt” the tools and principles to make them more palatable to the local culture. Most plant managers will actually argue this point vehemently.

Twenty years experience show that both tendencies are a sure recipe for disappointing, indifferent results. TPS works first because it’s a system, and you can’t ignore a part of it any more than you can choose tables with only the left legs, and secondly it delivers when you adapt yourself to it, not the other way around. This is exactly what Toyota has done, as it continues to struggle to be better at customer satisfaction, just-in-time, Jidoka and standardized work and kaizen, and THAT is the example to copy and take heart from.

Why Create Poka-yokes—and Why Disconnect Them?

September 7, 2011
Back to top

Dear Gemba Coach,

I’m a manufacturing engineer and since I have started participating in kaizen workshops, I have noticed that production supervisors tend to disconnect some of the poka-yokes we’ve put in place in the machines. When I challenge them about this they argue that operators can’t run production and cope with the complexity of our machines. I am perplexed by this and wondered whether you’d have a comment.

This is not unusual. In several cases, I’ve seen production teams abandon their automated equipment altogether and return to manual assembly processes and end up increasing productivity. There is no right or wrong in the matter, and it’s a question of spending more time at the Gemba observing how people actually connect to the machines in order to make good parts.

The three most common situations I’m familiar with are supervisors disconnecting in-built poka-yoke because:

  1. The poka-yoke (error-proofing device) is built in such a way that it adds to the operators’ burden in making the part.
  2. It’s so strict the machine is stopped all the time.
  3. It gives too many false positives that hinder production, or it’s so unreliable it’s down all the time.

People Proof

Just the other day, I was looking at an automotive supplier’s efforts to build a pick-to-light system. In order to make sure the operator assembled various parts in the right sequence (which, they knew, had an impact on quality), they’d rigged the component bins with lights which would indicate to the operator which part to grab next. The engineers had also built in a poka-yoke: an electric cell spotting the person’s hand going into the bin. If the person skipped a part in the sequence, the process would stop, and if the person went into the same bin twice, ditto.

Regardless of how elaborate the engineering system was, the ergonomics of the workstation were unfortunately not so great. Operators had to reach over a conveyor (with the assembled product on it) and to dip into largish containers – which were particularly awkward when they had to grab the last remaining components in the bin. As a result, they had frequent mishaps, such as letting go of the part and having to fish for it again or, in a case of a complex-shaped  component, having to shake the parts to extract one. As a result, the poka-yoke would be triggered and stop the process several times an hour, which got on everyone’s nerves (they had to call the supervisor and document the stop and so on.) There are easier methods of checking that the operator has grabbed the right part, such as asking them to push the light as they go. And these methods assume that people work hard at making good products rather than, as many engineers assume, that the equipment has to be people proof.

In a case of the second instance, an electronics company I know decided it had to tackle seriously its quality problems. So corporate issued an instruction to reprogram the machines with poka-yokes so that they’d stop at the first defect as opposed to all the varied rules they used locally (three consecutive defects, five defect in an hour, etc.). Asian plants reacted immediately, and chaos erupted in many areas where the process was really not under control. As a result they stepped back and planned a more layered approach, distinguishing machines with stop-at-defect (green sticker) and not-stop-at-defect (red sticker). In Europe, as can be expected, people went at it more cautiously, as the contradiction between stop-at-defect and hit capacity appeared starkly: don’t try it on an unstable process with capacity constraints. On the whole it has to be said that in this case the stop-at defect campaign had spectacular results, decreasing complaints by 30% globally.

Killing Quality

Stop-at-defect is the test to see that you’re serious about quality. Without stop-at-defect, you can’t see the context of the problem when it occurs, and investigation happens too late – it is said that in murder investigation the probability to catch the killer decreases exponentially with the time it takes for the investigators to get on the scene. But stop-at-defect is first and foremost a social challenge. For it to succeed, you need a social structure ready and able to cope with it. If the frontline management is not primed and keen to investigate when the process stops, chances are they will disconnect the poka-yokes in order to run production smoothly, and trust to final inspection.

Finally, some of the poka-yokes manufacturing engineers dream up can be over-engineered or just too complex for the job. Cameras, for instance, are notoriously fickle and require lots of imagery software and computer crunch power to spot defects, particularly when there are variations on how the part is presented. In one such case, the supplier received numerous complaints from the OEM because of misplaced labels on the part. Since the label doesn’t do much functionally, no one at the supplier worried about it overmuch until it became a serious management issue. After many misunderstandings it was finally discovered the OEM has a poka-yoke reading the label on the part for traceability. Without the correct label, the assembly process would stop. In fact, if the label was slightly misaligned or misplaced, the assembly equipment would stop.

Lines with overly complex poka-yoke devices tend to lose much productivity by having operators simply run the part through the detection device again until a part would be consistently stopped. Not surprisingly, production management can be tempted to simply disconnect the poka- yoke in order to run the line.

Make Machines Talk

Poka-yokes are one of the tools in a lean system’s jidoka pillar. jidoka is one of the least studied (and as a result the least known) aspects of the Toyota Production System and many experts argue that it is also the hidden part of the iceberg: stocks reflect variations and leaning a process to carry less inventory requires a robust methodology to solve technical problems.

jidoka’s translation in plain English is complex as the Japanese kanji meanings are complex and very nuanced, open to a wide scope of interpretations. In the early days it was translated as “autonomation: automation with a human touch,” which, I don’t know about you, but I don’t find very enlightening. Two key aspects of jidoka are:

  1. Built-in-quality: stop rather than pass a defect forward.
  2. Separate human work from machine work (http://www.toyota-global.com/company/vision_philosophy/toyota_production_system/jidoka.html).

Poka-yokes are an essential part of jidoka inasmuch as they allow both detecting defects and separating human work from machine work (no need for a person to keep watch on that part of the process) – but if, and only if, they actually help to visualize or highlight problems. The essential idea is to “make the machine talk to the operator” rather than make the machine operator proof. Toyota’s current definition of jidoka is to drive daily improvements by:

  1. A machine detects a problem and communicates it.
  2. A situation deviates from the normal workflow.
  3. The line is stopped.
  4. Manager/supervisor removes the cause of the problem.
  5. Improvements are incorporated into the standard workflow so that good products can be produced. The emphasis is on machines detecting problems by themselves, and then humans reacting to it and solving the problem.

In response to your question, this means that the best poka-yokes are part of a kaizen process rather than imagined ex nihilo by manufacturing engineers. Good poka-yokes should:

  • Not hinder the operator in any way. Separating machine work from human work means that the machine can produce the part on its own while the person is dealing with the next step of the process. If the poka-yoke imposes on the operator to slow down or backtrack on the process, it’s the wrong solution.
  • Identify and stop bad parts. There are prevention devices and detection devices. The ideal is to have prevention devices which stop the operator from making a mistake or stop a nonconforming part from progressing in the process. In many cases, this is hard to do so people build all sorts of detection devices – which is dangerous when the detection technology becomes too complex and not reliable enough.
  • Give quick and specific feedback. The whole point of a poka- yoke is to be able to kaizen the process by eliminating the cause of the mistake. The purpose of the poka-yoke is to give the operator immediate feedback on what is wrong where, and stopping the equipment so that the person can safely inspect the various operating conditions and find out what’s wrong and fix it rather than run in degraded mode. For instance, make sure the defective part has to be taken out manually in order to inspect the process and analyze what went wrong.
  • Be cheap and simple. Any device adds cost to the process both in terms of investment and operator labor. Cheap and simple devices can help the operator to do a better job, but unfortunately many poka-yokes I see are too elaborate and both costly and demanding for the people who have to build parts every day.

In fact, I believe you’re asking exactly the right question and are already on the path to solving it yourself. The ideal poka-yoke is a device invented by an operator in the course of doing kaizen. For instance, in one assembly process where they had to switch from one bin to the other according to variants, the operators simply covered the redundant part bin to avoid dipping in the wrong one. Or a simple modification of a fixture so that the part can’t be wrongly placed, and so on.

If you’re involving yourself in kaizen, you’ll probably discover that people are right to disconnect the poka-yokes that hinder them, but also that when they’re asked the right questions, operators can come up with very clever ideas to mistake-proof the process. The operational answer to your question would be to have manufacturing engineers to kaizen similar processes before designing the new machines so they understand the true purpose of poka-yokes from the operators’ perspective rather than as feats of engineering

How Can Lean Take Root in a Crappy Culture?

August 31, 2011
Back to top

Dear Gemba Coach:

I've done a lot of working with lean, and recently started my first coaching/consulting gig. And while I'd love to help by introducing people to flow, takt time, pull, and all the nifty lean tools and ideas, the most striking thing I've learned is how much hostility and mistrust exists among people. How can I help lean take root when the biggest problem turns out to be a crappy culture?

To be honest, what you describe could be said about most working environments. Yesterday I was visiting an industrial company and trying to understand, with the CEO, why a new development project was getting nowhere. The project manager accused another project manager of having jumped the queue for tooling, pushing her project ahead of others. The culprit defended herself by saying she was under enormous pressure from the customer and that they’d had to redo the tool because these idiots in tooling had botched it the first place. In tooling, it was all about the tool designer misunderstanding what the project manager wanted and, anyhow, nobody could ever work with anybody in this company.

The CEO was aghast. But the day before, I’d been walking the Gemba in a hospital where nurses, surgeons, and administrative staff were at each other’s throats over surgical theatre planning: medical secretaries could go straight into the planning system and change appointments, and in any case, surgeons never showed up on time, which wasn’t going to happen because sterile equipment was missing from central sterilization unit, and so on.

I’m OK; You’re Not

There is a well known psychological bias called the fundamental attribution error: we cannot help but overemphasize personality-based explanations of others’ behaviour, while dismissing situational-based rationales. The funny part is that we tend to reverse this when explaining our own behaviour, in which case the situation matters greatly more than our intentions (“I didn’t mean to do that”) or character (“I’m not like that, circumstances forced me to act in such a way”).

With this in mind, we can look back to real-life situations and see at the Gemba that work is, in many ways, set up to have people at odds with each other. First, there rarely is a common objective. People either define their own objectives or have them set up by their bosses in functional lines. Since all processes are integrated, different people seeking to optimize different aspects of the same process will invariably pull in different directions (what you win, I lose, and your loss is my gain), and thus fight – and attribute conflict to personalities or character.

Secondly, although most functions have traditions and professional criteria for what it takes to do the job well (i.e. what it means to be a nurse, a surgeon, tinker, tailor, soldier, sailor), few people understand the muda they create by their own technical choices and decisions. When the project manager sidesteps the tooling queue, she is creating consequences for everyone in the process she clearly does not understand or see. For instance, when a product designer chooses to use a different part to solve a problem, they hardly ever realize they’re creating an entirely new supply chain. Or when medical secretaries change the schedule for whatever reason, they have no inkling of the absolute mess they create in the entire operating theatre. Small, necessary changes for one person can involve large-scale overburden, stop-and-go and waste for many others. Until the person is trained to see it, they will continue to do so blithely, not understanding why all the others hate their guts (oh, these nurses, you know what they’re like…).

Trust in Problem Solving

To answer your question, you must first accept that trust is never a given. We start from a normal ape-like state of mild distrust, with every one wishing that others would simply let them get on with their job without impinging. Trust needs to be constantly, deliberately grown, like taking care of a plant, and it can be destroyed in an instant, in the same way that it takes years to grow a tree and minutes to cut it down. The lean system to build trust is teamwork: solving problems together. Indeed, in the hospital case, the administrative director I was talking with did not start by trying to solve problems outright with a lot of people who at the best don’t trust each other, at the worst hate one another. He started by deliberately building trust in relationships with others by solving specific problems with them. The trick here is to realize that improvement can only happen within a relationship and relationships can be built around Problem Solving.

By getting people to solve specific problems together whether they like each other or not – which often involves locking them in one room and banging heads together until they come to some agreement – mutual trust can seep back into the system. Teamwork is about giving individuals single responsibility to solve specific problems by working with others. Progressively, they’ll realize that the best way to help oneself is to help others achieve their objectives and that there is so much scope for improvement everywhere that it’s not that hard to do. In the hospital case, the administrative director started with something straightforward: the time of first incision. Every day he’d ask the teams to keep track of this and solve problems one after each other. It didn’t work in every operating theatre, but it did in most and the hospital gained overall 30 minutes of theatre use (it doesn’t sound like much but in a large hospital, this is quite significant). Most importantly, some teams learned that surgeon, nurses and admin staff could work together and so moved on to tackle other issues.

If this is so, the question then becomes: which problems can I pick in order to rebuild trust in a rotten culture? And the answer to that is written in your question: start with takt time, and ask people to keep to it. More specifically, start with customer complaints, and force teams to analyze these thoroughly. Just ignore the finger pointing: this is unavoidable and can be simply overlooked. By making people refocus on the main reason they all have to work together, some of the diverging objectives will exposed and be easier to deal with.

Still, only working on incidents is not necessarily conducive to more trusting relationships (it’s always someone else’s fault, remember). So the second step is to clarify what takt time means in the business and focus everyone at delivering at takt time, exactly. Whether these are new projects in engineering, surgical operations in the hospital or feeding customers in a restaurant, takt gives a rhythm that requires regular cooperation from all functions in the process.

Granted, visualizing what the takt is outside of straightforward manufacturing environments take some serious lean practice, but the thought to hang on to is that there is always a takt (after all, takt is an arbitrary device: open time divided by customer demand) to pacify the flow of, well, just about anything. Scratch your head and figure out what the takt is first, how you can visualize it for all second, and third how you can marshal every one’s efforts to keeping the takt, no arguments. Once you’ve figured out some concrete takt (or pace, whatever fits intuitively), the issue of trust is already half solved – it then becomes a case of managerial grit and as with Star Wars fighters in the Death Star’s canyons: stay on target! Stay on target!

The Lean Way to Change

Culture is both an input and an output of human behaviour. In my experience, it’s more the latter than the former: a collective expression of the fundamental attribution error, a way to explain to ourselves our collective actions and somehow cement and justify them. Culture change is thus much, much harder than situational change. So don’t worry about it and trust that if you change the rules you’ll change the game. The lean way to change the rules is to start with focusing on customers through quality and takt, and flow everything from there. Mutual trust will emerge from the practice of solving problems together regularly, takt will show which problems to solve daily.

If two people really don’t get on, no amount of lean work is going to change that. But cases of deep abiding dislike are rather few and far between. In all likelihood the broken process creates tensions, which are then interpreted as personal conflicts. Be soft on the people, tough on the problem and stick it out through several PDCA cycles and you’ll see the culture evolve, and most issues simply vanish.

Takt Time Thinking for a Low-Volume High-Mix Company

August 23, 2011
Back to top

Dear Gemba Coach,

Our company produces custom products that cannot be easily forecast in terms of when they will be ordered, and in what format. How can a company facing high-mix, low-volume, and unstable demand establish a production system that uses takt time?

Recently I discussed this type of problem with CEO John Bouthillon, who has turned around his construction company (building or renovating apartment blocks) by thoughtfully adopting core principles of lean thinking when facing low prices and high instability. In the past four years, he’s achieved double-digit growth, more than doubled his cash and steadily improved his profitability. I asked him what, of all the lean concepts he has worked with, has made the biggest impact on his business. His immediate answer was leveling.

A construction business is the epitome of high-mix (every project is a one off), low- volume (the company makes between 15 to 20 projects per year) and very unstable demand as no one know where or when the next project will come from. So how can takt time apply in such a context? Why would leveling be so important?

Profits by Problem Solving

The basic idea of takt time thinking isn’t that hard to apply. There are 52 weeks in the year, and if the company makes 17 projects, it needs to deliver one project every three weeks. From the Gemba however, this is not quite that simple. No two projects are alike. Some are large, some are small. Some are simple, some complex. Furthermore, projects that appear on the firm’s horizon can change dramatically from the time that competitive bids are put out to the actual demands of the project once launched. Everything changes all the time.

When John took over the company, the general wisdom was to bid for every project opportunity, add a standard margin to the estimated cost. Fluctuations in cost were partly mitigated by churning through employees as needed: Just poach site managers from competitors, hire on more temporary labor and off you go to build the condominium.

John started his lean transformation by asking his managers to focus on safety and orderliness on the construction site. Previously, when people hit a snag they were likely to put it aside and keep on working in order to keep on schedule. But this approach would eventually prove costly, as problems would add up, multiply, and require such systemic workarounds that there numerous and costly dramas. And so John worked with his managers on a policy of solving problems as they appeared – a rough form of jidoka. This new tack delivered unexpectedly large bottom line benefits. But the practice created a new problem.

Instilling a problems first policy revealed both the value—and the cost—of having well-trained workers. It became apparent that there was a big correlation between the ability of the site manager and his team at solving problems, and the profitability of their project. But this profit came at a cost—an investment in the training of people in Problem Solving. Competent workers become a critical resource; which meant that simply hiring individuals from competing firms would not do. The company needed employees who could adopt the problems solving approach – if at all. This took time and investment.

And so the company found that the success of projects was directly related to competent resource availability. Mura creates muri, which creates muda. Too many new projects at the same time and the management team is overburdened and can’t properly solve problems. Too few and they grow restless and look for opportunities elsewhere (remember larger competitors know this firm trains its people well, so they have a tendency to poach). Maintaining a steady flow or activity became essential – hence the leveling. Developing people by developing their autonomy in Problem Solving has become a very practical issue for John, and the acknowledged key to sustainable profitability.

Controlling Lead Time

The problem of leveling something as unpredictable as a low-volume high-mix sales landscape remained. John started working with his sales director to bid for work according to the leveled plan first over one year, then over two. This meant shifting from grabbing every possible option to stretching their time horizon in order to bring in work when you need it.

The second large issue beyond order intake is lead-time control for every construction project. Increasingly, a building must be finished at a set date because the management resources are scheduled to start the next one at a certain date. Given the large nature of these projects, and the huge amount of resources and logistics involved, hitting these dates are critical. One to two months late, which tend to be the norm in this business, can no longer be shrugged off. Consequently, after safety and then quality, John is now focusing his firm on lead-time control – which has uncovered many other new problems.

And yet, the results are clear. In John’s mind, the effort of leveling a business that, by nature, seems intractable to takt time is exactly what shines a new light on how business is done and highlights opportunities for progress. This is the wider point beyond construction. As long as Henry Ford produced black Ford Model T’s, he had no real need for takt time: all parts built would be assembled and sold, eventually. His only concern was flow, not pull. Toyota opened a different path long ago when it rejected dedicated lines for new models or complex options, bringing a higher mix to its own lines instead (as well as fairly small volume in the early days).

In one of his early visits to Toyota plants, back in the 1980s, my father (and co-author of The Gold Mine and The Lean Manager) was struck by the variety of vehicles assembled on the line. After careful observation, he concluded, “Ah, I see what you do. You schedule a short and a long vehicle in order to stick to the overall takt time.” “Yes, they answered, and the kanban.” He could see that if an operator had a short work content, and then a longer work content, overall he’d be keeping to takt. But why the kanban? Because, he was told, the line is also programmed in terms of options so that kanbans return the more regularly possible to withdraw on parts suppliers. Wow.

Companies that argue that their business has too little volume, with too much volatility, and too high a mix to apply takt time thinking have gotten hold of the wrong end of the stick. The point of takt time thinking is to shine a new light on your operations, regardless of how variable it is, and to see how rationally you can use your resources. Whatever your product mix and volume variation, how hard can it be to average daily demand over one month, and to divide open time by this number in order to compute a takt? Anyone can do this. Now, the real question is: how can I deliver the exact product customers want 1x1 in sequence, precisely at that takt?

Be Level Headed

Make to order is probably not worse than having mass products with components made in huge batches requiring long changeovers. In the former case, the issue is dealing with work content variation, in the latter with inflexible equipment. The point is that takt time thinking is NEVER easy but ALWAYS shines a light on your worst waste, particularly in terms of capital expenditure.

There is no set answer to your question other than a commitment to learn about how to keep takt. On the one hand, we definitely want to make products in the sequence in which customers ask for them – no debate. On the other, we also want to stick to takt time, or at least aim for it. These two aims are not always convergent, but we know that the least wasteful way to produce is somewhere in the overlap between these two regions. The answer is: stick to your guns and explore until you figure out how to level better and better.

And, by the way, it never gets any easier. Toyota has been leveling for longer than any one else in industry. It has sophisticated systems to trade-off car allocations by dealership and markets and level the factory workload. It lives and breathes all of this. And still, the great recession revealed it had let its inventory of finished cars creep up over the year and got caught with its corporate pants down just like anyone else when the bottom fell out of the market. Leveling is no easier for Toyota. Plants are not built fully flexible: first they master a vehicle (quality wise), then they tackle a second, and progressively they’re brought to greater flexibility. It’s hard work.

But that’s EXACTLY what lean work is: don’t adapt lean to your company, find sensible ways to adapt your company to lean instead. Regardless of what you make, calculate takt for your products, calculate takt for your main components, and scratch your head until you see how your own policies create stop-and-go, overburden and, hence, waste. There is no lean thinking without takt time thinking.

Why Is Failure Key to Lean Success?

August 10, 2011
Back to top

Dear Gemba Coach,

I am a LSS black belt working with a sensei to improve our performance. We conduct many workshops that get results, but the sensei focuses on only what we didn’t achieve. Although I understand the logic, I find this tiresome and difficult to explain to the teams. Many people have invested significant time and effort in improving things and end up feeling let down. How do I help the group deal with this?

Firstly, let me say that I feel your pain: I’ve been there. In fact, one of my senseis is my father, and so, as you can imagine, this is not always easy. All too often, I find myself echoing my nine-year-old son: “Oh Dad! You don’t understand! It’s not fair! You’re ruining it all.” I remember a discussion a while ago with another lean expert whose sensei would start every discussion by saying something akin to “you will fail, but try anyhow.”

Now, failure is not a word we like to hear. And we all crave praise from the people we respect. Without this recognition, finding the motivation to fight to make things better is a daunting task.

I would suggest that you try to understand this “you will fail” attitude from your advisor’s perspective. Your sensei is not your boss, and keeping you motivated is not his or her job. In fact, getting you to learn is not even the key to the sensei’s mission. The sensei’s role as regards to workshops is very clear: to push the teams to improve the furthest possible without investment, so that the company can learn. The most important person who needs to learn from shop floor experiments is the top executive visiting with the sensei: his or her understanding of what is possible has the greatest impact on further decisions. Next on this list are the members of the team, who can learn how much better they can do when they stretch themselves. Number three is the lean coach. If the group is unhappy with that, so be it. Most senseis I’ve met regret it but won’t lose any sleep over it.

Learning by Failing

But why be so mean? Why not praise people for their results? Consider the sensei’s challenge. Most kaizen events can produce significant results—without challenging any of the assumptions about how work is performed. Just this week, I was visiting a kaizen workshop in a production cell where it appeared that they had one person almost full time (there was a small assembly operation as well) checking components from the previous process one by one because of the high rate of defectives. By moving the quality check where it belonged, at the previous process, they had radically improved the cell’s productivity. Or had they?

They had certainly solved one problem. They had also correctly applied a tenet of lean thinking: to deliver only good parts to your internal customer. Full marks on both items. But they had also successfully avoided rethinking their cell in terms of better balancing and takt time thinking. In this typical instance, they’d hit upon a visible improvement—without having to challenge any basic assumptions about how they were organized for production. In other words, they had made improvements, and they had not learned anything much. Should they be praised for their effort? Absolutely. Had they failed? Completely.

Lean thinking is based on applying the scientific mindset to business situations. In science you learn when you fail. Successfully replicating an experiment may be reassuring by confirming that that you know what you know, but you have the most to learn in those dark corners where the experiment doesn’t conform with expectations. It means that there is something about your assumptions that doesn’t square with reality.

Actually challenging one’s thinking and looking for new ideas is hard. Our brains are hardwired to like known ideas and to dislike mistakes or failures. As Taichi Ohno realized at the birth of lean, if you don’t push yourself in to a mental corner and point an imaginary gun to your head, you’ll come up with a solution to the problem which generally involves workers working harder but without ever challenging the underlying reasons for the problem. Hence the fabled “5 Why?”

Wired for Status Quo

Social psychology has uncovered a few key findings about failure that should be noted: our brains have marked in-built biases for loss aversion, dissonance reduction and conformity.

  1. Loss aversion: first highlighted by Amos Tversky and Daniel Kahneman (who received the Nobel prize for this work), it appears that we suffer more from a loss than we enjoy from a gain. As a result, we overestimate the probability of loss, and the expected pain that goes with it. Furthermore, when loss does occur, we’re liable to make irrational decisions to compensate for these losses quickly. The sane thing to do is to learn to be quickly at peace with our loss, but that’s pretty hard to do.
  2. Dissonance: Leon Festinger first showed that when confronted with specific facts that go against deeply held opinions, we find ways to dismiss the “dissonant” information without realizing we’re doing so.
  3. Conformity: In another classic experiment, Solomon Asch showed that when surrounded with people holding the same opinion, we often adopt a position that we know is evidently wrong.

As a result, improvement efforts are inherently biased against looking for real change. They geared instead towards “fixing” the issue without challenging the underlying cause. As a result, no real learning occurs. Researcher Mark Fruin pointed out there was a word in Japanese, “mannerika” to describe thoughtless actions or apparent change without real change – think of the “here we go again” groans you get with some kaizen teams.

kaizen efforts are truly fruitful when the person or team realize an improvement beyond what they already know. This is the zone sensei seek – the moment when the team breaks the barrier of fixed assumptions and starts exploration for real. In general, this means acknowledging the immediate efforts without taking them seriously, focusing instead on what we’ve failed to achieve. Pushing people into that mental corner is essential to moving forward. It’s a countermeasure to the profound mental biases towards pretending to learn (confirming a further example of what we already believe) as opposed to real learning (acknowledging and understanding why we were wrong about something).

I guess that explaining why doesn’t make it easier to accept. Except that it does, to some extent. As you learn to seek that difficult corner, that obscure place where something strange is going on we need to understand better, you will discover the thrill of the chase, the excitement of the police investigation. In this mental frame, convicting the wrong suspect becomes unacceptable and chasing the true perpetrator imperative. Although it doesn’t get any easier to hear “you’re wrong” or “you failed”, one learns to get over it quickly by simply focusing back on the task at hand: what is the underlying cause driving this situation?

And the same applies to the groups you facilitate. If you set expectations right from the start, and you tell them how it’s going to be, they’ll be less surprised the next time the sensei comes along and just frowns and shakes his head disapprovingly as they proudly present their result. And if you quickly pick up on the remarks and get the team moving right away into the deeper investigation (why did he say that? What have we missed?), you’ll find that the team won’t fixate on what they feel is a negative reception, and will be more able to accept the positive part of their work – the improvement itself.

Escaping Ruts and Rituals

In my personal case, this aspect of lean became easier when I stopped focusing on each immediate kaizen activity, and looking instead at a sequence. I’ve come to realize that what people conclude from one event doesn’t mean much. When they’ve conducted three or four, they start to see things differently. By the tenth, they begin to understand the deeper issues. When you look at a sequence of activities, and not just one, to keep pushing for further answers makes simple sense.

Lean thinking is never easy because although we’re at our best when we’re fully engaged in discovery at work, keeping ourselves there is hard work and it’s easy to slip back into mindless routine and repetition. This is as true about kaizen as it is with any other human activity: without care, any behavior is likely to be ritualized and lose its purpose and meaning. Our mental images easily become cages we hold on to for comfort. The sensei’s role is to break these cages and set your thinking free. Putting the events in the perspective of a regular run of activities and sharing this understanding with your teams should help you cushion the blow.

Method vs. Tool

August 2, 2011
Back to top

Dear Gemba Coach,

I’m an engineering student working on my master’s thesis, which focuses on the Lean philosophy and specifically on Lean tools. Different authors often use the words “methods” or “tools” without making a distinction between these two concepts. For example, some authors refer to TPM as a method while others call it tools. I think that TPM, JIT, SMED, Heijunka are methods and the 5S, VSM Kaizen are tools.  Perhaps we could use the expression “solutions” to include both methods and tools? Where do you stand on this?

This reminds me, many years ago, in the previous century, before John Shook and Mike Rother published the seminal Learning To See, I remember some engineers who were discovering lean at the time argue the difference between the MIFA (Materials and Information Flow Analysis) and the MIFD (Materials and Information Flow Diagram). In your terms, we could probably say that the MIFA is a method (a procedure or processes for attaining an object according to Merriam Webster) while the MIFD is a tool (a device that aid in accomplishing a task according to Merriam Webster). With this in mind we could then make the case that Value Stream Mapping is a method whereas a Value Steam Map is a tool. One can easily forgive lean authors for using tool or method indifferently, because actually the same thing can be seen either as a method (the analytical process) or a tool (the formats supporting the process) according to the point one wishes to make, so let’s go to the Gemba and think about it from that perspective. Standing at the Gemba, I’d have to say this question is in fact more of an academic than a practical one. So let me jump straight to what I see as the critical point—the relation between the various things we call both tools AND methods and what you propose calling “solutions.”

The real question here is what are you trying to get done with these things in the first place? What problem are you trying to improve?

Notice that I didn’t use the word “solve”. That’s because lean methods/tools ARE NOT solutions. Actually, the word “solution” does not exist in the lean vocabulary. Lean guys talk instead about countermeasures. The word “solution” implies that there’s a definitive answer to the problem that goes against both experience and the Kaizen spirit. And so we’d rather think in terms of temporary stopgap measures. Sure, the closer you can trace your countermeasure to the root cause of a problem, the more of a “solution” you will end up with. But it’s important to use the proper language: the word countermeasure reminds you and everyone else that no answer is either perfect or definitive.

This isn’t an idle point. Our minds grew while roaming the African veldt for quick certainty, not for open minded rigorous confirmation of hypotheses. However finding root cause countermeasures to complex problems requires careful observation and methodical hypothesis testing, which completely goes against the grain. So using the word “countermeasure” is a good reminder.

The lean methods/tools are not countermeasures either. The countermeasure is what comes out of using a method/tool rigorously.

Let’s go back to the Gemba for a second. A little while ago I was on the shop floor looking at a group of engineers dealing with a recalcitrant robot. Because of all sorts of problems, the robot was often down. The people there had responded by adding an operator making the part manually with a clever little jig to hold the part. The operator worked occasionally, when parts were missing to complete the batch, and the engineers were looking at quality. Now, the operator worked more slowly than the robot, but as the operation was mostly welding, he actually made better welds than the robot, because the operator could adapt his welding to the components he was given. A large part of the trouble with the robot was that the new supplier selected in the Far East by Purchasing kept sending non-standard components. The robot couldn’t cope with this and either stopped or made bad parts.

Then someone asked the unthinkable: why don’t we just use operators, and forget about the robot (the robot requires a full time operator as well to feed in the components). The answer was obvious. The operator was far too slow to achieve the required piece rate.

But hang on a second. Required by whom? When the group calculated the customer Takt Time they found that the operator worked well within Takt. The difference would be between one reliable operator per shift (three heads) as opposed to one operator feeding the robot for two shifts (two heads) overproducing and hence stockpiling an entire shift.

Only a genuine lean fanatic would argue that Takt has to be followed no matter what. The correct principle is flow when you can, pull when you can’t. In the case of capacity equipment such as presses that work much faster than Takt it often makes sense to batch. Yet in some cases, you’ll put the presses in flow with the rest of the cell because the cycle is close to the takt, and it puts pressure on the presses to work dependably. It depends. Takt Time is NOT A SOLUTION. It’s an ANALYSIS METHOD to see how you fare against an ideal world of regular customer demand and thus to have a different look at your costs management to offset the unit price calculation (three operators and no robot could be less costly than two operators plus one robot if you take into account all the additional costs of the robot, but the robot’s unit cost calculation will often be much lower).

Lean methods and tools spring out of applying scientific thinking to the shop floor. Astronomy is a method (calculating orbits, and, well, all that weird stuff about looking for the 93% dark matter in the cosmic radiation) and a telescope is a tool. Their purpose is to describe the universe more accurately so that we can take the correct decisions about living in it (although changing neighborhoods remains somewhat problematic). Lean methods and tools are about describing the reality of the shop floor in a way to reveal the true cost and the added cost due to waste. Nothing more, but still a big thing.

Consider lean as “a procedure or process for attaining an object”. The object of these particular procedures is NOT to resolve the problem, but to learn by:

  • Visualizing the process to reveal problems
  • Describing the problem more accurately
  • Seeking root cause by asking why and scratching one’s head
  • Studying countermeasures to see what works and what doesn’t.

Lean is a system inasmuch as these various methods/tools are interrelated and comprise a full way of analyzing business. Please don’t conclude “Ah, it’s a philosophy!” however. That’s where sensei Bob Woods from The Gold Mine will roll his eyes and snap that it’s a practice. Indeed, the point of lean is that you get better and better at your job by practicing the tools in real life as part of your work, every day. And you get better at developing mutual trust when you practice the same tools with others. As a result, when all people practice the lean tools all the time together, they come up with smarter processes, and answers they had not thought of before – creating sustainable results. As Taiichi Ohno once instructed my father’s sensei: “Don't look with your eyes, look with your feet. Don't think with you head, think with your hands.”

Challenge! Open mind! It’s not too late to change your mind. Rather than thinking about your thesis in terms of a lean philosophy applied through its tools, change your perspective, angle of view, frame, and look at it as a practice acquired by using the tools repeatedly through which one develops one’s own autonomy in problem solving and vision or where to go next – and eventually, after just a few decades, one’s own deeper understanding of the short word “lean.”

Performance versus costs, part 2

July 22, 2011
Back to top

Dear Gemba Coach,

I’ve read your recent column on performance versus cost with great interest, as I believe we’re currently having a similar discussion at management level. Would you clarify further the difference you see between performance management and cost cutting?

Certainly, but if you are having this debate at senior level, beware: there be dragons! A large part of the debate centers around deep-set ideas on the nature of industrial investment. What Adam Smith saw at the very birth of the industrial revolution was that if you (1) divide work into narrow tasks (2) you make astounding gains in individual productivity by rationalizing each task and (3) you can then make further gains by inventing machines to perform the task mechanically. As you go through these three steps, your cost per unit plummets spectacularly. I just saw a plant do just that separating full product assembly by one operators into separate operations according to takt time and just by dividing the work they doubled productivity, by rationalizing each step they gained forty percent further parts per person per hour, and they then mechanized one station and doubled productivity again (from 500 a shift to 1,000). The problem they hit, of course, is that the tak time being at one and a half minute (about 500 parts a shift), 1,000 component parts were double than they needed.

And ay, there’s the rub: how to resist investment envy. In the traditional cost-based vision, lowering unit cost has to be a good thing no matter what. On top of which, as a manager, investment gives you a real buzz: that’s a separates-man-from-boys decision, and it’s fun to spend big money in order to get big returns.

The demand markets of days long past would take whatever you produced. Traditional industrial thinking hinges on:

  1. Making a demand forecast
  2. Investing in equipment that can supply the demand at the lowest unit cost
  3. And reduce direct personnel cost to a minimum (ignore engineering and logistics “overhead”)

Unfortunately, although we prefer to deal with the world as it should be rather than as it is, sometimes reality intrudes. If actual demand is lower than forecast demand, or if the mix is different from expectations, although the unit cost of producing one part is low, the total budget level results are not any better: you can make but you can’t ship, so you can’t charge. Furthermore, running at maximum local efficiency will create a lot extra activities in terms of warehousing and scheduling - in lean terms, waste – that will show up on the bottom-line but never be allocated to the machine that is overproducing.

Since some fairly senior necks hang on proving the ROI to justify the investment, operational rats are usually told to 1) run the kit “efficiently” (ie at full speed) to keep the unit cost down and 2) do what they can to control costs all around. There are two obvious ways operational guys can do this:

  1. Created demand: the capacity investment can be kept running at full speed by rearranging real customer orders in order to bunch orders that go the machine (and avoid the production losses due to change overs) and reschedule all over work accordingly.
  2. Tighter spending control: certain discretionary costs such as temporary work, training, external maintenance or parts, travel and so on are relatively easy to control because someone has to sign off the authorization – it’s easy to say: make without.

Does this work? Not really. The genius of the lean management model is to start with the Gemba and, as Jim Womack says in his new book, make it a better place where we can create more value with less waste, variation and overburden [Gemba walks]. The first step in lean industrial thinking is to recognize that mura and muri generate muda:

  • mura, unnecessary unevenness in work scheduling means that, in order to deliver, the system is dimensioned for the peak demand and sub-optimized at every other time. Since demand is now created demand to keep the investment running at the original forecast assumptions, the entire production system suffers from stop-and-go and is therefore overall oversized but ineffective.
  • muri, overburden on people and equipment. Bt tightly controlling spending, many necessary activities fall by the wayside. A classic example is refusing to hire temporary workers to compensate for absenteeism. As a result remaining personnel are overburdened and perform poorly which affects the system as a whole. Or denying the purchasing manager a plane ticket for China to check a supplier, which might generate serious costs in short suppliers and poor quality parts (which both need to be dealt with at real costs).
  • muda, waste, is the mechanical consequence of mura (bunching orders and rescheduling) and muri (overburdening people and equipment). The most obvious muda is caused by overproduction, having to manhandle, store, count, reroute the parts we produce without an immediate use for them in order to maintain the unit cost down. But there are many other instances of waste due to the fact that people don’t work regularly in a created-demand driven and overburdened production system: poor quality parts due to lack of training, absenteeism due to lack of responsibility, production losses due to machines being used haphazardly and often unavailable. As lean practitioners all know, there is no end to muda and, more to the point we often create our own misery.

From an industrial perspective, takt time is one of the most powerful lean concepts. In order to optimize the system’s performance as a whole, the idea is to aim all efforts not at optimizing unit cost but at keeping takt time. takt time is an average of customer demand over a period. The period depends of the facility’s flexibility. A Toyota car plant, for instance, will find it challenging to change takt time every couple of months, but Toyota’s engine plant aims to change takt time weekly. The idea here is to keep a stable volume as far as possible in line with real customer demand, and be as flexible on mix as we can.

With takt time as the production’s system central objective, all functions can work together towards this objective, and management’s problem then becomes to solve the issues stopping us from achieving takt time. Do we replace absent operators with temps? Yes, but we then investigate the causes absenteeism and try to solve them. Do we pay for needed spare parts? Absolutely, but we work on maintaining critical parts so that we don’t have to change them that often.

Does it mean that lean thinkers ignore all consumables expenses? Not at all. I recently visited a Toyota engine plant and one of the many charts on the management visual board was a tracking of consumables costs on the line. One of the other visitors pointed out that the paper was not up to date: actually it was posted but without any annotations. The tour guide pointed out that on this line, they were still focusing on the essentials:

  • Their percentage of takt time achievement
  • Quality issues on the line

Both of these papers were rigorously filled in. They agreed they should be tracking consumables spending as well, and doing kaizen on it, as well as other indicators such as RH training and so on. They knew they had problems on this segment of the line, so management priority was clear: first achieve takt and solve quality issues, and then move on to kaizen on consumables costs.

To summarize, I believe these are widely differing industrial paradigms. As I understand it, traditional thinking is about:

  1. Break the bank on a huge investment (buy a plant, a new state-of-the-art, high-speed, multi-purpose machine, etc.)
  2. Which needs to pay back, but has unexpected cost side-effects
  3. So narrowly control spending
  4. By specific cost reduction projects
  5. In order to achieve the double constraint of reaching bottom line objectives while keeping unit costs down.

Whereas lean thinking works completely the other way around:

  1. Focus on overall performance by making and good products at takt time
  2. By avoiding mura and muri in your management decisions
  3. And spending what you must in order to achieve quality and JIT
  4. But measure carefully costs in terms of budget and extra spending and investigate thoroughly any expense above budget to understand root cause
  5. To kaizen away the causes for extra spending
  6. And, in doing so rethink completely what kind of investments you need.

Toyota is still leading the way on such deep lean thinking. Buffered by disaster after disaster from the financial crisis to the recall crisis and then the tsunami and nuclear crisis, the company has not lost track of its fundamentals. "60 percent of the cost of the car is the investment into the plant. 20 percent is the parts that go in the car," says Toyota's Executive Vice President Atsushi Niimi. In it’s newest Ohira plant in Japan, Toyota aims to reduce its capital expenditure by 40% according to what is reported. “Manufacturing accounts for 20%-30% of total vehicle cost, with facility investment representing around half of that amount,” Nimii is quoted saying “This means that (a 40% reduction in facility investment) results in a 15% lower per-vehicle cost.” (Roger Schreffler WardsAuto.com, Mar 8, 2011).

How about that for cost control, don’t you think?

Problems First and Positive Thinking

July 12, 2011
Back to top

Dear Gemba Coach,

Isn’t always focusing on problems discouraging? My people feel that they’d like to be recognized for their successes and resent the negativity of looking at the half-empty glass. Is there a positive way of doing lean?

“Problems first” is indeed the cornerstone of a lean culture. Lean is about achieving objectives THROUGH developing people. The lean method to develop people is to (1) help them develop autonomy in problem solving and (2) help them develop their own clear vision of where to take their areas of responsibility. Focusing on problems and hearing adverse information without blaming the messenger are the foundational attitudes of lean thinking: no ifs, no buts.

And there is a deeper reason for it. Our brains have evolved while roaming the African savanna and are designed to reach conclusions quickly: mistake rustling leaves for a sabre-tooth tiger and you get a good scare and an unnecessary run, but pause to confirm whether it is really a sabre-tooth tiger and you get eaten – and the “confirm impression before you act” genes are out of the gene pool. Similarly, we often follow leaders for their self-confidence and decisiveness, unfortunately not necessarily their ability to get it right. In a modern hyper-complex world, where cause and effect and subtle and impacts long-term, flourishing is about being right rather than being quick – even if it takes a little longer. The key to lean thinking is the scientific method: making the effort to confirm before committing to a course of action. Hence looking at problems.

Is this negative? Sure, back at the Gemba, it can be perceived as such. I can think of one industrial company I know where every time I see them it’s all about problems, problems, problems: they can’t ever seem to get right what they attempt to do, and something else always happens (supplier goes bust, new product has issues, bottleneck machine goes down, people are upset). But over the years, they have set up a pull system, worked hard on improving quality and transformed workstations with their operators and, well, their performance has improved significantly (which justifies selling their products at premium price). There is a disconnect because problems are what they experience every day, and performance improvement creeps up at monthly or quarterly timeframe. Nothing fails like success, however, so they get so good that they get sold by their corporate owner for an outrageous amount. The new owners move in, fire the CEO, and, as per usual, integrate the company by imposing their own procedures, their own lean program and so on.

“Damn, we used to have fun!” complained the purchasing manager last time I saw them. The comment surprised me because I felt that previously they were struggling and constantly finding things difficult – over years. Fun? That was a new notion. But they all agreed. They used to have fun doing lean. Now they were back five years down the path to cost cutting and arbitrary corporate rules and it was definitely not fun anymore – although no one challenged them on their problems. In this new environment, they were back to “shoot the messenger” and were re-learning to toe the line and keep their noses clean. So what was fun with “Problems First”?

Challenge

I asked them about it, and they felt they were trying to do fun things. And it’s true we did laugh about it. A trivial example was the challenge to keep the backyard absolutely free of anything – empty. Every time, something showed up. Mostly, it was the result of reducing inventory, closing warehouses, improving supplier delivery and so on. Every one of these challenges created new problems. Nothing ever worked right first time, and problems cropped up all over. But these problems were the result of actively trying to move the company forward by taking on a new challenge. These were not passive problems, but the expected outcomes of taking a step further. The new management cost control rules restricted most of the experiments they were attempting and took away both challenge and performance improvement. Problems were still there (something always happens), but it wasn’t fun anymore.

Challenge is one of the core lean management themes, along with teamwork, and open mind, expressed by Pascal Dennis is his great lean novel Andy and Me. 

Open Mind

Lean focuses on problems because (1) you set yourself a target, say an hourly production objective according to (2) a process you try to run and 3) you look at problems to better understand your process. As John Shook explains in his latest e-letter: what are you trying to achieve? Why can’t you? Production losses every hour will show what is wrong with the existing process, and how to improve it. Looking at problems is not self-punishment or wringing of hands, it’s in fact cultivating an open mind. Furthermore, particularly in industrial, problems WILL happen whether you want to or not. Suppliers will do weird things. Machines will go down. People will stay home with the flu or be in a bad mood, or come up with … who knows what? So accepting that problems will occur actually makes you feel better. I have now accepted that taking a train in France WILL mean at least a 15-minute delay for every trip. This is not fate, and this is not about keeping me from reaching my appointment on time. It’s simply a reflection of the capability of the train company. So rather than fuming every time I’m stuck on the track somewhere, I think to myself: “Ah, here are five minutes gone. I wonder when the next ten minutes will occur.” Strangely, accepting that problems WILL occur and that problems are an INTERESTING reflection of the process develops equanimity, open mind, and yes, a form of positivity. Looking at problems encourages developing an open mind because we’re forced to admit that reality doesn’t tolerate our best ideas so well, and that problems demonstrate that we need to understand more fully what really happens – and accept often that others where right from the start, even though their conclusions can be disputed.

Teamwork

As the discussion about “we used to have fun” continued, they also realized they no longer worked together as they used to. They still got on fine individually, but no longer had the team problem solving sessions where production, purchasing, procurement, logistics, and quality actually put their heads together to solve their challenges. They missed both the comradeship of being at the front together and the seeing the BIG PICTURE as they exchanged each others’ perspectives on the business.

As I listened to them, I realized they missed their CEO. He’d never been a very operational guy and his interest at the Gemba had been limited to visiting the kaizen workshops and discussing with the operators – his vision was that of a learning organization. By and large he let his directors get on with their work and didn’t involve himself much in operational decisions. On the other hand, he’d been brilliant at seeing clearly the wider challenges, bringing an unstinting positive attitude to the business (if we work together we’ll solve every problem). Not being focused on nitty-gritty, he was never in a rush to get things done, but he encouraged a permanent spirit of open discussion and teamwork. He’d also made a point of sharing the rewards of improvement and had instigated an extensive program of profit sharing. Far from the caveman leadership of “follow me because I’m right or die,” this CEO was a leader because everyone in the company felt that things got better precisely because they were tackling their problems and taking the time to do it right, even thought that meant quite a bit of trial and error.

At the Gemba, whether people perceive “problems first” as negative or positive is a question of leadership. If there is no genuine attempt from the top at solving greater challenges, if nothing ever gets better, if people feel they’ll be blamed for whistleblowing, surely getting them to focus on problems will be seen as negative. But if they can see performance improve steadily, they personally benefit from it, and it is accepted that THERE WILL BE PROBLEMS and NO ONE WILL BE BLAMED, but that EVERY PROBLEM IS INTERESTING, then problems first can instead become a source of positive feelings at the workplace. It develops the self-confidence that challenges can be taken up and problems resolved autonomously (rather than wait for city hall to fix everything). It develops the open mind to see that when things don’t work out the way they want to because of technical specific reasons, not because others are incompetents out to get you. And finally, it develops the great feeling of working as a team and seeing how we connect to each other’s jobs and how our own technical decisions create issues in our colleagues’ work, and how to solve that.

In the end, I can only answer your question by another question: what kind of a leader do you want to be? A true test of lean leadership is when people start feeling positive about highlighting problems and tackling them with their colleagues, looking for innovative solutions to today’s problems. But this attitude, certainly, will not happen in a vacuum and needs to be led from the top on the Gemba, every day.

Performance Versus Cost

July 5, 2011
Back to top

Dear Gemba Coach

I am the continuous improvement director of a large hospital. We invested two years ago in a central machine to perform all the blood tests.  Unfortunately, we have many technical issues with the equipment and we don’t know how to get the manufacturer to solve the problems. The wards complain about our lack of responsiveness as well, and I don’t know where to start. What would you suggest?

Ouch – It sounds like you’re stuck, and I’m not sure I’ve got anything helpful to say. You’re experiencing a problem common in industry: concentration of means makes accounting sense in terms of cost per unit, but not necessarily overall performance sense it terms of delivering at the lowest real cost. Complex centralized equipment has three generic problems which I’ve never seen resolved satisfactorily:

  1. Service: by centralizing one operation, you create a “monument”: all flows now have to pass through this massive toll gate. It’s like creating a central border crossing checkpoint where all roads have to converge. Not surprisingly, this creates long queues. On top of which the monument is rarely flexible so it will batch work. Which means that one specific test from one specific ward might be stuck far in the queue and wait a long time.
  2. Cost: although cost by unit is clearly lower, the cost of use of the machine is generally higher than expected. Complex equipment has complex breakdowns, and requires sophisticated problem solving done by top dollar engineers. To evaluate the cost performance of a centralized investment, one needs to include all the exceptional babysitting costs of keeping the machine up and running. If you’ve got to fly engineers in from Frankfurt to check the software, you might be in for a pretty penny.
  3. Quality: on average the quality performance of a central machine tends to be better than of multiple spread-out operations – and yet, it’s also stable. What this means is that with smaller delocalized operations one can hope to improve quality if we try, as it’s often a case of training and attention. With the machine, however, the quality parameters tend to be mysterious, even to the machine manufacturer. Understanding how to go beyond 90% quality with a large complex equipment means doing serious capability analysis that often requires technical skills beyond what we currently have: although we know how to improve blood analyses (it’s what we do), we rarely know how to improve the automation of blood analyses (what the machine does).

Balancing Act

I’m not arguing against concentration of means – this is still a sensible thing to do in many cases. I’m ranting about the over-enthusiastic investment in such solutions (senior execs love nothing more than signing big checks on big toys). In practice, large concentrated investments get the job done in conditions of massive overcapacity – to cover up for the previous issues, which also means we’ve spent more money upfront than necessary.

This might sound very theoretical and far from your Gemba problem now that we’ve got the machine, but please bear with me. This is an issue you’re going to have to master fully because the few countermeasures I know of will be unpalatable to management as they will seem to add more cost to an investment that already broke the bank. Before you go charging in about fixing the problem, you need to frame the debate in the right way to have a chance of winning the upcoming political battle (no executive takes kindly to be shown he’s made a bad mistake and has egg all over his face).

The common frame of thinking for industrial decisions is cost. The reasoning is simple – simplistic in fact – control and reduce cost per unit, and so improve your profitability. “Figures are figures,” they say, so sign with the supplier proposing the lowest price and pocket the difference. The trouble is that we also need to perform for customers. If the lowest price supplier has quality issues, this will appear in our processes and products – as extra costs. We need to organize entry quality checking (cost!), we need to rework the bad parts we make because of their components (cost!) we need to check our own products more carefully in case a part has gone through (cost!), doing all of this distracts us from producing as planned (cost!), and if we don’t do any of this, our customers will walk away and we lose sales. Although accountants have ROI calculations to evaluate an investment, they seldom know how to discount the R in terms of the real costs incurred in making good products with so-so components. Still, most managers hold on to the magical belief that if you systematically go for cheaper you’ll get better. And that’s just with quality. If the supplier has delivery issues as well, double the cost.

Lean has taught us that cost management (as opposed to cost killing) requires a better understanding of performance. Performance is traditionally expressed in terms of quality, cost and delivery (lead-time), to which I’d add safety and morale, but for the sake of the bean counting argument, let’s stick with quality, cost and lead-time to start with. Performance is not as satisfying to accountants as just cost because it needs an element of human judgment (God forbid managers actually would have to know what they’re doing!). The overall estimate of performance cannot be estimated by a calculus, it has to be a personal estimate of the balance between quality performance, cost performance, and lead-time performance.

Frame the Debate

Toyota’s standard is to run its assembly plants in two shifts as opposed to the three shifts in most other OEMs. The downtime between the two shifts allows Toyota engineers to (1) work on the equipment to keep it in tip-top shape and (2) do overtime if necessary to stick to the sacred production plan. When Toyota’s French plant started operating in three shifts, all over the world, lean aficionados started rolling their eyes and hollering that Toyota was losing its way. That’s silly. Let’s face it, running a third shift radically reduces the cost per car – if we can perform as well with three shifts as with two. Toyota would have been daft not to try it. And, as expected, the French plant worked hard, became the most productive plant of the lot (no surprise), but never quite performed at Toyota standard. It never was a bad plant, but, the French engineers argued, the site was never designed for the volume of three shifts, so of course they had a bit more inventory and of course they had more frequent breakdowns and so on.

After ten years of running the French experiment (back to two shifts because of volume reductions), (1) Toyota has not generalized three shifts to its other facilities and (2) the French plant kept receiving visits from senior Japanese managers asking them: show me how this three shift system works. Convince me. The point of the story is that the overall estimate of performance between quality, cost, and lead-time is just that: an estimate, and as such subject to debate. The second point of the story is that it’s key for senior execs to have this debate constantly amongst themselves because this is precisely how they’ll form a common vision of how to run the company profitably over the long term.

This is precisely the debate you must bring to your management boardroom if you want to have a chance of solving this problem. To transform others, first transform yourself and try to master the simple technique of evaluating decisions in terms of performance. This means sketching the following table at the back of an envelope:

Options

Quality

Cost

Lead-time

Total

Option 1

Good

Average

Poor

Improve lead-time

Option 2

Poor

Good

Average

No go

The point of this exercise is NOT to make the best decision – outcomes are, after all, uncertain, BUT to have a sensible way of discussing this uncertainty within the management committee without being fixated on cost only.

Back to your Gemba. You’re going to have to change the focus from the machine to the wards: what is the delivery contract you have with the wards? What do you have to do to honor it, no matter what?

You’ll probably find that not all blood test requests are the same. An emergency sample because the patient is in the operating theatre and, while running the pre-op checklist, the surgeon suddenly has a massive doubt, is not the same issue as a patience being monitored during the recovery phase. The first step is understanding customer usage and customer requirements, and stop trying to fit it all within the machine’s constraints.

Secondly, and this is not going to go down well if the machine costs a lot to purchase and maintain, you’re going to have to set up parallel operations to actually perform to contract. Usually this means handmade analysis of urgent requests. This might seem costly, but is necessary not just to fix your problem but to understand it better.

Looking at performance will lead-you to distinguish cases and progressively to learn how to better balance machine use and human use. As you take away all the extreme cases from the machine’s workload, you will also be able to narrow down the machine issues to fewer, more machine specific problems, which can now be focused on and resolved.

To answer your question directly, first specify your performance contracts with your customers in order to understand better their real demands. One usually finds that an “average” performance measure does nothing for customers as they have different expectations in different cases, which is precisely what we need to understand. Second, forget the cost fixation for a second and put in the local means necessary to fulfill customer contracts. Third, optimize the overall resource to reduce the need for the extra costs, by focusing on the real problems, which you have now broken down in manageable chunks.  I realize my answer might not help your right there and then, because once the investment has been paid for in full, most deciders are busy justifying the investment rather than solving the problem. But having misplaced my magic wand, I don’t know how else to go about it. Good luck!

How Often Should We Change Takt Time?

June 3, 2011
Back to top
Untitled Document

Dear Gemba Coach,

How often should we change takt time?

Deep question. The answer is: I don't know; it depends! Let's make sure we're on the same page on what takt time is. takt time is commonly defined as daily work time divided by daily customer demand. The idea is to figure out how much time we have to make a part while sticking to customer demand, neither overproducing (and generating the associated waste) nor being late on schedule. Rather than focusing on optimizing the output of every process by looking at parts per minute, takt is a great device to flow by getting every segment of the process running at the same rhythm.

takt time has to be one of the most profound ideas in lean. Not only is it a key driver for kaizen by pushing you to achieve takt with the least resources and the least problems possible (it's impossible to keep the takt if the line has rework or breakdowns), takt time thinking has a huge impact on how you design where you invest your resources. Recently I visited a Post Office operation where mail is sorted for distribution. They had made a ginormous investment in space and machine that only worked at peak for two hours a day (sorry, a night) - and still no better than 3% errors and 15% non on-time-deliver (OTD). takt time thinking would have led to smaller, more flexible investments, which are easier to control. Similarly, takt time thinking can influence engineering, tooling, supply chain, and all aspects of industrial production. Understanding takt time is key to lean thinking.

Nevertheless, takt is a slippery concept. First, what exactly is daily work time? Should we count breaks? Breakdowns? Changeovers? What about banking holidays? And what about daily customer demand? It changes all the time - should we change takt time every day? Isn’t just-in-time about fulfilling exactly customer demand? But what of the impact on production if we do?

What Is the Problem?
The deeper question, as ever in lean is: what is the problem you're trying to solve? takt time is at the heart of the lean industrial model. The idea is to produce with the minimal resources by maintaining a stable volume, while working at high flexibility. The core assumption - generally proved right - is that although customers change their mind about which model they chose, the global volume of demand is fairly stable. First, because volume corresponds to a consumption process, which is essentially a renewal process at the customer, and hence stable. Second, because the law of high numbers applies and thus, relative variation on the overall volume is much smaller than on any of the component parts. takt time thus quantifies the stability of overall volume. Within this, however, we should be able to make any part any time to fulfill specific demand.

The lean industrial model is less wasteful because it manages the inherent contradiction of takt time-based volume stability and spot demand based mix flexibility. In this sense, the first problem we’re trying to solve is to stabilize the overall volume and thus keep takt time as fixed as possible. But what about real customer demand variations? What about financial panics? What about recall crises? What about earthquakes and component rupture? Well, there are a number of ways to flex output without changing takt time:

  • Inventory: the assumption is that if customer volume variation is repetitive, we can stick with takt because what customers are not buying today, they’ll purchase tomorrow and vice versa.
  • Short work days or overtime: it makes accountants hysterical, but you cannot work one day, and train operators or kaizen, just as you can use a week-end shift.
  • Adding or subtracting shifts: this is not something you can do lightly, but it is a possibility.

The core idea is that as demand for new models increase, we should be ample to ramp up the new model while diminishing the old and maintain a stable takt time. Now, this is clearly an ideal that assumes, in particular, that both the old model and the new one can be manufactured on the same line. But it’s one of the insights that make lean so capital free compared to traditional manufacturing which keeps on adding dedicated equipment and facilities for every new project.

takt time Paradox
Yet, there are cases where you deliberately want to change takt time. I was recently visiting a Toyota plant that had to go through the financial crisis, the recall crisis and finally the earthquake crisis. In the first year of the financial crisis, the plant maintained its takt time and reduced production by using short work. But then, a new plant manager arrived from Japan, steeped in TPS practice, who decided the plant was weak in its ability to train employees and conduct kaizen. He then imposed three or four takt time changes within a year. Historically, it took the plant about a month to absorb a takt time change, whereas the standard for a Japanese Toyota plant would be around a week. The problem the new president was trying to solve was to adapt to demand by learning to change.

takt time change is a huge endeavor inasmuch as every operator station has to be rebalanced at takt time. takt time change has also a huge impact on suppliers since parts may be pulled at a slower or faster rhythm. In this case, this meant retraining all the operators of the line and rebalancing all workstations. The first takt time change was quite traumatic, with many quality problems compensated with inspections, with ergonomics issues and so on. But the plant management worked with group leaders, team leaders and members to finally learn to deal with the changes. And so the fourth takt shift occurred without a hitch.

Should we change takt time? This is a core lean question, and a paradox. On the one hand we want to avoid changing takt as much as we can to stabilize the line. For instance, the same plant, when dealing with parts shortages, rather than consume all it had and then stop, preferred to schedule set stoppages to level the impact on its supply base. No takt change would be considered to deal with these conditions. On the other hand, takt is essential to sticking to customer demand, and to adjusting finely the resources on the lines - so takt has to be changed every so often to spur kaizen.

There is no straight answer to your question other than "why?" And then probably, "why?" again. Why do you need to change the takt? What are you trying to achieve? So much of lean is about developing a deeper understanding of capacity, these are critical questions to ask ourselves, so I’d encourage you to keep digging: this is absolutely the right question even though answers are far from obvious. Let me rephrase: what is the problem we’re trying to solve by changing takt time? What benefits do we expect? What issues will we encounter? How will we run the changes with the operators, not against them?

Standards vs. Standardization

May 25, 2011
Back to top

Dear Gemba Coach,

We’re often told that “there can be no kaizen without standards.” But when do you start when there are no standards? How do you standardize? And how about “just do it” kaizen?

This is an intriguing question, thank you. I’d say that the first point to clarify is that having standards doesn’t mean standardizing: it is NOT about everyone doing the same thing everywhere. In other words standards and standardizing are two different concepts and it’s easy to see how one can be mistaken for the other. Yet, where standards are key to lean thinking, misinterpreting “there can be no kaizen without standards” by saying “lean is about standardizing everything” is common – and self-defeating.

Obsession with standardization-as-uniformization is a reflection of modern management’s deployment mindset. In a Taylorist world, “best practice” must be replicated everywhere quickly in order to improve the organization as a whole. This mindset makes several assumptions—that (1) local context is the same everywhere and (2) it won’t ever change. Yet clearly, renting cars at the Aix-En-Provence office is not the same thing as renting cars in the Cincinnati downtown agency, and, for that matter the Aix-En-Provence high-speed train station has different issues than the Aix-En-Provence downtown desk: context is local. Sure, the paperwork is the same, but customer usage and requirements will differ significantly. All customers assume that you can provide them with a car and get them to sign the contract. Their satisfaction (or, more likely, dissatisfaction) rests in the specifics.

Lean reflects scientific thinking applied to business situations. Lean thinking is about exploration rather than deployment. The lean question is how to provide muda-free service in context, and in changing situations. Sure there are standards, but these are not one size fits all apply in all cases “standards.” We’re looking for something else.

Empirical Thinking

Taiichi Ohno’s core intuition was that our thinking generates a layer of waste on top of the unavoidable cost of doing anything. For instance, the idea that we can overload a machine without maintenance (demand is such that we run weekends and don’t have any time to stop the machine) generates the waste of having a breakdown with all of its consequences. The idea that we can build up a huge stock of products in advance, in order to reduce the cost of changing production, generates the extra cost of carrying unneeded inventory, while falling short of the parts we need right now. Finally, the idea that we need to optimize the efficiency of the process out of its context generates many useless activities such as walking, checking, correcting, moving and so on.

Lean thinking is essentially an empirical method to discover this extra layer of cost we add on to our operations because of our wrong-headed ideas (what Ohno called our misconceptions). To discover this layer of waste, we practice kaizen: in trying to improve performance, we will hit upon waste in the process, it’s unavoidable. But what about standards?

Lean practitioners have been exploring how the wrong method generates waste for over half a century now so, like in any scientific field, ideas can be classed as:

  1. Things you know: this is certain, it’s verified every time and don’t bother looking for an alternative, there isn’t one. Such certainty is rare, but it exists: one piece flow is more effective than batching (every time you try, it works), not passing on bad parts to the next process is the way to guarantee quality at the customer (every time you try it, it works), operators have lots to say about their work and are more engaged when they’ve improved their own workstation (every time you try it, it works). These are, well, standards. We don’t accept them because we have to. We accept them because evidence shows that they’re always correct.
  2. Things you think: far more common, in many situations, we think we know, but if we’re honest, we’re not that sure. We know in some context, but maybe not in this one. The only way to figure it out is to try and kaizen, not so much to improve per se, but to know more. The main difference in lean thinking is that true lean experts know how to distinguish what they think (most cases) from what they know (rare instances).
  3. Things where you haven’t got a clue: most situations, most cases. Knowledge is horribly domain specific and knowing something in one case doesn’t make it true (in fit-to-fact fashion) in another, so careful exploration is warranted.

In this sense, “start with standards” means start with what you know. Then improve it (kaizen) to see how well you do know it in context. What this means is that when a standard exists, start by applying the standard. This is particularly true in engineering. There’s always a clever guy who figures out how to save a couple of dimes by not following the standard. But the standard is there because many equally clever guys had a lot of experience with this in the past. In shaving some cost by not following the standard, you’re very likely to unwittingly generate the muda the standard is about. So do yourself a favor: start with the standard. Look for cost saving ideas where there is no clear standard.

There are far fewer standards than situations. When in doubt, start with the standard where you have one, and apply your creativity to all other situations where the standard is unclear or inexistent. Standards are rare peaks of certainty on a few islands of “we think it’s this way but we’re not absolutely sure” in oceans of “we don’t have a clue.” So don’t start by challenging standards – there’s plenty more fruitful to explore.

kaizen’s Role

What Toyota has routinized (or standardized?) is a method to seek out this knowledge in varying situations and contexts. The routines are rarely about applying a “way-to-do-this” in itself (except for the cases where there is a clear standard), which is silly since things change from context to context and time to time, but an unchanging routine about how to find out what is what – with varying degrees of complexity:

  • 5S: by practicing organization, neatness, cleanliness, routine-izing cleanup activities and keeping that discipline, you will discover how things change over time and how to keep the environment in effective conditions;
  • 4M: by analyzing the Manpower, Machine, Materials, Methods issues to explain problems, you will discover where and how standards are not respected and why?
  • A3: by following the QC story you’ll go into greater detail in technical manners and learn more about the specifics of the situation, and whether standards should be established or not;
  • 5 Why? By asking why five times you’ll explore the underlying conditions to events, beyond standards and surface problems
  • Hansei: by practicing reflection/review, you’ll question your own understanding of strategy, policies and politics in an ever changing business context.

A standard is the best known local method to work with the least muda. This is what we know in a given situation. Which means that (1) the same standard may not apply in the next cell, but it’s a good place to start and (2) the same standard may not apply next week because something has changed, but it’s a good place to start. The way to figure out whether the standard applies or not is kaizen.

In the end, I wouldn’t worry too much about it, and accept once and for all that standards and kaizen are just two sides of the same coin, like the back and the palm of your hand, one goes with the other. Standards are the right place to start kaizen, and kaizen is the right way to establish standards. In any situation, just ask:

  1. You’re doing kaizen? Fine idea, but have you started by finding out what the standard is and implementing it?
  2. You’re applying the standard? Fine idea, but when have you last kaizened this area?

To answer your specific question of where do you start when there is no notion of standard, I’d take a page from Isao Kato and Art Smalley’s great workbook on Toyota kaizen methods. Go to the process and draw up a simple form with three columns listing:

  • DETAILS of the current way of doing the job step-by-step
  • NOTES, reminders, tolerances, distance, time, etc.
  • IMPROVEMENT IDEAS: write them down, don’t trust to memory.

And see where that gets you. And yes, that’s a standard.

How Do I Change the Culture?

April 29, 2011
Back to top

Dear Gemba Coach,

I come from a company quite advanced in lean and I’ve joined a new firm as technical director. I’d like to apply lean concepts to the way we invest, but every one tells me I’d have to change the entire culture of the place, which I find daunting. Is that really the case? Any advice on culture change?

I think that it’s time to own up to a daily irony in my work. My background is in cognitive psychology and sociology of knowledge. This is how I got involved with studying the Toyota Production System (TPS) and its translations for the past 17 years. Now, when I’m at the Gemba, I argue with plant managers about how they use their people and their machinery, about why technical processes perform no better than that in uptime and quality, and more generally about their industrial vision. They respond that I should understand more about their company’s culture and how to get people to change, and to listen more to their specificities and unique history. The ironic beauty of it is that we keep exchanging our incompetences.

In general, I’m reluctant to discuss culture because I find that the less people know of a topic, the more their ideas are set and difficult to discuss (this is not surprising: the cognitive investment in knowing more of a topic to go beyond one’s prejudices is high for little initial payoff). Most managers tend to have very clear and simple ideas about culture, a topic I find as difficult as it is confusing. So, I usually skirt the issue and go back to discussing people, products and processes. Please bear with me as I break this personal rule, and try to answer more deeply your question about culture. You’re likely to be somewhat surprised by my position.

Culture is a slippery notion because it tends to be all-encompassing: everything is about culture. Typically, culture blends together values, beliefs, practices and artifacts. Culture can also be seen as norms and relationships. Culture is national, ethnic, professional, company-wide, you name it. Culture can also imply good taste in fine arts, or that you know your wines. Not only is culture a very vast word, each of its components is equally hard to define operationally: what are values? Or beliefs? Or norms? Not surprisingly, anything can be explained by “culture” in some shape or form.

And yet, for all its pervasiveness, it’s hard to pinpoint exactly the real influence of culture. Research and practice show that culture has less effect than:

  • Unique personalities
  • Strong leadership
  • Uniformity of practices
  • Specific technologies
  • Reactions to striking events

And, by and large, this other loosely defined concept that is “human nature” (talking apes with a bias for tools). Overall, the research shows that culture does have a statistically significant impact but only explains a small part of the variance – in any given situation, one of the other factors tends to overwhelmingly explain what happened. Oddly, for a sociologist (and I still see myself as such), I consider culture as an outcome variable, and look for inputs in terms of people, leadership, tools, investment, and events. Yes, the argument can be made that tolerance and reaction to these five factors is cultural, and I agree with that, but this line of thinking quickly becomes circular. So, before we get deeper in discussing culture proper I’d suggest you break down your problem in terms of:

  1. Who do you have to convince of what?
  2. Who has strong leadership and which way do they want to take the company?
  3. What are the basic investment cycles and practices in your company (e.g. do we design cells based on parts flow or do we purchase machines that we then put next to each other to build a cell)?
  4. What are the key technologies and how far from world class are you?
  5. What near past events and near future trends will affect your investments?

Now, let’s tackle culture. Most people define culture as a shared set of perceptions, beliefs, values, behaviors and artifacts within a specific group. (Full disclosure: I don’t, as I see culture as a set of theories, relationships and tools evolved by any social group, but for argument’s sake let’s take the usual definition).

Values are mostly expressed in terms of what is an acceptable goal and what is not, and what is an acceptable mean of reaching this goal. Yesterday evening I was visiting a large industrial center essentially built around one huge piece of equipment, with conveyors, and people organized willy-nilly around it. I pointed out that one lady had to repeatedly stand on her toes to grab a box of parts and then bend low to place it on a moving cart. The site managers smiled and quipped that they should have a policy to only hire men. Now, I can take a joke as well as the next guy, but this reflects a divergence of values. I value people’s health more than the concentration of capital, and I value access to work more than the ease of equipment design and use. This does not make me a better person, and holding these values doesn’t necessarily make me any better at putting them in practice, but we are talking about values in terms of goals and means.

Beliefs mostly express themselves in terms of causal relationships (if… then), and since most people are action oriented it shows up in how they go about doing things. For instance, early on this week, I visited a factory that is quite advanced in its kaizen practice, and that has hired a new plant manager from the automotive industry. One of the first things he did was to create visual boards in each workshop with a daily control of cost, quality, delivery, safety variances (these were tracked daily before, but the board became a central part of his management). Now, there is nothing wrong with this. However, he was puzzled when I pointed out that, as an operator, what I’d see every morning is my management team turning their collective backs on me in order to focus on a discussion around numbers. In effect, rather than bring quantified analysis at the machine level to teach operators to better understand their job and run the equipment, the new plant manager brought managing-by-numbers down to the shop floor. In this case, we’re seeing different beliefs about how to get results: (A) put pressure on managers to solve all problems to hit the numbers daily versus (B) work with operators at their workstations to learn with them how to improve the process and eliminate waste. There are starker examples of different beliefs (batch versus single-piece-flow, for instance), but this instance is interesting because it’s easy to confuse one with the other: both beliefs are similar yet very different. Furthermore, I am confident that we share the same values with the new plant manager: we agree on goals and means. We have different beliefs about how to get there, because we have a different mental model of what creates the outcomes (pressure on daily problem solving vs. relentlessly teaching kaizen).

Behavior is all about what behavior is acceptable or not – ranging from exemplary to offensive. For instance if we go back to yesterday’s Gemba visit my “problems first” behavior (pointing out problems) was felt to be aggressive and my attempts at doing this with humor were felt to be disparaging and disrespectful. On other gembas, where we have a strong working relationships, pointing out problems is expected (when I don’t, they wonder what’s wrong with me), and a kidding style is de rigueur to continue to reinforce relationships where we can tackle our deepest problems (usually, this means owning up to our own mistakes) and still not take it too seriously and remain good friends. The same behavior will be experienced as positive for the latter (we enjoy working together because we confront difficult challenges good-naturedly) and offensive to the former (arrogant and disrespectful). To follow our second case, the plant manager coming from the automotive industry I mentioned previously is perfectly charming, but has a way of expressing himself in strong clear terms on the issues he feels he has something to say (I’m not saying that he talks and doesn’t listen; he’s actually a good listener and does leave people room). The local culture however, is more about hemming and hawing, and finally coming up with an outrageous statement as an icebreaker until they start really discussing the topic in fits and starts. As a result, the new guy tends to interpret their reactions as agreement, whereas all they’re doing is bowing to the strength of the argument, but not necessarily in agreement. As he’s new, he doesn’t yet realize that the people with the established relationship then meet again without him, to reopen and address the issue in their “normal way”. Again, there is no right and wrong (the new guy’s communication style is definitely “better”), but accepted behavior and transgressive behavior.

Artifacts are the objects and tools a group of people use casually to go about their business. Back at the Gemba, the factory I just mentioned used to use one artifact to run all its scheduling: the MRP. As they progressed in lean, they started using Excel leveled production plans and pull system with kanbans for high runners. Then they set up a different system for to prepare advanced stock for promotions (with a specific location in the warehouse). They then realized they had to deal with some products where demand was infrequent, but in greater quantities than they could produce daily, so they invented another storage and scheduling system. They’re currently experimenting with yet another scheduling system to level seasonality of a range of their products; they still the MRP with the rest of items. Each of these scheduling systems is, in fact, scheduling artifacts. The newcomer will find dealing these artifacts difficult because he values integration (one integrated system is a good means to delivering to customers), he believes in virtuoso use of the MRP, and doesn’t have the knowledge and experience to master these different scheduling artifacts. Again, artifacts are not right or wrong they have purposes and uses. In lean the purpose of the artifact is often misunderstood, leading to very, very confused behavior.

Finally, and very oddly, all the above influence perception. When the manager of the large industrial site doesn’t see what I’m pointing at in terms of poor ergonomics, he doesn’t see and ignore me, he literally doesn’t see. Groups as a whole will agree on what they look at, and what they don’t. 5S, for instance, is a great tool to reveal what people look at and what they simply won’t see. In extreme cases, people might refuse to look because what they might see goes against their values, or dismiss what they see because it contradicts their beliefs, but perception is probably the easiest cultural factor to change, as it can easily be done by strong leadership. “Human nature” is such that the rest of the tribe will look in the same direction as its leader, so when the top dog starts looking at something, every one else will pay attention. Not surprisingly, John Shook and Mike Rother’s seminal Learning to See was a real breakthrough in the lean movement: it targeted perception of how value flows throughout the company (whereas Jim Womack and Dan Jones’s Lean Thinking was aimed at belief).

The fundamental issue with cultural explanations is that we expect that a culture is made of a shared set of consistent values, beliefs, behaviors, artifacts and perceptions. In practice, this is rarely the case. Culture tends to be a group level phenomenon (most people value, believe, behave, use, perceive in most cases) whereas at the Gemba we deal with what an individual values, believes, behaves, uses and perceives. In real life firstly there is not that much consistency between values and beliefs and behaviors and artifacts and perceptions and, secondly, there is not that much agreement either. Because our minds are pattern seeking generalization machines it’s easy to stereotype a “culture” at group level (it can even be measured quite precisely and robustly on given dimensions), but this is rarely predictive of what happens at individual level. As we were discussing, culture does have an impact on what happens, but the impact is relatively small.

“Strong” cultures are cultures where the alignment between these various aspects is high and the degree to which they are shared across the group also high. “Weak” cultures have inconsistent values, beliefs, behaviors, etc. and that are loosely shared amongst members of the group. However there is absolutely no evidence to suggest that strong cultures perform better than weak ones. Strong cultures have advantages in relationship building (people tend to communicate well and agree with each other) and in tool use (common goals, common practice), but they are equally prone to groupthink (collectively reaching the wrong conclusion in an uncertain situation) and inability to deal with changing circumstances. Strong cultures tend to promote peer pressure to conform and generate intolerance of difference, be it in body shape, personality, ideas or even tastes. Weak cultures can be unwieldy, but also far more open, creative and adaptive – which tends to be good for business.

Overall, culture is a great descriptive concept, but not a very operational change concept. Few books are as useful or influential as Jeff Liker’s work on the Toyota Way – a description of Toyota’s plan-do-check-act ( PDCA) culture. But attempting to transform your own organization by changing its culture from scratch is likely to deliver the results you hope. First, drawing actual culture and future culture is fraught with dangers and misunderstandings. Secondly, even if you do, the change impact will be moderate and hard to sustain. 

So how does one change a culture? Historically, the most reliable method remains strong leadership in the use of specific tools. The tools have to come with a cultural manual of (1) values – here are the goals, and here is how the tool is going to help us reach it, (2) beliefs – here is how the tool affects causal relationship between this and that, (3) behavior – in this specific situation, this is how we behave when people use the tool this or that way, (4) perception – this is what we look out for to see if the tool is behaving as we’d hoped to achieve our goals. Without this, tools in themselves rarely change the culture, as will testify all the people who’ve done single minute exchange of die (SMED) without specifying the goal of reducing batches and behaving consistently to increase changeovers, or those who’ve done 5S without specifying the goal of giving autonomy to teams to reduce variation in their operating cycles, and so on.

For what it’s worth, in your specific case, forget culture and focus on two practices:

  1.  Plan for engineers to regularly improve the performance of existing equipment in a “workshop” format (you have three days to improve output by 10%, or flexibility, or reliability, etc.)
  2. Set specific improvement goals for each new machine that is going to be installed (half the rejects, half the time to change, half the weigh, and so on), and make sure that real efforts are devoted to that goal

 Don’t feel you have to change the rest of the culture. If you focus on clear outcomes from clear practices and show strong leadership, the rest will follow. In order to achieve these goals, if you steer them right, your engineers will have to go to the Gemba and discuss with operators, they will have to think differently about the equipment, they will progressively be drawn in all the various tools of lean, from takt time to total productive maintenance (TPM). But you don’t have to tell them that. Set the direction, repeat the practice, and listen to them and help them out to deal with the ensuing difficulties and create strong relationships, and the culture change will come.

Why is Flow Easy, and Quality Hard?

March 4, 2011
Back to top

Dear Gemba Coach,

I’m the head of the lean program for an industrial company of 13,000 people worldwide. We’ve made tremendous progress increasing inventory turns, and now my CEO keeps asking me why quality is not progressing as fast. My lean team has become proficient at teaching flow but it's not gaining traction when it comes to quality issues. Do you have any recommendations?

The long and short of it is that flow is easy, quality is hard. Achieving flow is easier than improving quality because the lean methods apply more quickly, visibly, and in almost every Gemba you are looking at.  

To analyze a flow problem at the Gemba, you can start by wondering how to stabilize the volume demand over a period of time, and how to increase the mix flexibility by fraction and mix. Then evaluate the various ideas on how well they bring us closer to single-piece-flow at takt time. Once you’ve convinced people to (1) level the production plan, ( 2) hold all parts at the process that produced them and (3) increase changeovers by practicing SMED (leading up to the production operators handling changeovers themselves), then what can happen? It’s hard work, but you can see the gains with every step, and as you make progress the flow issues sort themselves out. I’m not saying flow is a piece of cake. You still need to deal with the usual amount of resistance and misunderstandings and a fair share of attempts that don’t pay off, but, basically, flow is similar in approach to PDCA: plan your next move, try it, check it out in terms of service and inventory, think about it and either adopt or adjust. Stay the course, and, as you’ve found out, results will come. And the groovy thing is that when results do come, they tend to be spectacular, and you get to be a hero. Not only is it nice to be right (first endorphin shot in the brain), but it’s double nice to be recognized for having doubled the inventory turns and liberated cash (second endorphin shot in the brain), so yippee, let’s do this again. 

Why Problems Reappear

Quality is different. Applying generic methods like six sigma or PDCA to specific quality problems tend to be hard and frustrating because the failure rate of the attempts to solve the problem is high. In fact, (and this is one of my father Freddy’s key messages in quality), just finding the right factor before jumping in and solving the problem is no walk in the park. When it comes to quality, most people shoot from the hip, looking for a quick fix or a process change. And so invariably the quality issues reappear. Frustrating work. Why the difference?

Serious quality experts—the guys you call in when there’s a customer fire—work differently, and you can spot the difference immediately. The expert will start by observing, by really observing what is going on. Then they try to relate this problem to others that they have seen, situations with this problem cropping up in similar processes. Say they observe a machine producing flawed parts. In essence they start from what they know (after so many cycles, the guiding rail on this type of machine gets out of alignment), and then look for clues of whether this is happening or not. At the same time they take note of everything else relevant, looking for important details that a non-expert might have missed (such as a bad smell from the coolant, prompting a check for bacterial contamination).

Experts don’t quite follow a mental A3 process. They don’t follow a tick-the-box methodology. They recognize a typical case, run it in their minds in the specific situation (like a quick mental simulation), come up with an on-the-spot solution which they then try out. Most often, it works. When it doesn’t they go back to figuring out a different “typical” case, and try again. Certainly, from a lean point of view the number of cycles is wasteful and we’d like to find a way to get experts to get to the heart of the matter quicker, but first we need to understand how they work under fire. When there are extraordinary situations calling for immediate action, experts do not outline multiple options and then decide between these options. What they do is closer to:

  • Observe the situation and look for specific cues
  •  Recognize a “typical” prototype case
  • Simulate it in this instance
  • Try it.

Which explains why quality is hard and flow is easy. Flow is about getting the right crates into the right trucks and the right products into the right crates: how hard can it be? Sure, some situations will be easier to deal with than others, but fundamentally the generic problems are the same whatever is being produced. Map the process, simplify the flow, reduce changeover time and something will happen; following the generic procedure is almost guaranteed to deliver visible improvements.

Messy

There is no generic procedure to help with quality problems. Quality problems tend to be unique to the part and the machine and problem “prototypes” are very narrowly linked to specific processes. To be good at solving quality problems requires a much greater catalogue of “problem prototypes” and their give-away clues. By nature, quality knowledge is local knowledge, or narrow process knowledge that is acquired by working for years with the same products, processes, and equipment, which is why corporate lean guys will find it hard to get into it.

If this is the case, then how does a method such as PDCA apply? This structured approach certainly applies. When the expert fails at his or her first attempt at recognizing the typical situation, for example, they start looking for another prototype. At this stage things get very messy, usually because the pressure is on and tempers are high. But that’s exactly when the power of PDCA kicks in. PDCA can be used not to recognize the prototype, but to organize and clarify how the expert moves from one prototype to the next, by being more formal about the “Check” and “Act” aspects of PDCA.

In effect, PDCA is essential in helping the expert grow their library of cases faster, and in a more structured manner. PDCA’s insistence on confirmation will push the expert into better mental testing of his or her prototypes before jumping to a solution. PDCA doesn’t help to solve the problem, so to speak. It’s of immense help in developing the knowledge to solve problems better. PDCA is also very helpful in getting the experts to communicate how they go about it, which is important when dealing with situations that involve many operational people. In this sense “P” is a unique opportunity to outline the prototypical case in mind, so that others can see it as well.

Unwieldy Andon

If quality knowledge is local knowledge, is there a lean tool to develop this faster? Certainly: Andon. The principle that everyone must “stop at defect” acts as a freeze frame device on processes that allow local process owners (operator, team leader, group leader, technical support) to develop their catalogue of cue-to-prototype cases. When a process is stopped as it has just created a defective, the process owners can inspect it for “point of cause” (what, exactly is making the wrong part right now) and which parameters are out of spec. This can be a hard and frustrating process as anyone who has worked on false positives in testing machines will attest.

Such “freeze frame” action is about the only chance to develop experience with creating prototypal cause-and-effect logical chains that eliminate the problem completely from the process. Without Andon, myths and legends about what makes process quality will continue to rule the day, and it will be hard to break the quality barrier of adding a 0 behind the comma in the ppm numbers.

But Andon is also a very unwieldy tool. A pull system can be implemented with one smart guy at logistics learning the master scheduler role and pushing the kanban and supermarket system onto Gemba supervisors. Andon is tougher: it requires a full social structure in which people react quickly to problems in the correct way. Teaching local management to use Andon is much harder than getting them to use a pull system (whether they like it or not).

So, quality is a much harder nut to crack than flow because (1) unlike flow most quality knowledge is very local and specific (to a product, a process, an equipment, a site’s conditions), meaning quality experts will tend to be either very narrow process experts or local people who have learned to work with local conditions. Or (2) the lean tool to spur the development of local quality knowledge is much harder to implement than flow: Andon requires full understanding and cooperation of the entire management chain, from the team leader to the site manager.

I don’t have any easy recommendations other than to get your lean experts to start by identifying the right quality expert when they want to run a quality–type action. Ideally, we should be able to do specific quality focused kaizen workshops by process to teach local people to better know their products and use their equipment. This would mean that the quality expert uses the PDCA structure of the workshop to pass on some of his or her knowledge to the Gemba. Again, this might not be so easy, so the obvious first step when your lean guys are tackling quality problems is to recognize which process is at fault (even that is rarely easy), find the most knowledgeable guy in the organization about this process and invite them to the workshop, making a big point of listening to them carefully.

Your lean team probably avoids real quality issues because once bitten, twice shy; they must come to realize that while they need to confront quality problems (which are directly linked to customer satisfaction), a generalist approach will not solve quality concerns, ever. In fact, this is an excellent teamwork exercise for the lean team: learning to solve problems across functional boundaries.

Are You Pulling?

February 25, 2011
Back to top

Dear Gemba Coach,

We’ve made a substantial effort in training all our operators to standardized work (SW)by deploying  Training Within Industry(TWI) principles across all our sites. While we’ve had some good results, the level of discipline on SW is disappointing, and many cells are producing well below target cycle time. Do you have any pointers for us?

Are you pulling? Sorry to be so blunt, but that’s the first question that comes to mind. I believe it could be the true source of your problems. Your situation calls to mind a plant that I visited several years ago. They were making a similar effort with standardized work. They had hired a standardized work expert from the automotive industry. He was good, and could really see the work. He had developed a basic course for supervisors, who were asked to train all their operators and so forth. When we visited the Gemba, you could see immediately that it wasn’t working properly. There were cells standing idle without operators—there were many processes in which one operator would handle one or two operations with semi-automatic machines, package the part, and ready it for shipping to customers. On other cells, the gap between the objective and the operator’s cycle was so obvious that even I could see it. The plant manager launched into an embarrassed explanation about them not taking temps into account well enough in their SW training system, but they had a deeper problem.

The key to this problem was knowing what to look for. One thing I’ve learned the hard way by visiting Toyota plants – by being caught wrong–footed again and again – is to look at the situation from the operator’s perspective. So I asked the ops director to stand in one of the stopped cells and tell me what he saw. From inside the cell, he immediately described a number of ergonomic problems: poor lighting, tools were hard to access, components that were not at hand, and so on. They also had a big debate because the standardized work sheet was nowhere to be seen. But they were missing the main thing.

“When you’ve finished the part,” I asked the ops director. “What do you do with it?” He shrugged and mimed finishing the part and placing it at the proper place in a half-full tray of other similar parts, stacked chest-high on a pallet on the side of the cell. “As you do this,” I continued, “Are you ahead or are you late?” Late, they answered: the production analysis board on the side of the cell showed that the operator was systematically behind on the objectives, with (as usual) no comments written. “Are you sure?” I insisted, “maybe the objective is too high?”

Not possible, they answered. Objectives had been calculated as part of the standardized work initiative, and target cycle time was achievable if the operator just followed the standardized work. The 20% to 30% lag on the objective was explained by a failure to follow the standardized work cycle.

The Customer Connection

People only see what they’re looking for, so I kept trying. “What happens to this pallet when it’s complete?” I asked. They looked at me as if I was stupid (I often get that “you don’t know anything about how a real factory works” look), and told me that the operator called for a forklift to pick up the pallet and take it to the supermarket at the end of a row of cells.

The interesting thing in this case is that they’d done their homework: they thought they were pulling. Their lean specialist had done a value-stream map (VSM) analysis of their process, and, at the end of a block of five or six cells, they’d created a “supermarket” where pallets of different products were ordered by product type in FIFO lanes and where another forklift came every hour or so to pull one and bring it to the shipping area. They’d centralized the pallets in the supermarket so that quality could handle the statistical control of the parts, and they’d been clever about it: the pallet would be blocked only if a bad part was found.

But for the operator, this “pull” never materialized. If they had gone into enough detail on the VSM visualizing the transport between the cells and the “supermarket” they might have realized the problem. The operator did not feel any tension to follow a steady rhythm since he or she dug a pit in the sand, through the sand into a wheelbarrow, which would be taken away when full – eventually. The key principle here was that operators had no connection with their customers.

“Imagine,” I suggested. “That rather than a supermarket, you create a shop stock here in the cell, from which you come to pull a tray every hour or half-hour.” The operator would then have a good reason to follow standardized work. Every hour someone would show up (in all likelihood a “train”) and ask for a set of parts. If the operator was late, he or she would have to explain why and call a team leader or a supervisor, and write it on the production analysis board. In doing this, the operator shares the problem of delivering on time in full with management.

Pushed to Pull

As the operator shares the problem, he or she will also be pushed to find a solution. The obvious solution is to follow the standardized work, or, if there is a practical problem with the SW (works for right handed but I’m left handed, etc.), to question it and improve it with the supervisor. The point is that a regular pull on the cell provides a reason for operators to be interested in standardized work and to apply themselves to follow them. SW delivers a real, immediate, practical benefit to them: it keeps them from showing up late at the appointment. Coupled with real pull, it prompts them to recognize and deal with problems the moment they occur.

Lean is a system. Standardized work cannot be considered in isolation from customer satisfaction, JIT, jidoka, and kaizen. In fact, when you look at how people often go about designing standardized work, they tend to jump in with the stopwatches to define the optimal sequence of work, skipping the very first box to fill on the form: takt time.

takt time, we’ll agree, is one of the core concepts of just-in-time, another pillar of lean. Yet, takt time is essential to standardized work. At the Gemba, takt time will be something like “the number of normal work hours per day/necessary quantity to build per day.” (This is not quite “demand” because production planning will have leveled the demand.) takt time is an essential measure to give the right amount of work to the cell. takt time is the basis for calculating target cycle time, and hence the content of work in the cell (should we add an operation; add an operator?). Without pull to represent takt physically, standardized work is nothing more than yet another paper exercise.

Similarly, can we maintain standardized work without jidoka? Not likely. The argument that once operators have been trained in standardized work they should know it from then on is like saying that you’ve opened the person’s head, slotted in a new “knowledge” card, shut the head and they will now perform accordingly. We know that people are not like that. Operators will master standardized work through continuous on-the-job training. For instance, imagine that every time the operator is late for her delivery when the hourly pick-up shows, and that she calls her team leader at that stage. The team leader will then go through the standardized work motion once again with her until they find where she’s getting a step wrong (NOT GUILTY – learning is a process), and this is how she’ll learn over time. Eventually, she’ll think of a smarter way of doing this or that, and have an improvement suggestion for the team leader. The supervisor can then help her formulate her suggestion, try it out, convince other shift operators and implement it.

Real or Random?

Standardized work is (1) takt time, (2) work sequence and (3) standard inventory (as in: 0 or 1) parts at each step of the process. But, without a link to customer satisfaction (don’t be late on the pulls!), without pulling at a regular pitch, without jidoka to react quickly to any problems holding up the delivery rhythm, operators are unlikely to take it on board. After all, they’ve been doing this job forever, they’re the ones stuck on their own in the cell, and they’re going to do the work the way they feel more comfortable to do so – who’s going to tell them different? If they haven’t agreed on the problem of timely, regular deliveries, why should they buy into your solution for their work, whether you call it standardized work, job instructions, or that’s how things are done here.

Finally, and probably more disturbing in the end, the moment the operations director stepped into the cell, he spotted a number of obvious ergonomics problems. Did they do anything about it after the visit? I doubt it. Standardized work and kaizen are the two sides of the same coin. On the one hand there can be no kaizen without standards (Where do we start from? Is it a real improvement or a random change?), but on the other, how can you convince operators to follow standardized work if it’s not their standardized work. By starting with kaizen, you can (1) show goodwill by solving, with the operators, obvious ergonomic issues and (2) convince operators that the standardized work is the best current way to do the job by challenging them to come up with better. Just as with crosswords puzzles, if they’ve tried but can’t think of anything better than what you suggest, they’ll have persuaded themselves that it is the correct answer. Do not separate standardized work from kaizen and expect it to work – it’s like taking two legs off a table and expecting it to stand.

I’d have to know more about the specifics of your company to give you a more relevant answer, but my gut reaction to your question is: are you pulling? Without a regular, frequent pull on the workstation, you’re not giving operators any reason to follow standardized work. Sure you can convince them that it’s the best way to work – and they might nod and agree – but why should they bother? Real pull means that you are (1) delivering to customer on time in full, (2) at takt time. Pull creates the conditions for standardized work. Without pull, you’ll have to go back and persuade people to follow SW all over again, again and again.

Properly Applying Auto-Eject Isn’t Automatic

February 3, 2011
Back to top

Gemba Coach,

I’m working on improving the design of our machines for lean manufacturing, and hear that an auto-eject feature can support this work. If this is so, can you clarify how?  

I was reflecting on this very question a few months ago, incongruously, as I was sitting at a table at a conference in Shanghai, in front of a pile of books to sign (which, let me say as an author, is more an occupational hazard than a sign of fortune and fame). We were late on our schedule and the idea was to go through signing the books as quickly as possible. One gentleman there was kindly trying to be helpful by taking the books off the pile, opening the first page and presenting it to me to sign. Quite a natural reflex when one lends a hand to accelerate a process by pushing it along. But this was not helping much. Let’s look at why. 

In order to sign a book, I have to hold it so that (1) I can position it correctly to sign and (2) it doesn’t slip away as I apply the pen. Each time I was presented with the book the handoff caused an unnecessary fumble as I tried to grab and keep the page open and position it correctly. And, my signing hand was encumbered by the just-signed book that was still in front of me. After several of these mishaps it struck me that what I needed was an auto-eject (yes, I know, too much lean thinking, another occupational hazard). And so I asked the gentleman to help me get rid of the just-signed book rather than feeding me a new book to sign.  

When we finally settled down to the new arrangement it went much faster – to my satisfaction (hypothesis confirmed, ha!) and his surprise. First we avoided the over-processing waste of me grabbing the open book and often reopening it again, and second, we eliminated a lot of muda movements. Considering the quick cycle involved in signing a book, we about halved the cycle, which does mean a lot when you have three huge piles sitting in front of you. It was funny, because, as on the shop floor, I was surprised at how greatly overall production can be improved by eliminating movement waste from a short cycle. 

Babysitting Machines

Auto-eject is essential for the simple reason that positioning a part is hard, and usually demands human judgment and in many cases, human experience; but ejecting a part is easy, as the action consists mostly of releasing the part from the fixture and pushing it gently into a receptacle. Getting a robot to position a part is always tricky and tolerates very little variation in both part and fixture. Actually, getting an operator to position a part correctly is no walk in the park either, which you find out when, for whatever reason, there is no direct line of sight. The operator inevitably fumbles if her hand can’t follow her eyes. Essentially, placing the part in the machine is where the real value is, not picking it out or starting the cycle

You may wonder about the value of an auto-eject if the finished part is ejected from the machine and the operator then puts it into a finished parts container? Not much, I agree. In many factories we find operators standing in front of a machine with a container of components on their left and finished parts on their right. They pick up the main component and the other bits and bobs to assemble, they set all of it in the fixture, they take a step back to clear the safety light-guards, they push the button to start the cycle, wait for the machine to do its job, get the part out of the fixture and place it in the finished parts container. Auto-eject will gain a few seconds at the most on a cycle where most of the muda consists of waiting for the machine to do its stuff.

Here, we have to consider a second fundamental principle of lean: don’t tie operators to a machine and don’t create isolated islands. As long as one operator is tied to one machine, he will have to babysit it while it cycles. Some people try to cheat with rotating tables that reduce the waiting time (the operation of the machine is conducted at the back of the table) but, nonetheless, the operator is still feeding the machine and taking parts off. Essentially, no matter how much you improve this workstation, you won’t be able to use the productive time liberated other than by producing more, which would be overproduction--a big no-no. One tenth of a person is a person if they don’t have another value-adding job to do. 

In order to get the benefit of any kaizen, we would then have to bring another machine close to the first one, and ask the operator to operate the first one, then the second. In the best of cases, this second operation would be conducted on the same part, so that more value is added (unfortunately, in many cases, you have to bring another part in, which creates all sorts of logistics difficulties). But say we’re lucky, we can bring the next operation on this part in the cell

The idea now is that while the machine cycles, the operator can place the part in the second machine and start the second cycle. But wait a minute – where does the part come from? If the operator had to pull it out of the machine, she’d still have to wait for the machine to finish to get the part out. If not, she’d need a stock of parts between the machines. In that case, she still has to put it in the machine, and then out of the machine to place the second part. This is usually the case anyhow because machines are separated by safety lightguards, chicken wire, containers of components, electrical panels and so on. 

If there is an auto-eject on the first machine, however, the operator can use the ejected part and place it in the second machine while the first operates. She is no longer tied to the machine. And, in fact, if the cell is designed without any barriers to the flow of parts between one machine and the next, the operator can simply push the auto-ejected part in the next fixture, and can probably deal with a third, fourth, fifth machine in the same cycle time, and with lowered ergonomic burden

cell or Obstacle Course?

Like most things in lean, auto-eject in itself does not provide any special benefits. It’s the reflection of a deeper manufacturing thinking of a cell as a flow of parts. In most cases I know, industrial engineers design a process, then pick (or design) the equipment needed to realize each step of this process and arrange these machines in a production cell. Even when they’ve made a “lean design” effort of creating a “U-cell” to limit operator walking, we find that moving a part from one machine to the other is a real obstacle course, and that it takes most of the operator’s working time to do so, with large machines, heavily built and guarded, component racks between machines and the ubiquitous electrical cabinets (by the way, check those over-engineered poka-yokes that slow the process and give out false positives in order to make production even more challenging in the name of “lean”). 

Lean thinking leads you to look at the process differently, think about the technical minimum solution to realize every step of the process, and then design a cell so that (1) the parts flows unhindered from one fixture to the other and (2) the operator can easily place the part in the next fixture without risking life and limb or straining themselves as they’ll do so several hundred times a shift. 

Auto-eject is a critical aspect of designing a lean cell, which only makes sense in the context of applying lean thinking to the entire cell conception. Without it, it’s just one more device with limited benefits. The answer to the question is the same as always: start from the operator’s movements and look at the flow of parts. If you work with the operators themselves to find a better compromise for both you’ll get a leaner cell, where auto-eject will help disproportionately.

The Trouble with Lean Experts

January 26, 2011
Back to top

Dear Gemba Coach,

I run a Lean Promotion Office(LPO) and my team mostly conducts kaizen events across the company. We are usually seen as successful in getting results and are well supported by our senior management. One problem is that middle-managers often complain about how individual LPOs go about effecting change, coming in with preconceived solutions, not listening to the people on the ground and sometimes adversely affecting operations in ways that don’t show up in the indicators. We see the lean program as quite successful overall, and have difficulties reconciling this with what we see is a worsening reputation. Have you come across situations like that?

Thanks for this question, it’s a courageous one to ask – and yes, funnily, I do come across similar situations. In fact, in my experience, they’re quite frequent, even when, as seems to be your case, lean activities deliver hard results. This is difficult on both fronts: firstly because frontline employees develop a deep distrust of “kaizen” as the reputation spreads, which is in direct conflict with the aim of spreading the kaizen mind, and secondly because lean specialists become discouraged with their job. They feel they’re doing good work by improving processes and getting results, and take it quite hard not to be better received by the teams on the ground. 

This is not an easy issue to tackle. Let’s explore it by its two main dimensions: the relationship and the result. First, let’s look at the relationship. I assume from what you say that your team has been working at lean for a while and is by now quite expert at improving productivity in cells. Expertise has many advantages, the largest one being the ability to correctly diagnose a situation quickly, and focus on the key leverage points that will lead to rapid improvement. The more expert the lean guys, the easier it is to obtain hard results from the improvement workshops. 

Experts, however, also have well documented drawbacks. As individuals grow in expertise, they also acquire behavioral side-effects that can irritate or downright anger the people they work with. What do we know about the various ways in which experts fall short

Domain Dependence

The most commonly known (and empirically validated) fact about expertise is that it is very domain dependent. One is an expert in one’s domain, relatively narrowly, and not in any other domain. For instance a great lean guy on injection presses (SMED, TPM, press settings, etc.) actually won’t be very good at lean assembly work (ergonomics, single-piece-flow, handling variation, component conveyance, standardized work, etc.). Although lean specialists (particularly consultants) tend to argue that their lean skills are broad and easily apply to any situation, this is not the case – and insisting on the fact that lean applies anywhere and that if people question this it’s because they’re resistant to change just rubs the matter in. Frontline employees know for a fact that their process is different (it is) and don’t believe cookie cutter solutions will apply. A smart way of going about it is to get them to apply the lean principles and tools to their domain expertise and see what comes out of it. But being prescriptive outright, even when right, is sure to aggravate operators with good cause.  

Overconfidence

Expert are also overconfident both in their ability to solve the problem and the effectiveness of their chosen solution (which can also be their pet solution – i.e., they don’t know anything else). This is not necessarily a bad thing as it brings confidence to the improvement team, but can rub people the wrong way when the experts will summarily dismiss other opinions or proposals. In the experts’ mind, they’re not being blinkered, they just evaluate low success probability to any other suggestion than their idea. Letting people try their own solutions before browbeating them into accepting the logic of your own, even if to conclude this wasn’t the right way to go about it lets them learn, and helps building better relationships. 

Gloss Over

Because experts are better at interpreting situations and finding the right way of dealing with the problem, they also tend to gloss over details and aspects of the problem they consider irrelevant. These details and issues, however, might be very relevant to the people on the ground who – rightly or wrongly – might have made a big thing of these issues, and causally linked them to the problem. 

For instance, in lean work, most operators are persuaded that what the cell really needs is a new machine here or there. They will pay great attention to the various ways in which the machine misbehaves. In many cases, it is obvious to the expert that, yes, the machine might be a problem, but unbalanced processes and intermittent component supply have a much bigger impact on performance. The experts will then skate over all the anecdotal evidence the machine has had its day and is completely shot, and probably rightly as well. But it’s not because the machine is not the main problem of the line that it isn’t the team’s main problem. To get the operators to realize the problem is elsewhere, the expert should first get them to conduct an analysis showing whether this is the issue or not. As long as people are convinced they know what the real problem is and the expert is just skimping over it, they’ll feel not listened to and not very trustful of the expert’s recommendations. 

Inflexibility

Oddly, experts tend to be quite inflexible in their own domain of expertise. If something changes, such a norm, a regulation or just knew knowledge, experts are often the last to accept the change and take it on board (unless they are true experts, realize this bias, and constantly self-monitor and challenge their own knowledge).

For instance, in one company’s expert team, the first understanding for eliminating waste was that one should study every operator work cycle distinguishing the “green” (value-added) activities from the “red” (nonvalue-added) activities. The aim of a kaizen workshop was to reduce the red, nonvalue added activities.

When the same team started to work under Toyota’s direct coaching, the sensei taught them that before going into this distinction, they should first measure the degree of variation between the minimum cycle of 20 and the maximum. The sensei redefined the kaizen work as reducing variation in the cycle before tackling the value-added non-value added distinction. For all sorts of reason this approach proved to be far more effective in terms both of parts per hours per person and operator involvement, but still, many of the “expert” members of the lean office refused to change their minds, and (no longer at the same company) some still conduct kaizen workshops with the red/green framework. The same group later learned from one of their Japanese counterparts that “preparation” for such a kaizen event wasn’t paper analysis but actually spending a few days in the cell with the operators fixing the most obvious ergonomic issues. As a group, they’re still struggling with acquiring this practice, although it makes obvious good sense. 

Another current example I come across regularly is getting lean guys to accept adding environment to quality, cost, delivery, safety, and moral indicators of customer satisfaction. The resistance to measuring the environmental impact of a kaizen workshop (less cardboard boxes, more reusable containers) is surprising. 

Not Good at Predicting How Others Will Do

Experts are equally notoriously poor at predicting how well others will do with the same problem. In the lean context, this is an issue inasmuch as lean experts typically get it wrong when they tell a team that this issue will be easy to solve and this one won’t. The issue here is not the actual problem, but the team’s own understanding of the problem and the expert is a very poor judge of that because no one understands what others don’t understand. 

Overall, experts are good at identifying the problem and solving it, but poor at sharing this understanding with others, which is a serious pitfall in lean where the number one aim is to teach people to solve their own problems. Not surprisingly, teams on the ground tend to complain about the lean experts – even if the expert turned out to be right. The first part of the answer to your question is for your expert team to work at being more self-aware and understand the state of the relationship with the shop-floor teams. 

One quick exercise to visualize this is to map the emotional level of the team throughout the workshop. Vertically we can draw a happy face, a neutral face, and an angry or upset face, and track horizontally the workshop path, to see how the participants feel at different stages of the event. Sure, you can’t make an omelet without breaking some eggs, sacred cows make the best burgers, no pain no gain and all these aphorisms explain that people are not necessarily happy changing their mind – but is it really necessary. In some cases (and I have to confess, I tend to do this), you just ram the ideas through and don’t care how people feel about it, as a way to make them progress faster. But if that’s your strategy, don’t wonder or complain that they’re not happy about it. 

To answer your question, the first aspect to investigate is whether your lean officers understand how much relationship building is part of lean. LEAN = kaizen + RESPECT. We walk on two feet: improving performance and developing mutual trust. If your lean team accepts that developing mutual trust with the frontline staff is a core part of its mission, maybe you can then assess and monitor attitudes and behaviors, taking into account what is known of “normal” expert biases. 

The second thing to check is the actual performance of your expert team. Are you definite that people’s situation has improved after the kaizen? I can’t count the number of kaizen events I’ve come across where productivity has improved on paper, but the situation is clearly worse for the people in the cell. Many “improvements” have not been finalized and the outcome is increased variation in the cell. Furthermore, many attempts at transforming “nonvalue-added” work into “value-added” work lead to increasing the ergonomic burden on operators. 

Lean is unique in taking the point of view of value-adding staff and encouraging them to think for themselves. These background complaints about the lean team should be taken seriously and investigated to assess (1) the real impact of kaizen events on the people in the cell and (2) the relationship developed by the lean team with operators and frontline managers during the kaizen workshop. 

If there is one overall lesson to draw from years of experience in transformation is that change occurs within a relationship. You can’t expect any deep change to occur in anybody unless there is a pre-existing mutual trust relationship. Even if you carry a lot of weight in the company and are not afraid to use a large gun to force people into doing this or that, they’re unlikely to adhere if they’re being bullied into anything. So the real question for any lean team is how do we first develop a relationship before we ask people to change? As I mentioned earlier on, I’ve found that working on basic ergonomics is an excellent relationship builder. As a first step to kaizen activities, taking the time of fixing issues for the people you want to later convince of new ideas can create a few mutual wins as a foundation stone for a future win-win relationship. I don’t know whether this answers your question, but that would be the first thing I’d go and investigate: are all my lean promotion officers aware that change occurs within a positive relationship?