Standardization in Manufacturing: 3 Planes

What is standardization in manufacturing?

Standardization in manufacturing is the systematic definition of a single, consistent way of doing something across a production environment — whether that something is a human work step, a data point, a machine interface, an API contract or a reporting structure. The textbook definitions focus on the visible layer: written SOPs, work instructions, inspection procedures. Those matter. But they sit on top of a much larger and mostly invisible layer that determines whether standardization actually scales beyond a single plant: the technical and data standards that let the process standards propagate, synchronise and remain comparable across lines, sites and countries.

I have spent the last decade building the technical substrate underneath one specific manufacturing platform. The SYMESTIC Cloud MES now runs more than 15,000 connected machines across 18 countries on four continents — from injection-moulding presses in automotive, to CNC centres in metal processing, to fully automated packaging lines in pharma. None of that scale is possible without standardization at the technical plane: ISA-95-aligned data models, protocol standards (OPC UA, MQTT), digital I/O taxonomies, REST API contracts, identity and access standards. When a multi-site rollout fails — and most of them do — it almost never fails because someone wrote a bad SOP. It fails because the technical standardization underneath was insufficient to let the process standardization survive contact with seven different plants. This article is about disentangling the three planes of standardization that actually matter, and about why the technical plane is the one most organisations underestimate.

The three planes of standardization

When manufacturers talk about "standardization," they usually mean one of three different things, and the conversations go sideways because nobody specifies which plane they are operating on. The three planes are independent, they interact, and each has to be addressed on its own terms.

The three planes are sequenced by how easy they are to see and how hard they are to fix. Process is visible — you can watch it happen. Organizational is semi-visible — it shows up in meetings and handovers. Technical is invisible most of the time, and it is the one that either makes the other two scale or prevents them from scaling. Manufacturers that invest heavily in process standardization without addressing the technical plane end up with well-written SOPs that cannot be propagated across plants, because every plant has a slightly different data model, a different taxonomy, a different integration pattern. The SOP is "the same"; the thing the SOP operates on is not.

Why technical standardization is the plane most organisations underestimate

Process standardization is popular because it is tangible. You can put an SOP in a binder, train operators against it, audit compliance, point to it in a quality review. Organizational standardization is visible in the org chart and in the meeting cadence. Technical standardization, by contrast, lives in schemas, protocols, data dictionaries and API contracts — invisible to everyone except the engineers who maintain them. This invisibility is exactly what makes it the highest-leverage plane and the one that quietly determines whether a multi-site programme succeeds or turns into five disconnected projects that happen to share a logo.

Three specific failure patterns show up again and again when the technical plane is under-invested. First, per-plant custom integrations. Each plant's MES implementation becomes a snowflake — a unique combination of PLC adapters, database schemas, ERP interfaces, custom field mappings. When the business wants to roll out a process change across all plants, the change has to be re-implemented per plant because the underlying integrations are not standardized. A six-week programme turns into six quarters. Second, incompatible data models. Plant A calls a machine stop "unplanned downtime"; Plant B calls the same event "operational stop"; Plant C splits it into three sub-categories. The written SOP is identical in all three plants. The KPI report is not, because the underlying data model is not. Third, protocol fragmentation. Modern lines connected via OPC UA, older lines via proprietary Siemens/Rockwell/Mitsubishi protocols, brownfield lines via whatever worked at the time of installation. Each integration layer has its own quirks, and none of them can be replaced without touching dozens of downstream systems.

The fix is not heroic engineering. The fix is committing to a small number of technical standards, applying them without exception, and refusing to accept local variants — even when the local team has a plausible reason for one. In my experience, the plausible reasons are almost always a local optimisation at the cost of a global one. The plant that gets its custom field mapping saves two weeks of setup. The programme that rolls out across 15 plants loses two years because those custom fields now have to be reconciled, plant by plant, every time anything changes.

Architectural observation from 15,000+ connected machines across 18 countries: the plants that scale fastest and stay consistent longest are the ones that accepted non-negotiable technical standards at day one and applied them even when they were inconvenient. Standard ISA-95-aligned data model, single stop-reason taxonomy, OPC UA for modern controls, MQTT for IoT-gateway-connected assets, digital I/O for genuine brownfield — no plant-specific variants at the data-model layer, ever. Plants that accepted this have rollout speeds measured in days per machine. Plants that insisted on local variants have rollout speeds measured in months per plant, and reconciliation burdens that persist for years after the last integration is "done." The discipline at the technical plane is what makes the process plane and the organizational plane possible at scale.

The technical-standardization stack that actually works

