Bill of Process in PLM: Manufacturing Process Planning, Routings, Work Instructions and the MBOM-to-MES Handoff

Most factories that “have an MBOM in PLM” still build product from a routing someone typed into ERP, a PowerPoint work instruction on a shared drive, and a station setup that lives in a supervisor’s head. The manufacturing bill of materials says what goes into the product. Nothing authoritative says how, where, with what and in what order. That gap is where the bill of process belongs, and it is where most engineering-to-production defects are born.

It matters now for two reasons. In March 2026 the IEC published the third edition of IEC 62264-2, the ISA-95 object model for Level 3 to Level 4 exchange, and restructured how operations definitions are modelled. At the same time, PLM vendors are pushing electronic work instructions and MES connectors as standard product, not services projects.

You will leave with a reference architecture, a data model you can implement, a worked example on a small assembly, a validation script, and the failure modes to plan for.

What this covers: BOP vs MBOM, operations and steps, resource and plant BOPs, consumed-part assignment, time standards, digital work instructions with 3D, ECO propagation, ISA-95 and B2MML mapping, and PLM to MES integration patterns.

Context and Background

Manufacturing process planning predates PLM by decades. Industrial engineers wrote route sheets and operation sheets on paper, often with computer-aided process planning (CAPP) tools in the 1980s and 1990s. ERP systems then absorbed the routing: a sequence of operations, each tied to a work center, with setup and run times used for costing and capacity planning. That ERP routing became the de facto process definition, even though it carries almost none of the information an operator needs.

The major PLM suites now each ship a manufacturing process management (MPM) layer that owns the richer model. Siemens describes the bill of process as the object that “details the planned production approach for a specific product,” built from processes and operations, with tools and equipment drawn from a bill of equipment and parts assigned from the MBOM, according to its bill of process overview. Siemens also documents generating plant-specific BOPs from a product BOP. PTC’s Windchill MPMLink splits the work across three browsers: the BOM Transformer for the EBOM-to-MBOM relationship, the Manufacturing Resource Browser for plants and resources, and the Process Plan Browser for process plans, per the PTC MPMLink help. Dassault Systèmes DELMIA on 3DEXPERIENCE models manufactured items, systems and operations, and lets planners balance operations across systems against a cycle time.

The vocabulary differs, but the underlying shape is the same. There is a product view (the MBOM), a process view (the bill of process), a plant or resource view, and links that say which operation consumes which part on which resource. If your MBOM work is still in progress, start with our guide to EBOM to MBOM transformation, because a BOP cannot be better than the MBOM it consumes.

On the execution side, ISA-95, published internationally as IEC 62264, is the reference model for exchanging operations data between business systems and manufacturing operations. MESA International maintains B2MML, the XML (and since version 7, also JSON) implementation of those object models. MESA’s release of B2MML version 7 in November 2020 targeted the 2018/19 versions of ISA-95 and IEC 62264, per the MESA announcement.

My thesis is simple and, I think, under-argued: the bill of process is a compiled artifact, not a shared database. The MBOM-to-MES handoff should look like a software release, with a build step, validation gates, an immutable versioned package and a deployment record per plant. Teams that instead “sync” live PLM objects into MES inherit every half-finished edit and every effectivity ambiguity directly onto the shop floor.

Bill of Process Reference Architecture: From MBOM to an Executable Process Package

Direct answer: A bill of process is the PLM structure that defines how a product is made: an ordered set of operations and steps, each consuming specific MBOM parts, executed on specific plant resources, governed by time standards, quality characteristics and work instructions. It is authored in PLM, specialised per plant, then compiled and released to ERP for costing and to MES for execution.

Figure 1: Bill of process reference architecture. Engineering structures feed the MBOM, the product BOP consumes it, plant BOPs bind it to real resources, and a compile-and-validate stage publishes a versioned process package to ERP and MES.

The diagram reads left to right as a chain of custody. The EBOM is the design intent. The MBOM restructures it for build, adding phantoms, kits, consumables and make-versus-buy decisions. The product BOP sequences operations generically against resource types. Each plant BOP binds those operations to concrete stations, tools and labour skills. A compile stage resolves effectivity, checks consumption completeness and packages the result. ERP receives a slimmed routing for costing and capacity; MES receives the full executable definition, including work instructions and data-collection plans.

BOP vs MBOM: Two Structures, One Contract

