Challenges in Demand-Driven Production: Recipe, Routing, and Cost

For the first five days, we have outlined a system built on this scenario: the order is clear, the parts to be made have a known design, the machines are set up for series production. Standard recipe, standard routing, standard cost. But in demand-driven production, reality is different. The customer does not always place a standard order. Sometimes they say “make this part a bit thicker but lighten it here.” Or “this material is unavailable this week, can you use something else?” Or last-minute material price spikes shift cost assumptions. In this case, the standard recipe written in the ERP is no longer enough. A dynamic recipe is needed. And cost must be calculated in real time.

Recipe and Routing: The Problem of Static Definitions

In a typical ERP system, a product’s recipe (Bill of Materials, BOM) and operation sequence (routing) are stored as fixed records. For example, product A is made like this:

• Operation 1: CNC lathe, 30 minutes
• Operation 2: Welder station, 15 minutes
• Operation 3: Quality control, 10 minutes

Materials:

• Primary stock: 50 mm steel rod, 1 kg
• Sub-assembly: Gasket, 2 units
• Paint: Epoxy black, 50 grams

This works perfectly for series production. If you produce one thousand units of A per month, the same recipe, same routing, same cost applies every day.

But in demand-driven production, the recipe can vary by customer specification:

• Customer A: “Make it without the gasket, as a single part.”
• Customer B: “Can you make it thicker? Add 2 mm.”
• Customer C: “Use zinc plating instead of epoxy.”

It is not feasible to open a separate product code in the ERP for each variant. They are dynamic. They are specified at order time. In this case, the recipe, routing, and therefore cost must be calculated at order entry. A static BOM is insufficient.

Operation Sequence Uncertainty

Another problem: the operation sequence (routing) itself may not be fixed. In the standard routing, CNC comes first, then welding, then inspection. But for some customer orders, quality inspection must happen before welding. Or because a machine is unavailable, part of the work is redirected to an alternate machine.

When the MES opens the work order, it may never know what the routing will be. The MOM must be a dynamic routing decision engine. “Given this material choice and this machine availability, what is the best routing?” it should ask. Then it should tell MES only that routing.

But in the ERP-MOM-MES chain, once this dynamic decision is made, it must report back to the ERP. “We altered the routing to X for this reason, so labor hours total 40 minutes.” Because cost calculation depends on routing.

Standard Cost vs. Actual Cost

In ERP systems, cost is usually calculated using standard cost:

• Product A = fixed material cost + labor hours × hourly rate + allocated overhead
• Formula: A = 0.50 TL material + 0.75 hr × 100 TL/hr + 0.50 TL overhead = 130 TL

But in demand-driven production, actual cost can be very different:

• By customer specification, material cost varies. Premium material costs more.
• If routing changes, labor hours change. Redirecting from welder to CNC is a different expense.
• Scrap due to choice of routing becomes part of the cost. “This routing choice results in 10% scrap; cost rises by that amount” must be reported.

To account for this variance, accounting must abandon standard cost and adopt actual cost. When a work order closes, it should show “Planned cost: 130 TL” but “Actual cost: 145 TL.” Why 15 TL difference? Material? Routing? Scrap? All must be reported.

Dynamic Recipe and Real-Cost Engine

To solve these problems, the production management system (MES + MOM) must do the following:

1. Dynamic Recipe Engine: A system that automatically calculates material selection and recipe based on order specifics.

   • If the customer requests “alternate material,” the system reports: “This material costs 5 TL more and adds 10 minutes.”

2. Routing Optimization: A decision mechanism that determines the best operation sequence given current machine and operator state.

   • If standard routing is X, but CNC is offline, the system asks: “Shall we use alternate routing Y?” and reports cost impact.

3. Real-Cost Engine: From the moment a work order starts, as every piece of data is logged (material draw, labor hours, scrap, waste), the cost updates in real time.

   • Planned 130 TL, but actual is 145 TL. System shows: “Variance: +15 TL; root cause: 3% extra scrap + material surcharge.”

Without these engines, the accounting department asks “What was our cost variance?” at month-end and no one knows. Or it is calculated by hand in Excel, prone to errors.

Integration Point: Dynamic Data Returns to ERP

At the start of a work order, MOM selects the recipe and routing to match demand. Then MES executes production with this data. When the work order closes and what was actually done—and what it actually cost—is reported, the ERP system must accept this dynamic data.

• “Routing deviated from standard, cost +5 TL” — send this back to ERP.
• “Scrap for this order was 15%, plan was 5%” — report it.
• “Material switched to alternate, price variance +10 TL” — ERP must know.

Otherwise, ERP continues on standard cost and accounting makes a variance entry at month-end. This leaves no useful insight into production efficiency.

Summary

In demand-driven production, recipe, routing, and cost cannot be static. They must be dynamic. To provide this:

1. MOM must be a decision engine that selects materials and operations based on order detail.
2. MES applies these selections and collects real data every moment.
3. At closeout, the difference between planned and actual cost is reported and fed back to ERP.

Infab.cloud provides this flow of dynamic data and cost between the three layers (ERP-MOM-MES). For ERP systems that only work with standard recipes and static routing, demand-driven production means month-end variance entries in accounting. Both data loss and trust loss.

Tomorrow we will discuss the synthesis of these three layers: how they must truly work as one integrated whole, and why building it alone is so hard.