Spreadsheet or business software: when is it time to switch?
Five signs a shared spreadsheet has become a risk, what moving to business software really costs, and how to switch without breaking anything.
The spreadsheet is an excellent tool — up to a point
We should start by doing it justice. A spreadsheet is set up in an hour, costs nothing beyond the office licence you already pay for, and can be changed without going through anyone: that is exactly what you want for a need that is still vague, a modest volume and one user at a time. Plenty of small businesses come to us convinced they need “a proper piece of software at last”, when a well-kept spreadsheet will cover their needs for another two years. We say so when that is the case. The switch is justified neither by the size of the file nor by its age, but by a change of nature: the day several people depend on it at the same time, when a keying error has visible consequences at a customer’s end, and when nobody knows any more which version is authoritative. As long as those three conditions hold, changing tools would cost more than the problem it solves.
Five signs that it is time to switch
One — versions multiply: “schedule_v4_final_OK_bis” is going round by email, and two people are working on two different copies. Two — re-keying: the same information is typed into the spreadsheet, then into the invoicing system, then into an email. Three — only one person understands the file: the formulas were written by someone who has left, and nobody dares touch them. Four — errors become visible from outside: a customer receives the wrong amount, a delivery is forgotten, a deadline is missed. Five — access is no longer controlled: the file holds personal data or pricing, and it is open to everyone on the shared drive. Two signs out of five are enough to open the discussion; four out of five, and the matter becomes urgent. Note that four of these five signs are organisational, not technical: it is the way of working that has changed, not the software.
Key points
- The trigger is not the size of the file, it is the number of people who depend on it at the same time.
- Put a figure on the time lost, in hours per week: without that figure, no project is justified.
- If the need is standard and regulated, take an off-the-shelf product rather than a development.
What a spreadsheet turned business-critical really costs
The cost is invisible because it is spread thin. It is made up of re-keying time — a few minutes per file, multiplied by the number of files and of people —, of checking time, because nobody trusts the file any more without counting it again, of error correction at the customer’s end, sometimes with a goodwill gesture attached, and finally of risk: a file lost, corrupted, or carried off by an employee who leaves. The method for costing it takes a week: ask three people to note down, every day, the time spent on the file and on everything that follows from it. The total almost always surprises directors, and it is that figure — not a technical argument — that decides the project. Add the opportunity cost to it: time spent maintaining the file is time not spent with customers.
Bespoke or off-the-shelf?
The right answer is often “off-the-shelf”, and it is worth saying so before asking for a development quote. Take an off-the-shelf product when the need is standard — accounting, payroll, point of sale, electronic signature, a generic CRM: a publisher spreading its costs across thousands of customers will always be cheaper, and it handles regulatory updates on your behalf. Move to bespoke when the way you work is precisely what sets you apart, when your teams are papering over the software’s gaps with spreadsheets and re-keying, or when no product will talk to your other tools. Between the two lies a third path that is often overlooked: keep the off-the-shelf product and add a bespoke extension or bridge to it. We regularly turn projects down on this basis: when an off-the-shelf product will do, saying so costs everyone less.
How to switch without breaking anything
By keeping the spreadsheet alive throughout the transition, never by cutting over from one day to the next. The sequence we follow: one to two weeks of scoping to write down the real journeys — not the theoretical ones — and set the scope of the first version; clickable mock-ups approved by the people who do the keying every day, because that is the moment when changes cost nothing; two-week cycles, each closed by a demonstration; a data migration from the spreadsheet, with a line-by-line check on a sample; then two to three weeks of dual entry during which the old file remains the reference. A small business tool is delivered in four to six weeks, a full application in two to four months. Only after a spell of dual entry with no discrepancies do we archive the spreadsheet — read-only, never deleted.
Does this subject concern your business?
This article belongs to our software development pillar. The first conversation is free and without obligation, in Nice and the surrounding area.
Read the case study: Helioneo: turning metering data into an energy experience anyone can read