In our last post, we talked about getting started on creating a value stream map. We said that creating a simple process map was a good place to start. Now, I could go through the steps of creating a process map but you and I both know that such instruction are…everywhere. Do a websearch for “how to create a process map” and you’ll get a few million hits. Essentially, you just draw boxes and arrows. Or put the process steps on Post-Its that you place on a sheet of newsprint you’ve taped to the wall. Rather than provide detailed instructions, I’ll just pass along a few hints and recommendations that I’ve found helpful.
First, discuss Suppliers and Inputs, then Outputs and Customers. Many of you will recognize this as the SIPOC (Suppliers, Inputs, Process, Outputs, Customer) approach to process mapping. I start with the Outputs/Customer discussion first by asking, “Who are the Customers of this process and what is the Output they expect?” Sometimes a process has a variety of Customers, each of whom expects different Outputs, so we might narrow it down to the Most Important Customers. In discussing expected Outputs, we pay attention to and document any specs or standards that need to be met. Then I ask a similar question: “What are the Inputs we need to begin this process and who are the Suppliers?” Again, the team might need to focus on the most important Inputs and/or Suppliers. And, again, the standards and criteria that Inputs must be should be discussed and documented.
Second, the team needs to decide just where the process map will start and where it will end. Generally, value stream maps start with the Supplier and end with the Customer, so that discussion doesn’t take long. Occasionally, though, a team might want to focus on a smaller portion of the overall value stream. Or the “distance” from initial supplier to ultimate customer might be long. (I once helped a team at an integrated steel mill create a value stream map. We didn’t start with “Digging up the iron ore” and end with a car owner. We focused on a smaller part of the value stream, from blast furnace to hot rolling. It worked out.)
Third, though some process maps use diamonds or some other shape to denote decision points, avoid their use in this case. I find that the use of “decision points” leads to very complicated maps as the team members think of every possible contingency that might exist and every possible variable that might impact the process. I usually start by saying, “We’re going to map the steps of the current state of the process but we are going to assume that everything goes the way it’s supposed to go.” That means we’re not, for example, have a decision point for “Does the product pass inspection?” after the “Inspection” step. We’re going to put the “Inspection” box on the map, then ask, “What happens next when parts pass inspection?” (Not to worry…we’ll get to all the variables that can occur at each step later on.)
How Much Detail?
A question almost always comes up when creating a process map: How much detail should we provide? The quick answer is: not much. A value stream map is pretty high level. It’s intended to show the most fundamental steps in the process. It’s not intended to capture everything that happens or might happen during a process. It’s certainly not intended to show each and every activity and task that takes place. Err on the side of less detail. You’re discussions will be lengthy enough as it is without getting completely bogged down in, say, how inspections are carried out or the steps to shipping different products. Most often, you’ll just put a box that says “Inspection” and another that says, “Shipping” and leave it at that. That said, I’ve almost always added or substracted detail after finishing a “rough draft” of a process map, so don’t get too picky either way. If someone is adamant about adding a step that you think is more detail than is needed, add it. Just don’t spend four meetings creating a process map that could easily have been completed in one or two meetings.
Fourth, keep the team on track. The objective is to create a current state map, not (at this point) to talk about all the things that can and do go wrong, not to talk about all the possible improvements, not even to talk, in much detail, about the process itself. Once a process step has been added, ask “Then what happens?” Do this all until the answer is “The customer gets it.”
At this point, you have a pretty simple, straighforward process map. In our next post, we’ll tell you what to do with it.