Problems Hidden In The Open

We were down on the shop floor watching an assembly operation. The takt time was on the order of three hours. The assembler was new to the task, and the team leader periodically came by and asked if he was “doing OK.” The reply was always in the affirmative.

As the takt time wound down to under five minutes to completion, this operation was the only one not reporting “Done.”

The count down hit zero, things went red, the main line stopped, and the line stop time started ticking up.

The team leader, other assemblers, the supervisor began pitching in to assist. Between them, the job was completed in about 10 minutes, and the line restarted.

So, again, my favorite question:

What’s the problem?

Lets try breaking it down to four key questions.

  1. “What should be happening?”
  2. “What is actually happening?”
  3. The above two questions define the gap.

  4. Why does the gap exist?”
  5. “What are we doing about it?”

These questions simply re-frame PDCA, but without so much abstraction.

So, in this situation:

What should be happening?
Two things come to mind immediately.

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

For this to work, though, the team member needs a clear and unambiguous way to answer a key question of his own: Am I on track to finish on time? Ideally the answer to this question is a clear “Yes” or a clear “No,” with no ambiguity or judgment involved. (Like any “Check” it should produce a binary result.)

On an automobile line with a takt time on the order of 55 seconds, the assembler can get a good sense of this. If he loses more than three or four seconds, he isn’t going to make it. But “a good sense” isn’t good enough.

Even in this fast-moving situation, you will see visual indicators that help the team member answer this question. Take a look at this photo.

toyota-assy

See the white hash marks along line at the bottom of the picture? Those mark off the moving line work zone into ten increments of about 5 ½ seconds. The assembler knows where he should be as he performs each task. If he is a hash mark behind, he isn’t going to finish on time. Pull the andon. We can safely say that, in this example, we have accomplished (1) and (2) above.

With longer takt times, it is much tougher for a human to have a good sense of how much time will be required to complete the remaining work. That makes it that much more critical that some kind of intermediate milestones are clearly established and linked to time.

What would be a reasonable increment for these checks? –> How far behind are you willing to let your worker get before someone else finds out? I’d say a good starting point is at the point when he can’t recover the time himself, the problem is no longer his. Following the standard work is the responsibility of the team member. Recovering to takt time is the team leader’s domain. At the very least, he is the one who pitches in and helps, or gets someone else to do so. But he can’t do this if he doesn’t know there is a problem.

So – what should be happening?

The team member must have continuous positive confirmation that he is on track to complete the work on time. With the failure of that positive confirmation, he should pull the andon and get assistance.

The team member must call for assistance (“pull the andon”) if his work falls behind the expected progress for any reason whatsoever.

What is actually happening?

In our example, the team member didn’t get help until it was too late. In fact, he verbally assured the team leader he was “OK” on a couple of occasions. The line stop was irrefutable evidence of a problem. That was a good thing. This company has a takt time, and runs to it. Think of what would have happened if they didn’t. It might take hours, or days, before this problem surfaced. (We are nowhere near the root cause yet. The line stop is just evidence of a problem, not the problem itself.)

Why does the gap exist?

It is a hell of a lot harder to answer this question than the other two. In this case, you are going to have to peel back a lot of layers before you get to the actual, systemic, root cause. But in the immediate sense, with a takt time bordering on three hours, there is really no realistic way a worker can judge if he has fallen too far behind to catch up. The fact that, in this case, the assembler was still learning the job, and that just compounds the situation.

From casual observation – when the team leader visited, he asked if things were OK and accepted the reply – I would start to investigate whether the team leader had a good sense himself of where the work should be at his regular check points… if he has regular check points at all.

But all of this is speculation, because after 10 minutes of watching the initial response to the line stop, our little group had moved on. I am mentioning these things as possibilities because you likely have the same issues in your shop. (And if you don’t have a rigorous sense of takt time, it is equally likely you don’t know about those issues even at the level we saw here. At least THIS company can see the evidence of the problem. That is a credit to their visual controls.)

What are we going to do about it?

Obviously there are a couple of immediate things that can be addressed to at least contain the problem. (That is, convert a hard line stop into multiple andon calls so the actual problems are seen earlier.)

I would want to establish a regular routine for the team leader’s checks. His leader standard work. At regular intervals, he should be checking progress of the work. How often? How far behind do you want the assembly to get before you are certain someone finds out about the problem? In this case, even every 20 minutes is less rigorous than the hash marks on the auto assembly line. But it would be a start.

So we have the team leader coming by every 20 minutes.

But he can’t just ask “How is it going?” We clearly saw that didn’t work. It isn’t that the assembler lied to him, it is that the assembler didn’t know because there was no standard.

What work should be complete 20 minutes into the work cycle? At 40 minutes? At 60? What verifiable facts can the team leader check by observation? There are a lot of ways to do this, most of them very simple and non-intrusive. Think it through.

But wait – now the team leader himself has standard work. What cues him to do it? Is he supposed to notice that 20 minutes has elapsed? In this case, the company already has a pretty sophisticated andon and sound system. It would be a pretty simple matter to put in an audible signal that told the team leader to make his checks. But, again, that is just one solution. I can think of a couple of others. Can you?

What is the team leader checking for? This is a critical question.

Think about it.

What was the original answer to “What should be happening?” (which is “the standard”)

We said:

  1. The work should be complete on time.
  2. As soon as you know it isn’t going to be complete on time, please tell someone so we can get you help.

We want the assembler himself to be checking #1.

So why do we have the team leader check?

So he can verify that the assembler is pulling the andon when he should. This is important because it is human nature not to ask for help until it is too late. This isn’t limited to factory floors. How many cardiac patients die because they ignored the warning symptoms for fear that it isn’t serious enough to get help?

It isn’t enough to ask the team member to call for help. You have to expect it, encourage it and require it.

Interestingly enough, as I was writing this post, John Shook posted his story about converting the culture at NUMMI.

A cornerstone of Respect for People is the conviction that all employees have the right to be successful every time they do their job. Part of doing their job is finding problems and making improvements. If we as management want people to be successful, to find problems, and make improvements, we have the obligation to provide the means to do so.

But, some of our GM colleagues questioned the wisdom of trying to install andon at NUMMI. “You intend to give these workers the right to stop the line?” they asked. Toyota’s answer: “No, we intend to give them the obligation to stop whenever they find a problem.” [emphasis added]

What was the problem in our example? We don’t know yet. We certainly can’t start looking for causes.

But the evidence of a problem was that the team member could not complete the work in the time expected. That is, he was not successful doing the job. And the line stopped because the support system failed to pick up the fact that he was falling behind until it was too late to recover.

It really does come down to respect for people.

An Exchange with Michael Ballé

Click image for Amazon.com listing

Background –
In my original comments on The Lean Manager, I compared The Lean Manager‘s story structure to that of Eli Goldratt’s classic The Goal.

This started a rather deep email exchange with Michael Ballé that goes far deeper into the book and the thoughts behind it than any review I could ever write.

With Michael’s permission, here is that exchange, with minor editing mostly for readability and flow.

