The Routledge Companion to Lean Management is now available for pre-ordering. It is a compilation of contributions from multiple authors, edited by Torbjorn Netland, and Chapter 8 is my overview of Lean Logistics. The other co-authors include Dan Jones, Jim Womack, John Shook, Jeffrey Liker, Robert Hafey, John Bicheno, Glenn Ballard, Michael Ballé, Mary Poppendieck, and many others whose work I am not familiar with.
“In the first six to 12 months, get the turkeys out. Don’t drag your feet.”
The problem with this approach is that, at the outset of Lean transformation, management doesn’t know what it’s doing. It’s not the managers’ fault, but the skills of leading a Lean transformation in this particular organization have to be learned along the way.
More often than not, the author’s version of “addressing the issue early” means firing loyal employees for disagreeing with something you later realize was wrong. And the message it sends is not one of commitment but of a mixture of brutality, incompetence and disrespect.
In an invitation to the Lean Enterprise Academy ‘s Lean Summit 2014, David Brunt included the following summary of Lean since 1990:
“Early implementations focused on empowered teams and continuous improvement (kaizen) or attempts to replicate a pre-defined box of tools such as 5S, SMED, SPC and kanban. For others lean became synonymous with kaizen events – that were actually kaikaku – radically reconfiguring individual operations. For some, this led to them developing their version of Toyota’s famed Production System (TPS) including their own schematic ‘house’ or ‘temple’ of lean along with departments of continuous improvement specialists.”
It is a pretty accurate account of what happened — the only major omission being the omnipresent VSMs — and it goes a long way towards explaining why the vast majority of these efforts failed. They were limited at best to superficial details of TPS, included elements that were not part of TPS, and misjudged implementation priorities. Let’s us go through the list:
- “Empowered teams.” As a manager you have a team to work with. What decisions should you allow this team to make on its own? This is best subjected to the sleep-at-night test. Knowing that you are responsible for the outcome, what can you delegate to the team and still sleep at night? It obviously depends on the team. If it is a team of production operators with 10 years of TPS practice behind it, the answer will not be the same as if they are beginners. Implementations that start with empowering teams put the cart before the horse.
- “Continuous improvement (kaizen).” Lean, or TPS, are often described as approaches to continuous improvement (CI), when CI is in fact only one component of the system. You cannot convert a plant from mass production to Lean manufacturing by continuous improvement, because it is not about tweaking details. For example, if you have implemented cells in machining or assembly, you can make them perform better with CI, but you have to have cells first, and that is beyond the scope of CI.
- “Replicate a pre-defined box of tools.” It can work, if your situation is sufficiently similar to the one you are copying, you really know what the tools are, and you master them.
- SMED and Kanban are tools of TPS but often misunderstood. For example, you often see SMED used to try to increase equipment utilization instead of flexibility, and Kanban is often confused with the two-bin system or even reorder-point.
- SPC is not part of TPS. This is so shocking to American and European professionals trained by the Quality establishment that they just inserted it back in, regardless of what Toyota actually did. The latest examples of SPC control charts at Toyota are from the 1950s.
- 5S is part of TPS, but is mistakenly assumed easy to implement because its technical content is trivial. In fact, the absence of technical content is what makes it difficult to implement and certainly unfit for an initial project.
- “Kaizen events” are an American invention and not part of TPS. As Brunt points out, the name is misleading, because what they do is not Kaizen. The popularity of this method over the past 25 years and the confusion created by the name have in effect prevented Lean implementation from including the real Kaizen.
- “Departments of continuous improvement specialists.” The creation of these departments has often made Lean implementation into a function alongside Production Control, Maintenance, or Quality Assurance, with the result of making it a professional specialty instead of part of everybody’s job. It works to make a good show for outside visitors, but not for much else. This department cannot be large enough to have the capacity to do all that needs to be done. Even if it did, it does not have the authority to make the changes take root in daily operations.
These efforts failed because the approach was simplistic. Both the technical and managerial content of TPS are deeper and take a while to learn. A successful implementation, particularly is a different industry, is not based on copying tools but on understanding underlying principles and deploying them as appropriate to the new context.
Value Stream Mapping (VSM) is probably the main analysis tool and the most used in the lean toolbox. Easy to understand and handle, VSM is the starting point of improvement workshops and kaizen eve…
Thoughtful comments, as usual from Chris Hohmann.
However, we need to go further and question the wisdom of reducing Lean implementation to Value-Stream Mapping and kaizen events when neither tool is central to the Toyota Production System.
“Value-Stream Mapping,” which is really materials and information flow mapping, is a minor tool at Toyota, used only with suppliers who have delivery problems. And “kaizen events” don’t exist at Toyota.
“…Quietly, though, in Nagoya, Japan, Taiichi Ohno and his engineering colleagues at Toyota were perfecting what they came to call the Toyota production system, which we now know as lean production. Initially, lean was best known in the West by its tools: for example, kaizen workshops, where frontline workers solve knotty problems; kanban, the scheduling system for just-in-time production; and the andon cord, which, when pulled by any worker, causes a production line to stop…”
This article implies that the “Kaizen workshop” is a tool of the Toyota Production System, when in fact it is an American invention from the 1990s and what it does is not what is meant by Kaizen in Japan
Then the article describes Kanban as “the scheduling system for just-in-time production.” It is really only a a tool of scheduling among many, including heijunka, just-in-sequence, consignment… The last example, Andon cords, had been observed at Ford in 1931.
Even if this choice of examples is unfortunate, Toyota people invented many tools while adopting and refining existing ones, and it is true that each tool, taken out of context, is of limited value. Toyota’s merit is to have deployed them in a uniquely effective way as part of a system of production.
This is, however, not what the article says. It jumps instead to management disciplines, like “putting customers first,” an idea that bazaar merchants worldwide have had for millenia.
“Enabling workers to contribute to their fullest potential” and “constantly searching for better ways of working” is in fact something that Toyota has done better than its competitors. And these are sound management objectives, but you could pursue them and still not be competitive.
The article implies that the technical content of the Toyota production system is a detail. All that matters is focusing on customers and treating people right. Is it? I don’t think so.
This attitude is the root cause of the failure of so many “Lean implementations.” Until the technical content of the Toyota Production System is understood and properly valued, the Lean movement cannot claim “Mission Accomplished” in manufacturing.
See on www.mckinsey.com
“How do you make time for improvements?” asked a manager on The Lean Edge. The anonymous questioner is self-described as experienced in Lean and currently CEO of a company in the outdoor sports industry, with employees who want time to climb, backpack, canoe, etc. This question brought forth an unusually brutal answer from usually mild-mannered Art Smalley, casting doubt on the questioner’s actual experience of Lean and telling him or her to exercise leadership.
I would not be so harsh. The situation in the CEO’s company is best described by this cartoon I found on Scott Simmerman’s site:
Getting out of this dysfunctional mode of operation is not obvious, and can be a challenge even for someone who has experienced Lean in a company that has been working on it for a few years.
While I have never seen it acknowledged in the literature, my own experience is that first-line managers — whether called supervisors, group leaders, or area coordinators — are the key agents for improvement activity. As part of management, they have the clout needed to get support from Maintenance, Engineering, and other support groups; from being on the first line, they are in direct contact with production operators and communicate with them daily. This puts them in a unique position to lead improvement projects, but the way their job is set up in many companies prevents them doing it.
In the Toyota system in assembly, the first-line managers are in charge of four to six teams of four to six operators each, which translates to a minimum of 16 operators and a maximum of 36, with the actual average being near the low end. When NUMMI was running, the figure was an average of one first-line manager for 17 operators. Contrast this with a situation I encountered in many manufacturing companies, where each first-line manager had 80 to 100 operators, and had no time for anything but expediting parts, keeping records, and disciplining rogue operators. The upper managers were proud of this situation, and described it as “Lean.” They didn’t think it was a good idea to have more first-line managers because they are “non-value added.”
I don’t presume to know whether this is the case in the questioner’s sporting goods company but, if it is, reinforcing first-line management is a good place to start, particularly if it can be done by internal transfers, for example by giving engineers the opportunity to try their hand at running production. It must also be clear that these new first-line managers, with fewer operators, are expected to spend 30% of their time on improvement.
Starting continuous improvement in an organization is a bootstrapping process. Pilot projects not only demonstrate value but free resources and develop skills that allow you to ramp up the activity. For this to happen, the selection of pilot projects is critical and here are some of the conditions they must meet:
- They must be few in number. An organization that is starting out in Lean may have the capacity to undertake two projects, but not ten.
- They must be within the area of responsibility of a single first-line manager, to avoid the complexity associated with involving multiple departments.
- Each one must have tangible, measurable improvements at stake, at least in quality and productivity. Otherwise, they will not be “pilots” of anything.
- They must be feasible with current skills of the work force.
- They must be opportunities to develop new skills.
- The target area must have a sufficient remaining economic life. If you plan to shut it down in six months, don’t bother improving it.
- The first-line manager must perceive the project as an exciting opportunity.
Most “Lean initiatives” do not bother with such considerations. No wonder they fail.
In the US, many use the Japanese word “Sensei” for the people who help companies implement Lean; in Japan, they use the English word “Consultant.” On both sides, words borrowed from the other’s language have snob appeal, and give the jobs a mystique it doesn’t need or deserve.
See What to Expect from Lean Manufacturing Consultants for a Japanese perspective on this profession. As I also pointed out earlier, “sensei” (先生) is the Japanese word for school teacher. As a title, it is used through High School but not in Universities. You might use it to say that a person teaches at a university, but there is another word for “Professor” (Kyoju).
In Karate, there are six levels of instructors, from Deshi to Soke, and Sensei is the second lowest. The word is also attached to people’s names as a form of address, instead of “San,” either to make them feel respected for their expertise or sarcastically. It is nothing special.
In Lean, there is nothing a “Sensei” does that is different from what a good consultant would do. There is no need for new vocabulary. Consulting involves a business relationship that is different from employment, but the same kind of agreement also covers contractors as well as consultants.
What is the difference? Most people don’t see any, and many contractors call themselves “consultants.” The key distinction is that a contractor works like a temporary employee, while consultants advise, train, and coach employees. The contractor’s output is more tangible, but the ability to produce it walks out with the contractor, whereas the consultant transfers know-how that remains after the end of the engagement.
You hire a contractor to write control software for your production equipment, because you don’t have engineers who can do it, and you don’t think you have a need for this skill on an on-going basis. If, however, you think it should be available in your organization, you may bring in a consultant to help your managers set strategies and policies on equipment control programs, select tools, and learn how to use them.
There are as many ways to work as a consultant as there are fields in which they are needed. Often, the know-how they transfer is procedural. They tell companies how to comply with regulations, pass audits, get ISO certified, or win the Shingo Prize.
Less often, it is about thinking through business strategy and finding the right moves in management and technology to be competitive. It is much more challenging, and there is no 12-step methodology for it. Lean consulting is in the latter category, because Lean implementation cannot be reduced to a procedure to be rolled out without thinking in every organization, whether it makes sausages or airplanes.
It is challenging, but it is what high-level consultants have been doing ever since Frederick Taylor invented the profession 125 years ago. It does not need a new name.
I came across this article titled “Top 5 Reasons Lean Projects Fail” and thought I would jot down my own list of 8 big reasons for lean failure: 1 Let’s start with his article – viewing lean as a collection of projects. Too…
Good insights! I will have to come up with my own list.
See on www.idatix.com
See on Scoop.it – lean manufacturing
One of the most common mistakes that companies make when embarking on a lean program is trying to do too much at once. These “boil-the-ocean” initiatives are long, costly and often end up stalling under the weight of their own…
Scoop It just brough my attention to this 2 1/2-year old article by BCG consultants Michael Zinser and David Ryeson. Their key point is that a successful Lean implementation must start with a small number of well-chosen, pilot projects, and I agree.
I do, however, part company with them on two other issues. First, they only speak the language of money, relentlessly bringing up costs, savings, payoffs, metrics and incentives. I understand that this language is familiar and attractive to top management.
The article only cites examples of improvements that have a direct economic impact, but there are many aspects of Lean for which the relationship is indirect. Scoring a goal in tonight’s game has a direct impact on performance; building a championship team doesn’t.
Which brings me to my second disagreement with the authors: there is no consideration in their article of the need to develop the organization’s technical and managerial skills. They are just assumed to be there.
Lean is about developing a team that is able to compete at the highest level in your industry. If you already have such a team, you are probably not looking to implement Lean. If you don’t have it, you can’t start projects as if you did. Instead, you have to focus on projects that your team can do today and that will start it on its way. The biggest payoff and the practically possible do not always match.
This perspective is missing in their guidelines.
See on blogs.hbr.org