What do you recommend -- clarify roles and responsibilities first or reengineer the process first and then define R&R?
Dear Gemba Coach,
I have been engaged in lean transformations, coaching and enablement in manufacturing for 16 years. For the past three years, I have been in a service/office environment. When I look into the root cause of most problems, it is quite evident that the roles and responsibilities of the people engaged in the processes are not clear enough. In such cases, what do you recommend -- clarify the R&R first or reengineer the process first and then define R&R or something else?
This is a very interesting question. What makes you think that clarifying roles and responsibilities will help? Or for that matter, re-engineering the process? Bear with me, I am not being glib. One of my biggest surprises in studying Toyota is how roles and responsibilities were less clear than in other companies, and how much kaizen differs from reengineering processes (I have some idea about that; I published a book on business process reengineering in 1995).
The core assumptions of how to run an organization in the West came from, first, Max Weber’s studies of how the Prussian army had organized itself in terms of roles, responsibilities, and chain of command, and then from Frederick Taylor who introduced the idea that if engineers devised the perfect process, operators could run it productively, and finally from Henri Fayol who defined the main functions of the enterprise (technical, financial, commercial, production, etc.) These ideas had enormous merit at the time.
For instance, a professional “rational-legal” bureaucracy had the advantage of protecting professionals from the arbitrary (and often loopy) instructions from aristocrats; an engineer-driven process design of the “one best way” had the advantage of being able to integrate fast workers from the fields or immigrants into industrial production lines; and running separate functions had the immense advantage of being able to scale organizations to a global level. But each of these three principles stems from the mechanistic thinking that if each part of the mechanical system is efficient, the whole will be effective – which is simply not true.
The inventors of lean at Toyota had the same background. After all, they started making automated looms and then cars from scratch, and then built factories on rice paddy fields. They understood in-and-out both the product and the process of making the product. And they also realized that without infinite access to capital, they could never have the volume to compete with American firms (a situation we see today in the digital world trying to compete with either American or Chinese winner-takes-all ventures).
3 Very Big, Very Different Ideas
Sakichi, Kiichiro and Eiji Toyoda’s thinking was shaped by three very different ideas. First, Sakichi Toyoda invented looms to help workers produce, not to replace them. Then he invented the automatic shuttle change, again to make the job easier for the loom operator. And then he invented the andon stop to liberate the operator from having to watch the loom spew cotton to make sure no broken threads created defects in the produced fabrics. The result was spectacular productivity improvements, but not from wanting to turn people into robots. Quite the opposite, the intent was to free people’s time by putting human intelligence in the machines.
Kiichiro Toyoda came up with the notion of “just-in-time” (in English in his original Japanese manual) to reduce the unavoidable waste of having the various parts of the operations he was setting up work at their own rhythm and with their own batches in a typical Fordist manner (we’re still very impressed by Ford’s advances at Highland Park, but let’s not forget Ford drove the Ford Motor Company to near bankruptcy with the Rouge complex). Kiichiro Toyoda wanted to better coordinate sites, machines and people to produce more value whilst generating less waste – coordination was the point of just-in-time. After the hardships of the war and post-war Japan, in which Toyota found itself bankrupt, Eiji Toyoda took over and understood that greater coordination could only be achieved by the active involvement of every employee – and started the Toyota’s creative idea program with the slogan “good thinking, good products.” In a complete reversal of Taylorism, teams were formed to create ideas for improvements and workers were encouraged to review their own jobs to constantly implement improvements themselves.
This different set of ideas converged into creating a company with a very different focus as what we knew in the west. Toyota became obsessed with:
- The process point: This is where the tool touches the part, and value is really added. Process point is usually very hard to see as it often mixes the laws of physics, of context, and of human perception. The focus on “where the rubber meets the road” radically changes one’s perspective about work as all else – the organizing things so that the rubber meets the road – is now seen as unavoidable waste, but waste none the less.
- The human thinking about the process point: Industrial processes don’t happen naturally; they are invented, engineered, realized and measured by human beings. Humans are not robots, and Ford’s dream of detaching the brain that comes attached with the hands is just bizarre. Toyota leaders understood that the only way to improve the process point was to develop the thinking about it, which meant learning to better communicate across functional barriers.
For instance, I was on the Gemba recently with the CEO of a company that sells quite expensive made-to-order products for customers (B2C, not B2B). A key step in the sales process is the down payment. This is when customers put their money where their mouth is, and quite an emotional moment for the customer.
The CEO realized on the Gemba that the 10% down payment required by his business was often beyond customers’ credit card limits. So, the process point was that when the customer put his or her card in the machine, they had to go through the embarrassment of seeing the transaction refused and then discussing it with the salesperson, and all the time having more reasons to double think their purchase. When the CEO tried to address this with his management board, two things happened. First, nothing. No one was interested as this didn’t fall into anyone’s clear functional responsibility area. So, zip, nada. Next, when the CEO kept pushing, every functional head started explaining why the policy was set that way, was necessary and an unavoidable cost of doing business.
Better People, Better Processes
Next, the CEO put his managers together in a reengineering workshop, where the outcome of the cross-functional process redesign was: no down payment at all. This is what Paul Watzlawick calls an “ultra-solution” in his book How To Fail Most Successfully, an “atom bomb” solution that destroys the problem altogether (operation successful – patient dead), without solving it. Down payments are an important part of the sales process because the customer commits. We need a down payment. The problem is making it as smooth and natural as possible to move the customer on to the next step seamlessly – and make the purchasing process as pleasant as possible.
Yes, organizations need defined roles and responsibilities, to some extent. Yes, processes can be clarified. But the fact of the matter is that we need people to do what they’re good at and talk to each other, and processes are what people do, not the other way around. Better people who work better with each other will create better processes. Conversely, imagine having both more rigid roles and responsibilities and clearer reengineered processes, how will this guarantee better outcomes? This is one of the deepest lessons of practicing lean.
May I suggest a complete change of focus? As in the previous Gemba example, the difficulty in service/office environments is to catch the “process point” – in the previous case, where the company’s sales handling (administrating, really) process encounters the physical salesperson-to-customer buying process.
Before either clarifying roles or reengineering processes, how about going back to the Gemba and identifying more clearly the process points, drawing a work process cycle and a work outcome cycle and seeing how both either merge or diverge? The real challenge of lean thinking is abandoning our mechanistic thinking about humans turned into robots as they are squeezed into a role and linked through a process and, instead, adopt a people-centric approach of looking together at the process points to deepen our thinking about them and their impact on what customers are trying to do – so that we help customers rather than hinder them. This revolution in intent then leads to a revolution in managerial practice.
What can we do to instill some passion in leadership about our lean implementation?
Dear Gemba Coach,
I’m in a company that is trying to implement lean but sees it simply as a series of rote steps to iterate without the sort of passion by leadership inherent in a successful journey. What can we do to instill some passion?
Is agile project management simply lean thinking applied to software development?
Dear Gemba Coach,
You seem to distinguish between agile and lean, but to my understanding, agile is simply lean thinking applied to software development. Am I missing something?
Factory physics was once the rage, but I don't hear about it any more -- was it wrong?
Dear Gemba Coach,
What happened to factory physics? It used to be all the rage some years ago, but we hardly ever hear about it these days. Was it wrong?