My words are in blue.

Michael Ballé is in black.

Text [in brackets] are my additions to help context.


Michael:

Mark,

Here’s the acid test:
Would you agree that Jenkinson play a different role from Jonah [in “The Goal”] ?
(hint: he is the lean manager :))

Michael

Mark:

Michael –

Actually, no, I don’t think Jenkinson plays a dramatically different role than “Jonah.”

Perhaps if the story had been written from Jenkinson’s viewpoint, with insight into his thoughts and worries about Andy, rather than a third-person view of his actions and words, I would agree. Then it would be about Jenkinson AS a lean manager.

But what we have is Andy Ward’s experience of Jenkinson. Thus, I don’t get any particular insight into what Jenkinson is actually thinking about how to get his message across to Andy except in the moments when he shares his thinking in conversation with Andy.

For example, Jenkinson (and Amy and Bob) are driving the concept of the problem solving culture from the very beginning. But Andy isn’t “getting it” until late in the story.

What was Jenkinson’s internal response to Andy’s misguided approach? What mental PDCA did Jenkinson apply when he saw the right results being gained at the expense of the social structure in the plant?

Thus, this comes across as a story about Andy Ward learning through his interactions with Jenkinson (and Amy and Bob Wood), and his experiences in trying to apply what they were telling him, rather than a story about Jenkinson’s approach to leading and teaching.

So the story is (to me) much more about Andy *becoming* the lean manager than Jenkinson “being one.”

The real difference between Andy Ward’s experience and that of Alex Rogo (his counterpart from The Goal) is that Andy’s boss is participating directly in Andy’s success vs. just issuing an ultimatum. Thus, Jenkinson embraces the role of the teacher as well as the boss.

Yes – that is exactly the message – that “leading” in the TPS is teaching. But I think [The Lean Manager] is much more about Andy learning it than Jenkinson teaching it.

The characters of Amy and Bob Woods seem to be there to add credibility since a CEO really doesn’t have this amount of time to spend with a single plant manager in a large global company. But they are so well aligned with Jenkinson’s approach that they are surrogates for him.

Thus, Jenkinson is the “teacher” in a story about Andy’s insights and development as a leader.

THANKS for asking the question.
It really made me think.

Mark

Michael:

Good debate.

One of the writing issues we’ve had was that Freddy and one of his CEO friends felt Jenkinson was underdeveloped whereas Tom [the editor] and I felt he was already far too omnipresent compared to Andy Ward. The basic challenge for the book was to share the experience of what it feels like to be a plant manager stuck between the hammer (CEO) and the anvil (real life in the plant).

Jenkinson was conceived to be this Batman-like scary character. He is a teacher, but not a very good one. Basically, his one redeeming teaching feature is his patience, but, hey, the guy is a CEO. I’ve worked with several, and then I’ve spent most of my time working with the plant managers so its the latter’s pain I wanted to share. Having said that, all your points are correct, and indeed, Freddy would agree with you.

More seriously, and I hope I can convince you …that [Jenkinson’s character is not a “Jonah”] because it’s a fundamental point I’m trying to get across. As you say, the fact that Jenkinson is Andy’s boss makes it TOTALLY different from the Jonah situation. Obviously I didn’t manage to get this across well enough, but having to learn from someone who holds the sword over your head is a vastly different issue than having found a great teacher (I’d agree with Woods/Jonah), no matter how cantankerous.

This learning-from-boss issue has to be my top of the list reason why lean is spreading so slowly. So I’d argue that beyond literary devices (how many lean novel plots can there be?) this is indeed a core point of the book.

Where I’ve obviously not written this well enough is that Jenkinson IS teaching, but in a boss kind of way, which is a very different position. In particular, I’ve been very mindful (maybe even heavy handed) of the fundamental asymmetry between roles, and the whole issue of how to deal with a boss’ comments.

By the way, Jenkinson is also doing what he can with the people he’s got (can’t replace them all, right?) For instance, you’ll notice that he gets very different responses from each of his plant managers. Jenkinson’s modus operandi is to show a lean problem to the plant manager, draw a line in the sand about where he wants him next, and push him/support him to get there; As people are different, each plant takes a very different path to lean its operations and requires a different mix or arm-twisting and lecturing.

The reason we never get any direct “look” into what Jenkinson really thinks (although we do many other characters) is that I wanted to reproduce this “boss” aura – no one ever actually knows what the boss thinks. We’ve discussed this quite a bit at the time of the writing, and your comments are spot on so I’m really interested in your opinion.

[a follow-on note]

Jenkinson was actually built on what I saw my dad do when he was CEO (I was helping him at the time with expliciting the “System” – I’m a sociologist). So Jenkinson does five [six, actually] things:

1) He forces. At several points in the book, he tells people: that’s the way it’s going to be. In the German plant, in the French plant with the impromptu kaizen, with the strike, etc. Basically, he forces his managers to commit and/or do something right away IN FRONT OF THEIR TROOPS. This is a specific technique – and not an easy one.

2) He gets them to go further in their thinking. At several points, Jenkinson works with Andy to push his questioning further (not always explicitly “why?”, but it does happen. Freddy, who used to be feared because of 1), was surprisingly in the HOURS he spent doing just that. It’s equally terrifying when you’re on the receiving end because, at first, subordinates are fishing for the answer they think the CEO wants to hear, and not thinking – which makes for a lot of frustration both ways.

3) He forces people to work together, particularly when they don’t want to. Actually, Amy does this in Andy’s plant at first with the production plan issue, but Phil forces the Neville/Andy link, and later the Engineering teamwork.

4) Phil encourages “problems first” at several occasions, which is trying to tell his guys that they come to him with problems rather than let them fester, and that if he learns of the problem from someone else first, that’s bad.

5) He lectures – although this is against his own expressed principles – as he states in the car at the beginning of the book. Phil is not so enamored with the sound of his own voice as the author, but we’re still all human, right?

One more thing Jenkinson does on several occasion:

6) “Stay on target, stay on target” – Andy keeps being distracted by all sorts of things, internal politics, problems in his plant, etc. Jenkinson realigns him at almost every conversation 🙂

The two insights we have in Phil’s thinking are:
– when do I pull the plug (close the plant, fire the plant manager/regional manager/sales VP, etc.)
– dealing with the politics of senior management

In writing the [business novel] genre You’re stuck between expliciting the thinking (the lecturettes, love the word), and sharing the experience through an action scene. Then there are the limits of the author’s writing talent – I had to really sweat it before trying work within the plant as opposed to out of it (The Gold Mine), because trying to describe a working plant environment is something of a writing challenge.

Michael

Mark:

Michael –

A couple of questions –
Who is the “ideal reader” – the target audience – for “The Lean Manager?”

What are the explicit teaching points the story is intended to present to the reader? What does this ideal reader take away?

What should the target reader do differently after reading the story?

What aspect of the story gives him that insight?

Did you have those things in mind as you wrote it? Or did the emerge with the story development?

