How Do You Capture Real Cost in Customer-Specific Production? Dynamic Recipes and the True Cost Engine
An order arrived. A work order opened. Then what? In Order Arrived, Work Order Opened, Then What? we saw how information scatters across paper, Excel, the foreman’s head, and WhatsApp groups. In Your ERP Is Not Lying, It Just Speaks Late and in Coarse Grains we discussed how ERP was designed for finance and purchasing, not for real-time shop-floor data. In What Is MES? Real-Time Shop Floor Data Capture we covered the layer that captures actual duration, downtime, and defect data from work order open to close. In What Is MOM? The Orchestration Layer Above MES we introduced the broader umbrella that includes MES and orchestrates production, quality, maintenance, and inventory under one roof. In How Do the Layers Connect? Data Flow in ERP-MOM-MES Integration and Local ERPs we examined 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 Test 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.
Concrete Scenario: Same Part, Two Different Work Orders
Imagine you sent the same metal enclosure to the same customer in two different orders. On the first order, the sheet metal was 2 mm thick, with a laser cutting + bending + welding sequence. On the second order, the same part was made from 3 mm sheet metal, with bending first then welding. Why?
In the first order, laser cutting finished in standard time, bending was done in a single stage. In the second order, the thicker sheet required bending in two stages, and welding took longer. Additionally, the customer added an assembly option to the second order — this was added after the work order was opened and changed the recipe.
ERP’s standard cost shows the same cost for both work orders because they are the same part. But actual cost differs. Looking only at ERP, you see that the second work order is “more expensive” — but you don’t know why. The first work order’s data is treated as normal because it falls below standard cost, but in reality, the first work order also had its own variances.
Dynamic Recipes: Every Work Order Carries Its Own Plan
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.
Partial Production Metrics discussed operation count tracking and material weight measurement. Here, they serve as the data input for the dynamic recipe. Instead of the binary “done / not done” status, converting each operation’s weight and rate into a cost transforms raw floor data into planning meaning.
The True Cost Engine: Every Order Tells Its Own Story
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.
Consider three work orders, all for the same product:
| Work Order | Laser Cut | Bending | Welding | Total Actual | Standard | Variance |
|---|---|---|---|---|---|---|
| WO-001 | 0.5 h | 1.0 h | 1.5 h | 3.0 h | 2.5 h | +0.5 h |
| WO-002 | 0.5 h | 2.0 h | 2.0 h | 4.5 h | 2.5 h | +2.0 h |
| WO-003 | 0.5 h | 1.0 h | 1.0 h | 2.5 h | 2.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: 1h bending, 1.5h welding → welding ran 0.5h over the recipe expectation
- WO-002: 2h bending → thicker sheet required two stages; welding 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? The Orchestration Layer Above MES 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 Do the Layers Connect? Data Flow in ERP-MOM-MES Integration and Local ERPs 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.