Column Archive: 2013

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

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

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

Get the whole story. Read Part 1.

Dear Gemba Coach,

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

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

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

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

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

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

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

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

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

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

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

Dear Gemba Coach,

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

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

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

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

It Depends

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

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

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

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

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

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

Countermeasure to Modern Management

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

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

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

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

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

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

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

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

Dear Gemba Coach

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

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

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

Recognize The Problems with Recognition

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

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

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

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

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

Many Losers

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

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

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

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

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

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

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

Dear Gemba Coach,

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

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

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

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

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

One Piece Flow Discipline

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

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

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

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

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

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

Quality Suggestions

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

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

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

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

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

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

• At company (or brand) level: what generic preferences should all our products reflect? A construction company, for instance, can decide that all its buildings – regardless of the customer’s architect’s requirement – will include a special effort to lower energy consumption. How could you write the sentence “Toyota = peace of mind” for your own activity?

• At product level: each specific product needs a preference identity that corresponds to its target market. Think Lexus, which combines the drive of a Mercedes with the comfort of a Cadillac; or iQ, which is the size of a Smart with the feel of a sedan; or Prius, that seamlessly blends the consumption/pollution of an electric car with the autonomy of any normal car.

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

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

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

• Marketing and related activities : the first place to look would be with surveys and competitor analysis to get a feel for how the entire market is moving. This is a very poor guide to actually select preferences, particularly at product level, since this information will make you a follower, not a leader. It is still however an essential part of reading the market: what is the market’s current base line and fashionable obsession?

• Genchi Genbutsu: visit customers, investigate every customer complaint, and figure out how customers really use your product as opposed to what you think they do with it. As I writer, I’d like to think my customers actually read my books, but more often than not, they purchase the book for their subordinates to read – and these stack them on the pile of “to do when I have the time.” What does this tell me about how I should write books? Or, more to the point about what makes books sell? There’s nothing wrong with a hedgehog notion about what customers prefer (say, durability), but you also need a fox’s strategy of looking at many, many specific instances to understand what durability really means, how it plays out, and what competing preferences your customers have.

• A takt of products: as Eric Ries points out in the lean startup, the only sure way to test customer preferences is to split a test group and test product variances. This is possible with websites, but much harder to do with actual products. So, accepting that whatever Marketing says has to be taken with a huge pinch of salt, you need to rethink your products in terms of a product stream, not a single product. The product streams implies that you release a product at a regular rhythm (or takt) and watch very carefully what gambles you’re taking with each product, and what the product’s sales curve tell you about what customers really prefer. This is a radically different approach to product release from the traditional “lets put any sexy gizmo in the new product and hope people will buy it.”

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

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

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

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

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

Dear Gemba Coach

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

Value is the topic I find most exciting in lean.

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

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

Let the Seller Beware

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

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

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

Absolutely Happy

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

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

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

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

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

Dear Gemba Coach,

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

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

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

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

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

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

A Lean Vision of Engineering

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

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

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

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

Go See

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

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

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

Dear Gemba Coach,

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

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

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

Eight Hours of Standardized Work

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

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

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

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

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

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

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

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

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

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

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

The Key to Standard Work

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

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

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

Dear Gemba Coach,

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

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

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

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

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

Runners and Strangers

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

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

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

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

Calculating Stock

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

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

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

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

 Figure: Lead Time Indicators

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

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

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

Figure: Current Operating Status

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

Dear Gemba Coach,

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

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

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

And ask yourselves: are we following these three points?

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

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

Facing Patient Issues

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

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

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

Where to Start

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

From:

Rationalization of processes projects across the hospital

To:

Patient-focused PDCA by each of the department heads.

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

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

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

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

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

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

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

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

Dear Gemba Coach,

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

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

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

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

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

Lean Coaching for Executives

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

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

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

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

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

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

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

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

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

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

All Ears

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

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

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

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

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

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

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

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

Dear Gemba Coach,

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

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

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

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

Where Strategy Starts

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

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

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

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

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

Two Levels of PDCA

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

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

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

Dear Gemba Coach,

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

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

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

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

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

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

What Is the Purpose?

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

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

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

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

Where There’s a Will

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

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

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

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

Kaizen Capability

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

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

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

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

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

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

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

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

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

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