Disconnected systems are holding manufacturing back

Manufacturers have spent years buying software to remove friction from individual functions. Production has one system, maintenance another, quality another and logistics something else again, each often doing its own job well. The contradiction appears when the factory must make a decision that crosses those boundaries and discovers that the systems cannot agree on what the underlying operation means.

Craig Scott, CEO and Founder of Fuuz, argues that fragmentation is rarely the result of a deliberate technology strategy. Plants tend to solve the problem in front of them, choosing specialist applications because they meet an immediate production, maintenance or logistics need. Over time, those individually rational decisions accumulate into a much more complicated software estate.

“What we see across our customer base is that complexity really starts to grow when you get beyond a couple of physical locations,” Scott says. “Companies may deploy the same point solution across sites, but often they do not, especially across different regions. You end up with localized pockets of data, and that makes it very difficult to get operational value across sites and business units, particularly when companies now want to use AI.”

Integration does not create a common language

As application estates became more complicated, manufacturers naturally tried to connect what they already had rather than replace working systems. Integration promised a pragmatic way to move information between departments while preserving the specialist tools each function relied on. Scott argues that experience has exposed a deeper problem underneath those connections.

“We started with integrations about 15 years ago, using integration tools and point-to-point connections,” Scott says. “The problem is that every system has its own definition of an object. SAP might call it a job order, MES a production order and CMMS a work order. You cannot solve that simply by connecting them. You need a common dictionary or definition across the business, so people and systems are talking about the same thing.”

When different systems describe the same operational object in different ways, manufacturers also must decide which version carries authority. One department may rely on PLM, another on ERP and another on MES, leaving people to reconcile the disagreement when a decision crosses those boundaries. Scott says manufacturers increasingly ask where the “golden record” should sit because that determines which information the wider business can trust.

Choosing one vendor ecosystem can appear to offer a cleaner answer, but it can create a different compromise. A manufacturer may reduce integration effort while giving up specialist depth in maintenance, warehousing or production simply to keep everything inside the same software family. Scott instead favors a common operational layer that allows useful specialist applications to remain while giving them shared definitions and a common foundation.

ERP remains important in this model without becoming the natural center of operations. Shop-floor decisions depend on equipment and process data, including live events that enterprise systems were not designed to manage in real time, so the objective is not to make one application the master of the factory. It is to make the relationships between applications understandable enough for decisions to cross them.

Standardize the foundation without standardizing every plant

The effort to create a common operational language can go too far if enterprise consistency starts to dictate how every site must run. Different equipment, products and operating constraints have shaped local processes over many years and removing that flexibility can simply drive plants back toward the point solutions the business is trying to control. The challenge is therefore to establish what genuinely belongs at enterprise level without erasing the differences that make individual facilities work.

“A common platform can support standardization without forcing every facility to work exactly the same way, but it requires the right architecture,” he says. “Each operating unit or facility should be able to inherit rules and operating models from the enterprise, while still having the ability to deviate where the local operation genuinely needs to.”

Local point solutions often emerge for understandable reasons. A plant chooses an application because the corporate system cannot accommodate a process quickly enough, and the workaround becomes part of daily operations. Replicated across a larger network, those practical decisions eventually create the application sprawl the enterprise later tries to unwind.

Once application sprawl becomes difficult to manage, wholesale replacement can start to look like the cleanest route back to control. The danger is that manufacturers treat architectural neatness as an objective in itself and underestimate how much working process knowledge is embedded in the systems already in place. Scott argues that the more useful question is how to create a common foundation without discarding functioning applications unnecessarily.

“I am adamantly against rip and replace,” he says. “Start by building a unified data layer across the enterprise and define how the operation needs to function. Once that knowledge layer exists, you can gradually replace fragmented systems where it makes sense, extend the platform where that adds value, or keep the applications that people already like and integrate them into the common foundation.”

The value of a common operational foundation ultimately depends on whether the workflows built on it reflect how production behaves under pressure. Factory processes are full of exceptions that do not appear often enough to dominate a process map but become critical when they do occur. That makes the experience of the people running the operation an essential part of how those workflows are designed.

“Where we have seen projects fail is when they become an IT project and IT makes all the decisions,” Scott says. “A system integrator can do the discovery and build current-state and future-state maps, but they do not live the business every day. Frontline workers understand the nuances and the things that happen once every six months that never come out in the conference room.”

AI-assisted development could move more design authority toward those users without requiring them to become programmers. Scott recently saw a group of end users build their own applications with Claude on the Fuuz platform, an example he believes points toward frontline teams shaping workflows themselves. Enterprise governance still must sit around that freedom so useful local solutions can be reviewed, reused and prevented from becoming another generation of hidden applications.

AI raises the cost of fragmentation

AI is raising expectations about how quickly manufacturers should be able to turn operational data into decisions, but those ambitions place much greater demands on the underlying architecture. Asking software to reason across production in real time is very different from using it to summarize information from a single business system. Scott argues that this is where many manufacturers are discovering the limits of the environments they have built over time.

“Fragmented applications are probably the single biggest hindrance we see to manufacturers adopting AI,” Scott says. “At the plant you have SCADA, MES, WMS, LIMS and homegrown Excel sheets everywhere. There is nothing that naturally connects all of that operational information, and traditional IT infrastructure is not designed for the transactional volume that OT needs. You need an operational layer between the plant and IT where that information can come together.”

The value of operational intelligence ultimately depends on whether it changes the response quickly enough to prevent a problem from becoming more expensive. A quality drift or equipment issue can continue creating waste while the information describing it is technically available somewhere in the system. Scott argues that the next step is to shorten the distance between detecting the problem and acting on it.

“Dashboards have a place, but when I worked in operations, I never had time to sit and look at one,” he says. “I was on the floor, moving between departments and putting out fires. If a quality issue is trending out of spec, putting it on a dashboard while the machine keeps producing poor product for another 30 minutes is not enough. We should be using the technology to get the right alert to the right person and, where it is safe, act on the problem directly.”

Giving plants the ability to create those responses introduces a governance challenge alongside the opportunity. Scott argues for application governance similar to the discipline manufacturers already apply to quality or engineering changes, allowing local teams to solve problems while enterprise teams retain visibility and decide whether a solution should be reused elsewhere. Without that control, citizen development risks reproducing the fragmentation manufacturers are trying to remove.

Manufacturers will ultimately learn more from the speed and repeatability of operational improvement than from counting how many applications have disappeared. Reduced licenses and integration effort have value, but the operational test is whether they can solve problems faster and reuse those solutions across sites without rebuilding them each time. AI may finally force the issue because it cannot coordinate a factory it cannot consistently understand, making a shared operational language more important than the pursuit of one system to run everything.