Excel as shadow IT: banning it is pointless, rethinking the process is not

In every company where I have seen an attempt to "ban Excel," the story ends the same way. A few months later the spreadsheets come back - slightly more hidden, under different names, through personal drives and email. The ban did not remove the need that created them.

Excel is not a bad habit of employees. It is a signal that somewhere a corporate system is not doing its job. Working with the signal is more useful than silencing it.

Why spreadsheets appear where they should not

When an employee opens Excel instead of the CRM or ERP, it almost always means one of a few things:

• the corporate system is too slow for day-to-day work;
• the needed report or data slice requires an IT request to obtain;
• the calculation logic is non-standard and does not fit the system's templates;
• entering data requires five screens, while a spreadsheet takes one row;
• there simply is no system that covers this particular task.

The employee is not sabotaging the process. They are fixing it with the tools available. The problem is that their fix is invisible, unmanaged, and not reproducible.

What makes shadow Excel dangerous

One spreadsheet in one person's hands is not a crisis. The danger appears when the spreadsheet becomes part of a process:

• data gets copied from it into other systems;
• decisions are made based on it that nobody else can verify;
• its logic is undocumented and lives only in the author's head;
• when the author leaves, nobody can reproduce the calculation.

I have seen companies where key financial figures were calculated for months in a file that lived on one manager's desktop. Not because they wanted power over the number. The ERP simply could not calculate what the business needed, and the request for a fix had been sitting in the queue for a year. The same dynamic - different people counting the same metric differently - is what makes self-service BI produce contradictory reports rather than shared insight.

How to find the real cause

Before changing anything, it is worth understanding exactly what the spreadsheet does for the person who uses it. Three questions:

1. What task does this spreadsheet cover? What exactly happens in it - calculation, aggregation, pulling data from several places, filtering?
2. Why is this not done in the main system? No feature, no access, too slow, too awkward?
3. Who else depends on this spreadsheet? Where does the data from it go?

Answers to these three questions usually reveal not a people problem, but a specific gap in a system or a process.

What works instead of banning

Banning removes the symptom. Other approaches actually work.

The first is legalisation with constraints. If the spreadsheet serves a real function, recognise it as the official tool for that specific process step, document the logic, and assign an owner. That is better than pretending it does not exist.

The second is removing the root cause. If employees routinely bypass the CRM because data entry is awkward, that is a task for IT: improve the interface or at least cut the number of required fields. Often not expensive, often quick to pay off.

The third is targeted automation. If the spreadsheet aggregates data from three systems, it may be enough to set up one report or a simple export, and the spreadsheet becomes unnecessary on its own.

A filter for auditing shadow systems

When I go through shadow tools in a company, I look at each critical spreadsheet through the same set of questions:

• What happens if the author of this spreadsheet does not come in tomorrow?
• Can the result in this spreadsheet be reproduced through the main systems?
• How many people make decisions based on this spreadsheet?
• When did someone last verify that the logic in it is correct?

If even one answer is concerning - that is not a reason to ban Excel. It is a reason to understand what process it is replacing, and decide how that process should work properly.