OLAP (Online Analytical Processing)
OLAP (Online Analytical Processing) is a data analysis technique that organizes metrics in a multidimensional data model – the OLAP cube – so they can be analyzed, filtered and aggregated very quickly along dimensions such as time, region, product or customer.
OLAP (Online Analytical Processing) is a data analysis method that stores large volumes of metrics in a multidimensional data model and prepares them so that evaluations can be carried out very quickly and flexibly along several perspectives at once. Instead of querying data row by row, OLAP arranges measurable quantities such as revenue or unit sales in a so-called cube, whose axes form the dimensions – for example time, product, region and sales channel. A user can rotate, slice and condense this cube interactively to answer questions like "How did revenue per product group and month develop by region?" in near real time and without technical knowledge.
The term was coined in 1993 by Edgar F. Codd and deliberately distinguishes analytical data processing from the transactional day-to-day business (OLTP). OLAP is therefore a central building block of business intelligence: it sits between the data pool optimized for analysis – often a data warehouse – and the reporting and dashboard tools that make the results visible. For companies this means that instead of rigid, pre-built lists, they gain a flexible tool with which business departments can dissect their figures themselves and take ever new perspectives.
At a glance
- OLAP = multidimensional analysis of metrics in a "cube"
- The axes of the cube are dimensions (time, product, region, customer); the cells contain metrics (measures)
- Core operations: slice, dice, drill-down/roll-up and pivot
- The counterpart to OLTP – the transactional day-to-day business in the ERP
- A building block of business intelligence, usually built on top of a data warehouse
How does OLAP work?
The heart of OLAP is the multidimensional data model. Unlike a classic table, in which every row is a single record, OLAP thinks in terms of metrics and dimensions. Metrics (measures) are the measurable values to be analyzed – for example revenue, sales volume, contribution margin or return rate. Dimensions are the perspectives from which these metrics are viewed – time, product, customer, region or sales channel. Each cell of the cube contains the value of a metric for a specific combination of all dimensions, for example the revenue for "product group shoes, May 2026, region South, channel online shop".
To make evaluations respond so quickly, many subtotals are calculated in advance and stored in the cube (pre-aggregation). Anyone who then switches from an annual to a monthly view or filters out a region gets the answer immediately, without millions of individual rows having to be summed up again. It is precisely this pre-aggregation that distinguishes OLAP from an ordinary database query and makes the interactive analysis of large data volumes practical.
The basic OLAP operations: slice, dice, drill-down and pivot
Four operations shape the daily work with OLAP. With slice ("cutting"), one dimension is fixed to a single value – you look, for example, only at the year 2026 and obtain a slice of the cube. With dice, several dimensions are narrowed down to sub-ranges at the same time, for example two regions and three product groups. Drill-down means zooming into a dimension – from the year through the quarter down to the individual day, or from the product group down to the individual item; roll-up is the opposite direction, i.e. condensing to a higher level. Pivot, finally, rotates the cube so that rows and columns swap axes and the same figures appear from a new angle.
MOLAP, ROLAP and HOLAP
Technically, there are various ways to implement an OLAP cube. With MOLAP (multidimensional), the data is physically pre-calculated and stored in a specialized multidimensional database – very fast, but with high storage and computing overhead during the build. With ROLAP (relational), the data remains in a relational database, and the multidimensional view is generated via query – more flexible and suitable for very large data volumes, but slower. HOLAP (hybrid) combines both approaches: condensed aggregates are held multidimensionally, while detail data remains in the relational database.
Why OLAP matters for analysis
The practical benefit of OLAP lies in speed and self-sufficiency. Business departments can dissect their metrics themselves without ordering a custom report from IT for every new question. Anyone who sees that total revenue has collapsed can drill down to the responsible region, product group or individual customer and find the cause in seconds instead of days. This ad-hoc capability makes OLAP one of the most important tools in controlling.
A second advantage is consistency. Because metrics and their calculation logic are defined centrally in the cube, all users see the same figures – regardless of who creates the analysis. This ends the widespread dispute over contradictory Excel lists and creates a shared factual basis. However, a prerequisite is high data quality in the source systems: an OLAP cube is only ever as reliable as the master and transaction data it is fed from.
OLAP in the ERP system
The ERP system is the most important data source for OLAP analyses, because that is where orders, invoices, stock levels and master data come together. In practice, however, this operational data is rarely analyzed directly in the OLAP cube. Instead, it is regularly loaded from the ERP into a data warehouse via an ETL process, historized and there transferred into the multidimensional cube. This detour has two reasons: it relieves the productive ERP of computationally intensive analyses and enables evaluations across multiple sources, for example ERP, online shop and marketplace data together.
Many modern ERP and BI solutions already come with OLAP-like functions or generate cube structures in the background for their dashboards and pivot analyses, without users ever hearing the term. For standard questions from ongoing operations, the built-in reporting functions are often sufficient. As soon as large histories, complex metric models or several data sources come together, however, a dedicated OLAP layer on a data warehouse is worthwhile, connected to the ERP via an API or a connector.
Distinction: OLAP vs. OLTP
The most important distinction is between OLAP and OLTP (Online Transaction Processing). OLTP describes the transactional day-to-day business: recording an order, posting an invoice, changing a stock level. Such systems – above all the ERP – are optimized to process many small write and read operations quickly and reliably. OLAP, by contrast, is designed for reading and aggregating large data volumes and answers analytical questions over long periods of time.
OLAP, reporting and the data warehouse
OLAP is often confused with neighboring terms. A data warehouse is the historized data store on which OLAP typically builds – OLAP is the analytical access and modeling layer on top of it, not the storage itself. Reporting, in turn, is the output layer: standardized reports and dashboards that often draw their figures from an OLAP cube. In simplified terms: the data warehouse holds the data, OLAP makes it multidimensionally analyzable, and reporting presents the results. All three together form central building blocks of a business intelligence architecture.
OLAP in the DACH SME sector
In German-speaking mid-sized companies, OLAP has long ceased to be a purely corporate topic. Cloud-based BI tools and analysis functions integrated into ERP systems bring multidimensional evaluations to smaller trading and manufacturing businesses too – often without the users even being aware of the OLAP cube in the background. Typical fields of application are revenue and margin analyses per channel, inventory metrics as well as controlling by cost center and cost object.
As with any analysis, data protection must be observed: as soon as personal data such as customer or employee data flows into cubes and dimensions, the requirements of the GDPR apply, in particular purpose limitation and data minimization. If OLAP analyses are used to monitor the performance or conduct of employees, the co-determination rights of the works council are also relevant. And as with all BI methods, the rule is: without maintained, consistent master and transaction data, even the best OLAP cube remains deceptive.
Example
OLAP cube at a multichannel retailer
A mid-sized fashion retailer sells through its own online shop, several marketplaces and brick-and-mortar stores. Management wants to know how revenue and gross profit develop per product group, channel and month – not as a rigid monthly list, but flexibly and on demand. Individual queries in the inventory management system take too long and cannot be freely combined.
Via a nightly ETL run, the revenue and returns data from ERP, shop and marketplaces is loaded into a data warehouse and condensed there into an OLAP cube with the dimensions time, product group, channel and region. Controlling now slices the cube freely: a drill-down from the product group "shoes" down to the individual model shows that a high-revenue marketplace channel delivers hardly any margin after returns and fees. Based on this insight, the assortment is specifically adjusted per channel – within minutes instead of after days of manual Excel work.
Frequently asked questions
Matching ERP systems
Related services
Questions about OLAP (Online Analytical Processing) in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.