Order decomposition translates the commercial lines of a customer order into the operational tasks required to deliver them. A fulfilment plan is the result: a dependency graph of tasks with owners, states, milestones and compensating actions, rather than a checklist or a report.
A €1.4 billion industrial equipment manufacturer closed a €2.8 million order for three configured air compressors, site installation and a three-year managed service contract. The quote took four days. The order took eleven weeks to deliver, and nobody inside the company could say why.
Sales saw "order booked" in CRM. Supply chain saw three sales order lines in the ERP. The plant saw a production order with no site context attached. Field service discovered an install was required when the customer called to ask who was bringing the crane. The commissioning report sat in a service manager's inbox for nine days, which meant the revenue milestone sat there too. At quarter end, finance chased it manually.
Nothing broke. Every system did its job correctly. The order simply had no owner in the space between the moment it was booked and the moment it was done, and that space contained about thirty-five distinct pieces of work.
What is actually going wrong?
An order is two different things at the same time, and most architectures only model one of them properly.
The commercial order is what the customer agreed to buy: priced line items, configured options, terms, discounts, a signed contract. It is the artefact CPQ produces and CRM stores. Its structure is optimised for negotiation and revenue: what was sold, at what price, under what terms, to whom.
The fulfilment view is what the business must actually do to honour that agreement: procure long-lead components, schedule a work centre, run quality inspection, raise export documentation, book freight, survey the site, dispatch a certified crew, commission the equipment, register a device, activate an entitlement, trigger a billing schedule. Its structure is optimised for execution: who does what, in what order, with what preconditions, and what happens when a step fails.
These two structures are not the same shape, and the gap between them is not small. One commercial line routinely becomes fifteen to forty operational tasks spread across five or six systems, each with its own owner, state model, latency profile and failure mode.
What is order decomposition?
Order decomposition is the process of translating the commercial structure into the operational one. It reads each order line item (the product offering, its configured attributes, the action type such as new, change, disconnect, suspend or resume, the delivery location, the customer's existing installed base and entitlements) and applies decomposition rules to determine what work is required.
Decomposition is recursive rather than flat. A commercial product offering decomposes into one or more technical product specifications; those decompose into the services and resources that actually deliver them. In telecoms modelling this is the familiar chain from customer-facing service to resource-facing service. In industrial and equipment contexts the same logic maps a sold product to a bill of materials, a work centre routing, a shipment, a set of work orders, a device registration and an entitlement record. The vocabulary differs; the pattern is identical.
Decomposition is also conditional. The same product ordered for a site in Rotterdam and a site in São Paulo produces different tasks: different export documentation, different certification requirements for the installing technician, possibly a different plant. The same product ordered as a change to existing installed equipment produces a different task set again: no production order, but a retrofit work order and an amended entitlement. Rules of this kind are driven by data such as product model, action type, geography, customer segment, fulfilment provider and installed-base state.
What is a fulfilment plan?
A fulfilment plan is the output of decomposition, and it is not a list. It is a directed acyclic graph of fulfilment tasks with explicit dependencies, where each task is routed to the system or team that owns it and carries its own state machine, SLA, assignee, input payload and compensating action for failure or cancellation.
A real plan holds several things that a task list cannot:
- Sequencing as data. The plan knows that freight booking cannot start before QA release, that the install work order cannot be scheduled before both delivery confirmation and a passed site survey, and that entitlement activation waits on commissioning sign-off. These constraints are stored, not remembered.
- Parallelism as intent. Tasks that can run concurrently do so. A site survey should run alongside manufacturing rather than after it, because a survey failure discovered late is the single most expensive thing that can happen to an order of this kind.
- A state model per task, and a rollup for the order. Each task moves through its own lifecycle. The order's state is derived from the plan rather than reported by whichever system last sent an update.
- Milestones with meaning. Delivery, commissioning and acceptance are not just statuses; they are the events that gate revenue recognition, warranty start and billing activation. Attaching them to tasks makes them auditable.
- Compensation and amendment. Every task that changes external state needs a defined reversal. A plan that cannot be unwound cannot be safely changed in flight.
Where does it fail in practice?
The failure patterns are consistent across industries.
Decomposition logic gets scattered. Some sits in CPQ configuration rules, some in middleware field mappings, some in an ERP user exit, some in a field service assignment rule written by a consultant years ago. No one can answer "what does this product require to be delivered?" without reading four systems.
There is no plan object, so there is no status. Because the plan is emergent rather than stored, order status has to be assembled by polling. It becomes a report someone runs, rather than a state something owns. Every "where is my order?" question costs human time.
Dependencies live as tribal knowledge. The sequencing is real, but it is enforced by a coordinator with a spreadsheet and a good memory. When that person is on leave, crews get dispatched to sites where the equipment has not cleared customs.
Amendments destroy work. Customers change complex orders in flight; this is normal, not exceptional. With no plan to amend, the standard response is to cancel and rebook. Completed manufacturing, completed surveys and completed procurement all restart. The clock resets on a delivery date the customer is already unhappy about.
Non-material lines have no home. Installation, commissioning, training, entitlement and device registration are not shippable materials. In an ERP-centric flow they end up as text lines, notes, or nothing at all, which is precisely why they are the steps that get dropped.
What is the business impact?
These costs are rarely booked as "order management" costs, which is exactly why they survive budget cycles.
Revenue timing. Most equipment-plus-service contracts recognise revenue at a milestone: delivery, commissioning or customer acceptance. If commissioning evidence takes nine days to reach finance, that is nine days of slippage per order, compounding at quarter end and distorting forecast accuracy. On a €2.8 million order, a two-week delay in recognition is real money at any plausible cost of capital, and it happens on every order, not the exceptional ones.
Cash conversion. Milestone billing depends on milestone evidence. Delayed commissioning sign-off delays the invoice, which delays collection, which shows up in days sales outstanding without anyone tracing it back to a service manager's inbox.
Deal loss. Buyers of complex equipment evaluate the last delivery when awarding the next one. A committed date missed by three weeks costs the follow-on order far more often than a 3% price difference does. In competitive re-bids, delivery performance is frequently a scored criterion with documented evidence required.
Sales capacity. Reps become expediters. When the only way to answer a customer's status question is to ping four internal teams and wait, the rep loses roughly a day a week per active complex order. That is pipeline generation capacity spent on coordination that a system should be doing.
Operational cost. Failed truck rolls are the canonical example: a crew arrives to install equipment still in customs, or at a site whose floor loading was never verified. Each failed dispatch burns a day of crew time, rescheduling overhead and customer goodwill, and it is caused entirely by a missing dependency in a plan that does not exist.
Penalty exposure. Where contracts carry liquidated damages or SLA credits for late delivery, missing sequencing turns directly into a line item on the profit and loss account.
Why does legacy CPQ struggle here?
This is a structural limitation, not a defect list, and it matters because the usual remedies target the wrong layer.
Legacy CPQ, the Salesforce, Oracle and bolt-on quoting generations, was built to end at the quote. Its data model is optimised for configuration validity, guided selling, pricing, approval routing and document generation. Those are genuinely hard problems and the tools solve them. But when the deal closes, the process boundary closes behind it. The system hands over a commercial order and considers its job complete. There is no orchestration layer because orchestration was never in scope for the product category.
The natural fallback is to promote ERP to orchestrator. ERP is excellent at what it owns: materials planning, production, costing, inventory, invoicing. It has no native concept of a field service work order gated on a customer site survey, no first-class model for a service entitlement, and no way to represent a task it does not itself execute. So the parts of the plan living outside ERP become point-to-point integrations, and the integration diagram becomes the plan.
Three consequences follow, and they are architectural rather than configurable:
- One commercial line is assumed to equal one ERP line. Anything that is not a material (installation, commissioning, training, entitlement, monitoring onboarding) has nowhere to live. These become the invisible tasks that no system tracks.
- There is no in-flight change model. Amendments require cancel-and-rebook because the order is a record, not a running process. There is no notion of patching a graph while some of its nodes are already complete.
- Status is aggregated rather than owned. Each system publishes its own view. Reconciling them is a reporting exercise, and reporting exercises are always out of date by the time someone reads them.
A fourth, subtler consequence: because decomposition logic is distributed across integrations, product launch velocity collapses. Introducing a new configurable product or a new regional fulfilment partner becomes a multi-system IT project instead of a catalogue change. Commercial agility is limited by fulfilment rigidity, which is rarely how the problem gets described in the steering committee.
What does this look like on a real order?
Order: three IC-900 compressors (configured, make-to-order), site installation and commissioning, and a three-year managed service contract with remote monitoring. Single customer, single site, Rotterdam.
Decomposition produces three branches from three order line items.
Line one, the equipment. Decomposes into: ERP sales order creation, planned order and material reservation, long-lead component check, plant production order per unit, in-process and final QA, QA release, export documentation pack, freight booking, shipment dispatch and delivery confirmation at site.
Line two, installation and commissioning. Decomposes into: a field service site survey work order (floor loading, power supply, ventilation, access route), rigging and crane scheduling, an install work order requiring a certified technician plus rigging crew, and a commissioning work order with performance test and signed customer acceptance.
Line three, the managed service contract. Decomposes into: IoT gateway procurement and registration, telemetry onboarding and baseline calibration, entitlement activation against the customer account, support routing configuration, and billing schedule activation with the correct start date.
The fulfilment plan then wires dependencies across the branches, which is the part no single system can do alone:
- The site survey is scheduled early, in parallel with production, not after delivery.
- Export documentation is gated on QA release; freight booking is gated on documentation.
- The install work order requires both delivery confirmation and a passed survey.
- Crane and certified technician availability is treated as a resource constraint on the install task, not discovered on the day.
- Commissioning follows install; the customer acceptance signature is captured as task evidence.
- Entitlement activation and billing schedule activation both depend on commissioning, so the service contract cannot start billing for equipment that is not yet running.
- The revenue recognition milestone fires from the commissioning acceptance task, automatically, with the signed evidence attached.
Now the realistic complication. The survey, run in week two, finds the floor loading insufficient for the IC-900 footprint. A reinforced base frame is required. This raises a change order.
With a real fulfilment plan, the amendment re-decomposes only the affected subgraph: a new material line for the base frame, a civil works task inserted before install, a revised install date, and shifted downstream milestones for commissioning, entitlement and billing. Production of the compressors continues untouched. The customer gets a revised committed date in days, backed by the actual dependency chain rather than a guess.
Without a plan, the order is cancelled and rebooked. Completed production is orphaned or scrapped into inventory, the survey is repeated because its result was attached to the cancelled order, and eleven weeks becomes fourteen. The customer's next tender goes to a competitor on delivery performance.
What does the modern approach look like?
The architectural shift is to treat the fulfilment plan as a first-class, queryable object sitting between commerce and execution, rather than as an emergent property of integrations. In practice that means four things.
A shared product model. The commercial product offering carries its technical decomposition, so the same catalogue entry drives both quoting and fulfilment. A new product is modelled once. This is what makes new offerings launchable in weeks rather than quarters.
Decomposition rules as configurable data. Adding a region, a plant, a partner installer or a new action type becomes a rule change made by a business configurator, not a code change made by an integration team.
Dependency-aware orchestration with compensation. The plan runs as a stateful process. Failures roll back cleanly using defined compensating tasks. Amendments patch the running graph instead of replacing it. This capability is what actually distinguishes an orchestration platform from a workflow tool.
Fulfilment systems as task executors. ERP, manufacturing execution, warehouse management and field service each execute the tasks they own and report state back into one plan. None of them is asked to be the system of record for work it does not perform. Integration remains necessary, but it stops being where the logic lives.
AI-assisted CPQ extends this usefully at the edges rather than replacing any of it: predicting realistic fulfilment duration from the specific configuration at quote time, so the date the rep commits to is defensible; flagging configurations whose decomposition has historically produced exceptions, before the customer signs; and suggesting alternative configurations that fulfil faster when the customer's real constraint is timing rather than specification. All of that depends on having structured plan history to learn from. Without the plan, there is no training signal, only anecdotes.
Frequently asked questions
Is order decomposition the same as a bill of materials explosion?
No. A bill of materials explosion resolves what a product is made of. Order decomposition resolves what the business must do to deliver the order, including services, site work, entitlements, registrations and billing triggers, and it is conditional on context such as geography, action type and installed-base state.
Can ERP handle fulfilment planning on its own?
ERP orchestrates the work it executes itself: materials, production, costing and invoicing. It has no first-class model for tasks it does not perform, such as a site survey gating an installation, so those steps end up in integrations, spreadsheets and inboxes instead of a plan.
What is the quickest way to test whether you have a real fulfilment plan?
Amend a complex order in week two. If the answer is cancel-and-rebook, the plan is emergent rather than stored, and every in-flight change will destroy completed work and reset the customer's delivery date.
Where does ServiceNow fit?
ServiceNow's Sales and Order Management capabilities sit between CPQ and the executing systems, holding the order, its decomposition and its fulfilment plan as first-class records on one platform, with field service, customer service and entitlements on the same data model.