A pragmatic integration pattern for plants that cannot pause the ERP to modernise reporting.
The constraint
The request is usually modest: put production, quality, and maintenance data on one screen. The constraint is that the ERP cannot be modified, cannot be paused, and is governed by a team with good reasons for both.
Any integration that begins by asking for schema changes has already failed. The pattern that works treats the ERP as a source of record to be read carefully, not a system to be reshaped.
Extract on the ERP's terms
Start with read-only extraction through supported interfaces, on a cadence the ERP team agrees to. Land the data in a staging layer you own, and do all shaping there. The ERP stays untouched and its team keeps their guarantees.
Write-back, where it is needed at all, comes later and only where a named owner has asked for it and accepted the consequences.
Model the question the plant asks, not the table the ERP keeps.
Model the question, not the schema
The temptation is to mirror the ERP structure and let the dashboard sort it out. That produces a dashboard nobody can maintain and metrics that disagree with the finance report.
Instead, write down the operating questions the screen must answer — a handful, in plain language — and model backwards from them. Where a number must match an existing report, define it once, in one place, and reference it.
Let latency vary
Not every view needs the same freshness. Line status may need minutes; a maintenance backlog view is fine at hourly; a monthly quality trend can be nightly. Standardising on the strictest requirement multiplies the load on the ERP for no operational gain.
State the latency per view on the view itself. It costs a line of text and prevents a class of argument about whether a number is wrong or simply not yet updated.
Written by the software delivery team. Published articles carry a named author once attribution is confirmed.
