Yamazumi Software vs Excel: Which Do You Actually Need?

Excel builds a perfectly good chart

A stacked bar per station, colour-coded segments per work element, a takt line drawn across it. Excel does all of this natively, and an engineer who understands the method can produce a defensible chart in an afternoon.

Any comparison that opens by claiming spreadsheets cannot do the job is selling something. They can. Building one by hand also teaches the arithmetic — how station totals accumulate, how takt is derived from demand, what balance efficiency actually measures — in a way that clicking through an application does not. Engineers who learned the method in a spreadsheet tend to read charts better for the rest of their careers.

Where Excel is genuinely the right tool

Spreadsheets remain the sensible choice in several common situations:

• One line with a handful of operators and a stable process, where an update takes minutes.
• Teaching and training, where the manual calculation is the point.
• A first improvement event, before anyone knows whether workload analysis will become routine.
• Low-volume, high-mix work where charts are rebuilt occasionally rather than continuously.
• Organisations at the start of a lean programme, where a stopwatch, a clipboard and a well-built workbook are enough to prove the method has value.

In all of these, the maintenance burden stays small enough that automation solves a problem you do not have.

The three things that break as complexity grows

Spreadsheet difficulties are rarely dramatic. They accumulate.

Re-entry

Every engineering change means retyping times, adding elements and reassigning work by hand. Each pass is small; the aggregate across several lines and frequent changes is not, and every transcription is an opportunity for a wrong digit that nothing will catch.

Formula drift

Workbooks grow by copying last quarter's sheet. Ranges shift, a reference breaks quietly, and a station total reads plausibly while being wrong. Nothing in a spreadsheet flags that a chart no longer matches its data — it will render an incorrect bar as confidently as a correct one.

Version divergence

As soon as more than one person edits, copies circulate by email and the file with the correct figures becomes a matter of opinion. This is the failure that most often ends the spreadsheet era: not that the tool fails, but that nobody can say which copy is current.

The real cost is engineering hours — do the arithmetic

Software licensing is the visible cost. Maintenance is the one that is actually being paid, and it does not appear in any budget line.

A worked estimate you can redo with your own numbers. Suppose a chart update — entering new times, checking formulas, reformatting the chart, preparing the summary — takes three hours. Suppose it happens twice a month per line, across six lines:

3 hours × 2 updates × 12 months × 6 lines = 432 hours per year

That is roughly a quarter of an engineer's year spent maintaining documents rather than analysing production. Whether that justifies dedicated software depends entirely on your own figures — a single line updated quarterly produces a number nowhere near this one, which is precisely why the calculation is worth doing before the decision rather than after.

The useful question is not "can we afford the software?" but "what is this maintenance already costing, and what would that engineering time otherwise produce?"

An honest feature comparison

The last row deserves more weight than comparison tables usually give it. A spreadsheet will do anything you can define. An application does what it was designed to do, well, and refuses the rest. For teams with genuinely unusual analysis requirements, that constraint is a real cost, not a rounding error.

What dedicated software does not solve

Worth stating plainly, because expecting otherwise is how implementations fail:

• It does not improve bad data. Estimated times produce wrong conclusions in any tool.
• It does not supply engineering judgement. Whether an element can move is a question about quality, ergonomics and reachability that no chart answers.
• It does not create adoption. Software nobody was trained on produces fewer charts than the spreadsheet it replaced.
• It does not fix undefined work. If work elements are named inconsistently between engineers, the tool will faithfully record the inconsistency.
• It does not deliver improvement. Analysis is not change; the floor still has to be altered and the result verified.

A plant with unreliable measurement and no standard work will get more from fixing those than from any application.

Video measurement is the actual dividing line

Feature tables tend to obscure the one difference that genuinely changes the work. A spreadsheet cannot watch a video.

The conventional workflow is to review a recording in a player, note times on paper, then type them into a workbook. Every step loses fidelity: element boundaries are set by reflex, the observation cannot be re-examined without repeating the whole exercise, and the transcription introduces its own errors. Six months on, when a figure is challenged, there is no way to check it short of re-recording.

Software that measures inside the video removes the transcription entirely. Element boundaries are set on the timeline, each segment stays linked to the frames it came from, and any number on the chart can be traced back to what was actually happening on the floor. For teams that have adopted video-based measurement, this — not chart automation — is the reason spreadsheets stop being viable.

Traceability and keeping the before state

Improvement work is only credible if the previous state survives. In a spreadsheet, the before state is whichever file someone remembered to save under a different name, and its provenance rests on the naming convention.

This matters more than it sounds. Most improvement claims are challenged eventually — during a customer audit, a management review, or when the numbers stop matching the plan. Being able to show the original chart, the elements it was built from, and the observation each time came from is the difference between an argument and a record.

Decision matrix

The threshold is not company size. A small plant running weekly video studies outgrows a spreadsheet faster than a large one charting twice a year.

If you do move, move deliberately

Migrations fail in predictable ways, and all of them are avoidable.

Standardise before importing. Agree work element names, measurement boundaries and classification rules first — carrying inconsistent definitions into a new tool preserves them rather than fixing them.

Start with one line. A single study taken from measurement through to a verified improvement teaches more than a plant-wide rollout, and it produces the evidence needed to justify the next step.

Expect the first study to be slower. Learning the tool and the discipline at once takes longer than the spreadsheet did. The gain appears at the second and third study, not the first.

Check what happens to your data. Whether analyses can be exported, in what formats, and whether they leave the building at all are questions worth settling before migration rather than during it. Yamazo Studio runs fully offline and exports to PDF, Excel, CSV and JSON — production video and the analysis built from it stay on the machine. It does not import third-party production data, which is a deliberate trade for that isolation.