Skip to content
    Supply Chain Technology

    Why most supply chain dashboards lie about the business

    May 20, 20265 min read

    Static reports refresh monthly. Operational reality changes hourly. Why the gap between dashboard and decision is costing you margin — and what to do about it.

    It's the second day of the quarterly business review. The VP of Supply Chain is presenting the on-time-in-full slide. The number is 94.2%. It's been 94% for three quarters running. The board nods.

    Two days later, the customer service team escalates: a Tier-1 OEM customer is threatening to deprioritize the supplier on next year's program awards because the last six weeks have been "operationally chaotic." The customer's view of OTIF on the specific lane is 78%.

    Both numbers are accurate. They're just measuring different things, on different cadences, against different baselines.

    The dashboard isn't lying. It's just not the right tool for the decision the team needs to make.

    The reconciliation lag

    Most enterprise supply chain dashboards refresh on a daily or weekly cadence. The OTIF number on the QBR slide is rolled up from operational systems that themselves report at varying latencies — the WMS within minutes, the TMS within hours, the carrier portal sometimes within days. By the time the dashboard renders, the operational reality it's describing is 24-72 hours stale.

    For a board-level metric, that's fine. For a planning decision, it's not. The planner needs to know what's happening on the lane right now, not what happened last week.

    This is the gap between dashboard reporting and operational truth. Dashboards aggregate. Decisions are made on specifics.

    Latency is the visible half of this problem. The invisible half is a source that has stopped reporting altogether: the dashboard keeps showing the last value it received, and nothing on the screen marks it as old. That needs a separate check, which is why telling a quiet shipment from a broken data feed is worth doing on its own.

    Why monthly reports are wrong by design

    The structure of monthly reporting forces three failure modes:

    1. Aggregation hides the specifics. Network OTIF at 94.2% conceals the lane at 78%. The QBR slide is correct in aggregate and wrong about the specific commercial relationship at risk.

    2. The dashboard can't drill. A metric isn't an answer. The OTIF number raises a question — which lane, which carrier, which root cause? — that the dashboard can't answer without a second tool, a different team, and a half-day of analysis.

    3. By the time the report lands, the moment has passed. Anomalies that surface monthly were operational hours, days, or weeks ago. The window to act has closed; the only thing left is to explain it in the next QBR.

    The fix isn't a better dashboard. It's a different layer. Live performance reporting sits closer to the operational data, refreshes continuously, and drills from the headline metric to the specific shipment in one view.

    What live KPIs actually look like in practice

    A working version of "live reporting" has three properties most monthly dashboards don't:

    Continuous refresh. The operational data lands as it happens. The metric updates when the underlying event fires. If a lane's OTIF drifts mid-day, the team sees it mid-day — not in next month's deck.

    Drill from KPI to root cause in one view. Click the network OTIF. Drop into the region driving the variance. Drop into the carrier. Drop into the lane. Drop into the specific shipment. Each drill happens in the same interface, on the same data layer.

    Anomalies surface themselves. The metrics that matter shouldn't require someone to be watching the dashboard. Anomaly detection models trained on the operational baseline fire when a metric drifts in a way that matters — not on every fluctuation, not on noise, but on signals the operator needs to see.

    This is the difference between performance reporting and performance recording.

    The drill problem most BI tools can't solve

    Most enterprises already have a BI tool. Power BI, Tableau, Looker, the in-house data team's dashboard layer. They're good at visualizing a data model. They're not good at building the model.

    The reason BI dashboards lag operational reality is that the data model underneath them was built once, by a data team, against a static schema. When the underlying source systems change — a new carrier, a new ERP module, a renamed SKU table — the model breaks or quietly goes wrong. Maintenance is a quarterly project. We've written more about why this happens in why WMS, TMS, and ERP data silos break visibility.

    The reconciled data layer handles this differently. It reads directly from the source systems through standard connectors, normalizes the schemas at load time, and produces one operational record per SKU, per shipment, per order. The reporting on top is correct because the substrate underneath is correct — and stays correct when the sources change.

    You don't replace your BI tool. You give it a clean data layer to read from. The dashboards finally agree with operational reality.

    What changes for the team

    Three things change when reporting is wired directly to operational data:

    • The QBR deck stops being a separate exercise. It's the same view the team works from daily, just summarized for the board. Finance and operations cite the same numbers because they read from the same source.

    • Anomalies stop being a QBR surprise. Drifts surface in real time. The team works the anomaly when it happens, not when the deck reveals it three weeks later.

    • Root causes become accessible. "Why did OTIF drop?" is a one-minute question with a click-through answer, not a half-day analysis project. The conversation moves from "what happened" to "what do we do."

    This is what the end-to-end performance reporting layer is actually for. Not prettier dashboards — more operationally accurate ones. The same logic applies to the platform analytics view where the same reconciled record is exposed for ad-hoc analysis.

    How Orkestra fits

    Orkestra reconciles operational data from your ERP, TMS, WMS, carrier, and POS sources into one performance layer. The pre-built KPI library covers OTIF, lead time, exception MTTR, freight cost per unit, dwell time, and others — already wired to operational data, no six-month BI build. Drill from any metric to the specific shipment, order, or SKU in one view.

    Anomaly detection runs on your operational baseline, not generic thresholds. The metric flags itself when something meaningful moves. Your team stops hunting and starts acting.

    See it on a sample KPI tree · Book a walkthrough

    Further reading

    And if you'd rather see the architecture in product form: the reconciled data layer your dashboards need.

    Continue reading

    Trusted by leading supply chain teams
    MatalcoOIA GlobalKingsdownDBWMatalcoOIA GlobalKingsdownDBW
    DLAIllyLevitt SafetySquareInstoreDLAIllyLevitt SafetySquareInstore
    TAKE THE NEXT STEP

    Action breaks down when operations are disconnected.

    Orkestra gives teams one place to see what matters, coordinate the response, and move operations forward.