A planner in Chicago opened three tabs last Tuesday to answer one question from a customer: where is PO 44817. The ERP said delivered. The TMS said in transit, two days late. The WMS had no record of a receipt at all. Nobody was lying. The ERP had closed the order when the invoice posted, the TMS was tracking a second leg that had been added after a port omission, and the WMS was waiting on a putaway scan that had not happened yet. Three systems, three defensible answers, one shipment. It took forty minutes and two phone calls to find out the pallets were on a dock in Joliet.
Volume is about to make this expensive
That kind of reconciliation is survivable in a quiet month. September 2026 is not a quiet month. The Global Port Tracker report from the National Retail Federation and Hackett Associates now puts September at 2.31 million TEU, up 9.6 percent year over year and narrowly ahead of July as the busiest import month of the year, after an early peak season refused to wind down.
The volume is arriving into a network that is already re-planning itself. Typhoon season has left North Asia carrying the majority of global port congestion, with berth waits at Shanghai and Ningbo measured in days rather than hours, and carriers are omitting calls to claw back schedule reliability. Every omitted call rewrites a routing. Every rewritten routing creates another record that your systems have to agree about.
Most teams read that as an integration problem and go looking for connectors. Integration moves the data. It does not make the data mean the same thing on both sides, which is why system silos keep breaking visibility even in operations that have already connected everything. What decides whether your systems agree is the data model underneath them.
Define the entities before you design the dashboard
A supply chain data model is a short list of things your business tracks and one written definition for each. Five entities cover most operations: the order, the shipment, the leg, the handling unit, and the exception.
The definitions sound obvious until you write them down. Is a shipment the booking, or the physical consignment that moves? If a consolidation splits across two containers, is that one shipment or two? When an order ships in three releases, does the order close on the first delivery or the last? Ask four people in your operation and you will get four answers, which is exactly why the report they each build comes out different.
Write one definition per entity, name the system that owns it, and hold everything else to it. This is the part Orkestra's data normalization layer is doing when it maps a carrier milestone, an ERP order line and a WMS receipt into a single shipment record: not moving fields around, but deciding what a shipment is so that every downstream number counts the same population, and so the same metric can be compared across regions without an analyst reconciling it first. Bridgestone's team put normalized data behind their production planning and alerting and took $11.6K in weekly savings out of 22 shipments, which is the kind of return that only shows up once the underlying records stop arguing with each other.
Pick keys that survive a handoff
The second decision is which identifiers hold the model together, and it is the one most models get wrong.
A single physical movement collects a new identity at every handoff. It starts as a purchase order, becomes a sales order, picks up a booking number at the forwarder, a bill of lading at the carrier, a container number at the terminal, and a PRO number on the final leg. None of these is the identifier. All of them are.
So model the crosswalk explicitly. Keep an identifier table that records every alias a movement has carried, which party issued it, and when it came into use. Never overwrite one identifier with the next, because the moment you do, the history before that handoff becomes unreachable and your cycle-time measurements quietly start at the wrong point. This is also what makes a genuine end-to-end view possible rather than a stitched one, and it is the foundation under any attempt to connect your ERP, TMS and WMS without replacing them.
Record events, not statuses
A status field holds one value. When the next update arrives, the previous one is gone.
That is fine for a screen and useless for everything else. If a shipment went from in transit to delayed to in transit again, the status field will end the week reading in transit and the delay will have left no trace. You cannot measure, root-cause or improve something you overwrote.
Model milestones as an append-only event log instead: what happened, when it happened, which source reported it, and when you received it. Derive the current status from the log rather than storing it. Two properties come free. You get the full history of every movement for analysis, and you get the reporting lag, the gap between when something happened and when you found out, which is usually the number that actually explains why your team is reacting late. It is also what separates KPIs that change a decision from KPIs that report a verdict.
Name the authoritative timestamp for each milestone
Every milestone has several times attached to it: planned, promised, estimated, actual. Every one of those can come from more than one source. A vessel arrival can be the carrier's ETA, the terminal's berth record, or the AIS position. A delivery can be the driver's scan, the carrier's EDI 214, or the customer's receipt confirmation.
Pick one authoritative source per milestone, write down why, and keep the others alongside it rather than discarding them. The alternatives are what let you measure each source's accuracy over time, which is how a team gets from complaining about carrier ETAs to actually improving ETA accuracy across carriers. A model that keeps only the winning timestamp cannot ever tell you that a particular carrier's estimates run eleven hours optimistic on transpacific lanes.
Make the exception a first-class entity
Most operations treat exceptions as an alerting configuration rather than part of the data model, and it shows. Alerts fire, someone reads them, and there is no record of what type of problem it was, who owned it, what they did, or how long it took.
Give the exception the same treatment as the shipment. A type drawn from a fixed list, a severity, an owner, a timestamp for detection and one for resolution. Do that and the exception log becomes the most valuable table you have, because it tells you which failures repeat and where. Without it, you are left with the industry's default position, where 62 percent of exceptions are only detected after the customer has already felt them. A command center like Orkestra can only prioritise and route an exception because the exception is a typed, owned record rather than an email, and every resolution it captures feeds the pattern that prevents the next one. We covered the operational side of this in catching exceptions before customer impact.
Decide in advance who wins a disagreement
Two sources will contradict each other. The carrier will report delivered while the WMS has no receipt. Write the precedence rule into the model before it happens: which source wins for which field, whether recency overrides authority, and what the system does with the losing value. The wrong time to invent that rule is at 4pm on a Friday with a customer waiting.
Where to start on Monday
Take one question your team answers by hand every week. Where is this order, why was this shipment late, which shipments does a new trade rule touch, what did this customer actually cost to serve. Trace the answer back to every system it touches and write down what each one means by the words in the question. You will find the disagreement within an hour, and it will almost always be an entity definition, a key that got overwritten, or a status that replaced a history.
The work of enforcing those definitions across a live operation is what a normalization layer does, and it is why Orkestra's 200 plus pre-built connectors land in a shared model rather than a shared database. Getting the model right is what turns connected systems into an operation that can answer a question once and be believed.
