The operating problem
A spreadsheet usually becomes dangerous gradually. It starts as a useful calculation or list, then gains colour codes, hidden columns, macros, approval flags, copied tabs, manual imports and special rules understood by one experienced employee. The business still describes it as “just a spreadsheet”, even though people now depend on it to decide what may be purchased, produced, invoiced, approved or reported.
Engineering judgement tied to operating evidence.
Founder and software/electronics engineer at INESSOFT. Reviewed against current INESSOFT delivery practice and operating evidence.
Published 12 Jul 2026 · Last reviewed 12 Jul 2026A spreadsheet is not automatically a problem
Spreadsheets are fast, flexible and transparent. They are often the correct tool for exploration, low-volume calculations, temporary planning and work owned by one knowledgeable person. Replacing every workbook with software would create unnecessary cost and rigidity. The decision changes when the workbook stops being a tool used inside a process and starts becoming the process itself.
- The file is still suitable when one owner controls it and the consequences of an error are limited.
- It remains useful when data volumes are modest and no complex permissions or audit history are required.
- It becomes risky when multiple people edit, copy, reconcile and reinterpret the same operational truth.
The hidden cost is coordination, not typing
Businesses often estimate the cost of the current method by counting only the minutes spent entering data. That misses the expensive part: people checking whether a value is current, asking who changed it, comparing versions, chasing approvals, recreating reports and recovering from mistakes. A process can look cheap because every individual workaround is small, while the combined coordination burden is significant.
- Measure time spent checking and reconciling, not only time spent capturing.
- Include management delay caused by waiting for a trustworthy answer.
- Include the cost of errors that are discovered only after the next department acts.
The strongest trigger is repeated state management
Files become poor operational systems when records move through states such as requested, reviewed, approved, allocated, completed, rejected and closed. A spreadsheet can display a status column, but it does not naturally enforce who may move the record, which evidence is required, what happens on rejection or how overdue items should remain visible. That is where a workflow system begins to create real value.
- Explicit ownership replaces informal chasing.
- Validation can prevent a record moving forward without required evidence.
- Audit history separates the current value from the history of decisions.
Do not automate confusion
A custom system should not freeze a badly understood process into code. Before building, the team must agree on the real record, required states, ownership, exceptions and outputs. In many projects the first benefit comes from simplifying the process itself. A focused first phase may control one complete workflow while leaving surrounding spreadsheets in place until the business has evidence that expansion is justified.
- Start with one end-to-end process, not a request to digitise an entire department.
- Separate mandatory rules from habits that developed around the old file.
- Design the exception path before polishing the happy-path screens.
What a sensible first system usually contains
The first release should establish a single source of truth for one meaningful business object: a job, request, inspection, quote, item, certificate or approval. It should control identity, status, ownership, evidence, search and reporting. It does not need to become a giant enterprise platform to outperform a fragile workbook.
- SQL-backed records with stable identifiers and searchable history.
- Role-based screens that show each user the work they actually own.
- Clear exception queues, reports and exports for management and downstream systems.
How to calculate the business case
A practical business case combines labour, delay, error exposure and opportunity cost. Estimate how often the process runs, how many people touch it, how much time is spent checking or recovering, and what happens when the answer is wrong or late. Then compare that recurring cost with a phased system that removes the most expensive uncertainty first.
- Use a monthly or annual baseline rather than one dramatic incident.
- Value shortened turnaround and reduced dependence on key individuals.
- Treat improved visibility as valuable only when it changes a decision or action.
Use the operating signal to choose the next action.
The same symptom can justify a custom system, a smaller integration, a stabilisation phase or no build at all. The decision should follow evidence rather than enthusiasm for a particular technology.
The file is mainly a personal calculator or temporary planning aid.
The flexibility of a spreadsheet is still an advantage.
Keep it, document it and avoid unnecessary software.
Several people copy, edit and reconcile versions of the same data.
The business no longer has a reliable source of truth.
Scope a shared SQL-backed record and controlled update flow.
Approvals, due dates and ownership are managed through colour, comments or email.
The real problem is workflow control rather than data entry.
Model states, roles, exceptions and notifications before building screens.
Management repeatedly waits for manually assembled reports.
The process has a visibility and governance problem.
Define trusted calculations and report ownership as part of the first phase.
Evidence that the current approach is becoming risky.
- The workbook has several unofficial copies with slightly different formulas.
- Only one employee understands how month-end or exception handling works.
- Users overwrite values because there is no distinction between correction and history.
- Approvals are implied by colour or email rather than recorded as explicit decisions.
- Reports require repeated manual consolidation before every meeting.
What to clarify before commissioning work.
- Bring one real workbook and the forms, emails or messages around it.
- Map who creates, checks, approves and consumes each record.
- List the states a record moves through and the exceptions that interrupt the normal path.
- Identify the reports or documents that must be reproducible later.
- Measure current monthly effort, delay and common failure recovery.
- Choose one operationally complete first phase rather than digitising everything at once.
Case studies behind the lesson.
These links provide system context, architecture, workflows and engineering decisions connected to the article.
Questions that usually appear during scoping.
Does every shared spreadsheet need custom software?
No. The trigger is not sharing alone. The stronger case exists when the file carries business-critical state, permissions, approvals, repeated reconciliation or expensive error exposure.
Can the spreadsheet remain part of the process?
Yes. A phased system can import or export controlled files while the core workflow and source records move into a database-backed application.
How small can the first phase be?
Small enough to control one complete business outcome. A narrow system that owns one request or job from creation to closure is more useful than a broad collection of unfinished screens.
What should be measured before development starts?
Frequency, number of users, manual handling time, turnaround delay, error recovery, reporting effort and the business consequence of an incorrect or missing record.