The difference between a quality record and a quality operation

We digitised. So why is everyone still calling each other?

Most conversations with a quality manager stall at the same point. Ask about the system: there is one. Ask about the procedure: there is one. Ask about the team: it is experienced. Then comes the question: “Which of today’s open cases is at risk?” The answer is usually not a screen but a name. “Ayşe knows that one.”

That answer is not a competence problem. Quite the opposite: it shows that the work genuinely gets done — but it also shows that execution runs on the attention of a few people rather than on an institutional mechanism. The quality data is digital; the quality operation is not.

Two different questions: “what happened?” and “who does what now?”

Most debates about quality software end inconclusively because they put two very different questions into the same box.

An organisation can answer the first question perfectly and leave the second unanswered. In fact that is precisely the most common situation, because record systems were designed to do only one of these two jobs — and they usually do that job well.

The natural limit of a record system

There is an easy mistake to make here: accusing record systems of inadequacy. That is both wrong and unhelpful. Enterprise systems have taken their present shape for sound historical reasons. The centre of an ERP is the commercial transaction; the centre of an MES is the production order; the centre of a PLM is the product definition and its revisions; the centre of a quality management system is the record, the document and compliance. Each is strong at its own centre.

The problem arises not inside the systems but between them. When a customer complaint arrives, the work does not sit at the centre of any single system:

• Customer, order and shipment context sits in the ERP.
• Product definition and revision sit in the PLM.
• Production conditions and lot data sit in the MES.
• Procedures and templates sit in the document repository.
• But “who does what, by when, with which evidence” sits in none of them.

That last one is not a data question but an execution question. Because it lies at nobody’s centre, it is left in between — and work left in between naturally falls to the nearest flexible tool: email, spreadsheets, calendar reminders and personal memory.

The five breaking points of an operation

The difference between record and operation is not an abstract debate. It becomes visible every day, at five concrete points.

1. Ownership

A record has an “owner” field. In an operation, ownership is not a field but a mechanism: who the work falls to the moment it is opened, what happens if that person is unavailable, how the work is divided when more than one department is required. A record with the owner field filled in does not mean the work has been owned.

2. Due dates

A record has a date. In an operation, what matters is where the due date comes from, how it changes by customer or case type, and what happens as it approaches. If the same OEM expects different response times for two different complaint types, a single fixed date field cannot carry that reality.

3. Evidence

In a record, a file is attached. In an operation, what is tracked is which decision that file is evidence of. The difference surfaces during an audit: ten attachments in a folder mean nothing; knowing which attachment justified the closure of which step means a great deal.

4. Escalation

A record can show a delay. An operation makes that delay bring in the right level of management. The difference is timing: a delay seen in a report is a delay that has already happened, whereas rule-based escalation gives you the chance to prevent a delay that has not happened yet.

5. Learning

In a record, a closed case goes into the archive. In an operation, the verified root cause that came out of a closed case is carried into future decisions on similar products and processes. The difference is whether the same problem reappears six months later on a different line.

You have the record but not the operation: seven symptoms

What follows are symptoms not of missing software but of an execution gap. How many of them feel familiar gives you a good sense of how wide that gap is.

1. To find out the status of a case, you ask the person following it rather than the system.
2. A significant part of the weekly quality meeting is spent answering “where does this one stand?”.
3. You re-enter the same information in two or three systems, or reconcile it by hand.
4. You learn that an action is late only after it is already late.
5. As an audit approaches, assembling the evidence turns into a project of its own.
6. Actions are marked “complete”; whether they actually worked is not separately verified.
7. When the person who knows the process best takes leave, the flow no longer runs the same way.

None of these items says “your system is bad”. They all say one thing: the work itself does not run in the system, it runs between people.

Why “we have a dashboard” is not enough

Visibility and control are often confused. A dashboard shows you what has happened; it does not carry out the intervention itself. A case that has turned red on the panel is red because it is already late. In other words, the panel reports the event after the fact.

This is where the operation layer begins to differ: risk becomes visible before the event, and visibility is tied not to a notification but to a defined behaviour. “If this step exceeds this duration, it goes to this role” is not a reporting rule but an operating rule.

What does an operation layer do?

The way to close this gap is not to replace the existing systems. Data ownership stays with the source systems. What is needed is to run the quality work that falls between them in a layer that has a name of its own. That layer has four jobs:

• Establishing the context. Bringing customer, product, lot, shipment, standard and criticality together at the moment the case is opened — so that the work reaches the right team with the right priority.
• Giving the work an owner. Turning the methodology from a document into a chain of tasks, dependencies and control points.
• Managing time and risk. Applying time targets according to the context of the case; raising late work by rule instead of letting it wait in silence.
• Separating closure from learning. Making completion and effectiveness two distinct steps; turning a verified result into reusable knowledge.

Note that none of these is “a better form”. Every one of them is about moving into the system the rules that today sit in people’s memory.

Where to begin

Trying to close this gap in a single move produces, in most organisations, the same result as not closing it at all. The more workable route is to begin with the single flow where the difference is felt most sharply. Customer complaints and the 8D/CAPA operation are a natural starting point for that: external customer pressure, short due dates, many stakeholders, a requirement for evidence and effectiveness verification all become visible at once.

There is one question to answer before starting: which step of this operation depends today on one person remembering? Writing that answer down is often more valuable than choosing a piece of software — because the answer also determines what the software has to do.

If you would like to place your own operation in this light, the maturity model offers a shared language, while the twelve-question stress test shows you in a few minutes where you stand across four dimensions.