You know which daily working decision the view, filters and detail should support.
Dashboard development →OXIAE / INTEGRATIONS & DATA
Business intelligence consulting.
Agree on business questions, calculations and the sources behind your figures.
Discuss your projectA dashboard question: where do you start?
You first need to define the business questions, indicators and model behind the reporting.
Business intelligence consulting (this service)Your question starts with shared KPIs, trends and exceptions for management discussions.
Management dashboard →UNDERSTAND THE SERVICE
What does a business intelligence consultant work through with you?
Business intelligence connects a business decision to the information needed to make it. I work with you to define the question a report must answer, what its measures mean and how they are calculated from the sources. You receive agreed definitions, an appropriate reporting model and checks an operator can use to trace the results. The engagement can start with one disputed measure or a limited reporting area; a new dashboard or data platform is not an automatic starting point.
When it is a good fit
This fits when departments calculate the same measure differently, figures change after combining sources or nobody can explain the selection behind a report. A business owner must be able to decide what the organisation means by a measure. If the required information is not yet available, data integration can supply the model with sources.
When to take a different approach
If definitions and calculations have already been checked and the main question concerns screens, filters and daily work, consider dashboard development. Shared measures, review meetings and follow-up on management decisions belong to a management dashboard. A model cannot reliably invent missing events or unknown source history after the fact.
PRACTICAL DECISION GUIDE
Business intelligence needs shared definitions before charts
A BI engagement starts with the questions an organization needs to answer. I work with teams to establish their definitions of revenue, active customers or capacity. Differences are resolved explicitly or made visible before figures from several systems are combined. [1]
We then design the analytical model, ingestion and refresh. Each number remains traceable to period, selection and source. Delivery therefore includes a glossary and checked examples. Final users assess visualizations by the decisions they support as well as their presentation. [2][3]
Questions to settle first
- Where do departments use different definitions for the same term?
- Which analysis needs detail and which only an aggregate view?
Make acceptance measurable
- An approved glossary and reconciled key figures.
- A user session demonstrating that the model answers decision questions.
Fictional metric check — not a customer case
Why does €300 become €400 after a join?
This original illustrative example checks one modelling choice. The amounts are test data only; they describe no customer, revenue result or complete financial report.
Define the measure and selection
The test question is the total recorded order amount of two selected orders in one fixed source snapshot. Order A has an order amount of €100 and order B €200, both in the same currency. The agreed check counts each order ID once: €100 + €200 = €300.
Check what one record represents
The order table contains one record per order ID. A separate line table has two lines for A and one for B. Its records therefore describe order lines; the order amount remains an order-level value.
Expose the double counting
Directly joining every line to its order repeats A twice. Summing the repeated order amounts then gives €100 + €100 + €200 = €400. The order source has not changed; the chosen join changes the level at which the values are summed.
Calculate at the agreed order grain
Calculate this measure from a selection with one record per order ID. If this order-level calculation uses information from the line table, first summarise that information per order. A separate detail view may still display individual order lines. Do not deduplicate amounts: separate orders may have the same amount. Allocating an amount across products requires a separate calculation rule.
Keep a repeatable reconciliation
Compare the selected order IDs, amounts and total with the same source snapshot. Also check unmatched keys and repeated IDs. Keep the selection, model version and expected test result so a later change can be assessed again.
What the process delivers
In this test, the two selected order IDs still total €300. The check exposes one possible modelling error; it does not assess every definition, source problem or measure in a production environment.
How to test this example
- The incorrect join is reproducible and yields €400 in this test; calculation at order grain yields €300 for exactly A and B.
- An additional line for A does not change the order total while the order amount and agreed selection stay the same.
- Give two separate test orders the same amount: both must still count. This exposes deduplication by amount instead of order ID.
Compare your options
Choose based on the task, the people involved and what you can maintain.
| Approach | Useful when | What to consider |
|---|---|---|
| Review an existing report | A specific figure differs or is insufficiently explained. | Compare the definition, selection and source records before commissioning a new model or screen. An explained difference is not necessarily an error. |
| Define measures and a reporting model | Several reports need to share meanings, calculations and breakdowns. | Requires business decisions about date fields, statuses, corrections and record grain. Screen development is scoped separately. |
| Make sources available first | The selected question is clear, but required data or history is missing from the reporting environment. | Establish what access and processing are possible. An additional connection does not automatically complete missing source records. |
What I need to start
- A concrete business decision, the people who need the answer and a business owner who can approve measure definitions.
- A meaning, unit, formula, included records, date field, period and reference point for each measure. Define how missing values, corrections and late-arriving records are treated; for a percentage, also define a numerator and denominator within the same agreed scope.
- Representative source examples with stable keys and known exceptions. Specify what one record represents in each table, which keys must be unique and how relationships can repeat or exclude data.
- A lineage map of source fields, transformations and calculations, with sufficient access to repeat the agreed checks. For dependencies across systems, software architecture can establish the technical boundaries.
- Agreements on refreshes, access, definition changes and maintenance. Decide whether a correction may change earlier reports and how an earlier report remains explainable.
How to assess the result
- The business owner reviews examples of records that are included and excluded. The documented definition supports the agreed business decision.
- An agreed check can be repeated with the same source selection, reference point and model version. Results are traceable to records; an equal final total alone is insufficient.
- Checks identify unexpected repetition through relationships, missing keys and unmatched records. The agreed handling of these exceptions is visible.
- Breakdowns and period comparisons use the agreed meaning. A new definition or changed source history does not silently alter the comparison basis.
- Handover includes measure definitions, model relationships, source lineage, check questions and instructions for a failed refresh or changed source. Owners and required permissions are documented.
SCOPE & INVESTMENT
What determines the cost?
A useful estimate starts with the scope. I distinguish development work from recurring usage and operating costs. These are the main drivers:
- The number of decision questions, measures, sources and required breakdowns within the selected reporting area.
- Investigation of existing calculations, source differences, history and exceptions; plus the extent of model changes and repeatable checks.
- Reviewing one existing measure has a different scope from creating a shared model. Screen design, source connections and correcting source recording are estimated separately.
- Licences, hosting, refreshes, support and maintenance after handover are agreed separately. A fixed price requires an understanding of the selected questions and available sources.
APPLICATION AND SCOPE
Your challenge.
A practical application.
Illustrative scenario; not a published client case.
Many figures are available but do not adequately answer management questions.
Business intelligence starts with a management question and agreed definitions for the figures. Data integration makes the required sources available. A management dashboard is then one possible presentation format; choose indicators and breakdowns based on the decisions users need to make.
THE QUESTION I ASK FIRST
Which decisions should the reports support?
Agree the first step
Use the prerequisites, acceptance checks and cost factors above to define your assignment. Agree who can approve the outcome and who will maintain the solution. The project approach explains discovery, delivery and handover.
Read the project approachQUESTIONS ABOUT THIS SERVICE
Your questions.
Clear answers.
Do we need to choose a new BI platform?
Not necessarily. I first assess which question the existing environment needs to answer and where the constraint lies. A corrected definition, calculation or model relationship may be sufficient. A platform decision follows when access, modelling, use or maintenance demonstrably requires different capabilities.
Why do two reports disagree?
They may use different date fields, statuses, source versions or exclusions. A connection may also count one source record more than once. We first compare the same definition and source selection, then investigate record-level differences; two equal totals do not prove that all records were processed correctly.
What does the grain of a reporting model mean?
It describes what one record represents, such as one order, one order line or one daily inventory position. An order amount repeated for every order line cannot simply be summed without further rules. The model must support calculation at the level appropriate to the measure.
What is handed over so we can check figures ourselves?
The agreed handover includes measure definitions, source fields, model relationships and repeatable checks with expected results and exceptions. We establish who maintains definitions and who reviews an outage or source change. Creating dashboards and ongoing maintenance are included only when separately agreed.
Sources and technical basis
These primary sources explain the technical principles behind this guide. The project recommendations are OXIAE’s interpretation; they do not imply endorsement by the publishers. Product documentation applies to the named platform.
- Understand star schema and the importance for Power BIMicrosoft Learn
Technical basis for an explicit analytical model.
Link and relevance checked: - Tips for designing a great Power BI dashboardMicrosoft Learn
Audience and information selection in dashboard design.
Link and relevance checked: - Data on the Web Best PracticesW3C
Provenance and quality as part of data use.
Link and relevance checked:
YOUR NEXT STEP
Prepare your project conversation.
Exploring Business intelligence consulting? Use the project checklist to describe your task, systems and intended outcome. Collect open questions and download a brief for your conversation.
Create your project brief