Pulp and Paper Mill Production Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the objective get scoped as minimise trim?

Because trim is the number the mill already reports. It appears in the monthly pack as a percentage, everybody recognises it, and it makes a clean project justification. So the specification says minimise trim loss, and a competent developer builds exactly that.

Trim optimisation is a cutting stock problem and the mathematics is well understood. What makes a mill schedule hard is that the cutting problem is coupled to the sequencing problem. Combining orders to fill a deckle better may cross a basis weight, a coating or a colour, and every transition has a cost in broke, time and off specification tonnes. A planner who optimises trim in isolation can build a week with the best trim figure of the year and worse economics than the spreadsheet produced.

The correction is to express the objective in money rather than in millimetres. Trim loss, grade change cost, earliness and lateness against the order due date, and the cost of overproduction against tolerance all become terms in one objective. The planner then evaluates real alternatives in minutes: this set carries forty millimetres more trim and avoids a basis weight change, and here is the difference in euros.

That comparison is impossible today, which is exactly why mills accept whatever the spreadsheet produces. Ask any prospective developer what they would optimise before anything else. If the answer is minimise trim, they will build something the mill cannot run.

What goes wrong with order book and constraint data?

The order book usually comes out of the enterprise resource planning (ERP) system in reasonable shape, and that gives false confidence, because the data that determines whether a schedule is runnable is not in the ERP at all.

Real constraints are messy and specific. Maximum number of knives on the winder. Minimum roll width the winder handles reliably. Maximum set count. Roll diameter limits at particular customers. Which accounts accept a splice and which do not. Which orders can share a set because they share a core size. Whether the sheeter downstream takes a certain width without a changeover. Which orders go to a converting plant you own, where you control the downstream schedule too.

None of that has a field anywhere. It lives with the planner and with two people on the winder, and it is discovered during the build one objection at a time.

The failure that follows is staleness. A constraint set captured once, hard coded and maintained by a vendor is wrong within a year, because knives get changed, a customer relaxes a splice rule and a new core size arrives. A stale constraint set produces schedules the crew quietly ignores, and that is the most common way optimisation projects die: not with a rejection, with a drift.

Model the constraint set completely, including the awkward ones, as data the planning team can edit themselves. That is more important than the mathematics. Then treat every objection during the parallel run as a missing constraint to be captured rather than as resistance, because each one is a rule nobody wrote down.

Why do ERP and quality system feeds break after launch?

Because they are owned by other people on other schedules. The ERP gets upgraded and an order field changes shape. A new grade code is introduced by the commercial team and nothing in the planning model recognises it. The quality control system, whether it is a Honeywell, ABB or Valmet installation, is serviced during a shut and tag names move. A converting site changes how it books demand.

The characteristic mill failure is a new product code arriving in the order book with no constraint mapping. The optimiser either refuses to schedule it, which the planner works around manually and never mentions, or schedules it against defaults that are wrong for the grade. Both outcomes erode trust and neither raises an alarm.

Build for that specifically. Validate incoming orders against the constraint model on arrival and quarantine anything with an unrecognised grade, width, core or customer rule, with a queue somebody clears each morning. A quarantine queue is a working control, not a defect.

Then monitor for silence as well as error. An order feed that stops looks like a quiet week in the order book, and a planner scheduling against a stale book will fill the machine with the wrong work. Version the parser per source, keep a stored sample as a contract test so a layout change fails loudly, and reconcile counts daily between the ERP and what landed.

What happens when tolerance and customer rules are not covered?

Tolerance gets used accidentally instead of deliberately, which is the same as not using it. Most paper and board orders carry a delivery tolerance agreed with the customer, commonly around plus or minus ten percent. That tolerance is an optimisation asset: producing slightly over on one order can enable a set with far better trim, and producing slightly under can avoid a grade change entirely.

Because tolerance is treated as a contractual footnote rather than a variable, it never enters the model. Planners flex it by instinct when they notice an opportunity, sales find out afterwards when a customer calls about an over delivery, and the relationship pays for a saving nobody recorded.

