How do we see data analytics?

Data analytics is one of the biggest topics in business today. But what is it, really? Ask Wikipedia and you will find a definition worth pausing on:

Data analytics is "a process of inspecting, cleansing, transforming and modelling data with the goal of discovering useful information, informing conclusions and supporting decision-making." — Wikipedia

Two very simple words with a very big meaning. When we talk to accountants and finance teams about data analytics, the conversation almost always jumps straight to programming languages, apps and dashboards. We think that skips the most important part. Below is how we see data analytics, and why the purpose matters far more than the toolset.

What is data analytics, really?

Strip away the software and data analytics is simply a disciplined way of turning raw data into a decision. The definition names four moves — inspecting, cleansing, transforming and modelling data — but every one of them exists to serve a single end: discovering useful information, informing conclusions and supporting decision-making. In other words, to make a difference.

If a piece of analysis does not change what someone decides or does, it has not really achieved anything, however clever the method behind it. That is the test we come back to whenever a project starts to drift toward complexity for its own sake. The value of analytics is measured at the point a decision is made, not at the point a chart is produced.

Why should data analytics start with a purpose?

Nowadays, when people talk about data analytics, they often start with the code, the programming language or the app. We believe the purpose comes first.

You can find many different proposed process flows for data analytics, and most of them are perfectly reasonable. But we believe more in starting with the difference you want to make. Many organisations we have seen began this journey without first defining that difference. Our advice is not to rush into choosing a tool. Define the problem the organisation is facing first.

Only once the problem is clear does it make sense to work out how to collect the right data, execute the work, process it and interpret the result. A clear problem statement is what keeps every later step honest, because it tells you what a good answer would even look like.

How should you plan the data steps together?

These steps happen one after another, but they should be planned together rather than in isolation:

• Define the problem you are actually trying to solve.
• Collect the right data — no more, and no less, than the problem needs.
• Execute and process that data in a way you can repeat and check.
• Interpret the result against the decision you set out to make.

Planning them together matters because a gap at one stage cannot always be fixed at a later one. In practice, three collection mistakes come up again and again:

• Collecting data you do not need in the end is a waste of resources.
• Collecting too little data leaves the analysis thin and inconclusive.
• Missing out a dimension entirely can make the analysis less meaningful, or even useless.

Because a shortfall at the collection stage cannot be repaired at the interpretation stage, it pays to design the whole sequence up front. Decide what conclusion you are trying to reach, then work backwards to the data and the processing that conclusion requires.

Does the tool really matter?

What about the tools themselves? We could not emphasise enough that data analytics tools — the programming code, the programs, the apps — are enablers. They help an organisation move through the process; they are not the process itself. Plenty of tools can perform very complicated analysis, but the real question is whether you actually need that complexity.

Once you have a plan for collecting, processing and interpreting your data, think about which tool can take the tedious work off your hands. Our advice is simple: use only the tools that you genuinely understand. A tool you cannot explain is a tool you cannot check, and unchecked output is where analysis quietly goes wrong.

What happens when you use a tool you do not understand?

Consider a control reviewer who performs a correlation between two general ledger accounts — say revenue and receivables. He uses a new tool his firm has just invested in, feeds in the data, and the report tells him the two accounts show a 20% relationship. Does that mean 80% of the movement is an anomaly?

Not necessarily. What had actually happened was that the tool used the batch number as the identifier to group transactions together. Had the reviewer understood this beforehand, he would probably have chosen a different identifier, because a single batch of journals can contain entries that have nothing to do with revenue.

The number was not wrong; it was answering a different question from the one he thought he had asked. That is the risk of trusting output from a tool you have not taken the time to understand — it looks authoritative long before you have any reason to believe it.

When is Excel enough?

There is also a quiet assumption that serious analysis demands specialist software. It often does not. If you are investigating a problem that involves a small data set, or something you only need to look at on a one-off, non-routine basis, the chances are that Excel is more than sufficient. Reaching for a heavier platform than the question warrants adds cost and complexity without adding insight.

The point is not that big tools are bad. It is that the tool should be sized to the problem, and a problem you can hold in a single spreadsheet rarely needs anything more.

The takeaway

A tool does not do wonders if you do not know how to use it. Treat data analytics as an enabler, not as a data analytics textbook to be recited. Start from the difference you want to make, plan collection and interpretation together, and choose the simplest tool you fully understand.

For accountants weighing where analytics sits alongside the rest of their work, it is part of the broader shift in how the profession is preparing for the future. It is also a reminder that judgement — not the software — is still what turns data into a decision, and that judgement remains central to the accountant's evolving role.