Analytics Last Mile: From Dashboards to Decisions

The widely quoted figure — that 87% of AI and data science projects never make it to production — traces to a 2019 VentureBeat report (Rumman Chowdhury, Transform 2019), and has been restated in subsequent Gartner and IDC work. It is not a commentary on data quality or model sophistication. It is a commentary on what happens after the model is built. The model works. The dashboard is built. The project is declared complete. And the production floor continues unchanged, because the insight is on a screen and the action is somewhere else entirely.

The analytics project ends at the dashboard. There is no mechanism for the insight to trigger an operational response. The analyst closes the laptop, the operations manager looks at the chart in the weekly review, and the decisions that the chart was supposed to inform continue to be made the same way they were made before the analytics programme started.

This is the analytics last mile problem. It is not a technology problem. The technology to close the gap - workflow integration, alert routing, work order creation, feedback loops - exists and is mature. The problem is that last mile work is unglamorous, hard to scope, and falls in the gap between the analytics team's mandate and the operations team's system ownership.

The analytics last mile is the layer between the insight on a dashboard and the action in an operational workflow. It includes alert routing (who gets notified, through which channel, when a threshold is breached), workflow triggers (what happens in the operational system when an exception is detected), work order creation (the maintenance request, the purchase requisition, the quality hold that the analytics insight should generate), escalation paths (what happens if the first responder does not act), and feedback loops (how the system learns whether the action resolved the issue).

A predictive maintenance model that identifies a bearing approaching failure has completed the analytics work. The last mile is: creating the maintenance work order in the CMMS, pre-positioning the replacement bearing, routing the alert to the maintenance supervisor and not the quality team, and recording whether the intervention prevented the failure or occurred too late. Without that last mile, the model produces an insight that gets ignored.

The last mile is different for every operational domain. In supply chain, it is the replenishment trigger. In quality, it is the production hold and the root cause investigation workflow. In logistics, it is the customer notification and the rerouting decision. Each domain requires a different integration, different routing logic, and different feedback measurement. That specificity is why last-mile work is scoped separately from the analytics build - and why it is so often left out.

The practical approach is to define the operational response before building the analytics. Start with the decision: what decision should change as a result of this insight? Who makes it? What system do they use to act on it? What information do they need to make it? The analytics build should be designed to deliver exactly that information, in exactly that system, at the moment of the decision.

For maintenance teams, that means the alert lands in the CMMS, not in an email. For supply chain teams, it means the replenishment recommendation appears in the planning tool, not in a BI dashboard. For quality teams, it means the production hold is triggered automatically, with the supporting data attached, not communicated via a report that someone may or may not read before the next batch runs.

Organisations that close the last mile consistently — that define the operational response before the analytics build, and integrate the insight into the workflow where the decision happens — are the ones in the 13% that reach production impact. The 87% are not building worse models. They are building better dashboards that nobody acts on.

The last mile is where Power Platform stops being a slide and starts being the bridge. When a threshold is breached or a model flags an exception, Power Automate routes the alert to the right person through the right channel and creates the record in the operational system — the CMMS work order, the purchase requisition, the quality hold — rather than leaving it on a dashboard. Power Apps gives the responder a lightweight screen to act, accept, or reclassify without leaving their workflow. That is the mechanism the 87% are missing.

It only works if the insight and the action read the same governed data. On a Microsoft Fabric foundation, the model, the Power BI semantic model that surfaces it, and the automation that acts on it all draw from one definition in OneLake — so the number on the alert reconciles with the number on the dashboard and the number in the work order. Where those diverge, responders stop trusting the alert, and the last mile collapses back into email.

Increasingly the routing layer is conversational. Copilot Studio lets an operator ask why an alert fired and get the supporting data back in plain language, and agentic analytics can watch the stream and open the work order before a human notices the threshold. But the principle holds regardless of how clever the surface gets: the insight has to land in the system where the decision is made, at the moment it is made.

None of this is exotic technology. Alert routing, workflow triggers, and feedback capture are mature. What makes the difference is designing them as part of the build rather than bolting them on after the model is declared finished — which is exactly the discipline the next section is about.

The most common failure is ownership. Last-mile work sits in the gap between the analytics team's mandate (build the model) and the operations team's system ownership (run the CMMS, the planning tool, the MES). Nobody is accountable for the integration that connects them, so it never gets scoped. The fix is to name an owner for the operational response up front — often the Fractional CDO — with the authority to commission work across both sides.

The second failure is trust. A responder will ignore an automated work order generated from data they do not believe, and they are right to — acting on a bad signal at machine speed is worse than not acting. This is why the governed foundation is not optional: the last mile only earns the right to automate once the underlying number is trusted. Skip the foundation and you have built a faster way to be wrong.

And the honest limit: not every insight should trigger an automatic action. Reserve straight-through automation for decisions where the correct response is known and bounded; keep a human in the loop for the judgement calls. Over-automating the last mile hides risk inside a workflow nobody is watching, which surfaces as a crisis later rather than a missed alert now.

The shift is from analytics as a reporting artefact to analytics as decision infrastructure. When the last mile is closed, the maintenance alert becomes a work order, the demand signal becomes a replenishment order, and the quality exception becomes a hold — automatically, at the point the decision is made, not in a chart reviewed days later. The dashboard stops being where insight goes to die.

And it does not need an enterprise programme to begin. Define the operational response for one high-value decision, build the analytics to deliver it into the system where that decision is made, and wire the routing through Power Platform — first value in 6 weeks. Prove the loop on one decision, then reuse the same pattern for the next, rather than building forty dashboards nobody acts on.

The line between the 13% that reach production impact and the 87% that do not is not model quality. It is whether the insight reached the decision that needed changing. Unify the data, predict with AI, act with automation — in that order — and analytics finally changes what happens on the floor rather than just describing it after the fact.