Only one person understands the Excel file, and that is a business risk

Short answer. If the logic of a core process sits in an Excel file that only one person understands, you have a single point of failure. If that person is gone, the process stalls and the numbers no longer add up. You secure this by examining the process and capturing the logic in a system that runs independently of that person.

The silent dependency that almost every business has

In nearly every business there is one file. It is usually called Planning_final_v7_FINAL.xlsx or something along those lines. It contains formulas that no one dares to touch, a few tabs that reference tabs no one can find anymore, and a macro built long ago by someone who left the company years back. That file runs a core process: production planning, margin calculations, hours, inventory. And there is exactly one person who understands how it works.

That is not an Excel problem. It is a knowledge problem. The crucial logic of your business does not live in a system, but in the head of one employee, with a spreadsheet as a memory aid. As long as that person is around, everything seems fine. The file produces numbers, the planning rolls out, and no one wonders what happens if that person gets sick, goes on holiday or leaves.

This is what is called a single point of failure: one point on which the entire operation depends. It shows up everywhere because it emerges organically. Someone once solves an urgent problem with a handy spreadsheet. It works, so it stays. A tab gets added, another formula, a link to another file. No one decided that this would become the system. It simply became one, step by step, without anyone designing it.

Why this is a real risk, not an inconvenience

The risks are concrete and well documented. Research that is widely cited indicates that the vast majority of business spreadsheets contain errors. The more formulas and links there are, the greater the chance that a mistake has crept in somewhere that no one notices. You then steer on numbers that are wrong, without knowing it.

On top of that comes the version problem. Excel has no built-in version control that tells you what the truth is. Copies appear: one on the laptop, one on the server, one in an email. Everyone works in their own version and at some point no one knows which one is the latest. Decisions get made based on a file when it is unclear whether it is current.

And then the dependency itself. You recognise an unhealthy dependency on one person by a few signals: no one else can fix an error in the file, there is no documentation, and every question about how it works goes to the same person. As long as that person is there, you do not notice it. The moment it hurts is precisely the moment you cannot afford it: that person drops out and the knowledge goes with them.

How I solve this: securing it in a system

The reflex is often to buy an off-the-shelf package that is supposed to make the problem go away. Sometimes that is the right choice, and I say so when it is. But often an off-the-shelf package does not fit the specific logic that sits in that Excel file, because that logic is exactly what makes your business different from the rest. Forcing a package then is not the solution, but a new problem.

I work in three steps. First the goal: you want better overview and control, numbers that add up, and less manual work. That is the starting point, not the tool. Next I examine the process. A spreadsheet that has grown over time is full of steps that once had a reason but can now be done smarter or removed entirely. That clean-up is half the work and is often skipped. Only then do I build the smarter solution: the logic captured in a system, with the calculation that simply needs to happen neatly automated, one source of truth instead of seven versions, and a dashboard that gives the overview the spreadsheet never gave.

So the calculation does not disappear. It needs to happen reliably. The difference is that it no longer lives in someone's head and a fragile file, but in a system that keeps running when that person is away for a while. That is the difference between knowledge that hangs on a person and knowledge that is secured.

How this plays out in practice

The same underlying pain looks slightly different per sector. Below are the places where I encounter this most often, with a deeper look at each situation.

In production and planning it revolves around the file that creates the planning. Who works where, which order comes first, what the capacity is. If that sits in a spreadsheet that splinters into versions, you plan on outdated information.

• Version chaos in production planning: why a planning file that has grown over time grinds to a halt as soon as you scale up, and how to secure the planning logic in a system.
• Which planning is the latest version: in construction, planning, subcontractors and execution often work in separate Excel versions, with the result that no one is sure which planning is the current one.

In finance and administration the pain sits in the numbers themselves. Reports and consolidations are put together by hand, in files that only one person can reproduce.

• Reports outside your accounting software: why the real management information often arises in a separate Excel alongside the accounting package, and how to make that reporting reliable and repeatable.
• Consolidating multiple administrations: with multiple entities or locations the merging is often done manually in a spreadsheet, error-prone and dependent on one person who knows the structure.

The common thread is always the same: a core process that runs on a file and a person, and that is vulnerable precisely because it appears to work so invisibly well.