Your Company’s Real Operating System Is Probably a Spreadsheet

There is a file. It has a date and somebody’s initials in the name. It lives on one laptop, and the week that person is on leave, the business finds out what it was for.

The system nobody bought

Most organisations of any size are running two operating systems at once. The first was purchased, implemented, trained on and paid for annually. The second is a collection of spreadsheets, shared documents, saved email folders, a WhatsApp group and a quantity of institutional memory, and it is the one that decides what actually happens on a Tuesday.

You can identify the second one by a simple test: when the two disagree, which one do people believe? If the answer is the spreadsheet, then the spreadsheet is the system of record and the software is a filing cabinet you are paying a subscription for.

Why “people need to use the system properly” is wrong

This is the standard diagnosis and it is almost always backwards. Nobody maintains a parallel spreadsheet for entertainment. It is unpaid, unrecognised, error-prone work that they do on top of their actual job, and they do it for exactly one reason: it is cheaper for them than the official route.

That makes a shadow system a measurement, and a rather precise one. Someone has compared the cost of doing it properly against the cost of doing it themselves, and concluded — with better information about their own work than anyone above them has — that the official system is more expensive. Deleting the spreadsheet does not change that calculation. It only removes your visibility of it.

The shadow system is not the disease. It is the diagnosis, produced free of charge by the person best placed to make it.

Four things a shadow system can be telling you

They look identical from a distance — a spreadsheet is a spreadsheet — but they encode four quite different gaps, and each has a different fix. This is why “migrate everything into the ERP” fails so reliably: it treats four problems as one.

• The system cannot represent it. Your process has a state, a role or a relationship the software has no field for. Someone invented a column. This is a configuration or development gap.
• The system can represent it, but too slowly. Six screens and four confirmations to change two fields. The software is capable and the interaction cost exceeds the value. This is a workflow gap.
• The system holds the data but cannot show it. Everything needed is in there; the view is not. Someone exports to CSV every month and rebuilds it by hand. This is a reporting gap.
• The system was configured for a business you no longer are. It fitted at implementation. Since then you added a service line, a second site, or a different kind of customer, and nobody revisited the model. This is a fit gap, and it is the most expensive to leave alone.

Instrument

Shadow-system audit

Three passes: find them, record them, decide what happens to each. A team of twenty will typically surface somewhere between eight and twenty-five. That number is not an indictment — it is the backlog you have been running on.

Pass one — finding them

Asking “does anyone use spreadsheets?” produces nothing. These five questions produce a list. Ask them of people who do the work, not of the people who manage it.

• Which attachment gets emailed on the same day of every month, and who assembles it?
• What do you check before you trust the report the system gives you?
• What did you have to build yourself because the system would not do it?
• What stops working when one particular person is away?
• Which number does the leadership team quote in meetings that no system actually produces?

Pass two — recording each one

Seven fields per shadow system. The last two are the ones people skip and the ones that change decisions.

• What it does, in one sentence.
• Who maintains it, by name.
• How long it takes per cycle, and how often the cycle runs.
• Which decision or obligation depends on its output.
• Which official system it duplicates or works around.
• What happens if it is a week late.
• Who else has a working copy — and whether they could actually run it.

Pass three — disposition

Five outcomes, each with a test. Assign one to every item before any building starts.

• Configure — the system can already do this and nobody set it up. Test: could a competent consultant configure it inside a week? Cheapest outcome available; check for it first, every time.
• Integrate — two systems each hold part of the answer. Test: is the manual work purely moving data between them, with no judgement applied? If so, it is a connector, not a project.
• Redesign the process — the spreadsheet exists to service a step that should not exist. Test: does anybody downstream actually use the output, or is it produced because it has always been produced?
• Build — the process is genuinely specific to how you compete. Test: is this a real difference in how you operate, or a habit that has hardened? Only the first justifies custom software.
• Leave it alone — low volume, one owner, works, costs an hour a month. Test: would automating it pay back inside three years? If not, say so in writing and move on. Not every manual process is a problem, and pretending otherwise is how audits lose credibility.

Then run the risk pass. Mark every item where the answer to “what happens if it is a week late” is material and the answer to “who else has a working copy” is nobody. Those are not efficiency problems, they are continuity risks, and they are fixed first regardless of what the return on investment looks like.

The part that is genuinely uncomfortable

Run this audit honestly and you will find at least one process where the business’s ability to invoice, pay people, or meet a regulatory obligation depends on a single file, maintained by a single person, with no documentation and no tested copy. It has usually been that way for years, and it has usually survived on the goodwill of somebody who has never been thanked for it.

That is worth surfacing on its own terms, separately from any modernisation programme. It is a small, cheap thing to fix and an extremely expensive thing to discover during a resignation.

What good looks like

• A written inventory of shadow systems, with an owner and a disposition against each.
• No process on which the business depends running from a single uncopied file.
• Information entered once, at the point it is created, by the person who created it.
• Reports produced by the system that people actually believe, rather than check.
• Configuration revisited when the business changes shape, rather than at implementation only.
• A route by which someone can say “the system does not fit this” and have it looked at — which is what stops the next spreadsheet being created.

Where to start

1. Run pass one on one department. A single afternoon, five questions, no software involved. The list itself usually changes the conversation.
2. Do the risk pass before anything else. Continuity exposure first. It is cheap to fix and it does not need a budget cycle.
3. Take the configure items next. They are the fastest, and delivering three of them buys the credibility to attempt the harder ones.
4. Only then decide what to build. With the inventory in front of you, build-versus-buy stops being an argument about preferences and becomes an argument about a list.

Scenarios in this piece are composites drawn from common patterns rather than accounts of specific engagements.