Jan 2 2014
Lean and Management Processes
An online sparring partner of 15 years, Bill Waddell, concluded our latest exchange with the following:
“Lean is comprised of three elements: Culture, management processes and tools. While you obviously have a keen awareness of the culture and tools, you continually under-appreciate the management processes, Michael.”
It is a 3-step progression: first, Bill makes a general statement of what Lean is, then he points out a serious shortcoming in my thinking, and finally he misspells my name.
As I am not trying to go global cosmic with Lean but instead remain focused on Manufacturing, rather than Bill’s three elements, I see Lean as having the four dimensions identified by Crispin Vincenti-Brown. Whatever you do has some content in each of the following:
- Engineering, in the design, implementation, and troubleshooting of production lines.
- Logistics and Production Control, covering both physical distribution and the processing of all information related to types and quantities of materials and good.
- Organization and People, covering the structure, sizing, responsibilities and modes of interaction of departments in production and support, to run daily operations, respond to emergencies, and improve.
- Metrics and Accountability. How results are measured and how these measurements are used.
Attention must be appropriately balanced in all of these dimensions and, if one is under-appreciated in the US, it is Engineering, not Management. Metrics and organization issues hog the attention; what little is left over goes towards Logistics and Production Control, and Engineering is taken for granted. The tail is wagging the dog, and reality bites back in the form of implementation failures.
What is a management process, and how does it differ from a tool? The term sounds like standard management speak, but, if you google it, the only unqualified reference to it that comes up is in Wikipedia, where it is defined as “a process of planning and controlling the organizing and leading execution of any type of activity.”
Since Henri Fayol, however, we have all been taught that the job of all managers is to plan, organize, control, and lead. In those terms, there doesn’t seem to be any difference between a “management process” and just “management.” All other Google responses are for the processes of managing different functions, like the “Project Management Process,” “Performance Management Process,” “Change Management Process,” or the “A3 Management Process.” The corresponding images are a variety of box-and-arrow diagrams, pyramids, wheel charts, dish charts, and waterfalls/swim lanes, as in the following examples:
A manufacturing process is the network of tasks to make a product from materials — with routes that merge, branch, and sometimes even loop. A business process, likewise, is a network of tasks to turn inputs into outputs, like the order fulfillment process that turns customer orders into deliveries. A political process is also a network of tasks leading to a particular result, like the election of a president or the approval of a budget. So, what about a management process? And what is the level of appreciation that it deserves?
Bill is the one who should really explain it, but, if I were to use this term, at the most basic level it would be for what I have been calling protocols, by which I mean the part of management work that is done by applying sets of rules or procedures rather than making judgement calls. They are pre-planned responses to events that might occur but are not part of routine operations. It can be the arrival of a new member into a team, the failure of a truck to show up, or a quality emergency.
This is the spirit of Toyota’s Change Point Management (CPM), in which the pre-planned responses are prepared by the teams that are potentially affected by the events and posted in the team’s work place. When the event occurs. all you have to do is retrieve the plan and you know what to do. And it is usually a better plan than what you would have improvised in the heat of the moment.
At a higher level, I would call process a protocol used to organize the way you make judgment calls. You can’t set the strategy of a company by applying rules, but you can use Hoshin Planning to organize the way you do it. A process like Hoshin Planning is akin to the rules of a game; it doesn’t determine how well the managers play. If they just comply with a mandate and go through the motions, they will produce a certain result. If, on the other hand, they understand what they are doing, connect it to their own work, and see the value in it, then they will produce a different result.
A good process does not guarantee a good outcome, and great teams have been able to coax performance out of dysfunctional processes. What is the proper level of appreciation for these management processes? Clearly, there is more to management than processes, and the best managers are those who excel at endeavors for which there is no script.
I learned to appreciate the relationship between management and engineering in Manufacturing from working with my mentor, Kei Abe. When he took me on as a junior partner in 1987, one of the first things I learned from him was to approach problems in a holistic manner, simultaneously at the technical and the managerial levels. I saw him coach a shop floor team on the details of SMED in the morning, and the board of directors on company strategy in the afternoon. It’s not a common mix of skills, but I believe it is what a manufacturing consultant should have.
José Ignacio Erausquin
January 3, 2014 @ 11:59 pm
I full y agree with Michel in the idea of not underestimating Engineering when implementing Lean Manufacturing. I had also the opportunity to learn my Lean basics with Kei Abe at the end of the 80’s and remember very well his ability to both help the Managing team to define the roadmap for a Lean turnaround and at the same time to provide the fundamental idea to fully change the Assembly process of our product from horizontal to vertical, with incredible Improvement in space requirements and productivity.
lean project management | SteeringCloud
January 4, 2014 @ 3:03 pm
[…] Lean and Management Processes | Michel Baudin's Blog https://michelbaudin.com/All other Google responses are for the processes of managing different functions, like the "Project Management Process," "Performance Management Process," "Change Management Process," or the "A3 Management … […]
Paul Quesada
January 6, 2014 @ 10:49 am
Comment in the TPS Principles and Practice discussion group on LinkedIn:
Jerry O'Dwyer
January 13, 2014 @ 5:37 am
Comment in the Lean & Kaizen discussion group on LinkedIn:
Michel Baudin
January 13, 2014 @ 6:32 am
When people tell you about “the way we do things around here,” it is usually with pride, as a feature that makes their organization special, and especially good at what it does. When it is spelled out, it is usually in the form of general principles rather than explicit rules, and you generally cannot understand them without seeing how they translate into actions.
I remember for example, the CEO of Harley Davidson explaining in an interview “the need to be close to customers,” but what he means by this is not clear until you see him dressed in biker leather on official occasions. The following picture is from the announcement of CEO Keith Wandell’s nomination as Chairman of the Board in 2009 in motorcycle.com:
Protocols, on the other hand, are specific,as in “When you pick up the phone, you say ‘Shipping and Receiving, how can I help you?'” If a truck is late, the protocol tells you when and whom you should call. When a new production operator shows up, it tells you the sequence of steps you have to take to integrate him or her into the team.
Protocols save time, but they are always imperfect, and relying on them too much may also blind you to the universe of events they don’t cover. You want protocols to help with routine situations, but you also want people to be able to improvise effective responses to exceptional events.
You don’t want people to be surprised by the onset of winter every year, but you do want them to have the ability and the confidence to figure out and do what needs to be done in the face of natural disasters — floods, fire, earthquakes — or radical changes in business conditions — the advent of a disruptive technology, the outbreak of war, or a deep recession.
Jordan Frank (@jordanfrank)
January 13, 2014 @ 12:36 pm
re: “what I have been calling protocols, by which I mean the part of management work that is done by applying sets of rules or procedures rather than making judgement calls. They are pre-planned responses to events that might occur but are not part of routine operations. It can be the arrival of a new member into a team, the failure of a truck to show up, or a quality emergency.”
These protocols are a mix of a Standard Operating Procedure and a Template Project / Set of tasks. A pattern I see in Emergency Response as well as in Manufacturing / business.
Jerry O'Dwyer
January 15, 2014 @ 5:34 am
Comment in the Lean & Kaizen discussion group on LinkedIn:
Michel Baudin
January 15, 2014 @ 6:05 am
Another way to express this is to make Tom DeMarco‘s distinction between methods and methodologies. A methodology is something like a 12-step process that you apply systematically regardless of context and is really an excuse for not thinking. Methods, on the other hand, are tools in a box that you decide to use when relevant.
30 years ago, I was responsible for testing a new version of a Manufacturing Execution System (MES) prior to releasing it for use in production. We did a great job of testing the function of the software. The user interface was straightforward, the transactions did the updates they were supposed to, and the results could be seen in reports. Then we delivered the software to a factory that used it as the rate of one transaction per second. At first, it worked fine. Within a week, however, it slowed down dramatically and crashed.
When the problem was eventually solved, it turned out that is was not with our application but with the database management system (DBMS) on which it was built. As it operated, the DBMS seized more and more of the computer’s memory and never released it, a problem now known as “memory leaks.” Once it had grabbed everything, it crashed.
Our methodology had not involved testing for that, and we were not even equipped to do it. The DBMS was provided to us by the largest computer company in the world at the time, and we had trusted its ability to test a DBMS product for something that essential.
To this day, I feel awful about the pain this put the plant through, particularly the systems engineers responsible for the availability of the MES. To my astonishment, they forgave me and we continued working together for several years afterwards. Enterprise software users, in those days, had low expectations for quality.
But this is the story I have in the back of my mind when I talk about the imperfections of protocols. We had done our testing “right,” but it was not enough.
Jerry O'Dwyer
January 17, 2014 @ 6:09 am
Comment in the Lean & Kaizen discussion group on LinkedIn: