Home > Gemba Coach> What do you recommend -- clarify roles and responsibilities first or reengineer the process first and then define R&R?

What do you recommend -- clarify roles and responsibilities first or reengineer the process first and then define R&R?

10/16/2017
Permalink   |   3 Comments   |   Post a Comment   |  
  |   RSS

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:

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

3 Comments | Post a Comment
Raj Wall October 17, 2017

Michael, thank-you for this great article that has raised profound questions for me to work on with my software development teams. For example, what are our "process points"? How do we as lean managers enable thinking deeper together about them? What are the behaviors that encourage "better people to work better with each other to create better processes"?

Fernando October 18, 2017

Fully agree. Furthermore, precise roles tend to hinder teamwork and responsibility. This can be counter-intuitive, but just think for a second: a clear responsibility is also a boundary and anything out of it "is not my role" ... sounds familiar?  http://lnkd.in/ed85ZDc

Kevin Potts November 1, 2017

Good process design matters.

A part of good process design is to clearly Pre-specify who is responsible for doing certain jobs.

Eliminate ambiguity. Pre-specify everything.

Remember, standardized work (another part of good process design) for a job or set of tasks is designed to be performed by one person at a time. And it is crystal clear who will perform it in advance.

This is done to speed problem detection and solving. A clear place to start.

We don't allow a person to tighten a bolt one time and someone else the next. We don't allow an Engineer who is responsible to update the BOM pass the task to a production team leader or anyone else for that matter.

If an Engineer or production person feels they must pass some or all of their pre specified work, we insist they use the Andon instead (problem alert / visibility is part of good process design too).

For pre-specified work to be reassigned, job load studies, test trials and training would come first. But we would also answer 'why is that person doing that task'? Could their time be better spent on other, more value added tasks relative to their role?

It's okay to serve in different roles (i.e. HR/EHS mgr.) just make sure the tasks associated with those roles are done by whoever is in the role at the time. If the person is pawning off some of their EHS tasks, perhaps It's time for a rethinking of how the roles were designed...

Keep in mind who your internal customer is when designing a role and the tasks associated with it (a process). Keep in mind the persons role(s) relative to the value they add to the company reason to exist.

For example, although ECR documentation is important, assigning this task to a production person is MUDA. It robs them of time they could've spent helping HR, Engineering, Sales and other support functions get paid - by focusing on safely producing quality on time. Resist enabling any function to lose focus on what the company mission is.

Once everyone knows what they are going to do based on internal customer(s) have had their workload balanced and aligned to the company purpose, they then work with support functions (and others with job knowledge) to improve whatever job it is they do.

It's a rigid, yet flexible system (TPS).

Other Michael Ballé Related Content

Gold Mine Master Class

Books

Articles

Webinars