The Real Cost in Customer-Specific Production: Dynamic Recipes and the True Cost Engine
An order arrived, a work order opened — what happened next? In A Reverse View of Work Orders, we saw how work orders grow and change through confirmations. In What ERP Is and What It Is Not, we discussed how ERP was designed for finance and procurement cycles, not for real-time data collection on the shop floor. What Is MES? covered the layer that captures operation-level actual duration, stoppage, and scrap data from order opening to closure. How Layers Connect examined the data flow between these three layers and why integration with local ERPs demands a dedicated bridging layer.
Today, within this framework, we tackle the least discussed problem in customer-specific production: the truth about cost.
How Cost Works in Mass Production
In mass production, the recipe is fixed. The same part, same materials, same operation sequence, same machines. Standard cost is calculated once and applies across thousands of parts. Actual cost converges toward the standard — deviations are negligible or accumulate predictably.
ERP excels in this model. Standard cost is entered, actual cost is tracked, the variance is reported. This variance sits at one or two percent and the control mechanism kicks in.
Every Order Is a Different World in Customer-Specific Production
In customer-specific production, every assumption of mass production collapses:
- Every order has its own recipe. The material list changes from order to order.
- The operation sequence is not fixed. One part requires coating before machining; another follows the reverse order.
- Which recipe, which work order do you reference when calculating standard cost?
- Actual cost stems from different sources per order. On one work order, tracking by material weight is highly meaningful; on another, operation count measurement is more direct.
Let’s make this concrete with an example.
Concrete Scenario: Same Work Order, Two Different Costs
Imagine you sent the same product to the same customer at two different times. On work order EM-001, the welding operation took 3 hours, casting took 2 hours. On work order EM-002 — same part — welding took 5 hours, casting took 1.5 hours. Why?
In EM-001, welding was done in a single large batch. In EM-002, the part was split into smaller sections, a different mold was used, and mold-change time was included.
ERP’s standard cost shows the same cost for both work orders. But actual cost differs. Looking only at ERP, you see that EM-002 is “more expensive” — but you don’t know why. EM-001’s data is treated as normal because it falls below standard cost, but in reality, EM-001 also had its own variances.
What Does Capturing Real Cost Mean?
Capturing real cost means knowing what production actually cost. In customer-specific production, this question yields a different answer for every order.
Two concepts solve this: dynamic recipes and the true cost engine.
Dynamic Recipes
A dynamic recipe is an approach where every work order carries its own recipe and routing structure. Instead of a predefined, rigid template, the recipe lives at the work-order level and operation level as a data structure.
It is no longer a one-time, fixed recipe — it becomes a recipe that is born and evolves per work order. Operations can be added, removed, or reordered. Material patterns differ per order. A dynamic recipe is the structure that accepts this variability into the system.
The True Cost Engine
The true cost engine places actual data alongside standard cost to produce a meaningful cost comparison. But it is not a simple subtraction.
Each work order carries its own standard cost — calculated based on the recipe and operation sequence valid for that specific order. Then actual data is compared against this standard. The variance is explained not just as a percentage, but in detail through operation count, duration, and resource consumption.
Partial Production Metrics discussed operation count tracking and material weight measurement. Here, they serve as the data input for the true cost engine. Instead of the binary “done / not done” status, converting each operation’s weight and rate into a cost transforms the raw floor data into financial meaning.
How Does It Work? An Example
Consider three work orders, all for the same product:
| Work Order | Welding Hrs | Casting Hrs | Total Actual | Standard | Variance |
|---|---|---|---|---|---|
| WO-001 | 3.0 h | 2.0 h | 5.0 h | 4.5 h | +0.5 h |
| WO-002 | 5.0 h | 1.5 h | 6.5 h | 4.5 h | +2.0 h |
| WO-003 | 2.0 h | 2.5 h | 4.5 h | 4.5 h | 0 h |
By ERP standard cost, the average variance is 0.83 hours — a single aggregate figure. But the true cost engine opens each work order with its own dynamic recipe:
- WO-001: 3h welding, 2h casting → welding ran 0.5h over the recipe expectation
- WO-002: 5h welding → mold-change time added extra duration; casting was normal
- WO-003: Matched the standard exactly
Each work order has a different cause, a different action needed. Average variance cannot reveal these causes. The true cost engine tells each order’s own cost story.
Where Cost Data Lives: The Integration View
What Is MOM? described MES as the execution layer and MOM as the umbrella that orchestrates production, quality, maintenance, and inventory under a single framework. The true cost engine acts as a bridge between these layers:
- Operation-level actual duration and scrap data arrives from MES
- MOM relates this data to quality results and maintenance records
- A cost profile is built for each work order
- This profile is interpreted before being passed to ERP
How Layers Connect explained why integration with local ERPs requires a dedicated layer. The true cost engine is one of its most critical components. Production data from MES/MOM is structured into a meaningful cost profile for each work order before it enters the ERP accounting cycle.
Conclusion
The cost problem in customer-specific production is not that standard cost doesn’t work — it’s that standard cost is different for every order. In mass production, one standard suffices. In customer-specific production, every work order carries its own standard.
Dynamic recipes allow each order to carry its own operation structure. The true cost engine compares those structures against actual data, revealing each work order’s real cost.
Together, they enable a meaningful answer to “where does the plan stand?” at the cost level: “Work order X is at operation Y, has consumed Z, and has W remaining.”
As we close the week, we will examine the difficulty of building MES+MOM+ERP integration from scratch and how air-gap/on-prem requirements make this even more complex.