Where should KPI formulas live: ERP, MES, data warehouse, or another platform?

Usually, not in just one place.

In most regulated manufacturing environments, KPI formulas should be split by purpose rather than forced into ERP, MES, or a data warehouse by default. A practical pattern is:

• System of record keeps the source facts, such as orders in ERP, execution events in MES, and quality events in QMS.
• Operational calculations live close to the process when people need them during execution, for example shift performance, queue aging, downtime response, or first-pass yield at a work center.
• Enterprise KPI definitions are governed centrally in a semantic layer, analytics platform, or well-controlled data model so finance, operations, and quality are not all reporting different versions of the same metric.

So the short answer is: put KPI formulas where they can be executed reliably and governed consistently, which is often a combination of MES plus a governed analytics layer, not ERP alone.

How to decide where a formula belongs

A KPI formula usually belongs in the platform that best matches these constraints:

• Decision timing: If the metric drives action during the shift, calculation often belongs in MES, SCADA, historian, or an operations intelligence layer close to the line.
• Data ownership: If the required facts are authored in ERP, such as standard cost, booked labor, or customer delivery promise, ERP may own part of the calculation or at least the source inputs.
• Cross-system logic: If the KPI combines ERP, MES, QMS, maintenance, and manual data, a data warehouse or semantic layer is usually the safer place for the official enterprise version.
• Traceability and change control: If the formula affects regulated reporting, management review, or quality decision-making, you need version control, approval, test evidence, and clear lineage from source data to reported result.
• Latency tolerance: If next-day reporting is acceptable, a warehouse or lakehouse is often enough. If operators need the value in seconds or minutes, batch analytics is too late.

What each platform is good at

ERP is usually best for commercial and planning-oriented metrics tied to orders, inventory valuation, purchasing, financials, and promised dates. It is usually a poor place for high-frequency shop floor calculations because ERP data is often delayed, aggregated, or not granular enough.

MES is usually best for execution KPIs that depend on real production events, routing status, labor booking, machine states, genealogy, or in-process quality checks. MES can support immediate action, but it often becomes a problem if every site builds local KPI logic differently and no one governs definitions across plants.

Data warehouse, lakehouse, or semantic layer is usually best for enterprise reporting, cross-functional reconciliation, and a governed “official” KPI definition. This works well for board reporting, plant comparisons, and trend analysis. The tradeoff is that it depends heavily on integration quality, timestamp alignment, master data consistency, and stable mappings across ERP, MES, QMS, and other systems.

Another platform, such as a historian, industrial analytics tool, or event-processing layer, may be the right place for machine-derived KPIs, condition-based metrics, or near-real-time operational alerts. But these tools still need alignment with enterprise definitions if the same KPI appears in management reports.

What usually goes wrong

• Different systems calculate the same KPI differently, often because of different filters, calendars, routing assumptions, or treatment of rework and scrap.
• ERP becomes the reporting source for metrics it does not actually observe at the needed level of detail.
• MES dashboards become site-specific and cannot be compared across plants without manual interpretation.
• The warehouse becomes the “truth” layer before source data is stable, so teams spend more time reconciling data than improving performance.
• Formula changes are made informally, without approval, regression testing, or documentation of effective dates.

In regulated and long-lifecycle environments, these failures matter because once a KPI is used for quality escalation, release decisions, supplier management, or executive review, undocumented formula drift creates avoidable audit and trust problems even if no regulation explicitly prescribes that KPI.

A practical operating model

For most brownfield environments, a layered approach is more realistic than choosing a single system:

1. Define KPI semantics once with clear numerator, denominator, exclusions, time basis, data sources, and effective dates.
2. Keep source events in the originating systems and avoid copying business logic into every downstream tool if you can avoid it.
3. Allow local operational calculations close to execution where latency matters.
4. Publish one governed enterprise definition in the analytics layer for cross-site and cross-functional reporting.
5. Put formula changes under change control with documented rationale, validation, and backward-compatibility decisions.

This is not as simple as centralizing everything in one stack, but full replacement strategies often fail in brownfield aerospace and similarly regulated environments. The qualification burden, downtime risk, integration complexity, validation effort, and long asset lifecycles usually make wholesale KPI standardization inside a single replacement platform slower and riskier than teams expect.

Bottom line

If you need one rule: ERP should rarely be the only home for KPI formulas, MES should not be the uncontrolled home for enterprise definitions, and the data warehouse should not invent metrics without disciplined source-system lineage.

The most robust answer is usually:

• MES or operations systems for real-time, action-driving KPIs
• ERP for financial and planning context
• A governed analytics or semantic layer for the official cross-functional KPI definition

That approach is less elegant than a single-system answer, but in mixed-vendor plants it is usually more maintainable and more credible.