Six months ago (yikes!) we were talking about how to develop and use Value Stream Maps. We had gotten to the point where we had put together a pretty good “Current State” map that included performance data. We said we’d look, in more detail, at the map and the data we had put together before we went on to creating a “Future State” map. And here we are…a mere SIX MONTHS LATER! So, let’s get going.
In our last post, we suggested a variety of questions that were intended to prompt ideas as to what sorts of data you should be gathering for your Current State map. Now, you need discuss the answers to those questions…the answers you have as a result of your data gathering. That first step of gathering data was like gathering clues at a crime scene. This step is like putting all those clues on the table and developing theories as to how the crime happened and who committed it. Every value stream map is different so it’s difficult to provide a “checklist” approach to working your way through the clues you’ve gathered but we can look at a few examples to help illustrate how to go about it.
I’m going to find a few examples of value stream maps on the internet and we’ll look at them together. Here’s the first: 
The first thing I notice is that there’s no scrap data. Get scrap data for your value stream maps. If cycle time at a process step is short and uptime is good but scrap is 33%, that’s going to be important to know. The other data I’d like to have would be something around the range of these variables, i.e., how much does the particular metric vary? Take that four days of inventory for packaged product, for example; is it always four days, no more and no less? Or is it sometimes 30 days of inventory and at others 10 days backlogged? It’s good to know those ranges. I’d rather see 10 days of inventory that only varies by a day or two than an average of 5 days of inventory that’s sometimes 25 days and other times 0 days.
Let’s look at that inventory; four days of packaged, finished goods isn’t bad (again, assuming it doesn’t vary by much). That’s 50 or so turns per year. But I also notice that there’s a total of almost a month of WIP in the process, and that doesn’t include raw material inventory. In other words, the operation could make product for a month without re-ordering. Again, 12 turns a year isn’t terrible but it does point to a improvement opportunity. Everything else being equal, there’s no particular reason why WIP between process steps can’t be, say, two days at most, and, ideally, even less.
I also notice that there are 10 days of inventory between Machine and Hone, even though Hone has a faster cycle time and 99% uptime. That doesn’t fit. I’d like to know what’s going on there. By the same token, I’d like to know why WIP between Hone and Deburr is seven days, even as Deburr has a much shorter cycle time. It has worse uptime, but 80% isn’t terrible, and, again, cycle time would allow me to make up for lost time. If we can address just these two issues so that WIP was reduced to four days between these process steps, we’d reduce WIP by 9 days for the overall process, not an insignificant improvement.
There are a few other things we could look into here but that would be a good start. Let’s look at another example in our next post.