Most work spends far more time waiting than being worked on. A value stream map makes that visible.
What it is
Value stream mapping grew out of Toyota's practice of drawing material and information flow. Mike Rother and John Shook's book Learning to See (1998) made it a standard Lean tool.
A value stream map follows one product or request from start to finish. For each step it shows:
- Process time. How long the work actually takes.
- Wait time. How long it sits before the next step.
- Inventory or queue. How many items are waiting.
- Information flow. How each step knows what to do next.
At the bottom is a timeline. The key number compares total process time with total lead time. It's common to find that work is actively touched for only a small share of the time it takes to get through.
Why people skipped it
The classic method is to walk the process, stopwatch in hand, and draw it on a big sheet of paper. It takes a day or more, and it's a snapshot that goes stale.
How a bot does it
Office and bot work leave timestamps everywhere: email received, file created, approval given, quote sent. A bot can build the map from those.
- Give it the logs. Email timestamps, file creation and modification times, ticket history, approval records, routine run logs.
- Have it trace a set of real items from start to finish. Twenty quotes, say.
- Have it split each step into work time and wait time.
- Have it draw the map as a table and timeline.
- Have it point to the biggest waits.
- A person walks the process once to check that the logs tell the truth.
The bot brief
Build a current-state value stream map for [process].
Inputs: [timestamp logs, file histories, approval records] covering [period].
Trace at least [20] real items from start to finish. List each item's timestamps.
For each step: median work time, median wait time before it, and current queue size.
Note how each step learns it has work (email, folder, schedule, person tells it).
Report total lead time vs total work time.
Identify the 3 largest waits and propose a cause for each, marked HYPOTHESIS.
Where logs don't show a step, write NOT IN LOGS. Don't invent times.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example: quote requests
| Step | Work time | Wait before it |
|---|---|---|
| RFQ email arrives | — | — |
| Bot drafts quote | 4 min | 2 hrs (routine runs every 2 hrs) |
| Estimator reviews | 10 min | 1.5 days (reviews in batches) |
| Sent to customer | 1 min | 3 hrs |
| Total | 15 min | about 2 days |
The bot is fast. The quote still takes two days. The fix isn't a better bot. It's how and when the estimator reviews, and how often the routine runs. See Lean for bots.
Where bots differ
Logs show when things happened, not why. A gap of a day might be waiting, or it might be someone doing real work offline. That's why a person still walks the process once.
And bots can create a new kind of inventory: drafts piling up unreviewed. A value stream map shows that pile clearly.
What this means for you
- Map one process from start to finish, using real timestamps.
- Compare work time to wait time.
- Attack the biggest wait, not the fastest step.
- Re-map after changes. With logs, it's cheap.