Bringing business data into a consistent reporting layer
How DNA Solutions brought information from several business systems into one reporting layer, with shared definitions and dashboards designed with their users.
BIBusiness reporting
01The situation
The information a management team needed was spread across several business systems. Each system held part of the answer, and putting the answers together took time and manual work.
The same indicator could be calculated in different ways depending on where it came from. The operational systems also had to keep serving the people who relied on them, so reporting could not get in their way.
Before
- Figures gathered by hand
- Definitions differ from report to report
- Slow to answer a new question
After
- Data brought together automatically
- One definition per indicator
- Dashboards built around decisions
02What the teams needed
- The figures that matter to decisions are available in one place.
- The same indicator gives the same answer, whoever looks at it.
- Reporting runs without disturbing the people who work in the operational systems.
- Figures are fresh enough for the decisions they support.
- Dashboards follow the questions users ask.
03How the reporting layer works
The reporting layer works in five steps. The first three prepare the data. The last two turn it into indicators that people use.
- Collect changes
Only records that are new or have changed in each source system are read, instead of copying everything again.
- Prepare
Records are cleaned, matched across systems and brought into a common structure.
- Apply shared definitions
Each indicator is calculated once, from a written definition agreed with the business.
- Publish dashboards
Dashboards present the indicators behind each decision, designed with the people who use them.
- After each release
- Improve with users
Feedback from users leads to new indicators or clearer views, which go through the same definitions.
04One definition per indicator
Without shared definitions, two reports built from the same data can show different figures. Each indicator was therefore defined in writing, agreed with the people who own it and calculated in one place. Every dashboard reads the same result.
Separate calculations
Same figure everywhere
Only what has changed
Reading only new and changed records keeps each refresh small. Processing stays short, and the work asked of the source systems stays limited.
All records
Changed
Processed
05Design decisions
Definitions before dashboards
Agreeing what each indicator means came first. Dashboards then show figures that different teams already accept.
Incremental processing
Processing only what has changed keeps refreshes short and predictable, and limits the load placed on the source systems.
Designed around decisions
The starting point was the decisions users have to make. Indicators and layouts were chosen to support them, then refined with the users.
06How we build a reporting layer with its users
Understand the decisions
Talk with the people who use the figures: which decisions they make, which questions they ask, what is missing.
- Key questions
Define the indicators
Write each indicator down with its definition, its sources and its owner.
- Indicator definitions
Connect the sources
Set up the collection of new and changed records from each business system.
- Incremental collection
Build the reporting layer
Prepare the data and calculate each indicator in one place.
- Reporting layer
Design the dashboards with users
Review early versions with the users and refine them until they support the decisions they were built for.
- Dashboards
07Results
Figures assembled by hand from several systems
One reporting layer across the business systems
Different figures for the same question
One definition per indicator
Slow to produce a report
Reports available sooner
Decisions based on partial figures
Decisions based on shared figures
08When this approach fits
A good fit when
- The figures for one decision come from several systems.
- Teams disagree about which figure is right.
- Reporting must not disturb operational work.
- Several teams need a shared view of the figures.
Probably not needed when
- All the data already sits in one system: its own reporting may be enough.
- A one-off analysis: a dedicated study costs less than a permanent layer.
Questions to ask before a similar project
What we clarify with a company before building a shared reporting layer.
Do the business systems have to be replaced?
No. The reporting layer reads from them. The business systems keep their role, and the people who work in them keep their tools.
Who decides how an indicator is calculated?
The business. We write each definition with the people who own the figure, then implement it once, so that every dashboard uses the same calculation.
How fresh are the figures?
Freshness is agreed per indicator, according to the decision it supports. Reading only new and changed records keeps each refresh short.
Can new indicators be added later?
Yes. A new indicator starts with a written definition, then reuses the data that is already collected and prepared.
Why is this case study anonymised?
We do not publish client names, sectors, systems, volumes or dates for work of this kind. Details about a company’s systems can help attackers, so they stay out of anything public. We describe the method and the result instead.