We discussed a few of the gaps in Data and Analytics in the real world. The “Last Mile of Analytics” refers to the struggle companies encounter in creating the behavioral changes that create value within organizations, from great analytics outputs.
If analytics is not going to change behaviors, why do we do any data and analytics project?
Evey company face challenges such as customer retention, employee engagement, goods consumption, etc. and the data-driven mindset and approach tries to address them by look at insight.
These insights can be diagnostics or predictive, combining complex queries and some fancy machine learning algorithm for prediction and probabilities. But at the end of the day, these analytics artifacts are sitting at the insight layer.
Actionable Insight is NOT Outcome
Data and analytics teams are engaged to solve these problems by building fancy machine learning algorithms. The Business Intelligence teams build hundreds of reports and dashboards. The team of BI and data scientists and engineers go to “a meeting” with business stakeholders in order to understand more about the challenge.
After the meeting data scientists go and build the necessary algorithms while the BI team starts building dashboards and reports. They look at the data, current employee engagement, customers buying behavior, and so on. They put together a well-designed dashboard, reports and accurate algorithm attempting to address the business challenge (e.g, churn).
The challenge is that neither of these accurate algorithm nor a well-designed dashboard and reports are going to change organizational behaviors. This is simply because despite the accuracy of the analytic algorithms, they are not delivering the necessary business value simply because:
- The results are not integrated into operations
- Frontline personnel or managers do not use the outputs because, of mistrust (i.e., overwhelming false positive, lack of domain expertise input in the result, etc.)
- Analytics results are presented in the form of a dashboard only showing numbers and graphs.
And still
- Actions are delayed
- Decisions are inconsistent
- Outcomes are lagging
All of it is because we humans suffer from confirmation bias.
The truth is the data is used to justify the already-made decisions
To address the challenge of the Last Mile of Analytics, the whole process of building the solution based on analytics should be revisited. The solution is not only about the accuracy of the analytical model and algorithm, or building more dashboards and reports. It is about how to create a solution that closes the gap between data and business operations.
Starting from the Last Mile of Analytics
To address the challenges above, commonly known as the last mile of analytics, the analytic solution should start with the challenge itself (i.e., the proverbial last mile). This means designing the analytics solution with adoption in mind. Crucially, this means ensuring it is aligned with business values and it is delivering the business objectives.
The missing gap here is the “business decision”. By modeling the business decisions for the particular problem, team will close the gap between data and the business problem (e.g churn). Once the decision is modeled it provides a blue print of how to improve it based on its inter-connected decision units.
Each decision unit will have its own specific technology requirements, data inputs and relevant technique, which the Decision Graph brings all of them together and executes it.
The Process
The goal must be to create an iterative, incremental delivery plan that allows the business to benefit from the solution as soon as possible, learn about the outcome, integration challenges and organizational barriers sooner rather than later.
To create the plan, you need to look at creating an inventory of decisions by:
Step 1: Build a Decision Inventory
Create a centralized inventory where each row represents a candidate decision.
- Look at the top algorithms, dashboards and reports
- Create a list and categories them based on the decision area (e.g. Claims & Payments, Underwriting & Pricing, Pharmacy Benefits…)
Make sure you capture the information below:
- Decision name (e.g., “Triage claim based on complexity”)
- Frequency (e.g., 1,000/day)
- Complexity (low/med/high)
- Impact (e.g. claims cost, compliance risk, customer churn)
- Current ownership (Ops/IT/BAs)
- Current execution method (manual, rules, ad hoc, Excel)
- Automation readiness
- Stakeholder priority
Step 2: Score and Prioritize Decisions
Define scoring criteria to help objectively select decisions for the pilot. You can use a simple matrix:
| Criteria | Description | Score Range |
|---|---|---|
| Business Impact | Financial, compliance, customer experience | 1–5 |
| Decision Frequency | How often it's made | 1–5 |
| Latency Gap | Delay between insight and action | 1–5 |
| Current Pain | Friction, errors, manual steps | 1–5 |
| Automation Feasibility | Readiness of inputs + rules | 1–5 |
Prioritize the top 2–3 decisions with high scores for the pilot phase.
Step 3: Model the Decisions
This is the point where the inventory hits the road, and we start modeling decisions using the decomposition technique.
The decomposition technique is used to logically and systematically break down a high-level decision into smaller, manageable decision units (e.g. business knowledge, decision, and sub-decisions and etc.). Starting from a core business question like “Should we approve this prior authorization request?”, the process involves identifying the essential decision units that contribute to the final outcome, such as checking benefit coverage, cost thresholds, clinical eligibility, or provider credentials. For each of this decision unit, you clearly define the required data inputs (using Fact Concept) and expected outcomes, ensuring each piece of logic is self-contained and traceable. This decomposition creates the Decision Requirements Diagram (or Dynamic Decision Graph) that represents how decisions are made.
To learn more continue on framing business decisions systematically.
Step 4: Operationalizing Decisions
Now the decision model is built and details about business rules, analytics, and data is in place. You can start testing them to verify they produce expected outcomes.
- Use live debugger to verify the behavior and ensure the expected outcome is produced
- Create test cases using data. Either provide Excel, or from the database and use orchestration
- Run the simulation and What-If Analysis to confidently investigate the impact
When you are confident, deploy the decision and integrate your processes and system to consume the decision service, or decision batch jobs.
Book a Custom Demo
Conclusion
What we explain in this article is part of the Decision-Centric Approach® that enables organizations to make decisions the first-class citizen assets. It means the explicitly model business decisions and proactively operationalize them.
By doing that so, the data and analytics team's artifacts (dashboards, dataset, Machine Learning models) will be integrated into the actual decision model that is integrated into processes and systems of organizations. With operationalizing the decision model, we operationalize dashboards, dataset, Machine Learning models which ensures they actively make impact on organizations decision-making scenarios.
This approach ensure that not only do organizations can address “The Last Mile” while designing analytics, but also gradually changes the teams positions from service provider and elevate them as part of new operating model of organizations.
Last updated May 7th, 2026 at 11:46 am Published August 6th, 2019 at 11:25 am