I see Andy as the central character of the story. It is he who undergoes the personal transformation, and the storyline revolves around his interaction with the other characters. As you intended, is a sympathetic character that many people the in the same position will identify with.

Thus the learning from the book is transmitted through Andy, based on his experiences.

I see Jenkinson as a (primary) supporting character, who in combination with the others, shapes Andy’s experience, and through that, shapes the reader’s experience. But in the end, he is mainly a teaching character.

Yes, he is also the boss and needs the results. He leads by example. He teaches “forcing teamwork” by doing it. He makes his intentions crystal clear, does not do hollow posturing, and can play the political resistance against itself. But to Andy, he is sensei.

A good student will be motivated by wanting to please the teacher. In this case, it is also an economic / career imperative, but in the end, it is about a motivated student.

The key points of what to teach certainly come out in the process, including the fact that Andy learns a few things the hard way in spite of being told (like the teamwork thing).

But overall, it seems to be about “How to be taught” by a true lean manager more than it is “how to teach like one.”

If the key point is to teach a senior executive HOW to be a “lean manager” then I guess I’d have written it from the teacher’s perspective rather than the student’s.

If I were a CEO or senior executive, I’d like to know what Jenkinson was thinking when Andy was getting bogged down in distractions. If the target audience for the story is a senior executive or CEO, then I would think the CEO character has to be the sympathetic character, with the frustrations and problems that these guys can relate to. Then they can see he isn’t “Batman” in a comic-book city, but he is dealing with the same problems they are.

John Shook made an attempt at that in “Managing to Learn” but the scenario was too limited to really create any dramatic “ah-ha” moments.

I think Dr. Bahri’s self-experience (Follow the Learner) was a unique perspective of learning-by-doing, but, again, the scenario is too limited for most people to see beyond a medical or dental practice.

So – after re-reading my own note above, and going back to your earlier note regarding your debate about Jenkinson’s character development vs. his “omnipresent” relationship with Andy
– I guess I’d say that:

With Andy as the point-of-view character, then Jenkinson’s development is appropriate.

But if Jenkinson is actually the title character, then I can see where Freddy and his CEO friend felt that he should be more developed. The difference is that, to get that development, the perspective of the story has to shift from Andy to Jenkinson as well. Then the “omnipresence” drops away as an issue because it is about Jenkinson teaching rather than Andy being taught.

One possible follow-on story could be this shift to the teacher’s perspective. Perhaps there is a new acquisition and Jenkinson assigns Andy to mentor the manager there through a turn-around as Andy’s next development assignment. Now Andy is the teacher, (with Amy’s help, or through the A3 process with Jenkinson), and we see the teacher’s perspective as he is trying to keep the student focused on the right things in spite of the noise and chaos that, perhaps, Jenkinson is throwing at it with his demands for performance.

Andy must simultaneously understand “the main problem” in the plant, and get his student to understand it without just telling him the answers. Maybe he sees the guy as a hopeless concrete head, and Jenkinson has to force him to be patient and stick with it.

What does a competent operations manager need to learn to be able to teach someone else? How does he learn it? What is the development process for that?

Then we would have a story of not only how to BE a lean manager, but how to teach one to teach another.

Thoughts?

Mark

Michael:

The books are about 1) teaching and 2) sharing an experience. It all flows from here – I never had a target audience in mind.

The Gold Mine was all about describing TPS from the point of view of a smart guy, who’s got the power to affect changes, but has got to learn all this stuff – that was Jenkinson then. The experience I tried to share then was “The Curse Of Knowledge”.

To Jenkinson most of TPS is new and counterintuitive and every time he’s picked something up, there’s more to it (and I still experience this fifteen years later), because you don’t know what you don’t know.

And for Bob Woods, the impossibility of expressing what you’ve figured out over years to someone, hence the annoyance and grumpiness (not “Jonah” 😉 ). Add Amy, who thinks she’s getting it because the tools make sense to her, but she doesn’t understand the wider business picture nor why older people have trouble thinking that way and you’ve got The Gold Mine. Now, the trick is in

1) sharing an experience and
2) conveying the concepts, so sometimes I get it right sometimes not.

Pat Lancaster of Lantech fame, made the same type of comment [about The Gold Mine] you did: “Why didn’t you write it from the plant manager’s perspective?” To convey the absolute panic of the moment you’re about to pull the plug on the MRP. The comment stuck, and eventually that became The Lean Manager.

The gimmick in [The Lean Manager] is that BOTH Jenkinson and Andy are “the lean manager” – Jenkinson is the closest I can make it to a lean boss outside Toyota (those I’ve known anyway) and Andy is learning that stuff – with the added twist of the asymmetry of relationship that defines authority relationships.

The Gold Mine was about TPS, and this one is about Toyota Way.

My overriding problem as a consultant on the shop floor when I talk to senior execs is: “Are we on the RIGHT problems?” The problem with consultants (me included) is that they seldom understand enough of the business to focus on the right things (not a problem to Toyota consultants with suppliers, because, well, auto is auto).

So I like the idea of Amy consulting with some company and getting them to fix the shop floor and yet having no results on the business because the real problem is in engineering – where she’s got everything to learn (enter Woods & Jenkinson). If I do that, definitely “teaching the stuff” becomes an issue (since this is my specific expertise, I’ve resisted going there so far not to pollute the message too much with my socio-techno stuff)

Will have to let this one simmer for a while.

In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.

I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest (more for the next book).

The only way I know how to fight on the field of ideas is by writing books and then getting them into people’s hands. So now that it’s out, I’d like to get it in the hands as as many people as I can to try and change the zeitgeist… Not my favourite activity!

Best,
Michael


I really wanted to share this exchange with you because it highlights a couple of the main problems that are encountered in any attempt to implement real change.

To quote again from Michael’s note:

“In any case, the one main point of the entire book is that you can’t do lean to someone else, and you can’t have someone else to it for you – TPS is a line management method, and a problem solving attitude.

I strongly believe that this misunderstanding is at the root of the slow progress of lean – we keep preaching to the choir, but really it’s the hard nosed finance-driven managers we need to interest.”

And, in the end, there it is.
Ironically, if you are even reading this, you already know it.

The Lean Manager is a success story, driven by the people who are actually responsible to deliver the results. While Michael and I may quibble about whether or not Phil Jenkinson is a “Jonah” character in the sense of The Goal is a discussion about literary structure rather than the core message here. What all of these books have in common is that it is the leaders who drive successful change.

The “slow progress of lean” comes in situations where the implementation is delegated to staff with the charter to “do it to someone else.” And, in my experience (having spent a painful amount of time as that staff), that situation is far more common out there.

I have more to go on this, but I am going to leave it for another day.

Audits vs. Leader Standard Work

5S audits, standard work audits, and for that matter ISO-900x audits, are a frequent source of questions in various online discussion forums. At the same time, the topic of “leader standard work” comes up frequently, as it did in a recent question / comment on “Walking the Gemba.”

I think the topic is worth exploring a bit.

Let’s start with audits.

