Column Archive: 2014


Is momentum loss normal during a lean transformation?

November 25, 2014

Dear Gemba Coach,

One of our outpatient wards reduced waiting time by 75% and got an award for their lean improvement project. But then momentum was lost and waiting time is now worse than it ever was. Is this loss of momentum normal?

Normal as in usual? Typical? Expected? Or unavoidable? Usual – let us say frequent. Typical – not really, it depends. Expected – sure, if you don’t do things right. Unavoidable, no. Much ink has flown in the lean literature about projects, momentum and top management support. In my experience, clearly, if top management is not leading the culture change by first personally learning how to think lean before asking others to do so, spot kaizen projects always disappear.

I remember a division VP in a plant in Germany very happy about the results of a kaizen workshop consultants had run for him in the plant. He was proudly showing me the powerpoint slides on his laptop, and I was puzzled because I had seen nothing on the Gemba. Eventually, we walked down from the meeting room to the shop floor, finally found the cell in question and observed that everything (and I mean everything) from the workshop had disappeared and people had reverted to business as usual. Awkward.

In this case, the VP was definitely committed to lean thinking and in many cases leading the change himself – what happened?

We consistently misunderstand the role of middle management in lean changes. Typically, where Toyota talks about group leaders, team leaders and team members, we still talk about supervisors and operators – we walk past the leadership element.

Twenty years ago, I remember the senseis telling us time and time again that the first responsibility of the group leader was to maintain and develop visual control. Most of the plant visits my father did with his sensei were about visual control and the at-a-glance distinction between what is normal and what is abnormal. Lean thinking is essentially about seeking the ideal conditions for creating value without generating waste.

In a project situation, typically the project team analyses a current process, identifies flaws, brainstorms for solutions and implements fixes. And then walks away. While the focus remains on “checking” whether these solutions work, performance improves. Once the project has been validated and translated into “savings” and the circus has left town, people will quite normally revert to how they worked before. Why shouldn’t they? Noe of their issues have been resolved.

Visual control is a technique to translate the top management challenge in visual goals for every team member, so that they understand intuitively what they’re asked to do without having to be told. Yesterday on the Gemba, the site manager of an aeronautics plants was telling me how excited he got when one of his line leaders had started measuring lead-time in her line. And then he had an “aha!” moment when he saw that the charts and numbers they were all so happy about would have no meaning for operators. Scratching their heads, they then came up with a way to visualize lead-time with open slots for products on a table, a kind of proto-kanban. Operators got it right away and the improvement wheel has started because both the middle manager and the operators are working on a problem in the daily course of their work without having to intellectualize it overmuch.

The Gemba approach to lean changes runs opposite to the project one:

  1. Identify a performance improvement opportunity that makes sense at a business level: improve safety, improve product quality, reduce inventory, reduce unnecessary costs, etc.
  2. Figure out a way to visually control the issue with the team: lines on the floor, red bins, a production analysis board, a measles chart, kanban, etc.
  3. Look out for the skills gap this visual control will highlight and train people: improvement is rarely hard because of will, but usually because of skill. Each new shop floor challenge typically reveals that employees are not so confident about this or that part of their work, and that’s okay – just a matter of one-to-one training.
  4. Improve the process: when people have been trained and when they follow the visual control, they’ll spontaneously have ideas on how to improve if their manager asks them and supports their initiatives.
  5. Find the next performance improvement opportunity: as the process improves, some doors close (thankfully) and new doors appear – which then need to be opened by going through the learning cycle again. The point is that as teams learn, so does management.

We were discussing this with my friends Paul Evans (plant manager) and Jiri Janatka (lean coach) in Czech Republic and they came up with this brilliant visual control for these same for steps (meta-visual control?):

For each step of the value stream, they check whether visual control is in place, whether there is a clear measure of performance is in place, whether they know an improve tool and whether they work at improving local skills – red tags are gaps. One board says it all!

Middle-management mastery of visual control techniques is the key to the sustainability of changes. It’s not mysterious, and not a culture or moral issue. Once you set up a roundabout at the entry of a village, motorists are far less likely to zoom through it. Signs along the road giving you feedback on your speed compared to the speed limit will lead to less speeding. Similarly, and visual control hack that leads to daily observations and discussions with the group leader about some aspect of the work will lead to sustainable improvement. At the end of the day, this is what Gemba practice is: better observation and better discussion. When people understand, they usually act. To get them to understand, you need to have them try stuff first. Try visual control first.

How do we solicit feedback from the shop floor without being overwhelmed by the enormous amount of ideas?

November 19, 2014
Back to top

Dear Gemba Coach,

My company is trying to implement a system for collecting, organizing, and maintaining visibility of employee suggestions and ideas.  I think we all know that the "suggestion box" has gone by the wayside.  How do we solicit feedback from the shop floor without being overwhelmed by the enormous amount of amazing ideas that we're asking for?

Twenty years ago or so, I visited the best lean plant I knew outside of Toyota, in northern Spain. The plant manager told me he only looked at one number daily: the number of suggestions made the day before. As we walked through the plant, he explained that he envisioned his job as observing how each cell was performing, pointing out problems to team members, team leaders and supervisors and encouraging suggestions from team members. This plant tour impressed me deeply to this day in demonstrating how macro-results, one of the best performing plants in its category, could be linked to such micro-improvements.

Suggestions are indeed one of the least familiar tools of the lean toolbox because of, I believe, the same difficulty everyone has with lean: it starts with the individual employee. Value stream mapping is easy to grasp. It’s a high-level tool not so different from reengineering where the manager can visualize redesigning the entire process. Suggestions, on the other hand, require involvement at the most detailed level, with the operators themselves.

What’s the Problem

Suggestions, nonetheless, are central to lean’s search for perfection. We often mention Taiichi Ohno as the originator of lean, occasionally stressing the impact of Kiichiro Toyoda as the theorist of just-in-time and his father Sakichi Toyoda as the inventor of jidoka. Yet, the less familiar figure is Eiji Toyoda, the legendary boss of the Toyota Motor Company who over his long tenure turned a bankrupt local company into the powerhouse it became.

Not often in the limelight (he once griped that Ohno was better known than he was), Eiji Toyoda protected Ohno from all the internal naysayers, supported the development of TPS and encouraged its spread to suppliers. More focused on the engineering side of the business, Eiji nevertheless has a determining influence on the budding TPS – he came back from a month-long training visit in Ford plants with a model for a suggestion system. His vision of suggestions as a way to involve employees influenced very strongly how the TPS evolved, and what “real” lean is about.

To return to your question, before we discuss tools, let’s ask again the fundamental question: what is the problem you’re trying to solve? Are you trying to:

  • Administer the suggestions from the shop floor so you can evaluate them, pick the best ones, and implement them (and eventually reward them)?
  • Encourage employee engagement and involvement in improving their own work environment?

These are two very different projects. In interviews, Eiji Toyoda describes how the Ford suggestion system was geared towards finding the best ideas to improve profitability. His own idea was very different: how to engage every mind to come up with better ways of working and give people more responsibility and ownership over their work areas. His vision was summarized then by the slogan: “Good thinking, Good products” (A slogan picked up from an in-house contest in 1953 after the creation of the Creative Ideas and Suggestion System).

If we seek to improve engagement and involvement we need to look at these two dimensions:

  • Engagement: enthusiasm and absorption in the work that translates into extra-inch effort to further the company’s aims. Engagement is mostly about grappling with problems and showing initiative and creativity to overcome them.
  • Involvement: feeling part of the team, and the company beyond and showing it through active participation in activities beyond the minimal definition of their role.

Key to Engaging and Involving

Engagement is therefore necessary to spot a problem, take personal responsibility for it (feel that it’s up to you to do something about it and not simply live with it) and come up with a suggestion. Involvement is about enriching the relationships with the team leader and the supervisor in order to move from suggestion to full resolution and also to convince other members of the team that the suggestion is a good one. In this sense, the suggestion process is the following:

  1. Spot an obstacle to doing good work and think about it
  2. Come up with a suggestion to improve the work environment
  3. Test it to see if it will actually do the job and adopt or adjust
  4. Convince other members of the team that it’s a better way of working
  5. Get it implemented in the company’s standards.

As we can see this is a tall order for an employee to do it on their own. The key then to engaging and involving suggestions is training frontline management to support the suggestion process.

Tools, then. Back in the Spanish plant, the plant manager had set up a system copying what Toyota was doing at the time:

  • The team leader helped the operator write a suggestion form with before/after and expected gain
  • This form went on a board (responsibility of the area supervisor) that showed the progress from New, to Accepted with the week, to Requiring more than one week to be evaluated, to Realized.
  • The plant manager check the boards on the shop floor to see that suggestions were looked speedily enough and check how they were handled by supervisors.

In Lead With Respect, we use a slightly different board for smaller companies, one less reliant on forms and bureaucracy:

Whatever tools you use (Toyota used suggestion boxes when it first started with its Creative Ideas and Suggestion System), the key to success is discussing with the management team the purpose of your efforts:

  1. What are your improvement goals in establishing a suggestion system: what problem are you trying to solve and what do you want to see improving?
  2. What tool will you choose and what process will you put in place to support the tool: for instance, how will you reward suggestions? Will you pick a “suggestion of the month?”
  3. How will you train frontline managers and team leaders to understand the purpose of the system, its operations and how to support their own team members in making suggestions?

Without these fundamentals in place the suggestion system, whatever form you chose, will devolve into a bureaucratic exercise, same a so many other attempts at suggestions in numerous companies. The issue is not the tool itself, but the kaizen intent behind the tool.

Can creative people, like product developers, follow such a structured method such as lean?

November 7, 2014
Back to top

Dear Gemba Coach,

For product development you need creative (maybe even chaotic) people. Are those people suited to follow such a structured method as lean? Like trying to achieve one-piece-flow in product development?

Thank you. What an interesting question! As a writer and novelist, I like the idea that it’s okay to be chaotic! But aren’t we making assumptions about the nature of creativity? Let’s take a gemba example of a product we all have experience with: a gasoline pump. In product development terms, this product evolves at several levels:

  1. Solving quality problems of products now in production through engineering patches (or adding customer-required options)
  2. Introducing regular product refreshes through engineering improvements to keep the customers (gas stations) interested in refurbishing
  3. Reducing work content through smart engineering in order to drive manufacturing costs down
  4. Making step change improvement to key functionalities such as the meter and the pump to keep market leadership
  5. Making technological breakthroughs to invent the dispenser of the future, with technologies such as connectivity, VGA screens, Big Data diagnostics and so on.

Tom Edison and Steve Jobs

Each of these specific change points have their own rhythm, or takt, and require very different types of engineering and, in particular, different types of creativity:

  • Quality problem solving creativity is centered on solving narrow, detailed problems as locally as possible without impacting the rest of the design. Doing so successfully demands full mastery of existing standards and a good dose of cleverness.
  • Product refreshes are based on changing specific product features, and again, require a full understanding of standards. A successful product refresh is one where as little as possible is changed to the full design, certainly no change of the product architecture, but specific features can be visibly improved for customers. The creativity required there is one based on full experience and mastery of standards with very local experimentation to minimize changes: every design change has a probability of failure and a number of points of impact. We need to be very cautious and frugal about these changes.
  • Reducing work content is mainly about modularity within the existing product architecture, and a lot of the creativity there involves teamwork with suppliers in terms of which parts come as separate components and which can be standardized as a full sub-assembly.
  • Step changes in key functionality should be made within existing interface standards, and necessitate to delve deeply into the science of the function. For instance, coming up with a new meter for the dispenser meant revisiting everything the guys knew about hydraulics, fluid dynamics and mater/fuel chemical interactions. This definitely requires another type of creativity, which is that of the dodged scientist who will, in Edison’s terms, not fail because she succeeded at the 1000th attempt, but learned 999 ways that won’t work.
  • Technology leaps require yet again another sort of creativity, and someone in the team had better have a Steve Jobs type of person, because it’s first and foremost about a total product vision and then knowing how to work with engineers to come up with a product reality that fits that vision – this is fashion designer type of creativity, and indeed, you might say, artistic and perhaps chaotic, but in any case rather a rare occurrence.

Putting the leap aside, which most companies I know are not that well set-up to achieve (fortunately, few companies have Steve Jobs as a direct competitor), the bulk of product development is not about total product reinvention but about making smart changes that have controlled impact on the full design. The secret to products that work (and that customers buy) is being both conservative on standards and daring on a few, visible features.

Overburdened Engineers

As a result of aggressive financial management, most companies I know are currently underinvested in engineering –- an easy budget to cut as the output is not immediately visible unless one calculates a clear takt of engineering changes. As a result, engineers tend to be overwhelmed by work covering at least the four previous types of engineering demands. After seven (plus two, minus two) work items on someone’s mental work desk, psychology tells us any human is saturated and starts shifting mindlessly from one pressing issue to the next without time for deeper thinking and self-reflection.

Peace of mind and time to think are absolute requirements for creativity and intuition. Chaos, a necessary ingredient of serendipity, only works for people obsessed with a clear question and with the mental space and disposition to keep working on it over time. If you’ve been mulling over something for long enough, then, yes, a brilliant idea will come in the shower or poking your fork in egg yolk at breakfast, or going to an art gallery – only because your mind is running the same questions on and on in its back office. The front desk is free enough from distractions that the little guy in the mind can browse files and make unexpected leaps of intuition. If the front desk is busy all day long, this is unlikely to ever happen.

In these terms, one-piece-flow projects create the best conditions for true creativity. Without a serene, one-by-one, and yes, structured approach, engineers are overburdened with too many demands on their time and have to juggle too many different burning fires, which is chaos, certainly, but not of the creative kind. The peace of mind of obsessing on one topic at a time is a general framework that liberates engineers to create some real creative chaos by thinking deeply into the issue and welcoming serendipitous insights.

What do you actually do on the gemba?

November 4, 2014
Back to top

Dear Gemba Coach,
What is it you actually do on the gemba?

Good question -- and hard to answer when not on the gemba. If I had to sumarize it in one point, I'd say that I try to see through the lens of the seven wastes at work level to the larger customer and capital wastes beyond. The following paper published in Industrial Engineer captures this quite well: 

www.iienet2.org/uploadedFiles/IIE/Author_permissions/IEOct14Balle.pdf

(Copyright 2014 by the Institute of Industrial Engineers. All rights reserved.)

My boss has asked me to take on the sensei role for the company. What does that mean?

October 28, 2014
Back to top

Dear Gemba Coach,

How do I become a sensei? My boss has asked me to act in the sensei role for the company but I’m not sure what that means – any advice?

Interesting question. “Sensei” is indeed one of the remaining mysteries of lean. I’m not sure it’s a role. As I understand it, the Japanese term originally was more a mark of respect towards a teacher -– no person would call themselves sensei, but students might call their teacher sensei, literally “a person who has come before another.” Yet, it is a fact that, particularly in the U.S., sensei is becoming a role. Some consultants are defining themselves as sensei, and some companies are even advertising for the role. Tricky.

What do senseis do? When he was CEO of an automotive supplier, my father had a sensei. Mr. Nampachi Hayashi was a senior executive in Toyota, a TPS expert, who had worked for Taiichi Ohno. He would come every couple of months and visit plants with Freddy. He would essentially walk the plant and point to things making (often cryptic) remarks, check kaizen efforts, and then offer brief feedback and explain (sketchily) a point or other.

Freddy and his team would then scratch their heads trying to figure out what he meant. One time, for instance, during the plant tour, the sensei turned to the plant manager and asked him “what are you paid for?” As you can imagine, this created something of a stir. It took a good long while to figure out that the plant’s manager main job was to create a visual environment where everyone could distinguish at one glance normal from abnormal. The sensei never said so directly –- this was the team’s interpretation after much soul searching and practical experimentation.

The Toyota sensei was supported by a Toyota consultant who helped the company use the tools properly. In the early days, we all thought it was all about the tools to get productivity: squeeze the lemon, get the juice. Over the years we realized we had it completely the wrong way around. The shop floor consultant’s role was to use the tools locally to do what became known as “model lines” to create a teaching place for Freddy, the CEO. The idea worked this way – the sensei would NOT explain but would SHOW, so he needed areas where the difference between a “lean” cell and the rest of the plant was stark enough even dumb gaijin could see it. The shop floor consultant was not there to provide direct results, but to demonstrate the tools –- results were the ultimate proof that the tools worked.

At first, of course, Freddy thought that by simply replicating the tools across his plants he’d leverage those results, but soon realized this worked rather randomly. After a couple of years he figured out he needed to be the sensei for his plant managers. At the time he ran 50 or so plants around the world and would visit each plant once a year (a logistical challenge). In these visits, he’d (1) look at the plant key indicators and ask about the plant’s main challenge, (2) walk the plant and look at the kaizen efforts, (3) check the plant’s budget with the site manager to see whether resources where being allocated to the correct problems in his opinion. Freddy has been retired for 15 years now, but I still meet people who remember these visits … very well.

Hit-and-Run Workshops

The fact is that spreading lean through kaizen blitzes is a western approach. In Japan, as far as I can understand the history of it, lean first spread internally around Taiichi Ohno’s department and then others, and then to the supply chain through the senior officers. I guess it helped that Toyota was both a major client and often a minor shareholder, but basically, the word got around that if you wanted to work with Toyota you had to apply this just-in-time stuff, and that if you asked nicely and showed commitment they would teach you how –- from the top.

For practical reasons (Japanese consultants coming to the US in short trips), the lean revolution started with the kaizen hit-and-run workshops, which gave lean a very different trajectory. The sensei, in this sense, is the person that helps the CEO draw the right conclusions from the kaizen efforts and to face the company’s challenges. When the CEO changes her mind, the company changes trajectory.

What practical tips could help you to get into this role?

First, find your own sensei. I’ve yet to meet someone who understood lean thinking on their own. A large part of the sensei’s value is in knowing the lean tradition and thus knowing how the lean principles apply differently in different settings. I can’t count the times when I applied what I thought was the correct lean principle in a given situation only to have my father point out something I’d not seen and explain that, in this case, it applied completely the other way around –- leaving me to tell the team we had to pull everything down and try again.

Very recently, I visited a plant where they’d done what I’d suggested and created a leveling box to pull product through the plant … for the week (one column per day). Later I had to explain that if we don’t pull at least every hour, we’re not pulling at all -– and that we need to optimize flow, not make it easy for logistics. That sort of detailed situation-based knowledge is impossible to discover on your own and must be taught. My personal rule of thumb for senseis is their own tradition: how many degrees of separation with Taiichi Ohno? The heart of the matter is that you need to keep learning about the tools no matter how proficient you think you already are.

Second, pitch for a full day a month on the gemba with your CEO. That’s the deal. If the CEO isn’t willing to commit, don’t take the job. The day a month is essential technically, because this is the opportunity to teach lean to the CEO by showing her the practical difference between anti-lean, not-so-lean, leaner and very lean so that she understands better how she is running her company – this is described in detail in our latest book Lead With Respect. But also, politically, privileged access to the CEO once a month in a very visible way will give you much greater clout and will make many of your battles to get things moving a lot easier – and I mean A LOT. A day a month gemba visit is the make-or-break issue.

Thirdly, set up an obeya. A key skill in playing the sensei role is to:

  1. Formulate business challenges in terms of quality, lead-time, productivity and morale. This in itself establishes a lean framework around vague business problems.
  2. Make sure the line is involved in solving problems rather than staff department coming up with new ways to control the shop floor (audits, kaizen programs, etc.) without having responsibility for bottom-line results;
  3. Focus on problems small enough so that the people themselves can resolve them practically.
  4. Show the CEO how the detailed kaizen relates to the larger issues –- and how people’s shop floor initiatives could open up much larger opportunities.

The “See” Level

One of the most interesting constraints one has as a “sensei” is not being permitted to explain (I have to say, I fail all the time – I find myself explaining this or that) but, ideally, being only allowed to demonstrate.

This is the crux of the job. You need to set up clear areas for kaizen efforts as well as a pull system to string them together and give yourself an architecture for kaizen, and then take the CEO there to make them see:

  1. How most of the obstacles to flow and productivity come from policies or decisions they themselves instigated at some point for very valid reasons. For instance, I can think of one CEO of an engineering company who had completely externalized all production. From visiting suppliers and engineering, he realized that this decision did not allow for any VA/VE efforts and actually hindered the improvement of products, and so he started to produce some in-house. He then realized that by producing in-house with a lean approach he was an order of magnitude cheaper that his supplier could ever be: the company’s strategy changed progressively from the gemba visits.
  2. How people’s initiatives to solve problems can open up new initiatives for business development. For instance, through regular gemba visits, one COO realized that most new products did not sell (plenty of them in the inventory), because they were essentially a reflection of what engineering thought would be best by customers. However, learning from shop floor kaizen effort, they then focused on designing a new product with the same functionalities but better and lighter, which the market took up right away.

The difficulty is therefore not to make points by arguing with them, but by having the right kind of kaizen effort going at the gemba and letting the CEO make up their own minds.

Fourthly, become an expert in pull systems, in order to always refine the tension between delivering just-in-time and built-in quality. I don’t know what your background is, but maybe lean promotion officers these days manage to do their job by focusing on kaizen events or A3s and without a clear idea of how to set up pull. Pull is your ticket to credibility with senior management as it brings together local problems by visualizing the overall flow. Pull absolutely needed to keep the pressure on the shop floor to highlight problems and solve them. Without pull, I doubt you can achieve any of the other points meaningfully. A pull system is never finished and it’s a great way to demonstrate that the goal of continuous improvement is …  continuous improvement.

Learn to Speak Finance

