By Hiran de Silva
For many years I have watched discussions about spreadsheets in the enterprise unfold in a rather curious way.
One group points to spreadsheet failures.
Another group points to new technologies.
A third group points to planning systems, ERP systems, Power Platform solutions, cloud applications, AI tools, or various alternatives to Excel.
Everyone has an opinion.
Everyone has a sales pitch.
Everyone has a preferred technology.
But very few people seem to start with the most important question of all:
What exactly is the business outcome we are trying to achieve?
Because if we do not begin there, every discussion quickly becomes a debate about tools rather than a discussion about results.
The Wrong Starting Point
The traditional narrative is familiar.
We are shown examples of spreadsheet chaos.
Multiple versions.
Files being emailed around.
Broken links.
Manual consolidations.
Lack of governance.
Poor auditability.
Lack of security.
The famous “Excel Hell” stories.
These criticisms are not entirely wrong.
In fact, many of them are accurate descriptions of what happens when spreadsheets are poorly designed.
The problem is that these examples do not demonstrate the limitations of spreadsheets.
They demonstrate the limitations of the people who created them.
There is a significant difference.
A badly designed spreadsheet solution tells us nothing about what spreadsheets are capable of when properly designed.
Yet much of the industry treats these examples as proof that spreadsheets themselves are the problem.
That is a dangerous assumption.
The Missing Benchmark
What is largely missing from the conversation is a benchmark.
Not a benchmark of technologies.
Not a benchmark of vendors.
Not a benchmark of features.
A benchmark of outcomes.
Suppose we take a common enterprise requirement.
For example:
- Annual budgeting
- Budget review
- Forecasting
- Management reporting
- Workflow approval
- Auditability
- Collaborative data collection
These are genuine enterprise requirements.
Senior management cares about these outcomes.
The question should therefore be:
What does an excellent solution look like?
Not:
“What product should we buy?”
Not:
“What feature should we use?”
Not:
“What technology is fashionable this year?”
Instead:
“What would success look like?”
Only after answering that question should we discuss tools.
A Practical Example
Take budget review.
The requirement is straightforward.
A budget holder receives draft management accounts.
They review the figures.
They drill into details where necessary.
They identify anomalies.
They flag concerns.
Finance reviews the feedback.
Adjustments are made.
The budget holder verifies the corrections.
The review is approved.
Progress is tracked centrally.
Management can instantly see which areas are complete and which remain outstanding.
This process is not optional.
It is a critical business control.
Now imagine that the entire process takes only a few minutes per manager.
No emailing.
No downloading data.
No exporting reports.
No manual reconciliation.
No waiting for specialist support.
Everything is available immediately.
The user simply retrieves the information, reviews it, enters comments where necessary, and submits the result.
This is not a theoretical exercise.
This is simply what a good enterprise spreadsheet solution looks like.
The Key Distinction
This is where an important distinction emerges.
What I am demonstrating is not Excel versus another technology.
What I am demonstrating is the difference between:
- People who know how to create enterprise-level outcomes with spreadsheets.
- People who do not.
That distinction matters enormously.
Someone may know every modern Excel feature.
They may know Power Query.
Dynamic Arrays.
LAMBDA functions.
Python in Excel.
Copilot.
Office Scripts.
Data Visualisation.
Social media trends.
Yet still be unable to produce an enterprise-grade budgeting solution.
Why?
Because enterprise outcomes are not created by features.
They are created by architecture.
Enterprise thinking is fundamentally different from feature thinking.
The objective is not to create an impressive spreadsheet.
The objective is to create a business process that delivers a business outcome.
The Benchmark Challenge
This leads to what I believe is a far more productive discussion.
Rather than arguing whether Excel is good or bad, let us establish a benchmark.
Here is a typical enterprise requirement.
Here is a working solution.
Here is the business outcome.
Here is the user experience.
Here is the governance.
Here is the audit trail.
Here is the flexibility.
Here is the transparency.
Here is the cost.
Here is the time required to implement.
Now we have something concrete.
At that point, every alternative can be evaluated fairly.
ERP systems.
Planning platforms.
Power Platform solutions.
Custom applications.
AI-driven solutions.
Whatever technology is proposed.
The question becomes:
How does it compare against the benchmark?
Not in theory.
Not in marketing literature.
Not in sales presentations.
In practice.
A Scientific Comparison
Once a benchmark exists, meaningful comparisons become possible.
We can compare:
- Capital expenditure
- Ongoing operating costs
- Agility
- Transparency
- Ease of modification
- Vendor lock-in
- Knowledge retention
- User adoption
- Deployment speed
- Maintainability
And most importantly:
The quality of the business outcome.
This transforms the conversation.
We are no longer defending Excel.
We are no longer attacking alternatives.
We are simply evaluating competing approaches against a known benchmark.
That is a scientific discussion.
The Enterprise Excel Blind Spot
One reason this discussion is so important is that many people have never seen Excel operating in this space.
They have seen traditional spreadsheets.
They have seen spreadsheet chaos.
They have seen Excel Hell.
What they have not seen is enterprise-grade spreadsheet architecture.
As a result, many assumptions have become accepted as fact.
Entire industries have grown around solving problems that many people believe Excel cannot solve.
My own experience over the past thirty years suggests otherwise.
The question is not whether alternatives exist.
Of course they do.
The question is whether those alternatives genuinely outperform a properly designed enterprise spreadsheet solution.
That is a very different question.
And it deserves a proper answer.
Conclusion
Perhaps the most important shift we can make is this:
Stop starting with technologies.
Stop starting with products.
Stop starting with opinions.
Start with the business requirement.
Define the desired outcome.
Build a benchmark.
Then invite every proposed solution to demonstrate how it performs against that benchmark.
That is not anti-technology.
It is not anti-ERP.
It is not anti-Power Platform.
It is not anti-AI.
It is simply a commitment to evaluating solutions based on outcomes rather than assumptions.
And once we begin doing that, I believe many long-held assumptions about Excel, enterprise systems, and spreadsheet engineering will be challenged in ways that surprise a great many people.
Add comment