Documentation / Calibration / Spreadsheet gage tracking

I — The incumbent

The spreadsheet is not a placeholder

It is what most gage programs actually run on, and it is better at parts of this than the software sold to replace it. Any honest account has to start there, because a page that opens by calling it primitive is talking to somebody who has already stopped reading.

Reference · No product claim on this page

Two independent signals say the same thing. The thirty-five-year category incumbent runs a webinar titled Outgrowing Excel: A Calibration Spreadsheet Reality Check: the competitor named by the category leader is a spreadsheet. And a gage-interface manufacturer publishes a guide to keyboard-wedge input in Excel, which vendors write for what customers actually do rather than for what they wish they did.

But “the spreadsheet” is doing two completely different jobs in most plants, and they fail in unrelated ways. Treating them as one problem is why replacement projects stall.

JOB 1  the register      which gages exist, when they are due
JOB 2  the bench sheet   the numbers, as they are measured

II — Job one: the register

A gage register in a spreadsheet does the obvious thing well. It lists instruments, it holds due dates, it sorts, and a conditional format turns the overdue rows red. For a small crib that is genuinely sufficient, and replacing it with software that does the same thing behind a login is not an improvement.

Where it breaks is specific, and none of it is about features:

FailureWhat it costs
No history, only stateA cell holds today’s due date. Overwriting it destroys the previous one, so there is no series to fit — which is exactly the data an interval analysis needs and the reason most programs cannot do one.
No audit trailWho changed a due date, when, and from what. A spreadsheet records the result of an edit and nothing about the edit.
Identifiers driftNothing enforces that an ID is unique or that a retired one is never reissued — and a reissued ID silently merges two instruments’ histories.
The copy problemSomeone takes a copy to work on. Now there are two registers and no way to tell which is current.
Certificates live elsewhereThe as-found numbers are in PDFs in a folder. The register holds a verdict, so the values needed later are one directory away and effectively unqueryable.
Nobody is told anythingThe register is passive. It reports overdue when opened, which is a different thing from telling somebody.
The honest summary of job one: a spreadsheet is a fine list and a poor record. Most of what goes wrong is not that it lacks features; it is that it stores the current state of things and discards how they got there.

III — Job two: the sheet at the bench

This is the one worth being precise about, because the ranking of the options is not the obvious one. There are four ways a number gets from an instrument into a record, and most plants run three of them at once.

WorkflowHuman transcriptionsError class it leaves behind
A · Clipboard, then type upTwoTranscription both times — and when the operator is busy, the sheet gets filled in from memory at the end of the run.
B · Excel at the benchOneTypos, and something worse: the value lands in the wrong row.
C · Keyboard wedge into ExcelZeroThe value is now exact. The wrong row problem survives completely intact.
D · A sheet that knows what it is asking forZeroRow is bound before the reading arrives, so the assignment error is designed out rather than hoped away.
Filling the sheet in from memory is the failure with no evidence. It is common, it produces a complete and tidy artifact, and nothing in the numbers distinguishes it from a run that was recorded as it happened. Any study built on it is measuring recall rather than the process, and no review of the finished sheet can tell.

IV — Why a value in the wrong row is worse than a typo

A typo is usually survivable. 2.51 typed as 25.1 is visibly absurd, sits outside every limit, and someone catches it.

A cell-navigation error is not like that. The measurement was taken correctly, the value is a real reading of a real feature, and it is written down one row from where it belongs. Every individual number remains plausible. Only the assignment is wrong, and there is no downstream statistic that can detect it, because nothing in the data is out of range. It corrupts a capability study, an R&R and a first-article report equally, and it corrupts them invisibly.

This is the part people get backwards about keyboard wedges. A wedge is the highest return-on-effort intervention available in shop-floor capture and it is worth doing on its own merits, but it is a typing robot. It fixes the error a reader would have caught and leaves untouched the error a reader would have missed, because it does not know which feature the number belongs to. It does not know which instrument sent it either, since the wire carries no identity at all.

V — What actually changes the answer

Ranked by how much they change, rather than by how much they cost:

ChangeWhat it fixes
Keep the history as well as the stateTurns a register into something an interval analysis can read. Costs nothing but a decision to append rather than overwrite.
Record as-found values rather than verdictsMakes both interval analysis and impact analysis possible at all. This is a purchase-order requirement rather than a software feature.
Bind the row before the reading arrivesRemoves the error class no statistic can find.
Bind the instrument at captureMakes reverse traceability a query rather than an investigation.
A wedgeRemoves transcription. Cheap, immediate, and does not address either binding.
Note the absence of “buy software” from that list. The first two are decisions about what is retained, and can be made in an existing spreadsheet. Most of the value in this domain is recovered by storing more of what already passes through the process.

VI — Sources and boundaries