Typically the purpose of an audit is to check compliance with a standard. The auditor has a checklist of some kind that defines various levels of compliance. He evaluates the current situation against the checklist, and produces a score, a report of discrepancies, a pass/fail evaluation of some kind.

So, for example, a typical 5S audit would assign various criteria in each of the 5 ‘S’ words, and assign a 1-5 scale against each of them. Periodically, the person responsible for 5S will come into the work area, do an audit, and post the score. Often there is a campaign to “get to level 3” or something.

Although there are fewer boilerplate checklists out there, “standard work audits” tend to be pretty similar, at least the ones I have seen.

Further up the scale is something like an ISO 900x audit, or an “Class-A MRP II” audit or a corporate “lean assessment.” These are often done by outside agencies to certify the organization. There is a lot of work up front to pass the audit, a plaque goes on the wall, and everybody is happy.

So what’s the problem? (this is turning into one of my favorite questions)

The key is in the difference between a “check” and a “countermeasure.”

A countermeasure is a change or adjustment to the system itself so that the root cause of a problem, or at least its effect, is eliminated.

Audits, on the other hand, actually change nothing about the underlying system. All they do is assess the current state against some (presumed) standard.

Yet so many organizations try to use “audits” as a means to alter the system.

What an audit is good for (if it is planned and performed well – a big assumption) is to CHECK to see if the other things you are doing are working. But, by itself, it is “management by measurement.” People will do what they must to pass an audit (if it even matters that much to them), then go back to what they were doing before.

Leader Standard Work operates at a much lower level of granularity, and looks for different things. Think of the analogy in a previous post about cost accounting:

When dieting, standard cost accounting would advise you to weigh yourself once a week to see if you’re losing weight. Lean accounting would measure your calorie intake and your exercise and then attempt to adjust them until you achieve the desired outcome.

So, to paraphrase, audits are weighing yourself once a week (or once a quarter!) to see if you are losing weight. Leader standard work, on the other hand, is a process to continuously verify that the calorie intake is as specified, and the exercise is as specified, while those things are being done.

That, in turn, implies that there is a daily plan for calorie intake, and a daily plan for exercise. Without those specifications, there is nothing to check.

Leader standard work defines what the leader will check, when it will be checked, and how it will be checked. It also defines how the leader will respond if there is a problem.

He is looking for solid evidence of control.

Are things going as planned?

Is anything disrupting the work cycles or flow of material?

Are quality checks being made as specified?

And, in my opinion, the most important: Are problems being handled correctly, or worked around?

This is important because a culture of working around problems is one in which problems are routinely hidden, often without malice and with the best of intentions. But hidden problems remain, come up again tomorrow, and become part of the routine, adding a little waste, a little friction, making the system a little worse every day.

The typical effort to “pass an audit” reinforces this – it actually hides problems, and the auditor’s job is to ferret them out. This is the exact opposite of the kind of problem transparency we need.

It is human nature to work around problems, and it is the default behavior, everywhere. It takes constant leader vigilance, coaching, response to prevent it.

Learn how to Learn

John Shook’s latest column on lean.org is titled “Was NUMMI a Success?” He adds some interesting thought to the mix of the ongoing post-mortem on GM and NUMMI.

John argues (successfully, I think) that Toyota’s objectives for NUMMI were to learn how to take their system outside of the safe cocoon of Toyota City in Japan; and that GM’s objectives, aside from getting an idle plant going again, were to learn how to make small cars profitibly, and learn Toyota’s system.

So both companies were in the game to learn.

But Toyota had a huge advantage.

And if there’s one thing Toyota knows how to do it is how to learn, especially where it’s important down at the operational levels of the company – a characteristic that is the embodiment of the learning organization. Toyota’s biggest strength is that it [had] learned how to learn, and it was that approach to learning that defined its approach to NUMMI from day one.

Just as strong as Toyota’s advantage here, was GM’s deficit. While they clearly learned about the system, and indeed implemented pieces of it in new plants, there is no objective evidence that GM ever really “got” that this is much more than an industrial engineering model.

It is a model about continuously challenging your understanding and beliefs.

We start teaching it deep down in the process, “Why did the machine stop?” but the intent is for this thinking to find its way to the very top and learn how to ask “Why are sales 12% under projection this month?”

Toyota has learned some hard lessons about what they did not understand in the last year. I only hope we will be able to say the same about our public gamble on GM’s learning.

If you want to go faster, stop.

Mark’s post on The Whiteboard tells a pretty common story. The good news is that this company has more business than they can handle. Pretty good results in these times. The bad news is that they are having problems ramping up production to meet the demand. In Mark’s words:

I’m working for a company that is very, very busy. They developed a new process that is the first of it’s kind and have taken the market share away from their competition. But they have not spent enough time making the process robust enough to handle the increase demand and the scrap costs are going out of the roof. Currently about 65K a day. Any suggestions? Our number 1 scrap producer is a machine that can not perform at the same capability as when Engineering did their run off…

At the risk of coming across as flip, the very first thing to do if a machine starts producing scrap material is to shut it down.  It is better to make nothing because that is a cheaper alternative than making stuff you can’t use.

However, it goes deeper than that.

Engineering had done a “run off” (which I presume was a test on theoretical speeds). Now actual performance isn’t meeting expectation. This is a problem.

But let’s rewind a bit and talk about how to manage a production ramp-up. Hopefully it is a problem more people will be having as the economy begins to recover.

Although this is in the context of the machine, exactly the same principles apply to any type of production. Only the context and the constraint changes.

Presumably there was some speed for this machine where it didn’t produce scrap, or the scrap was minimal. Going back to that time, here is what should have happened.

Promise production at the rate the machine is known to support.

Now crank up the speed a bit and see what happens. In the best case, you are overproducing a bit, but you are learning what the machine is actually capable of doing.

Crank it up a little more. Oops, scrap.

STOP!

Because you have been running a little faster than required, you have bought a little time. Understand why that scrap happened. Try to replicate it. Dig into the problem solving. Try to replicate the problem under controlled conditions. LEARN.

Hopefully you can find the cause and fix it.

Try it. Run the machine again, at the faster speed. Scrap? Back around to the “problem solving” cycle. Repeat until you can reliably run at the faster speed without scrap.

Then, and only then, promise the higher rate, because now you can reliably deliver it.

Then notch it up a bit until you encounter the next problem.

This cycle of promising only what you can actually deliver protects the customer while you are pushing the envelop internally to discover the next problem.

The alternative? Make a promise knowing you actually have no clue whether or not you can meet it.

But that’s what they did. So now they are burning a lot of money every day making scrap material.

The same principles apply, however. They are already not delivering what they promised. So throttle things back to the point where they can predict the results, and go from there. Pretending they can run faster than they can is not accomplishing anything other than burning money. Deal with facts, no matter how uncomfortable.

If you make a schedule based on what you wish you could do, you will have a schedule you wish you could meet.

No matter what, each time scrap is produced, the fact must be acknowledged. That allows the immediate response that is framed around a simple question:

“How the hell did this happen?”

