CASE STUDY 6.1: MY PROCESS, YOUR PROCESS, OUR PROCESS

A product data group created the marketing and manufacturing data- bases and “smart” product graphic symbols used by customers to create layouts and then order products. Together, this database work was the longest item on the new product development critical path. Standard time from start to release was nine months, often delaying new product commercialization. The process had for years resisted repeated attempts to improve it. As a last resort, the area manager asked for help from the office Lean team.

In doing background work, the Lean team found marked differences in how the database people did their work. Some seemed to start in the middle, some at or near the beginning, and no two people seemed to follow the same sequence of steps. In a series of intense work- shop sessions with the Lean team’s help, the database people agreed on a defined set of steps. In following sessions, they hammered out a sequence in which they would work through the steps.

One more workshop session produced on a large whiteboard a matrix of projects (as the rows) by process segments, and steps within segments (as the columns). With steady follow-up, the group came to follow the steps uniformly. Now it was possible for everyone to see the progression of work on each project, and daily stand-up meetings at the board enabled the team to mobilize help and develop an under- standing of problems when a project got hung up at a particular step.

A note on resistance: “Hammering out” is not too strong a descrip-

tion of what it took for these technical specialist office workers to agree, however grudgingly, to try the new process. Two factors were at work that led to overcoming their resistance to change, one internal to the department, one from outside.

The outside factor was the failure of all previous efforts over many years to reduce the bottleneck represented by the database process and the costly delays it added to product introductions. Even after completing implementation of a new enterprise resource planning (ERP) software system that encompassed engineering, marketing, manufactur- ing, order management, as well as database, there was no improvement in database throughput. Database was now a corporate-level problem, with the attendant pressure on management to find a better way.

There was no change in the value of treating people with dignity and respect. Now, however, it became clear that finding solutions to the database bottleneck had to go forward even if people did not like it—and that did not constitute disrespect for the database group. So, the department manager pushed for change more insistently and with greater firmness than his predecessors.

The internal factor was the power of value stream mapping. The mapping sessions revealed a veritable spaghetti bowl of rework, over- processing, and disconnected schedules and priorities, starting some work too early and other work too late; the map was nightmarish. It is said that reasonable people, given the same information, will reach gen- erally the same conclusions. That ultimately was the case here.

Supported by the department manager, the Lean team facilitators firmly but respectfully forced the database group to face the reality of their work processes. It was clearly reflected on the current state value stream map the database group had created, supported by the Lean team members. As part of the workshop, the database people had gone through Lean training. Now, in the value stream mapping sessions, the Lean team facilitators reinforced and interpreted the Lean lessons. Between their manager’s insistence and the Lean facili- tators’ support, enough of the database people realized they simply could not continue asserting their process could not be improved. They agreed, not without reluctance, on a future state that proved to be the key. In a matter of two years, the new process led to quadru- pled productivity in database, and over two-thirds reduction in cycle time. Now, this way of operating is taken as a given—and a point of pride—in the group.

Three years later, a similar process was implemented in the group responsible for modifying the databases when standard products were customized, or engineered to order, at a customer’s request. The data- base group consistently experienced rework because of incomplete or inaccurate inputs from the engineer-to-order team. And, the engineer- ing group was chronically late getting the new specs to the database team, which then had to rush, in addition to performing the frequently required rework. Often, the custom products missed the promised ship- ment date. Customers were unhappy, and so was everyone working in the process!

This time, Lean thinking had spread widely enough that there was little resistance from the engineers and database people to the idea that their process could be improved.

In a Lean project, the two groups worked together to create a value stream map of the steps in their processes. They immediately realized their steps needed to be interspersed with each other, and that working in batches in department silos was the cause of much of the rework in the database group. After creating a future state process design and value stream map, the project team created a daily update board show- ing the progression of work through the engineer-to-order and data- base process, and established agreed dwell times through each step in the process (Figure 6.1).

In a matter of a month, late releases and deliveries stopped, as though by magic. Both groups now swear by the power of this method of visually controlling their joint process.

CASE STUDY 6.2: INTERRUPTIONS