How to Get Started: Part Six - Implementation IV: Value Stream Mapping 5 - Current State Map
Now you're ready to start putting magic marker to flip chart and start documenting the Current State.
A reminder: I do this differently from what you've seen in the books. I use fewer symbols and gather a bit less information. It's not that I think my way is remarkably superior to that presented in, for example, Learning to See, but I do think it's easier. And I think the team is able to move more quickly.
Actually, there is a bit of work to do before starting the map. In fact, this work might have been done even before the previous step, Picking a Starting Point. You should spend a bit of time talking about the product you are mapping. How much of it do you sell each year? What are the margins on that product? What are the average inventory turns of that product? Any particular customer issues? What's the typical order size? Order frequency? Shipping lot size? Shipping frequency? What lead time is quoted to customers?
You don't have to get all this info before starting the map but you do need to be gathering the data earlier rather than later. I've found that simply discussing the need for these data shines light on issues surrounding the product and the process. Sometimes, even basic info isn't known. (A company ought to know how often and how much of its most important products it's shipping during a given period, for instance.)
In any case, once the info needed is determined, make assignments within the team to gather the needed data.
Before we actually begin, here are some things to keep in mind (and tell the team):
First, you are trying to document the current state assuming everything goes as it should. This means that you're not going to try to capture all the process loops and sidetracks necessary to correct problems that arise. This "rule" should also limit the amount of "if...then" decision points you put into the process. In other words, let's say you have an inspection step in the process. Map under the assumption that the product passes the inspection and goes on to the next step. You might say, "But this isn't realistic. The product won't always pass inspection and we need to account for the steps we carry out when it doesn't."
My response is:
OK...back to our map. You've decided where to start the map...put that step in a circle. (You're also going to put the final step in a circle.) Draw an arrow from the circle and ask the team, "What's the next step?" Put the answer in a square. Draw another arrow and ask, "Then what?" and put that answer in a square.
You'll find that this step can take a long time and generate lots of valuable discussion.
OK, this post has gone on long enough. I'll continue in my next one.
A reminder: I do this differently from what you've seen in the books. I use fewer symbols and gather a bit less information. It's not that I think my way is remarkably superior to that presented in, for example, Learning to See, but I do think it's easier. And I think the team is able to move more quickly.
Actually, there is a bit of work to do before starting the map. In fact, this work might have been done even before the previous step, Picking a Starting Point. You should spend a bit of time talking about the product you are mapping. How much of it do you sell each year? What are the margins on that product? What are the average inventory turns of that product? Any particular customer issues? What's the typical order size? Order frequency? Shipping lot size? Shipping frequency? What lead time is quoted to customers?
You don't have to get all this info before starting the map but you do need to be gathering the data earlier rather than later. I've found that simply discussing the need for these data shines light on issues surrounding the product and the process. Sometimes, even basic info isn't known. (A company ought to know how often and how much of its most important products it's shipping during a given period, for instance.)
In any case, once the info needed is determined, make assignments within the team to gather the needed data.
Before we actually begin, here are some things to keep in mind (and tell the team):
First, you are trying to document the current state assuming everything goes as it should. This means that you're not going to try to capture all the process loops and sidetracks necessary to correct problems that arise. This "rule" should also limit the amount of "if...then" decision points you put into the process. In other words, let's say you have an inspection step in the process. Map under the assumption that the product passes the inspection and goes on to the next step. You might say, "But this isn't realistic. The product won't always pass inspection and we need to account for the steps we carry out when it doesn't."
My response is:
- We're going to find enough opportunities for improvement even under the assumption that the process works as it's supposed to. If we also add in (at this point) all the problems and delays that we know occur, we'll never get finished.
- Anyway, we're not going to ignore problems and delays, we're just going to get to them later and in a different way.
OK...back to our map. You've decided where to start the map...put that step in a circle. (You're also going to put the final step in a circle.) Draw an arrow from the circle and ask the team, "What's the next step?" Put the answer in a square. Draw another arrow and ask, "Then what?" and put that answer in a square.
You'll find that this step can take a long time and generate lots of valuable discussion.
OK, this post has gone on long enough. I'll continue in my next one.


Comments