1. What we actually solve
- “Closing the monthly report takes us three days.” Exports from several systems, pasted and formatted by hand, always by the same person and always at the last minute.
- “Everybody turns up to the meeting with a different number.” And the meeting goes on arguing about the figure instead of deciding what to do.
- “By the time we have the data, it is no longer useful.” Information from three weeks ago for this week’s decisions.
- “We have data, but we do not know what to look at.” Hundreds of fields and not one agreed metric.
- “If somebody asks where that number comes from, the path has to be walked again.” And because it is costly, people stop asking, which is the worst thing that can happen.
2. How it works
A pretty dashboard on top of data nobody has organised lasts three weeks. What gets built underneath is what makes it hold:
- Connection to the sources. ERP, production system, CRM, spreadsheets if need be. They read themselves, at whatever moment is right; nobody exports anything by hand.
- A common data model. The entities of the business — customer, order, part number, work order — defined once, with their relationships. It is the part you do not see and the one that decides whether the project ages well.
- Scheduled calculation and refresh. At whatever frequency the use requires: on the fly if it drives an operational decision, once a day if it feeds a report.
- Dashboards by role. The board, the shop floor and sales do not need the same five figures, and giving all three the same screen is the fastest way to ensure none of them uses it.
- Traceability to the source. You click on a number and reach the record that produced it. That is what turns an argument into a check.
We usually build the visualisation layer in Power BI: it is where our track record is and, in practice, where most industrial companies already hold licences by being on Microsoft 365. If you already use another tool and it works for you, the project goes on top of that one: what decides is not our preference, it is which licences you already pay for and who is going to maintain this once we are gone.
And a warning worth hearing before buying anything: the dashboard tool is the easy part and the one that decides least. A Power BI wired straight into five sources with no data model underneath works for the first month and becomes ungovernable by the third, once every report has solved the same metric its own way.
Put side by side, the change is easier to see. Notice that the source data is the same: what disappears is the work in the middle.
- Export from each systemERP, production, the team’s spreadsheet
- Paste, reconcile and formatTwo or three days a month, always the same person
- Send the reportWith last month’s data
When somebody asks why a number does not add up, the whole path has to be walked again to find out.
- The sources read themselvesThe same systems, with nothing exported by hand
- One common data modelEvery metric defined once and in one place
- It calculates and refreshesAt the right hour, with nobody launching it
- The dashboard is up to dateAnd you can drill down to the source record
↳ When a number does not add up, you click through and reach the record that produced it. It stops being an argument and becomes a check.
The team moves from building the report to reading it, which is what it is paid for.
Both paths run at the same time and on the same time scale: the top one is still on its second step when the bottom one has already finished and is waiting. The proportions are illustrative — what we claim is that one takes considerably longer than the other, not exactly how much longer in your case.
3. One metric, one definition
It is the least glamorous part of the project and the one that decides whether it is worth anything. In almost every company we walk into, the same word means different things depending on who is using it: “order fulfilled” can mean when it leaves the warehouse, when the customer signs for it or when it is invoiced; “scrap” may or may not include reworked material.
Until that is agreed, every report will keep giving a different number, and rightly so. So it is part of the work: the definitions get written down, agreed with whoever has the authority to agree them, and implemented once, in the model and not in each dashboard.
It is usually the most uncomfortable conversation of the project and the one that leaves the most value behind, even if no dashboard were ever built.
4. Typical cases
Industrial analytics is where we come from: our clients are in discrete and process manufacturing — automotive, food and drink. The others are patterns that repeat in any sector.
Manufacturing: automotive, food and drink
Production is tracked with job sheets and spreadsheets, and the real performance of each line is calculated after the fact. By the time a deviation is spotted, the shift that caused it finished days ago.
Plant indicators calculate themselves from data that is already being recorded, and the deviation is visible the same day.
The board
The committee receives a report assembled by hand, with data from the closed month. Decisions are made on an old photograph, and half the meeting goes on reconciling figures.
A dashboard with the agreed metrics, up to date and with the same number for everybody.
Sales
Pipeline lives in the CRM, margins in the ERP, and nobody cross-checks them except at month end. The product that sells most gets pushed, not the one that leaves the most margin.
Margin by customer and by part number in plain sight, cross-checking both sources with no manual work.
5. What you need before we start
- The data has to exist. It sounds obvious and it is not: if downtime is not recorded anywhere, no dashboard is going to show it. Sometimes the first project is starting to capture it.
- Access to the sources. API, database or scheduled export, whatever each system allows.
- Somebody with the authority to close the definitions. Without that, the metrics stay in permanent debate.
- A handful of specific questions. “We want to see everything” is not a requirement, it is the absence of one. Five well-put questions are enough to build something useful.
- Accepting that the first result will be uncomfortable. Measuring properly almost always uncovers something people preferred not to look at. That is the sign it is working.
6. When this is NOT the answer
- There is no decision behind it. An indicator nobody is going to use to decide anything is an expensive ornament.
- The source data is wrong and nobody is going to fix it. A dashboard on dirty data does not inform: it legitimises the error and distributes it faster.
- A monthly report is enough. If the decision is monthly and the report works, building real time is overspending.
- What is needed is to sort out the process. Measuring a process nobody runs the same way twice produces correct numbers about a mess, which is still a mess.
7. How the return is measured
- Hours per month that stop going into assembling reports, with their equivalent cost. It is the first thing anybody notices.
- Time to data: how long it takes from something happening to it being visible. It is often worth more than the hours saved, because it shortens the reaction cycle.
- Decisions that change on seeing a number that was not visible before. It is the hardest thing to quantify and usually what pays for the project.
- Arguments about figures avoided in the meetings where something had to be decided.
The full framework is in how the return is measured in the guide.
Note: this page is for information only; it is not legal advice nor a guarantee of results. The figures quoted are usual ranges in real projects, not contractual commitments, and they depend on the scope and the starting point of each company.
8. Frequently asked questions
What is the difference between a report and a dashboard?
A report is a photograph somebody assembles and sends; a dashboard is a live source that refreshes itself and lets you drill down to the source record. The practical difference shows up when a number does not add up: with the report the path has to be walked again to find out why, with the dashboard you click through and reach the record that produced it.
Do we need to build a data warehouse?
Not always. For a few sources and normal SME volumes, a well-defined data model over what already exists is usually enough. A warehouse is justified when the volume, the number of sources or the need to keep history call for it, and then we say so. Building one by default is one of the most expensive ways to start a BI project.
Which tool do you build dashboards in? Can you use the one we already have?
Yes, and it is the first thing we look at: if you already pay licences for something that works, the project goes on top of that. We usually work with Power BI, which is where our track record is and where most industrial companies already hold licences by being on Microsoft 365, so if nothing is in place it tends to be the shortest route. What decides is which licences you already have and who is going to maintain this afterwards, not the supplier’s preference.
And if our data is wrong?
It shows up in the first week, always. What matters is what happens then: a dashboard on dirty data does not inform, it legitimises the error and distributes it faster. If the data quality is not there, the first project becomes fixing the source — or starting to capture what is not being recorded — and we say so even if it is an uncomfortable conversation.
How long until the first dashboard?
A dashboard scoped to a handful of specific questions is usually running in three or four weeks. What stretches the timeline is almost never building it: it is agreeing what each metric means and getting access to the sources.
Is this artificial intelligence?
Most of it is not, and that is worth saying. Connecting sources, modelling data and calculating indicators is ordinary data engineering, and it is what resolves ninety per cent of cases. AI comes in when free text has to be interpreted, patterns detected or a deviation anticipated, and then it is added on top of a base that already works. The other way round rarely goes well.
Services that usually go with this one: systems integration · AI strategy consulting.