02 / Business intelligence
Business Intelligence Consulting & BI Services
Business intelligence turns raw data into dashboards and reports a business can act on with confidence. Quorlytic aligns metric definitions across teams, builds governed semantic models, and delivers Power BI, Tableau or Looker dashboards designed around one specific decision rather than a general-purpose chart.
By QuorlyticUpdated
Make reporting a dependable part of how your business operates. Start with the decision and the metric definition, then build the model, dashboard and ownership needed to keep them useful.
The business problem
Revenue can mean invoiced, recognized, booked or collected. When dashboards disagree, prettier visuals will not solve the underlying ambiguity. Agree the calculation, grain, exclusions, time zone and owner before designing an executive view.
What we build
Define reusable measures, relationships and dimensions that match the business. Check slowly changing attributes, returns and currency conversion. Keep logic in governed models rather than scattered across spreadsheets and individual reports.
The outcome
Metric dictionary with accountable owners
When this is the right engagement
Symptoms that bring teams here.
BI problems rarely present as BI problems. These are the symptoms that indicate the definition layer, not the chart layer, is where the work is.
Two dashboards show different numbers for the same measure
The calculation has been implemented more than once, and no version is authoritative.
A meeting spends its first ten minutes arguing about the data
The figure is not trusted, so the decision the meeting exists for does not get made.
Analysts rebuild the same logic in spreadsheets
The governed model does not answer their question, so a parallel and unmanaged one has appeared.
Nobody can say whether revenue means invoiced, recognised or collected
The metric has no owner and no written definition, only an implementation.
Report count grows but decisions do not change
Dashboards are being built for a topic rather than for a decision.
Refresh failures are noticed when a report looks stale
Refresh state is not surfaced to the consumer, so trust erodes invisibly.
Capability model
From raw data to a decision.
BI is a consumption architecture: five layers between a stored row and a decision someone is accountable for. Select a layer to see what it is for and what breaks in it.
01 — Curated data
Governed tables at a known grain, with history handled deliberately, so measures are calculated on stable ground.
What it produces
Stable, documented tables that measures can be defined against.
What usually goes wrong
- Reporting built directly on source replicas
- Grain mismatches that double-count on join
- Returns, cancellations and restatements handled inconsistently
Technologies in this stage
- Warehouse models
- dbt
- Dimensional design
02 — Semantic model
Define measures, relationships, hierarchies and access once, so every report reuses them instead of re-deriving them.
What it produces
One certified definition per business measure, with an owner.
What usually goes wrong
- Measures duplicated per report with small differences
- Relationships that produce ambiguous filter paths
- Row-level security applied per report rather than in the model
- Model changes released without review
Technologies in this stage
- Power BI semantic models
- LookML
- dbt metrics
- Tabular models
03 — Metric definitions
Write down what each measure means in business terms: calculation, grain, exclusions, time zone, restatement policy and owner.
What it produces
A metric dictionary that a new analyst and a retrieval system can both read.
What usually goes wrong
- Definitions agreed verbally and then drifting
- Exclusions that vary by team
- Fiscal calendars and time zones left implicit
Technologies in this stage
- Metric dictionary
- Certified datasets
- Change review
04 — Decision surfaces
Build each view around one audience, one question and one action, with refresh state and definitions visible in context.
What it produces
Views tested with the people who will use them in the meeting they belong to.
What usually goes wrong
- Dashboards designed as a chart inventory
- Drill paths that lose the filter context
- Accessibility treated as a colour choice at the end
Technologies in this stage
- Power BI
- Tableau
- Looker
05 — Adoption and ownership
Make the model survive contact with the organisation: certification, a change process, and a boundary around self-service.
What it produces
A named owner, a publishing boundary and a documented change path.
What usually goes wrong
- Uncertified reports contradicting certified ones
- No route to propose a new measure, so people build their own
- Deprecated measures left in place indefinitely
Technologies in this stage
- Certification
- Access model
- Change process
- Runbook
Illustrative reference architecture
Reference architecture
The consumption path from curated data to a decision. The semantic layer is drawn as the narrow point deliberately: it is the control that stops the same measure being calculated four ways.
Curated models
Governed tables at a declared grain.
- Facts
- Dimensions
- History policy
Semantic layer
Measures, relationships and access defined once.
- Measures
- Relationships
- Row-level security
Metric definitions
The written meaning behind each measure.
- Calculation
- Grain
- Exclusions
- Owner
Decision surfaces
One audience, one question, one action.
- Executive
- Operational
- Self-service
Decisions
The meeting or workflow the number exists for.
- Planning
- Pricing
- Operations
Across every layer
- Certification
- Access model
- Change review
- Refresh transparency
- Definition documentation
The approach
- 01
Resolve the metric before designing the chart
Revenue can mean invoiced, recognized, booked or collected. When dashboards disagree, prettier visuals will not solve the underlying ambiguity. Agree the calculation, grain, exclusions, time zone and owner before designing an executive view.
- 02
Build the semantic layer
Define reusable measures, relationships and dimensions that match the business. Check slowly changing attributes, returns and currency conversion. Keep logic in governed models rather than scattered across spreadsheets and individual reports.
- Executive and operational dashboards
- KPI dictionaries and reusable semantic models
- Row-level access and controlled self-service analytics
- 03
Design for the meeting where a decision happens
Give each dashboard a specific audience, question and action. Expose refresh status, drill-through context and definitions. Use accessible contrasts and formats, then test with the actual users rather than measuring success by the number of charts delivered.
- 04
Handover includes ownership
Reconcile reported values to agreed source samples, test access by role and document refresh dependencies. Power BI, Tableau and Looker each have licensing and deployment choices to review separately. Ongoing report support is scoped explicitly.
- 05
The semantic model is the product
Dashboards are disposable; definitions are not. A governed semantic model holds the measures, relationships and hierarchies the business agreed to, so a new report reuses them instead of re-deriving them. Certified datasets, a documented change process and a named owner keep the model trustworthy as teams and questions change.
- One certified definition per business measure
- Model changes reviewed like any other release
- Deprecated measures retired rather than left in place
- 06
Choose the tool for the operating model
Power BI tends to fit organisations standardised on Microsoft licensing with a large self-service audience. Tableau suits exploratory visual analysis across mixed sources. Looker fits teams that want modelling expressed in code with governed reuse. Licence and capacity cost, existing skills, gateway and refresh reality, and where the semantic layer lives decide between them.
- Licence and capacity cost compared per user group
- Refresh, gateway and deployment constraints tested
- Analysis fit compared on real questions, not demos
- 07
Self-service needs a governed boundary
Self-service without rules produces parallel truths. Set the boundary explicitly: which datasets are certified, who may publish to which audience, how a new measure is proposed and approved, and what happens to an uncertified report that contradicts a certified one. Row-level access should be validated with the identities real consumers hold.
Delivery model
How the work is sequenced.
BI work sequenced so the argument about definitions happens before the build, not after the launch.
| Phase | Activities | Decisions made here | What you keep |
|---|---|---|---|
| AssessFind the decisions and the disagreements. |
|
| Decision inventory and disputed-metric list |
| AlignAgree meaning before building anything. |
|
| Metric dictionary with accountable owners |
| ModelImplement the definitions once. |
|
| Governed semantic model and tested measures |
| AdoptTransfer it to the people who will live with it. |
|
| Refresh runbook, access tests and adoption walkthrough |
Technology fit
What each technology is here to do.
BI tool choice is an operating-model decision more than a feature decision. These are the roles the stack has to fill.
Modelling
- dbt
- SQL
- Dimensional design
Curated tables are what measures are defined against. Weak models make every downstream layer harder.
Semantic tooling
- Power BI semantic models
- LookML
- Tabular models
- dbt metrics
The single control point for measure definitions, relationships and access.
Consumption
- Power BI
- Tableau
- Looker
Licensing, existing skills and the self-service audience usually decide this, not visual capability.
Platform detailPlatform
- Snowflake
- Databricks
- BigQuery
Concurrency and refresh behaviour under real reporting load, which is where BI performance problems actually originate.
Platform detailGovernance
- Certification
- Access model
- Change review
- Metric dictionary
What keeps the semantic model trustworthy after the engagement ends.
Technology marks belong to their respective owners. No partnership, certification or endorsement is implied.
Engineering concerns
What has to be answered before it is trusted.
What a BI platform has to be able to answer when a reported number is challenged.
- Definition ownership
- Every certified measure has a named business owner who approves changes to its meaning.
- Access
- Row and column level rules held in the model and tested with real role identities, not demonstrated with an admin account.
- Reconciliation
- Reported values tied back to agreed source samples, with the comparison repeatable on demand.
- Refresh transparency
- Consumers can see how current the data is without asking, so staleness is visible rather than assumed.
- Change control
- Semantic model changes reviewed and released deliberately, because a silent measure change is a silent restatement.
- Accessibility
- Contrast, text size and non-colour-only encoding checked, since a dashboard nobody can read is not a decision surface.
Where it applies
Related work, and why it is related.
Where governed BI is usually the first engagement, and what it connects to.
- Marketing analyticsAttribution disputes are definition disputes; the semantic layer is where they are settled.
- Pricing analyticsMargin figures depend on exclusions and grain being agreed before anyone models a price change.
- Financial servicesA reported figure has to be explainable to someone outside the team, which makes lineage and definition ownership non-optional.
- SaaSProduct, billing and CRM each hold part of the same customer measure, so the semantic layer does the reconciliation.
- Data engineeringWhen the dispute turns out to be upstream of the model, the pipeline work comes first.
Reconcile the total, not just the visible rows.
A dashboard can reproduce every regional figure and still publish the wrong company total. Ratios, distinct customers and balances do not aggregate like sales amounts. In this illustrative BI acceptance case, two regions have different order sizes. The question is whether the executive total represents all eligible orders, rather than an average of the percentages currently visible in a chart.
Scope and assumptions: The arithmetic below uses invented, unitless amounts to expose an aggregation error. The business must define eligible revenue, returns, cost and reporting grain. The fixture does not select a BI tool or establish the accounting treatment for a real organisation.
| Dimension | Fixture and expected meaning | Evidence to retain |
|---|---|---|
| Different denominators | Region A has revenue 100 and margin 20; Region B has revenue 900 and margin 90. Their percentages are 20% and 10%. Combined margin is 110 divided by combined revenue 1,000: 11%, rather than the unweighted 15% average. | Keep the component amounts beside the ratio. A total that merely averages displayed percentages fails this fixture even when both regional rows match their source. |
| Filter context | Repeat the comparison for one region, all regions and an excluded product. Apply the same eligibility policy to numerator and denominator unless a deliberately different population is part of the written metric definition. | Save the selected filters, business date and expected component totals. dbt's ratio-metric documentation models numerator and denominator explicitly, including their filters; it does not choose your business definition. |
| Join fan-out | Attach an order with two support interactions. Joining those interactions to order amounts before aggregation must not turn one order into two sales. Decide which grain owns the measure before introducing a many-side detail table. | Reconcile order keys, row counts and amounts before and after the join. A correct final percentage can hide duplicated numerator and denominator, so test the components independently. |
| Missing denominator | Include a segment with no eligible revenue and another with a missing cost. Decide whether each result is unavailable, excluded or handled by an explicit policy. A missing input should not silently become a reassuring zero-margin result. | Record the expected display and underlying value for missing, zero and negative amounts. Retain the reason for any exclusion so totals and drill-through views can be explained together. |
| Publication comparison | Run the fixture through the governed model and each consuming report. Include the total card, a drill-through and an exported summary under the same permitted identity and filters. | Keep model revision, refresh timestamp, filters and component values with the comparison. Differences caused by stale exports need a freshness explanation; they should not trigger an unnecessary rewrite of a correct measure. |
At narrow widths, scroll the worksheet to read every column. With the table focused, use the arrow keys to scroll.
Worked decision: the regional table passes, but a total card shows 15%. Correct the card's aggregation to calculate the ratio from eligible component totals, then rerun the filter, missing-value and join fixtures. If the components themselves differ, resolve that discrepancy first. This example identifies a testable BI deliverable; it claims no measured improvement in revenue or reporting time.
- Give non-additive measures their own total rule. Distinct customer counts need deduplication across regions; period-end balances need an agreed date rule. Reusing the ratio formula would introduce a different error.
- Use a small fixture that the metric owner can calculate independently. Keep it with the model change so a later relationship or filter edit cannot quietly reintroduce the disagreement.
For the wider definition and ownership model, read semantic models and metric governance.
Official references for this example:
Questions
Questions worth asking.
Can a dashboard be the first engagement?
Yes. Choose one decision workflow with accessible source data. If the underlying data is unreliable, a bounded model or pipeline fix should be part of the scope rather than hidden behind the dashboard.
Do licenses come with the engagement?
Platform subscriptions, cloud consumption and software licenses are separate unless the proposal explicitly includes them. Choose the deployment and sharing model before estimating recurring costs.
Should we standardise on one BI tool?
Standardising simplifies governance, licensing and support, and it is usually the right direction — but only after naming the consumption patterns the tool must serve. Consolidating while critical workflows still depend on another tool creates a second problem. Decide the target, run both deliberately during transition, and set a retirement date.
Do you build Power BI dashboards and reports?
Yes. We design the semantic model first: the measures, relationships and definitions every report depends on. The Power BI reports are then built on that model, with row-level security and scheduled refresh. Building on one governed model is what stops two reports from disagreeing later.
Next step
Discuss your BI platform.
Bring one disputed metric. It usually reveals more than a platform review.