Assume all three refinery processes run in perfect harmony. The monthly plan is set, the schedule executes it, the mass balance confirms it. Then the tanker carrying next month’s crude gets stuck - in whichever strait happens to make the news that week - and the plan is suddenly fiction. What happens next says more about a refinery’s data architecture than any quiet month ever will.
In Brief
- A refinery’s monthly plan rests on assumptions - crude arriving on schedule, units available; the real question is how fast it can replan when one breaks.
- Replanning is one round trip through the triad: take stock, re-optimise the plan, re-schedule, and keep the mass balance closing.
- The time goes into data logistics, not the solver - collecting tank levels, re-matching stream definitions, re-keying and reconciling by hand.
- On a shared backbone the replanning cycle shrinks from around five days to a single day, because the round trip no longer rebuilds the data every time.
Part of the series, The refinery optimisation triad
- Scheduling in the process industry, explained
- Why refineries count in tonnes: the mass balance, explained
- One data backbone, 25 years (series centrepiece)
- When the crude tanker doesn’t arrive: how fast can a refinery replan? - you are here
The situation
A plan is only as good as its assumptions
A refinery’s monthly plan rests on assumptions: crude arriving on schedule, units available as expected, markets behaving. The schedule translates that plan into transfers and unit programmes, and the mass balance verifies the result. The question is not whether one of the assumptions breaks - shipping delays, unit trips and quality surprises are routine - but how quickly the operation can replan when it does. Because from the moment the tanker stops moving, the schedule is executing a plan that no longer exists.
The task
What does replanning actually involve?
Conceptually, it is simple: find feedstock the old plan never considered - crude available on the market, or crude already sitting in the tanks - and run one round trip through the whole triad:
- Take stock. What is actually available - in the tanks, in transit, on the market?
- Re-optimise the plan. New feedstock options in, new targets out.
- Re-schedule. New movements, new unit programmes, new tank assignments.
- Keep the balance closing. The new plan starts from what is really in the tanks - not from last month’s assumptions.
Where the time goes
A week or a day: what decides the difference?
Not the optimisation - solvers re-run in minutes. The time goes into data logistics: collecting current tank levels and stock positions from several systems, re-matching stream definitions between the planning and the scheduling tool, re-keying results, reconciling by hand what the tools cannot exchange. If every handover between the three processes is a spreadsheet, a replan is a project.
| Processes wired by hand | Processes on a shared backbone | |
|---|---|---|
| Current stocks and positions | Collected manually from several systems | Live in one model, linked at the source |
| Stream definitions | Re-matched per tool, at every replan | Modelled once, including the many-to-one cases |
| Plan-to-schedule handover | Files, exports, re-keying | Flows through the shared model |
| Validation | Manual reconciliation before anyone trusts the new plan | The balance closes against the same model |
That difference is not theoretical. In comparable refinery deployments, replanning cycles have been reduced substantially, in some cases from several days to around one working day.
Integration does not prove its value on quiet days. It proves it on the day the tanker does not arrive.
The lesson travels
Resilience is a data property
The lesson generalises well beyond tankers. Every disruption - a unit trip, an off-spec batch, a sudden order - triggers the same round trip through the triad. And the speed of that round trip is set not by the optimisation tools, but by the layer connecting them: one shared definition of every stream, tank and unit; live values linked at their source instead of copied; the mappings between the three views modelled instead of maintained in spreadsheets. That layer is what turns replanning from a week-long project into a working day - and it is what the longevity of such backbones is really about (One data backbone, 25 years). The boTec DataBridge is built to provide the shared foundation required for trustworthy rescheduling.