The ERP conversation nobody wants to have
Ask a plant team how to connect its CMMS to MES data, and someone will suggest putting it in the next ERP upgrade. Ask when that is scheduled, and the answer is usually "two years from now, maybe three." Meanwhile, operators cannot cross-reference maintenance history with production output, so decisions get made with only part of the picture.
ERP projects are not the wrong answer for every problem. Structural changes to master data, billing systems, or supply chain coordination may require an ERP overhaul. But for operational questions on the plant floor, an ERP replacement is usually the wrong scope, timeline, and project team.
What connecting factory systems means for most plants
"Connecting factory systems" can mean a data warehouse, API integrations, or file export scripts. For the operational use case we focus on, it means something narrower: establishing a read path from two or three existing data sources so a query layer can return the context needed for a specific operational question.
That read path does not modify source systems or migrate data. It does not require synchronized schemas or a master data model. It requires a read-only connection to each system and a way to interpret the information returned.
The ERP conversation starts when data integration prompts IT teams to reach for the largest available container. An ERP can hold all that data in one place. But storing data together is not the same as making it answerable for the people who need it on the floor.
The read-only layer approach
Most CMMS, SCADA historian, and MES platforms expose a read-only API or database connector. Fiix has a REST API. IBM Maximo has a JSON API. OSIsoft PI exposes an OLEDB interface and REST endpoints. SAP has RFC connections and oData services. With the right credentials and basic system familiarity, establishing one read path takes a half-day to two-day project.
A read path lets people ask questions about data in a system without changing that system. Work orders, PM schedules, sensor logs, and shift output records remain where they are. Queries go in, results come out, and the source system is unaffected.
This is not a new idea. Reporting tools have worked this way for decades. The newer capability is bridging multiple read paths through a query interface, without requiring users to know where data lives or how to write the query.
Where ERP projects get in the way
When a data integration question gets absorbed into an ERP project, the scope usually expands to include data cleaning, master record synchronization, and schema mapping. Those tasks matter in a full ERP implementation. They are not required for a read-only operational query layer.
The timeline also stretches. ERP projects that touch production systems in manufacturing rarely finish on schedule. A project planned for 18 months can run to 24 or 30. The operational question that started the work gets pushed aside until the ERP goes live, when the team has new problems to address.
The project team is usually not the plant operations team. IT and finance stakeholders may have different priorities from the production supervisor who wants to know why Line 3 went down on Tuesday night. By delivery, the original operational question may have been forgotten.
A practical integration order for plant floor data
To make operational questions answerable without waiting for an ERP project, the practical sequence is: start with the CMMS, add monitoring or historian data, then add production output data.
The CMMS is the right starting point because maintenance history is often the most useful source for production questions. When an operator asks why a line is running slowly or why a fault code keeps appearing, the answer is often in work order history or the PM schedule. Making CMMS work orders queryable in plain language can deliver the quickest operational value.
Monitoring or historian data comes next because it adds the time-series context that maintenance history lacks. Knowing that a hydraulic servo was replaced last month is more useful when you can also see the sensor trend before the failure. PI System or Ignition SCADA data makes that comparison possible.
Production output data, shift reports, and OEE records come third. They connect maintenance and monitoring patterns to actual output impacts, but their formats are often messier and more specific to each plant. Starting with the first two connections lets teams answer useful questions while production data integration is cleaned up.
What this approach does not do
A read-only layer is not a workaround. It is a focused way to answer operational questions without changing source systems. It is not an enterprise data strategy, and it does not cover demand planning, inventory optimization, or financial reporting. It also does not replace data governance. Inconsistent failure codes or gaps in historian records will still appear in results.
It also does not remove the need for an ERP upgrade when a plant genuinely needs one. We are not arguing against that investment. We are saying that an operational query layer should not be routed through an ERP project when a faster path can make plant floor data answerable without touching source systems.
The read-only layer and the ERP project can coexist. In most plants we talk to, the ERP project remains on the roadmap for structural reasons while the operational query layer handles day-to-day data questions. They address different problems, and treating them as alternatives is where the conversation goes wrong.