When I describe the technical plane, I am not waving at an abstraction. There is a concrete stack that works, and there is a set of discipline rules that keep it working. The stack has six layers, each with a standard, and the whole thing is wasted if any one layer is allowed to fragment.

The discipline rule that sits on top of this stack is simple to state and hard to enforce: no local variants at the data-model layer, ever. User-interface layer adaptations — language, units, local labels, regional reporting formats — are fine and expected. Data-model adaptations — new fields, renamed entities, modified taxonomies, split categories — are not. The moment a plant is allowed one exception at the data-model layer, two things happen: that plant cannot be compared to the others on any KPI that touches the affected entity, and every subsequent plant will ask for its own exception citing the precedent. I have seen organisations lose two years of rollout velocity to a single well-meaning exception in year one.

How the three planes reinforce each other

The planes are separable for analysis and inseparable in practice. Process standardization without the technical plane produces SOPs that cannot be measured consistently across plants. Technical standardization without the process plane produces beautifully consistent data about inconsistent behaviour. Organizational standardization without the other two produces meetings where everyone reports "on standard" because each team is comparing itself to its own definition.

The productive sequence, learned from dozens of rollouts, is technical first, process second, organizational third. Technical first because it is the substrate — everything else rides on it, and fixing it retroactively is an order of magnitude harder than getting it right at the start. Process second because once the technical plane is stable, process standards can be propagated, measured and enforced with data. Organizational third because the cadence and accountability structures land naturally once everyone is looking at the same numbers from the same model. Organisations that do this in reverse — writing org charts and SOPs before the data layer is standardized — spend the next two years retrofitting the data layer under a process that has already shipped, usually at three times the cost of having built it right the first time.

A real case: Carcoustics

Carcoustics International is an international automotive supplier for acoustic and thermal solutions, with production sites in Germany, Poland, Slovakia, Czech Republic, Mexico, the US and China. The technology mix is what makes it interesting for a standardization discussion — injection moulding, cold foaming, stamping, each with its own cycle characteristics, alarm profiles and data conventions. The engagement with SYMESTIC started as a proof of concept at the Haldensleben site and scaled, within six months, to more than 500 machines across all plants. The speed is the point; it is only possible when the three planes of standardization are addressed in the right order.

The technical plane was the first thing we nailed down. OT integration runs through IXON IoT devices using the MQTT protocol into Microsoft Azure — one pattern, applied identically in Haldensleben, in Poland, in Mexico, in China. The same ISA-95-aligned data model across every plant, the same stop-reason taxonomy, the same event schemas. Bidirectional SAP R3 integration via ABAP IDoc — not a per-plant middleware, a single integration contract replicated plant by plant without variation. Machine cycles map back to SAP production orders; confirmations flow back to the ERP in real time. None of the plants has a "Carcoustics Poland version" of the data model. There is one data model; every plant lives inside it.

Once the technical plane was stable, the process plane followed. Setup-support workflows digitised across all plants using the same pattern, same HMI, same checklist structure. Performance KPIs rolled up group-wide because the underlying taxonomy and data model made group-wide aggregation arithmetically valid in the first place. The organizational plane — the KPI cadence, the cross-plant benchmarking conversations, the ability of central operations to compare Mexico to China to Poland on apples-to-apples metrics — fell into place almost automatically, because the two layers underneath it made those conversations possible. And once the pattern was established, the modular SYMESTIC catalogue let Carcoustics scale further on its own, without returning to the vendor for every incremental machine. That is the self-service pattern that distinguishes a standardized technical substrate from a vendor-dependent project: the customer becomes capable of extending their own platform, because the substrate is consistent enough that extension is mechanical rather than creative.

The right-hand column is the thesis of this article in operational form. None of these improvements were caused by a single heroic intervention. They were caused by the discipline of standardizing the technical plane once, correctly, and letting the process and organizational planes inherit the consistency. A plant-by-plant custom-integration approach would have produced the same headline numbers on one or two sites and nothing at scale. The standardization at the technical plane is what made the 500-machine, seven-country rollout arithmetic rather than heroic.

FAQ

What is the difference between process standardization and standardization in manufacturing?
Process standardization is a subset of standardization in manufacturing. Standardization as a whole covers three planes: process (what humans and machines do), technical (how systems, data and machines interoperate) and organizational (how teams coordinate, decide and escalate). Process standardization — SOPs, work instructions, setup sheets — is the most visible plane but rarely the highest-leverage one. The technical plane is the substrate that determines whether process standards can scale across plants at all.

