Value stream maps are simply good ol' process flow maps...with a twist.  We do a little extra data gathering around how long stuff sits between steps. 

I do value stream maps (VSM) as simply and quickly as I can, with a team, so that we can get talking about the value stream and how to improve it quickly.  I'm not much of one to use lots of symbols or to insist on lots of data.  (I've attached a value stream map from one of my clients that's been modified so as not reveal anything about the company.)  The value streams I've facilitated start and end at different places (i.e., back with the suppliers in some cases, first step in the manufacturing process in others, customer inquiry in still others) but I have a consistent approach otherwise.

First, lay out the steps of the process.  I simply ask, "What happens first?  Then what?  Then what?"  As we go along, the steps are connected with arrows.  This step can take several meetings because, quite often, the process in question has never been even informally mapped.  The answers to "Then what?" aren't always readily available.  In addition, the "Then what's?" don't always happen in a neat, serial fashion.  The "Then what's?" can take place as parallel steps, for example. 

Next, we go back through the map and answer the question, "How long does it take for info/material to get from this step to this step?"  Having used squares for the process steps, I use triangles for the "time steps", i.e., to capture the amount of time between each step.  As a first pass, I just get team members' best guesses as to the data to put into each "time step".  And, yes, these "best guesses" occasionally turn out to be way off the mark, so we do spend time verifying the data.  (This step in the process turns out to be an education in itself.  A recent VSM showed that the process being mapped...it was a supplier to customer map of a high volume product...was in better shape, lean-wise and agility-wise, than they thought.  In other cases, the learning has been in the other direction, i.e., the process was much slower than was thought.)

Another thing...as I'm getting these "best guesses", I get a range.  I'll ask "What's the quickest this ever happens?  What's the longest it might take?  How long does it take, typically?"  This is important because I stress that agility is a matter of getting variability out of a process and these data show how variable processes can be in their cycles times.  The sum of all the "longest it takes" times is often several hundred per cent greater than the total "least it takes" time.  I use this "total range" later in the process to generate discussion about the value of reducing variability in cycle time, even if we don't reduce average cycle time.

Then I have the team go back through the steps of the process and, at each step, brainstorm variances.  Variances are simply what can go wrong at each step. 

At that point, we have a map, some data about cycle times and some qualitative info about what goes bump in the night.  Now I get a discussion going by asking the following question, "Even if we don't take any cost out of the process, would we get a strategic advantage if we were able to reduce the either or both of the average cycle time and cycle time variability?"

More about this question and the sorts of discussions it generates in upcoming posts.