How OKELAS Organizes eQMS: From Document to Evidence to Audit Trail

2026-10-04

Executive Summary

• Most eQMS products organize data around the document: documents are stored, approved, released. This handles version control well, but leaves a gap: a document doesn’t tell you what actually happened.
• OKELAS approaches it as a chain: Process → Workflow → Event → Evidence. A process defines what should happen, a workflow runs it, each action is an event, and each event leaves evidence tied to its context.
• When actions are recorded as events from the start, the audit trail is a consequence of the design, not something rebuilt before each audit.
• This approach isn’t always necessary. For a small company, stable processes, or a need that is only document control, a DMS or a simple eQMS may be enough.
• This article describes an approach and design direction. The specific scope for any company is set by its process maturity and actual needs.

What traditional eQMS leaves unsolved

The earlier articles in this series went through the components of a quality system: document control, nonconformance, corrective action, internal audit and the rest. Each ended in the same place: an eQMS makes control depend less on human discipline, but it doesn’t solve everything.

There is a deeper limit, in how data is organized.

In a document-centered eQMS, the basic unit is the document: procedures, forms, records. They’re stored, approved, released and versioned. That’s what such systems do well.

But when an auditor asks “show me how this nonconformity was handled, under which procedure revision, and who was retrained,” the answer isn’t in any single document. It lives in a chain of events linking several documents, people and points in time. In a document-centered system, that chain usually has to be rebuilt by hand.

It’s the same gap analyzed in the article on DMS versus knowledge management: a DMS manages documents as independent units, but operational knowledge is a connected network. The auditor’s question, and the executive’s, is usually a question about that network.

How OKELAS looks at document control

OKELAS doesn’t start from “where is the document stored,” but from “what role does this document play in how the company operates.”

In this approach, a document doesn’t stand alone. It’s a node in a network connected to:

• the process it governs;
• the roles that must follow it;
• the training needed to apply it;
• the events that have referenced it (nonconformance, audit, change);
• the history of its versions and reasons for change.

An important point: OKELAS is not a replacement DMS, and isn’t meant to replace document storage tools. Version control, approval and distribution remain the foundation, in line with what clause 7.5 of ISO 9001:2015 requires. What differs is that the document is placed in its operating context.

The practical result is that three kinds of questions a document store typically can’t answer become answerable:

• Context: how does this procedure apply to a specific product or condition?
• History and cause: why was the procedure set this way, was another approach ever tried?
• Relationship: if this procedure changes, what else is affected?

Process → workflow → event → evidence in eQMS

This is the core of the approach. The four concepts can be understood like this.

Process. Defines what should be done: steps, roles, requirements.

Workflow. How the process actually runs: who does what, in what order, with what approvals and deadlines.

Event. Each action that happens in the workflow is an event: a document drafted, approved, released, a person confirming they’ve read it, a nonconformity logged, an audit finding opened.

Evidence. The event leaves evidence: who did it, when, on which version, under what authority, and in what context.

The distinction is that evidence is created as part of the work, not assembled after it.

Illustrative example (a design scenario, not a customer case): a work instruction is updated. In the event-based approach, this chain is recorded as it happens: a draft is created, the reviewer and approver confirm, the new version takes effect, the old version changes status, affected people are notified, a training requirement is assigned, each person confirms completion. If a nonconformity later occurs at this step, it links into that same chain. The question “who was trained on which version” becomes a query, not a search.

This view ties to a broader chain OKELAS uses to describe how a business runs: Process → Workflow → Event → Evidence → Knowledge → Decision → Action. eQMS is where the first four concepts are applied to the quality problem, and the later ones (knowledge, decision, action) are a natural extension, covered in the final article of the series.

The audit trail as a consequence of design

In many systems, an audit trail is an added feature: the system logs who did what. Useful, but a log that separates each event is often hard to read as a story.

With an approach that takes the event as the unit of record, the audit trail is a consequence of design. Because every action is recorded as an event with context, rebuilding the story is no longer a task before each audit.

This relates to a principle OKELAS uses throughout: a good answer isn’t only correct; it can explain itself, point to evidence and be traced (Explain → Evidence → Trace).

