Business Process Mapping (Value Stream Mapping): How to Identify Losses and Growth Points
A short guide to VSM for product and project teams.
Value Stream Mapping (VSM) is a tool to see the actual flow of work, not how it "should" look. In small teams, VSM is a quick way to find bottlenecks, eliminate unnecessary movements, and reduce chaos.
Why Do VSM in a Small Team?
The main goal is to understand where time is being spent, not who is "to blame." When the flow is laid out on a single page, the illusion of "everything is fine with us" disappears. You see waiting times, delays, bottlenecks at input and output.
A simple example: the team complains about "long tasks." We map the flow and see that out of a 5-day cycle, actual work is 6 hours, everything else is waiting for confirmations and context switching. This is the growth point.
How to Map a Value Stream: A Short Guide
1. Gather People Who Actually Do the Work
Not managers, not process owners. Those who manually execute the steps. Otherwise, the map will be beautiful but useless.
2. Describe the Current Flow (as-is)
Quickly, without embellishment:
- what steps tasks go through from input to output;
- how long each step takes;
- where the task is waiting (in queue, for review, for data, for "confirm");
- what are the inputs, what are the outputs.
Tip: record numbers honestly. "Roughly half a day" is usually 1.5–2 days 🫠
3. Mark Loss Points
In VSM, there are usually several types, but in a small team, we look at three:
- Hand-off: transferring a task between people. Often, this is where things get stuck.
- Waiting: review, design, approvals, data—anything that slows down movement.
- Reworks: changes, clarifications, unclear requirements.
These points usually form the "painful" cycle.
4. Choose One or Two Metrics for Improvement
Don't touch everything at once—the system will break.
Basic metrics:
- Lead time — the full path of a task.
- Process time — actual work.
- % waiting — often the strongest indicator of pain.
- Variability — tasks of the same type take different amounts of time.
5. Plan a Small Experiment
Examples of micro-experiments:
- add an incoming task template to reduce reworks;
- agree on a "review window" twice a day;
- reduce hand-off: combine two steps into one;
- prepare data/access rights in advance.
The main thing is not "reorganization," but a small change that can be tested in 1–2 weeks.
6. Measure "Before" → "After"
Look not only at the average time but also at variability. If the spread has decreased—that's already a victory: the process has become more stable.
Where Hidden Losses Usually Lie
A short cheat sheet from practice:
- Unclear input — a task arrives "somehow."
- Dependence on one person — they get sick, the process halts.
- Design/review/development are done sequentially, instead of parallel preparation.
- Frequent context switching — time "actually" goes there.
- Communication debts — "what did we want here?"
These areas almost always yield quick improvements.
Mini-Checklist for VSM in a Small Team
- [ ] The map describes as-is, not "as it should be."
- [ ] Work time and waiting time are visible.
- [ ] Hand-offs and points of cyclical losses are marked.
- [ ] One metric and one hypothesis are chosen.
- [ ] The experiment takes no more than one cycle.
- [ ] There is a before/after comparison.
Simple "Loss Calculator" (manual)
Use to estimate the scale of problems:
Lead time = Σ(work) + Σ(waiting)
% waiting = Σ(waiting) / Lead time * 100
Percentage of actual work = Σ(work) / Lead time * 100
If the % of actual work < 30%, the flow can almost certainly be simplified with small, targeted changes.
Conclusion
VSM is not about a beautiful diagram, but about an honest conversation with the team. You bring chaos to the surface, see where tasks "die," and improve gradually, without revolutions.
Think: which process in your team "breaks" most often? Start with it—write a short "on-demand" regulation and live with it for one cycle. If it gets easier—you've created a living document.