Process Documentation: From Static Docs to Live MES Models

What process documentation actually is

Process documentation in manufacturing is the structured, persistent representation of how a production process should run — the steps, the sequence, the machines involved, the parameter setpoints, the quality checkpoints, the responsibilities, the exception handling. It is the answer to the question "how do we make this product, exactly?", captured in a form that survives operator turnover, shift changes, and the gap between what the process engineer intended and what the line runs today. Every manufacturing operation has process documentation; the operationally consequential question is what form it takes.

For most of the last forty years the form was paper, or paper's digital imitation — Word, Visio, Excel, PDF files sitting on a shared drive or in a document management system. That form has one advantage and three fatal limitations. The advantage: it is cheap to produce and universally understandable. The limitations: it cannot be executed, it drifts silently from reality, and it scales badly across plants and product variants. The architectural shift that modern MES platforms enable — and the one that defines the difference between a process documentation system and a live process model — is moving the documentation from a description of how the process should run into the runtime that actually runs it. Documentation stops being a reference artifact and becomes the executable specification that drives the shopfloor. That transition is the subject that most competitor glossaries skate over in a sentence, and that determines whether the investment pays back in 18 months or in never.

Six terms that keep getting confused

Process documentation, work instruction, standard operating procedure, recipe, routing, process map — the six most overlapping concepts in manufacturing documentation vocabulary. They are not interchangeable. The distinctions decide which artifact lives where in the system architecture and who owns it.

The failure mode this table is designed to prevent: treating the process map (the graphical Visio diagram) as if it were the process documentation. The map is a communication artifact; it cannot drive execution, it cannot enforce parameter limits, it cannot capture the shift and operator who ran each step, and it goes out of date the moment a parameter is tweaked on the line. Plants that equate the two end up with a beautiful Visio wall chart that was current in 2019 and an actual process that nobody has ever written down. Process documentation in the serious sense is the model that the MES executes against, not the PDF that the process engineer drew.

Static artifacts vs. executable models — the axis that matters

The single architectural decision that determines whether process documentation pays back or remains expensive paperwork is where on the static-to-executable axis it lives.

The business case for moving from the left column to the right column is not documentation quality. It is the elimination of documentation drift — the gap between what the process documentation says and what the line actually runs — which grows silently in static-artifact systems and is almost always the root cause when quality failures surface months after a process change nobody remembered to re-document. In executable-model systems the drift cannot grow because the model is the runtime; there is no separate "actual process" to drift away from. That property alone is usually worth the migration cost, before any of the downstream analytics benefits are counted.

The ISA-95 and ISA-88 standards — the model underneath

Behind any serious executable process model in a modern MES is the ISA-95 / ISA-88 standard family. This is the part that competitor glossaries routinely skip because it is technical, and the part that every serious MES buyer should understand because it determines whether the vendor's process model can survive a plant-to-plant rollout or whether every new site will need a rewrite.

The practical consequence: a process model built against ISA-95's Process Segment structure can be serialized to B2MML, exchanged between systems, and rehydrated in a different MES without semantic loss. A process model built as a proprietary data structure — which is what most first-generation on-premise MES products shipped, and what several current cloud-native contenders still ship — cannot. That difference is invisible on demo day and decisive in the third year, when the second plant goes live and discovers that the process model from plant one has to be rebuilt by hand because there is no canonical interchange path. The architectural decision to base the process model on ISA-95 is the one that keeps rollout cost sub-linear as sites are added; everything else is implementation detail.

Versioning, effective dating, supersedure — the hardest operational problem

The operational problem that defeats more process-documentation systems than any other is versioning. Static-artifact systems "solve" it through filename conventions and folder hygiene, which fails silently and catastrophically in audit. Executable-model systems solve it through three mechanisms that have to be designed in from the start, not bolted on later.

1. Immutable versions. Every change to a process definition produces a new version; old versions are never edited in place. This is the same principle as Git for source code, for the same reasons: auditability, reproducibility, the ability to answer "which version ran on 2024-03-12 at 14:37" with a single database query rather than an archaeology expedition.
2. Effective dating. Each version carries an effective-from timestamp and, once superseded, an effective-to timestamp. The runtime selects the version whose effective window covers the execution moment — not the "current" version, because the current version at query time is almost certainly not the version that ran the unit in the traceability record. Effective dating decouples edit time from execution time, which is the property that makes historical traceability work correctly across the calendar.
3. Controlled supersedure. A new version does not automatically go live when saved. It goes through a change-approval workflow (see change control), gets an approved effective-from timestamp, and only at that timestamp does the runtime switch over. Supersedure is an event, not a side-effect, and the event is recorded in the audit trail with the approver identity, the reason, and the diff against the prior version.

