Your ERP Is Not Your Data Platform

SAP, Oracle, Microsoft Dynamics - these systems were designed to do one thing exceptionally well: process transactions without losing data. Every purchase order, goods movement, and financial posting is recorded with full audit trail, concurrency control, and referential integrity. For that purpose, they are excellent.

The design decisions that make ERPs good at transaction processing are directly incompatible with analytics. Row-level locking for write consistency is the enemy of query performance at scale. Highly normalised schema design ensures data integrity but requires expensive joins for any meaningful cross-functional query. Batch-based data propagation between modules means cross-domain reports are always a snapshot, never a live view.

None of this is a criticism of ERP vendors. They built what the market needed in the 1990s and 2000s. The problem is that industrial organisations have been accumulating 20 years of analytical debt by treating their ERP as an analytics platform - and the bill is now arriving.

The failure of ERP-as-analytics-platform manifests in predictable ways. Query times that degrade as data volumes grow. Reports that have to be scheduled overnight to avoid impacting transactional performance. Business users who cannot self-serve because every new report requires an ABAP or SQL developer. Month-end closes that take two weeks because the data reconciliation between modules has to be done manually.

The deeper failure is cross-domain analytics. An ERP can tell you what was ordered, what was manufactured, and what was invoiced - but it cannot easily tell you why the margin on a specific product line dropped, because that answer requires joining procurement data, production data, quality data, and distribution data that sit in different modules with different update frequencies.

When organisations add a BI layer on top of their ERP - typically Power BI or Tableau connecting directly to the ERP database - they inherit all of these constraints. The BI layer makes the data more accessible but does not solve the underlying architectural problem. Reports are still slow. Data is still siloed. Business users still wait for IT to build new extracts.

In a typical industrial company with 500–5,000 employees, the ERP coexists with 8 to 20 other operational systems: MES, SCADA, CMMS, WMS, QMS, CRM, TMS, PLCs, Excel files, and increasingly SaaS applications for specific functions. Each of these systems holds a partial view of the business. None of them talk to each other in real time.

The consequence is that every cross-functional question requires a manual data pull, a reconciliation process, and a spreadsheet that someone owns and nobody trusts. The cost of this - in analyst time, decision latency, and errors - is invisible on the P&L but material to operational performance.

Nine in ten IT leaders citing data silos as a major barrier to extracting value (Logicalis CIO Report) is not surprising. What is surprising is that so many organisations respond to that problem by buying yet another system — an analytics platform that sits on top of the silos rather than eliminating them.

The architectural response to the ERP-as-analytics-platform problem is a data lakehouse: a unified data layer that ingests from all operational systems - ERP, MES, WMS, SCADA, and others - into a single governed, queryable platform. The lakehouse does not replace any of these systems. It reads from them and creates a single analytical layer that is independent of the transactional systems it reads from.

The lakehouse architecture - popularised by Databricks's Delta Lake and Microsoft's OneLake - combines the schema flexibility of a data lake with the ACID transactions and query performance of a data warehouse. For industrial companies, this means you can store sensor data (high-volume, semi-structured) alongside ERP transactional data (structured) and CMMS maintenance records in the same governed platform.

The result is a single place where a production question, a finance question, and a quality question can all be answered from the same data model - without manual reconciliation, without scheduling overnight batch jobs, and without waiting for IT to build a new extract.

The transition to a lakehouse architecture is not a rip-and-replace. The ERP, MES, WMS, and other operational systems continue to run unchanged. The lakehouse sits alongside them, reading their data via change data capture (CDC) or API integration - not replacing any existing transactional capability.

The practical starting point is identifying the two or three highest-value cross-domain analytical use cases in the business: typically FP&A, operational performance reporting, or supply chain visibility. These become the first workloads to migrate from manual reconciliation to the lakehouse model. The existing ERP reports continue to run. New analytical workloads run on the lakehouse.

Once the pattern is established and the organisation trusts the new data layer, subsequent use cases - predictive maintenance, demand forecasting, quality analytics - can be added progressively. The architecture scales. The operational disruption is zero because nothing is being removed - only augmented.

In a Microsoft-stack build the layer is concrete. Azure Data Factory extracts from each operational system — SAP via the CDC (ODP) connector, Dynamics 365 natively, legacy MES or WMS via API or replication — and lands raw, immutable data in a Bronze zone in OneLake on a Microsoft Fabric foundation. Nothing in the ERP, MES, or WMS changes; the platform reads from them through data integration and leaves the transaction systems to do their job. That separation is the entire architectural point.

A medallion flow then does what the ERP cannot: Silver cleanses and conforms keys so a product or customer means the same thing across systems, and Gold publishes the cross-domain KPIs. A Power BI Direct Lake semantic model holds one definition of margin, OEE, OTIF, and days inventory outstanding — so the production answer, the finance answer, and the quality answer all come from the same governed model rather than three reconciled spreadsheets. Sensor data sits in the same Delta Lake tables as ERP transactions, which is the thing a row-locked OLTP database can never do well.

The reason to build it once, properly, is compounding reuse. The same OneLake foundation that powers FP&A also feeds predictive maintenance, demand forecasting, and quality analytics without a second integration. You connect each source once and add workloads on top — the opposite of buying another point system that sits on the silos instead of dissolving them.

A lakehouse exposes master-data fragmentation rather than fixing it. If the same SKU or customer carries different codes in the ERP, MES, and WMS, the Silver layer still has to reconcile them — and that reconciliation needs a governed master nobody may yet own. Without an owner for the SKU and customer master, the platform conforms keys by best guess, and the single version of truth quietly becomes a single version of someone's assumption. The MDM decision is organisational, not technical.

ERP extraction also carries constraints worth naming before you promise dashboards. Reading SAP programmatically for a non-SAP platform can have indirect/digital-access licensing implications, and not every source exposes clean CDC — some legacy systems only offer nightly files, which caps freshness for that domain. Map the extraction path and licensing position per source up front, not in build.

And not every report needs a lakehouse. A single-system, single-domain question the ERP already answers well does not justify the platform — over-architecting a problem the standard report handles wastes the budget that the genuinely cross-domain use cases need. The lakehouse earns its place on the questions that span modules and systems, which is precisely where the ERP fails; pointing it at everything dilutes the case.

The framing that matters: you are not replacing a sound ERP investment — you are building the analytics layer it was never designed to be, so it finally compounds. The 20 years of analytical debt shows up as two-week month-end closes, reports that must run overnight, and business users who wait on IT for every new extract. That debt is the cost of asking one transaction engine to also be the analytics platform, and it is what the layer above pays down.

It starts with the two or three highest-value cross-domain use cases — FP&A, operational performance, supply chain visibility — not a big-bang migration. A six-week build stands up the first workload on the lakehouse while every existing ERP report keeps running unchanged; first value in 6 weeks, zero operational disruption because nothing is removed, only augmented. Prove the pattern, earn trust, then add use cases progressively.

Keep the ERP doing what it is excellent at — recording transactions — and build a governed lakehouse above it for the questions that span systems. Unify the operational data, agree who owns the master definitions, then serve one number everywhere. The ERP and the analytics layer together are worth far more than either system pushed to do both jobs.