Should we calculate manufacturing KPIs in ERP, MES, or a data warehouse?

No. In most plants, you should not calculate all manufacturing KPIs in only ERP, only MES, or only a data warehouse.

The practical answer is to calculate KPIs in the system that has the right source data, event timing, and operational context for that metric, then publish governed results for broader reporting. In brownfield environments, that usually means a split model:

• MES for execution-level KPIs that depend on detailed production events, machine states, labor transactions, route steps, quality checkpoints, or genealogy context.
• ERP for financial, order, inventory valuation, procurement, and enterprise planning metrics.
• Data warehouse for cross-system KPIs, trend analysis, plant-to-plant comparisons, and executive reporting where data must be reconciled across MES, ERP, QMS, CMMS, and other sources.

What belongs where

MES is usually the better calculation point for metrics such as throughput by operation, cycle time by routing step, queue time, WIP aging at execution points, first pass yield at the work center, detailed scrap and rework by operation, and some forms of OEE or downtime analysis. Those KPIs break down quickly if you try to reconstruct them later from ERP transactions that were never designed to capture shop floor event timing with enough precision.

ERP is usually the better calculation point for measures such as order fulfillment, shipment performance, purchase price variance, inventory turns, standard versus actual cost, and other metrics tied to financial posting logic or enterprise master data. ERP can also be the system of record for planned quantities, due dates, and customer or supplier commitments, even when the manufacturing events come from somewhere else.

A data warehouse is usually the better calculation point when the KPI requires multiple systems, historical normalization, common calendar logic, enterprise dimensions, or a canonical definition across sites. Examples include end-to-end lead time, schedule adherence that depends on both plan and execution, COPQ rollups, supplier-to-production latency, and corporate dashboards that combine production, quality, and financial context.

Why a single-system answer often fails

Each system has different strengths and failure modes. ERP often lacks the event granularity needed for execution KPIs. MES often does not own the enterprise financial logic or all planning assumptions. A data warehouse can standardize and compare, but it is only as good as the incoming data, timestamp quality, identity matching, and business rules.

If you force every KPI into one layer, you usually create one or more of these problems:

• Metrics that are technically consistent but operationally misleading.
• Different teams recalculating the same KPI with different start and stop events.
• Lagging dashboards that are not useful for shift-level action.
• Executive reports that cannot be traced back to transactional evidence.
• Validation and change control overhead whenever logic changes.

Use system of record and system of calculation separately

A useful pattern is to define, for each KPI, both the system of record and the system of calculation. They are not always the same.

• A KPI may use MES as the record for execution events, but the warehouse as the place where the final enterprise KPI is calculated.
• A KPI may use ERP as the record for planned completion date, but MES for actual completion event.
• A KPI may be displayed in ERP, MES, or BI tools without being calculated there.

This separation matters in regulated environments because teams often need traceability from a dashboard number back to the underlying transactions, versions, and business rules used at that time.

What to decide before choosing the calculation layer

Before deciding where to calculate a KPI, clarify:

• What exact business event starts and stops the metric.
• Which system captures those events first and with acceptable timestamp precision.
• Whether the KPI must drive real-time action, period close reporting, or both.
• Whether the metric must be standardized across plants with different routings, vendors, or transaction practices.
• Whether the source data is complete enough to support the metric without manual patching.
• How changes to KPI logic will be versioned, approved, tested, and communicated.

Without that governance, the technology choice will not fix KPI inconsistency.

Brownfield reality

In mixed MES and ERP environments, coexistence is usually the right approach. Full replacement to get “one source of truth” often looks attractive on paper but fails in practice when plants have validated processes, custom integrations, legacy equipment, long asset lifecycles, and limited downtime windows. Replacing core systems just to simplify KPI calculation can create more risk than value because of qualification burden, integration rework, retraining, and disruption to traceability and change control.

A more durable approach is to keep calculations close to the source where necessary, then federate or reconcile results in a governed data layer.

Recommended operating model

For most manufacturers, the lowest-risk model is:

1. Define KPI formulas, event boundaries, exclusions, and ownership centrally.
2. Calculate execution KPIs in MES when real-time context and transactional fidelity matter.
3. Calculate finance and planning KPIs in ERP where posting and master data rules are authoritative.
4. Use a data warehouse or semantic layer for enterprise KPIs that cross systems or require historical normalization.
5. Maintain lineage so users can trace every KPI back to source records and logic versions.

If you cannot explain why a KPI is calculated in a given layer, and what data it depends on, the architecture is probably not stable enough yet.