Plants that try to retrofit this onto a static-artifact system end up with what I have seen called the "PDF version number problem": the document says Rev 7 in the header, the filename says Rev 8, the QMS registry says the current revision is 6, and the operator on third shift has a printout from Rev 5 taped to the station. Every one of those revisions is traceable to a real engineering intent; none of them is traceable to which unit ran under which revision. Executable-model systems cannot produce that failure mode because the version that ran a unit is captured by the runtime, not by hope.

From the SYMESTIC platform rebuild decision, mid-2010s: when we decided not to lift-and-shift the existing on-premise MES codebase into the cloud but to rebuild the platform from scratch, the question that took the longest to settle — longer than the microservice decomposition, longer than the Azure infrastructure topology, longer than the choice of messaging backbone — was how to represent process definitions internally. The old on-premise product had a process-definition model that had accreted over fifteen years of customer projects: a mix of relational tables, XML blobs in a content field, plant-specific extensions done as stored procedures, and a handful of customer-specific hard-coded paths in the execution engine. It worked, because enough of the team remembered why each piece was there. It did not scale, because every new plant rollout required someone who remembered the history to adapt the model, and the "someone who remembered" was a bus-factor-of-three problem in a team of sixty. The decision we made, and the one I would make the same way again, was to build the new platform around an ISA-95-aligned Process Segment model as the canonical representation and to treat everything else — the old proprietary format, Word-document uploads, legacy XML — as import adapters into that canonical form. The migration cost was enormous: eighteen months of parallel running, every customer migration individually validated, three customer-specific process patterns that we had to upstream into the canonical model because they were not isolated weirdness but legitimate variations the standard had not anticipated. What held, and what made the rebuild the correct decision in hindsight, was that once a process definition was expressed in the canonical form, the version control, effective dating, supersedure workflow, runtime execution, traceability linkage and audit-trail generation all came for free — they were properties of the canonical model, not features we had to implement per customer. The first customer we migrated onto the new platform was a metal-forming operation with fourteen process variants for the same product family; in the old system adding a fifteenth variant had been a two-week engineering task with platform-team involvement. In the new system the customer's own key user added the fifteenth variant in about four hours, with zero platform involvement. That was the moment I knew the rebuild had been worth the eighteen months. The lesson I still use on every architecture review: the data model is the part that has to be right the first time, because everything else downstream compounds the decision. Process documentation is not a feature; it is the data model of the MES, and the data model has to be the standard, not a derivative of it. Anything else turns into exactly the accretion-of-history pattern the rebuild was meant to escape, and the second-generation pattern is harder to unwind than the first because by then customers are production-dependent on the quirks.

The Process Owner role — RACI that actually holds

Process documentation without a named owner is filing. The Process Owner role is what turns it into a control mechanism, and the role only works if the RACI around it is explicit. The pattern that works — taken from mature plants, not from methodology textbooks — is a five-way split.

The failure mode that this RACI is designed to prevent: collapsing Process Owner and Approver into one person. When the same person who edits the process definition also approves it for production, the audit trail becomes ceremonial and the whole version-control discipline loses its meaning. The separation does not have to be elaborate — in a medium plant the process engineer authors and the quality manager approves, and that is enough — but it has to be real, enforced by the system at the workflow level, not by goodwill.

The regulated-industry overlay — GMP Annex 11, IATF 16949, 21 CFR Part 11

In regulated industries the executable-model approach is not an optimisation, it is a requirement. The specific standards impose architectural constraints on how process documentation has to be represented:

• EU GMP Annex 11 (computerised systems in pharma and medical device manufacturing): process definitions that drive production must be subject to formal change control, electronic signatures on approval, an audit trail that is readable, writable-but-not-editable, and retention for the product lifetime. The "writable-but-not-editable" audit-trail requirement is what rules out most static-artifact approaches immediately — a Word document cannot satisfy it.
• IATF 16949 (automotive quality): the process definition has a specific named artifact, the Control Plan, which links each process step to the characteristic being controlled, the specification, the measurement method, the sample size, the reaction plan. Auditors specifically probe whether the Control Plan on paper matches what the line actually runs; in executable-model systems the two are the same artifact by construction.
• FDA 21 CFR Part 11 (electronic records and signatures for pharma/medical device products sold into the US): electronic signatures on process definition approvals must be unique to the signer, linked to the record they authorise, and resistant to copying or transfer. This forces Active-Directory-linked authentication, reason-for-signature capture, and cryptographic binding between the signature event and the version being signed.

