Excel deserves more respect than inspection software vendors give it. A well-built thickness workbook, maintained by a careful inspector, can run a unit's program for years. It is flexible, free, auditable by anyone who can read a formula, and it never needs a login. Most inspection programs started there, and plenty still live there.
The honest question is not whether Excel is bad. It is when Excel stops scaling, and the answer has recognizable symptoms.
The symptoms, in the order they usually appear
- Identity drift. The same exchanger appears as E-101, E101, and E-101A across three workbooks. Merging them requires a human who remembers the rename. Corrosion rates computed across a rename are quietly wrong, and nothing in the spreadsheet flags it.
- Formula rot. The remaining-life calculation was right when it was written. Then someone inserted a row, a range stopped where it should not have, and a copy-paste carried an old rate onto a new vessel. Spreadsheet errors are silent by design; the cell shows a number either way.
- Version divergence. Thickness_Master_v7_FINAL and Thickness_Master_v7_FINAL_JT are both in circulation. Each contains readings the other lacks. The program no longer has a system of record; it has candidates.
- The single-owner problem. One person understands the workbook's structure, its macros, and its exceptions. When that person is on shift, on vacation, or retired, the program's data layer is unattended. This is the risk that keeps chief inspectors up at night, and it is invisible until it lands.
- Concurrency failure. Two inspectors return from the field the same afternoon. One workbook. Whoever saves second wins, or loses, depending on how you count.
The threshold, roughly
Programs cross the line when any of these become routine: more than a handful of active users touching the data, readings arriving from the field faster than one owner can transcribe them, history deep enough that rates and intervals depend on decade-old readings, or external scrutiny that requires showing where a number came from. One unit, one inspector, quarterly readings: Excel is arguably fine. A site program feeding interval decisions and audit responses: it is not, and the failures will be discovered at the worst possible moments.
What a purpose-built system actually changes
The replacement is not "Excel but prettier." The structural differences are specific:
- Identity is enforced. Equipment and CMLs are records with lineage, not text in column A. Renames preserve history instead of severing it.
- Calculations are versioned and tested. Rate and remaining-life logic runs the same way for every record, and changes to it are deliberate events, not accidents of editing.
- Capture happens at the source. Readings enter once, in the field, with units and context required, offline if the unit has no signal. Transcription, the largest error source, disappears.
- Concurrency and audit trail are native. Many users, one record, every change attributed and timestamped.
Migrating without losing what Excel did well
The workbooks themselves become the migration source, and their idiosyncrasies become the crosswalk work. Keep them read-only afterward as provenance, not as parallel truth. And preserve the flexibility that made Excel work: a system that cannot accommodate your program's real structure will drive the field straight back to spreadsheets.
This transition is the most common starting point for intelliSPEC deployments, which is why the trial supports loading a real unit's workbook history. Whatever you move to, move because the symptoms above have arrived, not because a vendor said spreadsheets are embarrassing.