Put another way, “What have we just learned about the limits of this process?”

It is only within that framework that you actually get any better. Anything else is relying on luck, and in this case at least, that didn’t work.

The Lean Manager: Part 3 – People, Purpose, Problems, Process vs. “Systems”

Click image for Amazon.com listing

This is Part 3 of a multi-part review. Part 1 is here.

Before I get into it, I will break the rules of blogging and acknowledge a time gap here. I did finish the book shortly after I wrote part 2, in fact, I didn’t want to put it down. So now I am going back through and bringing out some key points, intermixed with some other stuff that has caught my interest lately. Anyway – back to what you came for…

Steve Spear has described the TPS as a “socio-technical system.” Put in less formidable terms, it is a system that uses the structure of the work, the work environment and the support systems (the technical part) to create an organizational culture of problem solving.

Jenkinson, Andy’s boss in the book, describes it:

“You need to organize a clear flow of problem solving, explained Jenkinson one more time. “Operators need to have a complete understanding of normal conditions, so that whenever there is a gap, they know it’s a problem. Go and see is not just for the top management, It’s for everybody. This means operators as well, in particular how they learn to see parts and see the equipment they use. How can all operators recognize they have a problem? [emphasis added]

The simple statement, and following question posed by Jenkinson sums up a great deal that is left out of lean implementations. I see it everywhere, and will be commenting on it more shortly.

We talk about “go and see” (or “genchi genbutsu“) as something leaders do. I think this is because traditional leaders aren’t naturally out in the work areas, on the shop floor, in the hangars, etc. We don’t think about the workers because they are there all of the time.

Yes, they are. But what do they see? Do they see disruptions and issues as things they are expected to somehow work around and deal with? Or do they see these things as something to call out, and fully participate in solving?

And if they do see a problem, what is the process for engaging it?

Just saying “you are empowered to fix the problem” does not make it so. When are they supposed to do it? Do they have the skills they need? How do you know? Is there a time-based process to escalate to another level if they get stuck? (Or do they just have to give up?)

And indeed, as the story in the book develops, Andy turns out to be taking a brute-force approach. He is directing staff to implement the tools and to solve problems. But in spite of nearly continuous admonitions from his boss and other experts, he is not checking how they are doing it. He has put a “get-r-done” operations manager into place, and while the guy is getting “results,” in the long haul it doesn’t work very well. Yes, they end making some improvements, but at the expense of alienating the work force.

It is only late in the story (and I won’t get into the details to avoid playing the spoiler to a pretty good plot twist) that Andy finally learns the importance of having a process that is deliberately designed to engage people.

Commentary – it is amazing to me just how much we (in the “lean community”) talk about engaging people, but never really work through the deliberate processes to do it. There are explicit processes for everything involving production, administration, etc. but somehow we expect “engaging people” to happen spontaneously just because we believe it is a good thing.

The message in this book is loud and clear. This is about leadership. The tools are important, yes, but only (in my opinion) because they are proven techniques that allow people to become engaged with the process.

But the tools alone do not require people to get engaged.

Permission to make input is necessary, but not sufficient. If you want people to be engaged, you have to deliberately engage them. Otherwise you are just asking them to become nameless cogs in “the system.”

Clarity for the Customer

I have come to expect very little from most airlines, especially for the parts of the “service” that doesn’t involve actually sitting in the airplane. Still, some airlines make their policies more clear than others. Alaska Air, for example, is explicitly clear that I can hold a reservation for 24 hours and cancel with no penalty. They say so on the web site during the online booking process.

NWA (soon to be Delta), on the other hand, is somewhat less transparent. Thus, I had to call the “Elite Reservations” number, and talk to a human being to confirm the 24 hour cancellation policy. Of course I could have gotten this from their web site, I suppose. Maybe it is somewhere in here. Could this be any less clear if had been deliberately obfuscated? What purpose is served by serving up confusing information in the most difficult-as-possible to read format? How does this help their business? Or do they feel they have to trick their customers into buying the product?

I often wonder about things like this. Some companies just seem to get a thrill out of making it difficult for their customers to do business with them.

Penalties