For customers in these industries the process documentation question is not whether to move from static artifacts to executable models — the regulator has already answered it — but how to meet the technical requirements without turning the plant into a compliance exercise that buries operations under paperwork. The executable-model approach that works in non-regulated industries as an optimisation is the only approach that works in regulated industries at all, because the audit-trail and signature requirements cannot be bolted onto a document-management system retrospectively. See also role-based access control and change control for the adjacent architectural pieces.

Documentation drift — the KPI you should be tracking but probably aren't

The metric that most plants don't measure, and that every executable-model system makes cheap to measure, is documentation drift — the divergence between what the process documentation says should happen and what actually happens at the line. In static-artifact systems drift is invisible by construction, because the only way to detect it is a process audit, which happens annually at best. In executable-model systems the live execution data is continuously compared against the model, and drift surfaces as three measurable patterns:

• Parameter excursion rate — the share of produced units where at least one process parameter fell outside its documented band. A healthy figure is <0.5 %; above 2 % indicates the documented band is wrong or the process has shifted.
• Exception-override rate — the share of steps where an operator had to override the executable model (with a logged reason) to produce the unit. Above 1 % indicates the model does not reflect operational reality.
• Version-deprecation rate — how quickly new process versions replace old ones. A plant with a version every two days is chasing reality instead of leading it; a plant with no version change in two years is either perfect (rare) or not actually maintaining its model (common).

Tracking these three numbers turns process documentation from a compliance artifact into a leading indicator for quality and OEE problems. They are the drift metrics that expose the documentation-to-reality gap before it surfaces as a customer return or an audit finding, and they cost effectively nothing to produce once the executable-model architecture is in place — which is the last argument for the architecture choice and the one that compounds the longest.

How this fits into the SYMESTIC platform

SYMESTIC represents process documentation as first-class executable models in the Level 3 (ISA-95) layer, with the Process Segment as the canonical structure and B2MML as the interchange format for ERP integration and cross-site exchange. Versioning is immutable with effective dating and explicit supersedure workflow; the runtime selects the process version whose effective window covers the execution moment, not the current version at query time, so historical traceability remains correct across calendar boundaries. For regulated-industry deployments the approval workflow is integrated with Azure Active Directory for Part 11-compliant electronic signatures, the audit trail is writable-but-not-editable with full retention across the retention-policy horizon, and the Control Plan structure is supported natively for IATF 16949 automotive deployments. Process Owner, Technical Author and Approver are separate roles in the RBAC model (see role-based access control), enforced at the workflow level rather than by organisational convention. Drift metrics — parameter excursion rate, exception-override rate, version-deprecation rate — are available as standard dashboard elements alongside OEE, RTY and schedule adherence, because the whole architectural bet is that process documentation becomes actionable only when the model drives the runtime and the runtime's deviations from the model feed back into the improvement loop. The bidirectional ERP integration (SAP R/3 via ABAP IDoc, Microsoft Dynamics/Navision, Infor/InforCOM, proAlpha) carries routings and operation definitions into the MES and completion feedback back to the ERP, so the process documentation in the MES and the master data in the ERP stay aligned through the integration rather than through manual reconciliation. This is the architecture decision that made the platform rebuild mid-2010s the correct one, and it is the decision that determines whether a process-documentation project produces an improvement engine or an expensive filing system.

FAQ

What is the difference between process documentation and a standard operating procedure (SOP)?
Process documentation is the complete executable model of a production process — steps, parameters, checks, roles, exception handling — and it lives in the MES where it drives runtime execution. An SOP is the regulatory-compliance formalisation of a procedure, typically a document in a Quality Management System, approved and controlled for audit purposes. In regulated industries the two often have to coexist, with the SOP referring to the executable model as the authoritative runtime specification and the SOP itself covering the human-readable procedural narrative. Treating the SOP as the complete process documentation is the most common compliance shortcut and the one most likely to fail an Annex 11 or IATF audit, because an SOP cannot enforce parameter limits at runtime and cannot produce the version-specific traceability modern audits require.

How is process documentation different from a work instruction?
Process documentation is the full model of the process — all steps, all parameters, all variants. A work instruction is the operator-facing view of a specific step at a specific station, derived from the process documentation at runtime and displayed at the shopfloor terminal. One process definition typically generates dozens of work instructions, each for a specific combination of station, product variant, shift and operator skill level. The work instruction is downstream of the process documentation; changing an instruction without changing the underlying documentation is the classic anti-pattern that produces drift between documented and executed process.