The BOP vs MBOM question confuses many teams because both are “manufacturing structures.” The difference is in what each node means. An MBOM node is a thing: a part, an assembly or a kit, with a quantity. A BOP node is an activity: a process, an operation or a step, with a duration, a resource and a sequence. The MBOM answers “what is in the box.” The bill of process answers “what do we do, in what order, to fill the box.”

The two structures are joined by consumption links. Each MBOM line item is assigned to the operation that installs it. Siemens describes an automatic “logical part assignment” capability for this; PTC describes parts “allocated from the BOM or as operated-on parts.” Whatever the tool calls it, the invariant is the same, and it is the single most valuable check in the whole architecture: every MBOM line, at every effectivity, must be consumed exactly once by the BOP, and the quantities must add up.

Why keep them separate rather than embedding operations into the MBOM? Because they change for different reasons. A supplier change alters the MBOM but not the process. A line rebalancing changes the bill of process but not the MBOM. Merging them forces both kinds of change through one revision stream, and that couples engineering and industrial engineering change cadence for no gain.

Product BOP and Plant BOP

A product BOP is plant-agnostic. It says “press bearing into housing, using a press of at least 5 kN, then verify seating depth.” It references resource types and capability requirements. A plant BOP specialises that to a site: “Station A2-03, Press P-117, fixture FX-221, operator skill PRESS-L2.” Siemens explicitly documents generating plant-specific bills of process from the product bill of process, and Windchill handles plant-specific process plan data through its Plants tab.

This split matters for global manufacturers. Without a product BOP, each plant re-authors the process, and best practices diverge within a year. Without plant BOPs, the single “global” process cannot reflect real station layouts, so plants maintain their own shadow routings in MES, and PLM becomes a museum. The product-plant split gives you a governed baseline plus controlled local variance, and it makes variance visible: you can diff a plant BOP against its product BOP and see exactly where a site deviates.

Routing vs Operation vs Step

Terminology drift between ERP, PLM and MES causes integration bugs, so it is worth pinning down. In this post I use the following definitions, which align with common practice rather than any one vendor:

Routing is the ERP view of the process: an ordered list of operations, each mapped to a work center, carrying setup time, run time and sometimes queue and move time. It exists for costing, scheduling and capacity.
Operation is a unit of work performed at one resource or station, typically owned by one operator or cell, and reportable as complete. Operations carry consumed parts, tools, standard times and quality characteristics. Operations are the level at which ERP and MES share identifiers.
Step (sometimes “work element” or “task”) is a sub-unit inside an operation: “torque four M4 screws in a cross pattern to 2.2 N·m.” Steps carry the work instructions, data-collection points and visual aids. ERP usually never sees them; MES must.

The design rule that follows: operation identifiers are the integration key across all three systems; step identifiers are the integration key between PLM and MES only. If ERP routings and BOP operations do not share a stable operation number, cost roll-ups and confirmations drift apart silently.

Resources, the Bill of Equipment and the Plant Model

The resource side of the bill of process is often called the bill of equipment (BOE) or the plant BOP. It models the plant hierarchy, typically following ISA-95’s equipment hierarchy of enterprise, site, area, work center and work unit, plus tools, fixtures, gauges and skills. Siemens’s manufacturing process planning page refers to drawing tools and resources from the BOE and managing them in a manufacturing resource library. PTC handles this with the Manufacturing Resource Browser.

Treat resources as first-class, versioned objects with capabilities, not as free-text station names. “Press, force at least 5 kN, stroke at least 40 mm” is a capability; “P-117” is an instance that satisfies it. When the product BOP expresses capability requirements and the plant model expresses capabilities, the plant-BOP binding becomes checkable instead of a matter of trust.

Walk-through: Data Model, Worked Example and the Compile Step

The architecture is only useful if the data model underneath it is tight. This section sketches a vendor-neutral model, applies it to a small assembly, and shows the validation gate that turns a bill of process into something MES can trust.

Figure 2: A vendor-neutral bill of process data model. Operations sit under a process, own ordered steps, consume MBOM lines, require resource capabilities, and carry time standards, work instructions and inspection characteristics.

Figure 2 shows the minimum set of entities. A process groups operations for one manufactured item and one plant context. Each operation consumes MBOM occurrences, requires one or more resource capabilities, carries a standard time and links to a work instruction. Steps live inside operations and carry the data-collection points. Quality characteristics hang off steps, so a torque value or a seating depth is captured exactly where the work happens.

