Supply chain visibility that survives a bad week

A supply chain dashboard has a demonstration problem. It gets built and shown during a normal week, when the feeds are running, the vessels are moving and every tile is green. It gets signed off on the strength of that. The week it has to earn its cost is the week a port closes, a carrier stops answering its API, and a third of the numbers on screen are eleven hours old with nothing on the page to say so.

We built demand and inventory forecasting for a manufacturing group, integrated with their ERP and supply chain systems, aimed at delays and carrying cost together. The models were the straightforward part. The decisions that mattered were about what the system does when its inputs stop behaving.

Stale data has to look stale

The most dangerous state in a visibility system is a value that is wrong in a plausible way. A tile showing a shipment at sea, fed by a connection that died yesterday afternoon, is worse than a tile showing nothing, because somebody will plan around it and the plan will look sound. Every value on the screen needs its own freshness, visible without being asked for, and a rule for what happens when freshness exceeds tolerance.

We show the timestamp beside the value and grey the tile out when a feed misses its window. Planners disliked it for about a fortnight, on the reasonable grounds that the screen used to look better. Then a customs delay came through as a gap rather than as a confident number, and the argument ended.

Forecasts are trained on good weeks

A demand model learns from history, and history is mostly normal. The weeks that matter are structurally different from the ones in the training data, so a model that has been accurate for two years will be confidently wrong during a disruption, with nothing in its output to indicate the change. Publish the interval alongside the point forecast, and make the interval widen when inputs go missing. A forecast that reports its own uncertainty gets used as a forecast. One that reports a single number gets used as a fact.

The exception queue is the product

Nobody watches a dashboard. They watch it for the first month and then they stop, because a screen where everything is normal teaches people that looking at it wastes time. What gets used daily is the exception queue: an ordered list of the things that need a decision, each with its reason, its options and its deadline attached.

That reframes the build. Visibility is the input. The output is a short list of decisions, ranked by cost of delay, in front of somebody with the authority to act on them. A system that produces two hundred exceptions on a bad Monday has produced nothing, because the planner will work down the list in the order it happens to be sorted and run out of day.

Manual override, designed rather than tolerated

During a real disruption the authoritative information arrives by telephone. A planner hears from a carrier that a vessel will berth on Thursday two hours before any system knows it. With no way to put that into the platform, the planner opens a spreadsheet, and from that moment the platform is describing a world that has stopped existing.

So the override is a first-class feature: a way to record a fact ahead of the feed, attributed to a person, timestamped, given an expiry, and reconciled against the feed when it catches up. It is dull work, it never appears in a sales demonstration, and it is what keeps the system in use during the week it was bought for.

The test we now run before sign-off is a specific one. Turn off two feeds at random, delay a third by nine hours, and put a planner in front of the screen. If they can still say which shipments are at risk and what to do about them before lunch, the system will hold. If the demonstration only works with every input healthy, what has been built is a report.