Why Your Fractional Data Consultant Needs to Know Your ERP Cold

Every meaningful operational data question in manufacturing runs through the ERP. OEE? The production order is in SAP PP. Scrap variance? It is in the QM module, cross-referenced to the production order and the material batch in MM. Cost of goods sold? That is a FI/CO question that requires understanding how SAP standard cost runs against actual GI. A fractional data consultant who has never worked inside an SAP system can describe the OEE dashboard. They cannot build the data model that populates it correctly.

This matters because the ERP integration is always where manufacturing analytics projects break down. Not the Power BI layer — that part is straightforward. Not the Microsoft Fabric architecture — that is a solved problem. The failure point is the connection between the ERP data model and the analytical layer, because that connection requires knowing that goods movements in SAP use movement type 101 for GR against purchase order and 261 for GI to production order, and that the quantity field behaves differently depending on whether you are looking at the material document or the accounting document.

A data consultant without that knowledge will either produce a data model that is technically correct but misses operational nuance, or will rely on the client's IT team to explain it — which means the client is doing the consulting.

Real ERP knowledge in a fractional data consultant shows up in specific ways. They will ask which version of SAP you are running, whether it is on HANA or MaxDB, and whether you have any custom development on the standard tables. They will know the difference between MARA (material master) and MARC (plant-specific material data) without being told. They will understand that purchase orders in B1 live in OPOR and POR1, and that the document series matters for filtering.

They will ask to see the physical data — not a slide deck describing the data. They will want to run queries directly against the development or QA system to understand the actual data quality, the real volume, and the custom fields that standard documentation does not mention. Every SAP implementation has a handful of critical fields that are specific to that organisation and that nobody talks about in a scoping meeting. An experienced ERP consultant finds them in the first two days.

They will also understand the operational context that drives the data. They know what an MRP run does to open purchase orders, what happens to production order confirmations when the shift supervisor does a retrograde goods movement, and why the inventory report disagrees with the balance sheet if you look at it at period cutoff. That knowledge is not learnable from documentation — it comes from having made those mistakes on live systems.

Generic data consulting — meaning modern data stack expertise without domain knowledge — produces architectures that work in theory and fail in production. The Fabric lakehouse is built correctly. The medallion architecture is sound. The semantic model is clean. And then the plant manager looks at the OEE dashboard and the number is wrong, because the consultant built the transformation against the standard production order completion quantity and the plant uses a partial delivery workflow that puts goods movements against sub-operations, not the header order.

That fix takes ten minutes for someone who has seen it before. For someone who has not, it takes a week of investigation, three calls with the IT team, and a re-architecture of the data transformation layer. The cost is not just the time — it is the credibility of the analytics platform in the eyes of the operations team. Once a plant manager sees a wrong number in a dashboard, it takes months to rebuild trust.

This is why manufacturing analytics consulting should be evaluated on domain knowledge first and data technology second. The technology is learnable. The domain knowledge — understanding how a mid-market GCC manufacturer actually runs their SAP ByD or how an Indian packaging company uses SAP B1 with custom item classification — takes years to accumulate.

Ask them to describe a specific ERP integration they have delivered. Not the project at a high level — the specific data model challenge. What was the hardest join? What custom field did they have to handle? What did the data quality look like before cleaning and what did they do about it? If the answer is generic ("we connected the ERP to the data warehouse and built the dashboards"), they have not done this at the data level.

Ask what ERP modules they have integrated in your specific vertical. A manufacturing analytics consultant should be able to name the PP, MM, QM, and FI/CO modules and describe the relationships between them. An FMCG analytics consultant should understand the SD and MM interaction for trade promotions, and the specific challenge of reconciling sales order quantities against delivery quantities against invoice quantities in a distributor environment.

Ask what they would look at in the first two weeks of an engagement. A consultant with real ERP depth will immediately talk about the data — running queries to understand record volumes, data quality checks on key tables, validating that the quantities in operational reports reconcile back to the accounting documents. A consultant without that depth will talk about stakeholder workshops and process maps.