Quality software or spreadsheets: what actually forces the change

Comparison criteria

Criteria are stated explicitly and neither option is declared a winner: which one fits depends on the constraint that binds hardest in your operation.

The triggers are specific, and they are worth naming in advance

Businesses rarely outgrow files gradually; a particular event exposes the limit. A customer asks for the history of a specification change and the answer requires assembling emails. An auditor requests calibration records for equipment used on a particular date and the current file has been overwritten. Two people update the same nonconformance log and one set of entries disappears. Someone leaves and the training matrix turns out to have been maintained in a personal folder. Write down which of these would genuinely damage you, and treat their occurrence as the decision point rather than an argument about principle.

Certification does not require software, and never has

Management system standards are issued by standards bodies and assessed by certification bodies working under accreditation arrangements, and none of that presumes any particular tool. Plenty of certified operations run on documents and spreadsheets, and plenty of software implementations are found wanting because the underlying process is not followed. What assessment looks for is evidence that a system is defined, operated and reviewed. A file-based approach can supply that, provided the files are controlled, backed up, attributable and retrievable. Sector-specific rules can raise the bar considerably, particularly around record integrity, so check what your own market expects before assuming either answer.

Implementing software will not fix an undefined process

A quality system that exists mainly as habit becomes visible the moment somebody tries to configure it, because software requires decisions: who raises this, who approves it, what states it moves through, what closes it. Those decisions are the actual work, and they are why implementations stall. Doing them first, while still on files, has an underrated benefit — you end with a defined process regardless of what you buy, and the migration becomes a data exercise rather than an organisational one. Starting with a demonstration and adopting somebody else's workflow tends to produce a system your people work around.

Frequently asked questions

Can a spreadsheet-based quality system pass certification?

Frequently, yes. Assessment concerns whether a system is defined, operated, reviewed and evidenced, not which tool holds the records. What draws findings is loss of control: records that cannot be located, documents in circulation at the wrong revision, actions with no evidence of completion, or a log that has clearly been reconstructed after the fact. If your files are controlled, backed up, attributable to a person and retrievable on request, the format itself is rarely the issue.

What makes record integrity harder in a file-based approach?

Three things above all. Attribution, because a spreadsheet cell does not record who typed it or what it previously said. Version certainty, because copies proliferate and the authoritative one becomes a matter of convention. And retention, because a file can be deleted or overwritten without trace. Each can be mitigated through access controls, backup routines and a versioning discipline, but every mitigation depends on people following it, and that dependence is exactly what a system with a built-in audit trail removes.

How should a migration to a system be sequenced?

Define the processes first, while they are still yours to shape, and be explicit about who raises, who approves and what closes each type of record. Then move one process at a time rather than everything at once, starting with the one causing the most pain, so people learn the system on familiar ground. Decide deliberately what historic data comes across; migrating years of records usually costs more than it returns, and keeping the old files as a read-only archive is often sufficient.