Change Control in Manufacturing: The Engineer's View

What Change Control actually is

Change Control is the formal, documented process for evaluating, approving, testing and releasing any change to a quality-relevant element of a manufacturing system — a machine, a recipe, a PLC programme, an MES configuration, a validated document or a system integration. Its purpose is to ensure that changes become effective only after their impact on quality, compliance, safety and operational stability has been reviewed, and that the complete change history remains traceable for audits and incident investigations. In GMP-regulated environments it is mandatory under FDA 21 CFR Part 11, EU GMP Annex 11 and ISO 13485. In automotive it is covered by IATF 16949 through Engineering Change Requests, Notices and Orders. In food production it sits under HACCP and ISO 22000. Outside regulated industries it is often informal — which is where most of the avoidable problems originate.

That is the textbook definition. The clarification that actually helps the reader: "Change Control" is one phrase used for at least four distinct governance processes, and most confusion in real projects comes from conflating them.

The four things people call "Change Control"

All four are called "Change Control" in various industries, and they are genuinely different processes with different owners, cadences, evidence requirements and failure modes. When a pharma QA manager and an automotive engineering manager and a cloud-MES IT manager sit in the same room and all say "Change Control," they are talking about three different things. Getting this disambiguation right on day one prevents most of the misalignment that otherwise appears in month four.

The Change Control workflow, and where it actually breaks

A standard workflow looks the same across all four variants and runs through five steps: request, impact assessment, approval, test/validation, release and documentation. Each step has a characteristic way of breaking.

• Request. A change is proposed, usually as a form or a ticket. Breaks when the requester does not describe the change precisely enough for an impact assessment — "update the pressure sensor on Line 3" is not a change request; "replace pressure sensor S-17 on Line 3 (4–20 mA, 0–16 bar) with replacement part X (4–20 mA, 0–25 bar, recalibration required)" is.
• Impact assessment. Cross-functional review of quality, compliance, safety, operational and system-integration impact. Breaks when it is signed off by whoever happens to be available that day rather than by the roles whose sign-off the SOP actually requires. Also breaks when the assessor does not know the downstream systems — a sensor change affects the MES data pipeline if the range changes, and that impact is invisible to the maintenance technician proposing the change.
• Approval. Formal authorisation, usually by quality, engineering and production. Breaks in the two opposite directions: too slow (quality needs two weeks, production needs the change by Friday) and too fast (rubber-stamping without actual review).
• Test and validation. The change is executed in a controlled way and verified against defined acceptance criteria. Breaks when the test environment does not match production — the classic MES-configuration pitfall where a workflow change works in a test tenant and fails in production because the test tenant has different master data.
• Release and documentation. The change goes live, the documentation is updated, the audit trail is complete. Breaks when the change goes live but the documentation update is "done tomorrow" and never is. Within a year the system diverges from its documented state, and the next audit finds it.

Observation from two decades of PLC retrofits: the textbook example of a change that is genuinely high-risk and genuinely Change-Control-worthy is the Simatic S5-to-S7 migration. I have done these on beverage lines, on automotive stamping presses, on food packaging equipment. The retrofit itself is two to five days of physical work. The Change Control around it, done properly, is two to four weeks of paperwork. The ratio is not a bureaucracy problem — it is the honest acknowledgement that a PLC migration touches process logic that has been running for fifteen or twenty years, is understood in the heads of maybe two or three people in the plant, and whose edge-case behaviour cannot be fully re-derived from the source code alone. The way these retrofits go wrong is never at the moment of the retrofit. They go wrong six weeks later, when a special-cause condition that the old S5 programme handled silently — a sensor fault combined with a specific product variant during a specific shift pattern — triggers behaviour in the new S7 programme that nobody predicted because nobody had documented the original behaviour. The Change Control discipline is not about paperwork; it is about forcing the conversation that extracts that tacit knowledge from the two people who have it before the retrofit happens, not after. When the Change Control is skipped or rushed, this conversation never happens, and the tacit knowledge leaves the plant the next time one of those two people retires. That is the expensive failure mode, and it is invisible to anyone reading a Change Control SOP as pure bureaucracy.

Silent changes — the category that never enters the SOP

Every Change Control system has a blind spot: the changes that happen daily and never feel like "changes" to whoever makes them. This is where most real incidents originate, and it is the reason even a perfectly-run Change Control programme is not enough on its own.

• Like-for-like sensor replacements. A pressure sensor fails and is replaced with "the same one from stock." Six weeks later someone notices that stock contained a slightly different variant — same form factor, different characteristic curve — and the historical trend data has been subtly wrong since the swap. No Change Control ticket was written because the technician genuinely believed it was like-for-like.
• Gateway and IoT firmware auto-updates. Edge devices that auto-update their firmware. The update itself is fine, but it introduces a new timestamp format, or a new default sampling rate, or a subtle behaviour change in how alarms are batched. The MES-side logic was tuned to the old behaviour. Nobody raised a change ticket because the update was automatic.
• Control-loop re-tuning. A technician adjusts PID parameters on a line to improve throughput, logs the change in their notebook, does not raise a formal Change Control. Three months later the process is drifting in an unexplained way, and the adjusted parameters are one of four plausible causes — nobody can reconstruct which.
• MES KPI-definition tweaks. Someone changes how availability is calculated for Line 2 — maybe excluding planned maintenance where previously it was included, or changing the start-of-shift boundary from 06:00 to 06:15 to match actual practice. The dashboard now shows different numbers, cross-plant comparisons are quietly broken, and no Change Control was written because "we just corrected the definition."
• Workarounds that become permanent. A temporary fix ("bypass the interlock on Station 4 until we get the new part") that never gets properly reversed. Six months later the bypass is documented nowhere but is load-bearing for daily production.

A Change Control system that does not have a mechanism for catching these categories — periodic configuration audits, structured post-incident reviews, automated change detection at the signal and MES-configuration layer — will look perfect on paper and fail in practice. The honest way to handle silent changes is not to make the Change Control process heavier (which pushes more changes into the silent category); it is to build detection into the systems themselves so that a change that was not formally announced still becomes visible.

Creeping formalism — the opposite failure mode

The other direction where Change Control goes wrong is less discussed because it is less spectacular. It is the gradual extension of pharma-grade Change Control rigour to domains where it is not warranted.

• Over-applying GMP-grade process to discretionary changes. A food plant that is not in GMP scope adopting Change Control paperwork of a complexity appropriate for a sterile injectable line. The cost is real, the benefit is minimal, and the predictable downstream effect is that engineers stop raising formal changes for small improvements — and the silent-change category grows.
• Sign-off lists that exceed the review capacity. A Change Control form that requires six signatures, three of which are from roles that cannot meaningfully review the change at the pace the production floor needs. The sign-offs become rubber stamps within a quarter.
• Treating every MES-configuration change as a validated-system change. A dashboard layout change is not the same as a quality-rule change. A shift-pattern adjustment is not the same as a recipe change. Applying the same level of Change Control to all of them dilutes the meaningful ones.
• Confusing traceability with prior approval. Some changes are low-risk enough that a complete after-the-fact audit trail is sufficient; not every change needs prior approval. Distinguishing these categories honestly is harder than applying one process uniformly, but it is how the programme survives the first year.

The recurring pattern across the plants I have visited: Change Control that is tiered by risk — a fast lane for low-risk changes with full audit trail but light prior-approval, a formal lane for medium-risk changes with cross-functional sign-off, and a full validation lane for changes that touch validated processes or quality-critical elements — works. Change Control that treats every change the same way, whichever direction it is calibrated in, fails.

Change Control in an MES context — what actually needs it

The Change-Control-relevant configuration elements in an MES are narrower than the product backlog. Worth being explicit:

• Genuinely Change-Control-relevant: quality rules and acceptance limits, recipe definitions in regulated contexts, routing logic that affects traceability, KPI definitions used for cross-site reporting, workflow logic that enforces compliance gates, integration mappings to ERP and QMS.
• Lighter governance is usually appropriate: dashboard layouts, user-permission changes within established roles, shift-pattern configurations, alarm-threshold adjustments within operating ranges, label formats.
• Full software-release discipline applies to: the MES platform itself (vendor responsibility), customer-developed integrations, custom adapters, any code that executes against production data.

The typical mistake: treating the first and second categories the same. Either everything gets pharma-grade treatment — in which case the operational changes stop happening or go underground — or everything gets light-touch treatment and quality-relevant changes slip through. The working compromise is tiered, and the tier assignment is itself documented.

How this fits into the SYMESTIC platform

SYMESTIC provides the technical primitives that make Change Control enforceable rather than merely documented. Role-based access controls prevent unauthorised configuration changes at the permission level, rather than relying on policy alone. An audit trail records every configuration change — who, what, when, against which prior state — so the documentation step of the Change Control workflow cannot silently drift out of sync with the running system. KPI definitions and quality rules are versioned, so changes are visible as changes rather than as silent redefinitions. For regulated customers, the platform provides the electronic-records capabilities that underpin Part 11 and Annex 11 compliance obligations — audit trails, electronic signatures, controlled access — though compliance in full is a customer-side process discipline, not a vendor feature. Over 15,000 connected machines in 18 countries currently run on this foundation, including customers in pharma packaging (Klocke, referenced in the attached success stories) where Change Control is audited under GMP scope. Customer-facing entry points most relevant to this topic: production metrics, process data, alarms and production control.

FAQ

