Spaghetti Diagram: Turn Walking Routes Into Numbers You Can Act On

A Spaghetti Diagram records where people and material actually travel. You build the workplace layout, plot the movement routes in the order they happen, and the tool quantifies the motion waste that results. Every area, every stop and every route stays editable, so you can test a layout change without rebuilding the map.

The tool sits in the Measure phase of RDMAICS. By the time you open it you should already know which process you are studying and why. Measure is where you stop describing the problem and start sizing it. A Spaghetti Diagram is the right instrument when the suspected waste is physical. Walking. Fetching. Returning. Searching.

Reach for it when operators tell you the job feels busy but output stays flat. Reach for it when a layout grew by accident rather than by design. Avoid it when the constraint is queueing, waiting or information flow, because those wastes do not show up as distance on a floor plan.

The worked example in this guide is fictional. It is the sample data that loads with the tool, and it exists so you can learn the mechanics before you point the tool at your own floor.

The case is a pizza kitchen. One role is studied, the Operator. The process runs from reading the order to handing the finished pizza to dispatch. The current state has eight steps. Those steps move the Operator between an Order desk, Cold storage, a Preparation bench, an Oven, Packing and Dispatch.

Step four is the interesting one. The Operator returns to Cold storage to collect a forgotten topping, then walks back to the Preparation bench to finish preparation. That single return trip is the kind of detail a verbal description loses and a diagram keeps.

Start with the canvas. Turn the grid on so you have a visible reference, and turn snap on so areas and route points land cleanly. In the sample both are set to yes, and route style is set to straight routes.

Then set the scale. In the sample, one grid square equals 2. This is the single most important input in the whole tool. Every distance the tool reports is derived from it. If the scale is wrong, the layout will still look correct and every number will be wrong.

Place your areas next. For the current state these are the Order desk, Cold storage, the Preparation bench, the Oven, Packing and Dispatch. Size and position each one to match the real floor, not to make the diagram tidy. A diagram drawn for neatness will understate the walking.

With the layout in place, add the steps in sequence. Each row carries a step number, the role, the area and the activity. The current state reads in order: read ticket at the Order desk, collect ingredients from Cold storage, prepare pizza at the Preparation bench, collect forgotten topping from Cold storage, finish preparation at the Preparation bench, load oven at the Oven, pack order at Packing, and handover at Dispatch.

Order matters more than most people expect. The tool draws the route in the sequence you enter, so a mis-ordered step changes both the picture and the distance. Enter the steps as they happen, not as the standard work document says they should happen.

Record the return trips honestly. In the sample, step four is a second visit to Cold storage. If you merge that back into step two because it feels like an error rather than a step, you erase the exact waste you came to measure.

Once the routes are plotted, the tool quantifies the motion. The screen holds everything from the inputs through to the calculated result, so you can change an area position and watch the number respond.

The current state carries a value of 28 and 12 against every step. The future state carries 28 and 7. Those paired figures are what you compare. The first value is unchanged between states. The second drops from 12 to 7.

The tool also offers an AI review that explains the result in plain language. Treat that as a reading aid. The numbers on screen remain the evidence, and you should be able to defend them from the layout and the step list alone.

The future state in the sample has six steps rather than eight. The Operator reads a digital ticket at the Order desk, collects a kit from Point-of-use ingredients, prepares the pizza at the Preparation bench, loads the oven, packs the order and hands over at Dispatch.

Two changes drive the reduction. Cold storage has been replaced in the route by Point-of-use ingredients, which sits closer to the bench. And the return trip for the forgotten topping has gone, because the ingredients arrive as a kit.

This is where the Spaghetti Diagram earns its place. You did not argue about whether the kitchen layout was good. You proposed a specific change, redrew the route, and the tool reported the difference. The second value moves from 12 to 7 across the two states.

A completed diagram supports a narrow set of decisions well. It tells you whether relocating an area is worth the disruption. It tells you whether a point of use supply beats a central store for a given process. It tells you which repeat visits to attack first. It gives you a before and after that a team can see rather than argue about.

The mistakes are consistent across sites. The most common is drawing the intended process instead of the observed one. The second is setting the scale casually. The third is mixing several roles onto one canvas until the routes become unreadable.

A fourth mistake is stopping at the current state. A diagram of today without a proposed tomorrow is an observation, not an improvement. The sample data pairs the two deliberately.

The Spaghetti Diagram measures movement. It does not measure time. Two routes of identical distance can take very different amounts of time if one crosses a busy aisle and the other does not. The tool will not tell you that. You need observation, or a time study, to understand it.

It does not tell you whether a step should exist. It records that the Operator returned to Cold storage. It has no view on whether a better picking method, a checklist or a kit would prevent the return. That judgement is yours and the team's.

It does not cost anything. There is no figure here for labour saved, throughput gained or money recovered. The sample shows values moving from 12 to 7 in the future state. Converting that into a business case requires inputs the tool does not hold.

Finally, it does not validate itself. A diagram drawn from a tidy assumption will produce a confident, clean, wrong answer. The quality of the output depends entirely on whether someone stood on the floor and watched. The tool makes the measurement easy to record and easy to show. It cannot make it true.