Fourteen months after the platform went live, a planner at a European parts supplier learned that the vessel carrying her next production run had been dropped from the string. She did not learn it from the platform. She learned it from a forwarder's email, four days after the carrier made the call, attached to a revised ETA that pushed the parts past her line date.
The platform was not broken. Every dashboard in it was green. It had no idea the sailing had changed, because nobody had ever connected the schedule feed that would have told it.
This is the most common way a supply chain orchestration project fails. Not at selection, where most of the scrutiny goes, and not at go-live, which usually happens close enough to plan. It fails across the eighteen months afterward, quietly, while the software keeps reporting that everything is fine. Choosing the platform is the part teams rehearse. Finishing the rollout is the part that decides whether buying it was worth anything.
Why this is biting now
The replanning load has gone up, and it has stopped arriving as discrete events.
In the week to September 10, Drewry's World Container Index held flat at $4,476 per 40ft container for the second consecutive week. Underneath that flat headline the lanes moved in opposite directions: Shanghai to Los Angeles up 2% to $7,352, Shanghai to Rotterdam down 2% to $3,997 (Drewry). Across the major East-West trades, 47 of 729 planned sailings were scheduled to be blanked between weeks 37 and 41 (The Loadstar).
None of that is a crisis, and that is exactly the problem. It is a steady weekly drip of schedule changes and lane-level divergence that a team absorbs by hand whenever the system they bought cannot absorb it for them. A platform that only earns its keep during a headline disruption sits idle most of the year and goes untrusted in the week it matters.
Three gaps account for most stalled rollouts. They are worth checking in this order, because each one makes the next impossible to fix.
Gap one: the data was never made comparable
Most orchestration programs are scoped as a connection project. Count the systems, count the carriers, build the interfaces, done. The connections usually get built. What gets skipped is the part where the data coming through them is made to mean the same thing.
One carrier's "departed" is another's "gate out". Your ERP calls it a delivery number, the forwarder calls it a house bill, the warehouse calls it a receipt. Three systems hold a promised date and no two of them agree on which one is the promise. Until somebody reconciles that, every downstream feature is built on sand: the dashboard aggregates incomparable things, the alert fires on a field that means something different per lane, and the planner learns within a month that the number on screen is not worth acting on. Teams that skip this step end up working around their own data rather than from it, which is how a live platform quietly reverts to a spreadsheet.
This is unglamorous work and it is the whole foundation, which is why it belongs to the vendor rather than to a project team that disbands at go-live. It is the reason Orkestra leads with normalization rather than dashboards: 200+ pre-built connectors across carriers and ERP, TMS and WMS systems, with the mapping to a common model handled on the platform side instead of in a custom integration project your team owns forever. The measure of whether this gap is closed is not how many systems are connected. It is whether one shipment reads identically no matter which system it came from. If you are still wiring systems together by hand, the foundation is not in yet.
Gap two: coverage stops where your partners stop sending
The second gap is the one that produced the blanked sailing nobody saw.
Rollouts are usually scoped around the events that are easy to get: milestone scans from the carriers you already have API keys for, status updates from your own TMS. That covers the happy path well. It leaves out the events that actually change a plan, which tend to originate one step outside your contractual perimeter: a schedule revision from the ocean carrier, a roll notice from the forwarder, a customs hold, a supplier telling your buyer that the ship date moved.
Those events arrive as email, portal notices, and phone calls, and they land in individual inboxes rather than in the system. So the platform's picture of the world stays accurate about things that did not change and blind to the things that did. Around 62% of supply chain exceptions are still detected only after they have hit the customer, and a partial event feed is a reliable way to stay in that majority. The fix is a coverage audit rather than more software: list the last twenty exceptions that hurt, and for each one write down where the first signal actually appeared and how many hours passed before anyone acted on it. That table tells you precisely which feeds are missing, and it is the same discipline behind catching exceptions before they reach the customer.
Gap three: the workflow has no owner
The third gap is not technical, which is why it survives so many technical fixes.
A platform can detect an exception, score it, and route it. It cannot decide that expediting is authorized, that the customer gets told before the plant does, or that the planner on shift has the standing to change a booking without an email chain. When a rollout goes live without those decisions made, the software becomes a very expensive notification service. The alert fires, three people see it, each assumes one of the others owns it, and the resolution still happens in a chat thread that no system ever sees.
Two questions expose this fast. For your last significant exception, who was accountable for resolving it, by name and role? And where was the resolution recorded, such that the next person to hit the same problem could find it? If the honest answers are "several people" and "nowhere", the gap is ownership, not functionality. This is what OIA Global's 60% reduction in exception resolution time in Q1 actually came from: not a new alert, but a defined path from detection to a named owner to a logged outcome, with the coordination running inside the system instead of alongside it.
What to check before you blame the platform
Rollouts that stall rarely announce themselves. They show up as a slow return to the old habits: the planner who checks the carrier portal first, the weekly call that exists to reconcile what the dashboard says, the spreadsheet that quietly comes back.
So audit the three gaps in order, and be concrete about it. Take one shipment and trace every field back to its source, checking whether the same event reads the same way from every system that touched it. Take the last twenty painful exceptions and mark where the first signal appeared and whether it appeared in the platform at all. Take the most recent one and name the person who owned it. Those three exercises take an afternoon and they will tell you whether you have a product problem or an unfinished implementation. Most of these gaps are cheaper to find before you sign, which is what a properly scoped visibility pilot is for. In most cases it is the second, which is better news than it feels like, because the remaining work is bounded and the alternative people usually reach for, a full replatform, is not.
Where the work is genuinely too large to hand to an internal team, the honest answer is that the data layer should not be yours to maintain. That is the split Orkestra is built around: normalized partner data, exception detection, and the resolution workflow running above your ERP, TMS and WMS, with those systems left exactly where they are. The Defense Logistics Agency reached an 83% increase in proof-of-delivery visibility on a four-week deployment, which is roughly the timescale a rollout should be judged on. See how it connects the systems you already run, or book a demo and bring the three answers from the audit with you.
