Recipe Optimization & Modeling for Chemical Profitability

Introduction

In a process plant, meeting demand looks like running the recipe. But there's almost always more than one way to meet it. The same product can often be made by more than one recipe and on more than one workcenter, and when you run it changes the yield and the cost too. Every one of those paths costs something different, and picking among them is a decision, usually made out of habit rather than math.

That habit is where the margin hides. An ERP takes the recipe and the routing as given and nets the requirements. A spreadsheet runs whatever the planner picked. Neither one asks the question that actually moves the number: of all the valid ways to make what we owe, which is cheapest? Answering that is what recipe optimization does, and it's the difference between a plan that works and the plan that's best.

When a product can be made more than one way, that's a decision

Plenty of products have more than one valid recipe, a different formulation, a different feedstock, a different route to the same spec, each with its own cost and yield. Most of the time nobody treats that as a live choice. Someone picked the usual recipe years ago, the plant runs it out of habit, and what the alternatives would cost today never comes up.

WonForge can be configured to put that choice back in play. When a product has more than one valid recipe, the model weighs them against current material costs, yields, and capacity, and runs whichever one hits the spec for the least money on that plan. Not the recipe you always reach for. The one that happens to be cheapest given where prices and capacity sit right now.

When a product can be made more than one way, which recipe to run is an economic choice, not a fixed fact. WonForge can be configured to make that choice part of the optimization instead of leaving it to habit.

The recipe is one choice inside a bigger one

The recipe doesn't sit by itself. The same demand can be met on different workcenters, and when you run it moves the yield and cost as well, because in the model those numbers can vary by line and by period. A product run on one line this week is a different economic proposition than the same product on another line, or the same line next month. Recipe, workcenter, and timing all lean on each other. You can't settle one well without the other two.

That's the part a spreadsheet can't do. It takes them one at a time, recipe, then line, then timing, each step blind to what the last one just fixed in place. What you get is a plan that hangs together and still isn't the cheapest, because the pieces were never on the table at the same time. A solver puts them there together, which is the only way the recipe you end up with actually fits the line and the week you're running it.

Recipe, workcenter, and timing all affect each other, so they have to be weighed together. Pick them one at a time and you never land on the cheapest combination.

What recipe optimization actually does

Recipe optimization hands the whole decision to a solver: demand, the recipes a product can be made by, the lines it can run on, the timing, the yields each option returns, and every hard constraint. Out comes the plan that meets spec and demand for the least money. Not a plan that fits. The cheapest one that fits.

That's the whole distinction. A planner can build one workable plan by hand, running the usual recipes on the usual lines, and it'll be fine. What a person can't do by hand is weigh the thousands of other combinations, this recipe on that line next month versus that recipe on this line now, and prove which one costs least while still clearing every spec, capacity limit, and changeover rule. A solver can. That's why the plan a spreadsheet gives you is almost never the cheapest one that was available.

A spreadsheet builds one plan that works. A solver searches the valid ways to make what you owe, across recipes, lines, and timing, and finds the one that works for the least money.

Where the margin actually is

This kind of cost never lands as a line item, which is exactly why it goes unnoticed for years. It's the cheaper recipe that would have won this month and never got looked at. It's the product that always runs on the line where its yield is a little worse, because that's just where it runs. It's the campaign timed the way it's always been timed. None of it is a fire. All of it is margin, going out a plan at a time, on calls nobody reopened because the plant has always made them the same way.

Getting it back doesn't take a bigger plant or a leaner crew. It takes asking, every plan, the one question habit never asks: of all the valid ways to make what we owe, is this the cheapest? That's what recipe optimization is for, and the margin it's after is sitting in plans you're already running.

The distance between the way you've always made a product and the cheapest valid way to make it is margin, and it leaks on every plan that runs on habit instead of math.

Frequently Asked Questions

Our recipes are set. How is there anything to optimize?

Often a product can be made more than one way, a different valid recipe, a different line, and the timing moves the cost too, since yields and costs can vary by line and period. Even when the recipe itself is fixed, where and when you run it changes what it costs. WonForge can be configured to weigh the valid recipe options for a product, and it optimizes the line and timing either way. The spec doesn't move; what gets optimized is the cheapest valid way to hit it.

How is this different from what our ERP already does with recipes?

An ERP stores the recipe and nets requirements from it, demand minus stock, run through the bill of materials. That's arithmetic on choices you've already made. It never asks whether a different valid recipe, line, or week would cost less. That's the question a solver answers: it searches the valid alternatives and returns the cheapest combination that still meets spec and demand.

Do we need perfect data to get value from this?

No. You need the data you already plan with, recipes, capacities, yields, changeover rules, the constraints your planners already work around. The practical path is to prove it on your real data first, with a focused model of your plant, and see what an optimized plan finds before you commit to anything bigger.

Conclusion

Meeting demand looks like running the recipe, but which recipe, on which line, in which week is a decision with a price tag, and usually one of several valid options. Plan by habit and the plan works. Optimize it and the plan is the cheapest one that works, which isn't the same thing, and the difference is margin going out the door every cycle. The real question was never whether your planners can make the plan work. It's whether your system can prove it's the best one. If you want to see what an optimized plan finds on your own plant, Check Your Fit is a short, no-commitment call to find out.

Recipe Optimization: Advanced Recipe Modeling for Profitability