Finally, take a finance class. If you want to talk to the CEO, you need to talk their language, which is finance. If you want to help the CEO with wider business issues (and translate them in terms of quality, lead-time, productivity and morale), you need to understand the business case.

This is not something that you will have picked up on the shop floor, no matter how good you are at your job, and you need to acquire it. Learn about finance, talk to financiers, see how they see things. If you go back to the two Ohno classics Workplace Management and Toyota Production System you’ll find many pages on the situation of the automotive industry in Japan and what kind of financial decisions companies can make. People often skip over this in search for “lean” explanations, but, to me, what this demonstrate is Ohno’s deep grasp of the company’s business problems at the time and his search for a different kind of industrial solution. You can’t have the latter without the former. Take the class.

I doubt there even is a proper job definition for what it means to be a “sensei”, but my hunch would be to start by applying lean principles to yourself and define a development plan: what are your own skill gaps and how do you intend to develop yourself (no one will help you there unless you find your own sensei). I’ve shared a few pointers from my own experience, hopefully that can help, but I have no idea whether this kind of experienced can be generalized. I’d be very eager to hear how you’re doing with this one. If we could clarify the sensei issue in the lean movement, we would definitely have kaizened ourselves!

 

How is standardized work different from the Taylorist one best way?

October 19, 2014
Back to top

Dear Gemba Coach,

How is standardized work different from the Taylorist one best way?

Umm… I’ll give you a typical lean answer on this one: it depends. It depends on what? Your outlook. How can your outlook change what a thing is? Well, it depends again. It depends whether you’re trying to implement lean or trying to learn lean thinking. It depends whether you’re seeking static optimization or dynamic gains.

Frederick Taylor’s one-best-way idea was in equal parts commonsens and revolutionary. He thought of studying how work varied from person to person, picking the most efficient worker, breaking down how he worked in work elements, codifying it and then teaching all other workers to monkey see, monkey do. On the one hand this first gave tremendous productivity increases to any manager who did so (and Taylor insisted some of these productivity gains should be shared with the workers through higher wages), on the other hand no one likes to be told how to work and this approach created a lot of resistance, resistance that echoes more than a century later.

Standardized work is the sequence of movements one should follow to master a task. It’s not so much a process as a skill – a way to do things. Standardized work can thus either be seen as a way to force static efficiency by getting all workers to follow the standardized way – reversing it to Taylor’s one-best-way – or as a way to seek dynamic gains by treating it as a basis for improvement.

For instance, if the worker has only a general knowledge of the task, she’s likely to get into her own work habits and there are no reason to think this will be particularly helpful in terms of safety (some work habits can be dangerous), quality (check points might be ignored) or productivity (lack of movement fluidity). In this case, the first task is to catch-up to the best known way, and there is nothing else but learning the standardized work way and trying to apply it as well as we can. In this case, the best way we know.

But say that all workers have been trained to standardized work and you want to go further? On the gemba at a Toyota plant I remember being shown a case where a taller than usual operator struggled with a standard position to correctly place a windshield. In this case, rather than try and fix the one-best-way, the team leader was taught to discuss and observe with the team member and figure out what the difficulty really was. Beyond basic skills, the discussion entered into specific skills. As a result, both the physical environment and the movement for this specific team member was improved, which then led to a kaizen suggestion that improved the operation for all operators.

One Best Way

If you are in a below average situation, it makes sense to tread standardized work as a “one-best-way” catch-up tool: first learn  standardized work. But if most of your guys already know standardized work, then SW becomes a basis for improvement, not a rule to apply. On the gemba, standardized work sheets are visual control to check how the work cycle is done, not for compliance but for understanding: discussing every case where the movement differs from the SW sheet and wonder why? Why? Why? In some cases the SW sheet is amended, in others the team member has to learn a new skill. If we’re lucky, someone comes out with a suggestion for further kaizen.

The confusion mostly arises from middle-managers who will not take into account team members as individuals, with their individual strengths and weaknesses, skills, body shape and specific obstacles to deal with. In lean’s ideal of “respect”, the frontline’s manager’s job is clearly to support on-goingly team members in their understanding and mastering of standardized work, and to do so in the constant improvement of standardized work, change point by change point. As Taiichi Ohno once wrote: “standards should not be forced down from above but rather set by production workers themselves.” Do you practice your Taiichi?

How can I train technical experts who know more about the work than I do?

October 6, 2014
Back to top

Dear Gemba Coach,

I understand I have to train people, but I work in a very technical area and they all know far more about their jobs than I ever will. How can I train them if they know more than I do?

Teach them improvement. You’re making a very good point, and asking a very good question. In knowledge work, in particular, the people you manage are likely to know a lot more than you do about their job. The same happens dealing with suppliers – in many cases, we rely on outside partners to help us with aspects of our own job we feel less than competent at. How can we evaluate their work if they know best? What’s more, how can we train them? To what?

A pivotal attitude in lean management is “problems first”-- welcoming problems rather than brushing them under the carpet, shooting the messenger, or routinely looking for workarounds. Problem solving is the main development method in lean management. However, problems can be solved smartly or stupidly. Some “solutions” can turn out to be terrible ideas, with negative consequences. How can we tell a good countermeasure from a poor one if we don’t understand the field? In specialist fields, how can we become expert enough to figure out what’s what?

The trick is to focus on kaizen. If you’re unsure of what you know or understand, focus on an improvement topic. A couple of years ago, the CEO of a maintenance operation asked me to help with his lean program. I had never worked very closely with service or maintenance and found myself in the typical consultant situation of having to advise without knowledge – borrow your watch to tell you what the time it is. I told the CEO I was incompetent to help them, but he’d tried lean before and wanted to try something else, so we agreed we’d be learning together.

One thing I knew from years on the shop floor of various industrial operations is that service parts are always a problem – they take for ever to obtain, which is not surprising because they’re hard to schedule and manufacture from producer’s point of view.

So we gave ourselves a challenging improvement goal of no more interventions rescheduled because of a missing part. These are serious people, and serious operations, so they’d tried several times before, mostly with software patches. This time we did it the lean way:

  1. We visualized on-time-delivery for every technician in one center on a wall to show how well the parts delivery process performed for its internal clients.
  2. We asked the person in charge of the stock to list problems as and when they occurred.
  3. We visualized the inventory by reorganizing the physical holding of stock in terms of high-runners, low runners, and odd parts very difficult to procure.
  4. We asked him to recalculate his inventory levels once a month and to progressively build a plan per part.

We discovered that very few parts were used very frequently. With hindsight, this was obvious, but had been lost in all the background noise. We also discovered that the company had an implicit ordering policy with habitual suppliers and thus would buy in batches to get a price discount, cluttering the stock.  We learned that some parts could be procured really fast through new specialist sites (even, believe it or not, through Amazon), and not necessarily at a much higher price (in fact, we were astonished at the process differences and fluctuations).

In the end, it turned out that service parts could be a fully profitable business, not just supplying technicians on the field, but customers as well, as the firm learned the ropes of smart procurement.

Learning Areas

We also quickly found out that many problems came from dispatch – as they looked into applying the same basic method: measure the performance, list the problems, visualize the process, try new stuff. Sure enough, we discovered how complex dispatching really was as there are no two similar maintenance contracts and the level of service required varies from one client to the next.

From these two starting points, the CEO and his team progressively got closer to the core of the business: service on site. This is particularly hard to kaizen because technicians are on their own in client sites and the gemba is difficult to access. What they did was create learning areas in all centers with client training machines to explore with technicians how service itself was done, again, by asking them to improve certain aspects of their job.

The upshot is that I learned a lot about service. Over a couple of years, inventory was cut by half and margin doubled as a result of the CEO’s relentless kaizen efforts. And he learned things about maintenance that he didn’t know as well.

By the by, what he learned enabled him to attack a new market of independent clients he’d not have an in before because his company was geared towards servicing large corporate clients. He discovered that independents could be easier on price but required a much more personalized approach to service – and learned how to do so cost effectively.

Now, it’s clearly better to start with knowing something about the topic, but sometimes you start where you start – which can mean a clean slate. By focusing on kaizen topics, you’ll find you learn very quickly simply asking “why’ repeatedly. People are never shy of explanations when they’re in the midst of problem solving. They don’t feel imposed on or bothered by stupid questions. In the full flow of problem solving, exchanges are easy, explanations natural, and very often every one discovers that what we assume we all know is never so clear. Even the most experienced people learn when they explain to others.

Teach to Improve

How do you know you’re tackling the right improvement topics? Here again, lean tradition is a big help: if you’re looking at safety improvement, quality improvement, flexibility improvement (stock reduction) or productivity improvement you can’t go far astray.

Although you certainly can’t teach their jobs to people who are specialists in narrow expert domains (and shouldn’t try), you can always teach them to improve. Kaizen topics and kaizen techniques will soon surface specific technical problems and encourage observation and discussion. When this occurs, you will learn as the experts engage with the problem – they’ll spontaneously show you the guts of the issue. Furthermore, you can also contribute by your own experience or out-of-the-box thinking. In full problem-solving mode, no one will mind or resent that.

The next step is to ask experts to write up standards to support the kaizen ideas. As the knowledge base grows, so does your understanding of the situation. You will never get the same experience they have. Experience, in itself, is not transferable. But you’ll find you’ll learn about the fundamentals much faster than they have. Soon enough, you’ll be hiring someone not quite so expert to do the job and find yourself teaching them how to do it as well.

I’m a six sigma black belt and have now been ask to do lean. I’m not sure where to start with my team. Any advice?

September 29, 2014
Back to top

Dear Gemba Coach,

I’m a six sigma black belt and have now been ask to do lean. I’m reading the literature and there’s a lot to absorb. I’m not sure where to start with my team. Any advice?

The analytical tools you’ve used as a six sigma black belt will serve you well, but one of the main differences I can see between the two approaches is that where six sigma aims to solve a problem, lean aims to develop the spirit of continuous improvement. You need to get your mind around this rather big change for much of the literature to make sense, and the best illustrations can be found in Masaaki Imai’s Gemba Kaizen and in Jon Miller’s Creating a Kaizen Culture.

There are three broad aspects specific to lean to establishing continuous improvement habits in your team:

  1. Continuous improvement of visual control
  2. Continuous improvement of individual skills
  3. Continuous improvement of the flow of work (the process)

Visual control is very specific to lean and needs to be learned – often from scratch. Unfortunately the literature is not much help there because although it mentions it frequently, it doesn’t quite say how. The old time senseis use to badger us incessantly on whether we could, at a glance, distinguish normal situations from abnormal situations.

Visual control can be as simple as tape on the floor to highlight an area, say for buffer stock, which shows immediately that one extra box is overflowing. Visual control can be a kanban that visualizes the flow of jobs through your team. Visual control’s goal is that we see together, we discuss together, so we act together.

But the lean point is that visual control should be constantly improved, in order to improve the detail of problems we look for. For instance, if we paint lines on the floor to identify a buffer zone, the sensei would ask us to draw spaces for each individual container. If we’d set up a red bin to highlight defective parts, the sensei would ask us to draw levels so that we could tell whether the number of defectives right now was normal or abnormal. If we set up a team kanban in an engineering office, the sensei would ask us to make it individual kanban boards and so on. The essence here is that the work environment continuously evolves until work is perfectly intuitive and can be understood by all at a glance.

Developing People

As visual control improves, so does our understanding of problems. Problems are the principal training tool in lean as people’s expertise is developed by solving problems, and their ability to work with others is developed by solving problems across organizational boundaries. The difference I can see with six sigma is that you’re not expected to solve the problems yourself (with the help of your team). You’re expected to help your team members to solve their problems in order to develop their competences.

Your six sigma training should help you to understand problems in detail and do all the measurement and clarification necessary to frame it correctly. But then, rather than “solving it” in lean, we’ll ask “why?” and “why?” until we’ve figured out which exact part of the technical process we handle poorly, or which special cases we’re not so familiar with and so on. Once you’re figured this out the “problem” becomes a straightforward issue of training. Whether by codifying work standards better or continuing to solve similar problems, the aim of lean is to develop capability by growing the team’s expertise in handling their process in unusual or difficult cases.

By example, think of the damage vendors can do to overall process efficiency. Dealing better with difficult suppliers is a complex problem because there is not one cause, but many, probably a specific case for each supplier. Teaching project leaders or procurement officers to improve the regularity of supply is a core capability, which requires them to understand how their system adds to the vendor’s internal problems and how to help vendors deliver good parts on time rather than blame them for poor delivery. You will grow this capability as you train every one of your procurement people to better understand vendor specificities – never an easy job.

Biggest Barrier Going from Six Sigma to Lean  

Finally, “process improvement” in lean tends to mean something different than in six sigma. As I understand it, six sigma is focused on reducing variation… to six sigma levels. Nothing wrong with that. However, in lean our obsession is to improve the flow of work by reducing batches through reducing set-up times. Getting closer and closer to takt time is what “leans” the process and what reveals more detailed problems (and back to the first point).

I can’t emphasize enough the importance of set-up reduction in lean thinking, to understand process issues such as:

  • Lack of understanding of sales pace and production pace
  • Large batches
  • Broken up, complex interlocking steps
  • Poor inter-process logistics (batching up the transport)

Mastering variation in technical processes is a huge part of solving overall process performance issues, but not an aim in itself (other, than, of course inasmuch as it affects quality). Leaning a process is essentially about making work flow at the customer’s rhythm.

The upshot of the shift from solving discrete problems to developing a spirit of continuous improvement is that, in my experience, six sigma instincts tend to be to freeze the process once we’ve got it to work as we want it to – to seek static efficiency. Lean looks for dynamic gains, a very different source of performance. Lean tools are about teaching people to change:

  1. Change their work environment for ease of work and better visual control.
  2. Change how they do technical steps to better adapt to specific cases.
  3. Change tools and stations more often to have greater flexibility in both product mix and volume.

I remember a Toyota document detailing how they implemented lean in one of their plants decade after decade, and their explicit aim was: reform manager’s mind. The biggest difficulty you’ll probably face in switching from six sigma to lean is not the understanding of the tools, but the change of heart and mind about the kind of progress we’re after. Lean performance comes from the dynamic improvement, not static efficiency.

How should I accelerate my own learning?

September 22, 2014
Back to top

Dear Gemba Coach,

How should I accelerate my own learning?

Hmm, interesting question. If I reflect on the learning I see at the gemba, I can suggest basically three mechanisms for learning:

  1. Epiphany: the “aha!” moment in which something hitherto unseen clicks into place and your understanding is permanently changed;
  2. Practice: the step-by-step learning through trial and error and repetition.
  3. Adaptation: the unconscious changes we go through by adapting to the group of people we belong to;

One way to look at your question therefore would be how can you maximize these effects, or take away the barriers that hinder them.

Epiphany is probably the most fun but certainly can’t be planned for or programmed, no one seems to know exactly how these “aha!” moments occur, and mainly they seem to be in-the-shower kind of moments, times when you’re not actively thinking about the topic and something random creates a serendipitous click. Evidence with insight problems seems to point towards problem framing, how we look at the problem. The practical way to enhance this would be to continue to read about the topic and around it. By exploring peripheral concepts, some ideas will be seen through a different light, and so more likely to trigger an aha! moment.

Of course, aha! is also linked to practice as the more often you see a situation the more likely you are to have a sudden insight about it. Practice’s main difficulty is that we tend not to be very rigorous with what we learn and confuse ourselves precisely by looking about and around. For instance, it’s very hard to stick with one lean tool before immediately exploring the second. By the fifth or sixth lean tool, we’re overwhelmed and practice is confusing.

How to Maximize Learning

In the early days of lean, some senseis would have you practice 5S for two years before teaching you anything else, in a parallel to the famous “sweeping the yard” stories in zen practice. There is some sense to it, even though it’s not very appealing because of the great discipline it requires. Without being so extreme, the way to maximize learning from practice is definitely to task oneself with learning one thing at a time and moving from one chunk of knowledge to the next.

In this instance, TWI methods are very useful. Practice means not just dumb repetition but repetition with the aim of understanding step-by-step what we’re doing:

  1. What is the overall goal of the activity?
  2. What are the detailed steps of the activity?
  3. For each step what is the key point to succeed at it?
  4. Why is each step necessary?
  5. What could we do better at each step?

It’s definitely easier with a trainer keeping you on the straight and narrow as it’s hard to both do something and watch oneself doing it, but just the fact of breaking down activities in steps is helpful. By example, writing is a large part of what I do and I’ve learned to break down writing in terms of arguments, points, paragraphs and sentences. Each of these chunks have their own problems: the argument needs to be persuasive, the points clear, the paragraphs tight (without too much wandering) and the sentences easy to read and grammatical (no passive forms, fewer adjectives, etc.) In writing fiction you’ve got to add character design and plot, and so on. A clear understanding of the key steps definitely increases how fast your learn.

Monkey-See, Monkey-Do Methodology 

Finally, a little thought about a way to learn is to join a group of people who mastered the knowledge you seek – our profoundly social natures will make sure that you’ll pick up unconsciously many aspects you’re after. This is a completely different kind of learning as, for instance, many ex-Toyota people discover that what they did naturally at Toyota doesn’t apply so easily when they leave the company because the environment is completely different. They then have to make a conscious effort to practice what they did naturally before which brings us back to epiphany or practice.

Yet, definitely, consciously choosing who your role models should be and copying them deliberately will certainly speed up your learning curve, if only because by using the monkey-see, monkey-do method you’ll discover that some things your models seem to do effortlessly are in fact very hard to achieve – and thus trigger a new cycle of learning. Asking yourself with care “what should I learn from whom?” will clearly improve your learning ability (as well as make you realize your picking up unwanted habits from people around you don’t necessarily appreciate).

In the end what counts most is the passion for learning and I have no recipe for that. Some people keep it their entire life. For others, it comes and goes. Ultimately, is learning filling a vessel or lighting a fire? Probably a bit of both, but without keeping the fire burning,  it’s unlikely we’ll have the patience to keep filling the vessel (or, should I say, we’re unlikely to fill the vessel – those passives!). In any case, what a great question to ponder!

Would you have a fresh perspective on 5S to make it more motivating?

September 10, 2014
Back to top

Dear Gemba Coach,

I’m the manager of a plant that has changed hands (again). The new corporate team finds my 5S insufficient (again) and want me to make a 5S drive (again). Would you have a fresh perspective on 5S to make it more motivating?

5S, of course ... Well, 5S is never good enough and it can’t be bad to question your 5S approach now and again. The trick, of course, is to get every team member engaged in (1) eliminating what is not useful, (2) putting things back in their place after using them, (3) cleaning them before putting them away, (4) learning to do 1, 2, and 3 as part of every work routine and (5) making sure frontline management is interested and follows up.

This usually involves a lot of discipline and is not much fun. A good place to start is to explain (again) why 5S is important: not to have a “clean” plant in order to make corporate feel good, but to have an efficient plant where all work cycles can occur without mishaps because obstacles to the next operation in the cycle have been resolved (no stumbling over unnecessary items, no looking for tools, no grabbing faulty tools or parts, etc.). But explaining only gets you so far. The deeper question is: what do you have to change in your own management approach to make 5S sustainable?

So let’s take a step back. What conditions make team members feel engaged in any activity? From experience, three factors stand out:

  1. Tradition: when any site has a tradition of something, that harks back to at least the previous generation of employees, people tend to follow it because people are, well, people.
  2. Program: a steady program of improvement workshops that reinforces regularly the need for 5S might not go all the way to create an improvement culture, but certainly helps.
  3. Management: how committed and supportive to 5S are first line managers and their managers. What do you do a senior management to reinforce support for individual 5S initiatives?

The Real Question about 5S

People join companies and leave their boss. People join companies for pay and benefits, working conditions and work culture. They leave their bosses when bosses harass, are unfair, inconsistent, are always people’s back and so on. The same applies more generally to any activity: people will join in if they feel it’s part of the company culture and will opt out if their immediate boss (wittingly or not) discourages them.

Therefore, the real question is how to we train frontline supervisors to train team members to use 5S as a personal discipline to maintain standardized work in their own work areas. From the supervisor point of view, this means that 5S creates a steady flow of small changes to improve 5S conditions (as opposed to just the discipline of keeping the place “tidy”).

A few plant managers I know have attacked this by having a program of “ergonomics workshops” (which could also be called 5S workshops) in which the 5S questions are used to identify obstacles to smooth work. The program consists of one shift workshops once a week across the plant.

One lean promotion officer is typically dedicated to that job (the job involves preparing the workshop, running it and following up, at the rhythm of one a week, quite busy), only the supervisor and team members of the area participate in the workshop and the plant manager’s commitment is that they will show up at the end to the workshop to listen, hear suggestions and help where they can with minor purchases. In this way the plant manager demonstrates (1) her commitment to a 5S culture and (2) supports the supervisor in supporting 5S.

There are no magic bullets, and 5S goes deeper than many other lean tools as it requires both persistence, discipline and a real understanding of standardized work. Hopefully by working both at plant culture level and at immediate support level you will succeed in making 5S part of the plant’s traditions.

I fail to see the difference between hoshin kanri and the strategic planning we used to do. What am I missing?

August 18, 2014
Back to top

Probably nothing – any tool holds the same potential for bureaucratic nonsense if not used with common sense, and hoshin kanri (HK) more so than others. Toyota is a global automotive manufacturer that asks the right questions, and has developed a number of tools to bootstrap its learning. Yet, with any new tool coming out of Toyota we should careful about how it translates to other environments. HK has been around for decades and used to be known as policy deployment – the risk of interpreting it as cascading objectives from strategy planning is very real.

