“Sustaining the gains” is a frequent topic of discussion in the continuous improvement world. Often the discussion degenerates into a rant about “management commitment.”
But in the real world, people generally don’t sabotage improvements on purpose. (Though I have seen it happen, but only once.) The mechanism is far more subtle.
Before we get into what happens after improvements are made, let’s look at a common improvement process itself.
In many companies, the primary method for making improvements is through special events or projects. These are usually planned, organized and led by a staff specialist.
Although the exact methods and words vary, the general process usually looks something like this:
Identify an opportunity, select an area for improvement.
Analyze the current state.
Select an improvement team.
Teach the team members how to apply the improvement tools.
Facilitate the development of improvement ideas.
Work with the team members to implement them.
Wrap up with a report or presentation, including remaining action items for management.
A variation on this is where the team is chartered, and it is up to them to identify an opportunity. This approach was more common in the late 1980’s than it is today.
This process actually works. It is capable of making pretty dramatic changes over a short period of time, often only a few days.
So why do the results erode? Or put another way, what is the problem?
Take a look at the routine decisions that are made during normal work, especially the ones that result in some change to the process. Those decisions must be made, because people have to get something done. The question comes down to whether those decisions result in improving the new process, or eroding it somehow.
Once things are in operation, some kind of unforeseen event always happens. Guaranteed. It can be something that the improvement team didn’t think of. It can be a piece of malfunctioning equipment. Maybe there is a material shortage or a defective part is delivered. The same things happen in administrative processes, only the words are different. Incomplete information arrives.
It could even be a deliberate decision. A production rate change. A software upgrade. Making room for some other activity.
All of these things, no matter how small or inconsequential, force decisions to be made. “How do we deal with this this and get production going again?”
The person making that decision is either:
Fully capable of applying kaizen principles, and applies them in a solution to the problem.
Is not fully fully capable of applying kaizen principles, but knows that, and seeks assistance in finding a solution to the problem.
Is not fully capable, may or may not know this, and does the best he can to get production back on track.
Both (1) and (2) result in making the system better, more robust and more responsive.
(3) usually results in a little bit of erosion. Variation is accommodated, things are made a bit more complex, the layout is now less than optimal, the old process does not work as designed anymore so the team member must improvise a bit. That, in turn, introduces more variation into the process, and usually drives a cascade of these little decisions.
If there is no mechanism for problem escalation (and if there was, we would likely be in (1) or (2) in the first place), then this becomes the new way, and things are steadily creeping closer to where they were before the event happened.
Given enough time (which can be amazingly brief), the process reverts back to where it was, or morphs into something else entirely – but equally wasteful.
Meanwhile the improvement specialists have moved on to the next project. Even if the local leader did ask for assistance, they might not be available, or worse, they tell him to figure it out.
Follow this with an “audit” that dings the local leader for “not supporting the changes” and wonder why he is less than enthusiastic about this kind of help.
Here is the question I want to leave hanging out there:
What was the intent of the kaizen event? (and was that intent accomplished?)
I was cleaning out some old stuff and came across a folded piece of paper with notes on it. They were from my parting comments to a kaizen event team that had put in a great week with spectacular results. They had started out wanting to improve the delivery of WIP to and from the warehouse.
When we went to the shop floor to see the current situation, what I saw was much more opportunity. It took a little work, especially with the area manager, but by the end of the week they had gone from needing 5 work cells with 6 people each – plus more to meet the holiday seasonal production – to 4 production cells with 5 people each, that could comfortably meet the rush. Not bad for a week’s work.
That’s the background.
When I look at old notes like this, I am always comparing what I knew then with what I know now. Now and than I turn up something that gives a hint that I knew what I was doing.
These comments were as much for the rest of the audience as they were for the team members themselves. After all, they knew what they did, and were fully aware of what they had to do next. But the other teams, and their collective bosses, needed to hear it as well.
Wow – great team. You caught flow fever early in the week and ran with it. You make me look like I knew what I was doing – thank you.
You connected the operations into a smooth flow.
Now you can begin the process of kaizen. Stick with it, stay on the shop floor, and work to stabilize the work. Many problems will come up. Help the work teams learn how to see them and solve them.
If you can save, and stabilize, a quarter of a second every day, in three months you can get another 20% of productivity. Think about that – and do the math for yourself.
What made this work?
First and foremost, we had the operational manager there, fully participating. He was skeptical at first, but once I sat down with him and went through his production requirements, step by step, he began to see things in terms of takt times and production leveling rather than just quantities to push out the door. That was a big shift.
The other big thing was having the team work off line for a few hours to construct a mock-up of a “typical” work cell. Then, without worrying a bit about the takt time, work to minimize the cycle time of one person going through the complete cycle. They learned for themselves that to save time you must study motion. We went through three or four cycles of granularity – every time they thought they had “the” solution, we introduced another tool to see the next level of extra motion. Through this exercise, they gained confidence that it was entirely possible to make a dramatic improvement in the “optimal layout” that they already had.
After that, it was a matter of getting to work. They watched the actual operators, and now could see the excess motions that were being driven by the way the work was arranged. They started making little adjustments – always being respectful of the workers. “We’d like to try something different here, just to see if it works better for you. May we just try something?”
That “May we try this?” attitude introduced something into the dynamic that doesn’t show up often enough – humility. Rather than these managers saying “We’ve got a better way, do it like this.” they were saying “We really don’t know if this will work or not,” and asking not only permission to try, but for input on whether it worked, or how it could work if it wasn’t quite there.
A lot of changes got implemented, but there was no arguing or friction because everything was just an experiment to see if it would work or not.
In the end, I saw something I had never seen before – the manager put in a budget request for a reduction, because he knew he could get it done with less, or at least figuring out how was within his reach.
That scrap of paper reminded me of a pretty good week.
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.
“What should be happening?”
“What is actually happening?”
The above two questions define the gap.
“Why does the gap exist?”
“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.
The work should be complete on time.
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.
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:
The work should be complete on time.
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.
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.
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.
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.
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.
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.
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.”
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.
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.
