Walk through a large enterprise at 9am on a Tuesday and ask the operational managers (buyers, underwriters, schedulers, planners) what they decided this morning and what data informed it. You will get vague answers about systems they have used for years, and a smaller number of recent decisions where the dashboard "confirmed what they were thinking." That is the gap an enterprise data analytics strategy is meant to close: the distance between data the company has and decisions that actually change because of it.
Most strategies, the long ones with workstreams and capability maps, never name this gap. They describe platforms and tools and architectures. They produce decks that look serious in a steering committee and leave the Tuesday-morning reality untouched. McKinsey's State of AI survey finds fewer than one in three companies see meaningful EBIT impact from analytics and AI investment. The reasons people give for that are almost always technological: wrong tool, wrong vendor, wrong cloud. The actual reasons are organisational. Nobody owns the data. Nobody acts on the output. Nobody measures whether anything changed.
What follows is an attempt to write down what an analytics strategy looks like once you stop pretending it is about software. There are three levels of maturity that actually matter. There is a unit of work, called a decision-loop, that either lives or quietly dies. There is a small set of failure modes that account for most of the damage, and an architecture that supports decisions rather than just reports. If you are past the basics and trying to understand why the last big investment did not move the business, this is for you.
Key Takeaways
| Idea | What it changes for your program |
|---|---|
| Three levels of maturity actually matter | Reporting answers questions. Decisioning routes data into a workflow. Automation closes the loop without a human. Most enterprises live between two and three and call it three. |
| The decision-loop is the unit of work | A loop has a question, a data source, a decision-maker, an action, and a measured outcome. If any is missing, you have a dashboard. |
| Loops break in predictable ways | Data ages. Owners move on. The action pathway turns out to be a three-week ticket. The outcome never gets tracked. Authority lives upstream of the analyst. Each failure has a known fix. |
| Architecture serves decisions, not reports | Open table format underneath, lineage across the middle, event streaming where time matters, action APIs at the top. Built incrementally from real loops, not designed up front. |
| Maturity is counted decisions, not deployed tools | If you cannot count the decisions your analytics layer informs per quarter, the program does not know what it produces. |
The Three Levels That Actually Matter
Most maturity models have five or seven levels with names like "ad hoc" and "optimised" and a colour-coded chart that runs from red to green. They sound rigorous and explain almost nothing. The work people actually do at each level varies in three ways, not seven, and the three are worth keeping clear.
Level one is reporting. Someone in finance asks what sold last quarter, and a report arrives by Tuesday. The data exists, someone can pull it, the question gets an answer. This is the floor, and most organisations spend a surprising fraction of their analytics hours here. There is nothing wrong with that. Reports are how governance, audit, and the bulk of executive routine actually function.
Level two is decisioning. Someone has to choose between options, and the data now actively shapes the choice. A buyer looking at a demand forecast picks a reorder quantity she would not have picked on instinct alone. A retention manager working from a churn list calls fifteen customers this week instead of forty-five. The data has stopped describing the past and started reaching forward into someone's calendar.
Level three is automation. No human in the routine path. A reorder fires when the model says stock is at risk. A fraud check blocks a transaction in eighty milliseconds. The leverage is enormous. The cost of being wrong is enormous. Which is why level three only works on top of a level two that already works.
The mistake most strategies make is treating these as a ladder you climb once. They are not. A mature analytics organisation runs all three at the same time: reporting for the board and the auditors, decisioning for most of the operational work, automation for the high-frequency low-ambiguity calls. The question is not "which level are we at." It is "what fraction of our work happens at each." Programs that aim straight for level three without first sorting level two end up with sophisticated models nobody acts on, and a postmortem that blames the model.
The Decision-Loop
Underneath the three levels sits a unit of work that either exists in your organisation or does not. We call it a decision-loop, for lack of a less corporate name. A loop has five parts, and when any one of them is missing, what you actually have is a dashboard.
A loop needs a question worth answering. Not "what is the trend in returns" but "for this SKU in this store, do we mark down at 20% this week or pull it from the floor entirely?" The first is a research question. The second is a loop, because something happens next.
A loop needs a data source the answer can depend on, with defined freshness, ownership, and quality bars. Not "we have the data somewhere," but "the daily POS feed, owned by Maria in retail operations, refreshed by 6am, validated against these three rules."
A loop needs a decision-maker. A real person with the authority to act, or a system that takes the output and chooses without escalation. Decisions that have to be re-debated upstream every time they touch the dashboard are not real loops. They are committee inputs.
A loop needs an action pathway. The decision triggers something concrete: a reorder hits the supplier system, a customer gets a call from the retention team, a transaction gets blocked. If the recommendation only lives in a deck, the loop is open at the action end, and nothing ever closes.
And a loop needs an outcome that gets measured. After the action, what happened? Did the marked-down SKU clear? Did the customer stay? You cannot tell whether the loop is working without this, and most loops never get it.
The test is uncomfortable but quick. Pick any analytics artefact your team built in the last quarter. Walk through the five parts. If you cannot name the decision-maker, or describe the action pathway, or point to where the outcome gets tracked, that artefact is reporting. There is no shame in that. Reports are useful. They are just not where the leverage of an analytics program lives.
A small rule for prioritisation, because not every loop deserves the same attention: rank candidates by decisions per quarter, multiplied by the dollar impact of each. Loops with one high-stakes call per year sound important and are operationally hard to justify, because the team cannot get reps. Loops that fire dozens of times a week, even on small calls, are where the value compounds.
Where Loops Break
We have watched the same five things kill loops over and over. None of them are technical mysteries. They are organisational defaults that, if left alone, will quietly disable the work.
The data ages. The model was trained in Q1, the world is now in Q3, and nobody monitored the drift. The fix is unglamorous. Freshness checks on every input, wired to an on-call rotation with a name attached. When freshness drops below the agreed bar, the loop pauses. Running on stale data is worse than not running.
The owner moves on. Whoever built the loop took a new role or left the company. Nobody picked up the maintenance. The loop ran on autopilot until the day it produced something visibly wrong in front of an executive. The fix is to treat ownership transfer as an explicit milestone, not as something that happens by osmosis. When an owner leaves, the loop either gets a new named owner within four weeks, or it gets turned off.
The action pathway is paper. The dashboard looks great. The data is fresh. The recommendation is clear. And nobody acts on it, because the action requires a ticket to another team that takes three weeks to close. This has to be fixed during design, not after launch. If the loop's value depends on action within 24 hours and the actual workflow runs three weeks, the loop is broken on the drawing board, regardless of model quality.
The outcome never gets tracked. The action happened. Something downstream presumably changed. But nobody captured what. A year in, the team cannot say whether the loop earned its budget or burned it. The fix is to instrument the outcome before launch, using the same pipeline that feeds the model. Even if the result materialises slowly, the capture starts on day one.
Authority lives upstream. The person designated as the decision-maker does not actually have the authority to act without sign-off. Every recommendation gets re-debated with someone two levels up, and the loop's responsiveness dies. The fix here is not technical. It is a conversation about authority that should happen before the loop ships, not after the first month of frustration.
The Architecture That Supports Decisions
Architecture for decisions looks different from architecture for reports. Reports tolerate batch latency, ad-hoc joins, and pipelines you will fix later. Decisions do not. A loop that fires every six hours needs the data to be there every six hours, in a form the next step can consume, with a way to call something downstream when the answer comes back.
The pattern that holds up across most enterprise deployments has six layers. None of them are exotic. The discipline is in not skipping any.
At the bottom sit open table formats on object storage: Iceberg, Delta, Hudi. Avoid vendor-locked binary formats. The data outlives the processing engine you choose this year, and the next engine you adopt will need to read it.
Above that, change-data-capture from operational systems into the lake. Debezium, Fivetran, Airbyte, depending on your sources. Do not build bespoke ETL for systems you do not own. The maintenance bill compounds in ways that are invisible at planning and crushing at year three.
Then transformation. dbt or equivalent, declarative and testable. Versioned, reviewed, treated like production code. SQL written in notebooks does not survive the second analyst who joins the project, let alone the third.
Then a catalog with real lineage: Unity Catalog, Atlan, DataHub. Every dataset has a named owner, a freshness SLA, and a dependency graph that shows what touches it. Without this, governance becomes a series of educated guesses, and audits become months-long discovery exercises.
For decisions that cannot wait, an event streaming layer. Kafka or equivalent. Fraud, dynamic pricing, real-time personalisation, anything where the decision has to happen between an event and its consequence.
And at the top, action APIs. The loop's output has to call something: an order management system, a CRM, a messaging platform, a workflow orchestrator. These integrations need versioning, retry logic, and audit trails. Without them, every loop ends at "model returns prediction," and the prediction goes nowhere.
Across all of it, observability. Quality monitoring on the data, lineage tracking on the transformations, outcome tracking on the loops. Great Expectations, Soda, Monte Carlo for the first; OpenLineage for the second. The analytics platform is production software the moment anyone makes a real decision from it. Treat it that way.
The hard part is not picking these tools. Most teams can pick them. The hard part is sequencing the investment. The most common mistake is to build the whole stack before deploying the first loop. The opposite works better: build the minimum stack the first loop needs, ship it, then expand based on what the second and third loops actually demand. The platform earns its budget by removing friction from the next loop, not by being designed up front for needs that may never appear.
Who Owns a Decision-Loop
Most analytics operating models assign ownership by function. Data engineering owns pipelines. Data science owns models. BI owns dashboards. Each silo optimises for its own deliverable, and the loop becomes nobody's whole job. The parts that touch multiple silos rot quietly on the seams.
The alternative is to assign ownership at the loop level. Every loop has a product owner on the business side and a technical lead on the analytics side. Together they own the whole thing: the question, the data, the decision pathway, the action workflow, the outcome measurement. When something breaks, the responsibility is clear before the incident review opens.
This works better than functional ownership for one reason. The loop is the unit of value. It is also the unit of failure. When the unit of ownership matches the unit of value, accountability becomes legible. When ownership is split across three teams, the loop degrades on the seams nobody owns.
The trade-off is honest. Loop-based ownership needs people who can operate across data engineering, modelling, and business workflow. Those people are scarce, and the role does not exist in most corporate org charts. You either hire against it, or you grow it from analysts and engineers who already show the breadth.
For organisations not ready to restructure, there is an interim move that works. Keep the functional teams. But for every major loop, name one product owner who is accountable for the loop's outcome across functions. They do not manage the engineers. They own the loop's success, and they have the air cover to escalate when one of the functional teams under-delivers.
How to Measure What Is Actually Happening
The wrong metric for analytics maturity is the count of deployed dashboards, models, or pipelines. Those are inputs. They tell you what the team built. They do not tell you what changed.
The metrics that work measure decisions and outcomes.
The first is counted decisions per quarter. How many specific operational decisions did your analytics layer inform last quarter? Not "supported with reporting," which is a vague claim, but "directly informed a choice that would have gone the other way without the data." If your team cannot produce this number, the program does not know what it does.
The second is the time from data to decision. For a typical loop, how long passes between the data being captured and the action being taken? Hours, days, weeks? Mature programs compress this number deliberately. A loop where the data arrives daily but the decision happens monthly operates at a fraction of its potential value.
The third is decision quality, measured against outcomes. When the loop recommended A and someone took A, did the predicted result actually happen? Track this across loops, not just one. A program where 80% of loops produce outcomes within their predicted range is mature. One that cannot tell you this number is not.
The fourth is automated decision share. What fraction of decisions in your operational workflows happen through closed loops, versus through humans reviewing data and choosing? This number should grow for low-ambiguity decisions and stay low for high-ambiguity ones. The composition matters as much as the level.
And the fifth, the uncomfortable one: how many loops did you decommission last quarter? Mature programs turn off some loops every quarter. Programs that never decommission anything accumulate a maintenance burden that eventually swallows the team's capacity to ship new work.
These metrics are uncomfortable because they expose programs that look busy on dashboards but produce little change in operational behaviour. That exposure is the point. Without it, analytics maturity remains a self-reported attribute, and self-reporting drifts in the same direction as every other PR exercise.
Where to Start if You Are Not There Yet
The mistake most strategies make is starting with the platform. A platform without loops is infrastructure looking for a justification. The sequence that works runs the other way.
Start by picking three loops. Three candidate decision-loops in three different parts of the business. Each one should have a clear question, an identifiable decision-maker, and an action pathway that is technically achievable in 90 days. Rank them by decisions per quarter times dollar impact. Pick one to ship first, two to ship next.
Then ship the first loop end-to-end. Data source to decision to action to outcome. Use the minimum architecture the loop requires. Resist the temptation to build the perfect platform first. The platform grows in response to loops, not the other way around.
After three loops are live, extract the platform from them. When loop two and loop three reveal the same gap (a missing catalog entry, a fragile API, an unmonitored data source), build the component that fixes the gap for all current and future loops. This is how platform investment justifies itself: by removing friction from the next loop, not by speculating about needs that have not appeared.
Name the gates. Each phase ends with a measurable gate: number of loops in production, outcomes tracked, time-to-decision compressed. Crossing the gate unlocks the next phase's budget. Missing the gate triggers a structured review, not automatic continuation. This single discipline prevents programs from drifting from pilot to pilot to pilot for two years without ever crossing into operational impact.
And in parallel, train the operating model. The product owner role for loops. The cross-functional accountability. The outcome-tracking discipline. These are the soft parts that decide whether the technical work compounds or atrophies. They do not show up in architecture diagrams, and they account for most of the difference between programs that scale and programs that stall.
A first loop, scoped well, takes 8 to 12 weeks from kickoff to production. The platform that supports five or six loops takes 6 to 9 months. But only if it grows from the loops. Designed up front, it takes longer and serves less.
Where Silk Data Fits
We have built decision-loops across retail demand forecasting, financial fraud detection, EdTech plagiarism analysis, publishing search and summarisation, and industrial operations. The work tends to follow the same shape: a real business problem with stakes, data that is messier than the slides suggest, and a need for the output to actually drive action rather than sit in a quarterly review.
If you are at the assessment stage, our AI consulting work usually starts by mapping the candidate loops and where the current architecture supports or blocks them. If you are ready to build, our advanced analytics and predictive analytics engagements ship the first loop in roughly 90 days. When the data cannot leave the perimeter, we deploy on-prem, including the local LLM setup we have built for clients with strict residency requirements.
If you want a conversation about whether your problem is a loop problem or a platform problem, write to hello@silkdata.ai. We will tell you when the answer is neither, which happens more often than the consulting industry tends to admit.
