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 judgement 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 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.

9 comments on “Lean and Management Processes

  1. 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.

  2. Pingback: lean project management | SteeringCloud

  3. Comment in the TPS Principles and Practice discussion group on LinkedIn:

    I think in “Lean” there are production tools and management tools.
    I would agree that this distinction is important.

    I wouldn’t call it management “processes”.
    I’ve sometimes called it a management “system” (ie. TMS — Toyota Managent System).
    Other times I feel this is encompassed by calling it “The Toyota Way”, which impresses me as focusing more on the management tools than the production tools.
    (And then what’s “culture”? The willingness of the organization to use these tools? That’s what I would say.)

  4. Comment in the Lean & Kaizen discussion group on LinkedIn:

    I have re read your post several times and think it is excellent and thought provoking.

    Your last paragraph about Kei Abe does not surprise me. A good consultant should be a good project manager and therefore will be used to moving easily between shop floor project and senior management sponsor. To me , working with a senior team on strategy should have some of the same “protocols” (as you call them in your blog) as when you work with a shop floor kaizen group and if this occurs then you know that a “common” culture has started to emerge i.e. when both groups become uncomfortable when these “protocols” are not followed…..However , I agree that a person capable of helping a senior management team develop a strategy will require a certain set of technical and personal skills (not to mention b…ls) compared to those required to help the nightshift welding team solve a problem and these are not frequently combined in one person. Both situations can be equally intimidating in their own ways

    I think the key point is “processes”….or what you call protocols…because if you all can agree upon using good protocols and these appear logical to the participants then it makes both progress and facilitation easier. If these processes/protocols deliver results ( or learning followed by “adjustable” actions …because you use PDCA as a protocol …:) …) then people will gradually see the benefit of observing the protocols in future and will actually become “uncomfortable” if the protocol is not observed……you start to regularly hear stuff like “Let’s stop this and define the problem first” ….” Can we collect some data first ” …’Let’s go the Gemba and get the facts / observe” …which can be some of the signs of a cultural change emerging and I suggest that this is where process/protocols and culture merge and complement. It then becomes “the way we do things” . Fewer management strata, less silo more value stream / holistic approach and frequent Gemba contact help the speed the protocol adoption and achievement of culture change.

    If in management problem solving , for example if the senior managers did not transparently observe the protocols and rigour observed by a strong shop floor problem solving culture then would the shop floor culture ever survive ….in fact how did the shop floor culture ever come into being in the first place ? ….i would suggest that it is a temporary fad or initiative or some such phase rather than a sustainable culture.

    I have had the privilege to visit and work with many companies and those with a strong “culture ” want visitors to be aware and be able to follow their culture and “protocols” (ways of doing things) …so that (amongst other reasons) the visitor can have a successful interaction ….for example , you may be handed some information before you even turn up about how “we( the company) conduct meetings at every level” ….. What could be worse than following a meeting process that no one understands or is used to?… well worse still would be for you to use no process….even worse still would be for you to start following the company’s process only for a senior manager to say “screw all that ….let’s just …” and he dives off in random fashion and away from the agenda / objectives.

    What do you think ?

  5. 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:

    Harley Davidson CEO Keith Wandell in 2009

    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.

  6. 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.

  7. Comment in the Lean & Kaizen discussion group on LinkedIn:

    Michel ….fair points . It is interesting though that for example problem solving is “routine” ( to quote you) in the workplace and there are best known methods ( globally acknowledged as efficient , effective)…we could almost call it “standard work ” applied to problems……..yet some problems may be exceptionally complex , multi variate etc……or as you say “exceptional events” and in these circumstances there is always a balance between method / rigour and creativity . Indeed method may be the only way to tackle complexity …at least at the outset or until a creative solution emerges from the process ?

  8. 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.

  9. Comment in the Lean & Kaizen discussion group on LinkedIn:

    Michel …Yours is a great example and obviously very vivid for you. It is a good example of the methodology not being adequate or far reaching enough. The parallels that I think of are the contrast in styles needed in problem solving during methodical data analysis compared to the phases of brainstorming causes or brainstorming solutions …..both the latter call for freedom of thought meaning freedom of idea criticism until after the idea has been generated and recorded….ie encouraging creativity. If a problem solving does not include these distinct phases it will struggle …..in your example it was not just creativity which was missing but also the scope was limited so that “boundaries” were not examined (silo thinking?…I don’t know)

    Although I have no experience of software I have helped a software help desk improve their efficiency ( call handling , problem solving , standard work etc) …..your example reminds me of the interfacing of the software with myriad existing client systems.

    Good discussion !
    Do you think it has broadened our understanding of management processes ?

Leave a Reply

Your email address will not be published. Required fields are marked *