CHANGES ANY TIME CHARGE USD 150.00 FOR REISSUE. NOTE – DOMESTIC TICKETS ARE VALID FOR ONE YEAR FROM DATE OF ORIGINAL PURCHASE. THE TICKET MUST BE EXCHANGED AND THE NEW ORIGINATION DATE MUST BE WITHIN ONE YEAR OF THE ORIGINAL PURCHASE DATE DESIGNATED ON THE ORIGINAL TICKET. . TICKETS MUST BE REISSUED WHEN ANY VOLUNTARY CHANGE IS MADE. THE NONREFUNDABLE VALUE SHOULD BE PLACED IN THE ENDORSEMENT BOX ON THE REISSUE TICKET . IF MULTIPLE CHANGES ARE MADE AT THE SAME TIME ONLY ONE CHANGE FEE WILL APPLY. IF FARES WITH DIFFERENT CHANGE FEES ARE COMBINED ON THE SAME TICKET THE HIGHEST FEE OF ALL THE CHANGED FARE COMPONENTS WILL APPLY. . GDPR – GUARANTEED DAY OF PURCHASE RULE DECREASE IN FARE AFTER TICKET PURCHASE. . IF A DECREASE OCCURS AFTER A TICKET IS PURCHASED AND PRIOR TO ANY TRAVEL ON THE TICKET OR A NEW FARE FOR WHICH THE PASSENGER QUALIFIES BECOMES EFFECTIVE THE DIFFERENCE IN FARE MAY BE CREDITED. FOR COMPLETE DETAILS SEE PARAGRAPH VI BELOW. . I. PRIOR TO DEPARTURE A. CHANGES TO DEPARTING FLIGHT ARE PERMITTED FOR APPLICABLE CHANGE FEE PROVIDED THE CHANGE IS MADE TO THE SAME ORIGIN/DESTINATION AND SAME TICKETED TRAVEL DATE AND SAME BOOKING CLASS. . B. CHANGES TO DEPARTING FLIGHT INVOLVING A CHANGE TO ORIGIN/DESTINATION OR DIFFERENT TICKETED TRAVEL DATE OR BOOKING CLASS ARE NOT PERMITTED. SEE CANCELLATIONS . II. PRIOR TO DEPARTURE – CHANGES TO CONTINUING/ RETURN FLIGHTS WHEN THERE IS NO CHANGE TO ORIGIN/DESTINATION OR STOPOVERS. . A. CONTINUING/RETURN FLIGHTS MAY BE CHANGED TO A LATER DATE FOR THE CHANGE FEE WITHOUT REGARD TO THE ADVANCE RSVN REQUIREMENTS PROVIDED THE CHANGE MEETS ALL OTHER FARE RULES. . CONTINUING/RETURN FLIGHTS MAY BE CHANGED TO AN EARLIER DATE FOR THE CHANGE FEE PROVIDED THE CHANGE MEETS ALL FARE RULES. THE ORIGINAL TICKET ISSUE DATE MAY BE USED TO MEASURE THE ADVANCE PURCHASE REQUIREMENT. . B. IF A CHANGE IS MADE TO A BLACKOUT DATE OR THE CHANGE VIOLATES THE DAY/ROUTING/ FLIGHT /SEASONALITY/TRAVEL DATES OR BOOKING CODE REQUIREMENTS TRY THE FOLLOWING OPTIONS . B.1 RE-PRICE THE CONTINUING/RETURN PORTION WITH FARES IN EFFECT ON THE DATE THE ORIGINAL TICKET WAS ISSUED. ANY DIFFERENCE IN FARES PLUS THE APPLICABLE CHANGE FEE SHOULD BE COLLECTED. IF THE REPRICE RESULTS IN A LOWER FARE NO RESIDUAL VALUE APPLIES AND THE FULL CHANGE FEE SHOULD BE COLLECTED. . B.2 THE ENTIRE TICKET SHOULD ALSO BE REPRICED WITH CURRENT FARES. ANY DIFFERENCE IN FARES PLUS THE CHANGE FEE SHOULD BE COLLECTED. IF THE TICKET PRICE IS LOWER WITH CURRENT FARES THE DIFFERENCE IN FARES LESS THE CHANGE FEE MAY BE CREDITED TO THE PASSENGER IN THE FORM OF A NONREFUNDABLE MCO. THE MCO MUST BE EXCHANGED WITHIN ONE YEAR OF THE MCO ISSUE DATE. . B.3 IF THE RESULTS OF B.1 – B.2 ABOVE RESULT IN MULTIPLE PRICING SOLUTIONS THE LOWEST SOLUTION WOULD APPLY. . III. PRIOR TO DEPARTURE – CHANGES TO CONTINUING/ RETURN FLIGHTS WHEN THERE IS A CHANGE TO ORIGIN/DESTINATION OR STOPOVERS. . A. REPRICE THE CONTINUING/RETURN PORTION WITH A CURRENT FARE. ANY DIFFERENCE IN FARES PLUS THE APPLICABLE CHANGE FEE SHOULD BE COLLECTED. IF THE REPRICE RESULTS IN A LOWER FARE THE DIFFERENCE IN FARES LESS THE CHANGE FEE MAY BE RETURNED IN THE FORM OF A NONREFUNDABLE MCO. THE MCO MUST BE EXCHANGED WITHIN ONE YEAR OF THE MCO ISSUE DATE . B. THE ENTIRE TICKET SHOULD BE REPRICED WITH CURRENT FARES. ANY DIFFERENCE IN FARES PLUS THE CHANGE FEE SHOULD BE COLLECTED. IF THE REPRICE RESULTS IN A LOWER FARE THE DIFFERENCE IN FARES LESS THE CHANGE FEE MAY BE RETURNED IN THE FORM OF A NONREFUNDABLE MCO. THE MCO MUST BE EXCHANGED WITHIN ONE YEAR OF THE MCO ISSUE DATE. . IV. AFTER DEPARTURE – CHANGES TO CONTINUING/RETURN FLIGHT WHEN THERE IS NO CHANGE TO ORIGIN/ DESTINATION OR STOPOVERS. . A. CONTINUING/RETURN FLIGHTS MAY BE CHANGED TO A LATER DATE FOR THE CHANGE FEE WITHOUT REGARD TO THE ADVANCE RSVN REQUIREMENTS PROVIDED THE CHANGE MEETS ALL OTHER FARE RULES. . CONTINUING/RETURN FLIGHTS MAY BE CHANGED TO AN EARLIER DATE FOR THE CHANGE FEE PROVIDED THE CHANGE MEETS ALL FARE RULES. THE ORIGINAL TICKET ISSUE DATE MAY BE USED TO MEASURE THE ADVANCE PURCHASE REQUIREMENT. . B. IF A CHANGE IS MADE TO A BLACKOUT DATE OR THE NEW DATE VIOLATES THE DAY/TIME/ROUTING /TIME/FLIGHT/SEASONALITY/TRAVEL DATES OR BOOKING CODE REQUIREMENTS TRY THE FOLLOWING OPTIONS. . B.1 THE CONTINUING/RETURN PORTION SHOULD BE RE-PRICED WITH AN APPLICABLE FARE IN EFFECT ON THE DATE THE ORIGINAL TICKET WAS ISSUED. ANY DIFFERENCE IN FARES PLUS THE CHANGE FEE SHOULD BE COLLECTED. IF THE REPRICE RESULTS IN A LOWER FARE NO RESIDUAL VALUE WILL APPLY AND THE FULL CHANGE FEE SHOULD BE COLLECTED. . B.2 REPRICE THE CONTINUING/RETURN PORTION WITH A CURRENT FARE. ANY DIFFERENCE IN FARES PLUS THE APPLICABLE CHANGE FEE SHOULD BE COLLECTED. IF THE REPRICE RESULTS IN A LOWER FARE THE DIFFERENCE IN FARES LESS THE CHANGE FEE MAY BE RETURNED IN THE FORM OF A NONREFUNDABLE MCO. THE MCO MUST BE EXCHANGED FOR WITHIN ONE YEAR OF THE MCO ISSUE DATE. . B.3 IF THE RESULTS OF B.1 – B.2 ABOVE RESULT IN MULTIPLE PRICING SOLUTIONS THE LOWEST SOLUTION WOULD APPLY. . V. AFTER DEPARTURE – CHANGES TO CONTINUING/ RETURN FLIGHT WHEN THERE IS A CHANGE TO ORIGIN/DESTINATION OR STOPOVERS. . A. REPRICE THE CONTINUING/RETURN PORTION WITH A CURRENT FARE. ANY DIFFERENCE IN FARES PLUS THE APPLICABLE CHANGE FEE SHOULD BE COLLECTED. IF THE REPRICE RESULTS IN A LOWER FARE THE DIFFERENCE IN FARES LESS THE CHANGE FEE MAY BE RETURNED IN THE FORM OF A NONREFUNDABLE MCO. THE MCO MUST BE EXCHANGED WITHIN ONE YEAR OF THE MCO ISSUE DATE. . B. IF THE CHANGE IS TO A CO-TERMINAL THE DIFFERENCE BETWEEN THE APPLICABLE FARES MUST BE COLLECTED IN ADDITION TO THE CHANGE FEE. FOLLOW- THE POLICIES LAID OUT ABOVE ON HOW TO RECALCULATE THE DIFFERENCE IN FARES. . VI. GDPR – GUARANTEED DAY OF PURCHASE RULE . DOMESTIC PASSENGER TRANSPORTATION IS SUBJECT TO RULES/FARE/ROUTINGS AND CHARGES IN EFFECT ON THE DATE/TIME THE TICKET IS ISSUED/PTA PURCHASED UNLESS SPECIFIED IN THE FARE RULES. . DECREASE IN FARE AFTER PURCHASE . IF A DECREASE OCCURS AFTER A TICKET IS PURCHASED AND PRIOR TO TRAVEL ON THE TICKET OR A NEW FARE FOR WHICH THE PASSENGER QUALIFIES BECOMES EFFECTIVE THE DIFFERENCE IN FARES WILL BE CREDITED PROVIDED . 1. THERE ARE NO CHANGES TO ORIGIN/DESTINATION/ STOPOVER POINTS/FLIGHTS/DATES. . 2. ALL CONDITIONS OF THE NEW/REDUCED FARE MUST BE MET. THE ORIGINAL TICKET DATE OF ISSUE MAY NOT BE USED TO SATISFY THE ADVANCE RESERVATION/TICKETING REQUIREMENTS. THE BOOKING CODE OF THE NEW/REDUCED FARE MAY DIFFER FROM THE BOOKING CODE ON THE ORIGINAL TICKET. . . FOR TICKETS ISSUED ON/BEFORE 11NOV08 THE PASSENGER WILL RECEIVE A NONREFUNABLE MCO LESS A 50.00USD ADMINISTRATIVE SERVICE FEE. . FOR TICKETS ISSUED ON/AFTER 12NOV08 – THE PASSENGER WILL RECEIVE A NONREFUNDABLE MCO LESS A 150.00USD ADMINISTRATIVE SERVICE FEE . THE MCO CAN BE USED FOR FUTURE TRAVEL PURCHASE. THE MCO MUST BE EXCHANGED FOR A TICKET WITHIN ONE YEAR OF THE MCO ISSUE DATE. CANCELLATIONS TICKET IS NON-REFUNDABLE. NOTE – 1.CUSTOMERS FIRST POLICY. . 1. WHEN RESERVATIONS ARE MADE AND TICKETS ARE PURCHASED ON THE SAME DAY REFUNDS EQUIVALENT TO THE AMOUNT PAID WILL BE PERMITTED UP TO 1 DAY AFTER THE TICKET IS PURCHASED AT NO CHARGE. ANY CERTIFICATE OFFER WILL BE DEEMED USED AND WILL NOT BE REPLACED. 2. FARES ARE SUBJECT TO CHANGE AND NOT GUARANTEED UNTIL A TICKET IS PURCHASED. . B.WHOLLY UNUSED NONREFUNDABLE TICKET POLICY. . A WHOLLY UNUSED NONRFND TKT MAY BE APPLIED TOWARDS THE PURCHASE OF A NW/KL DOMESTIC/ INTERNATIONAL FARE/TICKET. -PROVIDED TRAVEL ON THE NEW TICKET ORIGINATES WITHIN 1 YEAR OF THE ORIGINAL PURCHASE DATE AND THE TICKET IS EXCHANGED NO LATER THEN 365 DAYS AFTER THE ORIGINAL TICKET ISSUE DATE. . -ANY NONREFUNDABLE VALUE IS CARRIED FOWARD IN ALL SUBSEQUENT REISSUES. THE NONREFUNDABLE VALUE SHOULD BE PLACED IN THE ENDORSEMENT BOX ON THE REISSUE TICKET. . -LIMIT OF ONE TKT MAY BE APPLIED TOWARDS A NEW TICKET. -APPLICABLE CHANGE FEE APPLIES. . C. TICKET VALIDITY AND CANCELLATION FEE . 1. TICKETS WILL BECOME INVALID/EXPIRED 366 DAYS AFTER THE DATE OF THE FIRST UNUSED COUPON AND MAY NOT BE USED OR EXCHANGED FOR TRANSPORTATION AFTER THAT TIME AND DATE. . 2. ONCE THE TICKET BECOMES INVALID – THE FARE AND RELATED TAXES AND FEES WILL BE REFUNDED. SIMULTANEOUSLY WITH THE REFUND NW WILL IMPOSE A CANCELLATION FEE EQUAL TO 100 PERCENT OF ALL AMOUNTS COLLECTED BY NW FOR ISSUANCE OF THE TICKET – INCLUDING – THE FARE AND APPLICABLE TAXES/FEES AND ANY OTHER CHARGES. – SEE GENERAL TARIFF RULE 105 – . D. EXCEPTION TO FEE COLLECTION. . IN THE EVENT OF THE DEATH OF THE PSGR A REFUND IS PERMITTED. THE CHANGE FEE WILL BE WAIVED.

This, of course, is the example of communications they let the customers actually see on their “award winning web site.” Therefore, I have to assume this is communication at its very best. I wonder what the pilots and crew have to deal with – and how much it distracts them from getting the job done safely and efficiently.

The Lean Manager: Part 2 – The Basics

Click image for Amazon.com listing

This is Part 2 of a multi-part review. Part 1 is here.

In my review of Kaizen Express back in May, I took LEI to task for two things – First, I didn’t feel Kaizen Express contributed anything really new to the body of knowledge. I would have been satisfied if it had more clearly explained what had been said before, but it didn’t do that either. Second, and more importantly, I felt that Kaizen Express, and the LEI in general, were propagating the conception that the tools were what defined “lean” and that “the tools” were “the basics.” I disagreed on both points, and still do.

I am now about halfway through The Lean Manager, and I believe this book is addressing those issues – and hopefully challenging some of the thinking within the publishers. In other words, in its content, this book is everything that Kaizen Express isn’t. Get it. Read it. Do what it says, and you will actually be implementing the basics.

What makes this different? Instead of revolving around technical descriptions of the tools, this book clearly shows the proper relationship between the tools and the two most important aspects of what makes the Toyota Production System work:

  • Leaders (and how they lead and what they lead – and it isn’t implementing the tools)
  • People (yes, other books pay lip service by mentioning shop floor engagement, but The Lean Manager is all about shop floor engagement)

The authors start to hammer home the point in Chapter 2, Everybody, Every Day. In one of the many lecturettes they use to convey the key points via their characters, Amy, a corporate consultant, sums it up:

Everybody, everyday solving problems, that’s the only answer to the Pareto dilemma. You’ve got to visualize two flows in the plant. One: the product flow[. . .].  Two: the problem flow to the person who finally solves the problem. [. . .] you shouldn’t funnel all problems to your key technical people. You should protect them to work on the really difficult issues. What you have to organize is the problem solving in the line!”

And with that, the rest of the story follows – this fictitious plant manager under fire in this fictitious company sets out to do that.

The subsequent chapters (so far – remember, I haven’t finished the book yet) are Go and See, which hammers home the importance of the leaders – all of the leaders being present, not just to witness problems, but to ensure they are being solved by the right people, in the right way. Further, they must break down any barriers which impede that flow. And it’s not just the leaders. Ultimately, the entire shop floor is organized so that everyone is immersed in genchi genbutsu every time a task is carried out or work is performed. This becomes the check in PDCA.

Chapter 3 is titled Managing is Improving and begins the confront the psychological and organizational aspects of the changes that are now coming to a head in the story. This part requires the most creativity on the part of the authors, as it is an entirely human process. Because it is a human process, not a technical one, it is impossible to write a technical manual on how to do it. It requires knowledgeable, dedicated leadership that is humble enough to stake out a position that might be wrong, knowing that doing so improves the chance of learning something.