I’m by no means an expert on hoshin kanri, but the CEOs I work with do try to use some aspects of it for their own internal questioning and direction. From their perspective, what would distinguish HK from the strategic planning they used to do (to varying degrees)? The four main aspects that come to mind are:

  1. Customer gemba focus: starting the thinking and planning process with a hands-on understanding of customer issues and figuring out where we could benefit our customers further.
  2. What do we need to improve? HK targets should be clear, concrete improvement targets as opposed to wishful thinking “what we’d like to do.”
  3. Gemba control points: where will we see on the gemba that our HK efforts are bearing fruit – do we know exactly what we’re looking at and do we have the right visual management in place so that everyone can see the same?
  4. Clear PDCA topics for every middle-manager: The high-level change must be broken up into small, every day operational changes, which will be middle-management’s job to carry out. To do so, and to learn, we have to make sure these smaller changes are carried out within a PDCA framework to learn together.

CEO Struggle Points

True customer focus is rare and difficult. Listening to customers is hard and hearing them is even harder, particularly since what they say they’d like is rarely what they really want (and are ready to pay for). In figuring out what “following customers” really means, most CEOs struggle with four distinct intents:

  • What customers say they’d like: Customers want always more of everything, and then you find out that when you offer it to them, they simply ignore it. This doesn’t mean we should ignore what customers tell us, but that it should be taken with some caution.
  • What they really use: In any product or service, customers really use a small part of functionalities (although different customer groups might use different ones, hence the need for good segmentation). Figuring out what customers really use is a full-time gemba effort. A good place to start is customer complaints where customers make an effort to educate us about what they try to do with the product or service.
  • What we’d like to do: Every organization, whether large or small tends towards inward looking wishful thinking -- politics make that unavoidable, as staffers are eager to anticipate what their bosses would like and to present it to them as their idea (or get consultants to do so). This is not necessarily a bad thing. As Henry Ford once quipped, if he’d listened to his customers he’d have tried to come up with a faster horse. Still, being clear about what we’d like to do is important to surface many hidden assumptions in the hoshin kanri process. Groups are always, always tempted to dress their collective wishful thinking in rational clothes to make it more palatable to themselves and stakeholders – watch out for that one.
  • What partners expect from us: No organization is an island and there are plenty powerful players from shareholders to regulatory bodies to key suppliers who have their own ideas of what we should do and pressure us into doing so. They’re not always wrong, and they sometimes have the clout to push their agendas forward– spelling it out clearly is an important step to understand (and withstand) the pressure.

These four circles rarely intersect and the CEO and her team must keep these questions in mind as they walk customers’ gembas and their own operations. There are no 100% conclusive answers, ever, and the world out there changes faster than we can change, so this is an endless open question. Yet, if we get this wrong upfront, the hoshin plan will be nothing more than a formal exercise to validate senior management hunches, rather than a true attempt to ask ourselves the hard questions and look for hard answers.

Once customer issues are clear(er), the second trick to HK is to express these in terms of improvement challenges. For example:

  • Reduce warranty claims by half
  • Shut down a stock-holding warehouse
  • Reduce total cost of one product by 10%
  • Double the number of accepted suggestions

Certainly, certain HK goals will be about doing something new, but most HK goals will be challenging improvements that will force us to do something radically better. In general, HK goals should be some form of step improvement in quality, security, flexibility, or productivity. Sure, some new offering activities will also be part of the hoshin plan, but I’m always suspicious of any plan that doesn’t squarely highlight aggressive improvement challenges. Real innovation capability stems from hands-on operational know-how and before we try new tricks we’d better be sure we master the olds ones and deliver on our existing promises before making new ones.

Thirdly, the exercise remains boardroom paperwork unless it’s brought to the gemba. How will we see at the workplace that the needle is moving on our HK goals? How will we involve every one in seeing the same thing? Visual management is a core element of HK in terms of physical control points. If we’re talking about halving the warranty claims, where is the war room devoted to warranty claims and following progress? If we’re shutting down a warehouse, can we go there and look among the racks to understand the inventory reduction strategy and how fast we’re going about it?

Gemba control points are a key difference between HK and strategic planning because we don’t rely on financial reporting to have some notion of whether the plan is going well or poorly. Also, control points are a key tool to communicate to others what we’re trying to do. As the saying goes “what gets measured gets done,” but, more to the point, “what the boss looks are regularly gets paid attention to.” Gemba control points are half the battle in making real improvement happen.

PDCA vs. Action Plans

The final HK specificity I’d insist on is the difference between PDCA activities and action plans. The temptation with “strategic deployment” or “policy deployment” is to establish clear goals (or clear wishful thinking – often hard to make the difference) and then build action plans, which frontline managers will have to execute. As I suspect from your question, you’ve had experience with those and you know how things turn out.

The hoshin kanri process, as I understand it, is fundamentally different in that it asks each manager for a PDCA activity related to the larger goal. There is no intent to add all these activities and somehow reach the goal from the sum of our actions. We understand these problems are complex and that something fundamental will have to change to get this order of result (if it was easy, we’d done it before). The aim of PDCA activities is to learn piecemeal to understand the problem better.

In the obeya room, we’ll see the indicator corresponding to the high level improvement goal (quality, security, flexibility, productivity, innovation) and then several PDCA activities (often written up as A3s) that look into different aspects of the problem. What tends to happen is that after exploring and discussing the issues, the team usually sees the leverage point they need to invest on – mostly with training – that will change the way the process works and thus what results it delivers.

In the previous examples, by exploring various instances of warranty issues, we’ll finally figure out the main weakness of our products and do what it needs in terms of value analysis in production and value engineering in development to improve things. To shut down the warehouse, we’ll have to figure out which scheduling practices lead to storing products – mostly to do with procurement habits and wrong forecasting guesses and so on. The point is that the goal is not achieved through the execution of an action plan but through discovering what the real weakness is in our existing knowledge and processes and tackling that.

Hoshin kanri is not specific to lean or Toyota – it became popular in Japan back in the 1950s. The intent then was to realize that each person was an expert in their (admittedly narrow) field and to somehow use the power of collective thinking to turn the firm into the best in its field.

The idea is to focus on shared goals, to make sure everyone understands these goals and to involve the management line in the planning of how to achieve these goals (as well as making managers accountable for their part of the plan.) Nonetheless, just as with the strategic planning we all grew up with, the make-or-break aspect is whether we’ve identified the correct business issues. Expressing business problems in terms of improvement goals is a safeguard against management wish fulfillment and a true instrument for learning: as we try hard to improve, we’ll understand far better the real terms of our business. As you correctly surmised, HK can have the same drawbacks than old fashioned strategic planning if not rooted in customer gemba and the spirit of kaizen.

What does developing people mean?

August 7, 2014
Back to top

Dear Gemba Coach,

Are people tools? Should bosses use people? What does development mean? How should we think about it?

Okay… deep question. To explore this, let’s go to a different gemba. In The Gold Mine, Bob Woods takes Mike, Phil and Amy to a yachting race to look at how two different skippers run their crew radically differently. [These characters return in Lead With Respect, the Ballés new novel about how to develop people to create a culture of continuous improvement –Ed.]

Imagine for a second that you are skippering one of these sailboats. You need to get the spinnaker up – the lightweight colorful sail one sees ballooning out of the front of the boat on reaching courses. This is quite a complex operation, and in any case you’re steering the ship as well, so you’ve got your hands full. But you’ve got a crew on board and you can use:

  1. Their hands: this is the most instinctive way to run people. You’ve got the knowledge and experience to know what needs to be done, so you order each crew member to do stuff step by step. You expect them to pay attention and be skilled enough to perform correctly every action you order. They’re extra pairs of hands to your brains.
  2. Their brains: This doesn’t come so naturally but is a different way to run people – you train them to perform the task autonomously. They learn to both do their job as well as coordinate with each other so the chute goes up on your say so but without your direct involvement. This has two advantages: first, it frees you to keep an eye on what else is going on and to spot if they run into problems they can’t see because they’re busy with their tasks, and second, it’s more fulfilling for the crew because they can feel responsible for getting the task done as well as the pleasure of working smoothly together.

In the first case you use people as tools, and in the other you develop teams. In a craftsmanship environment, the latter is supposed to come from the former. The artisan tells his apprentice what to do, in effect, uses them as extra arms, and through copying and repetition the disciple learns the craft. This is a rather slow process and very dependent on the skill of the artisan and his skill at coaching.

Today, we encounter this routinely as we go from one local restaurant (not chains) to the next. In some, the owner is really good at welcoming guests, cooking, and working the logistics, and usually waiters and waitresses reflect this. In others, the owner is not and, again, staff will mirror this.

Taylorism changed this process radically by (1) centralizing the method function – a central expert now devises the best method for all staff to work to and (2) pay for performance – having taken away the incentive to learn from the artisan in order to one day have your own shop, you have to incentivize people sufficiently so that they apply the prescribed method. Frontline managers evolve from examples staff try to follow in order to one day perform autonomously, to enforcers who make sure the prescribed method is applies. IT and computer systems have spread the Taylorist system to almost every human activity.

My Boss, the Computer

The combination of the Taylorist system and IT systems have scaled the use of human beings as tools to very large numbers. This HAS worked. The downside, of course, is that it doesn’t work very well because first, the IT system is not designed to deal with every specific situation (although post-Google search engines might be different) and secondly, it’s not that fun to work for the computer, so staff slaved to a software system tend to behave as bureaucrats – they do the minimum job but do not try to perform in unusual situations or better serve customers.

The lean approach is a revolution inasmuch as it is not a return to craftsmanship – why deny the benefits from a century of Taylorism – but it goes beyond by encouraging managers to be teachers rather than enforcers. I had this discussion yesterday on the shop floor:

  1. Manufacturing engineering comes up with the best known way to build the product – it’s their job to prescribe the assembly sequence and the correct tolerances at every critical step.
  2. Frontline management doesn’t simply enforce this method, but works with teams every day to understand the nuances of the job (how many turns of a screw give the correct tightness?) and how team members hand over tasks from one to the other.

If we return to the sailing analogy, there is a prescribed method on how to put the chute up, which is written in the sailing manual in terms of sequence of steps and what to pay attention to, but then the skipper can chose either to 1) keep the method to herself and tell each crew member what to do when or, 2) share the method with the crew and help them get better at their tasks and better coordinate amongst themselves.

Development, in that sense, means developing three dimensions of any role:

  1. Autonomy: the ability to solve specific problems on one’s own in the way the manager and other team members would like it to be solved.
  2. Teamwork: the individual ability to better co-ordinate with fellow team members and other specialists within the organizations in order to, collectively, come up with smoother better-flowing work processes.
  3. Initiative: the ability to spot problems or improvement opportunities, the presence of mind to call them out and the creativity to make suggestions on how to solve problems or improve and take action to try things.

Develop People Systematically

In any craftsmanship environment or Taylorist environment none of these three dimensions are obvious because chances are the default boss will resent autonomy (wishing to keep greater control) will misunderstand team work (asking for submission to the “team spirit” – i.e. to do what you’re told – rather than better coordination) and will discourage any form of initiative, seeing it as a challenge to his all-knowingness and source of further problems within the organization. Developing autonomy, teamwork and initiative requires great confidence in one’s own skills, in one’s relationship with one’s team and in one’s managers’ competence and caring. For this to work, the manager has to clarify with the teams:

  1. Which way we’re supposed to go: what are the success conditions? What are we trying to achieve, in terms of goals and objectives?
  2. What is the plan in terms of the main sequence of steps we’ll go through to succeed at the job or task?
  3. At each step of the plan, how do we make sure we’re doing OK versus Not-OK;
  4. Most importantly, how each of these points are explored and discussed continuously so that team members identifies areas for improvement and contribute their hands-on experience?

The conundrum, of course, is that there is no know way to make sure that frontline managers have the ability to develop autonomy, teamwork and initiative in their people – there can only be leading by example and hoping the right attitude will catch on. However, if the will to do so is there, the lean tradition has developed guidelines to how one can systematically develop one’s people. I was talking recently to Mark Reich, LEI’s COO, and from his Toyota past, he pointed out three core elements:

  1. Make them feel secure: people must feel free of physical injury risk and free of harassment, as well as secure in their jobs and so willing to commit to improvement.
  2. Continuous challenge to make people see problems and improvement opportunities, and develop new skills through training, job rotation, promotion etc.
  3. Utilize full capability by continuously improving value-adding in the job (removing wasteful operations).

The full lean system supports this:

  • Jidoka techniques such as stop and react at every defect are individual training techniques – every time an operator pulls the andon, the team leader first checks the understanding and performance of standards, and if the problem can’t be solved right away, the problem solving activity that follows is, again, about individual development.
  • Just-in-time techniques are all about improving cooperation between team members and processes. Starting from working every work station at takt time and one-piece-flow which involved very detailed baton-passing areas, to the larger issue that in order to produce just-in-time all functions must work in conjunction in order to keep the takt.
  • Visual management techniques (such as standardized work)with the explicit aim to visualize the difference between normal and abnormal conditions and thus support initiatives in terms of spotting problems, calling out, or imagining improvements.

Zombie Ideas Attack

Yet, to a large extent, an understanding of what the lean system really does hinges on the boss’s attitude of using it to leverage her use of further pairs of hands or her commitment to develop people. In the automotive industry for instance, where both Taylorism and lean have the longest history, I come across endless instances in which lean tools are used to further reinforce the boss’ control and management by pressure.

As we learn from military studies into authority and authoritarian personalities some people will always be ready to follow a controlling, even tyrannical leader, because somehow strength makes them feel secure but most people generally hate being told what to do or coerced into it. So far, the management model we’ve all grown up with emerged from Prussia’s Frederick II’s army (codified as bureaucratic thinking by Max Weber, one of sociology’s founding father), rapid automation and Taylorism. The challenge of these nineteenth century systems was to integrate uneducated farm laborers into mechanical armies or manufactures.

In the second decade of the twenty-first century, we can safely assumed times have changed and our key challenge is now to motivate over-educated youngsters into creating greater value whilst reducing environmental waste. The times of the boss as an enforcer of rigid work methods are long past, and yet this zombie idea still walks around in organizations and attacks people. The deep contribution of lean thinking is showing how one can both lead and care by shifting from using others as an extra pair of hands to develop their own autonomy, teamwork, and initiative.

What's new in your new novel "Lead With Respect"?

July 29, 2014
Back to top

Dear Gemba Coach,

I see that you have a new lean management novel out called Lead With Respect. What's new in it?

Well, the “respect” dimension of lean is hardly new. The very first paper published in English on the Toyota Production System, back in 1977 describes it as having two major features:

  • Just-in-time production: only the necessary products, at the necessary time in the necessary quantity are manufactured with stock on hand held to a minimum.
  • Respect-for-human system: workers are allowed to display their full capabilities through active participation in running and improving their own work.

Although, in the continuously evolving meaning of the term “lean” (and we hope, improving), in the early days just-in-time was really put at the fore of the message, and we’ve collectively come to realize very progressively the importance of respect-for-people to lean thinking. Whereas lean was first essentially about kaizen workshops to improve flow, ten years ago we saw that to shift from one-step improvement to continuous improvement, on-going training to problem solving was also a core element of lean thinking. Yet, so far, we had not looked at lean starting with “respect” and figuring out how the rest of lean thinking looked from this point of view.

When Freddy and I started having this discussion, about five years ago, just after publication of The Lean Manager, we kept coming back to the basic fact that although Freddy tried hard to develop all of his direct reports to lean thinking, a few “got it” and many didn’t. Later on, after Freddy retired, we designed lean programs to help other companies based on his experience and we tried to improve the “got it” ratio without, I have to confess, much visible success. The conclusion always seemed to be that about 2 or 3 in 10 execs “got it,” and as a result would learn to redefine what performance meant for the group, and would be followed by another 5 or 6, who would then apply tools to catch-up, leaving an unavoidable 2 or 3 resisting new ideas to the bitter end. Overall, this delivered very visible results but had the well-known weakness of being quite fragile because the entire program would rest on the energy and wits of a small number of people.

I'm at the Gemba, Now What?

Looking at it case by case we then asked ourselves what did distinguish the leaders who “got it” from the ones who didn’t and came to realize we were asking the question of a leadership standard – was there a lean leadership behavior people could aspire to to deliver lean results? We’d been saying for years that the first step to lean thinking was to “go to the gemba and see” – but what, exactly, was a leader supposed to do once at the gemba. (we realized that many leaders shunned the Gemba because they felt uncomfortable about their role on the shop floor in front of workers’ comments and occasional demands)

 As a starting point, from Freddy’s first-hand experience as a supplier to Toyota, we started by interpreting “leadership” as a commitment to achieve objectives through the development of each individual person, as opposed to with the development of people: every leader assumes he or she develops people as a matter of course. Here, we realized that developing people was the first imperative: results were to be sought by people development first, not by command-and-control and incidentally, developing people. This led us to define the main goals of leading by going to the gemba:

  1. Getting people to agree on the problem before arguing about solutions by focusing on facts and their interpretation – and making an effort to listen to frontline people’s opinions and hear their concerns.
  2. Day-to-day on the job development through the discipline of pull (JIT and jidoka) – every one learns by solving problems within the job itself by (1) learning standards and (2) solving problems.
  3. Intensifying collaboration within teams and across functional boundaries by learning to solve problems with colleagues – and thus to improve overall processes through better coordination.
  4. Encourage initiative and creativity from employees by supporting them in improving their own workplace through suggestions or kaizens.

In the numerous versions of the early drafts (thanks here to our editor, Tom Ehrenfeld, who kept challenging us on the topic), we realized that --

5. the leaders who “got it” learned to learn: in supporting kaizen and listening to people they also changed their own understanding of what was important and what less so, occasionally opening the way to true innovations.

What we then needed to do was to describe more precisely what, exactly, we meant by “developing people” – and the people development underlying Toyota’s approach – thanks to Toyota Way’s Jeff Liker’s generous help we came to refine the “T-development” presented in the book:

 

Finally, by looking back on lean leaders actual behavior on the gemba, we defined a behavioral management model based on improving both the results and the relationship which is now presented at the beginning of the book as the seven practices of Lead With Respect:

Boring Text Is Muda!

Indeed, we all know that there is not much new under the sun and that these ideas and practices have been at the core of lean practice since the very start – many of these already can be found in Taiichi Ohno’s own writings – what we hoped we have done is to focus on a “people first” look at lean and describe as precisely as we could the principles and tools of the people aspects of the lean tradition.

Is it new? Not as such as this has all been part of the TPS tradition for decades, but we believe this material has not hitherto been published in a consistent form. It’s new inasmuch as it presents what we hope is a full, self-consistent theory of HR that breaks away from both traditional Taylorist and the Human Relations schools. The principles and practices presented here are specific to lean and the underlying motivational model is a blend of modern psychology research and lean experience at the workplace – this part, for sure, is new.

In the 10 years we’ve been writing lean novels, Freddy and I have tried to present each time lean from a fresh perspective. The Gold Mine is an introduction to lean thinking and tools in a practical context, with a strong link to the business situation. The Lean Manager is a presentation of a full lean system as a complete way to run one’s business. Lead With Respect portrays on-the-job behaviors of lean leaders which can be learned through practice to fulfill the promise of lean by aligning the company’s success to individual fulfillment. A rather lofty aim, which we tried to make as lively as possible through the lives of the characters (boring text is muda!) to make it a good summer read as well!

What? My Pull System Is Supposed to Fail?

July 11, 2014
Back to top

Dear Gemba Coach,

We’ve given up on installing a pull system – every time we try, our on time delivery rate plummets, and we can’t let customer service suffer more than it already does. We’re doing a lot of A3 problem solving – isn’t that lean enough?

A pull system is supposed to crash – that’s precisely what it does. A pull system is not a device to replace the MRP with cardboard cards. It’s not a production system technique. It’s a device to improve the production system, and to learn. The tension between the need to produce exactly at takt and the commitment never to pass on wrong or unfinished work is the workplace for kaizen. The confusion is easy to make and the vocabulary doesn’t help. Lean is about:

  1. Improving customer satisfaction in terms of quality, lead-time and cost: this can’t be done by simply carrying work as usual more rigorously but actually examining every failure to deliver quality on time to figure out the errors in thinking that caused the mistake in the first place.
  2. Tightening the just-in-time conditions of production by reducing lead-times from customer order to delivery, from production order to shipping, from supplier order to production, by further leveling, fractioning and mixing production in order to get closer to takt time – this typically involves making production flexible to reduce batches and improve flow towards continuous one-piece-flow.
  3. Spotting defects closer and closer to where the defect is produced and stopping production rather than accepting a defective (or incomplete) part, making a defective part or passing on a defective (or incomplete) part or order.
  4. Involving team members more deeply in improving their work areas and mastering standardized work by working at a smooth repetitive flow and taking away all the reasons for unnecessary movements and efforts (waste).

Constant Tension

Typically, when Toyota starts production of a new model, very few cars come out of the production line at first because they are stopped along the process as issues are identified. Very soon, most of the problems are solved and the challenge is to achieve target cycle time as soon as possible. In normal conditions a line should run somewhere between 94% to 98% of target. When the line gets to 98%, resources are taken away, which leans the process further, reveals new problems, and the line falls back to 94% and so on. This constant tension is what keeps the leaning process alive and kicking.

