The spreadsheet of record

There is a file. It might be called Master, or Inventory Final, or Copy of Copy of Tracker. It has been open on somebody's screen every working day for four years. It is the most important system in the business and it appears on no asset register, in no budget, and in no continuity plan.

This is not a failure of discipline. It is what success looks like on the way up. Somebody solved a real problem quickly, the solution worked, and the business grew around it. That is the correct sequence. The mistake is only in leaving it there too long.

Why it worked, and why that stops

A spreadsheet is the fastest way to model a process that nobody has fully agreed on yet. No schema, no approval, no vendor. When the process is genuinely still being figured out, that flexibility is exactly right, and no system built too early would have survived contact with what you actually learned.

What changes is the number of people who depend on it being correct.

With one person and one file, the file and the truth are the same thing. With six people, three of whom keep local copies so they can work without fighting over edit locks, the file stops being the record and becomes one opinion about the record. Nobody decides this. It happens on an ordinary Tuesday and no one notices for a month.

The signals that it has turned

Not "it is getting big". Size is not the problem. These are.

One person can explain it. If the answer to "why does column AK do that" is a name rather than a reason, the business has an undocumented dependency with a notice period. This is the most serious signal and the most commonly tolerated.

Versions have names. Final, Final v2, Final USE THIS ONE. Version names are the visible symptom of there being no agreed record.

People read it more than they write it. When most interactions are lookups, what you have is a database with no access control and a very poor query interface.

Corrections arrive by chat. Someone messages a number, someone else types it in. The correction is now in two places, agrees in neither, and the reason for it survives nowhere.

Reconciling is a scheduled job. If a recurring block of somebody's week exists to make two sources agree, the cost is already being paid. It is just being paid in salary rather than software.

Nobody will delete rows. When people are afraid to remove anything because something else might depend on it, the file has become load bearing and nobody knows the shape of the load.

Three or more of these together is a system, not a spreadsheet, and it should be treated as one.

What not to do about it

Do not buy a platform and migrate the file into it. The file encodes years of real decisions about how your operation works, most of them undocumented. Import it without understanding it and you get the same confusion, now with a subscription and worse formulas.

Do not rebuild it faithfully. A rebuild that reproduces every quirk reproduces the mistakes too, and you have spent a budget to arrive where you started with better fonts.

Do not lock it down and call that governance. Permissions on a file whose logic nobody understands do not reduce risk. They reduce the number of people who can fix it.

What to do instead

Read it first, properly, as a document about the business.

Someone should sit with the file and the people who use it and establish four things. What questions does this file actually answer, and for whom. Which of its columns are inputs, which are derived, and which are dead. Where does its data come from, and where does it go afterwards. And what has to remain true for the operation to keep running, whatever replaces this.

That last one is the specification. Not the columns, not the layout: the guarantees. Stock counts that agree with what shipped. Approvals that leave a trail. One total that everyone quotes.

Once those are written down, the build is straightforward and often smaller than expected, because much of what the spreadsheet does turns out to be compensating for the fact that it is a spreadsheet.

The unglamorous conclusion

Sometimes the study concludes that the file is fine and the actual problem is that four people are entering the same order in three places. That is a process fix, it costs nothing, and it is a better outcome than any build.

The spreadsheet is not the enemy. Not knowing what it is doing is.