There is a persistent confusion in the analytics industry between insight and decision support. They are related but not the same thing, and tools designed for one rarely serve the other well.
An insight is an interesting observation about data. A decision is a commitment to a course of action under uncertainty. Decision support is the specific work of making the right decisions more likely.
Most analytics platforms are designed to produce insights. They are excellent at showing you what happened, identifying patterns, and surfacing anomalies. They are poor at translating any of that into decisions — because that translation requires understanding the decision structure, not just the data structure.
What makes a system complex
The word "complex" is overused in technology. When we use it, we mean something specific: systems where:
- Outcomes are determined by many interacting variables, not a few dominant drivers
- The system's state changes based on the decisions made within it — the observer affects the observed
- Information is incomplete, delayed, and often unreliable at the moment decisions need to be made
- The cost of different types of errors is asymmetric — being wrong about an upside is different from being wrong about a downside
Drilling an oil well, pricing a commodity position, planning a logistics network, managing a livestock procurement programme — these are all complex systems by this definition. A dashboard that shows you what happened last month is not decision intelligence for these systems. It is archaeology.
The anatomy of a decision
Every decision has the same basic structure:
- A decision frame — what is actually being decided, and by when
- Available actions — the set of options, including the option of waiting
- Relevant uncertainties — the variables that affect which action is best
- Payoff structure — the costs and benefits of each action under each uncertainty scenario
- Prior beliefs — what we know about the relevant uncertainties before looking at data
Decision support tools should be organised around this structure. Most analytics tools are not. They are organised around the data — tables, charts, aggregations — and leave the user to do the decision framing themselves.
This is not wrong. But it is incomplete.
Designing around decisions
When we design decision systems at 42Analytics, we start with the decisions that actually matter, not the data that is available. The questions we ask first are:
What are the three most consequential decisions this system needs to support? Often the answer is not the decisions the stakeholder names first. Those are frequently the operationally visible decisions (daily pricing, weekly reporting) rather than the structurally important ones (annual capacity planning, supplier concentration risk).
What is the cost of a bad decision here, and which kind of bad decision is more costly? For a drilling programme, the cost of deciding to drill a well that should not have been drilled is very different from the cost of deciding not to drill a well that would have been productive. The system design should reflect this asymmetry.
What information would actually change the decision? This question filters out most dashboards. A volume of data that would not change what you decide is not decision support — it is comfort. We try to identify the variables that are pivotal: the ones where knowing them better would lead to different, better choices.
The feedback loop problem
Complex systems have one feature that makes decision support particularly difficult: the decisions change the system.
A commodity buyer who consistently buys when prices are below a model threshold creates buying pressure at that threshold. A drilling company that relies on a particular analogue-based well planning approach will, over time, exhaust the easy analogues, leaving only the harder cases.
Decision support systems that do not model this feedback will gradually become miscalibrated as the system adapts around them. This is one of the most common failure modes we see in deployed analytics: a model that was excellent in its first year becomes unreliable by its third, not because the model was bad, but because the decision-makers using it changed the system the model was trained to predict.
The solution is not to avoid feedback loops — they are inherent to complex systems. It is to make them visible and to build recalibration into the system design from the beginning.
What this means for tool design
The practical implications for how we build:
Interface design should mirror decision structure, not data structure. The interface for a drilling planning tool should be organised around the stages of a drilling decision — prospect screening, analogue identification, difficulty estimation, campaign planning — not around the underlying datasets.
Uncertainty should be first-class, not an afterthought. If the system can quantify uncertainty, it should show it prominently, not hide it in small print or confidence intervals that nobody reads.
Decisions should be logged, not just outcomes. The hardest thing about improving decision quality is that you rarely have a clean record of what was decided, when, with what information, and what happened as a result. Building decision provenance into the system from the start makes learning from outcomes possible.
The system should have a defined scope of validity and be honest about when it is operating outside that scope. All models fail in some conditions. A good decision support system tells you when you are approaching those conditions.
The gap between analytics and decision intelligence is not a technical gap. The tools to close it mostly exist. It is a design gap — the difference between building what is easy to build and building what actually changes decisions for the better.