Spaghetti Diagram (Future State): Size the Travel You Remove Before You Commit to the Change

The Spaghetti Diagram (Future State) tool maps the future-state movement of people, documents, or data to confirm travel distance and motion waste reductions. You list each path in the flow. You record what the path costs today in metres. You record what it will cost after the change. The tool adds both columns and reports the gap.

You reach for it in the Improve phase of RDMAICS, after Analyse has given you a cause you believe in. The current-state spaghetti diagram belongs earlier. It shows you the tangle. The future-state version is different in purpose. It is not a diagnosis. It is a proposal with a measurement attached.

The value is in the sequencing. Teams often jump from a diagnosed cause straight to a build. The future-state map forces a pause. You have to state, path by path, what the new flow looks like and what each leg will cost. If you cannot write the to-be number, you do not yet have a design. You have an intention.

It also gives you something to defend. When a sponsor asks why this change and not another, you can point at a worksheet rather than a feeling.

Everything below uses the sample data that ships with the tool. The case is fictional. It is included so you can see the shape of a complete worksheet before you build your own.

The flow is an invoice process. Paper arrives. Someone carries it to an entry desk. It moves to a match station, then to an approval desk, then to payment, then to an archive. Five legs. Each leg is a physical walk with a distance in metres.

The diagnosed cause behind this case is straightforward. The process is physical when it does not need to be. Every handover requires someone to move a document across a floor. The proposed change replaces the physical handovers with digital ones: portal ingestion at the front, automated flow between stations, digital routing to approval, system integration into payment, and automatic archiving at the end.

That is the hypothesis. The future-state map is how you size it.

The worksheet has one row per path. Each row carries a path or flow name, an as-is distance in metres, a to-be distance in metres, a calculated reduction, and a note explaining how the reduction is achieved.

In the sample, the five rows read as follows. Invoice receipt to entry desk is 22 metres today and 0 metres in the future, a reduction of 22 metres, with the note portal ingestion. Entry desk to match station is 15 metres today and 0 in the future, a reduction of 15 metres, noted as automated flow. Match to approval desk is 30 metres today and 0 in the future, a reduction of 30 metres, noted as digital routing. Approval to payment is 18 metres today and 0 in the future, a reduction of 18 metres, noted as system integration. Payment to archive is 25 metres today and 0 in the future, a reduction of 25 metres, noted as auto-archive.

Notice the discipline in the notes column. Each one names the mechanism that delivers the reduction. That matters more than it looks. A to-be number without a mechanism is a guess. A to-be number with a mechanism is a design decision you can argue about, test, or reject.

Notice also that every to-be distance in this sample is 0. That is a consequence of the design, not an assumption baked into the tool. The fields are editable. If your redesign relocates a desk rather than removing a walk, you enter the shorter distance, not zero.

The result panel reports four figures. Current distance is 110 metres. Future distance is 0 metres. Distance removed is 110 metres. Reduction is 100 per cent. The panel is marked as built from worksheet, which tells you the numbers are derived from the editable rows rather than entered separately.

The accompanying note is worth repeating. Distance reduction is calculated from the editable current and future distances. Change a row and the headline changes. The result is not a fixed claim. It is a live summary of whatever you have written in the table.

A chart sits beneath the headline figures. It plots current distance against future distance for each of the five paths, on a scale running from 0 to 32. The visual point is the gap. Each path shows a current bar and a future bar at zero. The longest bar is Match to approval desk at 30 metres, which tells you where the single largest contribution to the 110 metres sits.

The tool also offers an AI review that explains the result in context. Use it as a second reading, not a substitute for your own.

A future-state map earns its place by narrowing choices. Here is what the sample result lets you decide.

First, whether the change is worth piloting at all. A reduction of 110 metres across five paths is a concrete claim. You can take it to a sponsor and ask for a pilot on that basis.

Second, where to start if you cannot do everything at once. The Match to approval desk leg carries 30 metres, the largest single figure in the table. Payment to archive carries 25 metres. Invoice receipt to entry desk carries 22 metres. If digital routing is the easiest mechanism to stand up, the sequencing argument is already made for you.

Third, what to measure after the pilot. You have five named mechanisms and five target distances. Verification is simply a matter of walking the new flow and checking whether the to-be numbers held.

The most frequent error is writing zero because zero looks good. The sample reaches 100 per cent because every physical handover is replaced by a digital one. If your design keeps a person walking, the to-be number is not zero. Overstating the future state is the fastest way to lose credibility when the pilot result arrives.

The second mistake is leaving the notes column blank. Without a mechanism, you cannot review the row. Portal ingestion, automated flow, digital routing, system integration and auto-archive are each a specific commitment. Someone has to build them. Naming them in the worksheet makes the dependency visible.

The third mistake is treating distance as the whole benefit. Distance is a proxy for motion waste. It is a useful proxy because it is easy to measure and hard to argue with. It is not the same as time, cost, error rate, or capacity. The tool measures what it says it measures.

The fourth mistake is skipping the current-state measurement. If the 110 metres is estimated from memory rather than walked and recorded, every downstream figure inherits that error.

The Spaghetti Diagram (Future State) tool does not tell you whether the change is feasible. It does not know whether portal ingestion can be built, what it costs, how long it takes, or who owns the system. The sample reports 110 metres removed and 100 per cent reduction. It reports nothing about the effort required to get there.

It does not convert distance into money or hours. There is no rate in the worksheet and no conversion in the result. If your business case needs a dollar figure, you have to build that elsewhere, using assumptions you can defend separately.

It does not validate your to-be numbers. The result panel states plainly that the reduction is calculated from the editable current and future distances. Whatever you type is what it uses. The tool is honest arithmetic over your own estimates.

It does not account for new movement the change might introduce. A digital flow may remove walking and add a different kind of handling. If that happens, the worksheet will not catch it unless you add a row for it.

Finally, it does not replace the pilot. The future-state map sizes the gain before you commit. Confirming the gain is a Control phase job. Use this tool to decide what is worth testing, then go and test it.