This chapter is from the book
This chapter is from the book
This chapter is from the book
Frame 3: End-to-End Flow
Far too often, providing customer value is thought of as a series of separate input-process-output steps, rather than an integrated flow of work through an organization. But if no one takes an end-to-end view of a customer problem or a product as it moves through a work system, customer problems fall into the cracks between departments, hard-earned knowledge evaporates at handovers, and the things that customers will really value get lost along the way. Developing an understanding of the end-to-end flow of work through a work system is fundamental to systems thinking.
One way to evaluate the end-to-end workflow through your system is to draw a process flow map—also known as a value stream map—of the end-to-end flow of a product or a customer problem as it makes its way through your organization. There are two reasons for drawing these maps. They help you
- Discover the reasons for failure demand, so it can be eliminated
- Find waste in the workflow, so it can be removed
Eliminate Failure Demand
Failure demand is waste. So the best questions to ask are "Why is the process producing failure demand? What can be changed to prevent failure demand?" In general, your bias should be against creating a process map for failure demand, because every activity on that map would be waste. But there are times when a process map for failure demand can help you discover how to reduce and eventually eliminate the waste.
Failure Demand Process Map
We were at a Web portal company drawing a process map of the critical defect resolution process. The group wanted to start their map when a critical defect report reached the development team. But critical defect resolution is a break-fix problem, so the process should always be mapped starting when the customer discovers that something is broken (see Figure 1-3).
)
Figure 1-3 Critical defect process map
"I'm one of your customers," I said to get the mapping process started in the right place. "So let's say that I discover a critical defect. What do I do?"
"Call Level 1 customer support."
"Right. I know how that goes: They tell me I must be doing something wrong; nothing can be wrong with your system. So how long does it take me to convince them that it's your problem, not mine?"
"Maybe a couple of days" came the sheepish answer. Next my problem moves to Level 2 customer support; a day later my problem makes it to Level 3 customer support. Often there is not enough information at this point, so they need to get back to me about 30% of the time. This might take two days.
Just over a day later my problem reaches the development team, which looks at the problem report immediately. Thirty percent of the time they have to get back to Level 3 customer support, which takes another two days. But often (30% of the time) Level 3 customer support needs to get back to me to answer the development team's question. It takes two days to contact me and another day to get the answer back to the development team.
Once it's clear what the problem is, it takes four hours to develop a solution and one day to wait for testing, which takes another two days. An additional half day, on the average, is needed to fix problems discovered in testing. Finally the fix is deployed.
All told it takes an average of six and a half days for the customer support process and another three and a half days for development. So it takes an average of ten days to solve my problem.
"What if the first six and a half days disappeared?" I asked.
"You mean have customers call developers directly?" The development VP was appalled. It didn't seem like a productive path to take.
But then someone spoke up from the back of the room. "We did that," she said. "A few years ago when I was working in another company, we were going crazy, we needed to try something. So we got the CEO to let us bypass customer support. It worked well."
"Who answered the phones?" the development VP challenged.
"The developers did, in rotation," she responded.
"How much of their time did that take?" He was clearly skeptical.
"Well, we did a lot of experiments, and we quickly settled on two rules: (1) Immediately after a release, the responsible team staffed the phones. (2) Developers were required to create a knowledge base report accessible to customers for every call, before they could close it out.
"With those two rules, we were astonished at the results. We had 800 developers. Before we changed the process, 60% of development time was spent on critical defects. After we changed the process, 20% of development time was spent on critical defects."
By connecting developers directly with customers, this company effectively gained 320 experienced developers—for free.
Mary Poppendieck
Remember, all time spent handling failure demand is waste. So it is usually better to create a map of the process that creates failure, rather than mapping the process that handles failure. Your objective is not to handle failure demand more efficiently; it is to eliminate failure altogether. Before mapping the flow of failure demand, ask yourself, "What is causing the development process to produce failure demand in the first place? What can be changed in the process to prevent (or dramatically reduce) the failure demand?"
In particular, we recommend that you think hard before creating a process map for handling a change approval process. Customers don't usually see change approval systems as a value; they see the changes they need as a value, but asking for permission to make the change is annoying. If customers see your change request approval process as a nuisance, that process is handling failure demand. Instead of improving your change request approval process, consider why you should have one in the first place. A change request approval process for a system under development is usually a sign that the development process can't absorb new ideas or handle typical variation in your customers' situation. Perhaps you are making decisions too soon, or waiting too long to ask for feedback, or not leaving enough space in your plan to accommodate that feedback. Perhaps your customer engagement and collaboration practices are ineffective. Ask yourself, "How can we reorganize our process so it can discover changes more rapidly and accommodate changes more easily?"
Map Value Demand
A value stream map is a diagram of the end-to-end flow of value-creating work through your process; its purpose is to help you understand the workflow for value demand so you can improve your process. Usually a value stream map starts when a customer has a need and ends when the need is met; however, a time-to-market map may start when a product concept is approved and end when customers start realizing value from the product. Before you start a value stream map, use a time series chart, as we discussed in Frame 2: System Capability, to visualize the end-to-end flow time for an average item moving through your system. This is your current capability. The value stream map will show you how much of that time is spent actually adding value. 19
Value Stream Map
Henrik Kniberg showed a value stream map of the development process at a video game development company.20 The company was experiencing very long development times, which led to missed market windows and high overhead costs, not to mention the toll that lack of success took on the people developing the products.
Henrik described the value stream like this:
When someone—call him Sam—came up with an idea for a new game, he took a couple of hours to prepare a concept presentation. After about a month, the presentation was made to the idea review committee, and since this was a good idea, it went into the game backlog. This was not the only game in the queue, however; there were several others, so it took six months for graphics and sound designers to become available (see Figure 1-4).
)
Figure 1-4 Time-to-market value stream map
Once the designers were free, Lisa assigned the new game to them, and two months later the design was done. Only a week was wasted during those two months, but when the game was designed, it was put in the design-ready queue, where it languished for six months. When the development team finally got to the game, it was working on two other games at the same time, so it took three months to complete development, even though the team spent only one month of that time actually working on Sam's game. When the team was done, the game sat in the product-ready queue for six months, waiting for final integration and deployment. Finally, over two years after Sam initially had his idea, the game was released. During those two years, only three and a half months—or 14% of the time—were spent actually adding value to the game.
Diagnosis:
There is obviously too much in-process inventory in this system, too many handovers, and a lot of multitasking. To address all of these issues at the same time, the company created cross-functional teams, each of which developed one game at a time, end-to-end, with no handovers. The first team demonstrated that it could repeatedly develop new games in less than four months (six times faster than before).
Mary and Tom Poppendieck
Find the Biggest Opportunity
The purpose of a value stream map is to help spot opportunities to improve your process capability. When you compare the value-added time to the total process time, you get a feel for how much better things could be. Ask yourself, "Why do we have so much non-value-adding time? Is it really necessary? What's causing it?"
Generally the biggest delays or loopbacks in a value stream map provide the biggest opportunity for improving the process capability. We recommend that you pick the most likely opportunity and tackle it. Forget the value stream map while you work on improving your process; you can draw a new one once you have changed the process.
Don't take the ratio of value-added time to total process cycle time (the process cycle efficiency) too literally. We find that after the process is improved, a new value stream map might show that the process cycle efficiency has decreased! Why? Because there was a lot of waste in the process that was not recognized when the first value stream map was drawn; once you get used to seeing and removing waste, you tend to find a lot more of it.