The Entity Model in JSON

Here is a compact JSON sketch of one operation. It is not a vendor schema; it is the shape your integration layer should normalise into regardless of whether the source is Teamcenter, Windchill or DELMIA.

{
  "process": {"id": "PRC-GM24-A", "item": "GM24-ASSY", "rev": "C", "plant": "PUNE-01",
              "effectivity": {"type": "unit", "from": 1200, "to": null}},
  "operation": {
    "id": "0040", "name": "Fit cover and fasten", "seq": 40,
    "predecessors": ["0030"],
    "workCenter": "WC-ASSY-2", "station": "A2-04",
    "requires": [{"capability": "SCREWDRIVER_DC", "params": {"torque_Nm": [0.5, 5.0]}}],
    "consumes": [{"mbomOcc": "MO-118", "part": "CVR-100", "qty": 1},
                 {"mbomOcc": "MO-121", "part": "SCR-M4X10", "qty": 4}],
    "time": {"setup_min": 0, "run_min": 1.1, "basis": "MTM-derived, illustrative"},
    "steps": [
      {"id": "0040-10", "text": "Place cover CVR-100 on housing, align locating pins",
       "visual": "3D view ref VW-0040-10"},
      {"id": "0040-20", "text": "Torque 4 x M4 in cross pattern",
       "collect": [{"char": "TQ-M4", "nominal": 2.2, "lsl": 2.0, "usl": 2.4, "uom": "N.m",
                    "source": "tool"}]}
    ],
    "workInstruction": {"id": "WI-GM24-0040", "rev": "B"}
  }
}

Three design choices in that sketch are deliberate. Consumption references the MBOM occurrence (MO-121), not just the part number, because the same part can appear in two places with different quantities and you need to know which occurrence each operation satisfies. Time carries a basis field so nobody mistakes an estimate for a validated standard. And the data-collection point names its source as the tool, which tells MES to pull the value from a connected controller rather than ask the operator to type it.

Worked Example: A Small Gear-Motor Assembly

Take a 24 V gear-motor with nine MBOM lines: housing, motor, gear set, output shaft, two 608 bearings, one shaft seal, a cover, four M4 screws and an ID label. The product BOP has six operations. The numbers below are illustrative, chosen to show the mechanics rather than to represent any real product.

Op	Name	Resource capability	Consumes	Std time (min, illustrative)
0010	Press bearings into housing	Press, ≥5 kN	HSG-100 ×1, BRG-608 ×2	0.9
0020	Install shaft and gear set	Assembly bench	SHAFT-08 ×1, GEAR-SET ×1	1.4
0030	Mount motor and seal	Assembly bench	MTR-24V ×1, SEAL-12 ×1	1.6
0040	Fit cover and fasten	DC screwdriver	CVR-100 ×1, SCR-M4X10 ×4	1.1
0050	End-of-line test	Motor tester	none	1.8
0060	Label and pack	Pack station	LBL-ID ×1	0.6

The total standard time is 7.4 minutes. If the target takt time is 2.5 minutes (again illustrative, for example 7.5 available hours divided by 180 units), the theoretical minimum number of stations is ceil(7.4 / 2.5) = 3. In practice you cannot reach three, because operations are indivisible and must stay in precedence order. Grouping them sequentially without exceeding takt gives {0010, 0020} at 2.3, {0030} at 1.6, {0040} at 1.1 and {0050, 0060} at 2.4: four stations. That is exactly the product-to-plant specialisation step. The product BOP has six operations; the plant BOP binds them to four stations.

Notice what the balance exposes. Line efficiency is 7.4 / (4 × 2.5) = 74 percent, and station 3 sits idle for more than half of every cycle. The fix is to split operations, not to buy equipment: if the seal installation moves out of 0030 into its own operation that can run at station 3, or the cover pre-placement step moves upstream, three-and-a-bit stations of work can be packed more evenly. Every one of those moves is a BOP change, not an MBOM change, which is why the two structures should revise independently.

Time Standards: Where the Numbers Come From

Run times in a bill of process come from one of four sources: predetermined motion time systems such as MTM (Methods-Time Measurement) and MOST (Maynard Operation Sequence Technique), direct time study with a stopwatch or video, historical MES actuals, or engineering estimates. MTM expresses time in time measurement units, where one TMU equals 0.00001 hours, or 0.036 seconds. The details of each system’s tables are licensed and beyond the scope of this post; what matters architecturally is provenance.

