Lean Product and Process Developmentby the late Allan Ward is an interesting view into his extensive research into Toyota’s product development system. I am still reading it (along with Product Development for the Lean Enterprise by Michael Kennedy. The books present the same basic model in different ways, though I should point out that it Kennedy is obviously a protégé of Dr. Ward.
One key point really jumped out at me, and challenges the traditional mindset of the design engineering community.
The output of product development is a profitable value stream.
Think about that for a minute. How does this mindset alter the focus of the design engineering subtask of product development?
Duke left a great question as a comment to “A Morning Market.” He asked:
What’s the key differences between the [morning] market meeting and a gemba walk? Maybe I should ask what is the purpose of a gemba walk?
Good question.
I’ll start with one of my (other) favorite quotes from an old friend, Dave:
“It isn’t about shaking hands and kissing babies.”
That is to say, a lot of leaders think that heading out to the work area to “show the flag,” and do a meet-and-greet with the team members is “walking the gemba.” While they may be at the gemba, and they may actually be walking around, this isn’t it.
Walking the gemba is part of “Check” in Plan-Do-Check-Act. It is the process of carefully observing to see where things are not as they should be. Sometimes there is less walking involved, and more just standing and watching.
This, of course, begs the question: Watching for what? This, ultimately, is what makes it different than even just walking around looking.
Try this exercise. Go to some place where any activity is taking place. It really doesn’t matter what. If you aren’t in a factory, just go watch someone doing data entry or computer work. Watch the receptionist process walk-in customers and phone calls.
Note: Whatever you choose, please talk to people and tell them what you are doing, otherwise this is going to seem creepy to them if they aren’t used to it.
Get a feel for what is happening. More importantly, try to envision what is supposed to be happening. If this process were going perfectly, how would it look? Try hard to visualize in your mind a smooth, totally value-adding work flow.
Now, as you watch, become totally conscious of what is really happening. Why is this process other than how you visualized it? What disrupts the work? Where could mistakes be made? What keeps those mistakes from being made? Is it just vigilance? Or is there some mechanism to either prevent the mistake or either cue the person on the correct way, or alert them on the incorrect?
Is there any backtracking, rework, looping around? Are things where they are actually needed? Do people have to look around for things?
How do they know what they should be doing? What is their source of information? Do they have to hunt it down, or worse, guess at what should be done? Or is the “right thing” and the “right way” chrystal clear to even the casual observer (that would be you).
Is there a pace to the work? Even if it isn’t traditional takt-time work (especially if it isn’t), there is some kind of deadline. How does the person know whether things are on time or not? When do they learn they are behind?
If the person encounters some kind of problem, something unexpected, something needed but not there, what happens? Is there a support system to get this person back on-process? Or is he or she left to their own devices to just figure it out?
As you watch, keep your standard very high. If something is not obviously as it should be, then question whether it is. “Control” has the burden of proof here, not chaos.
When you see these things, focus in on one of them. Ask yourself “Why?” does this condition exist? Where does the problem originate? Go there. Study some more. How is it that this process fails to support its customer? Do they have a clear understanding of what is expected? (Probably not, most don’t, especially administrative processes.) How do they know they delivered (or didn’t) what their customer required? Did they think their output was defect free (according to their standards), but was really causing problems for their customer?
Often it helps to look at one person doing a single task, find a single issue, and follow the trap line upstream until you arrive at the origin of the problem. Often, again, you will have a fixable root cause right in front of you.
Now the fun begins. As a leader, it is not your job to fix the problem. That is not what you are looking for.
When you walk the gemba, you are assessing how well your organization is tuned to seeing these issues, clearing them, finding their causes, and solving them. If you see these opportunities, then your job now is to teach.
Grab whoever it is whose responsibility bounds both the effect and the origin of the problem. Guide him through the same things. If this issue was unaddressed, there are a couple of problems this leader must address.
First, there is someone downstream likely coping with an issue that he should be raising. (Or worse, there is no process for raising the issue, or worse still, no process to respond if he does.) If that isn’t happening, help this leader understand that this is the shortfall here, not the actual issue. It is now his turn to teach, in turn, either the Team Member, or whatever leader is between him and the Team Member.
Second, upstream, there is a process which either does not understand what “defect free” is, or does not have (or does not use) a positive way to verify it before sending it along. Same issue. This is a leader training process until the education reaches the level that should be doing the checks and the verifications.
The best way to learn how to do this is to walk your flow with someone who has the skill. It is simply a skill, and it can be taught. But learning also requires some humility, and the student must bring that to the “classroom.”
So, to recap in two short statements.
The gemba walk is a “Check” of Plan-Do-Check-Act.
You are checking the health of your leadership systems by looking at how they engage their people and processes.
Walking the gemba is a process of developing your people.
Kris Hallan is a frequent contributor on the LEI forum at lean.org.
In this post, he outlines some great experiences with trying to implement the “A3 process” in his organization. Lean Forums – A3.
One thing that really drove home what goes wrong most of the time with the A3 process, and frankly, with most well-intentioned efforts to bring good analysis into organizations, was his experience of an early effort to try to “require” it without having the behaviors to back it up:
One of the worst things you can do is require an A3 be written and then allow a poor A3 to get past you. This has a tendency to happen when you put an A3 mandate on something that you don’t necessarily have control over. For instance, we started by requiring all CAPEX [capital expenditure – ed] projects to be proposed using the A3 format (hoping that the A3 thought process would come with the format).
What we got was a lot of projects summarized on A3s and virtually no feedback to go back and improve anything. No one learned anything from the process, no hanei occured, and nemawashi was non-existent. It became a box that everyone had to check. This can have a very detrimental effect on people’s attitude toward A3. Since they don’t take it seriously, they can’t really learn anything from it. I would say that this actually moved us backwards in our understanding of problem solving.
I could not agree more. I have seen this in other companies. This is PLAN-DO without the CHECK and ACTion. Set an expectation, go through the motions of compliance, but don’t ever bother to see if it is actually working the way that is expected.
The good news, further into his post, is that Kris’s organization figured it out and found that doing it thoroughly is more important (and quicker!) than doing it fast.
In past posts, I have referred to an organization that implemented a “morning market” as a way to manage their problem solving efforts.
Synchronicity being what it is:
Barb, the driving force in the organization in my original story, wrote to tell me that their morning market is going strong – and remains the centerpiece of their problem solving culture. In 2008, she reports, their morning market drove close to 2000 non-trivial problems to ground. That is about 10/day. How well do you do?
Edited to add in March 2015: I heard from Barb again. It is still a core part of the organization’s culture.
So – to organizations trying to implement “a problem solving culture” and anyone else who is interested, I am going to get into some of the nuts and bolts of what we did there way back in 2003. (I am telling you when so that it sinks in that this is a change that has lasted and fundamentally altered the culture there.)
What is “A Morning Market?”
The term comes from Masaaki Imai’s book Gemba Kaizen pages 114 – 118. It is a short section, and does not give a lot of detail. The idea is to review defects “first thing in the morning when they are fresh” – thus the analogy to the early morning fish and produce markets. (For those who like Japanese jargon, the term is asaichi, but in general, with an English speaking audience, I prefer to use English terms.)
The concept is to display the actual defects, classified by what is known about them.
‘A’ problems: The cause is known. Countermeasures can be implemented immediately.
‘B’ problems: The cause is known, countermeasures are not known.
‘C’ problems: Cause is unknown.
Each morning the new defects are touched, felt, understood. (The actual objects). Then the team organizes to solve the problem. The plant manager should visit all of the morning markets so he can keep tabs on the kinds of problems they are seeing.
Simple, eh?
Putting It Into Practice
Fortunately we were not the pioneers within the company. That honor goes to another part of the company who was more than willing to share what they had learned, but their key lesson was “put two pieces of tape on a table, divide it into thirds, label them A, B and C and just try it.”
They were right – as always, it is impossible to design a perfect process, but it is possible to discover one. Some key points:
There is a meeting, and it is called “the morning market” but the meeting does not get the problems solved. The difference between the organizations that made this work and the ones that didn’t was clear: To make it work it is vital to carve out dedicated time for the problem solvers to work on solving problems. It can’t be a “when you get around to it” thing, it must be purposeful, organized work.
The meeting is not a place to work on solving problems. There is a huge temptation to discuss details, ask questions, try to describe problems, make and take suggestions about what it might be, or what might be tried. It took draconian facilitation to keep this from happening.
The purpose of the meeting is to quickly review the status of what is being worked on, quickly review new problems that have come up, and quickly manage who is working on what for the next 24 hours. That’s it.
The morning market must be an integral part of an escalation process. The purpose is to work on real problems that have actually happened. Work on them as they come up.
Just Getting Started
This was all done in the background of trying to implement a moving assembly line. There is a long back story there, but suffice it to say that the idea of a “line stop” was just coming into play. Everyone knew the principle of stopping the line for problems, but there was no real experience with it. As the line was being developed, there were lots of stops just to determine the work sequence and timing. But now it was in production.
The first point of confusion was the duration of a line stop. Some were under the impression that the line would remain stopped until the root cause of the problem was understood. “No, the line remains stopped until the problem can be contained,” meaning that safe operations that assure quality are in place.
The escalation process evolved, and for the first time in a long time, manufacturing engineers started getting involved in manufacturing.
The actual morning market meeting revolved around a whiteboard. At least at first. When they started, they filled the board with problems in a day or two. They called and said they wanted to start a computer database to track the problems. I told them “get another board.” In a few days that board, too, filled up. It really made sense now to start a computer database. Nope. “Get another board.” That board started to fill.
Then something interesting happened. They started clearing problems.
PDCA – Refining The Process
The tracking board evolved a little bit over time.
The first change was to add a discrete column that called out what immediate measures had been taken to contain the problem and allow safe, quality production to resume. This was important for two reasons.
First, it forced the team to distinguish between the temporary stop-gap measure that was put in immediately and the true root-cause / countermeasure that could, and would, come later. Previously the culture had been that once this initial action were taken, things were good. We deliberately called these “containments” and reserved the word “countermeasure” for the thing that actually addressed root cause. This was just to avoid confusion, there is no dogma about it.
Second, it reminded the team of what (probably wasteful) activity they should be able to remove from the process when / if the countermeasure actually works. This helped keep these temporary fixes from growing roots.
You can get an idea of what a typical problem board looked like here:
The columns were:
Date (initial date the problem was encountered)
Owner
Model (the product)
Part Number (what part was involved)
Description (of the part)
Problem (description of the problem)
A/B/C (which of the above categories the problem was now. Note that it can change as more is learned.
Containment Method
Root Cause (filled in when learned)
Countermeasure (best known being tried right now)
Due Date (when next action is due / reported)
Verified (how was the countermeasure verified as effective?)
A key point is that last column: Verified. The problem stays on the board until there is a verified countermeasure in place. That means they actually tested the countermeasure to make sure it worked. This is, for a lot of organizations, a big, big change. All too many take some action and “call it good.” Fire and forget. This little thing started shifting the culture of the organization toward checking things to make sure they did what they were thought to do.
Refining The Meeting
While this particular shop floor was not excessively loud, it was too loud for an effective meeting of more than 3-4 people. Rather than moving the meeting to a conference room, the team spent $50 at Wally World and bought a karaoke machine. This provided a nice, inexpensive P.A. system. It added the benefit that the microphone became a “talking stick” – it forced people to pay attention to one person at a time.
Developing Capability
The other gap in the process that emerged pretty quickly was the capability of the organization to solve problems. While there had been a Six Sigma program in place for quite a while, most of skill revolved around the kinds of problems that would classify as “black belt projects.” The basic troubleshooting and physical investigation skills were lacking.
After exploring a lot of options, the organization’s countermeasure was to adopt a standard packaged training program, give it to the people involved in working the problems, then expecting that they immediately start using the method. This, again, was a big change over most organization’s approach to training as “interesting.” In this case, the method was not only taught, it was adopted as a standard. That was a big help. A key lesson learned was that, rather than debate which “method” was better, just pick one and go. In the end, they are all pretty much the same, only the vocabulary is different.
Spreading The Concept
In this organization, the two biggest “hitters” every day were supplier part quality and supplier part shortages. This was pretty much a final-assembly and test only operation, so they were pretty vulnerable to supplier issues. This process drove a systematic approach to understand why the received part was defective vs. just replacing it. Eventually they started taking some of their quality assurance tools upstream and teaching them to key suppliers. Questions were asked such as “How can we verify this is a good part before the supplier ships it?” They also started acknowledging design and supplier capability (vs. just price and capacity) issues.
On the materials side, the supply chain people started their own morning market to work on the causes of shortages. I have covered their story here.
As they implemented their kanban system, morning markets sprang up in the warehouse to address their process breakdowns. Another one addressed the pick-and-delivery process that got kits to the line. Lost cards were addressed. Rather than just update a pick cart, there was interest in why they got it wrong in the first place, which ended up addressing bill-of-material issues, which, in turn, made the record more robust.
Managing The Priorities
Of course, at some point, the number of problems encountered can overwhelm the problem solvers. The next evolution replaced the white board with “problem solving strips.” These were strips of paper, a few inches high, the width of the white board, with the same columns on them (plus a little additional administrative information). This format let the team move problems around on the wall, group them, categorize them, and manage them better. Related issues could be grouped together and worked together. Supplier and internal workmanship issues could be grouped on the wall, making a good visual indication of where the issues were.
“Problem Strips” at the meeting.
But those were all side effects. The key was managing the workload.
Any organization has a limited capacity to work on stuff. The previous method of assignment had been that every problem was assigned to someone on the first day it was reviewed. It became clear pretty quickly that the half a dozen people actually doing the work were getting a little sick of being chided for not making any progress on problems 3, 4 and 5 because they were working on 1 and 2. In effect, the organization was leaving the prioritization to the problem solvers, and then second guessing their choices. This is not respectful of people.
The countermeasure – developed by the shop floor production manager, was to put the problems on the strips discussed above. The reason she did it was to be able to maintain an “unassigned” queue.
Any problem which was not being worked on was in the unassigned queue on the wall. All of the problems were captured, all were visible to everyone, but they recognized they couldn’t work on everything at once. As a technical person became available, he would pull the next problem from the queue.
There were two great things about this. First, the production manager could reshuffle the queue anytime she wanted. Thus the next one in line was always the one that she felt was the most important. This could be discussed, but ultimately it was her decision. Second is that the queue became a visual indicator that compared the rate of discovering problems (into the queue) with the rate of solving problems (out of the queue). This was a great “Check” on the capacity and capability of the organization vs. what they needed to do.
There were two, and only two, valid reasons for a problem to bypass this process.
There was a safety issue.
A defect had escaped the factory and resulted in a customer complaint.
In these cases, someone would be assigned to work on it right away. The problem that had been “theirs” was “parked.” This acknowledged the priority, rather than just giving him something else to do and expecting everything else to get done too. (This is respect for people.)
Incorporation of Other Tools
Later on, a quality inspection standard was adopted. Rather than making this something new, it was incorporated into the problem solving process itself. When a defect was found, the first step was to assess the process against the standard for the robustness of countermeasures. Not surprisingly, there was always a pretty significant gap between the level of countermeasures mandated by the standard and what was actually in place. The countermeasure was to bring the process up to the standard.
The standard itself classified a potential defect based on its possible consequences. For each of four levels, it specified how robust countermeasures should be for preventing error, detecting defects, checking the process, secondary checks and overall process review. Because it called out, not only technical countermeasures, but leadership standard work, this process began driving other thinking into the organization.
Effect On Designs
As you might imagine, there were a fair number of issues that traced back to the design itself. While it may have been necessary to live with some of these, there was an active product development cycle ongoing for new models. Some of the design issues managed to get addressed in subsequent designs, making them easier to “get right” in manufacturing.
What Was Left Out
The things that got onto the board generally required a technical professional to work them. These were not trivial problems. In fact, at first, they didn’t even bother with anything that stopped the line for less than 10 minutes (meaning they could rework / repair the problem and ship a good unit). But even though they turned this threshold down over time, there were hundreds of little things that didn’t get on the radar. And they shouldn’t… at least not onto this radar.
The morning market should address the things that are outside the scope of the shop floor work teams to address.
Another organization I know addressed these small problems really well with their organized and directed daily kaizen activity. Every day they captured everything that delayed the work. Five second stoppages were getting on to their radar. Time was dedicated every day at the end of the shift for the Team Members to work on the little things that tripped them up. They had support and resources – leadership that helped them, a work area to try out ideas, tools and materials to make all of the little gadgets that helped them make things better. They didn’t waste their time painting the floor, making things pretty, etc. unless that had been a source of confusion or other cause of delay. Although the engineers did work on problems as well, they did not have the work structure described above.
I would love to see the effect in an organization that does all of this at once.
No A3’s?
With the “A3” as all the rage today, I am sure someone is asking this question while reading this. No. We knew about A3’s, but the “problem solving strips” served about 75% of the purpose. Not everything, but they worked. Would a more formal A3 documentation have worked better? Not sure. This isn’t dogma. It is about applying sound, well thought out methodology, then checking to see if it is working as expected.
Summary
Is all of this stuff in place today? Honestly? I don’t know. [Update: As of the end of 2011, this process is still going strong and is strongly embedded as “the way we do things” in their culture.] And it was far from as perfect as I have described it. BUT organized problem solving made a huge difference in their performance, both tangible and intangible. In spite of huge pressure to source to low-labor areas, they are still in business. When I read “Chasing The Rabbit” I have to say that, in this case, they were almost there.
And finally, an epilogue:
This organization had a sister organization just across an alley – literally a 3 minute walk away. The sister organization was a poster-child for a “management by measurement” culture. The leadermanager person in charge sincerely believed that, if only he could incorporate the right measurements into his manager’s performance reviews, they would work together and do the right things. You can guess the result, but might not guess that this management team described themselves as “dysfunctional.” They tried to put in a “morning market” (as it was actually mandated to have one – something else that doesn’t work, by the way). There were some differences.
In the one that worked, top leaders showed up. They expected functional leaders to show up. The people solving the problems showed up. The meeting was facilitated by the assembly manager or the operations manager. After the meeting people stayed on the shop floor and worked on problems. Calendars were blocked out (which worked because this was a calendar driven culture) for shop floor problem solving. Over time the manufacturing engineers got to know the assemblers pretty well.
In the one that didn’t work, the meeting was facilitated conducted by a quality department staffer. The manufacturing engineers had other priorities because “they weren’t being measured on solving problems.” After the meeting, everyone went back to their desks and resumed what they had been doing.
There were a lot of other issues as well, but the bottom line is that “problem solving” took hold as “the way we do things” in one organization, and was regarded as yet another task in the other.
About 8 months into this, as they were trying, yet again, to get a kanban going, a group of supervisors came across the alley to see what their neighbors were doing. What they saw was not only the mechanics of moving cards and parts, but the process of managing problems. And the result of managing problems was that they saw problems as pointing them to where they needed to gain more understanding rather than problems as excuses. One of the supervisors later came to me, visibly shaken, with the quote “I now realize that these people work together in a fundamentally different way.” And that, in the end, was the result.
In the end? The organization in this story is still in business, still manufacturing things in a “high cost labor” market. The other one was closed down and outsourced in 2005.
The meaning of this famous quote, attributed to Taiichi Ohno, becomes much more clear in the context of “Chasing the Rabbit” and previous published research by Steven Spear.
Spear’s research goes beyond Toyota’s process and delves into a more general question about how any organization playing in an otherwise level field can continuously out perform similar organizations in similar circumstances. This makes Toyota is a subset or an instance of a very fundamental principle, rather than a special, complex, unique case.
I think that is important. Some critics say Spear is making a soft version of the TPS. I think quite the opposite. He is explaining why it works.
And why it works comes right back to Ohno’s quote.
To better understand Ohno’s quote, let’s compare Ohno’s context with Spear’s.
All of us have been taught Ohno’s three elements of standard work:
Takt time
Work sequence
Standard inventory
In “Decoding the DNA of the Toyota Production System” (a summary of his PhD dissertation), Spear describes the first rule-in-use he observed:
All activities are highly specified in terms of content, sequence, timing and outcome.
Further, Spear’s research concluded that the process steps themselves include frequent, nearly continuous, built-in checks that are designed to call attention to any departure from the specification. It is those built in checks which, on an assembly line, trigger an andon call and start the escalation process.
It is the escalation process which, in turn, results in problem solving and improvement.
It is any departure from the standard which calls the standard itself into question and results in investigation to understand more about the process.
The elements of takt, sequence and standard inventory define not only standard work, but they define elements of the built-in checks.
Takt time is the standard. Cycle time is the actual. Actual cycle time is compared to the takt every time the process is carried out. If it takes longer than expected – problem, andon, escalation, problem solving.
The defined work sequence is the standard. It is (or should be) checked against the actual work sequence every time it is carried out. If something knocks the worker off the standard sequence – problem, andon, escalation, problem solving.
The standard inventory is the minimum amount of inventory required for the process to be successful at takt. Just as the work cycle is timed against the takt time, actual inventory can be compared with the standard. Too little? The process gets halted. That is a problem. Andon, escalation, problem solving. How do you check for too much inventory? Inside a process, specified inventory locations (5S, folks!). Inventory out of place? That is a problem. Andon, escalation, problem solving.
In regular takt-based work, these things in combination are a very effective set of cross checks of actual vs. specified work. BUT these are only tools that set up the system for kaizen.
It is the problem solving – the seeking to understand why the exception occurred that is true kaizen. This should must happen rapidly and every day. Not just during special “events,” every day.
It is part of the work, just like putting on protective equipment, just like maintaining the machines, just like cleaning up. Only this part of the work actually improves the operation.
So – without first specifying what is supposed to happen, there is no way to determine if what actually happened is routine or cause for investigation, learning and improvement. Then the exceptions become the routine because there is no expectation of otherwise. Look up the term “normalizing of deviance” and get an idea what the ultimate consequences can be.
That is why the first step in improving a process is often to attack ambiguity itself. This is especially true in administrative processes, and it is critical at the points where one process step turns over work to another.
If a defect-free outcome has not been specified, people are left with the leadership cop-out of “do the best you can” and that results in continuous erosion of morale, quality, delivery, cost. It is anti-kaizen. It is what is very much like kaizan – faking it.
His recent book, “Chasing the Rabbit” brings his work from academic publications such as “The Harvard Business Review” into the mainstream business press.
One of the differences between Steven Spear and most other experts on the TPS is that Spear is, first and foremost, a student of theory. He does not make casual observation and render an opinion. Rather, he develops a formal theory then seeks to continuously test it against facts.
During his years of research into high-performing organizations, Spear has found consistent examples where – all conditions being equal; where products are a commodity; where the playing field is level – one organization in the field consistently outperforms the others over time. Spear builds on a metaphor of the front-runner in the Boston Marathon seemingly coasting to victory while the pack following him struggles, fights and elbows for the honor of coming in second. He calls these high-performing or high-velocity organizations the “rabbits.”
Spear’s theory of what differentiates the “rabbit” organizations is, ironically, that they consistently apply theory and theory testing into their management systems. I suppose it took someone who was well trained in the “theory of theory” to really see that. He has extended the application into a general set of principles that he has found across all organizations which excel. Further, he has found that mediocre operations which begin to apply the principles can rapidly and dramatically improve their performance.
He makes his case through example after example of organizations outperforming their peers and comps.
I am not going to repeat those stories here – you can click on the link above, buy the book, and read them for yourself. Rather, over a series of posts, I am going to go through some of the points in the book that struck me, share my mental notes, cite examples where I believe his theory holds, and hopefully spark some discussion.
On a world-class automobile assembly line, the actual work is continuously being compared to the planned work. In each work zone, there is a planned sequence of tasks which are expected to produce a specified output.
If there is any departure at all from the planned sequence, if things get behind the planned timeline, if the necessary conditions are not there, if any process step does not complete as required then either the Team Member or an automated system turns on a help call – an andon.
The response is immediate. The first response is within seconds with a priority of clearing the problem. The line itself is still moving, but if the problem is not cleared before the end of the takt time the line automatically stops – things go from “yellow” to “red.” When that happens, the responsibility for the problem also shifts up a level in the response chain.
The priority is still to clear the problem quickly – and clearing the problem means to restore conditions required for safety and quality without compromise.
Once the problem is cleared, and the line re-started, the rest of the problem solving process engages to find the cause of the problem and address it in the system itself. If the problem is outside of the bounds, or outside of the capability, of the original Team Leader to solve, then his chain-of-support will engage to help him solve it so that his skills can be improved.
In summary – we have a sequence of tasks to be accomplished over about six hours that, in the end, will result in a car. That sequence of tasks is further broken down into sub-intervals where progress against the plan is checked. If problems develop, the system responds, swarms the problem to clear it, understand it, and adjust the process if necessary.
None of the above should be a surprise.
But what happens in your management monthly reviews?
Huh? How are management monthly reviews related to an assembly line?
Let’s see. In a reasonably functional organization the business plan is (or should be!) a series of tasks to be accomplished over a period of time that, in the end, will deliver specified results. That sequence of tasks is further broken down into sub-intervals where progress of the plan is checked.
But in a typical monthly review, the analogy ends there. When problems develop, the reasons are discussed, mentioned, and worked around. In dysfunctional organizations only the objectives are discussed, and in truly dysfunctional organizations the objectives themselves are adjusted to match what is accomplished.
Shift your thinking a bit, and apply the assembly line analogy to its end-state.
The monthly review is the fixed-stop position. Up to this point, the person responsible for the task “owns” it. He should be checking progress and ensuring that things are getting done as specified, and that the results being achieved are as anticipated (predicted). He should be monitoring conditions and making sure that the operating assumptions are holding. Ideally those checks are built-in to the process and planning so that they are at least semi-automatic.
If all is “green” going into the monthly review, then things are great.
But if something is “off” – yellow – that is equivalent to an andon call. The responsible person is that first-responder. He has until the next review to clear the problem. Think about the ramifications here. This means that if the reviews with the boss are every month, the responsible manager better not wait until the week before to find out what is happening so he can report on it. He has to stay in touch with what is happening.
The monthly review is the fixed-stop-position at the review, and the “andon” goes red.
The reviewing manager now “owns” the problem. His job is now to ensure that there are effective countermeasures in place to get things back on track. That does not absolve the responsible manager, but rather, this becomes a “check” and an “act” for his professional development by the more senior leader.
Again, think of the ramifications. The responsible manager must not only be in touch with what is happening, he also needs to make sure his people are being developed and pushed to fully understand the problems as they occur.
The job of these leaders, at each level, is not only to keep intimately in touch with what is going on, but also be fully aware of the skills, gaps and development of their people. If someone should be able to handle an issue, but can’t, that is a skill gap that, like any other gap, must be addressed (in this case by developing the person).
In mediocre organizations, professional development is owned and overseen by H.R. and may be tied to the annual review process. In organizations that “get it” professional development is a natural part of the leadership process, and happens at all levels in the natural course of getting things done.
This is a bit of a more pragmatic breakdown from the “How Strong Is Your Immune System?” I plan to follow-up with some practical approaches and tools to implement and conduct the kind of problem solving that needs to be done every day.
As we “promote lean,” what expectations to we set?
How well do those promises match up with what is delivered?
If there is a gap, does it dampen the enthusiasm of “management support?”
I think this is important for us to understand.
In the enthusiasm to “make the case” many lean manufacturing proponents point (and rightly so) to the higher performance levels of organizations that have done it. They talk about greatly improved quality, much faster inventory turns, greater returns on capital, much quicker response and throughput. By whatever measure, these systems clearly perform better.
The implementers start teaching the system through its mechanics. Takt time to pace everything; one-piece-flow; pull systems, supermarkets and kanban; quick changeovers; standard work; mistake-proofing.
Now I will be the first to tell you – this is how I was taught – the “just do it, and you will understand” approach. But no matter how well-intended, there is the danger of a diluted message: “Copy the mechanics of how these operations work, and you too can have these results.” Or, put another way, it “Don’t ask questions, just do it” gets (mis)translated into “You don’t have to understand it.”
Wrong. You do.
An expectation is created that, by implementing the basic mechanics of takt, flow and pull, these terrific results can be achieved and sustained.
Here’s the rub. All of the “tools of lean” are designed to force problems to the surface and make them too obvious to ignore. There is an implied expectation that the organization will see these problems and take on the challenge of tackling them as they emerge – true kaizen.
Of course all of this presumes that the organization has the resources, skill and most importantly the stomach to deal with these problems quickly and efficiently.
Bluntly, most don’t. If they did then none of this would have been necessary in the first place.
By implementing the tools alone, they are in effect taking a Newcomen steam engine – primitive, big, inefficient, slow, but functional through brute force- and replacing it with a state of the art steam turbine.
Yes, the turbine is much more efficient, but if you took one and dropped it into the year 1715 it wouldn’t run for very long. They didn’t have the resources or the skill to operate or maintain it.
So, in our lean- implementing factory, the new system is put in and in fairly short order, all of the previously hidden and tolerated problems are now revealed.
And it reveals the problem of “no process to devote the time or to develop the resources and skills to handle those problems” – to detect them, fix them, understand them and solve them.
Lacking the time and skills, the first line leaders do what they must to get the job done… they return to the tried-and-true countermeasures that keep the problems from disrupting things too much:
This is the fate of many so-called “kaizen events” which seek to make great change in a hurry.
So why does this happen?
I can speculate that it is a combination of ignorance on the part of some implementers who “got” the “just do it” part but didn’t pick up the “think for yourself” part.
Somewhere, sometime, someone established a precedent that making dramatic but unvalidated changes to a system was “kaizen.” Perhaps, at some point, a sensei said “Don’t ask questions, try this…” with the intention that people would try it and learn what problems came up, only to have it turned into “Do this” without any follow-up or understanding.
Others, perhaps, have an underlying fear that if they revealed just how much work and change was really involved that the leaders would be scared off and not take the first steps.
Now, to be clear, a certain amount of “just try it” is required to anchor that initial leap of faith. But the implementers must be prepared to immediately guide, lead, teach, coach and build the problem solving capability of the organization.
But, in the end, digging further into “Why?” doesn’t give us any more actionable information. “The system is designed to surface problems, and there is no process to handle them” is a root cause that can be directly addressed. It is simply important to acknowledge the truth.
What to do about it. I’ll get into more detail in future posts, but to begin, here are some things to think about:
Small steps. (Note that “small steps” ≠ “slow steps”). Kaizen can be done rapidly, but it must be done deliberately in a context of understanding. Understand why things are the way they are, understand the effect your change should have. Try it out – ideally simulate if first – and see what problems surface. Solve those problems, then implement your change.
Dedicate and manage time for solving problems. This is briefly covered by a couple of previous posts, “Why Doesn’t Daily Kaizen Happen?” and “Systematic Problem Solving” but is worth repeating. Problem solving and kaizen are work, just like anything else. If you want it to happen, you need to allocate time, resources and management to organize it.
Develop a systematic approach, then follow it. I am going to go into some detail on this over the next few posts, but I need to emphasize the last part: then follow it. Too many “standards” are declared, then ignored.
Don’t wait for “the next event” to make improvements.
Just get started. Don’t wait until you are ready, you never will be. The only way to learn is to practice, observe yourself, see what works, what doesn’t, and learn. This, in turn, requires something that is sadly in very short supply in most corporations: humility. Learning means acknowledging, usually in public, that “we don’t have the answers” and perhaps that is the most important lesson.
I could digress into a leadership roles discussion here, but I won’t. But if you want to do a bit of pre-reading for future discussions, find a copy of “Learning to Lead at Toyota” by Steven Spear, and as you read it think about the role of the leader in that story. Bob, the protagonist, starts out with one role, and learns his role is actually quite different. There will be a quiz later.
At one level, this news drives home the state of the global economy. But let’s parse the story a bit and see if there is contrast about how Toyota handles this vs. how their competitors do.
First, of course, is the “…since 1941” part, compared to the record losses that have been reported by the rest of the sector for many quarters now. This is the first time the leadership has had to report a loss.
Gloom dominated the annual news conference by Toyota’s president, who in recent years had outlined ambitious expansion plans. This year, Toyota President Katsuaki Watanabe even refused to give a worldwide vehicle sales goal for 2009.
“The tough times are hitting us far faster, wider and deeper than expected,” he told reporters at Toyota’s Nagoya office. “This is an unprecedented crisis requiring urgent action.” [emphasis added]
So what will they do about it?
Watanabe vowed Toyota would grow so lean it would realize profitability even if its worldwide sales slid to as low as 7 million vehicles — what he called the basic “bottom line” for Toyota.
“We must change to become more slim, muscular and flexible,” he said.
While I am certainly not inside anyone’s board room, here is what I am reading between the lines.
In Lansing (GM), the attitude is that external forces are causing an otherwise well managed company to suffer hard times. “We can’t do anything about this, it’s not our fault.”
In Nagoya (Toyota) the attitude is “If we had managed well enough, this would not have happened. We need to examine ourselves and do something about this so it doesn’t happen again.”
Of course the whole mess is fraught with U.S. politics which will complicate things immensely. But it will still be interesting to watch.
Oh – and, while they are certainly in trouble, I believe our friends in Dearborn (Ford) got off the denial train a while ago. Time will tell if it was soon enough for them.
pages 114 – 118. It is a short section, and does not give a lot of detail. The idea is to review defects “first thing in the morning when they are fresh” – thus the analogy to the early morning fish and produce markets. (For those who like Japanese jargon, the term is asaichi, but in general, with an English speaking audience, I prefer to use English terms.)
” and previous published research by Steven Spear.
” summarized his PhD research on Toyota. His dissertation is the 