And that has been the issue in our industry. It is far, far easier to describe the tools in excruciating detail than it is to confront the leadership and organizational change issues. And because the technical descriptions predominate the literature (including, and especially what has come out of LEI for the last 10+ years), it is far easier to believe that “implementing the tools” is something that leaders can delegate to specialized technical staff.

This book, so far, is (rightly) turning that thinking on its ear.

Continued at Part 3.

The Lean Manager: Part 1 – Customers First

Click image for Amazon.com listing

I just started reading this book, and my initial feeling is that it is a winner. Rather than producing a batch review of the whole thing at the end, I thought I would employ “one chapter flow” and share my impressions with you as they are formed. As I write this, I honestly do not know where it is ultimately going.

I am excited about this book because it is challenging the decades-old paradigm of kaizen events run by specialists (while simultaneously trying to justify the change activity to the people who hired them in the first place). In its place is a leader who knows what he is doing, and appears to be starting to lead by asking tough questions.

Even with that initial endorsement, this book appears to be following the standard formula established by Eli Goldratt in The Goal.

  • Manager finds out factory is being closed. News is devastating to his personal life.
  • The Jonah character emerges and teaches him how to save the operation.
  • He applies what he learns and saves the day.

While there is nothing wrong with this structure, it is wearing a bit thin, at least to me. So I hope that the authors are going to find an interesting twist that surprises me. Still, because this is a novel with a point, vs. an attempt at classic literature, I’m not going to spend much time on the literary style.

The two main characters (so far) are Andrew Ward, the manager who finds out his plant is being closed, and Phil Jenkinson, the new CEO, with the double role of bringing the bad news (closing the plant) as well as filling the role of the Jonah (or sensei in this case, I suppose).

In the opening chapter, Jenkinson’s style is authoritative, bordering on confrontational. Without knowing the culture of this fictitious company, I can’t say whether his blunt, direct approach is from necessity or because he simply doesn’t have the skills to ask tough questions without pushing people back. I’ll hold judgment on that part. My hope is that the book doesn’t teach this approach as how it has to be done, because in my experience, it doesn’t have to work that way.

The message, though, is crystal clear. The old way isn’t cutting it. Leaders, not staff, are responsible for results (safety, quality, delivery, cost). Leaders are expected to know the hot spots in their operations. Leaders are expected to be involved in the details – not to micro manage, but to develop the capabilities of others. (That last one is a bit of an extrapolation on my part.) “Lean” is not a program, not projects run by a staff of specialists, it is how we will manage the company.

The notable quote from this chapter comes in a shop floor lecture given by Jenkensin and nicely sums up the relationship between process and results.

Results… are the outcome of a process. What we want are good results from a controlled process because they will be repeatable. Bad results from an uncontrolled process simply mean that we’re not doing our job. Good results from an uncontrolled process…only mean we’re lucky. Today, bad results from a controlled process just says that we’re stupid: We expect different results from doing the same thing over again.”

Based on that, I sketched out this little matrix that captured my response and the key points.

process vs results

But the technical nuances aside, this story is clearly developing into one about leadership. The key issues, so far, are:

  • Safety, quality, delivery, cost, are line leaders’ responsiblity, with assistance from technical staff – who are also experts.
  • Though it is certainly a culture shock, the leader is teaching by asking questions.
  • The various character’s reaction to the confrontive authoritative style is predictable. I am uneasy, at this point, with that approach being held up as an example of the best way to get this done. But it is only Chapter 1.

GO TO PART 2

First: Define Value

A couple of days ago, in “The First Steps of The Lean Journey,” I said that there really is no first step, only the next step from where ever you are right now.

I admit that I left out a big assumption there – that you know where you are trying to go.

More specifically, that you really know the value you create.

Bas Mathijsen has posed the question here on The Whiteboard, as well as in a post in the LEI Forums where asks (paraphrasing) “Who defines customer value?” and “What is customer value?”

Good questions, and we don’t spend enough time there.
I have seen a lot of “improvement” effort dissipated because there was no clear idea of what the process was supposed to actually deliver.

As obvious as it seems, customer value is defined by no one but the customer. The transaction need not be monetary, or even commercial. A volunteer for a non-profit organization gives up time (and possibly money) and gets something in exchange. Usually that is some level of emotional satisfaction. A nonprofit that needs to attract volunteers needs to be conscious of this.

Since it is subjective, different customers are going to define “value” in different ways. Dan Sullivan once put it really well with this analogy (paraphrasing):

My neighbor has a really nice lawn. When he buys a lawnmower, he is interested in features like evenly cutting, ease of starting, how well it manages the clippings. But maybe I am looking for different things in a lawnmower. Maybe I hate mowing the lawn. I might be looking for a lawnmower that cuts the grass just below the roots.

Clearly these customers define “value” in different ways.

The other factor to keep in mind is that this isn’t a black-and-white thing. The value the customer finds in your product or service can be enhanced or diminished by an almost infinite matrix of circumstances. These include the magnitude of the (customer’s) problem you are solving, the degree of emotional satisfaction that is gained from your product or service, how easy (or aggravating) your sales and customer support processes are, the customer’s perception of your quality and a host of other intangibles. All of these translate into what (if anything!) the customer is willing to part with to get your product or service. Indeed, we have all heard of things that couldn’t be given away, or that had negative value.

The only real way to know what the customer truly values is to be the customer. This great little piece by Dan Markovitz on Evolving Excellence clearly shows how not to do it. Read the article, then do the opposite.

So, the customer defines what is valuable to him. What does the company do?

The company has to take their best information about customer value and translate it into specifications for the product and service they are going to provide. QFD is one formal way (though not the only way) to do this. Ultimately that becomes the product design. It is now up to production to actually deliver it at the target cost.

All well and good. Where this comes apart is (as always) at the seams.

Marketing and engineering “know best” and provide the “voice of the customer” when the customer actually isn’t even in the room.

The product may be specified, but the details aren’t worked through. There is only the most casual system to ensure that what is specified is actually what is built and delivered. Do you have a specified go/no-go outcome defined for each intermediate step in your process? Does that go beyond the product, and into the conditions required for success?

Delivery dates are given in terms of a range of time. In the USA the “cable guy” is famous for telling you he’ll be there between 9:00am and 4:00pm. We all laugh at how aggravating that is. But then think nothing of quoting “4-8 weeks” for a delivery window. WHEN is it supposed to be there?

Is your product support “leave it on the doorstep and run?” Do you follow-up with the customers and see what is, and is not, meeting their expectations? Do you solicit complaints (not simply collect them)?

All of these actions (or lack of them) will diminish your customer’s perception of value. Reputation and brand can carry past some transgressions, especially if there is really good follow-up. But even a 100 year old brand can be damaged, and the company is likely the last to know (not for want of clear signals).

The first step is “define value” but, to be clear, that means understanding what each and every step is doing to provide value to the next step in a long chain that both begins, and ends, with the customer.