Store the basis and the date of each standard with the operation. ERP costing will use the number regardless, and a guess entered during new product introduction can survive for years as the official labour standard. A basis attribute, plus a periodic job that compares standards against MES actual cycle times, turns that silent drift into a visible exception list. The comparison is the same data you would use to compute performance loss in an OEE data model built on MES and IIoT, so the integration pays for itself twice.

The Compile and Validate Gate

This is the step most implementations skip. Before a plant BOP is released to MES, a compiler resolves it for a specific effectivity and runs structural checks. The minimal checks are consumption completeness, quantity balance, orphan detection, precedence acyclicity, resource binding, and work-instruction release state. Here is the core of the first three as runnable Python:

from collections import defaultdict

mbom = {  # part number -> quantity per gear-motor unit
    "HSG-100": 1, "MTR-24V": 1, "GEAR-SET": 1, "SHAFT-08": 1,
    "BRG-608": 2, "SEAL-12": 1, "CVR-100": 1, "SCR-M4X10": 4, "LBL-ID": 1,
}

bop = [  # operation, resource, consumed {part: qty}, std minutes
    {"op": "0010", "res": "PRESS", "consumes": {"HSG-100": 1, "BRG-608": 2}, "std_min": 0.9},
    {"op": "0020", "res": "BENCH", "consumes": {"SHAFT-08": 1, "GEAR-SET": 1}, "std_min": 1.4},
    {"op": "0030", "res": "BENCH", "consumes": {"MTR-24V": 1, "SEAL-12": 1}, "std_min": 1.6},
    {"op": "0040", "res": "SCREW", "consumes": {"CVR-100": 1, "SCR-M4X10": 3}, "std_min": 1.1},
    {"op": "0050", "res": "TEST",  "consumes": {}, "std_min": 1.8},
    {"op": "0060", "res": "PACK",  "consumes": {"LBL-ID": 1, "TAPE-50": 1}, "std_min": 0.6},
]

def check(mbom, bop):
    consumed = defaultdict(float)
    for op in bop:
        for pn, q in op["consumes"].items():
            consumed[pn] += q
    errors = []
    for pn, q in mbom.items():
        if consumed[pn] == 0:
            errors.append(f"UNCONSUMED {pn}: MBOM qty {q}, BOP qty 0")
        elif consumed[pn] != q:
            errors.append(f"QTY MISMATCH {pn}: MBOM {q}, BOP {consumed[pn]:g}")
    for pn in consumed:
        if pn not in mbom:
            errors.append(f"ORPHAN {pn}: consumed in BOP but not in MBOM")
    return errors

for e in check(mbom, bop):
    print(e)
print("total standard minutes:", round(sum(o["std_min"] for o in bop), 2))

Running it on this deliberately broken plan prints:

QTY MISMATCH SCR-M4X10: MBOM 4, BOP 3
ORPHAN TAPE-50: consumed in BOP but not in MBOM
total standard minutes: 7.4

Both defects are realistic. A planner copied operation 0040 from an older three-screw cover variant, and someone added packing tape at the pack station without adding it to the MBOM. Without the gate, MES would issue a material kit with four screws and backflush three, leaving an inventory variance that finance discovers weeks later. The tape would be consumed physically but never costed. In production, run the same check per effectivity point, against MBOM occurrences rather than part numbers, and fail the release on any error.

The other checks are equally mechanical. Precedence must form a directed acyclic graph, which is a topological sort. Every operation must bind to a resource whose capabilities satisfy its requirements. Every referenced work instruction and visual must be in a released state at the same effectivity. None of this needs AI; it needs the discipline to treat the BOP as source code with a build.

Mapping the BOP to ISA-95 and B2MML

On the MES side, the natural target is the ISA-95 operations definition. In the B2MML schemas that implemented the 2010s editions of IEC 62264, a product’s production rules were expressed through operations definitions containing operations segments, with material, equipment and personnel specifications, and process segments described what the plant could do. A bill of process maps cleanly: a process becomes an operations definition, operations become operations segments, consumed parts become material specifications with a “consumed” use, resource requirements become equipment and personnel specifications, and step-level data collection becomes parameter specifications.