Do I need ISA-95 compliance for process documentation to work?
Not formally, but practically yes. A proprietary process-definition model can work inside a single plant with a single MES vendor; the moment a second plant, a second vendor, or a corporate-level consolidation is in scope, the proprietary model has to be translated into something, and the translation is expensive and lossy. ISA-95 (with B2MML as the XML serialisation) is the standard the translation would be into anyway, so starting with it eliminates the migration cost. For customers running more than one plant or planning ERP consolidations across sites, ISA-95 alignment is less an optional best practice and more a structural requirement for keeping rollout cost sub-linear as sites are added.

How do I handle process documentation across multiple plants with local variations?
The pattern that works is a three-layer model: a corporate-level process template that captures the invariant logic (mandatory steps, minimum parameter bands, required checkpoints), a plant-level specialisation that fills in equipment-specific details (which machine model, which sensor IDs, which operator terminals), and an order-level resolution that picks the appropriate plant-specialised version at execution time. The template is owned at corporate, the specialisation is owned at plant, and the resolution is automatic. Attempting to maintain fully-separate process definitions per plant produces drift within a year; attempting to enforce a single corporate definition without specialisation layer produces operator-level workarounds within weeks. The three-layer model is the middle path, and it maps cleanly onto ISA-95's Process Segment hierarchy.

What is documentation drift and how do I measure it?
Documentation drift is the divergence between what the process documentation says and what the line actually runs. In static-artifact systems it is invisible until an audit reveals it. In executable-model systems three leading indicators expose it continuously: parameter excursion rate (units produced outside documented parameter bands), exception-override rate (runtime overrides of the executable model), and version-deprecation rate (how quickly new versions replace old ones). Healthy plants run parameter excursion below 0.5 %, exception-override below 1 %, and have a version change cadence that reflects real process-improvement activity rather than noise. Tracking these three numbers as live dashboard elements turns process documentation from a compliance ritual into a leading indicator for quality and OEE problems.

Who should own process documentation — production, quality, or engineering?
Production — specifically the Process Owner in the manufacturing-engineering or production-management function — should be accountable for the process definition's correctness and performance. Quality should approve version changes before they go live, through the change-control workflow. Engineering (specifically MES key users) should author the definition in the system. The three roles must be separated; collapsing Process Owner and Approver into one person defeats the purpose of version control, and putting authoring responsibility on quality defeats the purpose of having production own its own processes. The exact role assignments flex by plant size and industry, but the separation does not.

How does process documentation interact with change control?
Every new version of a process definition flows through the change-control workflow before it becomes the effective version at runtime. The workflow captures the reason for the change, the impact assessment, the approver identity, the effective-from timestamp, and the diff against the prior version. In regulated industries the change-control workflow also captures electronic signatures per 21 CFR Part 11 / GMP Annex 11. The two concepts are complementary: process documentation is the what (the process model), change control is the how (the governance around modifications). Neither works without the other; a process-documentation system without change control produces the PDF-version-number problem, and a change-control system without executable process documentation controls paper that the line is not actually running.

Related: MES: definition, functions & benefits · OEE: definition, calculation & practice · MES software compared · OEE software · Change control · Work plan · Recipe management · Role-based access control · BOM explosion · Rolled Throughput Yield (RTY) · Schedule adherence · On-Time Delivery · Scrap rate vs. rework rate · Process data module · Production control module · Production metrics module · Automotive · Metal processing · Food & beverage · Plastics processing · For production managers · For operational excellence · For COOs & plant managers. External references: ISA-95 (Enterprise-Control System Integration) · ISA-88 (Batch Control) · MESA B2MML schema.

About the author

Mark Kobbert

CTO of SYMESTIC GmbH. B.Sc. Wirtschaftsinformatik, SRH Hochschule Heidelberg. Responsible for the SYMESTIC Cloud-MES platform architecture since 2014: microservice architecture on Microsoft Azure, IoT-gateway connectivity, real-time processing of >15,000 machines in 18 countries, 99.9 % availability target. Led the mid-2010s platform rebuild from proprietary on-premise MES to cloud-native, API-first, ISA-95-aligned process-definition model. Expertise: cloud-native MES architecture, Microsoft Azure, microservice architecture, OPC UA, MQTT, IoT gateway development, edge computing, ISA-95 / ISA-88 integration architecture, B2MML, industrial connectivity, brownfield machine integration, REST APIs, C#/.NET, SQL, Docker/Kubernetes, real-time data processing, IT/OT convergence. · LinkedIn