In Short: What Makes Logistics Data Hard?
The cost of a delivery is spread across systems that never meet. Transport cost sits in the TMS, handling in the WMS, fuel and time in telematics, and the invoice in finance - each with a different idea of what a shipment is. Conforming those identities is the project. Real-time is a separate question, and the answer is usually "for some things, not most".
Cost-to-Serve, and Why It Stays Unanswered
Almost every logistics operation wants cost-to-serve by customer, lane or product. Very few have it, and the reason is structural rather than analytical.
A single delivery touches:
- The TMS - route, carrier, transport cost
- The WMS - pick, pack and handling effort
- Telematics - actual time, distance, fuel, waiting
- Finance - the invoice, credits and claims
- The order system - what the customer actually bought
Each identifies the delivery differently. The TMS has a consignment number, the WMS a pick reference, finance an invoice line, and the customer a purchase order. Answering "what did serving this customer cost" requires establishing that all five describe the same event - and that mapping is the substance of the project.
Once conformed, cost-to-serve is arithmetic. Before it, no amount of dashboarding helps.
Freshness: Match It to the Decision
Logistics is the sector where "we need real-time" is most often asserted and least often examined. Real-time is genuinely valuable in specific places and expensive everywhere else.
Live genuinely earns its cost for: exception management on in-flight shipments, vehicle position for customer enquiries, dock and yard scheduling, and cold-chain or compliance alerting where a threshold breach has consequences.
Daily is fine for: cost-to-serve, carrier performance, network profitability, capacity planning, and essentially all management reporting.
Real-Time Intelligence in Fabric handles the first category properly, and Data Activator turns thresholds into alerts so exceptions announce themselves rather than being discovered.
The discipline is deciding per decision rather than per platform - the argument we make more generally in matching data freshness to decision speed.
Telematics Volume
Vehicle telematics generates data continuously, and landing every GPS ping at full resolution is the fastest way to outgrow a Fabric capacity without gaining anything.
A more useful default: aggregate to journey level before landing. Start, end, distance, duration, idle time, stops, fuel. That answers nearly every analytical question at a small fraction of the volume.
Keep raw pings only where a specific requirement justifies it - a disputed delivery, a driver behaviour programme, a route optimisation model in training. Our capacity sizing guide explains why volume that arrives constantly costs more than volume that arrives once.
Third-Party Carrier Data
If you use subcontracted carriers, their data is a first-class engineering problem rather than a footnote.
Different formats, different schedules, different definitions of "delivered", and highly variable quality. One carrier sends a clean daily file; another sends a spreadsheet when someone remembers.
Handle this explicitly in the Bronze-to-Silver layer with quality rules per carrier, an expected-arrival check that flags missing feeds, and a documented rule for what "delivered" means when carriers disagree. The alternative - somebody fixing it in a spreadsheet each Monday - is where most logistics reporting quietly loses credibility.
What to Build First
On-time performance and cost per delivery, joined to finance. Both are already argued about, both span systems, and both produce something the operation can act on within a week.
Network optimisation and demand forecasting are more interesting and worse first projects, for the same reason predictive maintenance is a bad first project in manufacturing: they need trust in the underlying data that has not been established yet.
Where Solv Systems Comes In
We build Fabric platforms for logistics operations, and the shape is consistent: the interesting analytics are blocked by an unglamorous identity-conforming problem nobody wants to own.
We take that on - joining TMS, WMS, telematics, finance and order data into one model where a shipment means one thing - then build reporting on top and add streaming only where a decision genuinely turns on minutes. The test is whether the operation and finance can look at the same cost number without either of them reaching for a spreadsheet.
Sources and Further Reading
Frequently asked
Because the costs are spread across systems that never meet. Transport cost is in the TMS, handling in the WMS, fuel and time in telematics, and the invoice in finance - each with its own idea of a shipment. Answering the question requires conforming those identities before any calculation happens.
For some things, genuinely yes - live network exceptions, vehicle position, dock scheduling. For most reporting, no. The useful discipline is matching freshness to the decision: live where minutes change an outcome, daily where they do not. Everything real-time by default is expensive and rarely used.
Aggregate before landing where you can. Full-resolution GPS pings are rarely needed for analytics; journey-level summaries usually answer the question at a fraction of the capacity cost. Keep raw data only where a specific requirement justifies it.
Most have APIs or database access, and Fabric pipelines handle both. The engineering challenge is rarely connectivity - it is incremental loading, handling systems that soft-delete, and reconciling identities across platforms that were never designed to agree.
On-time performance and cost per delivery, joined to finance. Both are already argued about, both span systems, and both produce a number the operation can act on within a week of having it.
As a first-class problem rather than an afterthought. Carriers send data in different formats on different schedules with different quality. That variability belongs in the Bronze-to-Silver layer with explicit quality rules, not in a spreadsheet someone fixes each Monday.