For eQMS, that principle has concrete meaning:

• When an auditor asks about a nonconformity, you follow the chain of events: detection, correction, cause analysis, action, effectiveness check.
• When a customer asks about a batch, you trace from the batch to the documents, people, training and suppliers involved.
• When leadership needs data for a review, it already sits in the chain and doesn’t need separate compilation.

On the standard’s side, this supports the evidence-retention requirements that run through ISO 9001:2015, such as retaining information as evidence of audit results (9.2), management review (9.3), nonconformity and corrective action (10.2), and protecting retained information from unintended alteration (7.5.3). The article Evidence in eQMS goes deeper into the difference between documents and evidence.

To be clear: a good audit trail doesn’t replace the quality of the action recorded. A weak root cause analysis is still weak even when fully logged. The system makes proving easier; it doesn’t make the work better.

Two approaches compared

The table below compares two ways of organizing an eQMS at the level of principle, not against any specific product.

Two things to face squarely. The second approach asks for more preparation: clarifying processes and roles before the system can record meaningful events. And not every company needs it.

When OKELAS fits, and when it may not

The principle OKELAS follows is to solve the operational problem with the smallest sufficient system. That applies to OKELAS itself.

It may fit when:

• The main problem is traceability and evidence: audits take long to prepare, or chains of action are hard to prove.
• Quality records, processes and knowledge sit apart, and the real task is connecting them.
• The company wants to open the way for AI that supports operations with context and evidence, rather than AI that only searches files.
• The company is willing to clarify processes as part of implementation.

It may not be needed when:

• The company is small, processes are stable, and the current paper or file system still works at reasonable cost (see From Paper QMS to eQMS).
• The main problem is only finding documents and controlling versions: a DMS or a simple eQMS may be enough.
• Processes aren’t agreed and there’s no intent to clarify them: any system will just record the ambiguity.
• The company faces specific requirements for electronic records systems that need separate checking before choosing a solution.

On implementation, OKELAS follows a progressive eQMS direction: start from the biggest pain point, usually document control, then expand with maturity, not roll out a whole suite at once. For companies with sensitive data or compliance requirements, on-premise deployment is a possibility to consider case by case, rather than assuming everything must run in the cloud.

OKELAS is also not an ERP. If a company has or is about to have an ERP, the two play different roles: the ERP manages transactions and structured operational data, while OKELAS manages understanding and process context around that activity.

A note on the scope of this article

This article describes OKELAS’s approach and design direction in eQMS. It doesn’t describe the results of any specific customer, doesn’t give improvement figures, and doesn’t commit to a fixed list of features. The specific scope for any company depends on its process maturity, sector and customer requirements, and actual needs, and is determined in discussion.

A note on ISO 9001 editions

References in this article are to ISO 9001:2015. According to certification bodies, a revised ISO 9001:2026 was scheduled for publication in September 2026, with a transition period expected to run about three years and 2015 certificates remaining valid during it. Clause structure and wording may change; check against the edition your organization is certified to.

Is your quality system recording documents, or recording what actually happens?

→ Contact OKELAS to discuss how to organize an eQMS suited to your manufacturing business’s maturity and needs.

Further reading:

• Management Review in ISO 9001: Why the Meeting Rarely Works — and How to Change That (previous)
• Evidence in eQMS: What It Means for Every Action to Be Verifiable (next)
• Evidence-Based AI: When Answers Need to Be Verifiable (related)
• AI Reasoning vs. Organizational Truth (related)
• eQMS for Manufacturing SMEs: A Practical Guide (pillar)

Sources:

• ISO 9001:2015, clauses 7.5.3 (control of documented information), 9.2 (internal audit), 9.3 (management review), 10.2 (nonconformity and corrective action): iso.org/standard/62085.html
• LRQA, ISO 9001 revision update: Publication date confirmed (certification body source; verify with ISO): lrqa.com

ISO 9001:2015 clauses are summarized in practical language and do not replace the text of the standard. The example is an illustrative scenario for the approach, not a specific customer case. The comparison table is at the level of principle and is not an assessment of any specific product. Content about OKELAS describes an approach and design direction, not a commitment on outcomes or a feature list.