Getting off spreadsheets
The spreadsheet is not the problem. It is usually the most accurate document in the building, maintained by the person who cares most — and any replacement that ignores why it won is a replacement people route around.
Why the spreadsheet won in the first place
It is fast. Bulk editing is the default rather than a feature. Reorder forty rows, change every quantity in a column, paste a section from a supplier's list — each takes seconds, and no dialog appears.
It is shaped like the problem this week. A column added on Tuesday because somebody needed it costs nothing. No administrator, no schema change, no conversation about whether it belongs.
It is trusted. One person maintains it, everybody knows who, and when it is wrong there is somebody to ask. That is a real quality property and most systems do not have it.
Any tool that loses all three in exchange for governance gets used for the governance and bypassed for the work — which produces the worst arrangement available: a PLM that is out of date and a spreadsheet that is authoritative.
The four things it cannot do
Hold more than one answer. A spreadsheet has one value per cell, so a change taking effect in October cannot coexist with what ships today. Teams solve it with a colour, a second tab or a note, and the workaround is correct until the person who invented it is on holiday.
Tell you what a unit shipped with. Reconstructing a build from a file that has been edited in place is impossible — there is no record that it ever said anything else. Version history in a file share gives you file states, not part revisions.
Answer where-used across products. A part in six spreadsheets is six searches, and the answer depends on somebody remembering all six files exist. That is the question an end-of-life notice asks, and it is where the missed one hides.
Survive a person leaving. Not because the file disappears, but because the conventions in it were never written down — why some rows are bold, what the third tab means, which columns are stale.
Keeping the speed
Four hundred rows pasted from a spreadsheet produce four hundred correct lines. That is asserted by a test rather than hoped for, and it was written as a requirement before the grid existed — because a tool that loses this loses everything else with it.
Correct means typed. A quantity of 1,000 becomes the number one thousand rather than a string that sorts between 1 and 2. EA and ea normalise. Reference designator ranges expand and are counted against the quantity, and where the two disagree the row is raised rather than accepted.
Fill-down, multi-cell edit and bulk attribute change work across a selection. Tree, indented and flat views over the same structure, so the view somebody prefers is not a different answer.
The model is yours to change. Object types, attributes and lifecycles are tenant configuration, edited in a sandbox with a preflight against real data and a rollback — which is the nearest thing to adding a column on Tuesday that a governed system can honestly offer.
The migration is smaller than you think
A spreadsheet-based organisation usually has less history to move than one leaving a PLM: current structures, a parts list, and whatever the file's version history holds. There is no released-revision history to preserve because there was never a released revision.
That has a consequence worth stating plainly. The three levels — identity, revision, iteration — start applying from the import forward. What a unit shipped with in March is not recoverable from a file that was edited in place, and no import can invent it.
The import runs in five stages with nothing committing until the last: extract, map, validate, deduplicate, commit. Errors name rows — not four thousand errors, but row 4,412 with a quantity of 8 EA in a numeric column and three reference designators listed.
Duplicates will be worse than expected, and the right response is to import them and consolidate afterwards through change control rather than merging during the import, where it is irreversible.
How it meets your ERP
This is where the spreadsheet costs most and it rarely appears in the business case. Somebody re-keys the BOM into the ERP, or maintains a second one there, and the two diverge quietly from the first change nobody propagated.
A released structure publishes outward on change release, dated to its effectivity, in the shape your ERP expects — and identity is matched against your ERP during the import on manufacturer part number then internal number, so you do not create a parallel item master and reconcile it for a quarter.
Cost, on-hand and lead time read back read-only, which removes the other common spreadsheet: the one holding costs copied from the ERP that were correct in March.
Where the boundary is
Some spreadsheets should stay. A one-off analysis, a supplier's quote comparison, a calculation somebody runs twice a year — none of those want to be objects in a system, and moving them in produces ceremony without benefit.
The ones worth moving are the ones that have become authoritative: the BOM everybody works from, the parts list purchasing checks, the change log somebody maintains. If a file is load-bearing and nobody would notice for a week if it were wrong, that is the file.
Facts
| Paste | 400 rows → 400 typed lines, asserted by test |
| Keeps | Fill-down · multi-cell edit · bulk attribute change |
| Model changes | Sandbox, preflight, rollback — your nearest new column |
| Cannot recover | What a unit shipped with before the import |
| Import | 5 stages, nothing commits until the last |
| Errors | Name rows, not counts |
| Duplicates | Import, then consolidate through change control |
| Leave alone | One-off analyses — moving them adds ceremony, not value |
Frequently asked
Will it be as fast as our spreadsheet?
For bulk editing, close enough that people stop noticing — pasting four hundred rows produces four hundred typed lines, and fill-down, multi-cell edit and bulk attribute change all work across a selection. That was a requirement before the grid existed rather than a later addition.
Can we still add a column when we need one?
Through the sandbox, with a diff, a preflight against real data and a rollback. That is slower than typing a header into a spreadsheet and it is the nearest thing a governed system can honestly offer — the preflight is what a spreadsheet cannot give you.
Can we recover what past units shipped with?
No, and no import can invent it. A file edited in place holds no record that it ever said anything else, so the three levels — identity, revision, iteration — start applying from the import forward. That gap is permanent and worth planning around.
How much history do we need to move?
Usually less than a company leaving a PLM. Current structures, a parts list, and whatever the file's version history holds. There is no released-revision history to preserve because there was never a released revision, which makes this migration considerably smaller.
What about our duplicate part numbers?
Expect more than you think, and import them rather than cleaning up first. Merging during import is irreversible in a way importing is not, so the safe sequence is to let the system surface duplicates as candidates and consolidate afterwards through change control.
Should we move every spreadsheet?
No. A one-off analysis, a supplier quote comparison or a twice-yearly calculation does not want to be an object in a system. The ones worth moving are the load-bearing ones — where nobody would notice for a week if the file were wrong.
What does this fix on the ERP side?
The re-keying. Somebody currently retypes the BOM into the ERP, or maintains a second one there, and the two begin diverging from the first change nobody propagated. A released structure publishes outward automatically, dated to its effectivity, with identity matched during the import.