Ask a room full of MES practitioners to draw the ISA-95 hierarchy and every hand goes up. Level 0 is the process, Level 1 is sensing and manipulation, Level 2 is supervisory control, Level 3 is MES, Level 4 is ERP. Everyone’s seen the pyramid. Fewer people could tell you what’s actually inside Part 3, which defines the Level 3 functions. And a genuinely small slice of the field has ever opened Part 4 or Part 5 — the parts of the standard that define what an integration message actually looks like when it crosses from MES to ERP or from one MES module to another.
That’s not a trivia gap. It’s the specific skill gap behind a lot of integrations that take far longer than they should, get re-architected mid-project, or quietly turn into a pile of custom field mappings that nobody outside the original integrator can maintain. The hierarchy tells you where systems sit relative to each other. Part 4 and Part 5 tell you what to actually send between them. Those are different problems, and most teams have only solved the first one.
What Parts 4 and 5 actually define
ISA-95 (formally ANSI/ISA-95, aligned with IEC 62264) is published in multiple parts. Part 1 defines models and terminology — the hierarchy everyone knows, plus the four core information categories: personnel, equipment, material, and process segment. Part 2 defines the object model attributes for those categories in more formal detail. Part 3 covers the activity models for manufacturing operations management — the functions MES is supposed to perform.
Part 4 is where the standard gets concrete about data exchange. It defines object models for the transactions that move between MES and other enterprise systems: production schedules, production performance, material and equipment definitions, personnel information, process segment definitions. Part 5 builds on that by defining the actual business-to-manufacturing transactions — the message types, like a production schedule request or a production performance response, that carry those objects between systems in a defined sequence.
B2MML — Business To Manufacturing Markup Language — is the XML implementation of these Part 4/5 models, maintained and published as open-source schema by the MESA International community. It’s not a separate standard; it’s the schema that lets you actually instantiate ISA-95’s abstract object models as real XML documents you can validate, transform, and send over a message bus. If Part 4 tells you a “material definition” object needs a material class, a material lot, an assembled property set, and a set of unit-of-measure conversions, B2MML gives you the actual XML elements and structure to carry that information.
Why almost nobody opens it
The honest answer is that Part 4/5 and B2MML are dense, genuinely awkward to read cold, and rarely taught in any structured way. Most practitioners learn ISA-95 from a slide deck at a conference or a vendor’s marketing one-pager, both of which stop at the pyramid because the pyramid is what’s visually teachable. The transaction models live in PDF specifications and XSD schema files that look like plumbing, not architecture, and plumbing doesn’t get its own keynote.
There’s also a structural incentive problem. Integrators are usually scoped and paid to build a specific interface between System A and System B, not to implement a standard. Under time pressure, it’s faster to open both systems’ native APIs, eyeball the fields, and write a point-to-point mapping than it is to first map both systems onto the ISA-95 equipment, material, personnel, and process segment models and then derive the transaction from that. The point-to-point approach ships faster on the first integration. It just doesn’t transfer to the second, third, or tenth integration, which is exactly the situation composable MES architectures are creating in 2026 — more systems, more integrations, more of this same rework happening independently at every plant that adopts a mid-market platform.
What the object models actually give you
The four core Part 4 object categories map cleanly onto questions every MES-to-ERP integration has to answer anyway:
- Equipment: what physical or logical assets exist, how they’re organized into equipment classes and hierarchies, and what properties describe them — this is what makes a work center in ERP resolve sensibly to a line, cell, or unit in MES.
- Material: material definitions, classes, lots, and sublots, plus the property sets that distinguish one lot from another — this is the backbone of genealogy and any integration touching inventory or quality.
- Personnel: qualifications, roles, and person-to-resource assignments — less glamorous, but essential wherever labor tracking, certifications, or shift assignment cross the MES/ERP boundary.
- Process segment: the reusable building blocks of a process — parameters, equipment, material, and personnel requirements bundled together — that let a production schedule or a production performance record actually describe what happened without re-inventing a data model per product line.
A B2MML production schedule document, for instance, is built from these objects: it references material definitions, equipment requirements, personnel requirements, and process segments, all nested under a schedule that ERP can generate and MES can consume without either side needing custom code to interpret what a “segment” or a “lot” means. That’s the whole point — the semantics are already agreed on, so the integration work becomes mapping your systems’ native fields onto an existing model rather than negotiating a brand-new one from a blank whiteboard.
A practical checklist for scoping with Part 4/5 instead of around it
Before an integration statement of work goes out for bid, or before your own team starts writing field mappings, work through this:
- Identify which B2MML transaction schemas actually cover your use case. Production schedule, production performance, material/equipment/personnel definitions, and process segment are the core set — most MES-to-ERP exchanges fit into one or a combination of these.
- Map your source and target systems’ native objects onto the ISA-95 Part 4 categories first, before touching field-level mapping. Which system owns the equipment hierarchy? Which owns material lot genealogy? Disagreements here are where integrations quietly go sideways later.
- Check for gaps, not just fits. Real systems don’t map onto the standard object models perfectly. Document where your data model needs an extension, and use B2MML’s extension mechanisms rather than a parallel undocumented field.
- Write the SOW against transaction types, not tickets. “Implement the B2MML production performance transaction between MES and ERP, including these process segment extensions” is a scopeable, testable deliverable. “Sync production data” is not.
- Ask any integrator bidding on the work whether they’ve implemented Part 4/5 transactions before, not just whether they know the ISA-95 hierarchy. Those are genuinely different skills, and the hierarchy answer is the one people rehearse.
The pyramid was never meant to be the whole standard — it’s the orientation slide, not the specification. The actual engineering content, the part that would save your team from reinventing a schema every single system boundary you cross, has been sitting in Parts 4 and 5 the entire time. Composable MES is going to keep multiplying the number of integration boundaries any given plant has to manage. The teams that treat Part 4/5 and B2MML as literacy — something a controls engineer or MES admin can actually read and apply — are going to scope those integrations in weeks instead of quarters. The teams that don’t will keep discovering the same transaction model, badly, one custom field mapping at a time.
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.
