The standard flow of analytics in most organisations goes like this. An executive has a question. They send it to an analyst. The analyst adds it to a queue. A few days later — sometimes longer — the answer arrives. By then, the meeting has happened. The decision has been made. The number arrives after the moment it was needed.

This is not a failure of the analyst. It is a failure of the architecture — a system designed around the assumption that analytical questions require technical intermediaries. That assumption was true when it was built. It does not have to remain true.

Why the analyst dependency exists

The dependency exists because most analytical tools require technical knowledge to operate. Querying a database requires SQL. Cleaning a dataset requires scripting. Building a chart requires understanding data structures. Non-technical executives cannot do any of these things — not because of any personal limitation, but because these are specialised technical skills that take years to develop.

The analyst sits between the executive and the data not as a gatekeeper but as a translator. They convert business questions into technical operations and technical results into business language. That translation is necessary when the tools speak only one language. When the tools speak both, the translator is no longer required.

The analyst is a symptom of tools that were not designed for the people who need the answers.

What self-service analytics actually requires

The phrase "self-service analytics" has been used to describe tools that are merely less technical — dashboards that non-technical users can read, but not query. Filters that can be applied, but not defined. Charts that can be viewed, but not created from scratch.

True self-service analytics — where an executive can ask any question of any dataset and receive a trusted answer without any technical involvement — requires three things that most tools do not provide simultaneously.

What true self-service analytics requires

  • Automatic data understanding — the tool reads any structure without configuration
  • Natural language interface — questions asked in plain English, not SQL
  • Certified answers — results that can be trusted without independent verification

The third requirement is the one most self-service tools fail. An AI tool that lets you ask questions in plain English but cannot guarantee its answers are correct has not eliminated the analyst dependency — it has hidden it. Someone still needs to verify the output before it reaches a decision-maker.

The verification trap

Many organisations have deployed AI analytics tools with the expectation of reducing analyst workload. What they have discovered is that the workload does not reduce — it shifts. Instead of analysts producing answers, they spend their time verifying answers that AI tools produced.

This is the verification trap: the tool generates results quickly, but those results cannot be trusted without review, so a technical person still has to be in the loop. The speed benefit is real. The independence benefit is not.

What eliminates the dependency

The analyst dependency is eliminated when the answer is certified before it leaves the system. When the formula is fixed, the computation is validated, and the result is traceable — the executive does not need a technical person to verify it. The verification happened at the architectural level, before the question was asked.

This is a different design philosophy from most analytics tools. It requires more work upfront — defining and certifying the metric library — and produces a different outcome: answers that executives can use directly, without review, without verification, without an analyst in the room.

What this changes

When executives can ask questions directly and trust the answers, the role of the data analyst changes. The analyst is no longer a translator between business questions and technical systems. They become what they should always have been — an investigator of the things the certified system flagged as interesting, a builder of more sophisticated analyses, a strategic resource rather than an operational bottleneck.

The goal is not to replace data analysts. It is to free them from the work that a well-designed system should handle automatically — so that their expertise is available for the problems that actually require it.