Why is technical standardization so important for multi-plant rollouts?
Because process and organizational standardization ride on top of the technical plane. Without a single data model, a single stop-reason taxonomy, a consistent integration pattern and a common identity system, cross-plant KPI comparison is arithmetically impossible, process changes have to be re-implemented per plant, and organizational benchmarking becomes guesswork. In my experience, the multi-plant programmes that succeed are those that treat technical standardization as a non-negotiable day-one investment. The ones that defer it end up paying for it two to three times as the rollout progresses.

What is ISA-95 and why does it matter for standardization?
ISA-95 is the international standard that defines the information model for integrating enterprise and control systems in manufacturing. It specifies hierarchical entities — equipment, materials, personnel, production orders — and their relationships. For standardization purposes, ISA-95 gives every plant the same vocabulary. A "work unit" means the same thing in Germany, Mexico and China; a "production order" is defined identically; an "equipment hierarchy" has the same structure everywhere. Without ISA-95 or an equivalent information model, every plant invents its own entities and cross-plant aggregation becomes impossible.

Can you standardize across plants with different machine generations?
Yes, and in almost every real rollout this is the situation. The technique is to standardize at the information and event layer, not at the physical connectivity layer. Modern machines connect via OPC UA; IoT-gateway-connected assets via MQTT; genuine brownfield machines via digital I/O gateways. Three different physical protocols, one unified event model on top. The operator dashboard, the KPI rollup and the cross-plant comparison see identical events regardless of how the machine actually talks to the system. Protocol fragmentation underneath is acceptable; event-model fragmentation on top is not.

What are the most common mistakes in manufacturing standardization programmes?
Five patterns dominate. Starting with process standardization before the technical plane is stable — everything ends up retrofitted later, expensively. Allowing per-plant exceptions at the data-model layer — each one creates a reconciliation burden that persists for years. Treating standardization as a document exercise rather than a system property — the written standard is compliance theatre if the underlying systems cannot enforce it. Underestimating organizational inertia — the hardest variants to eliminate are not technical but cultural, and they require explicit management sponsorship. And declaring victory too early — standardization is not a project that ends, it is an architectural property that has to be defended continuously against well-meaning local exceptions.

How long does it take to standardize a multi-plant manufacturing organisation?
The technical plane, if approached correctly, can be stable within 6-9 months for a 5-10 plant organisation — that is roughly what the Carcoustics rollout achieved, 500+ machines across seven countries in six months. The process plane requires another 6-12 months of disciplined execution on top of the technical substrate. The organizational plane is continuous — the KPI cadence, the cross-plant benchmarking rhythm, the accountability structures never fully stop evolving. Organisations that try to do all three simultaneously usually fail on all three. Organisations that sequence technical → process → organizational, in that order, get durable results measured in years of compounding improvement.

Does standardization reduce flexibility?
The opposite, when it is done at the right plane. Standardization at the user-interface layer would reduce flexibility — operators lose local adaptations that matter for their specific conditions. Standardization at the data-model and integration layer increases flexibility, because process changes, product introductions and capacity shifts become propagatable across plants instead of requiring custom work per site. The common confusion is to conflate standardization with rigidity. The productive pattern is rigid at the substrate, flexible at the surface. The rigid substrate is exactly what makes the flexible surface affordable to maintain.

How does SYMESTIC implement standardization across the three planes?
At the technical plane: single ISA-95-aligned data model across every tenant, OPC UA for modern controls, MQTT for IoT-gateway-connected assets, digital I/O gateways for brownfield without any digital interface, REST APIs and SAP IDoc for ERP integration — no per-plant custom middleware. At the process plane: digital work instructions at the HMI tied to the active order, enforced checklists, parameter sets pushed from the MES to the control system at changeover, standardized stop-reason taxonomy with no local variants. At the organizational plane: cross-plant KPI rollups with cycle-level drill-down, group-wide benchmarking that is arithmetically valid because the underlying data model is identical, role-based access control via Azure AD. 15,000+ machines connected across 18 countries on this architecture. See SYMESTIC Production Metrics.

Related: Process Standardization · Manufacturing Processes · Performance Measurement · OEE · ISA-95 · OPC UA · MES · SYMESTIC Production Metrics

About the author

Mark Kobbert

CTO of SYMESTIC GmbH. Responsible for the Cloud MES architecture since 2014 — from the Microsoft Azure microservice platform and IoT gateway connectivity to real-time data processing for 15,000+ machines across 18 countries. B.Sc. Business Informatics, SRH Heidelberg. Led the platform's cloud-native rebuild: instead of lifting on-premise software to the cloud, built the architecture from scratch around scalability, real-time capability and maintainability. · LinkedIn