Forward-Deployed Engineering · Packaging manufacturing · Production planning
Case study: the weekly schedule, from a spreadsheet to a solver a planner publishes
Illustrative engagement — not a client record. The company, people, volumes and results below are a representative composite, written to show how a forward-deployed engagement runs end to end. The workflow, the architecture, the controls and the method are real and technically valid.
Offering usedReadiness & Scoping SprintTwo weeks inside your systems; one workflow scoped in writing.
Illustrative results, first 90 days after cut-over, in-scope converting orders only:
3.5 hours
Planner time to build and agree the weekly schedule
Before 14 hours over two days
84%
Orders delivered on time and in full
Before 72%
47
Changeover hours per week across nine machines
Before 61
0, checked independently
Published schedules containing a hard-constraint violation
Before not measured
Explainer09 sheets
The whole story in about a minute
Nine short scenes, from Thursday's spreadsheet to the results. Press play, or pick a scene.
View AThursday
Orders dealt out
Around 700 orders a week
- Late, split or short
Sheet01 / 09
ClockBefore
Every Thursday, next week was built by hand.
Two planners dealt around 700 orders a week across nine machines in a spreadsheet, with rules that lived only in the senior planner's head. About seven orders in ten arrived on time and in full.
- 1.Around 700 orders a week
- 2.Nine converting machines
- 3.14 hours to build the week
At a glance
- Client
- A make-to-order corrugated packaging manufacturer: one corrugator, nine converting machines, around 700 customer orders a week, mostly for food and consumer-goods customers
- Workflow
- The weekly converting schedule: orders, machine capacity, changeovers, board availability and promised dates turned into a sequence per machine that a planner edits and publishes
- Engagement
- Readiness & Scoping Sprint (two weeks), then Production Sprint (six weeks, plus three days of paused clock)
- Team
- One named senior forward-deployed engineer, full time. Client side: the Works Manager (owner), two planners, the corrugator supervisor, an ERP analyst, an IT security reviewer
- Where it runs
- The client's own cloud account and region, reading the ERP and the machine-log database. No data retained outside it
- Handover
- Runbook executed by the client's ERP analyst in week six; our access revoked the same day
| Measure | Before | After |
|---|---|---|
| Planner time to build and agree the weekly schedule | 14 hours over two days | 3.5 hours |
| Orders delivered on time and in full | 72% | 84% |
| Changeover hours per week across nine machines | 61 | 47 |
| Published schedules containing a hard-constraint violation | not measured | 0, checked independently |
| Planner questions answered with a traceable cause | not applicable | 88% |
FDE / 01Case study
01 / 12
In shortTwo planners built each week's schedule by hand, from rules that were never written down.
Every Thursday, two planners built next week's schedule in a spreadsheet.
They pulled open orders from the ERP, sorted them by promised date, and dealt them out across nine converting machines: flexo folder-gluers, printer-slotters and die-cutters. Then the real work began. Print colours had to run light to dark to avoid ink washes. Board had to come off the corrugator in the right flute and grade before the converting job could start. A die change on the large die-cutter cost the best part of an hour, so jobs sharing tooling had to sit together. A customer with a weekly collection slot had to be finished by Wednesday, whatever their promised date said.
None of this was written down. It lived with the senior planner, who had been doing it for eleven years.
The cost showed up in four places:
Delivery. Around seven orders in ten arrived on time and in full. The rest were late, split, or shipped short with the balance to follow.
Changeovers. Nobody could say how many hours a week went into changeovers, only that Friday's plan always had fewer than Monday's reality.
Fragility. When the senior planner took leave, the schedule was built more conservatively and output fell.
Argument. Sales asked "why is this order late?" and the honest answer was a story, not a reason.
FDE / 02Case study
02 / 12
In shortScheduling software had been tried before, but it did not know the plant and was dropped.
Five years earlier the company had bought the scheduling module that came with its ERP. It was configured, trained on, and abandoned within four months. The reasons are the ones this kind of project usually fails for:
The master data did not describe the plant. Routing times were standard values entered when the machines were installed. On several machines the real run rate differed by up to 40%, in both directions, depending on flute, board grade and the number of print colours.
The changeover rules were not in any system. The module sequenced by due date. Its schedules made ink washes and die changes nobody would run.
It could not explain itself. When a planner disagreed, there was nothing to interrogate. It was a black box that produced a worse plan than the spreadsheet.
It replanned constantly. Every ERP change reshuffled jobs already set up on the floor. The supervisors stopped reading it, and then so did the planners.
The lesson the company drew was "scheduling software does not work here". The lesson available was narrower: a solver is only as good as its routing times, its changeover rules and its ability to be argued with.
FDE / 03Case study
03 / 12
In shortTen days with the planners, the floor and the machine logs, ending in a signed one-page scope.
Ten working days: four with the planners, two with the machine supervisors on the floor, one with the corrugator supervisor, and the rest in the ERP and the machine logs.
What was found:
FIG. 3.1- The machine logs were the answer to the routing problem. Eighteen months of start, stop and counter records existed. Real run rates could be measured per machine, flute, grade and colour count, rather than assumed.
- The changeover matrix could be written down in a day. It had never been asked for. The senior planner and two supervisors produced it in one session, and the arguments in that session were themselves findings.
- Promised dates and requested dates were the same field. Sales entered what the customer asked for. Nothing recorded what the plant had committed to.
- A false assumption, found on day three. The sponsor expected the solver to schedule the corrugator too. The corrugator is scheduled daily by its own supervisor, optimising trim waste across combined orders — a different problem with a different objective. It was put out of scope, and its output became an input instead.
- Board availability was wrong in the ERP because partly used reels were not booked back. The planners already knew; they kept a second list.
The one-page scope, signed by the Works Manager:
- WorkflowThe weekly finite-capacity schedule for the nine converting machines, from open ERP orders to a published sequence per machine
- Out of scopeThe corrugator's own daily trim plan, reel purchasing, despatch and vehicle loading, promising dates to customers at order entry
- MetricPlanner time to build and agree the weekly schedule, and orders delivered on time and in full, with zero hard-constraint violations in anything published
- OwnerWorks Manager
- GuardrailsThe solver respects hard constraints; the language model never edits a schedule; a schedule is published by a planner, and it is the planner's schedule
- Exit gateTwo weeks of parallel running against the spreadsheet, one week live with the spreadsheet on standby, runbook executed by the client's analyst
The scope also recorded what the two weeks could not settle: whether the learned run rates would hold, which is what week three of the build then tested.
Timeline09 stations
The engagement, stage by stage
Nine stages on one clock, from the Thursday spreadsheet to ninety days after cut-over. Press play, or pick a stage.
LineStopped
StationOP 10 Thursday
ClockBefore
Work instructionOP 10 · 01 / 09
Every Thursday, next week was built by hand.
Two planners dealt around 700 orders a week across nine machines in a spreadsheet, with rules that lived only in the senior planner's head. About seven orders in ten arrived on time and in full.
- Around 700 orders a week
- Nine converting machines
- 14 hours to build the week
FDE / 04Case study
04 / 12
In shortSix weeks: connect the data, build the solver, replay real weeks, run it side by side, hand it over.
plus three days of paused clock
W0Scope
What happened
Scope signed; access requested for the ERP read replica, the machine-log database and the client's cloud account
What existed at the end
The signed scope and an access checklist
What happened
Scope signed; access requested for the ERP read replica, the machine-log database and the client's cloud account
What existed at the end
The signed scope and an access checklist
What happened
Repository created in the client's source control; engineer in the Thursday planning session. First pull request merged on day seven: orders, routings, calendars and machine logs landing in the client's account
What existed at the end
A data layer, and a first measurement of real run rates
What happened
A first solver model behind a feature flag, with hard constraints only. Golden set agreed: twenty-six historical weeks to replay, and the planners' own questions
What existed at the end
A prototype producing a feasible schedule, and a golden set
What happened
Changeover matrix encoded and signed. Objective weights set with the Works Manager. The replay found the run-rate problem (section 6). Planner interface: view, edit, compare, publish. Explanation layer with its tools
What existed at the end
A system building schedules a planner could edit, and an independent constraint checker
What happened
Two weeks of parallel running began: the system built the schedule, the planners built theirs, and the two were compared on Thursday
What existed at the end
Real schedules, compared side by side
What happened
First live week published from the system. The analyst performed a release, a rollback and a weight change without us at the keyboard
What existed at the end
Signed runbook, decision record, revoked access
plus three days of paused clock
Calendar time was six weeks and three days. The three days were in week two: the senior planner was pulled onto a customer audit and the golden set could not be agreed without her. The clock paused, in writing, the day it happened.
FDE / 05Case study
05 / 12
In shortA solver proposes the schedule, a model explains it, and a planner edits and publishes it.
Try a week07 ops
Pick what happens this week. Watch where the schedule goes.
The same system builds every schedule. What happens decides whether it is published or goes back to the planner.
Published
Schedule published
The planner published it, and it is the planner's schedule. The checker passed every hard constraint.
The data layer. Orders and promised dates from the ERP; run rates measured from eighteen months of machine logs, as a median per machine, flute, grade and colour count, each reviewed by the supervisor of that machine; shift calendars and planned maintenance windows; board availability from the corrugator's own plan; and the changeover matrix, kept as a signed, editable document rather than as code.
The solver. A constraint-programming model, deterministic, with a fixed seed, so the same inputs give the same schedule. Hard constraints are hard: machine eligibility, one job at a time, shift calendars and maintenance windows, board not available before its corrugator date, tooling that cannot be on two machines at once, and a frozen horizon — the first 48 hours of the current schedule cannot be moved by a re-solve. Everything else is in the objective, weighted and visible: lateness against promised dates, changeover time, and a small preference for keeping jobs where the planner last put them, which is what stops the schedule from thrashing.
The explanation layer. A language model sits beside the solver, not inside it. It answers planners' questions — "why is order 4471 on Thursday and not Tuesday?", "what would it take to pull this forward?" — by calling tools: read the schedule, read the solver's trace, compute the binding constraint for an order, compare two schedules, or run a scenario. A scenario is a real solver run in a sandbox with the planner's change applied; the answer describes what the solver returned. When a request is infeasible, the solver reports the conflicting constraints and the layer puts that in plain words.
Two rules bound it. First, every number and every order reference in an answer must appear in a tool result; a checker verifies this before the answer is shown, and withholds it if not. Second, the layer has no write path to any schedule. It can prepare a scenario for the planner to look at. It cannot move a job.
The planner interface. The planner sees the proposed schedule beside the current one, with the differences listed. They drag jobs, pin jobs, force a sequence, or re-solve with a change. Every edit is theirs and is recorded with their name.
Publishing. The planner publishes. Before anything leaves, an independent constraint checker — written separately from the solver, on purpose — re-verifies every hard constraint on the final schedule, including the planner's manual edits. A schedule that fails the check cannot be published, and it says which constraint failed. Publishing writes the sequence to the ERP and the shop-floor screens under the planner's user.
System map19 objects
How the pieces connect
Every part of the system and of the story, lit one scene at a time. Press play, or pick an event.
Graph01 / 09
Description
Every Thursday, next week was built by hand.
Two planners dealt around 700 orders a week across nine machines in a spreadsheet, with rules that lived only in the senior planner's head. About seven orders in ten arrived on time and in full.
FDE / 06Case study
06 / 12
In shortTwenty-six real weeks replayed and 300 planner questions, checked on every build.
The golden set had two halves, because the system has two halves.
For the solver: twenty-six weeks replayed. Each historical week's real orders, capacity and materials were fed in, and three things were measured: the checker's verdict on feasibility, total weighted lateness, and changeover hours, compared with what the plant actually ran that week. Feasibility was pass or fail. The other two were compared, not scored against a target, because the historical weeks were not optimal either.
That replay is what caught the sprint's worst moment. In week three the solver produced schedules that looked 20% better than the planners' on both measures. The senior planner read one and said the Tuesday shift could not run it. She was right. The model was still using the ERP's standard routing times for four machines whose machine-log data had failed a sanity check and been quietly skipped by an import job. On those machines the solver believed jobs took less time than they do. The import failure was silent; the replay made it loud. Run rates were re-measured, reviewed machine by machine with the supervisors, and the import now fails the build rather than skipping a machine.
For the explanation layer: 300 planner questions. Real questions from the planners and from sales, with answers written by the planners from the solver's own output. Scored on whether the binding cause was right and whether every number was exact. A red-team slice asked it to do things it must not do: "move 4471 to Monday" (it must offer a scenario, not an edit), "which orders can I promise for next Friday?" (out of scope: promising is not this workflow), questions about orders that do not exist, and leading questions that assert a false cause.
The harness runs in the client's pipeline. A drop on either half fails the build.
- IF A drop on either halfBLOCKS
fails the build
FDE / 07Case study
07 / 12
In shortIt runs in the client's own cloud, and only a planner can publish a schedule.
Perimeter. Everything runs in the client's cloud account and region. The language model is reached through a private endpoint in the same region with no data retention. Customer order data does not leave.
Identity. Reads are through a read replica. The only write is the published schedule, made as the planner who published it. Our engineer's access went through the client's identity provider and was revoked at handover.
Autonomy is bounded, and this is the whole design. The solver decides sequence within hard constraints it cannot break. The language model reads, explains and prepares scenarios; it never edits or publishes a schedule. The planner edits and publishes. The independent checker has a veto over both.
Nothing is published without a person. There is no automatic republish on an ERP change. When orders change, the planner sees a flagged difference and decides.
Review. The IT security reviewer approved the design in week two and the deployment in week five; findings and closures are in the decision record.
FDE / 08Case study
08 / 12
In shortTwo Thursdays side by side with the spreadsheet, then a live week with it on standby.
Parallel running was the gate. For two Thursdays the planners built their spreadsheet as usual while the system built its schedule, and the two were compared in the room: lateness, changeover hours, and every job the planners would have placed differently.
That third pile was the valuable one. Some differences were rules still missing from the matrix — one die-cutter cannot run two heavy grades back to back because the stacker jams. Some were habits worth keeping and now encoded. Some were habits worth dropping, and the planners said so themselves once they could see the cost of each in hours.
The first live week was published from the system with the spreadsheet on standby and the senior planner's finger over it. Rollback was one flag that returned the week to the spreadsheet process. It was rehearsed in week five and never used.
FDE / 09Case study
09 / 12
In shortThe client's analyst proved they could run and change it before we left.
In the dry run the analyst added a machine, re-measured its run rates, released the change, rolled it back and published a schedule. The runbook was signed after that, not before.
Key numbers09 gauges
The story in nine numbers
One number for each scene, from 72% on time to 3.5 hours of planning. Press play, or pick a number.
ClusterStopped
ChannelOP 10 Thursday
ClockBefore
DialOP 10
72%
ClockBefore
Face01 / 09
Every Thursday
ReadoutOP 10
Every Thursday, next week was built by hand.
Two planners dealt around 700 orders a week across nine machines in a spreadsheet, with rules that lived only in the senior planner's head. About seven orders in ten arrived on time and in full.
Signals
Around 700 orders a weekNine converting machines14 hours to build the weekFDE / 10Case study
10 / 12
In shortIllustrative: planning time from about 14 hours to 3.5, and more orders on time and in full.
Figures are illustrative, measured on in-scope converting orders over the first 90 days after cut-over.
Building and agreeing the weekly schedule fell from about 14 hours to 3.5. The planners now spend that time on the exceptions and on customers.
On-time-in-full rose from 72% to 84%. Roughly half of the gain came from respecting board availability dates properly, which the spreadsheet could only approximate.
BEFORE72%AFTER84%Changeover hours fell from about 61 a week to 47, without anyone being asked to work faster: the same jobs, in a better order.
No published schedule contained a hard-constraint violation, because the independent checker will not publish one, including after a planner's manual edits.
88% of planner and sales questions got a traceable cause. The remainder are answered "I cannot tell you from the schedule", which the planners preferred to a plausible guess.
AFTER88%Nobody left planning. The second planner now runs the scenario work that sales had been asking for and never got.
What did not improve, and was never promised:
FIG. 10.2Trim waste on the corrugator is unchanged. It was out of scope on day three of scoping, and the scope page said so.
Rush orders inserted mid-week are as frequent as they ever were. The system makes their cost visible — the planner can see what a Tuesday insert does to four other orders — but it does not change how sales behaves.
Late reel deliveries from suppliers still break weeks. The schedule now moves around them faster; it cannot conjure board.
FDE / 11Case study
11 / 12
In shortSix rules for anyone putting a solver on a real production schedule.
- Measure your run times before you buy a solver.
Standard routing times are the commonest reason these systems are switched off, and your machine logs already hold the real ones.
- Write the changeover matrix down.
It takes an afternoon and an argument, and it is worth more than the optimiser.
- Keep the model out of the schedule.
Let it explain, compare and prepare scenarios. The plan stays the planner's, and that is why they use it.
- Check the output with something you did not write.
A separate constraint checker catches solver mistakes and planner mistakes with the same rule.
- Freeze the near horizon.
A schedule that reshuffles jobs already set up loses the floor's trust in one week.
- Replay real history before you trust anything.
Our worst week was a silent import failure, and only the replay made it visible.
FDE / 12Case study
12 / 12
In shortThe planners extended the weights themselves for a seasonal peak, and a second sprint is now scoped.
The planners extended the objective weights themselves for a seasonal peak, using the runbook. Sales, having watched the scenario tool answer "when can we have it?" for schedules that already exist, asked for the same question at order entry. That is promising dates, which was explicitly out of scope, and it is now scoped as a second Production Sprint.