Do we need formal Change Control if we are not in a regulated industry?
Yes, for the quality-critical and cross-site-reporting-critical subset of changes. No, for the broad majority of day-to-day operational adjustments. The mistake most non-regulated plants make is not having Change Control at all for recipe-equivalents, KPI definitions and integration mappings — changes that appear operational but have quality or reporting consequences downstream. The opposite mistake, applying GMP-grade rigour across the board, is just as harmful in practice.

What triggers the FDA 21 CFR Part 11 and EU Annex 11 requirements in an MES?
Any use of the MES to create, modify, maintain or transmit electronic records that are submitted to regulators, or that are used in lieu of paper records required by GxP regulations. For most discrete-manufacturing MES deployments this is out of scope. For pharma packaging, medical-device manufacturing and GMP-regulated food operations it applies, and the platform's audit-trail, electronic-signature and access-control capabilities become compliance-relevant rather than just operationally useful.

How is Change Control different from Engineering Change Orders (ECR/ECN/ECO)?
ECO/ECN/ECR processes govern product and manufacturing-design changes (BOM, part design, routing, tooling) and are rooted in the automotive and aerospace traditions. Quality Change Control governs changes to quality-relevant process elements, recipes and documents, and is rooted in the pharma and regulated-food traditions. Both exist in many organisations simultaneously, governed by different roles, and the interface between them is where most alignment issues appear — a BOM change (ECO) may trigger a process-parameter change (Quality Change Control) and neither owner automatically knows about the other's workflow.

What about PLC programme changes — what governs those?
In regulated environments, PLC changes that affect validated processes fall under Quality Change Control. In non-regulated automotive and metal-processing environments they typically fall under engineering discipline without a formal Change Control framework — which is the largest silent-change category I see in practice. The working pattern is to treat significant PLC changes (not every tuning adjustment, but any programme-structure change, any interlock change, any migration) as Change-Control-worthy regardless of regulatory status. The cost is real; the alternative is accumulating a configuration drift that nobody can reconstruct. See also operational data acquisition and machine data acquisition for the connected signal-capture context.

Can Change Control slow down continuous improvement?
Badly-designed Change Control slows everything to a halt. Well-designed Change Control — tiered by risk, with fast-lane approval for low-risk changes and cross-functional formal review for high-risk changes — preserves improvement velocity while catching the changes that actually need to be caught. The design question is always "what tier is this change in, and what evidence does that tier require?" rather than "does this need Change Control?" Every change needs *some* level of Change Control; the tiering is where the art sits. See MES: definition, functions & benefits for the broader quality-governance context.

What is the single most common Change Control failure in MES projects?
Treating MES configuration changes as "just configuration" rather than as a change that needs its own workflow. A KPI definition change on the MES side can silently invalidate cross-plant comparisons and undermine the reporting layer the whole organisation relies on. A workflow-logic change can remove a compliance gate that was doing real work. The platform gives you the audit trail; the discipline of writing a change request before making the change, testing it in a non-production environment, and documenting the acceptance criteria — that is customer-side process, and it is frequently skipped in the first year of a deployment.

How should silent changes be caught if they by definition don't go through Change Control?
Three mechanisms work together: periodic configuration audits (comparing the running system state to the documented state, quarterly is a reasonable cadence), automated change detection at critical configuration points (the MES flags when a quality rule, KPI definition or workflow gate is modified, whether or not a ticket exists), and structured post-incident reviews that ask explicitly "what changed in the system state in the 30 days before this incident?" These mechanisms do not replace the formal Change Control workflow — they catch what escapes it.

Related: MES: Definition, functions & benefits · OEE: Definition, calculation & practice · MES software compared · OEE software · Cloud MES vs. on-premise · AI in manufacturing and MES · Production metrics module · Process data module · Alarms module · Production control module · Automotive · Metal processing · Food & beverage · Plastics processing · For COOs & plant managers · For operational excellence · For production managers · For maintenance managers.

About the author

Martin Brandel

MES Consultant at SYMESTIC. Over 30 years in industrial automation. Connecting machines to higher-level systems since 1991 — starting with Simatic S5, warehouse management and material-flow control; today with OPC UA, IoT gateways and Cloud MES. Career path: Ing. Büro Jürgen Albert (1991–1995, automation engineer), Hermos AG (1995–2000, large projects in Eastern Europe and China — conveyor systems, process technology, paint lines), ODEVIS / SYMESTIC (since 2000) — first eleven years as Head of Automation Engineering, including the software standard for process-engineering plants in the beverage and wood industries and retrofits from Simatic S5 to S7/TIA; then MES Consultant since 2019. Dipl.-Ing. Nachrichtentechnik. Expertise: machine data acquisition (MDE), operational data acquisition (BDE), machine connectivity, PLC programming (Simatic S5/S7/TIA), retrofit projects, OPC UA, IoT gateway integration, brownfield connectivity, process control systems, material-flow control, industrial automation, MES project management, CE conformity. · LinkedIn