You've had to put up with several posts going on (and on) about Value Stream Mapping (VSM) concepts.  You're probably wondering when I'm going to get around to telling you actually how to do it. 

First, let me warn you....I take a decidedly idiosyncratic approach to VSM mapping because I don't like lots of detail.  A good book to get that goes into VSM from the classic, detailed point of view is Learning to See (order it from your friendly, local, independent bookstore...if you don't have one, here's mine).  Or just Google "Value Stream Map" and lots of stuff comes up (as I'm sure you've already determined if you're reading this). 

Here's the Chagrin River Consulting version of VSM (and, yes, it looks a lot like good ol' fashioned process mapping):

1. Pick a product or product family to map.  (I've also done processesthat don't have a manufactured product, mostly commonly Order Entry.)
2. Put a VSM team together.
3. Pick a start point (First manufacturing step?  Receive raw material from vendor?  Mining of  the iron ore?) and an end point (Packaged?  At shipping?  On the customer's dock?  Being used by the final customer?).
4. Using squares and arrows, map the current state process from start to end.  Map as if the current process flowed the way it's supposed to, i.e., don't put in all the loops and side processes needed to take care of stuff that goes wrong.
5. Go back to the arrows between steps and gather data (they can be rough data) as to the shortest and longest times for each.  You'll also want to know the modal or typical, not the average,  time for each arrow.
6. Go back to the boxes and gather data as to how long each process step takes and, especially, scrap and "leakage" at each step.
7. Still back at the boxes, brainstorm a list of typical (and maybe not-so-typical) variances that can occur at that step.  "Variances" are problems.  Anything that causes a delay, an error, a mistake, scrap, downtime, rework.  (At each step, brainstorm only that variances that occur at that step.)

This will give you a pretty good Current State map.

What about all that other stuff you typically see on VS maps?  I don't usually bother with that.  It's not that it isn't important.  It's just that I've usually gotten the client working on some of it (e.g., changeover times) anyway,  In addition, that can be a lot of data gathering and usually the team will be coming up with and eager to tackle significant problems before all that data gathering is done.  (It can be tough enough to get done such little gathering as I like for a team to undertake.)

Next time, I'll go into more detail on each of the steps.