Moving Beyond Spreadsheets

This is not an argument that spreadsheets are bad. They are one of the best tools ever built. It is an argument about what they are bad at, which is holding relationships.

What spreadsheets are genuinely good at

Worth saying first, because quality teams are usually told their spreadsheets are the problem by someone selling something. Spreadsheets are fast, universally available, need no training, need no permission, and let a competent engineer model something in an afternoon that would take a software team a quarter. Most quality departments run on them because they work.

What actually fails, specifically

The same fact in six places. A bore diameter of 24.00 +0.02/−0.00 exists in the drawing, the process sheet, the PFMEA, the control plan, the inspection sheet and the PPAP dimensional results. Six copies, typed by hand. The failure is not the typing — it is that there is no mechanism to make them agree.

Revisions expose it. The tolerance changes to +0.03. Now someone must find all six. They will find five. The sixth will be discovered by a customer, or by an auditor, or by a returned shipment. Nothing in a spreadsheet knows the other five files exist.

Revision control by filename. Control_Plan_P101_RevB_final_v2_JK.xlsx is not revision control. It cannot tell you who approved revision B, when it became effective, what changed from revision A, or whether the copy on the shop floor is the approved one.

Approvals in email. "Approved, thanks" in an inbox is not an approval record. It is not attached to the document, it does not survive the person leaving, and it cannot be produced on demand two years later.

Evidence gathering. An auditor asks for everything relating to one part for one customer over eighteen months. In a spreadsheet estate that is days of work, every time, and the result is a folder that is immediately stale.

Why the usual replacement fails too

Many teams escape spreadsheets into a document management system, and find they have not solved much. A repository gives you version numbers and an approval click — but the data is still trapped inside each file. The control plan is still a spreadsheet; it is now a spreadsheet with a revision number, stored next to a PFMEA it has no relationship with.

The distinction worth insisting on: is the source of truth the document, or the data? If a characteristic is a record that documents reference, changing it once is enough. If it is text inside six files, a repository has changed nothing except where the files live.

Moving without a twelve-month project

The reason teams stay on spreadsheets is rarely conviction. It is that migration sounds like a project nobody has budget for. Some things that make it smaller:

Start with one part family. Not the whole estate. One part, through the full chain, so the team sees the hand-offs work on something real.

Import rather than retype. Your spreadsheets already contain the data. A system that cannot take an Excel import is asking you to pay the transcription cost one final time.

Start where the pain is. Usually PPAP for a demanding customer, or the drift between the PFMEA and control plan. Solve the thing that hurts and the rest follows.

Do not migrate history. Closed submissions from three years ago can stay where they are. Migrate what is live.

Refuse the ERP prerequisite. If a vendor says you need an ERP integration before you can start, that is their architecture, not your requirement.

A reasonable test

Whatever you evaluate, ask one question: if I change this tolerance, what else changes on its own? If the answer is "nothing, you update each document" — it is a repository with a workflow. That may still be an improvement. It is not the thing that removes the reconciliation.