If You've Industrialized Bad Data, You Haven't Solved the Problem, You've Scaled It

🏭 Breaking the Bottleneck is a weekly newsletter and interview series covering manufacturing technology and physical AI. Want to chat? Reach out at aditya@machinafactory.org or connect with me on LinkedIn.

This newsletter is brought to you with support from our featured partners: AMT, IMTS, Jiga, Upkeep, and Industry 4.0 Club.

“What happens to my site if this fails at 2 am and your three-person support team is asleep?” Getting that answer right, the risk story, the integration path, and the operational continuity commitment are what separate a pilot from a rollout. That’s where pilot purgatory lives.”

You spent three decades on the operator side, leading global process control at Covestro, then overseeing 100+ discrete sites at Stanley Black & Decker, before joining APERIO. What’s a problem that was structurally invisible to you as a Fortune 500 SVP but became obvious from the startup seat? And conversely, what does the startup side consistently get wrong about how operators actually buy?

The thing that was structurally invisible to me as an SVP at Covestro or VP at Stanley Black & Decker wasn’t the technology; it was the cost of organizational inertia on every decision. When you’re inside a Fortune 500, you assume friction is normal. From the startup seat at Aperio, I suddenly saw it clearly: large operators aren’t slow because they’re unsophisticated. They’re slow because they’re accountable in ways startups never are. A bad call on a 16-site DCS rollout isn’t a pivot, it’s a safety event, a capital write-off, and a career moment all at once. One factor in my long-term success was claiming accountability for technical decisions. That relieved the workforce from the burden and let us move faster.

The flip side, startups consistently treat the technical champion as the buyer. They win the plant engineer’s enthusiasm, only to wonder why the deal stalls. The COO or SVP who controls the capital budget thinks in terms of risk reduction, not feature lists. Startups pitch OEE improvements and ROI calculators; operators are asking, “What happens to my site if this fails at 2 am and your three-person support team is asleep?” Getting that answer right, the risk story, the integration path, and the operational continuity commitment are what separate a pilot from a rollout. That’s where pilot purgatory lives.

OT owns the sensors, IT owns the cloud, and data science owns the models. Accountability is distributed, but someone still has to sign the contract. Who’s APERIO’s typical internal champion today, a plant-level OT lead, a corporate digital transformation VP, a CIO? And once they’re bought in, how do you align the other two seats at the table when each one measures success on a different KPI?

At Aperio, our most consistent internal champion was the end user, typically the OT data historian lead or unit engineer. Not the digital transformation VP, not the CIO. The person closest to the process, who understood the data and felt the pain of not having better tools. This tells you something important about where industrial AI adoption actually lives today: it’s being pulled from the shop floor up, not pushed from the boardroom down. My lifelong experience is that the person whose hands are closest to the process knows more about it than anyone else.

The alignment challenge across IT, OT, and data science remains unsolved industry-wide. OT cares about uptime. IT cares about security and governance. Data science cares about model performance. Those aren’t naturally compatible, and the contract signer is trying to satisfy all three simultaneously with a vendor who only speaks fluently to one of them. Layer on top of that a C-suite chasing the latest technology hype cycle, and you have budget and mandate flowing toward whatever got the keynote at Davos that year, not necessarily what the plant actually needs. When alignment works, it’s because someone with enough organizational authority makes it their problem to broker. When that person doesn’t exist, you get pilot purgatory from the inside. Extremely frustrating for everyone involved.

On a Tuesday afternoon at a plant running APERIO, what is the system actually doing differently from a traditional historian, and at which point in that chain does the error get caught: at the sensor, at the edge, inside the historian, or in the lake? What’s required from a change management perspective to ensure the error is captured, noted, and resolved before it reaches the model?

On a Tuesday afternoon at a plant running DataWise, the system is doing something a traditional historian wasn’t designed to do: actively evaluating OT data quality across the entire enterprise in near real-time. A historian records. DataWise watches.

