Quality Management · 8 min read
The Quality Management Gap: Why Spreadsheets and ISO Binders Still Run Your QMS
Walk into most quality departments — including certified ones — and you will not find a quality management system. You will find a patchwork: a folder of spreadsheets, a shared drive of controlled documents, one analyst's Minitab file, and a monthly export into a BI tool nobody trusts. The certificate on the wall says the system works. The day-to-day says otherwise.
This is a Kanso perspective. See how Kanso runs ISO 9001 and Lean Six Sigma on one platform →
The QMS you have is a filing system wearing a certificate
Here is the uncomfortable part. An ISO 9001 certificate does not mean you have a working quality management system. It means an auditor, on a given week, found enough evidence that your documented process matched what you actually did. Between audits, that evidence lives in whatever tools happened to be lying around when someone needed to record something. A CAPA opened in a spreadsheet. A risk assessment in a Word file with three near-identical copies. An internal audit tracked in someone's Outlook reminders.
None of this is negligence. It is what happens when a quality program grows one requirement at a time. You needed a document register, so you built a spreadsheet. You needed to track corrective actions, so you built another one. You needed a control chart for a customer, so an engineer opened Minitab. Each tool solved its problem. But the QMS was never designed — it accreted. And a system that accretes has no memory, no single source of truth, and no way to see itself whole.
We call this the quality management gap: the distance between the QMS you are certified against and the collection of files you actually operate. Most teams cannot see the gap because they are standing inside it. It only becomes visible when something goes wrong — a recall, a failed surveillance audit, a customer complaint that traces back to a change nobody logged.
Version chaos is the first tax you pay
Spreadsheets do not have a version history you can trust. They have filenames. And filenames are where quality data goes to become fiction. Risk_Register_v4_FINAL.xlsx sits next to Risk_Register_v4_FINAL_updated.xlsx, and the difference between them is a single risk score that someone changed in a meeting and forgot to propagate. Which one is controlled? Whichever one the person answering the auditor happens to open.
The shared drive makes it worse, not better, because it feels like control. Folders, naming conventions, a read-only master copy. But the moment someone emails a spreadsheet to a supplier, or copies a tab to work on it offline, the master stops being the master. You now have two truths, and no log of how they diverged. When we audit a new client's setup, the first thing we look for is not whether they have a document register. It is how many copies of it exist. The answer is rarely one.
The cost here is not just embarrassment in an audit. It is decisions made on stale numbers. A management review that approves a risk profile from a spreadsheet that was superseded two months ago is not reviewing anything real. It is performing the ritual of review over data that has quietly gone out of date.
The audit trail you think you have
Ask a quality manager if they can reconstruct who changed what, and when, across their QMS, and you will get a confident yes followed by a long pause. The confidence comes from the process on paper. The pause comes from the realization that the process depends on people remembering to write things down in a change log that lives in — you guessed it — another spreadsheet.
A real audit trail is not a column called "Last Modified By." It is an immutable record of every state a document, a CAPA, or a risk entry passed through, generated automatically because the system captured it as the work happened. Spreadsheets cannot do this. Shared drives cannot do this. They record the current state and, if you are lucky, a manual note about the last change. Everything before that is gone.
This matters most in the moment you can least afford it. A regulator asks how a specification changed between two production runs. A customer wants proof that a corrective action was actually verified before you closed it. If your answer depends on someone's memory or a note they may or may not have written, you do not have an audit trail. You have a story, and stories do not survive scrutiny.
Analysis that stops at a bar chart
This is the part that quietly costs the most, and it is the part nobody puts in the risk register. Most quality analysis stops exactly where the tool runs out of road. Someone exports records into a BI dashboard, gets a bar chart of complaints by month, and that is where the thinking ends. The chart shows what happened. It does not show whether the process is in control, whether a shift is real or noise, or which of forty variables actually drives the defect.
And here is the opinion I will defend: a bar chart of quality data is often worse than no chart at all, because it manufactures false confidence. A bar that went down looks like progress. But quality data is variation data, and variation lives in control limits, in the run rules, in the distribution — not in whether this month's bar is shorter than last month's. A team looking at a tidy dashboard feels informed. A team looking at an X-bar chart with a Nelson rule violation knows something is wrong. Those are not the same feeling, and most BI tools only ever give you the first one.
The deeper problem is that the analysis and the records live in different worlds. Your control chart is in Minitab. The CAPA it should trigger is in a spreadsheet. The document that should be revised is on the shared drive. So even when the analysis is good, it is stranded. It found a signal, but the signal has to be carried by hand — in an email, a meeting, a mental note — to the place where action happens. Most signals do not survive the trip.
Follow-through that depends on human memory
Every quality system runs on dates. The review date on a controlled document. The due date on a corrective action. The recurrence check thirty days after you thought you fixed something. In a patchwork setup, all of these dates depend on a human noticing them. And humans, reliably, do not.
What we have seen, again and again, is that the QMS does not fail at the moment of the mistake. It fails in the follow-through. The corrective action was well written. The root cause analysis was sound. The document was properly revised. And then the effectiveness check that was supposed to happen sixty days later simply did not, because the reminder lived in a spreadsheet cell that nobody opened. The loop never closed. On paper it is complete; in reality it is a fire that was never confirmed out.
You cannot fix this with discipline, and it is a mistake to try. Telling people to be more careful is not a control. A system that only works when everyone remembers everything is a system with a single point of failure, and that point of failure is a tired person on a Friday afternoon. The follow-through has to be owned by the system, not the person.
What closing the gap actually looks like
Closing the gap does not mean buying a better spreadsheet or a nicer dashboard. It means putting the records and the analysis on the same platform, running on the same live data. When your document control, CAPAs, audits, risk registers, and training records live in one place, the version question disappears — there is one record, and its full history is captured automatically. The audit trail is not a discipline anymore. It is a byproduct of doing the work.
But the real shift is what happens to analysis. When the control chart runs on the same data as the CAPA, a rule violation does not have to be carried by hand to where action happens — the record and the signal are already in the same room. You can run an X-bar chart with the full Nelson rule set, a Gage R&R study, an FMEA, a designed experiment, or a hypothesis test directly against your live quality records, and drop into SQL or a Python and R notebook when the question outgrows the standard tools. The analysis stops being a stranded island. It becomes part of the record.
And follow-through stops depending on memory. The review date, the effectiveness check, the recurrence review — the system holds them, and surfaces them, and flags the CAPA that was closed without its verification step. That is the difference between a QMS that documents work and one that actually runs it. The gap closes not because people try harder, but because the tool finally does the remembering.
A category above the patchwork
This is where Kanso sits, and it is worth being precise about the claim. Kanso is not a cheaper spreadsheet, a friendlier Power BI, or a Minitab you do not have to license. Comparing it to those tools misses the point, because those tools are exactly the patchwork we are describing. The whole idea is to stop stitching a QMS together from four categories of software that were never designed to talk to each other.
What makes it a category above is simple to state and hard to build: the analysis lives on the same platform as the records. The SPC charts, the Six Sigma toolkit, the Data Lab, the nineteen native chart types — they run on the same live data as your document control, your CAPAs, your audits, and your risk registers. There is one source of truth, and everything else is a view onto it. An assistant drafts records and flags drift, so the follow-through has a second set of eyes that never gets tired.
If you run a quality program today, you already know whether you have this gap. It shows up as the spreadsheet you do not fully trust, the analysis that stops at the chart, the corrective action you hope got verified. Naming the gap is the first step. Deciding it is no longer acceptable is the second. We built Kanso, at eclips.tech, for teams that have reached that second step — not because certification demands it, but because they are tired of running a quality system on tools that cannot remember what they did last month.
See Kanso in action
One platform for ISO 9001 and Lean Six Sigma — with the analytics to query and model your quality data in SQL, Python, and R.
Book a walkthrough