Most data quality problems aren't caused by bad systems or broken integrations. More often than not, they trace back to people. Specifically, to the gap between what the system is designed to capture and what actually gets entered into it.

Here are the two most common issues I see, and what works to fix them.

Issue 1: Your Work Orders, Job Logs, and Tickets Don't Reflect Reality

Statuses aren't updated. Priority fields are blank or filled with placeholder numbers. Callout requests never get logged. Field tickets come in late or incomplete.

We call all of this "work." And whatever system your team uses to manage it, whether that's SAP, Maximo, ServiceMax, or something else, that's your work management system. In our experience, it's almost never kept as current as it needs to be.

Here's a real example. You build a break-in rate metric. The system says 10%. Talk to the team and reality is closer to 25 or 30 percent. The shoulder-tap work, the email requests, the verbal callouts never got logged. The metric isn't wrong because the code is wrong. It's wrong because the inputs are wrong.

Trace it back and it's almost always the same story. A technician or planner, moving fast, didn't know how to fill out a priority field or didn't see why it mattered. So they skipped it.

That's not a technology failure. That's a people and process problem.

How to fix it

I think it helps to step back and think about the people side before you look at the system. What behaviors are you trying to drive, and are you making it easy for people to do the right thing?

Three things need to work together.

First, leadership has to make it clear it matters. If keeping records current isn't part of the job expectation, it's going to keep sliding.

Second, supervisors need something they can act on. What we build for clients is a simple data quality view that flags the specific records causing problems. A high priority work order missing justification. A job log with no due date. Filtered by person, so a supervisor can open it and follow up directly. No hunting.

Third, people need to see why it matters. When you can show a technician that a handful of incomplete work orders is what's pulling the team's numbers down, it stops feeling like paperwork. It starts feeling like part of the job. People want to make a difference. Give them a way to see that they are.

Issue 2: Gaps in Historian and Time Series Data

With work orders and tickets, the data quality problem is usually visible if you know where to look. This one is harder to find.

When PI tags stop transmitting, the gaps they leave behind are easy to miss. With thousands of tags generating data constantly, one or two missing data points feels like a rounding error. Most teams assume it won't matter much. What we find, when we get deep into the data engineering, is that those gaps add up. And when we bring it to clients, they're often shocked by the impact.

A team might think they're leaving $250,000 in margin on the table. Account for the historian gaps correctly and that number is closer to $2.5 million. Same assets. Same operation. Very different picture.

The human failure here is the same as Issue 1. Nobody built the monitoring to stay on top of it. Nobody is watching.

How to fix it

Just like we build a data quality dashboard for work orders, we build one for tag availability. It tracks which tags are transmitting, where the gaps are, and how often they're occurring. That gives teams something to act on rather than a haystack to search through.

In the reports we build that use this data, we also add a low data warning flag. If a metric is being calculated on less than seventy percent of available data, the report flags it. The team can still use the number to unblock themselves, but they know something is affecting its validity and they know where to go to address it.

It's not a perfect solution. But it makes the problem visible. And visible problems get fixed.

Who Actually Owns This?

Ask who's responsible for data quality in most industrial organizations and you'll get a pause, then "probably IT."

IT can't fix this on their own. Data quality is a result of whether people are keeping the system current. Whether work orders are being closed out. Whether callouts are getting logged. Whether PM records are complete. That's an operations problem. It lives in maintenance, in planning, in the teams doing the work every day.

Think of it like a rowing team. If one person stops rowing, it throws off everyone. One team not keeping their records current affects the numbers the whole organization relies on.

Two Things Worth Pushing Back On

"It'll fix itself." It won't. Bad records pile up and get harder to trust over time.

"AI will fix it." AI doesn't fix bad data. It amplifies it. If the foundation isn't clean, your AI initiative is going to hit the same trust problem you already have with your dashboards, just faster and at greater scale. Clean data has to come first.

Where to Start

Start with the metric nobody believes. The one where someone always says "that can't be right."

Trace it upstream. Most of the time the logic is fine. The problem is what's going into the system, whether that's work orders not being closed, callouts not getting logged, or priority fields left blank.

From there, build the visibility. Show supervisors the specific records that need attention. Close the loop for the frontline and show them how their input changes the number.

That's the cycle that builds a data foundation people actually trust. Not a one-time cleanup. A habit.

Quail Group helps industrial companies build the operational foundation that makes technology investments pay off, starting with the people, process, and behavior side of data adoption. Set up 30 minutes with our team to get a free perspective on quick fixes you can implement to drive better data-enabled decisions across your team.