Dynamic Recipes and Real Cost in Make-to-Order Manufacturing: The Collapse of Static Formulas

For five days we’ve broken down the system. What is ERP, what is MES, what is MOM, how do they connect. But everything rested on one assumption: the order’s recipe is fixed, machines are standard, cost is known in advance.

In make-to-order manufacturing, reality is messy.

Monday morning, an order arrives: 100 units of standard A product. The customer says: “But this time, no washer, thicker top cover, and you know I like fast delivery.” So what happened? The standard recipe includes a washer. The thickness is different. And fast delivery means the operation sequence might change. Wait, where’s that “standard routing”? It can’t be written down because every customer brings a different ask.

This situation creates a collapse between a simple ERP system’s recipe and the MES execution world.

Static Recipe: The Institution That Loses Real Flexibility

In most ERP systems (Netsis, Odoo, Logo, Paraşüt, even SAP simplified at this point), a product’s recipe and routing live in one place. For example:

Product A Recipe:

Okay. If you’re producing a thousand units of A, this recipe can be used the same way for 200 days. But in make-to-order, every order is a variant. Customer A: “Make it without washers.” Customer B: “Use zinc plating instead of epoxy.” Customer C: “I need it done in 2 hours.” If you open a separate product code in ERP for each customer, your catalog explodes into thousands. You can’t manage it manually.

So what do shops typically do?

  1. They pull the standard recipe and hand-write “no washer” on the work order.
  2. The operator sees that note at the machine and skips the washer.
  3. But what about cost accounting? ERP will deduct a fixed price for the washer anyway, so the product’s total cost will appear understated.
  4. By month-end, accounting sees the same thing: “Product A’s actual cost is 15 TL below standard.”

This makes it hard for management to understand cost and variance. You expected standard (e.g., 150 TL), you see actual (e.g., 135 TL). Why? The recipe changed, but the system never recorded it.

Operation Sequence: Uncertain Routings

The second problem is operation routing. Standard routing says: CNC → Welding → Quality Control, done. A 3-hour flow. But if a customer says, “Can you speed this up, I need it Friday noon?” then the routing changes.

Quality control doesn’t happen right after welding, because furnace annealing might disqualify it. So should Quality happen before annealing or after? The shop floor manager says, “Suggestion: partial check before anneal, final after.” That’s not a static routing. Every order is redesigned based on delivery time and current machine capacity.

MES doesn’t see this dynamic routing. The ERP “standard route” stays simple. MOM must determine this routing dynamically: “Given this customer, this time constraint, and current machine status, the best sequence is: CNC → Anneal → Quality → Weld.”

But how does this dynamic decision affect cost? If the operation sequence changes, labor hours and overhead change too. If the system doesn’t notice, cost estimates will always be off.

Standard Cost: An Illusion

The ERP cost formula:

Product Cost = (Material Unit Price Ă— Qty) + (Labor Hours Ă— Hourly Rate) + (Overhead Allocation)

Example: Product A = 50 kr material Ă— 2 + (0.75 hours Ă— 100 TL/hour) + 50 kr overhead = 130 TL

If Customer Ahmet orders without washers: Product A (No Washer) = 40 kr material Ă— 2 + (0.75 hours Ă— 100 TL/hour) + 50 kr overhead = 120 TL

But because this “120 TL” wasn’t pre-calculated or coded in ERP, accounting still starts from standard 130 TL and logs it as a variance.

Plus, if the operation sequence changes, labor hours might too. Standard assumed “0.75 hours,” but dynamic routing makes it 0.9 hours. That difference disappears in the cost report.

Real-Cost Engine: More Necessary Than It Seems

In make-to-order, cost must be calculated in real time. When MES starts operations, MOM must know:

  1. Actual Operation Sequence: What’s the routing for this order? (Determined dynamically.)
  2. Actual Labor Hours: How long did each operation take? (MES pulls start-end times.)
  3. Actual Material Quantity: Did the recipe change, what was scrap? (MES and quality sensors.)
  4. Actual Overhead Allocation: Did maintenance stop machines, was there waiting? (Wait time reduces overhead per unit.)

If these four data points are calculated correctly, the job’s real cost returns to ERP. Accounting can report: “This order cost X, standard was Y, the difference came from Z.”

Management, seeing this clarity, can then ask: “Why are we consistently under standard, did the process speed up or was it a recipe change?”

Conclusion: A Dynamic System Is Required

Static recipes and fixed routings exist only in the plan, not in practice, in make-to-order. MES, when launching operations, must know the dynamic recipe and routing. MOM must pull this from ERP and align it with the order. When the job ends, data recorded by MES must return to ERP via dynamic calculation.

Otherwise, accounting will spend every month-end complaining: “Product A’s cost variance between estimate and actual is X%.”

What infab.cloud provides is precisely this: a real-cost engine. When an order is customized, the recipe is built on the fly. The routing is dynamically chosen by machine status. When the job ends, the system knows: “This order was built with 0.87 labor hours + 42 gr epoxy + zero washers + 2 hours anneal. Standard was 0.75 hours, why the difference?” and can say.

That’s not a cloud guess—it’s data from your process.

This post is Day 6 in the “Make-to-Order Manufacturing and Factory Software” series.