What I Learned Rebuilding a Logistics Dashboard as a Power BI Operations Report

Most logistics dashboards answer the wrong question. They tell you how last month went. The operations director standing on the floor at 6am needs to know which of today’s shipments is about to miss its window — and the dashboard is silent on that.

I spent an afternoon rebuilding a logistics and supply chain dashboard concept as a proper Power BI operations report. Nine pages: Dashboard, Shipments, Warehouses, Tracking, Transportation Cost, Performance Report, Delays & Exceptions, Inventory Status, and Alerts. This is a write-up of what the build surfaced — less about the visuals, more about the layer underneath that decides whether any of it is useful.

The distinction matters because the two reports look almost identical in a screenshot. Same cards, same trend lines, same regional breakdown. What separates them is not on the screen. It is whether the numbers were assembled by hand from yesterday’s exports, or read live from systems that agree with each other. That difference is invisible in a demo and decisive on a Tuesday morning when three trucks are running late.

The version I started from had everything a good-looking dashboard should have. A clean OTIF card reading 88.2%. Total shipments at 12,450. Delayed shipments at 1,470. Fuel cost up 15% on the month. A regional heat map, a delay-cause breakdown, a warehouse league table. It would pass a board review without a question asked.

And that is the trap. Every figure on it was true and every figure was historical. The OTIF number was a monthly average. The delayed-shipment count was a tally of what had already gone wrong. The cost figures came off a periodic upload. Nothing on the screen could tell an operations leader what was happening to a consignment in transit right now.

When you sit with the people who actually run distribution, the complaint is never “we don’t have a dashboard”. They have several. The complaint is that the dashboard and the floor disagree, and the floor is right. The report says OTIF is 88%; the shift supervisor knows three trucks are stuck outside Onitsha and the customer has already called. The dashboard is describing a version of the operation that ended at the close of last period.

This is the same pattern I see across manufacturing, FMCG and logistics estates. The reporting layer is competent. The visuals are clean. But the data feeding them lands once a day, or once a week, from systems that were never wired together — so the report is always describing a business that has already moved on.

OTIF — On Time In Full — is the cleanest test of whether a supply chain’s data is live or stale, because it depends on two events that happen in the real world at unpredictable moments: the shipment leaving when it should, and arriving complete when it should. You cannot fake OTIF with a tidy monthly upload. To report it honestly, you need dispatch events from the warehouse management system, delivery confirmations from the carrier, and order lines from the ERP, all reconciled to the same shipment, continuously.

If your OTIF figure only moves once a month, it isn’t measuring your operation. It’s measuring your reporting cycle. That single observation is usually enough to reframe the whole conversation. The problem was never the BI tool. The tool is rendering exactly what it’s given. The problem is that what it’s given is a snapshot, uploaded on a schedule, from systems that were never wired together.

The same logic applies to every metric an operations leader actually steers by. DIFOT, fill rate, on-time dispatch, dwell time at the dock — each one depends on events from more than one system landing against the same shipment record. Get the foundation right and they all come alive together. Get it wrong and you can compute every one of them perfectly, a month too late.

The rebuild kept the same nine views, but the design principle shifted from “show the history” to “support the decision”. Four things change once the data underneath is live and governed rather than uploaded.

OTIF and on-time delivery update against actual dispatch and delivery events, so the number on the card is the number on the floor. Delay alerts fire against in-transit shipments before the SLA is breached, not as a post-mortem the next morning. Each shipment exists as one reconciled record — SAP, the warehouse management system and the carrier feed agreeing on a single version — instead of three systems telling three stories. And an exception, like a warehouse crossing 90% capacity, becomes a signal that reaches the people who can act on it, rather than a red cell nobody is watching.

On a Microsoft estate this is a Microsoft Fabric job. OneLake holds the reconciled shipment data, Power BI renders it through Direct Lake so the visuals read live rather than from a cached import, and Power Automate carries the exception to the warehouse floor. The visuals — the cards, the trend lines, the regional breakdown — are the easy and visible 20%. The live, governed data underneath is the 80% that decides whether the report is a decision tool or wall art.

