Your ERP, CRM and financial data in one place, with historical data and one agreed definition for each KPI.
Trusted by leading organisations
A data warehouse is a central database where you bring together data from ERP, CRM, an online shop and planning, clean it and organise it for reliable reporting, including on historical data. Having a data warehouse built pays off when reporting takes too much manual work or departments produce different figures. Data Science Lab builds it, from the first integration through to ongoing management.
On the first working day of each month, the controller exports revenue from the ERP system, puts it in Excel alongside a CRM export and manually corrects the customer numbers that differ between the two systems. Meanwhile, the sales team reports directly from the CRM. At the management team meeting, there are two revenue figures on the table, and nobody knows which calculation rule is correct or who decides.
Historical data adds another complication. When a customer moves to another region, the CRM overwrites the previous value. If you then request last year’s revenue by region, the report calculates it as though that customer had always been in the new region.
A data warehouse automatically pulls in data from the sources, maps the customer numbers once and tracks changes instead of overwriting them. The figure in the dashboard then comes from a single model, with one calculation rule and one owner.
A proven approach is dimensional modelling based on Ralph Kimball’s method: fact tables for events such as orders and invoices, and dimensions such as customer, product and date. First, we define the grain: the level of detail represented by one row. This keeps reports fast and easy to understand.
We first load the source data unchanged, then transform it within the platform, often using dbt. This puts every calculation rule in version-controlled code, with tests for things like unique keys, empty fields and valid values.
With slowly changing dimensions, which track changes over time, you can preserve what a customer or product looked like at any given point. With type 2, a change creates a new version with a validity period, so last year’s revenue remains linked to the old region.
We define what counts as revenue, an active customer or an on-time delivery once, in a shared semantic model such as a Power BI model or metric views in Databricks. All Power BI dashboards then use the same formula.
Every source and every KPI has an owner who knows what the fields mean and who resolves errors. Checks in the loading pipeline catch empty or unusual values before they appear in a report. These arrangements are part of data governance.
We connect ERP, CRM, webshop, HR and planning systems through APIs, database connections or automated exports. We define centrally how customer numbers and product codes from different systems match, rather than working it out again in every report.
Tell us what sources you have. We’ll help you identify the first topic for your data warehouse.
We start with the reports and decisions the data warehouse needs to support, and define what each KPI means and who owns it.
We look at which systems provide the data, how to access it, how often it needs to be refreshed and where quality falls short.
Data warehouse or lakehouse, cloud or your own server: we choose what fits your data, your team and your existing IT environment.
We build out one clearly defined area, such as sales or inventory, from source to dashboard. Users check the figures against what they know from their day-to-day work.
Then we move on to the next process. We reuse dimensions such as customer, product and date, so new areas connect to what is already in place.
We monitor the data loading processes and adapt the model when sources or definitions change. We can also continue to handle that management for you.
DSL helped us set up our very first data warehouse. They guided us step by step and worked with us to identify the information we need to make better decisions. This has given us important insights and increased our profits. For us, they are a fantastic partner, and we would recommend them to other SMEs.
A data warehouse stores structured, controlled data in tables designed for reporting. A data lake stores data of any type in its raw form: it is inexpensive and flexible, but the data is not validated, making it less suitable for management reporting. A lakehouse combines both in a single open storage format, with layers that move from raw (bronze) through cleaned (silver) to business-ready (gold). Databricks and Microsoft Fabric call this the medallion architecture; your data warehouse’s dimensional model can form the gold layer.
If you mainly work with structured data from ERP and CRM systems and your team writes SQL, a data warehouse is often enough. If you also need to handle sensor data, documents or machine learning, a lakehouse is likely a better fit. For Vivara, we built a data platform on Azure Databricks that retrieves data daily from sources including SAP, Magento and SharePoint.
It does not have to be in the cloud, either: for Zuiver, we built a data warehouse on its own server, bringing together data from different sources. To learn how a data warehouse fits into a broader data environment, read about the data foundation.
Every organisation can start an AI pilot. The challenge is what comes next: making AI part of the organisation. That’s where Data Science Lab makes the difference.
Read more about us
10+
8.7
200+
A data warehouse is a database designed for analysis and reporting, separate from the systems where day-to-day work takes place. It brings together data from ERP, CRM and other sources, cleans it and retains historical data, so you can compare figures across departments and years using the same definitions.
In principle, any system you can extract data from: ERP packages such as SAP, CRM, webshops, HR and planning systems, Excel files and SharePoint. For Koninklijk Concertgebouworkest, we connect and standardise information from different systems and archives in one data platform. The hardest part is rarely the connection itself, but agreeing which source takes precedence.
dbt (data build tool) is a tool for writing, testing and documenting transformations in SQL. This means every step from source data to KPI is recorded as code in version control, and changes to calculation rules can be traced. At Fokker Services Group, we use dbt and Databricks to model data from different sources according to the medallion architecture, with built-in data quality checks.
With slowly changing dimensions. With type 1, you overwrite a value, such as a corrected email address. With type 2, you create a new version with a start and end date, for example when a customer moves to a different region. In dbt, you do this with snapshots. Many source systems do not retain changes themselves, so capture them from the start: data the source has already overwritten is often impossible to recover.
Both. As a Databricks Partner and Microsoft Partner, we build data and AI platforms on Databricks and Microsoft Fabric. Fabric is a SaaS service; Databricks runs with a cloud provider such as Azure. In both cases, the data is stored in the open Delta format, so you are not tied to one vendor. What matters most is where the data needs to reside, who will manage it and what expertise you have in-house.
Usually, yes, although the calculation rules move to the central model. We start by taking stock of what is there: which tables exist, which calculation rules are embedded in reports and which of those are actually used. Rules currently spread across separate reports move to the central model. We then migrate existing reports one by one, so users do not have to switch all at once.
If you report from a single system that has good reporting capabilities of its own, or if you only need a handful of reports that rarely change. A Power BI model connected directly to the source is often enough in those cases. A data warehouse will not fix a messy source either: you need to start by cleaning up the data and agreeing how it should be entered. If a simpler solution is enough, we will tell you honestly.
E-mail info@datasciencelab.nl
Phone +31 (0)20 3636 724
Tell us which data sources you have and which figures are currently causing debate. We’ll work with you to identify the first topic to tackle and the architecture that fits it.
Message sent
Thanks for your message. We’ll be in touch as soon as possible.