A board operator has deep experience but finite attention. They’re tuned into a handful of critical tags. DataWise is evaluating anomalies enterprise-wide, from sensors to the cloud, including sensor failures, IT/OT network issues, and process deviations. The error gets flagged at the point it occurs, before it ever reaches the model.

That matters more than people realize. Models are only as good as the data they’re built on. DataWise flags bad data from the earliest stages of deployment, keeping the historian cleaner and ensuring bad data that does get through is identified and resolved rather than quietly corrupting model output over time.

The change management requirement is significant. The technology can flag the anomaly, but someone has to own the resolution. That means clear accountability for data quality, not just process performance, and building the habit of treating a DataWise flag as seriously as a process alarm. In most plants, that’s a cultural shift, not a technical one. And the honest reality is that many industrials simply don’t have the time or manpower to address every anomaly. The system can surface the problem. Only the organization can fix it.

The 80% AI failure rate is often cited, and “data quality” has become the convenient post-mortem. But pilots also fail because of the wrong scope, buyer, KPI, or business case. How much of what gets blamed on data is actually a buying and scoping problem dressed up as a data problem, and how do you know APERIO is solving the real bottleneck rather than the most visible one?

The 80% failure rate citation is real, but “data quality” has become a catch-all that lets everyone off the hook. Pilots fail for all the reasons you listed: wrong scope, wrong buyer, wrong KPI, and data quality is often the most visible symptom rather than the root cause.

That said, for industrials specifically, data quality is genuinely foundational. You cannot train a reliable predictive maintenance or process model on bad data. Industrials are sitting on millions of sensors, years of inconsistent tagging, and an IT infrastructure never designed with model training in mind. That enterprise data mess is real.

But most pilot failures I observed weren’t primarily data problems. They were buying and scoping problems wearing data’s clothes. The champion didn’t own maintenance or operations and couldn’t influence the work that needed to change when the model surfaced an issue. You’d have a model correctly flagging an asset anomaly, with no one authorized to act on it. Or what looked like a model failure was actually a bad sensor throwing the output sideways, and the organization had no process for telling the difference.

Scope is the other silent killer. If the pilot doesn’t connect to what leadership actually measures, it dies quietly regardless of technical performance. The data problem is real. The buying-and-scoping problem is just harder to admit.

Industrial foundation models trained on operational time-series data are starting to appear from the Siemens, GE, and Rockwell sides of the market. Does that future make a dedicated data trust layer less important, because models can learn around noise, or more importantly, because biased data at scale produces confidently wrong outputs across an entire fleet?

The “models can learn around noise” argument is mostly hype, and it’s a dangerous framing for industrials specifically. A foundation model trained on operational time-series data is still being trained on something. If that something includes years of bad sensor data, inconsistent tagging, and unresolved instrumentation failures, the model doesn’t learn around it. It learns from it. At fleet scale, biased data doesn’t produce uncertain outputs. It produces confidently wrong ones consistently across every asset the model touches.

But the more important point is entirely missed in the model conversation. In an industrial environment, a bad sensor can trigger a control action or a safety event. The stakes aren’t a wrong recommendation on a dashboard. They’re a process upset, an unplanned shutdown, or worse. Field instrumentation reliability and data trust aren’t model training problems; they’re operational integrity problems.

The Siemens, GE, and Rockwell foundation models are worth watching. But they don’t eliminate the need for a data trust layer; they make it more critical. You still need a human in the loop who can distinguish a genuine process anomaly from a failed transmitter. Foundation models don’t know the difference. They just scale whatever they’re given. If what you’re giving them is unreliable, you’ve industrialized the problem, not solved it.

To contact Jane, reach out to her on LinkedIn here. She’s always open to chatting and sharing valuable insights.

This newsletter is brought to you with support from our featured partners: AMT, IMTS, Jiga, Upkeep, and Industry 4.0 Club.