None of this is exotic. It is the ordinary discipline of data integration done once, properly, instead of re-stitched by hand every reporting cycle. The dispatch event from the WMS, the delivery confirmation from the carrier API, and the order line from SAP S/4HANA are reconciled to one shipment key in OneLake. After that, every view downstream is reading the same truth — which is the whole point.

Abstract architecture is easy to nod along to and hard to picture. So here is a working example — a logistics and supply chain operations report built on the same Microsoft stack, with illustrative figures.

Move between the views — shipments, warehouses, tracking, transportation cost, delays and exceptions, inventory and alerts. This is the shape of a logistics report when the data underneath it is live and reconciled across systems, rather than uploaded once a day and reconciled by hand. The figures are sample data; the structure is the one I would build on a real estate.

The discipline that made the rebuild useful was simple: every view had to answer one operational question a named person asks at a specific moment — not just display a category of data.

The Dashboard answers “is the operation on plan right now”, not “what was our throughput last month”. Shipments answers “which consignments are at risk today”. Tracking answers “where is this load and will it make its window”. Delays & Exceptions stops being a historical breakdown of causes and becomes a live queue of shipments breaching, or about to breach, their SLA. Transportation Cost moves from a monthly fuel-and-freight summary to cost-per-shipment trending against the lanes and carriers driving it. Inventory Status flags the warehouse crossing capacity before the inbound truck is turned away. Alerts is the page that earns its place only if the signal actually reaches the person who can act — otherwise it is a wall of red nobody reads.

Reframed that way, the rebuild was not a visual exercise. It was deciding, view by view, what decision the page exists to support — and then checking whether the data underneath could support it live. On most of the nine pages, the honest answer at the start was no. That is the work.

It would be dishonest to pretend the live model is free. It isn’t, and it isn’t always the right call.

If the source systems don’t emit clean events — a WMS that batch-writes overnight, a carrier with no API, dispatch logged by hand hours after the truck has gone — then “live” is a promise the data can’t keep, and forcing it produces a fast dashboard that’s confidently wrong. Direct Lake has real limits on model size and transformation complexity; push past them and you’re back to import mode, refreshed on a schedule, which is fine as long as everyone knows that’s what they’re looking at. And a sub-25-shipment-a-day operation rarely needs any of this; a well-built scheduled report is the right tool and a live pipeline is over-engineering.

The honest position is that the live operations report is worth building when the events exist and the decisions are time-sensitive — and that you should say so plainly when they don’t. I have talked clients out of this build more than once, because their carrier could not send a usable delivery confirmation and no platform was going to invent one. The discipline is naming that before the budget is committed, not after.

For an operations director or supply chain head, the test is not whether the report looks good in a steering meeting. It is whether it changes a decision before the cost is locked in. A late delivery you learn about the next morning is a complaint to manage. The same delivery flagged while the truck is still on the road is a re-route, a phone call, a window saved.

The return shows up in three places. Exceptions get caught while there is still time to act, so OTIF and DIFOT move because the misses are prevented, not just counted. The standing argument about whose number is right ends, because SAP, the WMS and the carrier feed reconcile to one shipment record. And the operations team stops spending the first hour of the day rebuilding a picture of reality from three screens and a WhatsApp group.

There is a quieter shift underneath that. When the report is trusted, speed becomes structural — it stops depending on who happens to be watching the dashboard that morning. The insight arrives at the decision point instead of sitting in a report nobody opens. That is the difference between a dashboard the board admires and a report the floor actually runs on.

A logistics dashboard that refreshes once a day is a rear-view mirror. It’s useful for the review meeting and useless for the shift. Operations runs on the windscreen — what’s ahead, while there’s still time to change it. The gap between the two isn’t a visual-design gap. It’s whether the data underneath is live, governed and agreed across your systems.

If you’re looking at a supply chain dashboard that everyone admires and nobody trusts, the question worth asking isn’t “can we make it prettier”. It’s “is this number live, or is it last month’s”.

I work with mid-market manufacturers, FMCG, packaging and logistics businesses on exactly this — turning ERP and WMS data into operations reporting people actually trust, on Microsoft Fabric and Power BI. If your OTIF number is last month’s, a 30-minute diagnostic with Amit will tell you why. No slides. No pitch deck. No obligation to proceed.