Manufacturing intelligence must follow the disruption

A production problem rarely respects the boundaries manufacturers have built between their systems. A supplier delay can alter the plan and leave a line waiting for material, while every application involved still appears to be doing its own job correctly. The gap appears when someone must understand what changed across those systems and decide what the business should do next.

Amit Sharma, President of Manufacturing ERP at QAD, sees the central problem as one of ownership and response. Each application is optimized for its own function, but a disruption can move from the supply base into planning and eventually reach the shift before any one system captures the full consequence. The question is therefore not which system detected the problem, but how quickly the business can assemble a response across them.

“When a supplier delay happens, which system is accountable?” Sharma says. “Is it procurement, planning, scheduling or the frontline system? The impact goes all the way to the factory floor. Many times, human beings are the glue across all those systems, collecting information from email, Excel, supply chain and ERP, and then making a decision based on what they have in front of them.”

The disruption does not belong to one system

Frontline decisions become difficult when every role sees the problem through its own lens. A shift supervisor may be protecting OEE, while a commercial team is worried about a customer commitment somewhere further downstream. Neither priority is necessarily wrong, but optimizing one in isolation can push the cost of the disruption somewhere else.

On the shop floor, the most obvious response to a disruption is often shaped by the immediate pressure to restore production. What looks sensible from the perspective of one line or shift, however, may conflict with commitments being managed elsewhere in the business. A local decision can therefore carry consequences that are not visible to the person dealing with the original problem.

“If a machine goes down, you need to figure out the best course of action, but you should not be limited to the information in front of your screen or to whoever you have spoken to,” he says. “You need to understand the options for handling the disruption and the economic impact. That information needs to be surfaced at the right point in time for that user.”

Producing that view means understanding how information from several systems relates to the same event. Sharma describes this as context engineering: bringing information from ERP, supply chain, manufacturing execution and frontline systems into a common intelligence layer, then giving AI enough manufacturing-specific structure to understand which questions must be asked. A machine-down event should lead the system toward open orders and available production alternatives rather than simply returning more information about the machine itself.

That approach changes the modernization question because the intelligence does not have to sit inside any one underlying application. If context can be assembled across the existing estate and then returned to the user at the point of work, manufacturers have less reason to replace functioning systems simply to create a cleaner architecture. Those applications may be imperfectly connected, but they contain process logic the business already depends on and employees already understand, so the more practical route is to build intelligence across them rather than start again.

“We need ERP because it knows the truth, and we need manufacturing execution because manufacturers have invested in it and trained people to use it,” Sharma says. “What we can do is create an intelligence layer that is specific to the vertical, then bring that intelligence back into the systems where the user interacts every day. If I am looking at a purchase order, I should be able to understand the wider context around that purchase order without ripping and replacing everything.”

Put exceptions in front of the person who can act

Frontline teams do not need another stream of notifications layered on top of the alarms, dashboards and production targets already competing for their attention. The harder design problem is deciding which events deserve intervention and which should remain part of normal operating flow. Sharma argues that manufacturing intelligence becomes more useful when it filters that noise before asking a person to act.

“If I am in procurement and a supplier is delayed by a few hours, that may be inside my threshold and I do not need to be bothered,” he says. “But if that delay affects an open production order, I want to know. I also want the system to assess the impact, show me the blast radius and give me the possible courses of action.”

On a running shift, the usefulness of an insight is determined partly by whether there is still time to act on it. Sauder Woodworking provides a useful example because, before deploying QAD Redzone, a frontline operations platform that connects production information with shop-floor teams, operational data could be about 24 hours behind the activity on the floor. Teams could review what had happened, but they had fewer opportunities to recover performance before the shift was over.

After deployment, operators and supervisors gained live visibility into hourly production performance and recurring losses that previously surfaced after the fact. The initial pilot area moved from about 50 percent OEE to above 70 percent after stabilization, while Sauder reported near-term efficiency gains of 15 to 20 percent. The improvement came from using current information during production rather than waiting for reporting to explain the loss later.

Some production problems can only be resolved through the experience of the people closest to them. The risk is that the solution remains with those individuals, particularly when it emerges during an informal discussion or under the pressure of a live shift. Over time, factories can end up repeatedly solving problems that someone in the organization has already encountered.

“When a disruption happens and people assemble to solve it, there is a loss of productivity,” Sharma says. “If you solved the problem, what were the conditions and what action did you take? We can capture that so that next time something similar happens, users do not have to huddle again and solve the same problem from the beginning.”

AI must earn authority on the shop floor

Recommending a response is very different from allowing an AI agent to initiate one. Actions affecting production can carry consequences that are difficult to reverse, so manufacturers need a way to expand automation without assuming that a technically capable system should immediately be trusted with every decision. Sharma expects the boundary to move gradually as users see how the agent behaves in real operating conditions.

“Every AI and every agent has to earn the right of trust,” he says. “You would not let an intern make decisions on things that are irreversible or have a very large impact. You supervise and monitor them, and over time you decide which things they can handle.”

Manufacturers can make that boundary explicit by defining thresholds around the consequences of a decision. A small change with limited impact may be allowed to proceed automatically, while a disruption that threatens an important delivery or creates significant financial exposure can be returned to a person with the likely consequences and available options already assembled. Sharma also argues that technical guardrails must restrict what an agent is permitted to access or change, with actions logged for auditability.

Authority is more likely to expand when manufacturers can show what happened after an AI recommendation was followed. Sharma says QAD is working on outcome attribution that records the recommendation alongside the user’s response and the resulting economic effect. The same mechanism can capture cases where the user chose a different course, creating a history of where the system added value and where human judgment produced the better result.

“Trust is earned over time,” Sharma says. “People will see where AI can help, and if the recommendations and improvements continue to follow the logic of the operation, that trust will start to appear. There is no magical point where people believe everything overnight.”

Measured outcomes ultimately determine whether manufacturing intelligence becomes part of the shift or remains another layer of software. The goal is not to create another dashboard or stream of alerts, but to connect the systems and people around a disruption closely enough that the right person can act before the cost is already locked in. Intelligence reaches the shift when it helps people understand a change quickly enough to make a decision while the outcome can still be influenced and then measured.