What kind of issues a pull system is likely to uncover? Typically, we’ll find 4M problems:

  1. Material supply issues: missing parts are an endemic difficulty in any complex assembly, particularly with many options. The pull system withdraws from supplier processes the parts needed just-in-time and, eventually, makes the supply flow smoother particularly as assembly is scheduled for leveled pull on components;
  2. Machine availability issues: certain processes prove troublesome particularly when they’re over complex or inflexible. Machine tools designed to perform too many operations on the part, presses too hard to change and so on.
  3. Manpower issues: in many cases, a lack of stable teams means operators are moved around in the shop and not trained well enough at handling certain processes they can be unfamiliar with – this creates spot problems for them and for the flow that are hard to pinpoint as long as people are not stabilized in the shop and don’t develop ownership for their own processes.
  4. Method issues: if you stand just 10 minutes in any assembly area, you’ll see that although the overall flow of work is often defined as soon as you look at detailed assembly operations the team members fight against ambiguity and hurdles. Parts are jumbled together in boxes and need to be unraveled, screws are poorly positioned and difficult to put in, components don’t fit well together and need hammering in and so on. These many problems cause quality issues and late deliveries, as well as endless team member safety or ergonomics problems.

Now, of course, falling from 98% to 94% is hardly “plummeting” and if attempts at setting up the pull system really have dire consequences, such as an OTD lower than 70% as I’ve sometimes seen, then, of course, you should stand back and rethink your efforts. In early attempts at pulling, it is easy to fall in any of the following traps:

  • Not leveling well enough – pull can hardly happen all at once from scratch – it has to be learned progressively. The trick is to focus on the very high runners, pull the first, then the second and progressively go down the list by 1) first leveling the demand of the every high runners over the week (the law of high numbers makes it likely that the percentage of daily demand variation on high volume won’t be too bad) and 2) pull progressively the products with higher peaks and deeper troughs. The weekly levelled planning meeting is essential in learning to smoothen a variable customer demand.
  • Sluggish logistics pull – pull means, well, pulling, which is picking up products or parts throughout the day – at the very minimum once an hour. People are often tempted with one or two pull pitches a day to make it easier on logistics. In doing so they forego the “pull” effect on the line, don’t improve much and discredit the whole pulling idea which now looks like another corporate raindance.
  • Being hostage to a process – this can be a “bottleneck” troublesome machine, or one that needs setters to change (and the setters are never available) or a supplier that simply can’t ship the needed components. Pull can reveal one key part of the flow that is hard to improve because it’s owned by someone who won’t or can’t improve. This is a particularly difficult case as it often creates hard political battles around the idea of pulling.

Chasing Your Tail

A3 problem solving is of course beneficial but the real question is: what is a problem? How are problems picked? What kind of solution is expected? Human beings naturally favor problems they know how to solve whereas the very function of pull is to make you face the problems you have to solve – even if you have no clue how. The risk you run by pushing A3 problem solving without pull is to run around in circles chasing your own tail and never addressing the deep issues people are working around. As Chris Argyris once pointed out, many organizational dysfunctions stem from taboo issues, and the fact that the issue is taboo becomes taboo as well. Pull breaks through all of this fancy footwork.

Pull is never easy because it always challenges the status quo. On the other hand, pull progressively makes sure all the rowers in the boat row at takt, in rhythm with each other, which is what makes the process perform.

The root of many problems with pull is to see it as a production technique. It’s a management technique. Pull is the main tool of the site director or even the operations manager to get the flow to behave the way they want it to. It’s a dressage technique for a very powerful and willful horse to take the image of The Lean Manager. Mistaking it for a production technique which will advantageously replace the MRP is an error few recover from because it completely underestimates the political pushback a real pull system will create as long as you continuously increase the level of just-in-time and take cards out. Pull is an essential tool if you who take the “pursuit of perfection” seriously. I don’t believe “lean” makes much sense without pull. 

Am I doing PDCA correctly?

June 30, 2014
Back to top

Dear Gemba Coach,

How do I know if I’m doing PDCA correctly?

Very good question! PDCA is indeed the mainstay of a lean company. Toyota used to represent itself as a pyramid of PDCA cycles building on a foundation of Toyota Way (its values: challenge, genchi genbutsu, kaizen, respect, teamwork) tending towards its goal: long-term prosperity and growth as an organization. That sounds heavy going for a simple Plan-Do-Check-Act cycle, but I guess that you’ve found out for yourself there is nothing simple about teaching – or learning PDCA.

Firstly, context: where does PDCA fit in the larger picture on the shop floor? In order to effectively “grow the company as an organization”, we’re trying to do three things:

  1. Express business challenges in terms of Quality, Lead-time, Delivery and Morale. This is an essential point because it forces you to express vague business problems (“sales are behind plan”) in an operational way (“we’ve had too many complaints and we’re late on delivery”) that you can actually act on as opposed to look for escapes (“our new product will fix that”).
  2. Involve the management line in solving the problem. Fixing performance is not a staff issue, but a line one. We don’t expect the quality department to come up with better audits or better procedures to improve quality. We expect the production department to analyze the causes of customer complaints, figure out what they do wrong and improve it – then talk to engineering or supply chain, figure out what went wrong there and improve it (we do expect the Quality department to provide correct data about customer complaints and defects, in a way that doesn’t hinder value-adding work).
  3. Small step by small step. We don’t expect a PDCA exercise that will make the entire problem go away. If it were that simple, we would have fixed it long ago. What we’re looking for is problems small enough that we can go to the root cause and figure out by this kind of “problem sampling” what is really going on. The PDCA exercise is not meant to “fix” the problem. It’s meant to understand the problem’s causes so that we can improve the company’s way of working.

PDCA has to be seen in the context of the basic lean values of Challenge (relate the PDCA to Quality, Lead-time, Productivity or Morale), Genchi Genbutsu (go to the workplace and take a specific problem that every one can see and grasp), Kaizen (start small and improve step-by-step), Respect (by understanding the perspective of the various people involved in the real-life situation so that we develop a joint understanding) and Teamwork (developing individual insight in the problem and learning to work together). The underlying assumption is that any growing company develops “big company disease” – in my experience, big can start at twenty people – and the PDCA is a key moment where line managers show their leadership what they’re doing wrong in a very specific instance.

This is very powerful, as 1) the line learns to solve its own problems but also 2) leaders learn to see how they created the problem (without meaning to) by some policy or decision taken for completely different reasons. Too often, tactical choices become policy, with dire consequences. PDCA is the antidote.

To get started, you therefore need a business concern, a willing middle-manager and a small, defined problem to look into.

First, Plan. Plan starts from an important premise: there is a good way to do the work. In lean thinking, any problem is expressed as a gap between a standard (whether a regular performance or an ideal) and the actual situation. This is a value judgment. Whenever you walk the gemba with senior management in many companies you discover that in many instance people just work with what they have – they no longer feel there is a way to work well, they’re just happy to get through the day with all the crap that is thrown at them. Asking oneself “what is the standard”:

  • Standard performance: what should we expect to achieve? in terms of customer impact, delivery on time, time it takes, safety of the task, etc.
  • Standard process: how should we expect to work? In terms of having a clear sequence of tasks, with a clear understanding of right/wrong at each step and clear vision of what working conditions (Manpower, Machine, Materials, Method) we need to achieve this.

Is already making a strong stand – it assumes there is a right way to work as opposed to just getting stuff done.

Don’t be surprised if you run into trouble at this very first step of PDCA – you’re touching on some deeper value issues than appears at first glance. Three points need to be clear at the Plan stage:

  1. What is the gap between Standard Performance and Actual Performance and which part of Quality, Lead-time, Productivity, Morale does the problem impact?
  2. What does the manager think the main cause is?
  3. How do they plan going about addressing this?

Second, Do. Do is a tricky part because when you have given people enough of a hard time on specifying their problem, they’re eager to jump in and “do” something – the action plan comes out in minutes flat.

Unfortunately there is a deep bias in the way our brains are constructed. We unconsciously (emphasis on unconsciously) replace any complex problem we’re faced with a problem we know how to solve. Most people take the opportunity of “do” to come up with what they’ve always done – or wanted to. In many cases, this will tend to reinforce the problem rather than solve it, and gets you nowhere in terms of learning. To benefit from “Do” you need to answer two questions:

  1. What skills gap explains the process gap?
  2. Who needs to be trained by when?

The first response to “Do” is to purchase, replace, spend. To learn from “do” you need to switch to “who learns what how”: a different kind of action plan.

Third, Check. Check needs to be planned from the Plan stage – if the measure is not in place before the action plan, how can we tell whether we’ve improved or not. With any measure, nothing works either completely or not at all. The hard lesson about lean is that quality and productivity are in the details: there are no generalities, only specific cases.

 “Check” is really about understanding:

  1. In which situations the action plan worked?
  2. In which it didn’t?
  3. Why the difference?

Fourth, Act. Learning is different from understanding. Learning supposes an actual change in behavior. In many cases, doing something new is not that hard, but stopping an existing habit is. Institutions are not resistant to change per se. Actually, they change all the time in order to remain the way they are – that’s their goal, really, self-replicate. Challenging the status quo is hard. The real test of Act is therefore to abandon the rules or behaviors that maintain the status quo:

  • Adopt
  • Adjust
  • Abandon

What is the fundamental purpose of PDCA? It’s not simply to succeed at solving this or that problem but to create space to think for every employee. To keep up their motivation, employees, people, need to feel they’re not just cogs in the machine. Work is neither Modern Times nor Brazil. Work is about aligning individual fulfillment with a contribution to company success. In motivation, we always hear about the complex part, incentives, recognition, and so on. Space to think is free. Space to think and discuss with one’s manager is simple, and the simplest source of motivation within local teams.

I once read an account of special forces team preparing for a mission. They carried out a “walk through, talk through” exercise in which they discussed every step of the plan in minute detail and every one would contribute question, challenges, and suggest way to make sure this part of the plan would work out. Such a practice both ensures a higher probability of success as every one knows the devil is in the details, but also bonds the team together and intensifies collaboration. PDCA is about doing the same in less intense situation, within the regular routine or normal work.                                                                      

You’re doing PDCA correctly if you use the mechanics of the PDCA cycle to create such space to think and to discuss that binds the team together and motivates both personal engagement and team involvement.

We found your visit rather challenging ... does “real” lean have to be such a struggle?

June 12, 2014
Back to top

Dear Gemba Coach,

I’ve just finished your two novels after your visit to our plant. I have to say we found your visit rather challenging, which I can now put in better context after reading the books and look forward to your next one. The question I’m facing internally however is whether “real” lean needs to be that challenging or is there an easier way to do lean projects without questioning as much what has been done in the past?

The goal of continuous improvement is … continuous improvement, and that’s pretty much non-negotiable. I hear what you’re saying, though, and the “challengingness” is really an effect of the early visits – after a while people get used to it, and it can even become fun (unless we hit again deeper issues when it becomes challenging all over again). Why is a gemba visit so challenging? Essentially, I think you’ve hit it square on the nail: the visit questions what has been done before and since people find it difficult to separate their work from their selves, they feel attacked when something they’ve done is questioned.

On the gemba, I have to work very hard in the early days to get people to relax with the fact that no one is reducing people to one idea they’ve had. In fact, the main lean assumption is that people are doing their job well, but that they hold a few misconceptions that make them do silly things, and they need to realize this by themselves, hence the challenging questioning. The problem obviously is to find a balance between challenging enough so the person will question her thinking and not so much that you tick them off so much you lose the connection. As with most of human posturing this is a delicate strong/warm balance.

The Struggle Is …

Is there an easier way? I’m not sure – and that’s not for lack of searching. In the foreword to the next Gold Mine series book, Lead With Respect, Jim Womack writes “For readers encountering the Ballés (father Freddy and son Michael) for the first time, I welcome you to a world of struggle and great difficulties but, as always, with an eventual happy ending as the transformed Southcape not only survives but flourishes.” I feel that “struggle” is the perfect word.

In The Hard Thing About Hard Things, the best business book I’ve read so far this year, CEO Ben Horowitz describes what he calls “The Struggle.” His point is that every entrepreneur starts a company with a clear vision for success but then things never go as planned: products have issues that are hard to fix, the market isn’t where you thought it was or has dramatically shifted, employees are losing confidence and either leaving or soldiering and, most dramatically, sales aren’t what they were supposed to be.

Suddenly, you’re running low on cash, your backers tell you it won’t be easy to raise more money and then… you lose a loyal customer (this is more or less where Phil Jenkinson starts his lean journey The Gold Mine). Horowitz tells us: “The Struggle is when you wonder why you started the company in the first place. The Struggle is when people ask you why you don’t quit and you don’t know the answer. The Struggle is when your employees think you’re lying and you think they may be right. The Struggle is when food loses its taste.”

The Struggle might sound hyperbolic but one thing I’ve learned about working with CEOs over the years is that I’ll never want to be a CEO because they all of them go through The Struggle at some point – regardless of how well they’ve done the job. In many ways it’s precisely The Struggle that defines them as CEOs as it defined their company for the future. So, sure, you can ignore The Struggle, but then, as Deming once quipped, no one has to change, survival is optional.

Lean Lessons for CEOs

Lean is great because it teaches CEOs to face The Struggle by (1) being better ready for it by struggling a bit every day – a well trained army is much better prepared to face battle than a lazy one and (2) by teaching to face it with others and not on their own. Certainly the CEO needs to protect their employees from the stress of The Struggle, but by learning teamwork and kaizen, many aspects of the hyperbole go away. Horowitz breaks down the job of CEO in two terms:

  1. Knowing what to do (sometimes in situations of extreme uncertainty)
  2. Knowing how to get it done (leading other so the company performs even in tough times)

Lean has a very unique way of addressing these two points. First, by getting people to conduct kaizen on the gemba every day the CEO builds a careful, progressive understanding of what the company’s real challenges really are, from customer response, to tech mastery to supply chain footprint and partnerships. Genchi genbutsu with the view to clarify challenges through exploratory kaizen is a very powerful way to discover what needs doing as opposed to expecting to wake up one morning with “the vision” for the company.

Secondly, precisely because of the involvement of all people all the time in practicing kaizen and drawing standards, performance is built in the lean method. Involving every employee in the dynamics of improvement is precisely what gives the company its performance. It is also a great generator of morale when done well, as employees develop greater confidence in (1) the competence of their executives, (2) their ability to do the day to day job and (3) their abilities to face new problems.

From that perspective, one key to understand the power of lean practice is that it turns The Struggle in caps into the struggle in lower case. Rather than fight alone with impossible situation, the CEO learns to be less of a providential leader and more of an adaptive one: working with others to adapt the company by continuous small steps every day rather than through large reorganizations, M&A, and all the usual tools of the CEO toolkit.

Executive’s Role

Yet, let’s face it, this only works if the spirit of the struggle remains – watered down certainly, piecemeal, absolutely. But constant nonetheless. A key TPS tenet is that no process is ever perfect so there is always room for kaizen. In practice, this means that as an executive it’s an important part of your lean role to point out:

  1. In what specific way the process is not perfect (point out the waste)
  2. Ask “why?” for deeper causes to avoid knee-jerk reactions
  3. It’s the responsibility of the people who run the process to improve it (with management support)

This, on the gemba, remains a struggle no matter how long and how well we’ve done it. And by the way, if sometimes the struggle disappears, it’s a sure sign we’re no longer asking the right questions. So yes, the struggle is part of lean and the only thing to do is, as I was once told in the UK: relax and enjoy your problem(s).

 

Are computer screens okay for visual management?

June 4, 2014
Back to top

Dear Gemba Coach,

Can I use computer screens for visual management or is that a big no-no?

No problem at all. I’ve seen some great visual management examples on screens, and I use screens myself, particularly as a quick way to set up andon boards. But it’s a good question, and there is a definite reluctance to use virtual stuff in lean – and with good reason. To go into this more deeply let’s take a step back and consider what we mean by “visual management.”

Management, in the lean context, has a very specific definition: developing the business by developing people. In operational terms, this is expressed in terms of solving performance problems on the gemba by reducing skill gaps. The aim of visual management is to:

  1. Visualize the performance gap concretely where the problem occurs in the process.
  2. So that the corresponding skill gap can be observed and discussed.

The first topic of visual management is safe vs. unsafe: can we see at a glance whether the work can be done safely or whether there is a risk. This, of course, if not always obvious, particularly with ergonomic problems – are you sitting at a safe distance from your computer screen? Is the screen set at a safe luminosity for your eyes? Are screen and chair at the proper height for your back and so on.

Trying to visualize safe vs. unsafe immediately raises the question of how much we know about the topic? I, for one, would not be able to answer the previous questions precisely, and will certainly look into it more deeply. In this case, a cursory check on the internet didn't help much – so my own skill gap is now obvious.

The next topic is ahead versus late: can every team member see at one glance what is their hourly plan (or daily or weekly plan in the case of project work) and whether they’re ahead or behind? The three typical tools we use in lean are:

  1. A shop stock of finished product so that each person or team own its own production until the next step in the process comes to pick up what they need just-in-time
  2. A queue of kanban cards to visualize how the products picked up by the customer will be reconstituted in the order in which they were taken (and what special orders need to be made)
  3. A production analysis board (hour, target, actual, comments) to see whether work is happening at the target cycle time, faster or slower, and why?

These three elements are essential to visualize (1) gaps with delivering to (internal) customer demand just-in-time, (2) gaps with takt time and (3) gaps with target cycle time. These are physical features that would be hard to have on a screen.

In this case, for instance, screens are not necessarily a good idea. One sensei I know was telling me recently of being shown a screen to visualize the process flow plugged into the MRP: the data was visualized as waiting time at bottlenecks. As proud engineers showed her the system, she pointed out that, at one of the bottlenecks, the display showed 40 days of backlog.

The obvious question is whether one should put one’s energies in resolving the backlog problem rather than creating computer graphics. The bias to physical visual system is helpful there because 40 days of kanban cards would immediately call for attention and create tension in ways that no number on a computer screen can create. Similarly, large batch overproduction that won’t fit in the shop stock will create a clear and present problem that has to be dealt with, whereas information on a screen about semi-finished parts in the inventory is easy to live with without much strain.

Physical and Visual

The physicality of visual management is what generates the creative tension to observation and problem solving NOW! The physicality of visual management is also what creates a common space so that both team members, front line managers and executives can discuss the problem hands-on until they agree on the very specific skill that needs to be developed in order to solve the problem, and the appropriate kaizen effort to do so. Computer visuals are far less intuitive and immediate – they display a situation but don’t call for action.

The third large topic to visualize is quality gaps. This means that:

  1. Quality issues have to be spotted on the part before passing it to the next step
  2. Team members must be able to call out every time they have a doubt with about the job.

Ideally, physical poka-yoke should block bad work from happening, but in many processes, there is no simple of doing so, and we need to rely on electronic devices and screen visualizations. Originally, andon boards were hardware flashing lights, but increasingly it’s a lot easier to use a large screen.

The risk, however, with such screens is that management tries to display far too much status information. An andon screen should be as simple (and stable) as your car’s dashboard. The point of the andon board is to point immediately to the area where the problem is occurring so that management can go and see the issue first-hand.

And therein lies the rub with computer screens and why lean practitioners tend to be rather doubtful about their use. Lean management, as we’ve seen is about observing firsthand performance gap and discussing the situation with the people who do the job about the skills gap until ideas for kaizen emerge to train people by problem solving. These discussions can be quite challenging, particularly if the situation is unclear and every one is making different assumptions. The “visual” part of visual management is about making the process so intuitive that all involved – team members, front-line managers and executives – can see the same thing and share their understanding. In lean terms, we see together, so that we know together, think together and act together.

3 Roles for Visuals

Technically speaking, good visual management has to perform three roles. First, it has to be actionable (yes, I know, ugly word), which means that it has to take the ambiguity away from the workspace so that the next step is obvious to everyone. I’m just back from a distribution center where they have prepared a row of pallets, but without any indication of which goes where – every time there is ambiguity, people stop in their tracks and risk making the wrong choice.

Second, it has to correctly frame the issue: good visual management is about seeing at a glance the difference between OK and not-OK. The white line on the road tells you the difference between driving on the right side of the road and being on the wrong side. Visual management should make you pick up that you are in an abnormal situation without having to remember or think about it.

Thirdly, visual management has to provide what we sociologists call “social proof” – a confirmation that every one sees the situation in the same way you do (which of course happens if you correctly create actionable situations with the right frame). Social proof is critical in lean because every one’s default mode is “if it ain’t broke don’t fix it,” and then “you’re crazy to want to try and improve this.”

Good visual management makes the problem obvious to every one, so that attempting to resolve the issue meets with group approval rather than rolled eyes and resentment. Highlighting problems is one challenge, making people want to resolve them a bigger one.

As with road signals, a clear, intuitive and habitual visual set up makes people feel more confident about what they see and more relaxed about the situation – a good visualization of the process reduces a fair bit of the stress of having to face up to the problems it highlights. The more physical and obvious the visualization, the easier it is to grasp intuitively for any one, the easier it becomes to think of kaizen ideas.

Displaying Info vs Visual Management

What about computer screens? Well, there’s nothing wrong with computer screens in themselves, other than the bias towards information display rather than actual visual management (as in the case of the system displaying 40 days of backlog without anybody caring.) Computer systems have the further drawback (from the lean point of view) of rigidifying the process -- once it’s coded in, fat chance to improve it --  whereas, as with everything else in lean, visual management continuously improves. Indeed the goal of continuous improvement … is continuous improvement.

As Dan Jones recently heard from the CEO of an IT company showcasing his pen-and-paper obeya, some decisions are too important to computerize. Using screens to further visual management certainly makes sense in some cases (imagine airports without screen flight displays), but make sure you’ve fully stabilized the physical visual management and pen-and-paper tracking before coding it in. Visual management is a specific lean skill, and as such has to be honed over many cycles, which is much easier to do pen and paper than by going straight to the computer screen.

