Why dashboards disagree
A common frustration: the sales dashboard shows one figure, the finance report shows another, and a spreadsheet someone built last year shows a third. The cause is rarely that anyone is careless. More often the three outputs draw on different systems, refreshed at different times, using different rules for what counts.
Better business intelligence therefore starts well below the dashboard, with the way data moves from the systems where it is created to the place where people read it. This article describes that plumbing in plain terms. How a central team compares with self-service use is covered separately; here the focus is on the technical layer that either model depends on.
Source systems
Most organizations create data in many places: an accounting package, a customer relationship tool, an order system, an HR system, a website, plus spreadsheets. Each is designed for its own job, not for reporting. They may:
- use different identifiers for the same customer or product
- store dates, currencies and units in different formats
- be updated at different times
- hold overlapping or contradictory records
Reporting directly against each of these separately means every report has to deal with the mismatches itself, and each report may deal with them differently.
Integrating the data
Integration brings data from several sources into a shared, reporting-friendly form. Common building blocks include:
Extraction. Data is copied from source systems on a schedule or as changes happen. Copying, rather than querying live systems repeatedly, protects operational systems from heavy reporting loads.
Transformation. Data is cleaned and reshaped: formats are standardized, duplicates are resolved, codes are translated and records are matched across systems. This is where much of the real work lies.
Storage. The result is held in a central store, often called a data warehouse or similar. It is organized around business subjects such as customers, orders and products so that people can ask questions without knowing how each source system is laid out.
Delivery. Dashboards and reports read from that store rather than from the source systems.
The sequence is usually called a pipeline. Pipelines run automatically, but they need monitoring, because a failed overnight load can mean that morning’s dashboard shows yesterday’s figures without any obvious warning.
Consistent definitions
Technical integration is not enough on its own. If two teams still disagree on what “active customer” means, a shared store simply holds both disagreements in one place.
A shared definition normally covers:
- the precise calculation, including filters and exclusions
- the source data used
- the time period and the cut-off rule
- the owner who decides changes
- the date and reason for each change
Writing definitions down and applying them in one place, rather than in each report, is what produces consistent numbers. The detailed practice of metric definitions deserves its own attention, and master data management addresses the related problem of keeping a single trusted record for entities like customers and products.
Data quality at the foundation
An integrated platform can spread poor data quickly. Typical problems include missing values, duplicate customer records, inconsistent spelling of names, and entries typed in the wrong field. Checks built into the pipeline, such as row counts, range tests and reconciliations back to source totals, help catch problems before they reach a report. Common data quality issues are worth learning to recognize because they often show up as odd-looking totals before anyone investigates.
What centralization adds, and what it costs
Potential benefits
- Reports from different teams are more likely to agree because they use the same data and definitions.
- Common logic is maintained once, not repeated in many reports.
- Access rules can be applied in one place.
- Analysts spend less time reconciling numbers and more on analysis.
- A history of data can be kept in a consistent form for trends.
Potential costs and risks
- Building and maintaining an integration layer takes skilled people and sustained funding. Costs vary a lot with the number and complexity of sources.
- A central model can become a bottleneck if every new data source or field requires a queue for the same small team.
- A fault in the central pipeline can affect every report at once, which is the single point of failure problem.
- Some sources, such as legacy systems, may be hard to connect, and the choice of tools raises questions about system interoperability and vendor lock-in.
- Overnight batches mean data is not always current. Some uses need faster updates, which adds complexity.
A simple illustration
Imagine a company where the order system records an order when the customer confirms it, and the accounting system records revenue when the invoice is issued. A sales report built on orders shows 120 for the month; a finance report built on invoices shows 105. Neither is wrong; they measure different events and the 15 unit gap reflects orders confirmed but not yet invoiced. (These figures are invented for illustration.) Without a shared definition and a shared data layer, the two reports look like a conflict. With them, both numbers can be presented side by side with labels that explain the difference.
Governing the layer
Integrated data needs ownership. Typical elements are data stewards who look after specific subjects, a process for requesting changes, documented lineage showing where each figure came from, and periodic reviews of whether the platform still serves its users. The wider topic of data governance supplies the structure; BI is one of its main users.
Practical sequence
- List the key reports and the source systems each depends on.
- Find the places where the same term is calculated differently.
- Agree and document definitions for the most important measures first.
- Integrate the highest-value sources before attempting all of them.
- Add automated checks and monitoring from the start.
- Review use after launch and retire reports nobody opens.
Centralized systems can give business intelligence a more dependable base, but they do not remove the need for judgement, clear ownership and ongoing maintenance. Technical choices depend on your own systems and constraints, so involve qualified data and IT professionals when planning.