Is lean where we are going or how we are getting there?
Let me suggest that lean, like the term implies for the human body, is the absence of waste (fat), continuous flow of materials without interruption, and total engagement of people, resulting in high customer satisfaction. Without getting into a debate as to whether that is complete definition or not, (see previous posts) lets accept it just for the sake of the real point I want to make in this post.
But just as a lean body is a condition or state we would all like to achieve, it in no way describes a methodology for achieving that state. To achieve a lean body you could have liposuction, exercise every day, become a vegetarian, or just have good genes. I am sure we would not confuse the end state with the method of change or achieving that end state.
Change management methods are something completely separate from lean. The absence of sound change methodology is a major weakness in many lean implementations. Now, let me suggest that there is micro-change and macro-change; or, continuous improvement and what I like to call whole-system architecture. Both may be right at different times.
I spoke at a Toyota suppliers conference some years ago and the president of a supplier company got up and described the process of Toyota’s consulting group coming into his plant and completely redesigning everything. They sent all the workers home and told the president he had to stand by and not interfere. They ripped all the equipment out of the floor, moved everything around, completely reworked the flow, redesigned the jobs of both workers and managers, and then instructed them when they returned to the plant. This young president described it as a rather traumatic experience.
I sat with the Toyota consultants at lunch and asked them why they didn’t ask the workers to participate in designing the future state. Their answer was simple and direct. “We know and they do not know. Why would we ask them?” Not exactly the model of participation.
This was obviously not continuous improvement, but this was an implementation of Toyota Production System. It was revolution not evolution. It was not gradual experimentation by those on-the-spot, it was a whole-system change.
For many years before anyone heard of the term lean, I was a practitioner of socio-technical system design, or what we called Whole-System Architecture. Simple idea: in every organization there is a technical system – the work flow, equipment, job definitions, etc.; and there is a social system – who knows, who cares, who decides, who is informed, how are people organized into teams, what is the job of managers, etc.? The theory is simple – change is optimized by designing both the social and the technical system together and creating alignment. This theory comes fromm Eric Trist and Fred Emery at the Tavistock Institute and its early proponents in the U.S. were Bill Walton at Harvard, William Passmore, Lou Davis at UCLA and others. All the early self-directed team plants were created through socio-technical system design. These included Gaines Topeka and all the Proctor and Gamble plants. Ironically, it was Norman Bodek, who brought Shingo and others to the U.S. and translated their work, who introduced me to socio-tech.
I just completed a whole-system redesign of a home health care delivery organization in Canada. They had previously created a central planning/scheduling center (think central hotel reservations) where they both standardized and centralized the scheduling process. The nurses and managers out in the districts around the country had no control of the scheduling process because of this centralization. We formed a design team and in ten weeks redesigned the entire work flow from the time a customer calls needing a service provider to the time they get paid. Long story short: the time required to schedule a nurse declined from an average of five hours to an average of five minutes. A pre-survey of customers had indicated that 84% were either “very dissatisfied” or “somewhat dissatisfied” with the level of service. Two months after implementation ZERO
customers reported being either somewhat or very dissatisfied. Before the implementation nurse managers reported that they spent 80% of their time fighting fires, rework, etc. Now that has been eliminated. Now, every nurse is a member of a “primary care team” and the person doing the scheduling is part of their team. Now, the nurses do their own “load leveling” by adjusting their schedules to help each other, eliminate missed visits, etc.
This could not have been achieved through continuous improvement. It required a complete redefinition of the flow of the work, where people were located, the definition of jobs, the decision processes, etc., etc. It was a whole-system change and it eliminated a huge amount of waste. Now, they can and need to engage in continuous improvement. Now every team feels empowered to conduct experiments and find small improvements. They could not have done that in the old system.
Whole-System Architecture or socio-technical systems design is a high participation process of redesigning the system of the organization. It is not “lean.” It is a change methodology for achieving a lean end state. Just talking about lean or just implementing small improvement teams will never achieve the dramatic changes needed in many organizational systems. You must have a methodology for redesigning the whole-system.
The following, in very simple terms, describes the process of Whole-System Architecture. See the linked article in the Papers section for a more complete description of the process.
So, whether we call them Macro Kaizen events and micro Kaizen events, or continuous improvement and whole-system change, revolution vs. evolution, I don’t care. But, we should recognize the time and place for each. When people are not receiving the data, when they are not formed into teams, when their work is controlled by standard operating procedures defined by some distant person, and when the manager thinks it is his job to make all the decisions, continuous improvement is virtually impossible.
Although I had not heard the term “socio-technical design,” I wholeheartedly agree with it. The consulting firm I joined in 1987 was called Management & Technology Japan, led by Kei Abe, and the name said it all: you had to address the clients’ management and technical issues jointly. Working with Abe meant coaching a shop floor team on SMED in the morning and on the role of first-line managers in production in the afternoon.
I also agree with you that there is more to Lean than continuous improvement, and many people, including consultants and authors, are confused on this issue.
On the metaphor front, I wouldn’t equate Lean with the absence of fat in a human body, because the only way to achieve 0% body fat is to die of starvation.
Also, as I explained in my last blog post, I believe in having methods but no methodology. Methods are like tools in a box: as a professional, you pick which ones to use as needed to solve the problem at hand. A methodology, on the other hand, walks you through a sequence of 12 steps that supposedly leads to a solution regardless of what the problem is. A methodology is an excuse for not thinking.
I could not describe Lean as an end-state either, because it implies a full stop. For the same reason, I always talk about improvement and never about optimization. I prefer to view Lean as a pursuit, which never ends.
Michel, regarding the “fat” metaphor: Perhaps “absence of fat” is the wrong phrase. Reduction of fat would be more appropriate. You never completely eliminate fat in the human body, nor do you completely eliminate waste in an organization. The difference is that fat in the human body actually serves a valuable purpose in storing energy. I am not sure waste does the same in an organization.
That’s why I avoid equating the waste with fat. To me, by definition, waste is such that eliminating it does not decrease your performance in any way, and I see a phrase like “necessary waste” as a contradiction in terms.
Very interesting Larry, as it reminds me of the model an ex-GE employee presented to me as the Culture Change vs. Technical Change. He termed it Accelerated Change Process and I would equate it’s use with the Whole System Architecture Process vs. Continuous Improvement although some of the elements could certainly be used judiciously within incremental impovement teams. He built an equation of Quality (Technical Change) X Acceptance (Cultural Strategy) = Effectiveness. It is a 7 Step Process with measurement methods throughout the process to measure tension within the organization based on their ability to accept change. But like I said, it is mainly used for wholesale change similar to the Whole System Architecture and not incremental change.
On the issue where the Toyota consultants installed a new system, how did they teach the old managers how to manage the new system? My experience has seen great systems fall flat when management style (measures, rewards) did not follow suit.
Dan, I agree with you. Hence my argument for designing both the social and technical systems together and to be aligned. I don’t know the answer to the question. My feeling was that these Toyota guys were very oriented to the engineering side of things and knew a great deal about bending metal. I am not sure that they knew a great deal about change management, as we know it, or how to help the managers and employees to adapt.