Manufacturing systems are converging around execution

By the time a quality hold reaches purchasing, production and scheduling, the problem has already escaped the software category that first recorded it. A failed incoming inspection may begin in a quality system, but it can leave a line short of material and a planner rebuilding the schedule while procurement is still working from a different view. The factory behaves as one operation even when its software estate does not.

Bryan Sapot, EVP at Nulogy, argues that this mismatch is pushing manufacturing systems back toward convergence after years of investment in specialist applications. Those systems were often selected because individual departments needed depth in areas such as quality or maintenance, and there was little reason to compromise that functionality when each function could optimize locally. The difficulty emerges later, when the business expects those decisions to behave as one operating model.

“The biggest difficulty is the integration between the systems and having to maintain that,” Sapot says. “If you are a mid-sized manufacturer, you probably do not have your own team of people maintaining all those integrations. The systems have different upgrade schedules, things break, and sometimes you do not realize it until later. Then you still have the problem of reporting across all of them because you need them all to run the plant.”

The factory needs a different operating layer

Software vendors are approaching this convergence from different directions, with ERP providers extending toward the shop floor while MES providers broaden beyond traditional execution. For manufacturers, the more useful question is not which software category eventually dominates, but which part of the architecture is expected to respond to the volatility of live production. Sapot draws that boundary around what happens inside the plant.

“ERP is rigid and structured because it is built on an accounting foundation,” he says. “The manufacturing floor is extremely dynamic. You may think you are going to run one schedule today, but 20 people do not show up, or a raw material is missing, and suddenly you have to change the plan. The factory still needs structure, but it must adapt to what is happening on the floor.”

In Sapot’s definition, a manufacturing operating system brings production, quality, inventory and maintenance into a common execution environment while leaving accounting and other back-office functions with ERP. The purpose is not to erase the boundary between enterprise and plant systems but to keep information that affects execution close enough to the operation that one change can be reflected across the decisions that depend on it. Cycle time is a useful example because a single production measure can influence planning well beyond the line that generated it.

Standards written into a system rarely remain perfectly aligned with what the plant is achieving. A new machine, a changed product mix or different staffing can alter real performance while the original assumptions continue to drive the schedule until someone reconciles them manually. When actual operating data feeds the wider execution model, those decisions can adjust with the factory rather than lag it.

“If the real cycle time over the last 30, 60 or 120 days is different from the standard, that should drive the schedule,” Sapot says. “Then I am more likely to deliver on time, have the right staffing and have the right raw materials available. When production, maintenance, inventory and quality share the same operational information, everybody is making decisions from the same picture.”

Integration fails when definitions diverge

Some of the most expensive integration problems appear only after the technical work has succeeded. Data moves on schedule, dashboards populate and both source applications continue to operate normally, yet two teams can still arrive at different answers to the same operational question. Sapot has encountered that problem directly while bringing together manufacturing applications that appeared, on the surface, to use the same terminology.

“You think you are speaking the same language, but you are not,” Sapot says. “One system can calculate cycle time completely differently from another or treat parts differently in terms of where they can run. You can get data from one system saying a job took three hours and another saying two hours and 15 minutes. Which one do you believe? That is the painful and expensive part of integration.”

The practical cost of that disagreement becomes visible when a delay originates in one function but appears somewhere else. Sapot recalls a manufacturer that introduced production monitoring expecting machine breakdowns to explain most of its lost time. The data instead showed that one of the largest constraints was waiting for quality approval at the start of a run, exposing a bottleneck created by the handoff between departments rather than the equipment itself.

“When the first run is complete, the system can automatically trigger the quality assessment and notify the person who needs to do it,” he says. “Most of the information can already be populated, so they are not writing down the part number, date, shift, line and job every time. If you get five minutes back on every product run across multiple lines every day, those minutes add up very quickly.”

Once production and quality share the same workflow, the information gathered for compliance can also influence execution instead of remaining a separate record of what happened. A failed check can trigger action at the point where the issue appears, while traceability and non-conformance data can remain connected to the production event that created it. The value comes less from putting more information on a dashboard than from removing the manual coordination that previously sat between the two functions.

Convergence should follow the problem

Most manufacturers will have to pursue that convergence while continuing to run the software estate they already depend on. Years of customization, local workflows and accumulated data mean any new execution model must coexist with existing systems from day one, often across plants at very different stages of digital maturity. Sapot is clear that the route forward must respect that starting point.

“If I need better non-conformance processes, I can start with quality and expand from there,” he says. “You cannot just rip and replace everything because it is too expensive and disruptive. The idea is to solve the problem you have now, then grow into the other areas as you discover what is limiting performance.”

Production monitoring can provide that first diagnostic layer because it reveals where the factory is losing time before the business decides which additional system or process needs attention. At Louisiana Fish Fry, a US producer of Cajun and Creole food products, downtime data was used to focus maintenance activity and improve shift performance after two earlier production-monitoring deployments had failed to deliver the required visibility. Within the first nine months, the company increased OEE by 12 percent.

What happens next does not always require another software module. Better visibility may show that the answer is a process change or an engineering modification, while other problems may justify deeper quality, maintenance or material-control capability. That incremental approach also gives manufacturers room to keep specialist systems where their additional depth genuinely earns its place rather than treating consolidation as an objective.

As the operational foundation becomes more consistent, AI adds another reason to connect information that previously lived in different functions. Sapot describes one manufacturer that spent about two weeks tracing repeated machine jams and out-of-spec parts back to a change in the steel it was receiving, even though the material arrived under the same part number. Quality data describing the material and production data describing the machine behavior existed separately, leaving people to discover the relationship after the disruption had already become expensive.

AI can shorten that search by looking for patterns across materials, equipment and process performance, but it can also use the same connected context to help workers respond. Sapot sees opportunities for systems to recognize a drifting production condition, guide a less experienced operator through the appropriate adjustment or help a scheduler reconcile more constraints than a person could reasonably evaluate at once. None of those use cases removes the need for specialist systems, but each becomes easier when the plant has a consistent operational picture underneath them.

Manufacturing may therefore be moving into another cycle of software bundling, but the destination is unlikely to be one application that owns everything. The more practical convergence is around execution, where production, quality, maintenance and inventory need to understand the same events quickly enough to coordinate a response while ERP and other enterprise systems continue doing the jobs they handle well. For manufacturers, the test will not be how many applications disappear, but whether the factory can turn information from different functions into a better decision before the problem reaches the next department.