Two things changed in 2026. The IEC published IEC 62264-2 Edition 3.0 on 6 March 2026, replacing the 2013 edition, according to the IEC webstore listing. Public summaries of the new edition describe the separate product definition, production schedule, production performance and production capability models as folded into the general operations models, plus new operations event, operations record, location and test models. The listing also states it cannot ensure backward compatibility with implementations based on earlier editions. At the time of writing I could not confirm whether MESA has published a B2MML release aligned with Edition 3; check MESA directly before committing a schema version.

The practical consequence: do not let your BOP data model be a mirror of one B2MML version. Keep a neutral internal model, like the JSON above, and write the B2MML (or vendor MES API) mapping as a replaceable adapter. Batch industries face the same choice when they map master recipes, which our post on ISA-88 batch control and recipe management covers; discrete assembly and batch recipes converge on the same ISA-95 operations definition, but from very different source structures.

Digital Work Instructions, Change Propagation and PLM to MES Integration

The bill of process becomes visible to operators through work instructions and becomes dangerous through change. This section covers both, then compares the integration patterns that carry the result into MES.

Authoring Digital Work Instructions from the BOP

Digital work instructions should be generated from the BOP, not written beside it. When each step already knows its consumed parts, tools, characteristics and 3D context, most of the instruction can be assembled automatically: the parts list for the step, the tool and torque setting, a 3D view of the product state before and after the step, and the data-collection prompts. The author adds the human layer: the caution, the hand position, the tip that prevents a cross-threaded screw.

Siemens’s Teamcenter process planning material describes authoring and sharing electronic work instructions with 2D, 3D and augmented-reality visualisation under revision management. PTC, Dassault and many specialist vendors offer comparable capabilities. The feature lists matter less than three architectural properties.

First, instructions bind to step identifiers and effectivity, not to a document number that someone remembers to update. When step 0040-20 changes from three screws to four, the instruction for that step is invalid until re-released. Second, 3D content comes from the released model with product manufacturing information (PMI), so the torque callout or the datum reference in the instruction is the same one in the model-based definition (MBD). Our comparison of STEP AP242, JT and QIF for MBD and PMI covers the format choices for carrying that geometry and annotation downstream. Third, instructions are rendered in MES, not exported as PDFs. A PDF loses the link between a displayed value and the data-collection prompt, so the operator types a torque reading into a field that no longer knows what the nominal was.

A useful rule of thumb from deployments I have seen: if an instruction change requires a person to open a second application to update a second artifact, that second artifact will eventually be wrong. Generate, do not duplicate.

Change Propagation from ECO to the Shop Floor

The hardest part of any bill of process implementation is change. An engineering change order (ECO) touches the EBOM; the MBOM must follow; the bill of process must follow the MBOM; plant BOPs must follow the product BOP; and MES must switch over at a precise effectivity point while work in progress (WIP) is still on the line.

Figure 3: ECO propagation through the bill of process. Each structure is updated in order, impact analysis flags affected operations, the compiler rebuilds per plant, and MES activates the new package at the agreed effectivity while existing WIP completes on the old one.

The sequence in Figure 3 has five decision points worth making explicit. When the ECO releases, an impact query asks which MBOM occurrences changed, which operations consume them and which plant BOPs inherit those operations. Our post on engineering change management, ECR, ECO and effectivity explains the upstream workflow; graph-based where-used queries make this downstream traversal fast.

Next, a process planner decides whether the change is process-relevant. A supplier swap with identical form, fit and function may need only a material master update. A new fastener count changes consumption, time, torque characteristics and the instruction. The plan must classify the change before anyone edits anything.

Then plant BOPs are re-derived. If the product BOP changed an operation that a plant had locally overridden, the merge is a conflict, and it must be resolved by a human, not by “last writer wins.” This is where the product-plant diff earns its keep.

Then the compiler rebuilds and validates each affected plant package at the new effectivity, running the same consumption, precedence and resource checks shown earlier.

Finally, MES cuts over. With date effectivity, orders released after the date use the new package. With serial or lot effectivity, the switch happens at a specific unit. WIP already released keeps the package it started with, unless the change is a safety or quality containment that forces rework. The MES must therefore hold at least two active versions of a process definition simultaneously, and every production record must store which version it was built to. That record is the as-built half of the digital thread; configuration baselines are the as-designed half, which we cover in configuration management in PLM.

PLM to MES Integration Patterns

There are four common ways to move a bill of process into execution. They differ in coupling, latency and who owns the truth.

