Business Intelligence in the ERP Stack
Business Intelligence (BI) is the layer of software, data structures and operating practice that turns the transactional records inside an ERP system into the management information that decision-makers use day to day. In the DACH mid-market, BI is no longer the discrete “reporting project” it was in the early 2000s — it is a continuously evolving capability that spans the ERP itself, a separate data warehouse or lakehouse, a semantic-modelling layer, one or more visualisation tools, and the data-literacy of the people who consume the output.
This guide covers what BI is, how it sits inside or alongside an ERP, the architectural distinction between classic OLAP and cloud-native data warehouses, the role of semantic layers like dbt and Cube, the vendor landscape for visualisation tools (Power BI, Tableau, Qlik, Looker), DACH-specific BI considerations, and the practical question of when BI investment pays off for a mid-market company.
What Business Intelligence covers
BI as a discipline covers four layers, each of which has its own market and vendor landscape:
- Data integration: extracting data from operational systems (ERP, CRM, e-commerce, MES, finance, HR) into a central store. Tools: classic ETL (Informatica, Talend), modern ELT (Fivetran, Stitch, Airbyte), event streaming (Kafka, Confluent).
- Data storage and modelling: the central store itself — historically an on-premises data warehouse (Microsoft SQL Server, Oracle, Teradata, SAP BW), now increasingly cloud-native (Snowflake, Google BigQuery, Databricks, Amazon Redshift). The modelling layer translates raw operational tables into the dimensional structures (facts, dimensions) that BI consumers understand.
- Semantic and metrics layers: a relatively new category that defines business metrics centrally (revenue, gross margin, customer lifetime value) so that every BI tool reading from it returns the same number. Tools: dbt for transformations, Cube and AtScale for live semantic layers.
- Visualisation and consumption: the dashboards, reports and self-service analytics that end users actually see. Tools: Microsoft Power BI, Tableau, Qlik Sense, Looker, MicroStrategy, plus operational analytics tools like Sigma Computing and Mode.
A mature BI stack rarely uses one vendor for all four layers. The pragmatic mid-market pattern is Fivetran or Airbyte for integration, Snowflake or BigQuery for storage, dbt for transformations and semantic modelling, and Power BI or Tableau for visualisation.
BI in the ERP context
Every modern ERP system ships with embedded reporting. SAP S/4HANA includes embedded analytics through CDS views and Fiori; Microsoft Dynamics 365 includes Power BI integration and the Common Data Model; Oracle NetSuite has SuiteAnalytics; Sage Intacct has Sage Intelligent Time and built-in dashboards. For the most common operational reports — open invoices, sales by customer, inventory positions, purchase commitments — the embedded reporting is sufficient and the right answer is to stay inside the ERP.
The case for a separate BI stack arises when one or more of the following conditions hold. Cross-system reporting — combining ERP data with CRM (Salesforce), e-commerce (Shopify, Magento), HR (Personio), marketing (HubSpot, Google Analytics) — cannot be done inside the ERP alone. Historical trend analysis over multiple years stresses the operational ERP database; offloading history to a data warehouse improves both operational performance and analytical depth. Self-service analytics for business users who want to slice and dice without IT involvement requires a separate semantic layer that the ERP's embedded tooling does not provide. Group-level consolidation across multiple ERP instances (post-acquisition heterogeneity, two-tier ERP strategies) needs a layer above the operational systems.
For a mid-market company on a single ERP instance with limited cross-system reporting needs, embedded ERP analytics plus an Excel-based finance reporting layer is often sufficient. For a group operating two or more ERPs, with e-commerce and CRM in the mix, a separate BI stack is essentially mandatory by the time revenue passes EUR 50–100 million.
OLAP vs OLTP and the cloud data warehouse
The architectural distinction at the heart of BI is between OLTP (Online Transaction Processing) and OLAP (Online Analytical Processing). OLTP systems — including every ERP — are optimised for many small, fast transactions: posting an invoice, releasing a production order, reserving stock for a sales order. The data is stored in normalised relational tables that minimise duplication but require many joins for analytical queries.
OLAP systems are optimised for the opposite pattern: relatively few queries that scan huge volumes of historical data, aggregated along multiple dimensions (time, geography, product, customer). The data is stored in denormalised dimensional structures (star schemas, snowflake schemas, or modern column-oriented formats) that trade storage efficiency for query speed.
The classic on-premises BI architecture put a separate OLAP cube (Microsoft Analysis Services, SAP BW Bex, Oracle Essbase) between the ERP and the reporting tool. The cube was rebuilt overnight from the operational data, which limited reporting to T-1 (yesterday) freshness and required substantial cube-design discipline. From 2015 onwards, the architecture has shifted to cloud-native data warehouses — Snowflake, Google BigQuery, Amazon Redshift, Azure Synapse, Databricks — that decouple storage from compute and run analytical queries directly against denormalised columnar tables without a pre-built cube.
The shift matters for DACH buyers in two ways. First, cloud DWH dramatically reduces the time-to-value: a Snowflake plus dbt plus Power BI stack can be operational in weeks rather than the months a classic SAP BW project required. Second, data residency becomes a real consideration — Snowflake has EU regions, BigQuery has EU multi-region storage, Databricks runs in EU Azure regions; the legal review of the data-processing agreement is part of every cloud-DWH selection in the DACH market.
Semantic and metrics layers: dbt and Cube
One of the structural problems of BI for the past 30 years has been the “same metric, different numbers” problem: marketing reports revenue one way, finance reports it another way, sales reports it a third way. The semantic layer solves this by defining business metrics centrally, once, in a tool that every downstream BI consumer reads from.
Two categories of tool dominate this layer today:
- dbt (data build tool): an open-source transformation framework that defines models in SQL with dependencies, tests and documentation. The output is a set of clean, tested tables in the data warehouse that downstream tools can query. dbt is the de-facto standard for the “T” (transform) step in modern ELT architectures. The dbt Semantic Layer (introduced 2023) adds a metrics definition layer on top of the transformation models.
- Cube: a headless BI / semantic layer that defines measures, dimensions and pre-aggregations once, and exposes them through SQL, REST and GraphQL APIs to any downstream tool. Particularly useful when multiple BI tools (Power BI for finance, Looker for product, Tableau for ad-hoc) need to agree on metric definitions.
In the DACH mid-market, dbt has gained substantial adoption since 2021 alongside the move to Snowflake and BigQuery. The semantic-layer category is younger and adoption is still concentrated in tech-forward companies, but the direction of travel is clear: metric definitions are moving out of individual BI tools and into a central, version-controlled, code-reviewed layer.
The BI visualisation tool landscape
Four vendors dominate the visualisation layer in the DACH mid-market, with a handful of credible specialists alongside them.
- Microsoft Power BI: the dominant choice in DACH by user count, particularly in companies already on Microsoft 365 and Azure. Strengths: tight Excel integration, low entry-point pricing (Power BI Pro at roughly EUR 10 per user per month), deep ecosystem of certified connectors. Weaknesses: governance becomes complex at enterprise scale; the “Power BI everywhere” pattern can produce hundreds of unmanaged reports.
- Tableau (Salesforce): the historical visualisation leader, particularly strong for exploratory analytics and complex visualisations. Strong in companies that have invested in analyst skills. Pricing materially higher than Power BI; the Salesforce acquisition (2019) has tightened integration with Salesforce CRM but slowed feature innovation in some areas.
- Qlik Sense / QlikView: the European veteran (Swedish origin) with strong DACH presence, particularly in manufacturing and wholesale. The associative engine handles complex multi-dimensional analysis differently from the SQL-on-warehouse model that competitors use, which is a strength for some use cases and a complication for others.
- Looker (Google): cloud-native BI built around LookML, a semantic-modelling language. Strong fit for tech-forward companies on BigQuery. Pricing has moved upmarket since the Google acquisition (2019), making it less attractive at the lower end of the mid-market.
Specialist vendors fill credible niches: MicroStrategy for large enterprises with complex governance needs, Sigma Computing for spreadsheet-centric analysts on cloud DWH, Hex and Mode for analytical notebook workflows, Metabase and Apache Superset for the open-source segment. SAP Analytics Cloud is the natural choice for SAP-centric environments; its integration with S/4HANA and BW/4HANA is deep and the data-residency story for SAP customers is clean.
DACH-specific BI considerations
Three DACH-specific factors regularly shape BI architecture decisions in the German mid-market. Data residency under GDPR (DSGVO) is the most material: any BI stack that processes personal data (customer master, employee data) must satisfy the legal review on EU storage, processing locations and sub-processor chains. Cloud-DWH and BI vendors with US headquarters typically offer EU regions, but the Schrems II ruling means the legal review is more rigorous than it was a decade ago; some German mid-market buyers still prefer on-premises or EU-only deployments for sensitive workloads.
Second, Betriebsrat (works council) involvement is required for any BI tool that surfaces employee performance data — sales rep performance, helpdesk-agent metrics, time-tracking analytics. The Betriebsvereinbarung (works agreement) typically constrains which metrics are visible to whom and how they are aggregated; BI tools that handle row-level security and aggregation rules cleanly have an advantage. Third, integration with DATEV and German finance practice matters more than international vendors expect. The chart of accounts (SKR03, SKR04), German VAT reporting (UStVA, ZM), the depreciation rules for fixed assets and the BAB (Betriebsabrechnungsbogen) all need representation in the data model; pre-built finance content from a vendor that has invested in DACH localisation saves substantial modelling work.
BI inside the ERP suite vs a separate stack
The choice between using the ERP's embedded BI capability and building a separate stack has a clear decision logic. Stay with the embedded ERP analytics when the reporting needs are predominantly operational (today's open orders, this month's margin per product, current inventory positions), when there is a single ERP instance, and when cross-system reporting needs are modest. SAP Analytics Cloud + S/4HANA, Power BI + Dynamics 365 Business Central, SuiteAnalytics + NetSuite all cover this scope well and avoid the cost of operating a separate stack.
Build a separate BI stack (cloud DWH plus modelling plus visualisation) when cross-system reporting becomes the norm, when historical depth (multi-year trends) is needed, when multiple ERP instances exist post-M&A, or when self-service analytics for business users without IT involvement is a strategic priority. The economic threshold is typically in the EUR 50–100 million revenue range, with significant variation depending on business model: e-commerce-led companies cross it earlier (lots of cross-system reporting needed), single-ERP service businesses cross it later.
A hybrid model is increasingly common: ERP analytics for operational reporting (fast feedback loops, real-time dashboards) plus a cloud DWH for cross-system analytics and management reporting (typically refreshed daily). This pattern lets the ERP team and the analytics team move at different paces and reduces the burden on the ERP's operational database.
When BI is worth the investment in the Mid-Market
The honest answer to “when does BI pay off for a mid-market company” is: when the cost of decisions made without it exceeds the cost of operating the stack. That is rarely the case for the smallest companies, where Excel plus the ERP's standard reports is sufficient. It is almost always the case for groups with multiple ERP instances, multi-channel revenue, or growth ambitions that depend on understanding customer behaviour at a granular level.
Three signals that a mid-market company is ready to invest in a separate BI stack:
- The same business question is answered three different ways by three different teams. This is the “single source of truth” problem. A semantic layer and a central data warehouse are the structural answer.
- Excel files are emailed around the company as the de-facto reporting system. This pattern hides errors, prevents version control and breaks when the analyst who built the workbook leaves. A managed BI stack with governed access replaces it.
- Strategic decisions are being deferred because the data is not available in time. When the M&A pipeline, pricing changes or customer-acquisition investment depends on data that takes weeks to produce, the operational cost of slow BI exceeds the licence cost of a faster stack.
The typical total cost of a mid-market BI stack — Snowflake or BigQuery, dbt, Power BI or Tableau, plus 1 to 2 FTE for analytics engineering and BI development — runs to roughly EUR 250,000 to 500,000 per year inclusive of cloud spend, licences and staff. For companies above EUR 100 million revenue, this is typically a sound investment; below that, the case has to be made carefully against the alternative of better-trained Excel users and improved ERP standard reporting.
Related Topics
Frequently Asked Questions
Do I need a separate BI tool if my ERP already has reporting?
For purely operational reporting on a single ERP — open invoices, current inventory, monthly P&L — the ERP's embedded reporting is usually sufficient and the right answer is to stay inside it. SAP Analytics Cloud with S/4HANA, Power BI with Dynamics 365, SuiteAnalytics with NetSuite all cover this scope cleanly. A separate BI tool becomes worth its cost when cross-system reporting (ERP + CRM + e-commerce + HR) becomes the norm, when historical depth beyond what the ERP database holds is needed, or when self-service analytics for business users without IT involvement is a strategic priority.
Snowflake vs BigQuery vs Databricks — which is right for DACH mid-market?
All three are credible choices with EU regions and German-data-residency commitments. Snowflake is the broadest pick, with the deepest partner ecosystem in DACH and the cleanest separation of storage from compute. BigQuery is the natural choice for organisations already on Google Cloud; pricing favours steady, predictable workloads. Databricks is the strongest fit for organisations with substantial data-science workloads alongside BI — the lakehouse model lets unstructured and structured data live in one place. For a typical Mittelstand BI workload focused on ERP + CRM + e-commerce data, Snowflake is the lowest-risk default; for analytics-heavy organisations, Databricks deserves serious evaluation.
What is dbt and why does everyone talk about it?
dbt (data build tool) is an open-source framework for the “T” (transform) step of ELT. It defines data models in SQL with dependencies, automated testing, version control and documentation — turning data transformation from a fragile collection of scheduled scripts into a software-engineering discipline. dbt has gained substantial adoption since 2020 because it solves the structural problem of how to turn raw data warehouse tables into clean, trusted, well-documented analytical models that every downstream BI tool can read from. For DACH mid-market BI projects on Snowflake, BigQuery or Databricks, dbt is essentially the default choice.
Power BI or Tableau — which should a DACH mid-market company pick?
For most DACH mid-market companies, Power BI is the lower-risk default. It is materially cheaper (roughly EUR 10 per user per month for Power BI Pro vs EUR 70+ for Tableau), integrates tightly with Excel and Microsoft 365 (which the buyer almost certainly already runs), and has a mature partner ecosystem in DACH. Tableau remains the stronger choice for exploratory analytics, complex visualisations and analyst-heavy organisations where the visual quality and analytical depth justify the price. Qlik Sense deserves a serious look in DACH manufacturing and wholesale where its associative engine has historical traction.