Spreadsheets vs an IDMS: what the switch actually changes

When do spreadsheets stop working for inspection data?

A workbook per vessel, one inspector, formulas in view and a file that lives on one drive works well enough for a small unit. The formulas are visible, the history is a column, and the person who built it knows where everything is. Nothing about that is careless.

It stops working when history stacks up across tabs, when CML counts climb into the thousands, when more than one person edits, when an auditor asks who changed a value and when, when intervals have to be recomputed after every reading, or when a copy leaves the site with a contractor. Each of these is survivable alone. Together they turn the workbook into a liability that nobody wants to own.

• More than one person edits the same workbook
• More than one unit or site shares the program
• CML count passes a few thousand
• Findings need to link to a repair or a work order
• An audit is due within the next inspection cycle
• The person who built the workbook is leaving

What does an IDMS change about the record?

Identity is the first change. Equipment becomes a record with one identifier and a hierarchy, not a row that may be duplicated across three tabs. History becomes a series per CML with method, date and gauge on each reading, not a column added at each inspection.

Calculation is the second change. Corrosion rate, remaining life and the next inspection date are stored with their inputs and the code basis, not a formula that anyone can overtype. Findings link to the equipment and to the work that closed them. Every change carries a user and a time, and access is by role instead of by who has the file.

What does it change in the field?

In the workbook world the reading is written on a clipboard, walked back to the office, and typed in. Every retype is an error opportunity and a delay. With a device in the field the reading is captured once, the photo is bound to it, and the gauge can send the value directly instead of being read aloud.

Offline behavior matters more than it sounds. Units, tank farms and pipe racks have no signal, and a form that needs a connection to save is a clipboard with extra steps. The other field question is what happens when two people edit the same record before either syncs. A workbook answers with last save wins. A system should record the conflict and let someone resolve it.

What are the real costs of switching?

Migration is the largest cost and it is mostly data condition, not software. Tags have to be cleaned and deduplicated, CMLs reconciled across tabs, columns mapped, and a decision made about how much history to bring. Validation follows: rates are rerun in the system and compared to the workbook, and the differences have to be explained. Expect the comparison to find errors in the workbook you did not know were there.

Training and a parallel run add weeks. Inspectors need time on the device, the engineer who owned the macro needs to trust the new calculation, and most programs run both for one inspection cycle before retiring the workbook. Then there is the subscription. intelliSPEC imports workbooks and CSV with AI-assisted column mapping, and its published prices, Starter at $69 and Professional at $129 per user per month billed annually with Enterprise quoted, give a starting point for that line. For one unit the whole switch is measured in weeks to a few months; for a site, longer, and the driver is almost always the state of the data.

• Tag cleanup and CML deduplication
• Deciding which history to bring and which to archive
• Validation of rates and dates against the workbook
• Training and one cycle of parallel running
• Subscription and any per-module cost
• Time from the internal owner, which is the cost most often left out

How do you migrate a spreadsheet into an IDMS without losing history?

Freeze the workbook first so nobody edits it while the move is in progress. Inventory every tab and decide what each one is: register, readings, findings, calculations or notes. Build the equipment hierarchy in the system before importing a single reading, because history without a home is worse than no history.

Import one unit as a pilot. Map the columns, load it, rerun the rates and compare to the workbook line by line. Fix problems in the source data, not in the system, so the fix survives a reimport. When the pilot reconciles, repeat by unit. Keep the retired workbook as a read-only archive with a date on it, because an auditor may still ask for it.

• Freeze the workbook and record the freeze date
• Inventory tabs and classify each one
• Build the hierarchy first, then import readings
• Pilot one unit and reconcile rates line by line
• Fix at source so the fix survives a reimport
• Archive the workbook read-only with its freeze date

How do you know the switch paid off?

Measure the things the workbook made slow. Time from a reading in the field to an updated next inspection date. Number of readings retyped, which should be zero. Time to answer an audit request for a given vessel. Number of equipment records with no owner or no inspection plan. Number of findings closed with a repair record attached.

If those numbers do not move in the first cycle, the problem is usually the migration, not the system: history that was not brought, tags that were not reconciled, or a hierarchy that does not match how the plant thinks. Fix that before judging the software.