The data already exists. The problem is the structure.
Almost every production environment already has a historian or SCADA writing measurements every second. The idea that data is 'missing' is rarely accurate. What is missing is the translation into ERP logic. A historian records at millisecond level; an ERP posts at order level, sometimes per day. A PLC works in grams; the purchasing department works in kilograms. A machine knows nothing about an order number. Each of these gaps sounds minor, but together they ensure that the connection between shopfloor and ERP delivers exactly what no one wants: figures that are formally correct but operationally meaningless.
Lesson 1: aligning time resolutions between the historian and ERP postings
A historian stores values per second or per event. An ERP posting is a snapshot tied to an order, a shift, or a day. If you map those two directly onto each other without an aggregation layer, something unexpected happens: you get hundreds of small postings for a single order, or you lose data because the time windows do not overlap. The solution is not to post faster in ERP, but to explicitly define which time window belongs to which order. That sounds obvious, but in practice it means sitting down with production, planning, and finance to agree on what 'complete' actually means and at what point the historian values are closed off. Without that agreement, the connection remains a technical success but an operational failure.
Lesson 2: partial batches closed halfway through a shift
This is the most underestimated problem. An order spans two shifts, but the first crew closes the batch at a moment when the machine is still running. Or an operator splits it manually because the raw material has just run out. In ERP, that moment does not exist: an order is either open or closed. The historian simply keeps recording. The result is a gap: production volume that exists in the sensor data but does not appear anywhere in ERP. You solve this by building a buffer layer that knows when an operator has entered a batch split, and that cuts and labels the historian data accordingly. That requires an explicit interface for the operator, ideally a single tap on the HMI or a simple screen on a tablet, not a separate Excel file filled in after the fact. Without that input, every connection runs blind at precisely the split moments that matter most.
Lesson 3: when a direct ERP connection works against you
The reasoning is understandable: set up a direct connection between the historian and ERP, and data flows through in real time. In practice, that approach has a weakness that only becomes visible when something goes wrong. ERP systems are not designed for the write frequency of a historian. A direct push leads to timeouts, corrupted postings, or an ERP that slows down at exactly the moment production is running hardest. Buffering is not a compromise in this situation; it is the better choice. A lightweight middleware layer that collects, validates, and sends messages to ERP in batches makes the system more robust and keeps ERP manageable. That layer does not need to be complex: a simple queue with validation rules is sufficient. The direct connection is attractive on paper, but in production environments with high write frequencies, buffered synchronization is more reliable.
When is a full rebuild of the core system the better path?
Building integrations on top of existing systems works well when the ERP foundation is solid and the problems are limited to the integration layer. But if the ERP itself cannot support the required model, if order numbers do not correspond to what is actually happening on the floor, or if three layers of middleware have already been built around it that no one fully understands anymore, then it is time to consider whether rebuilding the core system is the better option. That sounds drastic, but an AI-native system designed from the ground up to account for shopfloor data, batch splits, and time resolutions will ultimately require less maintenance than an ERP with seven integrations wrapped around it. The decision depends on how deep the data model problem runs, not on how much data is already stored in the existing system.