Could you clarify the difference between cause and root cause?

May 29, 2014
Back to top

Dear Gemba Coach,

Could you clarify the difference between cause and root cause?

Good question. A common starting point for lean at the workplace is to set up a “customer wall.” Every customer complaint will be logged (internal customer if it’s a department) in the following format:

Date

Problem

Cause

Countermeasure

Status

 

 

 

 

 

The point of the this tool is not to prioritize the 20% of complaints that make up 80% of the problem as management theory would have us do, but indeed to investigate  every complaint and our immediate response to it to learn to listen to our customers better and to map the organization’s knee-jerk reaction.

For instance, I was recently at the gemba in a service sales office where customers regularly would not accept the invoice due to differences in price calculation. What the board listed as a cause was “error in calculation” line after line and then “explain to the customer” line after line. This is not unusual as, at first, the people living with the problem daily don’t understand what we’re after and fill in the flipchart with how they see the problem.

The first coaching step is to clarify what we mean by “problem” in the lean context:

            A problem is a gap in performance caused by a gap in process

The First "Why"

In practice, this means explaining that many of the “causes” appearing in the cause column are really part of the description of the problem. In the present case the problem would be “the customer challenged the invoice because of an error in calculation.” The cause column is there to understand why this error occurred.

“Aha!” people then say: “we’re looking for the root cause, then?” Not at all, we are indeed looking for the proximal cause, which is the response to the first “why?” In our case, we would have to work with the person establishing the invoice to write in the Problem line that “the customer refused to pay the invoice because a disagreement in how the work hours were counted” – the cause has to be specific enough to answer the question “what happened?”

The second difficulty is that the usual answer to the first “why?” is “someone screwed up.” This is probably the case, if the process wasn’t followed properly it is likely that someone screwed up – but that doesn’t help us very much. If we ask people to keep a long list of how they’ve screwed up, how likely are they to become engaged with the tool? The trick here is to ask “why?” not “who?”

The “not guilty” assumption means that what we’re after is why someone screwed up – we assumed that everyone is trying to do a good job (and, yes, sometimes this requires militant belief in people) but that something happened to confuse them or distract them and as a result they didn’t do what they meant to do. What we’re looking for in the first why is how the work process is ambiguous, confusing, or too difficult to handle so that people’s response is not good enough – in other words, we’re looking for specific causes of muri – overburden.

In day-to-day work, people routinely act on specific cues, but when suddenly given an unclear choice they first stall and second choose without much thought. This is a normal human response, and it happens to all of us, from the guy filling in customer invoices, and then the error is an irritant but not tragic, to the lawyer taking the case through the wrong process and then the mistake can cost the company millions. The point is that human beings are simply not designed to deal with sudden ambiguity in routine processes – the mind boggles and then jumps to conclusions, mostly wrongly (there’s a reason the process is suddenly ambiguous).

The first cause is about saying out loud what happened to muddle people. It’s about specifying the obstacle the person encountered that made it hard to get the job done right – and thus led to a customer complaint. Usually, the first why highlights a design flaw in the process – and middle management starts getting testy about it.

First Cause, Not the First Thing

As the team continues to fill in the board and examine every cause of customer complaint what typically happens is that 1) customers complain about a wide variety of things we didn’t think mattered to them and 2) some complaints come back repeatedly.

The wide variety of complaints is a good opportunity to draw again the four following circles:

  1. What do customers ask us to do?
  2. What do they really use of our work?
  3. What do we want to do?
  4. What would our environment like us to do?

Just to realize that our understanding of our product and/or service is much sketchier than we thought and constantly in flux.

The repeated complaints are a good opportunity for kaizen – let’s crack these one by one. What we’ll typically discover is that when you ask the second “why?” everyone and his pet raccoon has an opinion, none of them validated. One way to clear the board is to group causes into Manpower, Machine, Materials, Method, but still there are many. It’s a difficult moment because teams are then tempted to argue it out and pick one cause on the basis of who’s the smartest, or who yells loudest, or which one is “obvious.” This is a time to be rigorous and create a second format:

 Cause Hypothesis

 

Impact

Confirmation method

Confirmed Yes/No

 

 

 

 

Asking why? And why? Again only makes sense once the main factor has been empirically assessed. If not, as veteran TPS sensei used to tell us back in the day, your “5 why?” technique is likely to be all over the place: the better defined the starting point, the more likely you’re to actually hit on a real cause.

What’s a “root” cause then? I don’t believe it’s ever been defined, or that any cause can really be root enough, still, personally, I consider that when we hit the calculation that caused the problem in the first place, it’s pretty root. I buy into Roger Martin’s view of knowledge as first myth (unsubstantiated opinions), then heuristics (empirical rule of thumb) and finally algorithm (a calculation somewhere). Personally, I find quality problem solving starts getting interesting when we involve engineering (or whoever design the technical process) and challenge their models.

More often than not, there is a calculation somewhere in the model that works fine in most conditions but not in the specific one that creates the problem. If we reach calculation level in mental models, in my experience, we can actually affect outcomes long-term. It’s not easy, though. The main difficulty is keeping every one motivated to continued seeking until the problematic model or procedure is unearthed, and that can only happen through teamwork.

To sum up, first cause is not the first thing that comes to mind, but the specific factor that we can empirically prove causes the main part of the gap between where we are and where we’d want to be. This is nowhere near root cause, it’s just the starting point (think of it as getting a judo black belt being the first belt, not the end of white, yellow, orange, green etc.). Causes start being “root” enough when we find the calculation or procedure that caused the entire situation in the first place. Not for the faint-hearted!

What's the main quality I should look out for in hiring a lean coach?

May 14, 2014
Back to top

Dear Gemba Coach 

I’m in the process of hiring a Lean Coach for my team and I wondered if there was any one quality I should look out for?

Curiosity. Your question really threw me off my stride. My first reaction was persistence. And then I thought “open mind,” because this is certainly key as well. Then I listed all the great lean coaches I’ve been privileged to meet over the years and the one personality trait they all shared was … curiosity.

Your fascinating question touches upon a deep aspect of lean, and one that is extremely hard to convey. I remember one of my sensei describing a gemba visit with his Toyota sensei. The plant manager is desperate for help on reducing costs on one of his cells –-if he can’t find a way to do it, corporate will take the cell away and transfer it to a low cost country.

“What is your quality like?” asks the sensei

“Quality is fine,” answers the plant manager, “we’re under 8 ppm” (8 bad parts per million, incredibly good)

“Ah,” answers the Toyota sensei, “this means you must have very few defects.”

“Yes, yes, quality is not the issue, cost is killing me though.”

“So these defects must be very interesting,” continues the sensei. “Could you show us your latest defect?”

This exchange sums up one of the key misunderstandings of lean thinking. The aim is not to get the results: the aim is to learn. And results are the only real-life test of true learning.

Bottom-line level results derive from improved capabilities on critical topics. Fixing the immediate problem is interesting only inasmuch as it leads us to confront deeper skills gaps and to enhance what we know.

Why, Why, Why?

This comes down to a fundamental motivational issue. If your goal is to solve your immediate problem, your search for information and ideas will be limited at the first “why?” Lean thinking is all about asking “why?” again and again until we not only discover how to countermeasure whatever is happening now, but better understand the deeper boundary of knowledge, the grey area where what we know and what we don’t know blur. The only thing that takes you there is curiosity.

In visiting suppliers to Toyota, I’ve witnessed many examples where the problem has been solved but Toyota engineers keep nit-picking and asking for parts and testing stuff until they’re satisfied that they understand what happened. This is very frustrating for the supplier as they feel the problem has gone away and they have many more other issues to work on. Why is Toyota being such a pain? They’re just curious, that’s what. First true “why?” starts once the countermeasure is in place and has worked. The First PDCA cycle is but the beginning. “Why did the problem occur in the first place?” is the truly interesting question.

Typically, companies don’t hire lean coaches for their curiosity. Lean coaches are sought out for their mastery of the lean tools and their (perceived) ability to get things done. It’s hardly ever said at the individual level, but the underlying question is “what is the return on investment on a lean coach?” The question never asked is “what is the cost saving of a mistake avoided?” or “what is the benefit of an innovation?”

Hiring lean coaches to fix operational problems will not, cannot, improve competitiveness. The company’s processes are perfectly adapted to its current level of performance, and hiring people to make sure these processes work as is, as opposed to challenge and explore them is a sure way to … not get very far quick.

The eternal hiring question is do you hire skills and instill attitude? Or should you hire attitude and teach skills? Obviously, this is a chicken-and-egg question. Without enough prerequisite knowledge of tools, how can we evaluate the person’s attitude towards solving problems? And, conversely, even the best attitude can hit the barrier of too high a skills gap – too much to learn before being effective. So we look for an attitude/skill compromise:

  1. The attitude to understand that the aim of kaizen is not just solving the issue but deepening the person’s own understanding of their own job – as close to basic physics principles as we can – and increase their knowledge.
  2. The skills to figure out which tool will best help the person to learn in which case, and how each tools applies differently in different cases. For instance, Kanban in a machining area will work on the same principles as Kanban in a software design office, but many practical aspects will differ considerably. Regardless of form, the skill is to see that the tool does what it’s expected to do, as opposed to be forced on to people regardless.

Curiouser and Curiouser

Curiosity is often seen as a distraction to efficiency. A curious person is likely to get lost in unexpected details, to get side-tracked by what is considered a side-issue, to make unconsidered changes to basic tools so that they no longer perform as they should and to spend far more time on a problem than is considered sensible. On the other hand, the curious person is also the most likely to put their finger on the breakthrough that will fundamentally crack the problem.

A current myth is that discoveries are happy accidents – they happen through serendipity, mistakes, errors and dumb luck rather than by research. Be that as it may, discoveries also happen to people who have devoted their life studying a subject. Sure, the answer is rarely where we look for it. But we’ll only recognize the answer if we’ve been searching for it for a long time. If we’re still curious for the answer.

The choice is yours: effectiveness or efficiency? Ask “why?” or fix the problem? Develop a kaizen mind or improve processes to reduce cost? The selection of a lean coach really depends or your own take of what kind of lean you’re after. Do you aim to help line guys learn to better solve their own problems? Or have you sold a lean program to your CEO and do you intent to roll it out no matter what? Who you hire, in the end, will reflect as much on what you intend to do as to who they are.

I want to apply lean to engineering. Any thoughts?

May 4, 2014
Back to top

Dear Gemba Coach
I am the regional manufacturing VP of a large industrial company. After the latest reorganization, engineering now comes under me. I’ve had good success with lean in manufacturing and want to apply it to engineering. I plan to get engineers to solve production problems faster. Any thoughts?

I completely agree with your goal. One of the uniquely “lean” aspects of lean engineering is greater teamwork between engineering and production – indeed, it is a distinctive sign of lean that the plant is ultimately the measure of all things. The peace of mind of both customers and producers is what we seek, and both are tightly linked. Indeed, if I had to sum up years of practicing lean with CEOs at the full company level, I’d say something like:

Using pull and stop-at-defect to surface good VA and VE problems to improve product design and develop people’s skills.

Value Analysis problems are those we find in products being currently produced, whereas Value Engineering problems are issues we can solve at the design stage, mainly from previous value analyses. Typically, by looking at customer complaints, final inspection and flow we will discover that some products in our range work better for customers and are easier to assemble than others. Main reasons tend to be:

  • Fragile aspects: some dimensions of the product that don’t resist well to real customer usage, and customers do rather unexpected things with products in real life.
  • Difficult assembly: if some aspect of the product is difficult to assemble, chances are some assembly won’t be done well enough, and chances equally are this will slip through inspection control, as the assembly will be standardized.
  • Borderline manufacturing processes: when solving engineering problems engineers are often tempted to stretch known solutions to dicey conditions. This can work on paper, but in real production conditions the odds are that the manufacturing process won’t be robust enough and create both rejects and defects in the final product.
  • Supply Chain surprises:  without close relationships with suppliers it’s often hard to know what exactly goes into the parts they provide at tier 2 or tier 3 level and sometimes quality causes are hidden deep in the supply chain and hard to get to.

 Engineers Are Just Different

At the gemba, what we do is look at red bins in the process and discuss with engineers as to whether the problem is one of:

  1. Operator difficulty: is the gap in assembly itself, and why?
  2. Process problem: is the machine part of the process not performing as we hoped?
  3. Design issue: is the part as we’ve designed it difficult to assemble or difficult to make?

Experience shows that as we solve these problems with engineers, one by one, as they appear on the shop floor we discover issues no one had taken seriously before and sometimes it takes us deep into the very theory of how we make the parts. Working from the pull,  flow is essential because it prioritizes engineering problems in terms of what operators stumble upon and not what engineers would like to work on. In this sense, I think your goal is exactly a lean one.

However, and I realize I need to eat my hat by hearing me say so, it’s not so simple because we have a professional culture issue. Yes, yes, I know I’m the guy who’s been ranting that culture is a red herring and not a working concept and so on, but there it is. Engineers are simply very different from production guys.

I’ve learned the hard way at the gemba that involving engineers in solving operators’ problems is very, very difficult – and for some very valid reasons. First, engineers are typically already overloaded by their current workload, so it takes a strong managerial push to get them to take the time to interest themselves in what can be found in the red bins. Secondly engineers tend to think long thoughts, they think across weeks or months, whereas production guys are all about solving problems right now and then moving on to put out the next fire, it’s very hard to talk across different timescales. Thirdly, engineers tend to think in terms of the following mental cycle:

  1. Understand the practical problem
  2. Frame it as a theoretical problem
  3. Solve it in theory
  4. See how the theoretical solution can be applied in practice

Whereas production people tend to go from 1 to 4.  They don’t much care about the theory as long as the problem goes away.

What Is Product Development’s Job?

What it comes down to is that at the outset, it’s extremely hard to interest engineers in production problems – they have neither the patience nor the inclination, and many will actually feel threatened by the nuts-and-bolts, grease-and-grime aspect of daily life on the shop floor. The current generation of engineers, in particular, has been brought up to see themselves as on-the-screen designers and not failing 1,000 times before finding the right filament to make the light bulb work type of engineers.

The upshot is that I’ve found that in order to coach engineers to involve themselves with good VA or VE project you’ve got to start with a fully “engineering culture” lean program as well, to create a context for engineers to find their bearings in lean before, in the end, bringing them down to the customer gemba or the shop floor.

One of the best ways to do so in my experience is to start with Durward Sobek and Allen Ward’s groundbreaking Lean Product and Process Development, second edition, book and to set up an engineer’s program based on the key idea that Development’s job is to create operational value streams. In practice, what I’ve found works quite well is:

  1. Reaffirming the job of chief engineer for each product
  2. Creating a visual product launch plan to see ahead/late for each new product
  3. Asking the chief engineers to write a two-page concept paper for his or her product, detailing customer segment, customer value, what functionality will be in the product and what won’t be in terms of performance, main techs, milestones and milestones management plan, and unresolved technical issues to explore before starting the project.
  4. Conducting target cost exercises
  5. And doing various teamwork workshops throughout the project life, such as tear downs, upfront problem solving, A3s, slow builds, 3P and so on until launch.

Re-Focus on Customers

Many of the engineers I come across are hampered by a very narrow definition of specs. They’re told it’s marketing management’s job to write up specifications, and they will design to spec. As a result they loose the “engineering” part of their job – they see themselves as delivering designs, not performance. This is a very hard nut to crack because the whole engineering management system often locks them in this position with brutal gate reviews, design reviews, and all sorts of tick-the-box activities that make sure the deeper questions are never asked.

On the other hand, I’ve found that once you’ve interested your engineers to what the product does for customers, once the discussion is back on to product performance and price, the engineers typically will follow through in production – after all, they are long thinkers, and when grabbed by a topic, won’t let it go. They’re engineers!

To answer your question directly, I completely agree with your aim, but I’d be a tad careful about how you go about it. I’d start with a lean development project that focuses on creating discussions about customer value and how we aim to deliver that (a formal way to do this is through QFD, but again, this requires some maturity) to involve engineers and create teamwork, and then progressively bring them to the shop floor to understand real-life issues. With engineering, it’s more important than ever not to try and force engineers to do anything (if you do, they’ll simply do it badly), but to involve them progressively in seeing that customer problems and operational problems are just as interesting as the problems they themselves prefer.

Why do you lean guys always focus on shop floor processes? The lack of clarity and focus at headquarters is far worse! As a plant manager, I feel I’ve solved most of the issues our lean coach keeps badgering me about, why don’t they go and kaizen head office instead?

April 21, 2014
Back to top

Now, that is an interesting question. There are so many issues there, it’s hard to know what comes first. Let me start by saying that I feel your pain – I see this all the time. Let’s see if I can partially answer your question.

It’s not easy to be a plant manager. Daily life is about:

  1. Getting production out
  2. Fighting all the fires burning because of problems arising from our own lack of process mastery here and there
  3. Dealing with all the nonsense requests from headquarters

Few human beings know how do deal with more than seven issues at the same time on their mental desktop – okay, maybe nine. Beyond that, whatever new file you put on the mental shelf makes another one fall off. This simple cognitive constraint has two very large consequences:

  • A lot of operational managers simply get bogged down with issues – like cars on a freeway, at a certain point of saturation, traffic just jams, and this definitely happens to operational management teams;
  • Operational managers make (often implicit) choices about how they select issues – it turns out that some of these choices are self-defeating. If you do follow all the headquarters instructions, you’re bound to fail. If you fight headquarters too hard, you will succeed, but they’ll be hunting for your scalp, and any moment of weakness will be used against you. Tough call.

Lean Obsessions

I vividly remember discussing lean with a pharmaceutical management team in Denmark – the operations VP clearly saw the sense of improving safety, quality, delivery, flexibility, and productivity, but, right there in the room, all his functional colleagues: the IT lady, the quality guy, the finance guy, the HR lady started arguing why it would be a terrible idea. Their argument was that they already had systems in place to deal with issues and the main problem was that operations was not implementing the systems rigorously enough. The CEO listened to the majority view and the operations VP had to bite the bullet.

The problem, of course, is none of the systems pushed by the functional directors are actually there to help you produce value. Because of our Taylor/Ford/Sloan legacy, each functional director’s job is to put in a system to reduce costs. The quality director wants to reduce the cost of non-quality (what is that?) the IT director want to optimize the flow in current conditions, the purchasing director’s bonus is tied to his price coefficient and so on. There not there to help you create value – their career hinges on convincing the CEO that their system contributes most to the company’s cost saving efforts. If the CEO hasn’t seen the lean light – that’s that.

The difficulty is compounded by the fact that in too many case the “lean” director operates exactly on the same premises. He or she has to proved that her system – a “lean” one in this case – will most contribute to cost savings. Which is why your plant get swamped with lean headquarters guys with three obsessions:

  • Productivity kaizen on lines
  • VSM to fix your “value streams”
  • “Savings” workshop where they see an opportunity

So yeah, chances are that as an operational manager, the lean program coming to your plant is not there to help – it’s designed to force you to make the headcount reductions your senior management is convinced you have underfoot but don’t want to make. To be fair, in totally non-lean plants, this can actually benefit the plant in the first two years by forcing plant management to see its low hanging fruit and actually realize some obvious improvements. But the story gets old very quickly.

Program Pushers

Which gets us to the third issue – lean consultants you’ll meet are not likely to be very good. For the past 20 years I’ve worked with lean programs in the mid term – the longest I’ve seen is twelve consecutive years, but on the whole, I’ve been counting and I follow through a specific program for four to six years, by which time there’s a management change (Senior exec retires, company gets bought up, etc.) that stops the lean effort as the new guy is clueless and wants it all the way it was before. In that period of time, I can see firsthand that the issues in year four are very different than those in year two. In year six, many of the problems we face are quite deep engineering problems, both in terms of product quality and equipment flexibility. The goal posts move, which is a healthy sign that we’re actually doing lean since the goal of lean is… continuous improvement.

In the process, I’ve witnessed a fair share of headquarters sending in lean consultants to tackle issues that had never been solved, but taken on board by line management for a few years now. This is an interesting problem as, clearly, no line is perfectly level, no operator does 100% value-added work, but after the first few workshops, there is no know way of going beyond other than involving every one every day in kaizen, which means, andon, suggestions, and a lot of frontline management care.

In this situation the new consultant comes in, measures cycle time variation, or counts inventory buffers, and decrees that there is much progress to be done – we can all agree on that. When asked how, the issue becomes trickier because the obvious problems have long been resolved and the consultant is stumped. Many frontline managers are actually working with their teams and engineering at solving these issues at this stage, but this is a messy kaizen process that, unfortunately, the new consultant simply doesn’t get. AND he or she can’t go back to headquarter empty handed – looks bad – so they’ll sing a song about resistance to change and whatnot.

Your question has no obvious answer because of deep, deep problems at three levels:

  1. As long as the CEO doesn’t take a monozukuri (making the right products the right way) and hitozukuri (developing people in an atmosphere of mutual trust) attitude, the balance of power in any senior management team is biased towards program pushers, not value creators. The point is every one wants innovation, but every one hates innovators. Functional directors tend to support the ideologies of their functional specialties rather than the needs of delivery process to actually deliver more value.
  2. The lean initiative director is probably part of the problem more than the solution since his or her career depends not so much on helping the business grow its market share and generate cash, but in implementing a program that will deliver savings where all his or her colleagues have failed in the past. This programmatic lean has little more than its name that is lean, but that’s still what many senior execs buy from consultants – it’s such as cash cow because that’s what leadership asks for.
  3. The consultants in a lean programmatic approach are not likely to be very good at actual kaizen support. Their job is to force standard techniques onto operational managers to prove that further productivity can be squeezed from operations if only you have the will to do so. This works well for the first two years, as a wake up call and clear-the-window practice, but it’s a plain pain in the neck after that when what the plant really needs is a kaizen approach based on respect for operators and leadership from line management.