Carry the tolerance per order line as a real bound in the optimiser, with a customer specific policy, because some accounts genuinely will not accept over delivery and others are delighted with it. Then report which orders were flexed and by how much, so the commercial team is informed rather than surprised. That reporting is what makes the feature politically survivable inside the mill.

The same applies to the rest of the customer rules. Splice acceptance, diameter limits, packaging and marking requirements all constrain which orders can share a set, and a system that models the machine perfectly while ignoring the customer will still produce schedules the mill has to unpick by hand.

Should you build custom or configure what you already own?

Buy Greycon opt-Studio if your problem is squarely trim optimisation, your constraint set is conventional, and you want a proven specialist product supported by people who know the industry. It is a real product solving a real problem and for many mills it is simply the correct answer. Do not build around a tool you have not first tried to configure properly.

Buy from your automation supplier if the actual gap is production reporting and quality data rather than planning. ABB, Honeywell and Valmet cover that ground properly and a planning project will not fix a measurement problem.

The build case appears when the workarounds around the specialist tool cost more than the benefit inside it. Typically that means your converting rules, tolerance policy or order intake habits sit outside its model, so the planner still works manually on both sides. It also appears when trim and grade sequencing genuinely need to be solved together against a money objective, when you own converting and want the mill and the plant scheduled as one system, when you allocate orders across several machines by habit, or when you cannot answer how much of last month's trim was avoidable.

The threshold is order book variety rather than tonnage. A mill running long campaigns of a few standard widths is already near its trim floor and should spend the money on machine reliability or quality variability instead. If your planner spends an hour a week building sets rather than a day, the return will not justify the project.

How do hidden costs get into the quote?

• Machine count. Allocating orders between machines is a materially harder problem than single machine trim, and quotes rarely distinguish the two.
• Owned converting. Scheduling the mill and the converting plant together is the right answer eventually and roughly doubles the model. It belongs in phase two, priced as phase two.
• Grade structure. How many basis weights, coatings and colours run, and how constrained the transitions are between them. This drives engine complexity more than deckle width does.
• ERP depth. Reading the order book is one thing. Giving order promising back to the sales system is another project.
• Quality and production linkage. If actual production, breaks and off specification tonnes are to feed re planning automatically, that is live integration rather than a nightly file.
• Planner time. Weeks of parallel running by the person the mill can least spare, which is almost never in the plan.

What separates a build that works from one that fails here?

The builds that work make re planning cheap enough to do daily. Orders arrive and cancel through the week, a break wipes hours from the plan, and a pulp quality problem forces a grade off the schedule. If a rebuild takes an afternoon, re planning happens as rarely as the planner can get away with and the schedule drifts further from optimal every day. If it takes minutes, the plan tracks reality.

They treat stability as an objective rather than an afterthought. A schedule that changes every hour is worse than a slightly suboptimal one the crew trusts, so there is a tunable penalty for churn and a clear view of what changed and why between two versions of a plan. Optimisers that produce a completely different schedule on every run get switched off within a month, and the reason given is never the real one.

They score the plan afterwards. Store every plan with its objective breakdown, compare it to what actually ran, and report trim, grade change count and tolerance usage against a computed best possible for that week's order book. That separates structurally unavoidable loss from sets built under time pressure and from orders accepted at widths that combine badly with everything else. In our delivery experience this reporting changes commercial behaviour more than the optimiser changes the machine, because sales finally sees what an awkward width costs.

They keep the reasoning visible. Trust arrives when the system reproduces a schedule the planner would have built and then shows a better alternative with the logic exposed. Hiding the reasoning is the fastest way to lose the crew, and once lost it does not come back in that installation.

And they settle ownership before kickoff: the repository, the infrastructure and the right to hire anyone else to continue. At Digital Heroes the code is yours from the first commit. The constraint model encodes years of knowledge about your machine, your winder and your customers, and it should never live somewhere you cannot take it.