Many pundits out there think the economy has hit bottom. If the last couple of cycles are any indication, when things start picking up again, it is going to happen fast. As people scramble to retain or gain market share they are going to want more and want it now.
And, if the last couple of times are any indication, many businesses are going to be caught totally flat footed and struggling to increase their output. I would also imagine that the “never again” vows that they made as things were going down will, once again, go out the window.
So, short of building up a lot of inventory and/or investing in excess capacity, what can you do to be more prepared?
Continue to work toward the ideal of one-piece-flow.
This does a few things for you. If you do it right, you will progressively collapse the throughput time of your process. This will make you more responsive to changes and make you less vulnerable to forecast errors.
More importantly, though, is the understanding you gain as you do this work. You want to know the cycle time constraint of each and every process in the value chain. With that information, you can predict what will constrain you from reaching any given level of production, and start to work on those constraints. That does not mean you increase production, nor does it mean that you add capital equipment. It means you know exactly what you are capable of doing, and exactly what you must do to get to the next level. In other words, you have a plan that you can put into motion at any time.
Work to standardize and stabilize your processes.
This effort helps make your work more ready for people. Many operations today are running well below their capacity, and they have lost their performance edge. Problems are going unnoticed and unaddressed because they aren’t really affecting production right now. That will change, and change fast, in a ramp-up situation.
Worse, unstable and poorly understood processes translate to long, error-prone learning cycles for new people, or current people in doing different work.
Re-energize your daily kaizen and problem solving and start seeking out the things that are disrupting the work. That investment will not only develop your ability to respond quickly and robustly to growth, it will develop people’s skills as well.
Develop your people and organization.
This will help your people become more ready for the work.
Things may be slow today, but do you know who you would put into your next leadership positions as they open up? Have you developed those potential leaders? Have you thought through how you will organize and support the work as business expands?
The more preparation you can make now, the easier it will be when you get into a fast-moving dynamic growth period. You will already have a baseline plan, so you will only need to assess the situation, modify as appropriate, and carry it out. The more of this planning you can do now, the more thinking you will be able to put into execution.
Even people who are already in leadership positions can probably use skills development. There are a few easy things you can do that will pay great dividends in a fast-flux environment.
Look into the TWI programs. These address crucial skills that line leaders need to succeed. Ideally, people would demonstrate those skills before being put into leadership positions.
The side benefit is that these programs give people skills they can use today to make the workplace safer, more consistent, and more stable. In a growth situation, Job Instruction gives you a standard method to bring new people on board, or to flex people quickly into different work and get them up to speed.
Free up as much capacity as possible.
The bottom line results of kaizen are seen primarily in the form of additional capacity – you are able to produce more with the same resources. You might not need that additional capacity right now, but if you are living within your means today, you can put that additional capacity in your hip pocket. Then, the first round of sales growth can be met without any additional resources. The better you are at kaizen, the longer you can hold your resource levels the same while growing output. The only way to get better is to practice, and just like learning to play the piano, this means practice every day.
Understand your supply base.
How well do you know your suppliers? How quickly can they respond if your needs change dramatically? Do you know which supplier controls how quickly you can increase output? Do you know at what point that bottleneck shifts to a different supplier?
The other thing to consider here is the length of that supply chain. If you are bringing in things from overseas, there is one fundamental that many people try to wish away:
No matter how hard you try, you can’t change what is on the boat.
That might seem obvious in saying it, but it is amazing how many times that four or five week transportation time ends up negating any “cost savings” in lower prices.
I am not saying this is good or bad. I am saying to look beyond invoice and transportation prices and understand your enterprise value chain as a dynamic, moving thing with a response time to change. That response time becomes critical when things are changing. Know what that response time is, and manage to it. If you don’t like the answers, you have to alter the system somehow.
Bottom line: The time to get good is now.
When you are scrambling to meet demand, “there won’t be time” for kaizen, and there will be even less time to learn how to do it. The time to get good at it is now. Your alternative is growing your cost structure at least as fast as sales are growing. Experience has shown that your cost structure likely grows faster than sales, and additional earnings come only with non-linear growth – relying on volume to make up for ever thinner margins. That might look OK in the short-term, but it is a strategy of becoming ever less efficient.
The better prepared you are for the upside, the stronger you will be the the inevitable next cycle.
I remembered reading this years ago, and thought I had lost my copy. In the midst of my current file purge, I came across my photocopy of a photocopy of a photocopy that was passed around Boeing with the hand written notation “Hey team, this is a good read – enjoy!”
“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.”
.”
