At what level should we map? I’ve done VSMs where an entire factory (a big one, making lawn tractors) was merely a box on the map. Our focus was on logistics and distribution- we included inventory, capacity, and setup time in the factory box, but that was about it. On the other end of the spectrum, I’ve done VSMs for an Order Entry process. We got into much greater detail and discussed when/how credit approvals were done, etc. The level you go to really depends on your goals and scope of the VSM. If I were taking a first crack at VSM, I’d start door-to-door in a process, using major activities as my process boxes. If you find that one or more of these process boxes are real issues or need a better depth of understanding, you can complete a follow-up VSM on that process which includes more detail.
Prior to doing a walk-through, I like to list out the process steps we intend to put on our map. This is helpful for a couple reasons. First, it gives us solid start and stop points. We try to define this in the charter, but once we start listing it out, the team may have the desire to make minor adjustments. Second and more importantly, it gets us focused on the right level of detail for the VSM. This will help gauge the detail and depth we get into during the walk-through. If we start making the list of process steps, get 20 on the board and find we’re only about 1/4 through, we need to bring it up to a higher level. We likely have time limitations and the map has to be something most people can comprehend. I’ve seen process flow maps with over 100 boxes on them (I like to count things). Too much! Very few people can absorb something like that. On the other extreme, I’ve made maps where there are only one or two boxes. It’s hard to see any opportunities at that level…so we broke those boxes down further. Every map is different, but in general, I find perhaps 6 – 30 process boxes to be a good number to work with. I’ve occasionally done more or less, but it’s a guideline. The goal is to get to a good amount of detail while still making the map manageable.
I’ve drawn maps on white boards. I’ve draw maps on paper. I’ve drawn maps directly into Visio. I’ve attempted using Excel before and I do not recommend. If you want electronic documentation, Visio is a nice product for that.
The most common practice my peers and I use is creating the VSM on a sheet of craft paper using Post-It notes. We hang the paper on the wall with tape or push pins, create the map and then preserve it by entering it into Visio. Some prefer to simply use pictures. My hope is that VSM continues to be used, and an electronic copy of the map can be modified and distributed easily. A VSM should really be a living document.
I was recently in a lab with no available wall space, so we laid the craft paper out on tables. It wasn’t ideal, but it accomplished the job. Sometimes, you have to make do with what you have. I’ve also put the VSM directly into Visio. The direct input saves duplicate effort (first the wall, then the software) and is easier to read than most people’s handwriting. I practiced this for a few years, but returned to creating VSM on the wall first. One of the criticisms of a direct-to-Visio map is that it is less tangible for the participants. It’s something that I control on my hard drive. They can’t touch or look at it before, afterwards or during break. They can’t see the whole map if I’m focused on a small section of it. It’s my map, not theirs. Creating it on a wall makes it more of “their” map and allows better interaction with the team. I know good things are happening when team members are getting out of their chairs and walking up to the map to point out things and generate good resulting conversations.
Hint: Refrain from writing directly on the craft paper. If you must, use a pencil. It’s not uncommon for someone to suggest a change or add a process box. You’ll wish you hadn’t used permanent marker. If you want to use arrows to represent flow, you can purchase sticky arrows, although they are sometimes hard to find, or simply cut a 3x3Post-It note into 3 equal pieces, with adhesive on each. You can then draw an arrow and move it around on the map as needed.
In general, VSM is not a precise tool. Accuracy and precision may be required when working on subsequent projects such as line balancing, but don’t overanalyze during your VSM. We need to be in the ballpark /right order of magnitude / directionally correct, but not precise. If someone tells me setup time is 2 hours, and it’s really 1 hour 46 minutes with a 12 minute standard deviation, that’s fine in most cases. In the Value Stream Map, we really want to know if it’s a quick, medium, or long setup. Combined with the frequency of setups, this will help us better understand our current operation, and whether or not the changeover time is driving other things such as a large batch, lack of capacity, etc. This understanding will help us determine whether or not setup time is an issue or opportunity, and to what degree. If someone says they have a machine problem 5 times a day but it’s really 4, that’s fine because it won’t significantly change our understanding of the impact. If the real number is once per day, then that is a material misrepresentation of the real condition and may lead the Value Stream Map to a less impactful solution.
You can use ranges for data as well. I often hear that a value (perhaps setup time) varies from product to product. I’ll often represent that in a data box as an average and range: Setup = 45 minutes – 90 minutes, 60 minutes average. Alternatively, we may want to define different categories: Setup = 2.5 – 3.5 hours (full die change), 15 – 20 minutes (insert). And, define frequency of category: full change: 40%, etc. This may or may not be of value to the VSM, but I tend to include this information when I can. As long as it isn’t clutter, it may help the team understand the system better and drive improved solutions.
There are 3 types of truths: subjective, normative, and objective:
If I’m doing a transactional VSM, and I ask “what percent of the time does ‘X’ happen?” An individual might tell me it happens 20% of the time. Are they right? I really don’t know, but if that’s the best information I have, it goes on the map. If it’s deemed a critical value, we can always collect some data and update the map later. If the individual suggests 20%, and several others agree it’s a reasonable number, then I feel pretty good about the number. Perhaps it’s really 15% or 25%, but we’ll likely arrive at the same conclusions if we are that close. If the individual presents data they’ve collected, or perhaps from an MRP / ERP system, then we can be very confident - assuming it was tracked well.
With VSM being a rough tool, it does not require precision. We don’t need a 3-month study, at least not at this point, unless it’s a resulting study if you’re going to invest millions of dollars. We want close, directionally correct numbers. I may ask a machine operator how reliable her machine is and she may tell me 95%. I may then ask “so, over the course of a month, you collectively have 1 day or 8 hours of downtime?” She may agree; or put that way, she may respond that it’s more like 2 hours per month, in which case we’ll land on 99%. Other times, she may say “I don’t know”, in which case you can ask how many hours / days the machine has been down in the past 3 months. Always make sure employees know what you are doing, why you are doing it, and that it is not a personal evaluation of any sort.
To be continued in part 3 of the series, where you will learn about the customer and supplier details of a VSM.
At the end of the series on Friday, you will receive a complimentary download of A Practical Guide to Value Stream Mapping e-book. The e-book will go into further details of a Value Stream Map, including: