It’s 9 AM.
The morning shift supervisor calls because the real-time Operations dashboard—the one management loves showing visitors—is reporting numbers that make no sense. Line 3 shows 750% efficiency. Line 5 has been “down” for three hours, except it’s running fine. Seven quality samples are still to be picked by the lab logistics team, at least according to the dashboard. The quality team’s results don’t match what Operations is seeing. And nobody knows which number to trust.
This is what data governance failure looks like on a Tuesday morning.
In our latest podcast, we sat down with Wybren van der Meer, strategic data consultant at AG Solution, to talk about the topic everyone needs but nobody wants to discuss: data governance in industrial environments.
Governance doesn’t give you a flashy dashboard or an AI-powered recommendation. It won’t win you innovation awards or make it into the CEO’s quarterly update. But here’s what it will do: it’ll ensure that when you do build that dashboard or deploy that AI model, people actually trust the results enough to act on them.
And in industrial operations, trust isn’t nice-to-have. It’s the entire foundation.
The Trust Problem (And Why Excel Exports Aren’t the Answer)
When we asked Wybren why we should bother with governance—why not just give everyone their Excel export and let them do their jobs—his answer cut to the heart of the matter:
“We need a centre of truth. And this centre of truth requires trust. Trust is the hardest to win and the easiest to lose.”
Think about what happens without that trust. Plant engineers develop their own calculations because they don’t believe the corporate dashboard. Data scientists spend 80% of their time tracking down who changed what and why. Every meeting devolves into arguments about whose numbers are correct. Projects stall because nobody can agree on baseline performance.
This isn’t a technology problem. The sensors work. The historians collect data. The cloud platform processes it. The issue is that nobody trusts what comes out the other end—and for good reason. When the same asset shows up with three different names in three different systems, when calculation logic exists only in someone’s head, when changes happen without documentation, trust erodes fast.
As Wybren noted, experienced engineers “know what is wrong with the data. They know where the gaps and the instrumentation errors are.” But what happens when those engineers retire? What happens when you scale from one plant to five, or when you expose that data to machine learning models that can’t intuit which readings are dodgy?
That’s when governance stops being optional.
What Changed? (And Why It Matters Now)
Data governance in industrial settings isn’t new—experienced engineers have always had implicit rules about what data means and how to interpret it. So why the sudden urgency?
Two things changed.
First, the workforce. As Wybren explained, “We have a lot of new workforce. We have a lot of people that we need to introduce into an ecosystem where there are people that have been working with the data for years.” That institutional knowledge—the understanding that Reactor 2’s temperature sensor drifts after six months, or that Thursday’s batch data is always suspect because of the weekly calibration—used to transfer through apprenticeship. But that doesn’t scale. Not across plants, not across continents, and definitely not fast enough for today’s transformation timelines.
Second, the use cases. We’re no longer just monitoring and controlling—we’re optimising, predicting, and automating. We’re exposing operational data to data science teams, feeding it into digital twins, using it to train AI models. These new consumers of OT data don’t have the operational context to know what’s reliable and what’s not. They need explicit data quality indicators, documented lineage, and clear ownership. They need governance.
The Three Pillars: People, Systems, and Documentation
So what does effective governance actually look like? Wybren broke it down into three interconnected pillars, each essential:
1. People: Roles and Responsibilities
“Governance starts with knowing who is responsible for what,” Wybren explained. Not just who maintains a system, but who owns the data coming from it. Who decides what “downtime” means? Who approves changes to the asset hierarchy? Who’s authorised to modify the semantic model that contextualises your sensor data?
This is where facilitation becomes critical. You need both IT and OT representatives who understand each other’s constraints and can make decisions together. The IT side knows what’s architecturally sound and scalable. The OT side knows what’s operationally viable and safe. Neither can do it alone.
The mistake? Treating governance as purely an IT function. “Many people see that as an IT problem,” we noted in the podcast. But IT doesn’t know that Asset Tag XYZ-123 is actually Pump A in Building 2, or that it typically runs at 85% capacity except during summer shutdowns. That context lives in Operations. Governance requires both sides, working together, with clear ownership defined.
2. Systems: Where Governance Lives
Governance isn’t just policy documents—it has to live in your systems. As Wybren put it, “The model needs to live in your broker landscape. It needs to live in your way where you standardise. The model needs to live in your data lakes.”
This connects directly to the platform capabilities we’ve discussed before (particularly our Industrial Data Platform Capability Map). Your connectivity layer needs to enforce consistent data models. Your contextualization layer needs to maintain the semantic relationships that give meaning to raw sensor streams. Your governance layer needs to control who can access what, who can modify structures, and how changes get versioned.
Without this technical infrastructure, governance becomes Word documents and Excel sheets that nobody follows. The rules exist in theory but not in practice, which is worse than having no rules at all.
3. Artefacts: The Living Documents
Finally, governance requires documentation—but not the “create once and forget” kind. Wybren calls these “living documents” because they evolve as your operations evolve. New equipment gets added. Processes change. Standards get refined. Your governance documentation must keep pace.
“There’s not really a set platform for this type of documentation management,” Wybren acknowledged. In practice, companies use Jira, Confluence, SharePoint—whatever works, as long as it’s structured, searchable, and maintained. The critical part isn’t the tool; it’s having “all your rules and your responsibilities defined, not one without the other. You need the rules and the responsibilities.”
And here’s where many governance initiatives fail: they build elaborate documentation structures but assign no one to maintain them. Or they assign responsibility but provide no authority or time to actually do the work. Six months later, the documents are outdated, and everyone’s reverted to Excel and tribal knowledge.
Start Small, But Think Big
One of the most valuable exchanges in the podcast came when we discussed scope. How do you start a governance initiative without spending three years documenting 300,000 data points?
Wybren’s answer: “I am definitely a supporter of the start small team. But at the same time, don’t start too small.” The key is choosing a use case that’s regionally focused but globally applicable. In his example, a plant had OEE reports that worked locally but didn’t follow enterprise standards. By taking that existing use case—something people already found valuable—and retrofitting it with proper governance, they created both immediate value and a template for global rollout.
This is where “start small, think big” stops being a cliché and becomes a strategy. As we noted in the podcast: “In start small, think big, think big is not optional. You need to know where you’re heading towards.”
You also need to allow for rework. Engineers are trained to design the perfect solution upfront—get the specifications right, build it once, never touch it again. But data governance doesn’t work that way. “You have different phases,” Wybren explained. “You have the phase where you start up the governance, where you say, okay, this is my base layer of rules and documentation. You have your design of your solution. And then when you have that finished, you have your starting base of your living documents.”
That base is never final. It’s the foundation you build on, refining as you learn what works in practice.
Getting People on Board (Without Becoming the Data Police)
We’ve all been there: when Operations hears “we’re implementing data governance,” they’re not usually enthusiastic. It sounds like more bureaucracy, more rules, more things slowing them down.
So how do you get people on board?
Wybren’s answer centres on value: “The main value driver that we use is the solution where you can quickly roll out use cases. This marketplace of solutions where people can say, instead of doing half a year or a year long project, I can just download it and it works.”
This is the platform effect in action. The first use case takes months. The second takes weeks. The fifth takes days. When people see that governance makes reuse possible—that following standards means they can leverage work from other sites instead of rebuilding from scratch—resistance drops fast.
But it’s not just about technical reusability. It’s also about transparency and inclusion. “Being transparent on what you’re doing. IT/OT cooperation is here also really important,” we emphasised. When governance feels like something being done to Operations rather than with them, it fails. When plant managers are part of defining the standards, when operators see their feedback incorporated, when data stewards come from the operational ranks—that’s when adoption happens.
There’s also a cultural element. Wybren mentioned the importance of getting “the lead/support way of working” right, where both IT and OT are invested in the outcome. This isn’t about IT dictating standards or Operations refusing to follow them. It’s about meeting in the middle, with respect for each side’s constraints.
The Work That Nobody Sees (But Everyone Depends On)
Good governance is invisible.
When it works, people simply use the data. They don’t question whether the numbers are right. They don’t spend meetings arguing about definitions. They don’t waste time hunting for the “real” version of the asset list. Things just work.
But that invisibility is what makes governance so hard to fund, staff, and sustain. The ROI is in what doesn’t happen: the projects that don’t fail because data was trustworthy, the analyst hours not wasted on data archaeology, the decisions not delayed by ambiguity.
As we’ve said before in this blog: transformation isn’t about doing everything at once. It’s about doing the right things, in the right order. Governance is one of those right things that, when skipped, causes everything else to crumble.
You don’t need to implement a perfect governance framework on day one. But you do need to start. Define ownership for your critical data domains. Document your standards, even if they’re simple. Build the mechanisms that enforce consistency. Create the processes that make change manageable.
And remember: this work isn’t just technical. As Wybren noted, “There’s also a large part of culture and a large part of people business and some politics that is involved.” You need facilitators who can bridge IT and OT. You need leadership that values long-term scalability over short-term shortcuts. You need data stewards who understand Operations well enough to earn respect and IT well enough to enforce standards.
These people aren’t easy to find. And they’re even harder to empower in organisations where IT and OT still barely talk. But when it works—when ownership is clear, stewards are empowered, and discipline holds—the infrastructure you build today makes tomorrow easier. New plants onboard faster because the models are familiar. New applications work across sites because the context is consistent. New questions get answered quickly because the semantic foundation is solid.
So Where Do You Start?
If you’re reading this and thinking “we need to get serious about governance,” here are the first concrete steps:
Identify your source of truth problem: Where is lack of trust causing the most pain? Failed projects? Wasted analyst time? Decisions delayed by data ambiguity?
Pick one domain: Don’t try to govern everything. Choose one critical data domain—asset master data, production events, quality measurements—and start there.
Assign ownership: Who actually owns this? Not who maintains the systems, but who owns the data and the definitions. Get names and commitment.
Document what exists: Not what you wish you had—what actually exists today. Capture the current state, warts and all.
Build incrementally: Start with basic rules. Add structure as you learn. Allow for rework.
And most importantly: don’t do this in a vacuum. Involve both IT and OT from day one. Make it collaborative. Make it transparent. Show the value early and often.
Stay Tuned for More!
Subscribe to our podcast and blog to stay updated on the latest trends in Industrial Data, AI, and IT/OT convergence.
🚀 See you in the next episode!
Youtube: https://www.youtube.com/@TheITOTInsider
Apple Podcasts:
Spotify Podcasts:
Disclaimer: The views and opinions expressed in this interview are those of the interviewee and do not necessarily reflect the official policy or position of The IT/OT Insider. This content is provided for informational purposes only and should not be seen as an endorsement by The IT/OT Insider of any products, services, or strategies discussed. We encourage our readers and listeners to consider the information presented and make their own informed decisions.