Pattern	How it works	Strengths	Weaknesses	Fits when
ERP relay	PLM sends MBOM and routing to ERP; ERP sends production orders with routing to MES	One integration for PLM; ERP is already the order master	ERP routings cannot carry steps, instructions or characteristics; detail is lost	Simple discrete products with paper or MES-authored instructions
Direct publish	PLM publishes the full process package to MES on release; ERP gets a slim routing in parallel	Full fidelity to the shop floor; one source for instructions	Two downstream integrations must agree on operation IDs and effectivity	Most mid-to-high complexity assembly
Live federation	MES reads BOP objects from PLM at runtime through APIs	No copy, no sync lag	Shop floor depends on PLM availability; unreleased edits can leak; latency on every station load	Rarely appropriate; sometimes for low-volume engineering prototypes
Event-driven package	PLM release emits an event; an integration service compiles, validates and publishes an immutable package to MES and ERP	Validation gate, versioning, replay and audit by design	More moving parts to build and operate	Multi-plant, regulated or high-change environments

My recommendation for most manufacturers is the fourth pattern, with direct publish as an acceptable simpler start. The ERP relay remains common in practice because ERP already owns production orders, but it forces the shop floor to recreate the missing detail somewhere, usually in MES configuration that PLM cannot see. Live federation looks elegant on a whiteboard and fails the first time PLM is down for an upgrade during a production shift.

Whatever the transport, the payload decision is the same. ERP needs operation number, work center, setup and run time, and component allocation to operation for backflushing. MES needs all of that plus steps, instructions, characteristics with limits, tool programs, resource bindings and the effectivity window. Sending MES a superset and ERP a projection of the same compiled package keeps the operation identifiers consistent by construction.

Capacity and Volume: How Big Does This Get?

It helps to size the problem before choosing tools. Consider an illustrative mid-size assembly plant with 400 active manufactured items, an average of 25 operations each and 6 steps per operation. That is 10,000 operations and 60,000 steps, before plant variants. If 10 percent of items change per month, roughly 40 process packages are recompiled monthly per plant. Even at several megabytes per package with embedded 3D views, that is a modest data flow. The constraint is not bandwidth; it is the human review queue for process-relevant changes and the correctness of effectivity resolution. Size the team and the validation tooling, not the message bus.

Trade-offs, Gotchas, and What Goes Wrong

A bill of process program fails in predictable ways. Figure 4 maps the most common failure modes to the gate that should catch each one.

Figure 4: Common bill of process failure modes and where to catch them. Most defects are detectable at compile time; the rest need runtime reconciliation between PLM, ERP and MES.

Consumption drift. Parts consumed in the BOP stop matching the MBOM, as in the worked example. Symptoms appear far from the cause: inventory variances, backflush errors, kits with leftover parts. The fix is the consumption gate, run per effectivity point, plus a nightly reconciliation that compares MES actual consumption with BOP planned consumption.

Effectivity gaps and overlaps. Two versions of an operation are both valid for serial 1,250, or neither is. Date and unit effectivity mixed across EBOM, MBOM and BOP make this easy to create and hard to see. Resolve effectivity in the compiler, and fail the build if any point in the requested range resolves to zero or two definitions.

Operation ID drift. ERP renumbers operations when a planner inserts one; MES keeps the old numbers; confirmations land on the wrong operation. Make operation identifiers immutable surrogate keys, and treat the visible sequence number (0010, 0020) as a separate, changeable attribute.

Shadow routings in MES. When PLM releases are slow, supervisors edit MES directly. Within a year the MES process differs from the BOP, and the next PLM release overwrites the local fixes. Either give MES a governed “local deviation” object that flows back into a plant BOP change, or lock MES process definitions entirely. Allowing both silent edits and overwrites is the worst option.

Over-modelling. Some programs model every reach and grasp as a step, producing instructions nobody reads and a BOP nobody can maintain. Model steps at the level where a defect could occur or a value must be captured. Motion-level detail belongs in the time-standard analysis, not the operator screen.

Stale instructions. A work instruction released at revision B still shows the old cover after an ECO. The release gate must check that every referenced instruction and visual is released at the same effectivity as the operation.

Vendor lock-in through the data model. Each MPM suite has its own object model, and deep customisation of it makes migration expensive. A neutral internal model and adapter layer costs more up front but contains the blast radius when you change PLM or MES.