What can be done? I’m sorry to say that I have no advice at this point – I’ve certainly never convinced a senior manager that hadn’t first convinced himself or herself. The frustrating part of this is that we all know how to generate superior performance. Senior management has to approach work as an athlete and not an administrator. Athletes look at real performance, not effort. Athletes are coached, and the higher the competitive level, the more coaching they look for. Athletes practice every day in order to compete. Athletes understand that the goal posts move that the status quo has to be challenged every day.

Lean is not for every one. Lean is a method invented for the few senior managers who are serious about adapting their organizations to the crazy changes in the markets we’re living through today, and doing so with their people and not against them. This takes a special type of person. Can lean be done at headquarters? Sure, but headquarters has to want it first!

What is the worst mistake you’ve made on the gemba?

April 10, 2014
Back to top

Dear Gemba Coach,

What is the worst mistake you’ve made on the gemba?

Yikes. Worst mistake? Tough question. I guess the obvious answer is being too tough at times and not enough at others. Getting people to change is difficult because in order to really change, they’ve got to go through a period of discomfort as they try to adopt new behaviors and abandon old ones. Sometimes, you’ve got to push them hard into the pool – others you’ve got to stop and listen and hold hands. There’s never a good balance, or at least, I have never found it. On the one hand what you tolerate will continue, on the other hand when some people get really pissed off they can hold long grudges which come back and bite you. But I suppose this doesn’t count as a mistake as such, more something I’m not very good at and a constant topic for kaizen – the balance between strong mind and warm heart. 

Actual mistakes that have slowed the pace of progress are harder to spot – it’s difficult to see yourself work – but, upon reflection, I can guess at two mistakes I’ve repeatedly made: one technical, one political.

My greatest technical mistake is not spending enough time on the product/process matrix. In most situations I’ve seen, from production to service (it’s actually much worse in service), the product/process balance is deeply built-into the organizational structure. When I first started lean, sensei were adamant on flow when you can and pull when you can’t. That meant we created cells wherever the cycle time was not too different from takt, and then dealt with capacity equipment when cycle time was at least an order of magnitude faster than takt.

Our main tools to get started were the spaghetti chart and the flow chart. Over time these were replaced with value-stream mapping, which shows another vision of the plant but tends to hide the diversity of products. When you strive to create continuous flow cells, you actually have to go through the hardship of clarifying the product/process matrix. There are four keys to understanding mura in the process:

  1. Complex flows
  2. Large batch sizes
  3. Not enough will to adjust production rhythm to sales rhythm
  4. Poor supply logistics

By tackling the complexity of flows and stabilizing which product is made on which equipment we usually find a gemba key to address the other issues. On the other hand, without tackling this upfront, even if we make progress on the other subject, the people on the gemba can’t find their autonomy in handling products and so the instability remains as spot decisions hinder as much as they help.

In many high-mix low-volume environments it’s easy not to devote enough attention in stabilizing product groups, and in service environments in many cases the question is not asked at all. Working on the product /process matrix long enough to sort it out is key – but hard, and as I look back I’ve definitely missed a trick or two there, at a much larger costs in terms of performance improvement overall. In terms of inventory turns, the larger benefits come from component inventory reduction through milk runs and so on, but this, in turn requires a detailed understanding of fraction-mix decisions at the production scheduling stage.

Don’t Ignore Naysayers

My worst political mistake is rather different in nature, but probably more costly in the long run. In any lean initiative, at the management level there are those who help and those who hinder – it tends to be as simple as that. Help with what? On the gemba, getting closer to monozukuri through hitozukuri:

  • Solving product/production problems for specific customers
  • Through developing people’s skills in an atmosphere of mutual trust.

You get there through kaizen, but kaizen requires the proper questions asked, which involves quality, just-in-time and jidoka. In organizations, this bothers many people who have far different agendas. Typically, the purchasing manager is largely evaluated on the price reduction he or she gets from the supply base, and arguing that suppliers should deliver good parts on time makes his or her job harder, not easier. In fact, if the purchasing manager takes on a cheaper supplier with lower quality, they get the bonus and the plant manager gets the hassle. I’m not saying all purchasing managers think that way, and indeed, I’ve worked with some excellent ones who “get” the quality and lead-time issues. Al I’m saying is that you’ll always find some people in the organization who simply don’t see it the lean way because it doesn’t suit either their goals or their style.

The mistake is ignoring them. When lean works, first it delivers results in terms of cash and performance and second it keeps you rather busy. The tendency is to focus on the people who are willing to teamwork and kaizen and ignore the rest. This works great because by creating a team of people committed to improvement, you get spectacular results, but it also fails because the others can gang up on you – I’ve seen this happen time and time again, and, at certain points in decision-making have enough influence to kill the improvement effort. To be fair, their argument is that their way to improve is more effective and we should stop this people-coaching stuff and do more systems-implementation stuff.

The hard point is that it’s very hard to get teamwork from someone not doing kaizen on their own, because every weakness you’ll expose will be used against you. I’ve just lived through this as the commercial director of a company refused to see the problems he was creating by inflated pricing and crazy 80% discounts through promotions and such, which completely screwed up the demand signal, and kept arguing that what destroyed the OTD was none other than the lean effort. Ouch. Every time we tried to get this guy onboard, he used the information shared about what production did not know how to do (and needed sales help) against the COO. Not fun.

The temptation then is to let well alone and stop talking. I’ll get on with my stuff, you’ll get on with yours. This rarely ends well, because at some point some real crisis will come up, and if the next level up in the food chain doesn’t deeply understand lean and realize what is going on, the naysayer can sometimes win the day through sheer Machiavellian politics. We don’t like to consider this, but some people, particularly at corporate do make a career of blame politics, and lean guys are simply not equipped to deal with that as their attitude is to be open about one’s problems. The tough challenge thus is to keep talking to theses guys, no matter how irritating, aggravating and occasionally dangerous it is. Stopping communication gives you a respite for a while, but I’ve often found it kills you in the end.

Continuous Challenges

Product/process understanding on the technical front and not dealing well with adversaries on the political front would definitely be on the top of my personal list of mistakes. In the end it comes down to pretty much the same thing. By the very nature of continuous improvement, lean continuously challenges the status quo, and sooner or later is going to step on the toes of someone of the big-system-solution persuasion rather than kaizen with all people all the time. Results help, of course, but it’s surprising to see how little results count as an argument in a purely political food fight. I’ve seen very senior executives throw away millions in cash (literally, millions) to implement their favored form of centralized supply chain, centralized IT system, financial control, purchasing strategy and so on. Their arguments are always the same: no pain no gain, we’ll get the returns later on and better a tough solution now than this endless small-step continuous challenge nonsense.

The conundrum remains: we need results now to be convincing, but this means pushing people hard and making enemies. We need to work with people and connect to their interests and let them find their own footing, but this slows down getting results and opens flanks to the real enemies (which we often don’t see clearly because we’re not talking to them, but they talk to the CEO). No easy answers, but that certainly keeps the job interesting!

We’re being audited on five levels on fifteen topics. I feel that if we actually worked on all these items, the plant would just stop working. Am I missing anything?

March 27, 2014
Back to top

Dear Gemba Coach,

Our facility is being rated on a “lean maturity” audit. We’re being audited on five levels on fifteen topics, each having multiple sub-topics. I feel that if we actually worked on all these items, the plant would just stop working. Am I missing anything?

Unfortunately, probably not. Still, it depends, as audits do make lean sense in certain circumstances. I’ll come back to further down. However, if your company is anything like many of those I know, these audits are indeed complete nonsense. Worse, as you suspect, if execs take them seriously, they can be seriously counterproductive and damageable to the plant.

First, where do these lean maturity audits come from? I’m not sure who started this, but I’ve been seeing this sort of thing ever since the lean word was coined. Managing-by-objectives is basically about (1) establishing goals, (2) establishing plans to reach these goals and (3) making sure plans are carried out and goals are reached. Nothing outrageous so far, except, of course that reality exists and reality resists. So, when goals are not met, leadership creates new jobs in order to make sure the plans are followed. This, in turn, tends to generate new goals and new plans, and requires more control and so on.

For instance, say your plant has poor quality results and that quality actions are not paying off as hoped for. It is very tempting to create a Total Quality department that will make sure every quality procedure is followed to the letter. This will (1) improve quality short term – as Is get dotted and Ts get crossed and (2) stop any further possibility of quality improvement. By burdening the process with all quality procedures, it becomes very difficult to figure out what exactly was going wrong and identify the real critical-to-quality parameters.

Furthermore, quality is customer specific. The head of the new Total Quality department is there to have a performing Quality Control system, not to care for customers. Chances are he will be very resistant to the idea that different customers have different preferences in terms of quality (which would be a huge challenge to his job as opposed to rigorously applying all procedures all the time). As a result, for a small quality improvement, we have now burdened the plant with additional costs and limited its scope for growth. This plant will not progress beyond this plant, and will in all likelihood tire of the rigor soon enough and slip back to where it was with the added costs firmly set in.

Give Up on Assessment?

Lean is far worse than quality in this respect because it has so many dimensions. Should lean maturity be about leadership clarity? Or about 5S rigor? How about problem solving proficiency? Or reaction to problems? And so on. We’re not dealing with one thing here, but, as you’ve said, ten, fifteen, twenty “core” aspects of lean. In this sense, lean is the wet dream of any systems artist – they’ll come up with the best possible evaluations schemes and win PowerPoint presentation prizes.

There are structural reasons lean doesn’t measure well on any grid:

  1. Lean is about improvement: The sure test of lean is that the goal post has changed. There is no reason to think goal posts will changed in a predetermined way. The whole point of lean is getting the company to face its challenges and to balance care for today with care for tomorrow. Maturity, such as it is, is in the capacity of recognizing, acknowledging and facing one’s own challenges – so how could any external auditor have any sensible opinions about that?
  2. Lean is a system: To perform the various elements of lean have to work together. Perfect flow without jidoka is unlikely. Jidoka without pull also. But could be possible as well. As in any system the link that matters most is the weakest at any given time. Consequently, lean progress is more one of “punctuated equilibrium” than an action plan to roll out. Lean breakthrough on any single one of the lean principles changes how all the other work, and thus changes the problem.
  3. Kaizen is customer specific and operator centric: Two cells in the same plant could well has improved well and reached apparently opposite solutions. Senseis don’t say it depends to frustrate you, but it really depends. No evaluation audit can ever capture that.

Should we give up any assessment effort then? No, of course not. Performance can always be assessed, and benchmarked. For instance, when practicing lean at division level, all sites are evaluated real time (or as real time as can be, which is usually monthly) on basics such as:

  • Safety
  • Quality
  • Delivery
  • Inventory
  • Productivity
  • Cost
  • HR development
  • New project introduction
  • And so on,

But this, again, will depend. For instance, in service activities, quality in terms of complaints hardly captures either churn (the ratio of lost customers to total number of customers) or Net Promoter Score, so the list of performance measures will vary according to what the site is doing. But performance can, and should, be measured.

Sites can be compared on their performance ranking as well, but what we’re really looking for is progress. For instance, we’ll ask a site that has had no lost time accidents last year to start measuring near misses. A site with 99% OTD performance will start measuring missed deliveries per million (99,5% on time delivery is 5000 MPM). As a result, on a chart benchmarking several sites, a site can be good in terms of results, but “red” (poor) in terms of progress.

Maturity Levels

“Maturity” in gemba terms, has to do with the ability to self-reflect and develop this in others. If push comes to shove, my criteria of maturity (so far) would be:

  1. Level 1: we’re so good at this, look we’ve done all these great things!
  2. Level 2: we’re overall okay but have got some specific issues here and there
  3. Level 3: we’re doing well at some things, but are really poor at others, some of them we don’t really understand
  4. Level 4: we’re doing well at some things but have identified some huge, messy, dicey areas we need to be good at and we’re trying very hard but have only just started
  5. Level 5: we have some big challenges we don’t fully understand, but we’re confident that if we all work together people will come up with innovative ways to address these

Maturity has to do with the ability to see one’s own strength and weaknesses, build on one’s strengths and address one’s weaknesses. Having an andon chord in place doesn’t do any good if people are reluctant to pull it for fear that it will reveal problems (it would get a good mark on the audit sheet though).

Why do people spend so much energy in such silly endeavors? Ultimately, I suspect that we’ve all bought into Taylor’s mechanistic view of the world. There is a platonic “perfect” process we seek, and all should be made to ascribe to it. Not surprisingly, some people resist this idea thinking that human beings should be free from any form of process at all (which is means remaining in the Taylorist paradigm, but fighting it). Toyota taught us that there is no perfect process, and there never will be.

If I look back and remember what we were taught by the old time senseis when working on problems, I’d say that lean is neither mechanistic nor anti-mechanistic (I mean, the discipline of standardized work is real), but organistic if there is such a word. A new plant grows from and older plant, itself the daughter of a mother. A coach is taught by a mentor, who also has or had a sensei. A technique is evolved from another. Indeed, Toyota Motor Company grew out of making automated looms. The underlying vision is that leaves are born by branches growing out of trunks drawing on deep roots. Everything has a developmental history.

If I may be fanciful here, kaizen is about cell evolution: replication with mutation. The speed of kaizen is the speed at which every cell renews itself, just as the frequency of parts train is like the blood pumping through the plant’s system. An organism is neither mechanistic nor random, it is organizes organically. I am in no way suggesting that any organization is a living organism, just that the metaphor, the image for the organization is one of a natural cycles. As a point in case, Akio Toyoda’s 2008 vision was about drawing cycles of industry closer to cycles of nature.

In that sense, maturity would be about growing from a new born leaf to a thickening branch, to a deepening tree. Maturity would be about your chain of sensei and, at some point, your chain of deshis and where your tradition fits in with other lean traditions. I doubt any one will make an audit sheet out of that!

Why do the characters in your books struggle a lot with lean?

March 18, 2014
Back to top

Dear Gemba Coach,

I’m new to lean and I’ve just finished reading The Gold Mine and The Lean Manager and enjoyed them thoroughly – thank you. I do have a question: the characters seem to struggle a lot, and there’s a lot of conflict. Is that always the case or is it in there to make the books more interesting?

Thank you for this question, it has really given me pause. I’ve thought about it and, agreed, no two lean journeys are the same. Some are so conflict prone that people give up; others are fairly smooth and good fun. What Freddy and I try to capture with the business novel form is not just a manual for doing lean (although, most certainly the books are that) but also the “feel” of doing lean. We believe this important inasmuch as learning and understanding are two different things. The deep learning question is should you be content to change your understanding, and in this case a manual is exactly what you need, or should you aim to change your behavior and in which case other dimensions, such as the political context and the personal fallout need to be looked into.

How does learning lean feel? From my background as a cognitive sociologist and years coaching executives on the Gemba, I’ve cobbled together a four-step model (I had big words in mind, but I like your notion of “struggle”, so let me try my hand at a 4-S modelJ): Situation, Search, Struggle, Satisfaction.

  1. Situation: learning doesn’t start in a vacuum, but someone in a given situation feels compelled by either necessity or personal interest to seek to change this situation. In many cases, we’re quite satisfied with the status quo, so the situation can be pretty dire. Also, not every one will see the need for change in the same way, so context really matters. Are we facing a type-I problem in which it’s a matter of applying better a known solution, or are we in a type-II case of an adaptive problem in which we need to seek an altogether new approach?
  2. Search: once motivated (literally, put into movement), the person will then enter a search phases of inquisitiveness, (limited) curiosity, and looking for a fit-to-situation answer. This is usually rather fun and interesting because we all love exploring new stuff and changing our understanding – it’s changing behavior we find painful. So there definitely is a think… think… think… phase until one path of action becomes clear and…
  3. Struggle: the person then enters the struggle phase. As soon as action is involved, obstacles will appear, and many of those seem quite insurmountable. Conflict comes from the fact that some of these obstacles will be people (and not always the ones you think). Basically the change is smooth until someone gets in the way and then, bang, conflict – so yes, conflict is pretty typical of change. The deep question at the struggle phase is whether the person commits to persevere no matter what, or gives up and looks for a new interest somewhere else.
  4. Satisfaction: there is a deep and lasting satisfaction at mastering something new. Humans are profoundly tool users, and handling the correct gesture, mastering a new set of skills with a new tool is deeply satisfying, as is the feeling of getting results from having overcome the obstacles and pulled through. Deserved success makes you feel really good about yourself.

 

Real Lean vs Fake Lean

The odd thing about lean is that as an overall approach it tends to keep you in the struggle phase more than any other learning method. The moment you set up a pull system with an andon, problems keep coming and keep coming – of all sorts. Some problems are of getting new people on board with countermeasures we’ve experimented elsewhere and some problems are simply new. Actually, a good sign that lean is working is that you keep uncovering problems you didn’t know you had. The self-reflective element of a lean culture is a large part of what makes it work over the long term, and a sure way to distinguish “real lean” from “fake lean.” But, consequently, you’d better get use to the feeling of struggle if you want to do lean for real.

The struggle part comes essentially in two forms: feeling stumped or conflict. Feeling stumped feels like being a prehistoric ape watching a wheel turning and thinking “it turns, but how?” In many cases the lean tools lead us to understand a problem much better but still see no practical way to solve it. This is a specific feeling of hitting one’s head against a brick wall, and takes some getting used to. When it happens to me (which is frequently), I take it as a good sign because it means the problem is real. At that stage, take easy, focus on special cases and try small stuff. As Daniel Kahneman pointed out success is largely a matter of talent and luck. The way to be lucky is to try many different countermeasures, hope that you were talented enough to try smart ones in the process (you never know which) and wait for something to unknot itself. It usually does.

Feeling stumped is something of an acquired taste, and hard to share with others. One of the difficulties of real lean is sharing this tendency to pick at problems with others who seek quick solutions to be able to move on. They can easily find you annoying for picking a wounds rather than just shutting up and getting on with… the situation as its always been. So the first cause of tension is to establish that feeling stumped is a normal feeling, and although frustrating, not necessarily a negative one. Feeling stumped also means fail fast, fail early: creating an environment where you can fail at solving the problem until something unravels and a solution emerges. It takes a special kind of patience, and persistence to try and see, try and see.

Real Change

Which brings us to conflict. Change, real change, often requires a sacrifice. In order to do adapt, you typically will have to abandon a practice that has worked well for you until now. A clear way of seeing this is when you get promoted. Ever step up the ladder increases the political dimension and say you’ve been promoted for your ability to get things done, suddenly the success skill is striking deals with allies and enemies – radically different. Chances are what made you good at getting things done, being a straight shooter and energizing people will make you a liability at the next level up. And so on. Lean change does bring that kind of change, often, when you need to abandon a deeply held belief to progress. Indeed, the first twenty pages of Taiichi Ohno’s first workplace book are about accepting that about half of what you think is false and the need to root out these “misconceptions” as well as admitting them to others. He knew what he was on about, and yes, this is a real struggle. We have to learn to be comfortable with “I was wrong, I’ve changed my mind.”

Worse, the sacrifice might be asked of others, to whom it can be intolerable. Several of the executives I’ve worked with on the Gemba already had a lean program in place with a lean guy doing lean stuff. They sought me out because they weren’t satisfied with it. Whatever the local lean guy was doing was perfectly adapted to the results they were getting, which his CO wasn’t satisfied with. So the lean guy will, unavoidably, have to change his practice. I can think of a couple of cases where we got lucky and the lean officer was really keen to learn and change. But I often come across lean guys who want to hang on to their practice and are unwilling to sacrifice what they know of lean (as in, there is more to lean than VSM, for instance). Next, it gets worse. As you start implementing the pull system, you logistics director will realize his or her practice is about to change radically and many of their reflexes are anti-lean. An on it goes. The quality director doing an excellent job at auditing and maintaining the various accreditations the company has is not likely to be the most adapted to an andon system where we need to react to every operator doubt within a work cycle. You get the picture.

Yes, struggle is inherently part of doing lean, and you need to get comfortable (or not too uncomfortable) with the feeling. If, right now, you’re not feeling stumped, feeling that you have to sacrifice a practice or belief, or have not realized you’re unwittingly asking such a sacrifice from someone else, you’re probably not doing lean in earnest. And this is definitely a feeling Freddy and I have brought to the novels. The gun-to-your-head feeling of needing to change, the frustrating feeling of trying to change and not getting it, and the conflict of coming across people for whom the change involved is (understandably, not blame involved) simply too much to ask.

What about satisfaction? Well, all the people I know who’ve discovered real lean (which usually means sticking to it beyond the first couple of years) don’t look back, and don’t relent. The satisfaction is rarely on the spot (because we’re usually in some form of struggle or other) but it feels great to see results improve, to feel the camaraderie of working as a team and more than anything else, to see people blossom and grow.

Lean is not mechanistic, but neither is it craftsmanship. If anything, lean is organic. We watch a pull system grow from a sapling (pulling the first high-runner) to a mighty tree that encompasses the whole plant. We watch people grow as they learn first to take on the challenges imposed on them by the method and then discover their own challenges and develop self-reflexiveness as we give them space to think. We watch companies grow by growing both customers’ and staff’s satisfaction, and to be honest, this feels great. And after a while, we get a real kick of discovering yet another layer of problems on the Gemba – it’s like an adventure at work, every day.

