Every MES integration project eventually hits the same wall. Someone pulls up the ISA-95 pyramid, points at the line between Level 3 and Level 4, and says “that’s not our job, that’s ERP.” Someone else disagrees. Weeks later, you discover that advanced scheduling logic is split between two systems that don’t agree on what “the plan” even is, and nobody can explain why quality disposition data lives in three places at once.
This isn’t a new problem, but it’s gotten sharper. ISA-95 was written when Level 3 and Level 4 meant different buildings, different databases, and often different companies running them. In 2026, SAP Digital Manufacturing Cloud, Rockwell’s Plex, and Siemens Opcenter are all selling cloud-hosted platforms that explicitly claim to unify scheduling, quality, and business planning in one environment. The vendors aren’t wrong that the technology has changed. But the standard’s underlying logic — which hasn’t changed at all — is what teams keep getting wrong.
What ISA-95 actually separates (and it isn’t hardware)
ISA-95 divides manufacturing activity into functional levels, not physical tiers. Level 4 is business planning and logistics: what to make, how much, by when, and at what cost, driven by orders, forecasts, and financial constraints. Level 3 is manufacturing operations management: how to actually execute that plan on the floor, in real time, against real equipment and real people, right now.
The boundary was never really about where the server sat. It was about time horizon, granularity, and the consequence of being wrong. A Level 4 system deciding to move a work order from Tuesday to Thursday is a planning adjustment. A Level 3 system deciding which of six identical machines runs the next job, in what sequence, accounting for a tool change and an operator going on break, is an operational decision with a much shorter fuse and much higher granularity.
That distinction survives the move to the cloud. What doesn’t survive is the assumption that Level 3 and Level 4 are separate products from separate vendors running on separate infrastructure. When SAP DMC or Plex host scheduling, quality, and ERP-adjacent planning inside one tenant, the architectural line disappears even though the functional line still needs to exist somewhere in your process design.
The mistake teams keep making
The common failure mode isn’t “we don’t understand ISA-95.” It’s “we mapped functions to systems instead of mapping functions to responsibilities.” Teams see a single cloud suite that offers both a scheduling module and an ERP planning module, assume the vendor has already resolved the Level 3/4 split for them, and skip the conversation about who owns what decision. Then they discover, mid-implementation, that the “advanced scheduling” feature in their ERP-adjacent tool is actually finite-capacity planning at the plan level, not dispatch-level sequencing — and the shop floor still needs something else entirely to sequence jobs against actual machine and labor availability in the next four hours.
The fix isn’t a better diagram. It’s a function-by-function placement exercise, done before you sign a statement of work, not during UAT.
A placement checklist that actually works in 2026
For each capability under discussion, ask three questions: What’s the decision horizon? What’s the required data granularity? And what happens if this decision is wrong for ten minutes versus wrong for a week? The answers tell you which layer owns it, regardless of which product’s login screen it lives behind.
Scheduling: split it, don’t pick a side
“Scheduling” is really two different jobs wearing one name, and this is the single biggest source of confusion in cloud suite rollouts. Master production scheduling — allocating capacity across a planning horizon of days to months, balancing demand against material and labor constraints — is Level 4 work. It answers “what should we build and roughly when.” Detailed sequencing and dispatching — deciding the exact order jobs run on a specific line in the next shift, accounting for changeovers, tooling, and real-time machine status — is Level 3 work. It answers “what runs next, right now.”
Cloud ERP vendors increasingly bundle both under a single “scheduling” umbrella, and their sales materials don’t always draw the line clearly. Your job is to ask, explicitly, which horizon and which granularity a given scheduling feature actually operates at, and to make sure something — not necessarily two separate products, but at least two clearly defined functions — still handles both jobs.
Dispatching stays close to the equipment
Dispatching — releasing the next work instruction to an operator or machine — belongs at Level 3 almost without exception, cloud architecture or not. It depends on real-time equipment state, operator availability, and material staging that Level 4 systems simply don’t have visibility into at the necessary refresh rate. If your cloud ERP suite offers to “dispatch” work orders directly to the floor without a Level 3 execution layer mediating that handoff, treat that as a scoping question, not a feature to accept at face value: what happens when a machine goes down between the dispatch decision and the operator scanning in?
Genealogy and traceability live where the event happens
Material genealogy — what lot went into what batch, on what equipment, under whose supervision — has to be captured at Level 3, because that’s where the physical event occurs and where the data has the granularity (timestamps, equipment IDs, operator IDs) to be forensically useful later. Level 4 systems consume rolled-up genealogy for compliance reporting and recall scope, but they should not be the system of record for the underlying event data. Cloud suites that promise “unified genealogy” are usually describing a reporting layer built on top of Level 3-originated data, not a replacement for capturing it there.
Quality disposition depends on the decision, not the department
This is the subtlest one. In-process quality checks and hold/release decisions tied to a specific unit, batch, or lot in production are Level 3 — they need to happen fast, close to the line, without waiting on a business-system round trip. But quality decisions with business consequence — supplier disposition, cost-of-quality reporting, CAPA tracking tied to financial or contractual outcomes — belong at Level 4. The mistake is putting all quality in one bucket because one vendor’s “quality management” module happens to touch both. Ask specifically: does this disposition decision need to happen in seconds against a physical unit on the line, or can it tolerate a slower, business-context-aware review? That answer tells you the layer.
What to do with this on your next project
Stop asking “is this Level 3 or Level 4” as a question about which product owns a screen. Ask it as a question about decision horizon, data granularity, and consequence of latency, for each function separately — scheduling, dispatching, genealogy, quality, and anything else on your integration scope list. Write the answers down before you finalize your architecture, not after you discover a gap in production. Cloud-native unified suites genuinely can host both layers well, and there are real efficiency gains in reducing the number of integration points between them. But collapsing the physical separation between systems was never the point of ISA-95. Preserving the functional separation between decisions is — and that job hasn’t gotten any easier just because it’s all in one tenant now.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