The honest limit of this whole approach is organisational. The compile gate will reject releases, and someone must own fixing them. If industrial engineering has no capacity to maintain the bill of process, a stricter pipeline only makes the backlog visible faster.

Practical Recommendations

Start with the contract, not the tool. Agree which system owns each attribute: PLM owns sequence, consumption, characteristics and instructions; ERP owns costs and work-center calendars; MES owns execution state and actuals. Write that ownership table down and make every integration respect it.

Then build the compile step early, even if the first version is a script like the one above, running against an export. The value of seeing consumption mismatches on day one is larger than any visualisation feature. Pilot one product family in one plant, measure release lead time and post-release defects, then scale.

Keep the internal model neutral. ISA-95 is being restructured in its 2026 edition, B2MML versions follow the standard, and vendor APIs evolve. An adapter you can rewrite in a sprint is cheaper than a data model you cannot change.

Checklist for a first bill of process rollout:

Define routing, operation and step precisely, and publish the glossary to ERP, PLM and MES teams.
Make operation IDs immutable keys; keep sequence numbers as attributes.
Split product BOP from plant BOP and report the diff per plant.
Model resources as capabilities plus instances in a resource library or bill of equipment.
Record a basis and date for every standard time; compare against MES actuals monthly.
Generate work instructions from BOP steps; bind them to step ID and effectivity.
Gate every release on consumption, quantity, orphan, precedence, resource and instruction checks.
Publish immutable, versioned packages; let MES hold two active versions for WIP.
Give MES a governed deviation path back to PLM instead of silent local edits.

Frequently Asked Questions

What is a bill of process in PLM?

A bill of process (BOP) is the PLM structure that describes how a product is manufactured. It contains processes, operations and steps in sequence, the MBOM parts each operation consumes, the resources and tools required, time standards, quality characteristics and links to work instructions. It is authored by manufacturing or industrial engineers, specialised per plant and released downstream. ERP uses a simplified projection of it for costing and scheduling, while MES uses the full definition to guide and record execution on the shop floor.

What is the difference between BOP vs MBOM?

The MBOM lists what is built: parts, assemblies, kits and consumables with quantities, structured the way manufacturing assembles them. The bill of process describes how it is built: operations, sequence, resources, times and instructions. The two are joined by consumption links that assign each MBOM line to the operation that installs it. They are kept separate because they change for different reasons. A supplier change typically alters the MBOM only, while a line rebalance alters only the BOP. Merging them couples two change processes unnecessarily.

Is a routing the same as a bill of process?

No. A routing is the ERP view: an ordered list of operations with work centers and setup and run times, used for costing, scheduling and capacity planning. A bill of process is richer. It also holds steps, consumed-part assignments, resource capabilities, quality characteristics, tool settings and work instructions. A good integration derives the ERP routing from the released BOP so operation identifiers stay identical. Treating the ERP routing as the master forces detail into other places, typically MES configuration or documents, where PLM change control cannot reach it.

How does a bill of process map to ISA-95?

In ISA-95 terms, a process maps to an operations definition, operations map to operations segments, consumed parts map to material specifications, resource needs map to equipment and personnel specifications, and step-level data collection maps to parameters. B2MML, maintained by MESA, implements these models in XML and, since version 7, JSON. IEC 62264-2 Edition 3.0, published in March 2026, restructures several models and does not guarantee backward compatibility, so keep a neutral internal model and treat the ISA-95 or B2MML mapping as a replaceable adapter.

Should MES read the BOP directly from PLM at runtime?

Usually not. Runtime federation makes the shop floor depend on PLM availability and response time, and it risks exposing work-in-progress edits that were never released. A better pattern is to compile and validate a released, effectivity-resolved process package and publish it to MES as an immutable version. MES then runs independently of PLM and can hold several versions at once for work in progress. Federation can make sense for low-volume prototype builds where engineers and operators work side by side.

How should digital work instructions relate to the BOP?

Digital work instructions should be generated from BOP steps rather than authored separately. Each step already knows its parts, tools, characteristics and 3D context, so most instruction content can be assembled automatically, with authors adding cautions and technique. Bind every instruction to a step identifier and effectivity, take 3D views from the released model and its PMI, and render instructions inside MES so displayed values and data-collection prompts stay connected. Exported PDFs break that link and drift out of date.

Bill of Process in PLM: Manufacturing Process Planning, Routings, Work Instructions and the MBOM-to-MES Handoff (2026)