Manufacturers need analytics close to the process
The most valuable production knowledge in a factory is rarely held in one place. It sits with the people who understand how a process behaves on a difficult product run, what a noisy sensor usually means, why a shutdown was handled a certain way and which early signal suggests a problem is beginning to form. Central analytics teams can build powerful tools, but manufacturing improvement still depends on putting analytical capability close enough to the people who understand the process.
Brent Railey, vice president of industrial enterprise transformation at Seeq, says the issue is less about who makes the final operational decision and more about who has the tools to build and use the analysis behind it. Where local staff still own large, complex assets, decisions from analytics often remain with engineers and operational specialists. The bigger change has been around who builds the analytics and how manufacturers balance central governance with self-service capability.
“Where I have seen centralisation of analytics is around who builds the analytics themselves,” Railey says. “You are almost playing the game of which analytics should the central function do, and should you do self-service analytics, and what is the value proposition and the risks associated with self-service analytics? Companies that tend to run leaner tend to allow more self-service analytics if their risk appetite permits it.”
Production questions rarely arrive in a neat queue. An engineer may need to understand why a batch drifted, why a turbine bearing failed, why a pump is showing early signs of trouble or why one line is behaving differently from another while the process is still live and the consequences are still unfolding. A central analytics team can support the wider framework, but it cannot be the route for every investigation if the people closest to the process are waiting for someone else to define the problem, locate the data and return an answer.
Process data behaves differently
Manufacturing data is harder to analyse because it is tied to physical behaviour, not just business activity. “Time series has some particular nuances, particularly multivariate time series,” Railey says. “When you’re looking at manufacturing, you’re looking at something much more first-principles oriented. You’re often trying to connect multiple variables together, and each one of those variables is collected at a different sampling rate, so you never get anything lined up in time.”
Those variables do not arrive in neat, aligned tables. One signal may update every second, another every few seconds, while another may be irregular or compressed. Before engineers can compare signals, build correlations or apply more advanced analytics, the data has to be brought into a unified view without stripping away the meaning of the process.
“Each one of those variables is collected at a different sampling rate, so you never get anything that is lined up in time,” Railey says. “If you’re trying to do any more advanced analytics or correlative work, where you’re trying to do machine learning or AI over the top of it, you need a way to bring it into a unified data set.”
Sensors add another complication because they do not always fail cleanly or behave consistently. A tank level reading, for example, can become noisy because of activity inside the vessel rather than a problem with the sensor itself. That means process analytics cannot simply treat every wobble as an outlier. It needs enough context for engineers to distinguish genuine process behaviour from measurement noise.
Spreadsheets cannot carry the load
Manufacturers have long relied on spreadsheets, historians, dashboards and ad hoc reports to investigate production issues. Each has a role, but the approach starts to break down when operations become more complex, and the required answer depends on large volumes of contextualised time-series data. Historians remain critical for collecting plant data, but the tools around them often struggle to support fast, repeatable investigation.
The limits show up when engineers need to investigate rather than simply report. Spreadsheets can pull historian data, but they usually run locally, handle limited volumes and narrow the analytical environment. Dashboards help monitor known conditions, but they often struggle when a useful analysis from one pump, heat exchanger or cooling tower needs to be applied across similar assets.
Railey says ad hoc investigation is where the difference becomes most visible because speed changes the outcome. At a previous employer, a turbine bearing failure triggered an incident call built around the initial assumption that something had gone wrong during startup. Using Seeq, an optimisation engineer was able to analyse multiple turbine signals and identify patterns that had appeared during previous shutdowns and were getting worse.
“He was able to say, no, there was a failure emerging, and they were 20 minutes into the initial incident investigation call,” Railey says. “An incident investigation like this would normally have taken weeks to complete, and he almost got to the conclusion in a 20- or 30-minute call. When you have solid analytic capabilities, you can do a much faster investigation process.”
That is the case for analytical autonomy. It is not about turning every engineer into a data scientist or allowing every calculation to become a new standard. It is about giving process experts a way to test hypotheses, compare patterns and understand events before the trail goes cold.
Governance improves when work is visible
The tension between autonomy and governance is unavoidable. Manufacturers do not want important calculations changed casually, and they need confidence that shared methods remain consistent. At the same time, denying engineers practical tools does not stop self-service analytics from happening. It simply pushes the work into spreadsheets, file shares and opaque local methods that nobody else can see.
“When something is working and you know that it works, you want good governance around it so that nobody unintentionally breaks it by tinkering with it,” Railey says. “However, engineers, particularly shopfloor-type engineers, are dealing with day-to-day operational issues that hit them all the time. If you don’t give them good tools, they end up doing it in very non-standard or opaque ways anyway.”
The stronger governance argument is that unmanaged self-service already exists. “They’re doing self-service analytics now anyway,” Railey says. “They’re just doing it in a way that you can’t see, and they’re making decisions from it in a way the organisation can never know, because it’s an Excel document from a file share somewhere.”
That changes the role of central analytics teams. They are no longer required to answer every local question, but they still define standards, support high-value use cases, govern important calculations and help scale methods that have proved valuable. The aim is not central control or local freedom in isolation. It is a managed environment where useful work can emerge locally and then become trusted more broadly.
AI must keep the expert in view
The arrival of AI assistants and agents adds another layer to the discussion. Railey says some of the strongest current uses are in accelerating search for information, especially where plants already have procedures, P&IDs, manuals and instructions that carry important context. AI can help users surface relevant knowledge faster, but applying agents directly to operations requires care.
The harder question is how far AI agents can be trusted inside operational workflows. “The challenge with large language models is you can give them the same input, and the output could vary,” Railey says. “For a lot of analytical, response or automation use cases, that is not going to work well. You have to figure out how to bring some element of determinism back into those behaviours.”
Seeq’s approach keeps the subject-matter expert at the centre, especially as experienced workers retire or move on. “What we want to do is capture the experience of that SME,” Railey says. “You have an ageing workforce and attrition through retirement, and when that knowledge goes out the door, a lot of times operational capability goes with it. There are lessons that must be relearned as a result.”
That is where event-oriented knowledge capture becomes valuable. If an event can be described, monitored and routed to the right people, the decisions and context around it can be retained for future investigation. The next time a similar pattern appears, the organisation is not starting from memory or a closed incident report. It has a reusable record of what was seen, what was decided and what followed.
The strongest companies will scale local knowledge
Turning one good investigation into a repeatable workflow takes more than the right platform. “You need a culture that is open to sharing data,” Railey says. “You need mechanisms to be able to scale. Where this is useful is if you have the same type of facilities at multiple locations, or similar enough processes for the information transfer to be valuable from one site to another.”
The endpoint is not the largest possible central analytics function. It is an organisation that can capture local knowledge, codify useful experience and make it available where it can improve future decisions. Central governance still matters, but it should enable expert work rather than create a queue for every operational question.
“The philosophy is to scale your best,” Railey says. “The folks who know your process, you’re able to capture their experience and codify that experience and make that experience available to other folks. My personal view is that knowledge is inherently decentralised and inherently localised.”
Manufacturers that understand that distinction will have a better chance of moving beyond dashboards and isolated projects. The value of analytics is not only in better models or larger data platforms. It is in giving process experts the means to investigate faster, govern what matters and share the knowledge that keeps production improving.