The Gold Mine and The Lean Manager, as well as the next installment in the series, Lead With Respect were written by Freddy and I to share the experience of learning on the Gemba with a sensei, with people doing lean who haven’t had the luck of coming across the old time Toyota senseis. The conflict and struggle in the books is not made up (if anything, it’s toned down). Lean learning is learning from solving real world problems. Change is not easy as the A of the PDCA leads you to Adopt new practices and Abandon old ones (Adopt is much easier than Abandon). Our intent in writing the books is to share experience of learning to change behavior, not simply understanding, and we hope we succeed in conveying this – struggle included.

I’ve heard you say the quality department is the worst enemy of quality. I find this offensive.

March 3, 2014
Back to top

Dear Gemba Coach,

I’m in the quality department of a large company and I’ve heard you say quality is the worst enemy of quality. I find this offensive, but I’m willing to keep an open mind. How would you back up such an outrageous statement?

Oops! That does sound like the kind of things I would say, so first of all let me apologize if I’ve given offense. I do get carried away as I try to make difficult points and I’m in no way suggesting that people in quality departments do their work wrong or are disengaged – not at all. I don’t know in what specific context you heard me say this, but usually what I have in mind is a more fundamental point. Please bear with me as I try to explain, and, please, again, accept my apologies if this has hurt feelings in your department. Let me backtrack some.

Yesterday, as I came back from a plant with the COO and the lean officer of an industrial group we sat down in a café to have a beer before waiting for our respective trains. As we’re about to order, the waiter asks us to move to a table further inside the restaurant, because he had to set the tables close to the window for dinner. The waiter was denying us our preference for a table by the window for the sake of this own process. This example might seem mundane, but, to me, it has profound implications:

  1. First, by adhering to the process in order to support efficiency and quality this bar has lost three customers – we won’t go back.
  2. Second, the waiter wasn’t responsible in any way – he was told to work this way, and embarrassed about it. By imposing such as silly process on him, his manager was taking away the deeper meaning of waiting on people: being a welcoming host. The waiter was reduced to a pair or arms doing the job, suffered friction with customers and lost a tip (okay, after we discussed it, we tipped him anyhow, but grrr!)
  3. Thirdly, as long as the process doesn’t acknowledge the variety of customer preferences, there is no hope for kaizen.

