Illustrative examples of data strategy diagnostics in logistics and supply chain organisations. Covers shipment margin leakage, TMS integration failure, governance breakdown, and what structured advisory produces.
These are illustrative scenarios. They reflect the types of problems encountered across freight, warehousing, and distribution environments. Names, figures, and identifying details are not drawn from specific clients.
The purpose is to show what a data strategy diagnostic examines, what it typically finds, and what it produces. This is not implementation work. It is structured advisory — before systems are changed, platforms are selected, or technology is purchased.
For the strategic and governance framework that sits behind these examples, see Logistics and Supply Chain Data Strategy.
A logistics group operating across three sites was reporting positive margins at a group level. However, individual site managers had different views on profitability. Routes that appeared profitable in one report appeared marginal or loss-making in another.
The diagnostic found that the group had no single definition of “shipment cost.” Each site allocated fuel, driver time, and vehicle overhead differently. One site included toll costs. Two did not. Subcontractor rates were coded to different cost centres depending on the site controller’s preference.
Revenue was tracked in the TMS. Costs were tracked in the ERP. The two systems did not share a shipment identifier. Reconciliation was done monthly, manually, in a spreadsheet that one person maintained.
Margin figures were directionally useful at best. Route-level pricing decisions, which depended on these figures, were not grounded in consistent data.
A regional transport operator had invested in telematics. Vehicle location, speed, fuel consumption, and driver behaviour were all being captured. Reports were generated automatically each week.
The problem was that the data was not trusted. Finance did not use it. Operations used it selectively. When the two functions disagreed on route costs, the telematics data was not treated as authoritative.
The diagnostic identified the root cause: no one had defined which system held the authoritative record for fuel consumption. The telematics platform, the fuel card system, and the depot log all produced different figures. Each figure was correct within its own logic. None had been designated as the source of truth.
Fuel adjustments were made manually at month-end to reconcile the three sources. These adjustments were not documented. They were not approved. The person who made them had left the organisation six months earlier. Their replacement continued the practice without knowing why it had started.
A distribution business had implemented a new Transport Management System. The implementation had taken eight months and exceeded budget. After go-live, adoption was low. Dispatchers continued using spreadsheets for route planning. Managers continued using phone calls to track deliveries.
The diagnostic did not focus on the TMS. It focused on the decisions that the TMS was supposed to support.
What it found: the TMS had been configured for the organisation that was described in the requirements document, not the organisation that actually existed. Customer delivery windows in the TMS were fixed. In practice, they changed daily based on phone negotiations between drivers and site managers. The TMS had no mechanism for capturing these changes.
Delivery completion in the TMS required a four-step confirmation process. Drivers confirmed completion on their handheld devices. In poor signal areas — which covered a significant portion of the delivery network — confirmation was delayed by hours. Dispatchers, receiving no confirmation, would phone drivers directly. The phone call resolved the operational question. The TMS record was never updated.
By end of day, the TMS showed 30% of deliveries as incomplete. The actual completion rate was over 90%. No one trusted the system. No one fixed it.
Two distribution businesses had merged. Both had existing systems, existing processes, and existing definitions for core operational concepts — shipment, delivery, route, exception.
Within three months of the merger, leadership was receiving two versions of the weekly performance report. Both were accurate for their respective businesses. Neither was comparable to the other.
The diagnostic found seven different definitions of “on-time delivery” across the combined entity. Some measured against planned departure. Some against planned arrival. Some against a customer-confirmed window. Some used a 15-minute tolerance. Some used 30 minutes. Two used no tolerance — any deviation counted as late.
Operational decisions — capacity planning, route pricing, carrier performance — were being made against different benchmarks. When regional managers debated performance in leadership meetings, they were not comparing the same thing.
Across these scenarios, the decision to commission an independent diagnostic was triggered by one or more visible symptoms. The underlying problems were always older than the symptoms.
Seven different shipment definitions. When a single entity cannot agree on what a shipment is — when it starts, when it ends, what it includes — reporting becomes unreliable and performance management becomes contested.
Manual fuel reconciliation spreadsheets. Spreadsheets maintained by individuals, without version control or approval workflows, are not a reconciliation method. They are a deferred governance problem. When the individual leaves, the reconciliation logic leaves with them.
Inconsistent SLA reporting. When different teams report SLA performance using different denominators, different tolerances, and different data sources, the figures cannot be used to make commercial or operational decisions.
Late exception escalation. Exceptions that are resolved informally — between a driver and a dispatcher, between a site manager and a client — and not recorded in any system create an invisible risk register. Problems recur because there is no record that they occurred before.
Duplicate customer master records. When the same customer appears multiple times in the customer master — under different names, different codes, or in different systems — revenue attribution, SLA tracking, and billing all become unreliable. Duplicates accumulate when no one owns the customer master and no validation rules exist at point of entry.
Across logistics diagnostics, the most common findings are structural. They are not technology problems. They are governance and decision clarity problems.
Ownership unclear. The most frequent finding is that no one has been explicitly assigned accountability for specific data. Shipment data “belongs” to operations. Cost data “belongs” to finance. The data that sits at the boundary — carrier invoices, fuel allocation, exception codes — belongs to no one.
KPI misalignment. Teams are measuring the same concept differently. The misalignment is not accidental. It reflects genuine differences in how each team defines operational success. Without a governance process to align definitions, the misalignment persists indefinitely.
Duplicate system entries. The same event — a delivery, a vehicle movement, a customer contact — is recorded in multiple systems with different reference numbers, different timestamps, and different outcomes. No system is designated as authoritative. Reconciliation is manual.
Unvalidated manual overrides. Month-end adjustments, reclassifications, and corrections are made directly to reports or financial records without documentation, approval, or traceability. These overrides solve the immediate problem. They obscure the root cause and create audit exposure.
No data lineage documentation. When a figure in a management report is questioned, no one can trace it back to its source. The calculation logic exists in someone’s memory or in an undocumented spreadsheet formula. Challenging the figure requires finding the person who built the report, not reading the documentation.
The output of a data strategy diagnostic is not a technology recommendation. It is not a project plan. It is not a list of tools to evaluate.
It is structured clarity — delivered as a set of documents that leadership can use to make decisions.
Governance model. A clear assignment of data ownership by domain. Who is accountable for shipment data, cost data, customer master data, and SLA data. What “accountable” means in practice: what they are responsible for, how disputes are resolved, and how quality is monitored.
Priority roadmap. A sequenced view of which data problems to address first, based on their impact on operational decisions and financial risk. Not everything needs to be fixed. Some things need to be fixed before anything else can be fixed.
Control design. A set of recommendations for validation rules, approval workflows, and exception handling processes. Where data is entered. What is checked at entry. Who approves adjustments. How overrides are documented.
Reporting redesign. A proposal for standardised definitions, consistent denominators, and agreed-upon data sources for core KPIs. Not a new reporting system. A set of decisions about what the existing systems should produce and how those outputs should be interpreted.
Executive summary. A short document — written for leadership, not for analysts — that states the problem, the root cause, the priority findings, and the recommended first steps. Clear enough to be acted on. Specific enough to be challenged.
This work does not include system selection, platform configuration, pipeline development, or software implementation. Those are delivery activities. They follow from clarity, not the other way around.
The diagnostic produces the clarity that makes delivery decisions defensible. It answers the questions that, if left unanswered, make implementation expensive and reversible.