When Excel Isn’t Enough Anymore: How to Recognize the Problems to Solve

Excel doesn’t stop working with an error message. It stops being enough silently: one day the person who kept the file goes on vacation, or two copies of the same list say different things, or it takes half an hour to answer “where does that order stand?” Before asking for a quote for a business management system, it’s worth knowing which of these problems you’re trying to solve, because not all of them are solved with software.

First, the list of spreadsheets

Start by writing down what exists. A few lines for each file.

• Its name and where it physically lives.
• Who edits it and who only reads it.
• What it’s used for today, not what it was used for when it was created.
• Where the data it contains comes from and where it goes afterward.
• What would happen if it disappeared tomorrow morning.

The list almost always holds two surprises: some files that nobody reads anymore but someone keeps updating, and one or two critical files that live on a single person’s computer, with no copy.

The one-week log

Counting from memory doesn’t work: someone who does a task every day stops noticing it. For one week, whoever touches those spreadsheets notes what they do, how long it takes, and what went wrong. A few lines a day are enough, written by whoever does the work, not by whoever supervises it. The entries below show how to fill it in: they aren’t your numbers.

By the end of the week, the log tells you three things: where the time goes, where the errors come from, and which tasks exist only to hold different spreadsheets together. These last ones are the target: none of them produce value, they exist only because the tool doesn’t prevent them.

The signs that point to a limit of the tool

• The same information is written by hand in two places. Every re-copy is an error waiting its turn.
• There’s a recurring task that exists only to make two lists match.
• Nobody knows which version is the right one, and the files are named final, final two, final ok.
• Two people can’t work on it together, or they do and overwrite each other.
• There’s no way to know who changed a number, when, or why.
• You can’t grant access to part of the spreadsheet without granting it to all the rest.

The first two ease up with more discipline. The last three don’t: they aren’t solved with better formulas, because they concern what a spreadsheet isn’t built to do.

The problem may be the organization

Many projects fail because software is bought to resolve a disagreement. Three typical situations.

• The process hasn’t been decided: it’s unclear who approves a discount, or at what point an order is confirmed. The software doesn’t decide for you: it freezes what it finds.
• Everyone works their own way. You choose the way first, then put it into a system; otherwise you end up building every variant and maintaining them forever.
• The data is dirty: the same customer written four different ways, missing codes, inconsistent units of measure. Brought in as is, they stay dirty and become harder to fix on top of that.

When Excel works just fine, and it’s worth keeping

• Few people, data that doesn’t feed anything else, and nobody who needs to read it in real time.
• Calculations and simulations that change every time: here a rigid system is worse, not better.
• Rare or seasonal tasks, which wouldn’t repay the work of building something on top of them.
• Processes that aren’t stable yet. A spreadsheet is the best place to figure out how something should work before locking it in.

The opposite mistake exists and is common: replacing a spreadsheet that works with software that does the exact same thing, with more steps and less freedom. If a file doesn’t show up in the log, leave it where it is.

Choosing a pilot process

1. Pick a process with a clear beginning and end — from order to delivery, from inquiry to quote — not “running the company.”
2. Choose it among the ones that weigh most heavily in the log, not among the easiest to explain.
3. Write down how it works today, exceptions included. Exceptions are the part that makes projects fail, and they’re always mentioned last.
4. Define three or four observable improvement criteria: a re-copying step disappears, the data exists in one place only, a search no longer requires opening a file, the weekly reconciliation is no longer needed.
5. Decide who will actually use the new version and who keeps working as before until it’s ready.

A pilot that doesn’t touch any of the annoyances that came up in the log is a useless pilot, even when it works perfectly.

What this guide doesn’t cover

This guide stops at the diagnosis: which problems you have and which of them concern the tool. The choice between a ready-made business management system and custom software is the next step, and it’s made with a criteria matrix. How to bring in old data while checking that it arrived intact is a separate job, with its own checks.