The jury is in, the verdict is read: quality is the key to profitability. In an influential article, HBR authors Raynor and Ahmed conclude from their statistical study of thousands of companies that there are three rules for making a company truly great (http://www.thethreerules.com/ ):

  1. Better before cheaper
  2. Revenue before cost
  3. There are no other rules

In a similar vein, the in-depth study of the PIMS database for over 30 years from Robert Buzzell concludes that the one thing to emerge from the data is that (http://www.business.ulst.ac.uk/intlbusiness/courses/bmg900m1/PIMSReview.pdf ):

  1. Market share drives profitability
  2. Perceived quality drives market share

Where’s the Beef?

All well and good. What’s my beef with the quality department then? The problem is in “better” and “perceived quality.” For many years, we’ve obsessed (rightly) that quality lay in consistency. Nothing wrong with that; one of Deming’s core lessons. But, if we’re not careful, consistency can easily split into “single process mentality.” As team members explained to me on the shop floor just last week, if you want us to be consistent, let us build just one product. To be fair, as we all looked at what they had to go through to shift from assembling product A to product B, we got their point.

The simplest way to deliver consistency is to educate the customer to fit within our (consistent) processes. Unfortunately, in this day and age, this is also the surest way to enrage the customer.

As 2.0 is spreading through all aspects of our lives, immense choice and personalization are now the rule. Customers like things just the way they like them. And, sure, they’re inconsistent – aren’t we all? I can guiltlessly blame a favorite shirt brand for changing a minor thing on the shirts I usually buy as well as berate them for not carrying the exact new model I suddenly fancy.

Our organizations, from the design department to the quality department are set up to deliver on specifications. engineering builds to specification, quality makes sure they’re enforced. Engineering tries for specifications that will satisfy the largest user base, but that’s precisely the problem. Specifications are only the entry ticket – not the sale. Sure, all cars need to respond to safety, performance, and style specs – but is that why you pick a Toyota over a Nissan? A BMW over a Merc? A Chevy over a Kia? This is not about functionality but taste: preferences.

Responding to customer preferences without losing product or service consistency is a major headache. Most organizations simply don’t attempt to solve it. They just do what they do, and, as a customer, you deal with it or not.

Indeed, most bureaucracies treat their customers as alibis. Teachers treat kids as an opportunity to teach (have you noticed that when you try to talk to the teacher about your kid, the teacher explains about the class?), hospitals treat patients as opportunities to nurse (have you noticed that when you try to talk about your grandmother, they explain about the ward?), and so on. Quality departments treat people and products as the opportunity to maintain and defend processes.

Let Me Explain

I never meant that quality departments are the enemy of quality in their terms – of course most quality departments fight for the rigorous adherence to process. But that’s exactly the point. As they drown engineering and production in processes, they burden the company with an added layer of costs (how much does it cost to obtain a quality qualification?) to the detriment of flexibility and following customer preferences. Yes, I understand that variability makes it harder to maintain consistency – no one is arguing against that. But that is precisely the job. How do we maintain consistency and flexibility?

This can’t happen through a quality specialist department. It has to come from the value-adding team members themselves. The waiter needs the flexibility to let three tired, bossy middle-age men have a beer just where they want it as they want it, as well as setting up tables for dinner. Such flexibility can’t be obtained without deep team member engagement, just as one-product-batch on the line can’t be obtained without working steadily with the team members themselves to make the product change easier in a way that they own the flexibility and are proud of it.

I’m sorry if I’ve expressed it tactlessly, but the point remains. Is the mission of the quality department to support value-adding team members in catering to customer preferences as well as product consistency (which, yes, it’s hard) or is it the mission of the quality department to make sure the existing processes are respected, regardless of what happens at the sales point? Is quality defending customer preferences? Or is quality using customers and operators as an alibi to do quality? These, I find, are deep fundamental questions about the nature of the firm and how well it performs on its markets.

If you are certain that your particular department is fighting for customer preferences every day (did you defend a customer preference today?) and for the engagement of team-members in greater flexibility (have you contributed to energizing team members on flexibility today?) then I’ll admit that my remarks are out of place. Gladly. But, if on the contrary, you have found yourself telling value-adding employees that their work is to conform to the quality system then I stand by my words – no language is strong enough to wake up companies to the true meaning of perceived quality. Better means better for customers, not better for quality departments.

If I turn off MRP in favor of kanban, will the factory collapse around us?

February 24, 2014
Back to top

Dear Gemba Coach,

Our sensei wants us to turn off the MRP and work with kanban cards. I’m really nervous about this. We’ve been doing a lot of problem solving, but I’m not sure we’re ready. Any insights?

Oooh, scary moment that! I’ve been there with many plant managers and indeed, we keept our fingers crossed hoping the factory won’t collapse around us as we switch the system off (it mostly doesn’t). The answer is it depends. I don’t know what you’re specific situation, but let’s look into it step-by-step from the gemba.

First, do we agree it’s the scheduling function you want to turn off. MRP is essential to handle the bill of materials and send orders to suppliers. So we are talking about the scheduling of production modules, aren’t we? There is really no sense in scrapping the MRP altogether, we want to better leverage it, not fight against it.

Second, let’s take a step back and look at the larger picture. MRP is not an issue in itself, nor, to be honest is kanban or level pull. The challenge is just-in-time. Problem solving is well and good, but without a constant tightening of your level of just-in-time (reducing the water in the lake) you don’t have a handle on:

  1. Whether this is an interesting (high pay-off) problem to solve or a side-issue
  2. Whether your countermeasure makes sense or not

Every company works at a its level of just-in-time. Just ask yourself:

  1. How long does it take to respond to a customer, and then to get the service or product to them?
  2. How long does it take to manufacture a specific item (not take it from the finished goods stock) once production has the customer order in hand?
  3. How long does it take for suppliers to deliver a specific item after you’ve ordered it?

Whatever these numbers are, whether weeks or days, cut them by half and ask yourself: what would this company look like with half the total lead-time?

Giving Team Members Responsibility

Clearly, this is not going to be a walk in the parks and if you attempt it, you will have a set of problems to resolve one by one – rework, flexibility and so on. This is IT. This is how you lean a business. And, experience shows that in the production part, doing so with kanban cards is a lot easier than with the MRP.

Kanban cards shift logistics responsibility from a central function in IS to the team member himself or herself: they produce the parts in the order that is needed (much like the cook in a restaurant makes the dishes in the order the orders come in) and they order material as they consume components (every time they start a new box, they take the kanban card and mail it to be resupplied). Because they now own the function, kaizen is a lot easier as team members understand why they need to reduce batch sizes and make sure the first part is a good part and so on.

If you’re considering taking the plunge, I’m assuming you’ve got supermakets (shop stocks to be precise) at every one of your production cells and that the team members in the cell own this production. If not, do take a deep breathe and think again. Now, walk to the shop stock, pick up a finished part and ask yourself:“what happens next”?

When the MRP is driving the place, the answer is often … nothing. Eventually, the product will be logged into the system, which will recalculate need according to how much it believes customers will want, how much it’s got in inventory, how much safety you’ve told it to have and so on. Then it will produce a production order, which will be transmitted to the cell. Team members have a sheaf of production order and build them as well they can.

With a kanban card, the story is different. When you pick up a finished part, the card attached to it is returned immediately to the production queue (okay, if you’re batching, there’s a bit of skullduggery going on with batch – building boxes to recreate batches by clipping several kanban cards together in the queue). But the point is that you can visually track the information flow:

Withdraw a product - send the card back into the queue - produce a new one of this item

By making the system visual, team members can spot all the glitches and you can support their kaizen efforts in very specific ways. You don’t pick the problems, they reveal themselves to you one after the other.

From Kanban to MRP

Of course, I’m assuming here that the customized part of the product is at the end of the assembly flow, because this only works with a finite number of variants. If you fully customize every product, you might indeed want to use the MRP as long at the batches are for one at a time (which makes sense with high customization).

To be honest, it really depends. Last time I visited a Toyota plant, I found out they no longer used kanbans for suppliers, but, in this particular plant (every Toyota plant I’ve seen does things differently) they had the MRP pull on suppliers. Now, the lead-time being half a day – this was almost indistinguishable from kanban cards. The issue here is not the technique as a production system, but as a learning system. Your sensei probably feels you need to work with physical kanban cards for a while to progress and learn (having the cards circulate makes it a lot easier to see the problems and kaizen). Don’t be surprised if you revert to MRP after a while – it just won’t be the same MRP at all.

Kanban cards are an essential tool of kaizen, a point many people who try to computerize the kanban system completely miss (might as well learn to use the MRP to reduce lead-time). Kanban are useful insofar as we can, in Taichi Ohno’s terms “see with our feet, think with our hands” because the team members themselves own their logistics tool as opposed to a central IT specialist tool. Our purpose is to raise productivity and quality by invigorating employee morale, through engagement in problem solving in their area!

I don’t find much about lean strategy in the literature. Where should I look?

February 10, 2014
Back to top

Dear Gemba Coach,

I’ve been tasked to come up with a presentation on what is a “lean” strategy to our Strategic Planning Group. I don’t find much about lean strategy in the literature and am stumped. Where should I look?

Thank you for your question, it certainly gave me pause. The truth is I don’t know either. Now that Toyota is numero uno again, the question doesn’t come up so often but through the years of studying lean, the company has been continuously disliked by financial analysts for its absence of clear strategic planning, or indeed its lack of communication of its strategic intent. Several years ago, I asked Toyota executives what the company’s strategy was and the answer came down to, in one form or another, “kaizen.” Not very helpful – how can kaizen be a strategy?

An interesting book to read on the topic is Osono, Shimizu and Takeuchi’s (of knowledge-creating company fame) Extreme Toyota. The authors claim that Toyota’s success is not built on a clear strategy but, on the contrary a set of paradoxes, deep contradictions that, in their terms push the company to extremes and keeps it on the edge. They’ve narrowed down these contradictions to the six following points:

  1. Moving gradually and also taking big leaps
  2. Cultivating frugality while spending huge sums
  3. Operating efficiently as well as redundantly
  4. Cultivating stability and a paranoid mindset
  5. Respecting bureaucratic hierarchy and allowing freedom to dissent
  6. Maintaining simplified and complex communication

Paradoxes as Strategy?

Having visited Toyota sites around the world over the years, these “contradictions” do speak to me inasmuch as I’ve never been able to see twice the same thing. On one hand the company will do a lot of kaizen to shave a second from a work cycle and on the other there are coordinators and staffers and lots of people at lots of meetings everywhere.

Stability is a constant obsession and so is the feeling that Toyota is permanently failing and not doing what it should.  I’ve seen cases where the company is tight fisted to the point of penny pinching and then willing to lavishly spend on other things. Last time I was in Durban, South Africa, I was struck by the efforts Toyota made to teach its team members to drive (many didn’t) to get them to understand how it felt to own a car, as well as a huge investment in their own container storage area above the Durban harbor because they felt service from the port was too slow. And so on.

This flies in the face of the “clarity” proponents of lean, the “North Star,” “Clear Direction” (and I half-heartedly include myself in that group) because it certainly has not been my direct experience of observing the company from the outside (maybe things are incredibly clear inside, but I somehow doubt it). Does that mean there is no such things as a “lean strategy”? Surely, paradoxes can’t count as strategy, can they?

Well, one thing we know about the company is that is isn’t afraid of very bold moves to capture customers, such as creating a fully fledged luxury brand (unheard of) with Lexus, and did the same to capture young drivers with Scion or to attack head-on the impossible goal of the clean car, revolutionizing the industry in the process. There has to be some strategic thinking there, right?

Let’s go back to the gemba. I recently visited an independent automotive supplier specialized in roof windows who had just succeeded in selling a project to a top-of-the-line German OEM (pushing out their traditional German supplier) as well as a Japanese manufacturer. This is of strategic importance to this company because it opens new markets of higher value products (and a chance for long-term growth.) Another company makes automotive springs and they’ve been having a hard, hard time since the Lehman Brothers crisis, but at now bouncing back (ha ha!) thanks to a non-automotive construction contract they obtained by focusing narrowly on delivering on time every time.

The first company convinced higher-range customers by the intent of their customer focus through the application of lean engineering tools such as immersion and customer preferences identification. The second branched out of its traditional market by using a pull system and learning just-in-time discipline.  Was it strategic? Or simply opportunistic. Operational improvements open doors we didn’t know were there and new opportunities arise. Better be lucky than good any day.

The Strategic Planning Bias

Choosing your customers is probably what lean strategy is about. Most strategies are “market” and “resources” based. What markets should be pursued to maintain growth and profitability and what can we actually do with the resources on hand. As Roger Martin explains in his Jan-Feb 2014 HBR piece on “the big lie of strategic planning”, no matter how glorious the strategic planning seminar location and how groovy the interaction, strategic planning’s built-in bias is to keep the management team in its comfort zone. Real strategy, the author claims should feel uncomfortable. “Focus your energy on the key choices that influence revenue decision makers — that is, customers,” he advises.

From this point of view, there is indeed a lean strategy:

  1. Focus on existing customers first – on your promoters. There is nothing more important than doing what it takes to convince an existing customer to repurchase, and be so happy about your product or service she or he will tell their friends about it.
  2. Look for customers willing to pay more for better – in order to improve revenue now, try to reach for upper range customers, if you can provide that extra value (or understand what really matters to them) they’ll pay for unstintingly simply because they’ve got the money to do so.
  3. Look for customers with new tastes or quirks. What do customers that don’t choose us prefer? Faster? Organic? Friendlier? Cheaper? Let’s look out for these and, if we’re lucky, find customers who wouldn’t have purchased the product at all but solved their problem through other alternatives.
  4. Take care of your new entrants. In Toyota terms, who wants to drive their parents’ car? In order to do (1) we have to get customers hooked into our brands, so what entry product do we have that is fun, sexy, cheap, exciting and so on?

You become the customers you’ve picked – it goes way beyond marketing. As you work with certain customers (and I’m not talking about segment, but individual customers), their values and quirks will inevitably rub off on you. Work long enough for a French automotive manufacturer as a supplier and you’ll start thinking that bleeding your own suppliers dry is the only way to stay profitable in the current market conditions. Work with a customer that accepts 0.5 percent of defects as inevitable and pretty soon you’ll wonder why your lean guy is loosing his or her temper all the time. You are your customers. Your destiny is their destiny, so choose them wisely.

It’s Kaizen

But how is it possible to choose one’s customers? Well, ahem, kaizen. Taking a page from Toyota’s book, the two companies I mentioned didn’t explicitly seek these new customers – they work hard at establishing kaizen within their own organizations. Then, suddenly, the improvements generated by the kaizen efforts opened up new opportunities and top management started thinking about what they could do to fuel and encourage this. Kaizen is the lean strategy.

This is the point Osomo, Shimizu and Takeuchi have made. In a mass-market industrial age, contradictions, paradoxes, opposites are seen as needing to be avoided. Think! The chaos, the duplication of effort, the confusion — shock, horror. But in the knowledge age, however, new knowledge appears when we reconcile our own unique perspective with those who disagree with us. They claim that “what differentiates Toyota from its rivals is its view of the factory worker as more than a pair of hands on the assembly line. Each is a knowledge worker who accumulates new knowledge through direct experience and interaction with others.

What Toyota is postulating is a new management model fit for industrial production in the knowledge age, where growth depends not only on operational efficiency but also on people and organizational capability. Toyota’s model represents a more human approach to industrial production because it positions humans, not machines, at the center of all things.” (Extreme Toyota, Wiley, 2008). Kaizen is the lean strategy.

In TPM, Isn't it needlessly costly to replace parts that are working fine? What do you think?

January 28, 2014
Back to top

Dear Gemba Coach,

I have a question about Total Productive Maintenance. My management has hired a TPM consultant who makes us systematically replace certain parts in our equipment even though they’re working fine. This seems needlessly costly. What do you think?

Ahh... I have to confess I’m not a TPM expert. My very first gemba workshop was a consultant-driven TPM workshop and it remains a vivid memory: picture a young theory of knowledge PhD. Doctoral student cleaning parts in the gut of a huge cold-stamping press. This was the start of my long love affair with the gemba, but, I have to say, not with TPM. I have come across several such programs since with varying degrees of results and so, again, I’m weary of general statements. In some plants I’ve come across, TPM has been hugely positive to get the guys to realize they have to take care of the plant and not just run machines (or people for that matter) into the ground and then replace them. Muri remains the first, and to my mind, most bitter waste.

Over the years, I’ve also witnessed how Toyota engineers helped their suppliers with machine uptime and machine upkeep. It turned out to be quite different, as you can expect, and, if you bear with me as I take a detour, I’ll try to describe the gap.

As a young social sciences researcher I was studying how Toyota taught TPS to one of its supplier. One Toyota engineer convinced me then that, in order to really understand what I was seeing, I needed to get my hands dirty and do some kaizen myself, and so I started helping out a shop floor consulting firm as an extra pair of hands to run their workshops – these were the crazy days of five-days full immersion events and moving machinery around on Wednesday night and hoping the plant would restart on Thursday because top brass was coming on Friday. Looking back, it was completely nuts (a big hello to those of you who still do that), but tremendous fun (for the consultants, that is).

Lean vs. Lean

This is when my research work became very, very interesting because I slowly realized that the “lean” (it wasn’t called lean yet) the consultants were doing and the TPS the Toyota engineers were practicing looked the same but were qualitatively different. As a sociologist, I had landed in one of these rather unique events: a paradigm shift. Paradigm is a big word to describe a set of thoughts and practices in a certain field at a certain time – for instance the Newtonian paradigm describes the world as clockwork driven by gravity, whereas the Quantum paradigm describes the world as, well, a weird incomprehensible place driven by quantum equations our monkey-brains can’t quite grasp. A paradigm shift is when the dominant worldview shifts from one to the other, and as worldviews tend to be “sticky” that doesn’t happen very often. I came to accept that I should not try to understand TPS through the eyes of other engineers, but seek out what was different, not similar.

Back to TPM. All TPM programs have the same goals: maximize equipment effectiveness through a system of preventative maintenance throughout the equipment’s lifetime. Basically, it’s about reducing down time, speed losses and defects. We all agree.

The way to do this in the traditional paradigm is through a maintenance schedule. You use the data you have on equipment breakdown to analyze the most sensitive parts and how long they last, and, much as with your car’s service, you plan the maintenance schedule of every piece of kit. In practice:

  1. List all the equipment requiring maintenance work
  2. Assign priorities (ha!)
  3. Estimate costs
  4. Create a schedule
  5. Make sure all the parts needed are ordered on time
  6. Implement the calendar and review failure data.

Sensible? Of course this is far from simple because equipment is rarely available when scheduled, maintenance is often organized by functional specialties (electricians won’t touch mechanics, etc.) and the maintenance guys are rarely free when scheduled and finally, well, breakdowns to occur and every one will be pulled in getting the machine back to work and there goes your plan.

I suspect that this is what the consultant you mentioned set up for your plant – a rigorous (and probably smart) schedule of maintenance and parts replacement that should, in theory, pay for itself in machine availability and OEE.

Autonomous Team Members

What I saw Toyota engineers teaching their suppliers was rather different. They weren’t looking to establish a schedule upfront (thought that did happen on some things). They were trying to solve three specific problems:

  1. How do we improve team member’s autonomy with the machines they handle?
  2. How do we treat each equipment as an individual?
  3. How do we free the maintenance department from as many things as we can so they can focus on rapid intervention and complex tasks?

To grasp how different this is, think of kanban. In the old paradigm, kanban is about replacing MRP with cards – essentially replacing one production scheduling system with another. People are obsessed with calculating the ideal number of kanbans, with seeing the full flow of kanbans in their VSMs and so on.

TPS engineers were trying to do something rather different: they wanted the operators on the cell to be autonomous as regards to their logistics. Team members had to be able to tell at any moment:

  1. What they were supposed to work on now (the current production kanban)
  2. What they would do next (the next kanban in the launcher)
  3. Order the materials they needed for the next hour of production (the materials ordering kanban).

The system had to work to make team members autonomous as regards their logistics function. When you think about, it this is quite an endeavor: simplifying the logistics function to the point that team members can handle it without it breaking their cycle by distracting them from their work (think about what happens when one has to decipher a production instruction order). The spirit of kanban is cell autonomy, and the fact that when kanbans fail, the cell STOPS, CALLS (through the andon) and WAITS (rather than start working on another part – overproduction).

The same spirit applies to maintenance: how can team members be more autonomous in handling their own equipment. Well, the same simplifying hard work needs to be done until regular maintenance can be done by the team members themselves without losing more than 5 minutes of production time per shift. On the gemba this appears as:

  1. Clearly indicated checkpoints on the cell to show what needs to be maintained.
  2. Easy maintenance activity with clear instructions (cleaning, oil lubrication, etc.- should be self-explanatory.
  3. Constant training and coordination with maintenance technicians to further simplify maintenance.

With this in mind, we can now build a profile for the machine according to their age – I remember in Japan a Toyota supplier where all machines had a large sign stating their age, a few going back to before I was born – and their peculiarities. The maintenance parts ordering system can now work just-in-time with:

  1. Current parts on hand in stock replenishment
  2. Some specific parts with one part in stock and immediate replenishment when used
  3. Parts that need to be ordered when needed, but with a clear identified supplier and a taxi system to fly them in quickly.

In this way, the plant learns to do what your consultant is trying to get you to do without carrying the extra cost that you have – rightly – noticed.

Machines Are Your Patients

In the end, maintenance will increasingly be about big data. Toyota veterans tell me that they keep historical information on all their important machines and they can compare performance across the group! Clever IT is definitely needed, but not so much on the scheduling front, but on understanding each machine as one would a patient and drawing the right conclusions for engineering to focus on: what do they need to strengthen in the process to avoid repetitive problems.

The deeper point here is about changing one’s perspective. The insight of lean is not to try to maximize the efficiency of the system at system level (no matter how consultants project this onto lean) but about developing the autonomy of team members and equipment by knowing them as individuals and training them one by one. In this, the lean ideal is indeed that of craftsmanship – the pilot in love with his 1930s biplane, the old car enthusiast – within the context of mass production efficiencies. We need to seek that space in all we do, including maintenance.

I recently had the opportunity to visit Toyota’s first historical plant out of Japan in Sao Paulo in Brazil, where they showed me a 1937 press still making parts for the Corolla, in mint condition. Now, that is TPM!

Why do you lean experts still revere the Toyota Production System? Hasn't any one come up with something better?

January 22, 2014
Back to top

Dear Gemba Coach,

Since Toyota formulated TPS 50 years ago, many other companies have come up with their own business systems – I have been taught the Nissan Production Way. Why do you lean experts still revere the Toyota Production System? Hasn't any one come up with something better? Is this just conservatism or ideology or do you actually have a reason to stick with TPS?

Wow! Bonus points for a challenging take-no-prisoners question! I have no direct experience of the Nissan Production Way but, having personally contributed to building several such systems in various companies, I think I understand where you’re coming from. If, in the same lapse of time, Microsoft has replaced IBM as a reference, Apple has replaced Microsoft, and now Google or Amazon are dethroning Apple – why wouldn’t the same evolution be likely in Production Systems? I’ve had to think carefully about this, and take into account that as one of the “you lean experts” I am probably biased, and as resistant to cognitive dissonance as the next man, so what is the test method that would make my answer valid and not just an expression of wishful thinking that TPS remains a gold standard for lean.

The question, as I grasp it is: what is so unique about the Toyota Production System that it remains a standard for lean as opposed to either more recent evolutions such as the Nissan Production Way or alternative directions such as Lean Startup?

First, let’s clarify what we’re talking about. There are many paper versions of the TPS mostly involving customer satisfaction, just-in-time, jidoka and standardization/kaizen in some order or other. Some versions include employee satisfaction and mutual trust, earlier versions have the twin pillars of just-in-time and automation with a human touch resting on the base of load-smoothing production, with respect for humanity in the center, and so forth. But to me these paper systems do not accurately describe my experience of TPS with time spent on the gemba with a sensei to look into the details of visualization, problem identification, and kaizen activities.

TPS is not something you know, it’s something you do. As Art Smalley translates, one of TPS’s principal founders, Taiichi Ohno describes it as “a series of related activities aimed at the elimination of waste in order to reduce cost, improve quality and improve productivity.” He explicitly states that it is about developing the scientific mindset of starting with actual phenomena of the shop floor and searching for root causes in order to solve the problem. This is rather specific and highlights the fact that the Toyota Production System is most definitely not Toyota’s system of production. Toyota’s production practices are the outcome of TPS activities, NOT TPS itself.

A System of Questions

Which brings me to what I still consider distinctive in TPS. To my mind, TPS is a system of questions supporting the essential gemba question of “why?” It’s not random questioning  and it’s nothing to do with applying principles, no matter how lofty. It’s a practice to teach you to ask the right question in specific circumstances. My way of reading the TPS “temple” would be:

  • What is our current level of customer satisfaction and how to improve it?
  • What is our current level of just-in-time and how to improve it?
  • What is our current level of jidoka in terms of how good are we at distinguishing OK from not-OK at every step of the process?
  • What is our current adherence to work standards and how much kaizen are we doing ?
  • How satisfied are our employees in terms of do they feel engaged in their work, involved with their teams and other colleagues, and can we develop higher mutual trust between employees and management?

As a system of knowledge, this makes TPS quite unique. Knowledge is not held in the form of answers such as “in this situation, to obtain this, do that,” but in the form of targeted questions such as “in this situation, to seek this, answer this question.” For instance, on the shop floor if you’re trying to improve flow, it’s very, very different to say:

  1. To improve flow the number of kanban cards in the system should be X

Or:

  1. To improve flow cut the shop stock in half

Both statements will lead to specific knowledge about the flow of parts, but in completely different ways and, in actual practice, to very different answers.

And a Hierarchy of Questions

I was recently asked for my opinion on a very elaborate IT system to run the shop through e-kanban – with significant performance improvement results – and I realized I didn’t have an opinion because my understanding of kanban is as a support to kaizen, not as an operational method to schedule production. To my mind, kanban is the ultimate tool to reduce the level of the water in the lake and make the problems appear, and then hit the problems with kaizen activities involving the people running production themselves.

It’s a system of questions inasmuch as there is a hierarchy of questions. For instance, how to improve the level of just-in-time? Say, from just-in-time within the week to just- in-time within the day, will then break down into: How to improve the level of load-smoothing? How to get batches closer to takt time? How to reduce the number of breaks in the flow (points where inventory accumulates)? How to tighten up the pull system?

Furthermore, it’s also a system inasmuch as the questions are interrelated: how is possible to do use kanban without identifying bad parts at each part of the process? How is it possible to improve jidoka without going to single-piece-flow? How can we maintain single-piece-flow and jidoka without standardized work? How can standardized work exist without takt or specifying the standard stock of 1 or zero parts? And so on.

Is this original? Yes, very. Maybe even unique. My background is in sociology and theory of knowledge and the most common take on knowledge is the so-called “tripartite” approach: since Plato we tend to see knowledge as “justified true beliefs”:

  • If one doesn’t believe a thing, one clearly cannot know it;
  • No matter how sincere or well justified a belief, if it’s plain wrong it cannot be considered as knowledge;
  • It’s not enough to consider intently that something is true, one also needs to have a good reason to think so – lucky guesses aren’t knowledge. Indeed, changes in justification systems have had paradigm-shifting impacts on what we consider to be true, from cave-man mysticism, to religion, to Newtonian science, to modern science, etc.

As a result, as far as I know, we tend to think of systems of knowledge as systems of answers. The knowledge management craze of the 1990s was all about making explicit every implicit knowledge, and capturing it in a computer. This probably happened in an unexpected way with the advent of the web where we now have access not just to one answer, but to any one’s answer with a strong enough opinion to go to the trouble of posting it.

What I haven’t come across so far is a system of knowledge based on specific questions. Science has clearly moved that way as modern scientists well recognize that facts have a half-life and that questions are more interesting than answers. For instance, we, as yet, have absolutely zero answer to the puzzle of where (or what) is all the dark matter in the universe but the question keeps motivating thousands of scientists and big money research programs. But in business thinking what is mostly on offer are systems of questions, complete with To Do lists and roadmaps – the lean movement has indeed spewed a few, and I’ve been guilty of doing so myself on several occasions.

Learning to Learn

Your question is very helpful in highlighting the profound misunderstanding of seeking answers from TPS if I’m indeed correct and what it holds is kaizen questions. This misalignment would explain many mishaps in the lean field. It would also explain why it is so difficult for “us lean guys” to implement John Shook’s vision of “learning to learn.” The hypothesis I’m proposing to you is that the key to learning to learn is not to accumulate answers (this is unavoidable, that’s how the mind works), but to become truly expert at what questions to ask.

Seeing TPS as a system of questions would also shed an interesting light on another puzzle I’ve encountered in 20 years of studying lean: how different Toyota plants are to each other. The main elements are there, certainly, such as the andon, the visual management, the precise internal logistics, but beyond that, each plant definitely has a personality of its own and many good practices of one won’t be found in the other and vice versa. Local answers to the same question will give similar, but differing answers.

Questions can be very powerful tools. For instance, one CEO of a high-tech company I know now uses the jidoka question of “what is your test method to determine the quality of parts I make for you?” as the basis of his discussions with his customers, which has greatly improved the quality of his exchanges with his counterparts (either they know and they see that he is serious about quality, either they don’t and that is a good contractual topic to start working on at the outset.) Questions also explain why standards are local, expressed in the form of trade-off curves and why standardization does not mean uniformization. The same question can have different answers according to what specific situation one finds oneself – industrial knowledge is far more specific than we’d think.

As a system of questions I believe that TPS remains unrivaled probably because no one else has quite looked at knowledge in this very unique way. Thank you again for asking this tough question, because whatever your answer is, it has certainly made me think long and hard, and I now look at many things in a different light. “Asking “why?” might go much deeper than I even imagined.

We struggle to set target conditions. Is there a system to do so?

January 14, 2014
Back to top

Dear Gemba Coach,

We work with Toyota Kata, which we find very helpful, but we struggle to set target conditions. Is there a system to do so?

First of all please bear with me as I go on a tangent – I’m not sure what kind of system you’re looking for? A systematic way of setting target conditions, as a formula? In many cases to understand something fully, we need first to backtrack to clarify our assumptions, or risk missing the answer in front of our very eyes. The very notion of “system” reflects how profoundly we are all influenced, even conditioned, by Taylorism.

Frederick Taylor’s intent is clearly stated in his introduction to Principles of Scientific Management in 1911:

We can see and feel the waste of material things. Awkward, inefficient, or ill-directed movements of men, however, leave nothing visible or tangible behind them. Their appreciation calls for an act of memory, an effort of the imagination. And for this reason, even though our daily loss from this source is greater than from our waste of material things, the one has stirred us deeply, while the other has moved us but little.

As yet there has been no public agitation for “greater national efficiency,” no meetings have been called to consider how this is to be brought about. And still there are signs that the need for greater efficiency is widely felt.

The search for better, for more competent men, from the presidents of our great companies down to our household servants, was never more vigorous than it is now. And more than ever before is the demand for competent men in excess of the supply.

What we are all looking for, however, is the readymade, competent man; the man whom some one else has trained. It is only when we fully realize that our duty, as well as our opportunity, lies in systematically cooperating to train and to make this competent man, instead of in hunting for a man whom some one else has trained, that we shall be on the road to national efficiency.

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

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

From Taylor to Toyota

Apologies for the long quote, but this is to show how much Taylor’s ideas have percolated within our culture – I for, one, agree with every one of his points, although maybe not with his extreme conclusion that the system must be first.

One thing Toyota has taught us is that it’s all about people! In one of the best illustrations of kaizen ever, as seen in this video, http://www.youtube.com/watch?v=EedMmMedj3M, a young lady who is part of the kaizen states her belief that “if you have a good system the work kind of takes care of itself”. This we ALL believe. But what actually happens in the video is much closer to Mike’s kata http://fr.slideshare.net/mike734/kata-walks than actually setting up a system – the team identifies a problem and then sets to solve it, and improves the situation by a multiplicity of small improvements and ideas – something the “system” would never give you.

In my experience, there is no systematic way of defining target conditions in any given situation – defining target condition is precisely part of the iterative work needed to do with the management and the teams to actually understand what the problem really is. There are, however, rule-of-thumb trick that can help in clarifying the target condition on the gemba.

I was on a gemba yesterday with the Ops VP of a service company as we toured kaizens. As we see in Toyota’s meal per hours clip, the discussions went back and forth on a number of topics:

  • What is the overall business challenge? What problems does the business need to resolve? In the case of the service company, one overall issue was tough market pressure on price, which made competition on quality even more of a challenge as the only way to preserve price was to demonstrate superior service as well as lowering costs. In the video, the challenge is stated as “having one last box and seven families to feed on the line – that kills me.” Then “I like to put smiles on people’s faces.”
  • What is the local problem you’re trying to resolve? In the case of the service company, these are missed interventions because the technician misses either a part or critical data. This is both poor quality and an cost overrun on operations. In the clip’s case it’s the number of boxes per truck against the demand from families. These are very practical problems that we call agree on.
  • How will you measure this problem? There, it often gets tricky. Measuring the problem is not the same as tracking activity; it’s measuring the gap between what we’d like and what we have. There is no set way to come up with a good measure, and it is part of the thinking to have the teams and management discuss back and forth until they can agree on a practical measure (it has to be practical or it won’t be used) that kinda sorta represents the problem. In service, it was counting the times the technician could not do the intervention. In the clip, the number of boxes in the truck, the time it takes to prepare the boxes and then the time it takes to hand them over to hungry families.
  • How do you go about solving the problem? This again, is not systematic, it’s about working out the causes, sometimes trivial, sometimes deep, or sometimes simply outside the box. This is where the “muda, muri, mura” or “waste, overburden and unlevelness” heuristic is so useful – these basic rules-of-thumb are prompters to look into what is going wrong and what could be fixed in very practical ways. In the service case, the un-levelness of the parts supply to the technician is an obvious culprit – then the overburden imposed on the system by unusual requests manually put in to the system, which screws up the operations and so on.
  • Did it work or not? Many problems have a marginally results curve – basically, you’ve found one cause, which delivers – say you’ve taken some air out of the boxes so you can now put more boxes in one truck – but at some point progress is stopped. What tends to happen is that the kaizen itself will have created new conditions which require new analysis. It’s tough for teams because they now have to backtrack and rethink their causal analysis to be able to go forward again.

Targeting Target Conditions

I agree with Mike in that there is not a formulaic way to solve any of theses steps, other than observation and discussion, and, to my mind, this is the great thing about lean – this is where you engage with people, and they engage with their work, this is the fun of creation and being human – it’s NOT a system!

Target conditions: well, once you have an agreed measure in place there is no system, but a few tricks:

  1. Target 0 or 100% - go to extremes: what would it look like to solve the problem completely?
  2. 50% improvement – when in doubt, always a good stretch target
  3. The best day every day: in every data set, normal variation shows good days and bad days. The best day every day is a reasonable target, and as things improve and we get closer to the best day of two months ago, luck will have it that a new best day has appeared and so on.

But none of this is as important as constantly picking on the fundamental question of: are we solving the right problem? Are we trying to improve something that should simply be eliminated? Are we fixing old solutions when we should be exploring new ones? I am currently faced with this issue often concerning the impact of Big Data and open source manufacturing on many aspects of every product. At the end of the day, studying the link between the practical actions of kaizen and the formulation of the larger challenges is the key to meaningful target conditions. It’s not a system, it’s a practice.

 

How does lean fit together with Lean Startup concepts?

January 6, 2014
Back to top

Dear Gemba Coach,

I work in IT and discovered lean through the Lean Startup movement – now as I read more about it I find that lean is about the complete elimination of waste. How does that fit together?

That’s a rather deep question, actually. Lean is the generalization outside of Toyota and the automotive industry of the Toyota Production System (TPS). Toyota Motor Company defines the TPS as a philosophy of “the complete elimination of all waste.” There it is.

TPS did not emerge fully formed. Taiichi Ohno didn’t come down from Mount Fuji with the tablets of TPS and its commandments of kanban. The system grew organically and without any specific program out of the problems Toyota’s engineers set themselves to resolve and their tinkering in resolving them.

Toyota’s original founder, Sakichi Toyota turned his back on the carpentry family trade (still in the days of samurai) to develop an automatic loom to save labor for women slaved to their traditional looms. Sakichi tinkered night and day with his looms to make them as good as British ones – not an easy challenge without an established industry to back him up.

In the process, he came to realize that if a cotton thread broke, the loom would continue to produce bad material until stopped by an operator. This was obviously wasteful, so he came up with the famous andon system – a mechanical device that stops the loom autonomously when a thread breaks.

As loom engineers (and Taiichi Ohno amongst them) tinkered with this idea, they realized that there was no need to keep an operator per loom and, in the 1920s hit upon the idea of saving labor by having one person run multiple looms.

A New Industry Loomed

About that time, as he started the car production company within the premises of the loom factory, Kiichiro Toyoda, Sakichi’s son came to realize that having unneeded parts lying all over the place in times of sparse cash was wasteful, and he invented the concept of just-in-time (JIT) , (he phrased it in English), probably meaning “exactly on time,” what was needed, when needed, in the quantity needed – not more. He tinkered with the idea until all was stopped when the military took over the plant during the war.

After WWII, many out of work aeronautics engineers joined Toyota and with the notion of “takt” in mind – and Taiichi Ohno realize how wasteful it was to run around looking for parts at the beginning of the month and then hurrying to produce at the end of the month – he hit on another form of waste.

As he tinkered with the kanban supermarket system to make JIT concepts work, he further discovered that one-piece-flow as systematically more productive than small batch work. Yet another form of classic waste.

In the same years, another bunch of Toyota engineers figured out that having a press dedicated per part was wasteful in terms of capital use, and since they didn’t have the cash on hand to buy a press per part (or the volume to justify it) they began working on faster changeovers –-  purchasing the few fast changeover presses of an American company that went bankrupt stateside.

TQ and TWI

At the same time, Toyota engineers competed for the famous Deming prize and got up to speed in its total quality practices, deepening their understanding of how wasteful non-quality could be and the links with both standards (developed through yet another American-taught group in the form of the TWI program) and kanban.

Eiji Toyoda, who recently passed away at 100 years old, Kiichiro’s cousin visited Ford operations in the early 1950s, was struck by numerous inefficiencies and came back with the idea of a suggestions system. Contrarily to Ford, he did not seek the one brilliant idea, but saw it as a way to involve all operators in spotting waste in their own jobs.

In other words, the progressive development of TPS can be seen as the study of the various forms of waste generated by our production systems. To a large extent, the spread of lean outside of the automotive industry follows the same pattern. In each new field, the main difficulty is finding the dominant form of waste – which is rarely easy and involves quite a bit of tinkering and kaizen. Dan Jones has done a superb job of showing how lean in healthcare differs from Lean in, say, IT.

I remember wondering, when I co-wrote the preface to the French edition of The Lean Startup what kind of waste was Eric Ries addressing. It’s actually a rather fundamental waste – that of failed new product introduction. And sure enough, Toyota has developed several engineering learning practices to address it. The  minimum viable product (MVP) concept is not necessarily practical in all cases, but customer  immersion, distinguishing fixed from flexible, collaborating intensively with suppliers are all par for the course.

Lean Entrepreneurs

An easy mistake to make in lean thinking is looking for standard solutions – believing that if one adopts this or that lean technique, performance will improve and all will turn out fine. Lean thinking, really, is a science of waste – understanding all the forms of waste in detail and specific circumstances. This is also why lean thinking applies so broadly across industries. For instance, Dupont estimates that 33% of all food produced is wasted (http://fr.slideshare.net/DuPont/infographic-sustainable-food-systems-and-world-food-day-2013) with 33% of all food bought thrown away in the U.S. Lean thinking would probably not follow Dupont’s conclusions of using genetically modified seeds to improve yield in African fields but rather start tinkering with ways to reduce food wastage in consumption and the supply chain.

Taiichi Ohno is quoted as saying: “There is a secret to the shop floor, just as there is a secret to a magic trick. Let me tell you what it is. To get rid of waste you have to cultivate the ability to see waste. And you have to think about how to get rid of the waste you’ve seen. You must repeat this -- always, everywhere, tirelessly and relentlessly.”

The question for lean in IT is what kind of typical wastes can be seen in IT. Wasted money, time and energy on new products people don’t buy is one, for sure, but there are many others, such as the waste created by shifting project scope, unstable dev teams, buggy code and so on. Lean Startup has opened the debate of waste in entrepreneurship –- now we must tinker day and night until we fully grasp the situation and start seeing activities to highlight typical forms of waste, which someone will surely then enshrine as principles!