In my last post, we were getting started on our map.  I was saying that, even a simple approach to mapping a process generates a lot of discussion.

OK, so you're asking the team, "What's next?" and filling in the squares.  Here are some issues you're likely to run into:

• Parallel processes
• Decision points
• "Forgotten" steps
• Steps that generate lots of other "feed in" steps
• Process loops

Capture parallel processes as best you can, assuming that capturing them adds value to the map.  Make sure decision points are needed in a "goes as desired" current state.  In other words, make sure they aren't really  "good vs. bad" decision points.  If they make sense and help the team map and understand the process, keep them. (In general, I try to keep decision points at a bare minimum in VSM's.)  "Forgetten" steps are those the the team remembers later in the map.  Just go ahead and add them in.  Steps that generate other "feed in" steps tend to be administrative steps like "produce the forecast" or "order the raw materials" or "Develop production plan".  Sometimes the team will want to map all the steps that need to take place to get that document or that piece of info.  I don't like to do this.  It slows the mapping process down and often doesn't add much info.  If it turns out that the step in question is problematic, you can always go back and develop that "feed in" process in more detail.

Once you have all the steps from first to last (circle to circle), go back to the first step and ask, "How long does this step take?"  (Make it clear that you're asking how long that one step takes to complete.  Teams will sometimes think you mean "How long from when one step starts until the next step starts?"  And that's not what you want.  For instance, if we're looking at two steps, "Make the Widget" followed by "Ship the Widget" and I point to the "Make" step and ask, "How long does this take?", the team might tell me how long it takes to make the widget and  get it to shipping and wait in shipping to get loaded onto a truck.  You need to separate all these times.)

Then the second step, the third and so on.

Then go back to the arrows, and ask, "How long does it take to get from the first step to the second step?"  "From the second to the third?"  And so on. 

When getting this info, I'll generally ask for it in three ways:

• What's the typical (or modal) amount of time it takes?
• What's the least amount of time it takes?
• What the most amount of time it takes?

In conversation, most folks understand "average" and "typical" to mean about the same thing.  But if the team is actually going to pull data together (as it should be) and we say, "Get the average time,"  the info that comes back will be skewed.  Most "time it takes" distributions aren't normal;  if the least time it takes to get between steps is one day and the most is 100 days, the mathematical average might be 50 days, something that actually happens only a small percentage of time.  We want to know the "On a typical day, how long does it take?" time, which is probably going to be more like two or three days.

The "least" and "most" times are just what you might think.  So, you have a range of times along with the typical time between in step.

Enough for now.  Tune in to my next post.