Data, AI & Analytics

A dashboard is only worth building if somebody opens it on a Tuesday without being asked to. So we start from the other end: the questions you already ask every week, the ones that currently get answered by somebody exporting a file and squinting at it. Those questions decide what gets built. It usually turns out to be a small number of views rather than a library, and the small number is the part that gets used.

In practice that means one screen per decision, not one screen per department. Whoever runs operations gets what is late and what is about to be. Whoever owns the money gets what came in, what went out, and what has been promised. You get the handful of figures that tell you whether the month is going the way you think it is. Nobody has to learn somebody else's screen to find their own number.

Then the unglamorous half, which is most of the value. It updates on its own, on a schedule you choose. If a source stops feeding it, you hear about that, rather than quietly reading a stale number for a fortnight. It works on a phone, because a view that only opens on a laptop gets looked at once a week and a view that opens on a phone gets looked at in the car park before the meeting.

And every figure can be traced back to where it came from. That sounds like a technical nicety and it is actually the thing that decides whether a report survives its first disagreement.

The information already exists. It is in the system that takes the orders, the one that tracks the stock, the one the accountant lives in, and a spreadsheet somebody maintains that is quietly more important than any of them. Bringing it together means getting all of that into one place, in one shape, on a schedule, without a person in the middle doing it by hand every week.

Most of the real work is in the joins. The same customer is spelled three ways across three systems. An order exists in one and has not reached the other yet. A date field means ordered over here and shipped over there, and nobody ever wrote that down. Deciding what counts as the same thing is the part that takes judgement, and it is the part that determines whether anyone believes the finished article.

Then there is running it. The schedule, the retry when a system is briefly unavailable, and the alert when one goes quiet for long enough to matter. That last one earns its keep more than it sounds like it should. The failure that hurts is not the one that stops with a loud error. It is the one that keeps producing a number that stopped being true on Tuesday.

We also try to move as little as possible. Every field copied out of a system is a field somebody now has to keep correct in two places. Where a question can be answered without moving anything, we would rather not move it.

This is the part that gets underestimated, and it is the part that decides whether any of the rest was worth doing. A report built on data nobody believes does not get politely ignored. It gets argued with, then worked around, then abandoned, and whoever suggests a dashboard next inherits that history.

The work has two halves. The first is cleaning what is there: the duplicate records, the gaps, the field that three people fill in three different ways because nobody ever agreed what it meant. The second is changing whatever produces it. If the form that created the mess is still sitting there untouched, the mess is back within a quarter, and you have bought a clean-up rather than a fix.

The change at the source is usually smaller than people brace for. A dropdown instead of a free text box. A field that was optional becoming required. One step that two teams did differently until somebody sat them down and asked them to agree. None of that is a technology problem, which is exactly why it tends to get left alone, and why so much of the value is sitting in it.

The last piece is writing the rules down. What counts as an active customer. Which date a sale belongs to. How a refund is handled, and what it does to last month's figure. Those definitions are the real product. Once they are agreed and written, two reports stop disagreeing, because they are finally answering the same question.

With enough clean history behind it, the same data starts telling you something about what is coming. Which stock is going to run out and when. What cash looks like in six weeks. Which customers have gone quiet in the particular way customers go quiet a few months before they leave.

This is also where we say no most often, and it is worth being plain about why. A model trained on thin or dirty history does not fail loudly. It produces a confident, specific, wrong number, and a confident wrong number is worse than no number at all, because people act on it. Sometimes the honest answer is that you need another year of recording something properly before the question is worth asking.

Where it is worth doing, we keep it boring on purpose. A forecast nobody can explain does not get used for anything that matters, so we favour approaches whose reasoning fits in a sentence, we show the range rather than a single figure, and we check it afterwards against what actually happened. A forecast nobody scores is just a guess with better typography.

And it stays in its place. The model suggests, the person decides. Anything that would act on its own, reordering stock or emailing a customer, gets built as a flag for someone to approve, and stays that way until it has earned more.

Bringing data together has a side effect worth naming out loud: it concentrates it. Information that used to be awkward to reach, because it was spread across four systems, becomes easy to reach because it is now in one. That is the entire point of the exercise, and it is also the risk, and both of them arrive on the same day.

So access is part of the build rather than something bolted on at the end. Salary figures, customer records, anything a regulator takes an interest in, each get their own boundary instead of quietly inheriting whatever the reporting tool does by default. Most people need their own numbers and their team's. Very few need everything, and the list of who does should be short enough to say out loud.

Retention is the other half, and it is the half that gets forgotten. Data you no longer need is not neutral. It is something you are still responsible for. So we agree what is kept, for how long, and what happens to it at the end, and then we make that run on its own rather than depending on somebody remembering.

All of this is far cheaper at the start than as a retrofit. Putting access rules on afterwards means telling people they are losing a view they have had for a year. That is a conversation, not a configuration change.