Over the past few years we've been involved in a good number of intelligence retrofit enquiries, and what really sends a project off course is rarely technical difficulty — it's the idea of "intelligence" the project was scoped around. Three misconceptions come up most often.
Misconception one: treating "new hardware" as "intelligence"
The most common move is to replace the old machines wholesale, install new ones with screens and network connectivity, and consider the job done. The result is a sharp rise in hardware cost, while the data is still only collected and displayed — it never enters any decision path.
The test is simple: once this is live, whose specific action changed? If nobody works differently, then the equipment was updated, but intelligence was not implemented.
Misconception two: treating "visible" as "decidable"
Big screens, dashboards and live curves are the easiest part of an intelligence project to deliver and the easiest to praise, because they are immediately visible. But a dashboard on its own creates no value: if a screen shows an anomaly and nobody is specifically required to react to it, it soon becomes wallpaper.
| Level | Typical form | Does it create value? |
|---|---|---|
| Visible | Data wall, live curves | Not directly — it is only a precondition |
| Explainable | Anomaly identification, state assessment, alert grading | It starts to — it lowers the cost of human judgement |
| Owned | Named responsibility, handling process, closed-loop records | Truly does — but depends on management keeping pace |
| Predictive | Trend warnings, strategy recommendations | Highest value — but only once the first three are in place |
We often advise customers: rather than jumping straight to the fourth level, make the second and third solid first. Projects that skip levels usually end up back at the starting point.
Misconception three: treating "one-off investment" as "total cost"
The cost structure of an intelligence system is very different from that of ordinary equipment. Buying hardware is a one-off; for an intelligence system the bulk of the cost comes later: data maintenance, model calibration, system iteration and staff training. If only the build cost was budgeted, two years in you tend to reach the awkward point of "can't afford to run it, can't maintain it".
- Build cost: hardware, software, integration and implementation
- Running cost: data quality maintenance, periodic model calibration, system monitoring
- Evolution cost: functional changes and redevelopment driven by the business
- Organisational cost: staff training, process redesign, clear ownership
What actually needs budgeting isn't the system — it's the thing that keeps the system useful.
Back to a more basic question
Avoiding all three misconceptions really only takes answering one question at kick-off: which specific decision do we want this system to make faster, or more accurately?
Answer that clearly and the technology choice, the scale of investment and the acceptance criteria all fall into place. Answer it vaguely, and however advanced the technology is, the likely outcome is simply one more layer of complexity in the same place.