It's all one problem. Eleven years of learning that.
Really? People study this?
That was my reaction, eleven years ago, to the first research paper I found on trim loss. I had been sitting with corrugator schedulers for a few months, asking about the math, trying to see if there were ways to improve. I didn't understand how the knives and slitters worked. I understood even less of the paper. But the question it raised stuck and never left: why wouldn't you just run it as a one-dimensional problem and only cut the sheets you need?
I'd started with the part I could hold — cutting stock, one dimension, in Excel. First-fit decreasing by hand, then the Solver add-in, reading the help page on GRG versus simplex versus evolutionary to figure out which one gave a global minimum. That spreadsheet taught me what a global minimum was. It also taught me I was doing geometry without knowing it.
The answer to the question took years to land. If you cut exactly what you need, you leave partial bales all over the plant. A unit is a physical thing. Nobody wants it on their floor, nobody wants to store it, nobody wants to absorb the cost, and if you're early or late with it the logistics are a nightmare. So you cut inside a window — ten percent either way — and you build the schedule so an order finishes close together, on two patterns at most. That window is where the math meets the forklift.
Mostly I watched. I kept thinking, isn't this just math? It is. But planners had customers to call and a plant to answer to. There were hot orders, elevated cases, somebody on the phone asking "can we move this up?" The math doesn't go away when that happens. It stops being the only thing in the room.
Later I installed OMP as a forward-deployed engineer and trained front-line staff. The install was fine. The thing I actually learned was that manufacturing teams are hard to win over, and they should be. You develop trust before anyone reads your report. Then you operate next to them and listen to the complaints, because the complaints are where the model is wrong.
Trim is generally a corrugator's largest waste percentage. When it came down a quarter of a point, people were happy. That's when "cost of board" became a number to me — not from a book, from a waste committee and the supply chain team.
I got to suggest mill roll widths. The decision belonged to supply chain, but I could propose, and when I gave the mill widths that fit the corrugators, the mill's trim went down. A sales guy had told me early on: in this business, the mill is king. He meant that's where the money is. What I eventually saw was that the mill cuts reels into roll widths and the plants cut roll widths into orders, and the width catalog is the hinge between two cutting problems. Most people only ever stand on one side of it.
What I got wrong first was the waste. I thought trim was the schedule's problem. It's the whole chain's.
A pattern is a web width, up to three orders on the three knives, and the outs of each. A CI is a pattern plus a run length. A schedule is a list of CIs. That's the whole object. For fifteen orders of one grade there are somewhere between a hundred thousand and a million feasible patterns before a single run length is chosen. You prune in order: the cheap physics first — used width can't exceed the web; trim can't exceed seven inches a side or the chute jams — and the expensive checks, like whether the score lines fit on three shafts two inches apart, only on what survives.
One grade partition, every schema it could run, and where each one dies
The pruning ladder
The 2-D map: web width × used width
Selected schedule
Run the schedule lineal feet along the machine · web centered · each rectangle is one sheet off its HQM knife · solid lines are slits, dashed are scores, orange across the web is the shear at an order change · scroll to zoom, drag to pan
The orders in this partition
What this is and isn't. The enumeration, the chute band, the shaft bound, the dedup and the scores are the real gates from the scheduling-math ladder (L1–L5), with the machine constants from the plant-truth ledger; the speed model is the measured web-band curve, the short-cutoff haircut and the spread cliff. The master is a greedy cover of the ±10% window, sequenced widest-web-first, standing in for the CBC MIP with Dinkelbach the engine runs, so the schedule is good, not certified optimal. Run lengths follow the engine's L7 bound, r̄ = min over the schema's orders of 1.1·q / sheets-per-foot, and an order that can't be covered is listed, never dropped silently.
Every rule is one of two kinds. Physics: one grade per CI, the chute, the shafts, one order per knife. Those are removed from the space, never penalized. Liberties: the window, setups, short cutoffs. Those are priced or bounded, never forbidden. I used to call the second kind slack, which isn't quite it — slack is what's left in a constraint at a solution; a liberty is the decision you make up front about which rules are walls and which are prices. When a planner says "we can't run that," the first thing to find out is which kind of can't. Score depth sounds like physics and is usually a customer preference. Whether die-cuts get scored on the corrugator sounds like a fact and is, as far as I can tell, an open question.
The part that changed how I see it. In Excel I picked a pattern, ran it, subtracted the sheets, picked the next. That can never prove it's optimal, because each choice was made before the later ones were known. The master problem subtracts nothing. Every run length is an unknown, and every order is one row — feet run on every pattern that carries it, times sheets per foot, inside the window. All at once. A pattern that helps one order and overfills another is pushed and pulled by both rows at the same time. A loop can't see that. It's all one problem.
And the solver knows when it's done. It carries the best plan found and a bound on the best possible, and when they meet, that's proof. When the clock runs out first, it tells you the gap. No loop can say "within two percent of the best possible." That sentence is the reason to leave the spreadsheet.
The objective is useful MSF per hour, and the ratio was the part I struggled with most. A linear solver maximizes sums of constant-times-variable. MSF is one. Hours is one. Their ratio isn't — double every run length and the ratio doesn't move, which nothing linear can do. So you hand the solver "MSF minus λ times hours" for a guessed λ, set λ to the rate you got, and go again. Three or four rounds. Which is what a scheduler does: "I think this pool can do 280." Build it. It did 290. "Okay, 290." Can't beat it. Done.
The ratio is why ten or fifteen feet a minute matters. A short cutoff haircuts a whole pattern's speed by a quarter. An extra inch of trim on a 110-inch web is under one percent of the paper. A fixed-MSF objective packs the web and eats the slow cutoff. The ratio sees the hours and takes the inch. You sometimes eat an inch of trim to keep the gator humming between orders. Nobody wrote that rule. It's what the ratio does.
The master hands you a bag of CIs, not an order. A CI change is a dry-end setup — the shear, the knives, the scorer. A web change means new rolls on the stands. A flute change means a module facer swap and the only transition that actually stops the machine. So: minimize changes. Group by web. Wide to narrow, because stepping up costs about three times stepping down. Sequence the flute transitions in and out so one facer preps while the other runs. Everyone wants wide. The order mix doesn't always allow it.
If you can run a full roll, you run it. If not, half and splice to the other arm. What you're really doing is bringing the rolls that cause the fewest trips on a clamp truck, because every butt roll is a trip back, a storage spot, and a roll handled twice. The sequence that's right for the wet end is usually the one that's right for the forklift.
Due dates fight all of it. Earliest deadline first is provably optimal for one machine with no setup cost, and the moment setups cost something, it's at war with web grouping. A hot order on the narrow web wants to run now; the web wants to run last. So you price both — speed lost at boundaries plus weighted lateness — and let the solver say whether the step-up is worth it for this order. Sometimes it is. Sometimes you call the customer. The point is to say yes when the number says yes, and to be able to show the number.
On-time delivery is by order. If you're behind, and it happens, the customer comes first and there's probably overtime. Monday morning it's downtime, waste, speed. None of the three proves anything alone. Together they're directionally accurate, and that's enough to know where to walk.
One thing my engine gets different from the plant: a released schedule is an immutable record in the engine. In a plant you just insert the order — downloads are dry-end setups; the wet end only changes at a quality change. The plant is right. The engine should let you insert, and keep the record of what was released versus what ran. It's on the list.
If a 25-year-old data engineer asked me what to learn, I'd still say SQL. Data structures matter, and SQL is the step anyone can take to shape and clean what's in front of them — and you'll be shaping and cleaning before any of the above is possible. Excel is a tool. Good for some things, not for others. You'll run into it regardless.
And I'd tell them it's going to take longer than they think, and that's not a failure. The papers are right that it's math. The floor is right that it isn't only math. You'll spend a while not understanding either one, and then a while understanding one and not the other. The people on the floor will be patient with you if you're honest about which stage you're in. That's most of it.