Podcast Episode 37 min
OT Data Governance with Wybren van der Meer
A deeper dive into our conversation with Wybren van der Meer on the unglamorous work that makes scaling possible
In This Episode
- Wybren van der Meer moved from eight years studying physics into automating Siemens' logistics tracing so thoroughly that he ran out of work, which pulled him toward data, and he's spent nearly eight years at AG Solution consulting on industrial data governance.
- Wybren's starting point for any governance conversation is agreeing on what "data" actually means at a given company, since its scope varies wildly, sometimes covering everything, sometimes just batch information, and different companies structure their governance domains completely differently.
- Wybren structures data governance as a three-layer pyramid: strategy at the top (why are we doing this), a middle layer translating that vision into concrete direction, and an implementation/control layer at the bottom (the actual practical rules for connecting new data sources, security, and confidentiality).
- Wybren demonstrates his own principles with a home coffee roaster wired via Raspberry Pi and OPC UA, streaming to both AVEVA PI and Ignition simultaneously to stay technology-agnostic, while keeping his actual roasting recipe isolated in an internet-free domain since it's more confidential than the resulting roasting reports.
- Wybren's clearest ROI case for governance: specifying exact data formats and protocols in vendor requirement documents upfront saves an entire follow-up project later, since without that discipline, teams end up needing a separate integration project, with fresh vendor calls and licensing costs, just to retrofit a new SCADA system's data into existing reports.
- Wybren advises starting governance rollouts small but not too small, pointing to a South American regional program where a manager already wanted better cross-factory OEE comparisons, giving the effort a built-in internal sponsor who benefits directly once the properly standardized solution then spreads globally.
Meet Wybren van der Meer: From Physics to Automating Himself Out of a Job
00:00 – 03:16Wybren van der Meer studied physics for eight years, split between the Netherlands and Belgium, before joining Siemens to work in logistics, automating the company's way of tracing shipments. That automation went so well that he eventually found himself with very little left to do, which pulled him toward data instead, combining a physics grounding in understanding processes with a growing interest in what actually sits behind the data describing them.
He's spent nearly eight years since at AG Solution, working across many different data domains, software platforms, and technologies, noticing real recurring commonality across them. More recently, his focus has shifted toward consulting specifically on data governance, running large programs aimed at bringing industrial data together with the data organizations actually need to learn from.
“This automation went super fast... eventually when everything was automated, I had very little to do on the day. And I started looking into data.”
Wybren van der Meer · 01:03
Why "Data" Means Something Different at Every Company
03:16 – 05:21Wybren's first principle for any governance conversation is agreeing on what "data" actually means, since its scope varies enormously between companies. For one client, data can mean literally everything that qualifies as information; for another, it means specifically batch information and nothing more.
Companies also structure governance domains very differently: some cleanly separate production, HR, and safety into distinct domains, while others treat everything as one undivided whole. Establishing exactly what data, and what domain boundaries, a governance program actually covers is, in Wybren's view, the essential first step before anything else can happen.
“For one company data can mean everything, everything that is information. And for another company data can mean just the batch information... it is very important to have a good understanding of what is the data that we are leveraging.”
Wybren van der Meer · 04:07
A Single Source of Truth Requires Trust — Hardest to Win, Easiest to Lose
05:21 – 06:42Wybren frames the core goal of good governance as building a genuine center of truth, and that center only works if it's genuinely trusted, which he calls the hardest thing to win and the easiest to lose. Getting there requires a solid, fact-based system underneath it: a set of rules rigorous enough that people can actually rely on a given source being correct, rather than trusting it purely out of habit.
“We need a center of truth. And this center of truth requires trust. And trust is the hardest to win and the easiest to lose... you need to have a good facts build system.”
Wybren van der Meer · 05:21
Why Governance Matters More Now: A Generational Workforce Handover
06:42 – 08:02Wybren points to a real structural shift driving urgency around governance: a large wave of new workforce entering an industry where veteran staff have long trusted their data simply because they personally know its quirks, exactly where the instrumentation errors and rule errors tend to hide.
Handing that same system to a large influx of new people who lack that tacit knowledge requires making the data's trustworthiness explicit and clearly documented rather than relying on institutional memory, a shift Wybren sees companies increasingly recognizing they need real structure to support.
“If you bring someone new into this system, and even more, if you bring half a new workforce into the system, you have to make sure that this is clear cut, trustable and ready to hand over.”
Wybren van der Meer · 06:42
From Data Mountains to Data Value: The Rise of ML and AI in Leadership
08:02 – 09:12Wybren also notes a broader cultural shift: higher management increasingly wants to apply machine learning and AI to compare plants and locations across longer time periods and larger datasets than before.
The underlying mindset has changed too, moving from simply accumulating data, "throwing it on a mountain," toward actively asking what real value can be extracted from it and how to process it into something genuinely usable for improvement.
“The culture around data has changed in the last few years where we are looking more and more into what value can I get out of it? Instead of just throwing it on a mountain.”
Wybren van der Meer · 08:02
Data Governance Is More Than Legal Rules — It's a Pyramid From Strategy to Implementation
09:12 – 11:40Wybren pushes back on the common, narrow assumption that data governance is mostly about legal rules, sharing policies, locking your PC. The real scope also covers reliability and trust: knowing sensors are streaming to the right place, knowing which reports and information sources are genuinely more or less reliable.
He describes governance as a three-layer pyramid. The top layer is strategy, why are we doing this at all, drawn from the company's broader and digital strategy (for example, wanting to be the safest and best at treating data). The middle layer translates that vision into concrete direction: what specifically needs building to get there. The bottom layer is implementation and control, the actual practical rules, like how to connect a new data source, and the real distinction between security (keeping data safe) and confidentiality (deciding who it's actually shared with).
“It's also touching on this topic of reliability and trust... You will need a classical approach to policy and governance. In the end is a pyramid... on top, what am I doing? Why am I doing it?”
Wybren van der Meer · 09:12
"Data Police" Is Meaningless Without Real Ownership and Follow-Up
11:40 – 13:46Rules alone, what Wybren jokingly calls being the "data police," mean nothing without a defined ownership and responsibility structure, and a genuine way to follow up on whether people actually comply. Without that follow-up mechanism, the real value delivered by a governance model stays very low.
He's also more forgiving about flexibility than people might expect: deliberately leaving certain areas flexible, like which machines or vendors get connected, is entirely fine as long as it's a documented, reasoned decision rather than an oversight. A well-argued, recorded flexible model still counts as good governance in his book.
“Governance without a team of ownership and responsibilities means nothing... if you don't have a way to follow up on the governance that you make, the end value that you get out of it is very low.”
Wybren van der Meer · 11:40
The Coffee Roaster Demo: OPC UA, PI, and Ignition All at Once
13:46 – 15:18Wybren brings his principles to life with a genuinely fun personal example: his home coffee roaster, wired through a Raspberry Pi into OPC UA, streaming the amperage going to the roaster's heating element, the drum's rotation, and the resulting temperature simultaneously to both AVEVA PI and Ignition. He does this deliberately to stay technology-agnostic, since his client work spans a wide range of different platforms.
He extends the example into what real scaling would require: upgrading to a bigger roaster or replicating the process elsewhere would demand defining the information's exact shape, thinking through its full lifecycle (when it's generated, used, and eventually destroyed), and locking down security so a hacker couldn't tamper with roaster settings and ruin a batch of coffee.
“Right now I have my coffee machine connected by a Raspberry Pi that is connecting to an OPC UA... I'm streaming it to AVEVA Pi and to Ignition at this point... I'm more or less trying to be technology agnostic.”
Wybren van der Meer · 13:46
Protecting the Recipe, Sharing the Report: Confidentiality as Its Own Governance Pillar
15:18 – 17:49Wybren extends the coffee example into a genuinely useful lesson on confidentiality: since bean size, origin, and weight all directly shape his roasting recipe, the recipe itself needs to live in an isolated domain with no internet access at all, while the resulting roasting reports, which reveal far less, can be shared much more freely.
He frames this as one of several governance pillars alongside architecture design, data lifecycle, and security, plus a genuine risk assessment of what actually happens if a given piece of data leaks, distinct from how sensitive that data is in the first place. All of it converges into a real data management framework carried by an actual organization: specific people explicitly responsible for specific domains, one person owning the accuracy of process-report data, another owning the correctness, safety, and connectivity of the recipe data itself.
“My recipe system has to be safe. I need to put my recipe system in a domain... which has no access to the internet, but I still want to have the data in my reporting... the recipe has a higher confidentiality than my roasting reports.”
Wybren van der Meer · 15:18
Even Tap Water Matters: Supply Chain and Master Data in a Global Comparison
17:49 – 19:12Extending the coffee metaphor further, Wybren points out that something as seemingly incidental as local tap water composition genuinely affects taste and output, meaning meaningful cross-location comparison has to account for supply chain and master data differences too, not just pure process data.
The goal, he stresses, is still a uniform model or format, tying directly into unified-namespace-style thinking, that lets an organization meaningfully compare fundamentally different local contexts on a consistent basis.
“The tap water that they are using in their processes has a big impact on their taste... the supply chain has an impact on it. This master data has an impact on it. It's not only industrial data anymore.”
Wybren van der Meer · 17:49
Why Vendor Requirements Documents Save an Entire Project Later
19:12 – 22:42Wybren distinguishes brownfield governance work, expanding an existing environment, from pure greenfield, starting from nothing, which he calls the easiest scenario since you simply define the rules from day one. The key brownfield lesson is stepping in early, ideally embedding governance requirements directly into a new vendor's requirements document from the very start of a project, specifying exactly how that vendor should format and deliver data, for example matching a defined JSON schema that plugs straight into an existing UNS.
Without that upfront discipline, teams routinely end up needing an entirely separate follow-up project just to retrofit a new SCADA system's data into existing reports, incurring real extra cost, delay, and vendor licensing fees, purely because the original connection specification wasn't nailed down from day one.
“If they had already made sure that they were using an open protocol and the right structure, they would have saved a lot of time and money.”
Wybren van der Meer · 20:25
The Real Payoff: Applying an Existing Use Case Instead of Starting From Scratch
22:42 – 23:45Plants often don't independently see the need for, or benefit of, a proper governance structure until it's demonstrated concretely. Wybren's clearest example of the real payoff: with a properly matching structure already in place, deploying something like an energy-management or OEE program at a new site becomes as simple as confirming the structure matches and downloading an existing, proven model built elsewhere in the company, rather than launching an entirely new integration project with fresh vendor calls and system-integrator work.
“If you get this structure correctly... you just say, okay, my model matches. I know that the company does OEE in another location. Their model matches my model. I download it. I apply it. It works.”
Wybren van der Meer · 22:42
Minimizing, Not Eliminating, Technical Debt Through Early, Reasoned Choices
23:45 – 27:38Wybren doesn't believe technical debt can ever be fully eliminated from these programs, but he's clear that early wrong choices compound into missing pieces that later have to be retrofitted at real cost. The real discipline is minimizing that debt through reasoned, documented decisions rather than defaults made without much thought.
His practical example of manageable standard proliferation: even having three different piping standards instead of one is workable, as long as all three are clearly documented, since expanding from one factory to another then simply requires checking whether the standard matches, applying directly if it does, adapting if it doesn't.
“Minimizing this technical debt, I don't believe that you can have no technical debt, but minimizing this is part of the exercise.”
Wybren van der Meer · 26:28
Ownership, Systems, and Documentation: The Three Things Governance Needs to Actually Live Somewhere
27:38 – 30:45Wybren reiterates that ownership needs to be a formally defined, delegated role, a specific person genuinely accountable for keeping a specific slice of information, like recipe data, accurate and current. But ownership alone isn't enough: the governed information also needs a real system to physically live in, a broker landscape, a standardized model, actual data lakes, and real documentation, the rules and artifacts themselves, housed in a genuinely well-structured, intuitive repository.
He candidly admits there's no single agreed-upon platform for this kind of governance documentation across the industry, mentioning tools like Jira, Atlassian, or a well-structured SharePoint as common real-world choices, with the explicit goal of making that documentation as intuitive to navigate as a unified namespace itself, so anyone can glance at the repository and immediately know exactly where to look for a given rule, responsibility, or data model.
“You need the rules and the responsibilities and they need to be a formalized structure... I want to be able to go into this document repository... and I need to be able to see in one glance... I need to look there for these rules, for these responsibilities.”
Wybren van der Meer · 29:03
Start Small — But Not Too Small: Finding an Internal Sponsor Who Already Wants to Win
30:45 – 33:54Wybren generally supports a "start small" philosophy for governance rollouts, but cautions against starting too narrowly. His live example is a South American regional program with locally scoped use cases that are actually globally applicable, led by a regional manager comparing OEE across factories using a report that doesn't yet properly follow governance standards.
Bringing that existing situation under proper governance works especially well precisely because the manager already wants the solution to succeed, giving the program a built-in internal sponsor. If that manager follows the rules and the resulting solution then successfully spreads globally because it's properly standardized, that sponsor effectively wins twice, exactly the kind of organic momentum that helps build the broader cultural buy-in a governance program actually needs.
“I'm definitely a supporter of the start small team. But at the same time, don't start too small... this already creates a sort of internal sponsor that you need to run this program forward and help in the culture that you need.”
Wybren van der Meer · 30:45
From Planting the Seeds to Growing the Documentation Organically
33:54 – 37:11Wybren describes distinct phases in these programs: first establishing a baseline layer of rules and documentation, then designing the actual solution. Once that foundational layer of "living documents" exists, living because it keeps evolving over time, he considers a large chunk of the genuinely hard work already done; from there, an ongoing operational team takes over growing and maintaining that documentation as implementation, execution, and support continue, gradually extending the initial seeds into a fully mature organizational structure.
He points to a "marketplace of solutions," letting teams download and deploy an existing, proven use case in a fraction of the time a from-scratch project would take, as the real driver of enthusiasm, both clarifying the "why" for stakeholders and generating real excitement as that capability comes into view. He closes by underscoring that none of this is purely technical: a significant part of the work is culture, people, and even a bit of politics, meeting with stakeholders, convincing them, and choosing the right words matters just as much as the technical architecture itself.
“This governance and design is really planting the seeds that you need in order to have your right documentation. And then in your operation and in your implementation, you grow those out to a fully grown network.”
Wybren van der Meer · 33:54
Full episode transcript raw feed ▸
Speaker 2 (00:01) Welcome to the ITOT insider David. I think today we have somebody whose name we can pronounce a hundred percent correct. We have Wybren van der Meer. eh Good luck trying pronouncing that outside of the Netherlands or Belgium. So uh Wybren is a strategic data consultant, but I see you more as the industrial data geek at AG Solution. And so we're very happy to have you here to talk about our favorite topic in general, data. Welcome. And yes, Speaker 3 (00:37) and maybe if we compare that to the rest of the world, our second favorite topic, how to work with data, right? Reuben, thank you for joining us. Hey, start by your introduction, uh a bit of your backgrounds. I know you also have a background in applied physics, which is kind of interesting as well. So why don't we start there and walk us through your career? Absolutely true, absolutely true. Speaker 1 (01:03) Yeah, physics is where I come from. I've been studying physics for forever. um I did eight years of physics, split between the Netherlands and Belgium. After that, I started working for Siemens, a very well-known company to most of us, where I worked in the logistics department, where I automated their way of tracing logistics. This automation went super fast. in a way that eventually when everything was automated, I had very little to do on the day. And I started looking into data. And this is where a bit of my passion comes from, from the physics side, understanding the processes, but from the data side, understanding what is behind it and how it works. In that sense, I started working with AG Solution because you only need one good solution for your data. This is a secret model to the company where we, no, no. And I've been working for seven, almost eight years for AG solution, working in different data domains with a lot of different softwares and technologies where I've seen a lot of commonality, a lot of things that are same throughout your data ecosphere, throughout whatever you use to bring your information together. And there in the last few years, I've been more and more consulting on the stories around data governance and you work with data. So there is a little bit my history, a little bit of what I'm doing now, and there I'm running a few really cool, really big programs on how do we bring industrial data together with the data that you need to learn something from. Speaker 2 (02:42) Okay, so if you do data governance, you must be the most sort of guy after guy at a party, I imagine. Yeah, think data governance is a bit like having to eat your veggies. You know you need to do it, it's just not the most sexy topic, if I'm honest, to talk about. It doesn't always get the attention that the big... applications gets that deliver value immediately, of course. Speaker 1 (03:16) Yes, exactly. Speaker 2 (03:17) mean, and that's what we all want at least. Yeah. Speaker 3 (03:20) I think the interesting thing here is to stay a bit in, you made a very interesting analogy here, Willem, is um data governance is also something which I think operations perceives as something IT does. Like, is that our problem, question mark? Yes, it is. But we're gonna talk about that today, but I think many, many people see that as a IT problem. And from... my perspective, and why don't we start with the definition, Wybren, because from my perspective, there is also not really, like there is not a real clear definition, at least in my, in my mind. Like what is data governance or to make it bit more uh specific, maybe what is data governance in an industrial context? Yeah. Speaker 1 (04:07) Yeah. Yeah. And I think there you touch a very important point. We have to make sure that the definition that you and I use is the same. That when I speak about data, that you know what kind of data I am speaking about. in the setting of industrial data, it can mean something different for each of the companies that we are working with, for each of the places that we work with. In AG, I see many different industry sectors, see many different manufacturing locations, many different styles of products. And for one company data can mean everything, everything that is information. And for another company data can mean just the batch information. And there it is very important to have a good understanding of what is the data that we are leveraging. Where is the scope of this data governance? Where do we set the boundaries? What is our domain? Let's say. We see some companies that divide those domains that say, okay, we have a specific production domain, we have a specific HR domain, we have a specific guidance and safety domain. And we have companies that say, no, no, everything is together. And this is very important to see and say, what is this data in order to say, how do we govern it? Speaker 2 (05:21) Okay, but just playing the devil's advocate here is, you know, why are you complicating life, Wybren? I mean, just give me my Excel export, let me do my thing, because I have a job to do. Yeah. Speaker 1 (05:37) And I think that touches on things that you discuss on the daily base. We need a center of truth. And this center of truth requires trust. And trust is the hardest to win and the easiest to lose. You need to make sure that this trust is there and to be able to have this trust in place. You need to have a good facts build system. that allows you to say, this source of truth, it is the truth. And I can rely on it because we are following a set of rules that make me trust that source of truth. So it is a little bit like the greens, but you still need your vitamins. Speaker 2 (06:16) changed then over the past years? Because if you look at the context of a plant, mean, those engineers have been working with data since the beginning. It's like decades and decades. So was it a topic then? I don't think that the Dharma was out at the time yet, defining the different layers of governance and data management. So what changed? Speaker 1 (06:42) I think what changed is that the industry itself has changed quite a lot over the years. We have a lot of new workforce. We have a lot of people that we need to introduce into an area or into an ecosystem where there are people that have been working with the data for years and they trust it because they know it. They know what is wrong with it. They know where the gaps and the instrumentation errors are, and they know where the rule errors are. And if you bring someone new into this system, And even more, if you bring half a new workforce into the system, you have to make sure that this is clear cut, trustable and ready to hand over. And I think that's one of the changes that we are seeing and one of the changes that companies feel that there needs to be a good structure to be able to do this. Speaker 2 (07:27) I think this reminds me of the uh comments that I think uh Bert made from times here when it came to data quality. The main people who will want to have proper data quality tracking, for example, are not going to be the people who understand that, know, but it's okay. I know that the sensors in this reactor, they fail after so much time, so with some deviation, I know it's going to be all the other people who start using the data as you start to expose it into... data science teams, machine learning, AI, et cetera. Absolutely. Speaker 1 (08:02) And we see a lot more use of this machine learning and AI side on also the higher management team, on the people that look at comparison of locations and plants over longer time periods. They want to compare data over longer time stretches. They want to compare more data. The culture around data has changed in the last few years where we are looking more and more into what value can I get out of it? uh Instead of just throwing it on a mountain of saying, okay, but what do I need from this mountain? And how do I process it into something that I can consume something that I can use to improve. I'm gonna try it here. Speaker 3 (08:44) I'm gonna say it. But what is governance? So we've talked a bit, we've talked about data, sure. We've talked on there are things changing and also obviously with AI tools and all this and reporting going everywhere and flowing everywhere and even uh legal constraints or, et cetera, et cetera. But then the question still is, but what is then the governance side? Speaker 1 (09:12) Now, and I think the legal one that you mentioned is definitely part of it. It's the first thing that people think of when you say data governance, they think, yeah, it's the rules for when I share something and I share it wrong or when I leave my PC unlocked. Those kinds of things are things that people think about when they hear about data governance, but it's a lot more. It's also touching on this topic of reliability and trust. How do I know? when to trust my data, how do I know that my sensors that are coming in, that they are streaming the data to the right place, that it gets combined and that the report that I see at the end has a high sanity value, has a value that I can look at and say, yeah, I know that this is good, this is right. Or I have a report to decide, and more more governance reports, where you can say, okay, these informations are reliable, these informations are less reliable. To get from this mountain of data, and data flowing everywhere to a place where you can say, I trust this data because I know what is behind it. You will need a set of rules. You will need uh a classical approach to uh policy and governance. In the end is a pyramid that I've shared it with you, but it's a pyramid where you say on top, what am I doing? Why am I doing it? You get your strategies. from your company strategy and your digital strategy, where you say, I want to be the best in treating data. I want to have the most safe construction of how to use my data. Based on that, you will develop your what? Your middle layer, where you say, okay, if I want to be a company that treats my data in the safest way and that moves toward machine learning and AI, what do I have to do to build this vision? And if you have that clear, Then you have your regulations and your concepts a little bit more clear, which allows you to start working on the lowest layer, the how do you do it, which is what many people know as the governance side. But this is your implementation and control layer where you say, these are the rules if you want to connect a new data source. This is the security on this kind of data. This is the confidentiality. Of course, the security is how you keep it safe, but the confidentiality is... Mm-hmm. Do I share it with you? Do I share it with an external party? Do I share it freely? And those kinds of things are considerations that you have to take in each of those layers of the simple pyramid. Speaker 3 (11:40) because nobody likes rules. How do you em enforce those? em Will we be sending in the data police? Speaker 1 (11:51) Yeah, and that's a good one because that's term that I use on a daily basis as well. But yes, yeah, I mean, when you say data police, everybody knows what you're talking about. But in the end, governance without a team of ownership and responsibilities means nothing. I can make the rules, but if you don't have any way to follow this up, no way to report on how people are following the model, those kind of things, if you don't have a way to follow up on the governance that you make. the end value that you get out of it is very low. And on the other side, if you have everything strictly defined and you know why each decision is made within your governance model, because... To be honest, it is not a problem if you make a governance model where you say, leave flexibility in these zones. I leave flexibility in which kind of machines you connect. I leave flexibility in which external parties you work with. If you make this decision based on a good argument and you have that noted down, if you have that recorded, it's also still a good version of governance. It's also still a good model. Speaker 3 (12:58) Yeah, you mean if that's the, yeah, if we agree that we, yeah. I wanna make this more concrete. I happen to know that the three of us share a common passion and that's a passion for coffee. um Being in specialty coffee. I also happen to know, Iberen, that you have your own uh roaster um at your house, I assume. Speaker 2 (13:21) That's next level. Speaker 3 (13:22) And I also happen to know, because that's how we first started talking, that Willem, Webern even has linked uh the OSI Pi, now the AVEVA Pi system, to his home coffee roaster. Speaker 2 (13:40) Next you're going to tell me you have like an online HPLC connected to your coffee machine. Speaker 1 (13:46) No, right now I have my coffee machine connected by a Raspberry Pi that is connecting to an OPC UA. And from this OPC UA, I'm grabbing the amperage that goes to the roaster heating element and I'm grabbing the rotation of the bin and I'm grabbing the temperature, which is of course the end result of what you need to control the process. I'm grabbing that in OPC UA and I'm streaming it to indeed to AVEVA Pi. and to Ignition at this point. Because in my multitude of working with different customers, I also see a lot of different technologies. And as you both know, I'm more or less trying to be technology independent, technology agnostic. So I want to see every way that all of these systems can connect. So I know how to connect it with Pi. I know how to connect to Ignition. Speaker 3 (14:35) suppose, Wibberen, that your hobby gets out of control and we're roasting coffee beans. It's obviously a batch process. So we put in some beans, roast it to a certain temperature for a certain duration, you better than I. And that's my batch somehow. How would you suppose that this grows out of control? How would you start implementing a data governance ideology principle? Speaker 2 (15:08) Yeah, why? That's maybe a bad... sure David that their worries are not data management. That's not their problem. Speaker 1 (15:18) for sure. Yeah, yeah. But if you want to make sure that, for example, if I want to take my coffee roasting to a next step and I buy a bigger roaster, or if I want to duplicate my process and put it somewhere else, then I need to start setting the rules of how do we combine information. How do we bring information to a point that I can use it? Which means I need to know how the information looks. For me, that's easy. I know how the information looks. But I need to know the life cycle. When is the data generated? When is it used? When is it destroyed? I need to work on how do we do that? How do we generate, destroy, use data? I need to work on the security part because in the end I want to be able to make sure that hackers cannot come in and change the settings on my roaster so my coffee fails. So I want to separate those. Speaker 2 (16:03) competitive by the way. You'll have roasters looking for each other's roasting recipes maybe. Speaker 1 (16:08) Maybe, maybe. yeah. Yeah, especially since coffee roasting is a very product dependent industry, the size of the beans and the way that the beans are and where they come from and their weight is absolutely, absolutely a factor in your recipe. So I don't want them to steal my recipes either. So my recipe system has to be safe. I need to put my recipe system in uh a domain in an area which has no access to the internet, but I still want to have the data in my reporting. I need to have a good architecture design, which is one of the pillars of the governance is this good architecture design. One of the other pillars is this life cycle. One of the pillars is the security. And then of course, we need to know the risk. What is the risk of one of my roasting reports getting out? Okay, then you see how the coffee is made and maybe I don't mind sharing the roasting reports, but my recipes is something that I want to keep to myself. So the recipe has a higher confidentiality than my roasting reports. And this all leads me to a sort of design of this data governance, how you manage your data, this data management framework, which is then what I like, I said, it's the governance carried by an organization. So I need someone that has this responsibility, someone that can say, okay, you're responsible for the roasting process. So you are responsible for making sure you give me the right information. You are responsible for the data, for the recipe data. So you are responsible for making sure my recipe data is correct and safe and connected. And then bringing this together, it makes a model where I have a set of rules and an organization that carries and maintains that set of Speaker 2 (17:49) I'm thinking for example about uh Coca-Cola who has a secret recipe. I mean, I'm pretty sure they don't care that much about how the bottling happens, but they don't want the master recipe to get out. So they're going to treat that very differently, I imagine. Absolutely. Speaker 1 (18:06) And there also the factors that you have, like the tap water that they are using in their processes has a big impact on their taste. And this is something that you need to be able to compare to say, okay, but we have this recipe in this geographical area and this recipe in this geographical area. What are the differences? How do we use our materials different? Because that's also one of the things that we want to consider is the supply chain has an impact on it. This master data has an impact on it. It's not only industrial data anymore. When I bring the metaphor of this coffee roasting in, if I would do this in different locations in the world, it also means that the supply chain for those locations is different. It also means that the supplier is different, but still I want to have some model that captures this in a uniform way that I can start reporting in this model, that I can start bringing this information. in the right format into a U and S or into a way that we gather information uniformly to bring this to a point where we can do these comparisons. Speaker 3 (19:12) Suppose that I am the operations manager of the coffee roaster. My priority, for example, I have a scaling priority. have more customers than I can, I have more demand than I can currently deliver. So my priority as an operations manager is gonna install a new line and we're gonna commission the new line and... And know, maybe we had SCADA system A in the past, but you know, our ideas has changed and you know what? We got a very nice offer from a vendor. So let's go for SCADA system B, you know, whatever. In my mind as an operations manager, like data governance is never gonna be this, wait, and we also need data governance. So like I'm wondering like, when are you stepping in and why are you stepping in? And are you stepping in because a guy or woman thinks they have a data governance problem or are you stepping in because... I don't know, they are like stuck and they go like, Rebron help us and you go like, yeah, but like... Speaker 1 (20:25) so there are different scenarios. em And the scenario you mentioned is more of a brownfield scenario where you already have something existing and you want to expand it. Of course, you also have the scenario where you have nothing. That's the easiest scenario because then you say, here are the rules, make it. em But for this scenario that you mentioned where you have something and you want to expand it, it is very important to step in early. So I make sure that I am either stepping in myself or that the information from the governance is clear within the project that is being done. uh And of course you need to motivate this. There's no reason for you to have this data governance, at least you think from the start. You don't need it. You can just connect the new machine, connect the new line, it will work. But then your manager will come to you and they'll say, okay, but how do I get this to show up right on the report? Okay, they have to start up a next project to make this one-to-one connection between the new SCADA and the old report to make sure that that works. Instead of saying from the start, okay, I talked to a new vendor, I give this vendor the vendor requirements and in this vendor requirements document, it's a data governance artifact. You have your lines on how should a vendor connect this data? And then the vendor, in the ideal situation, he knows, okay, I need to provide the data in this format, in this shape. in this specific uh JSON that matches into the UNS, they build the new SCADA. They make the connection because they know how it is in the documentation and it automatically appears in the reports and everybody's happy and it saves one more project. And this is something that we see quite a lot where we work on these projects and then we bring in a plan that is already existing and then they have to say, yeah, we have some of this information, but it's in an export. We get some of this data, but We have to call the vendor every time that we want to see one extra value. And then they have to start a new project with that vendor just to click the OPC UA box. And it costs them a lot of things and a lot of licensing. Whereas in the start, if they had already made sure that they were using an open protocol and the right structure, they would have saved a lot of time and money. Speaker 2 (22:42) ah Could I say from the story and also from experience is that data management per se is not really a problem that individual plants have on their mind because it's not really a problem they have. Like David said, like I need to expand, have safety to look at, I have people problems that we need to manage. mean, these are their real problems. It's usually going to be something more either from a corporate function, be it like a central engineering, central IT. And once you start scaling up that these groups start to... to face the problems that come with not having uniformly managed data across different sites. So having a discussion with an individual site, plans, operator, it's not their daily reality. And I don't think it's going to be in the short term. You'll be often talking to those, know, global engineering or global data science groups. Speaker 1 (23:45) It is definitely an issue that is coupled with vision and with seeing things for sure. For sure. I would say that a plant on its own does not per se directly see the need on one hand, but they also don't see the benefits on the other hand. If you get this structure correctly, this means that running a uh energy management program or an OEE program, it's just a matter of saying my vendor kept to the structure. So my structure matches. So I apply the use case without having to say we start a new project and we call all the vendors and we see if there are any system or integrators that can build this system for us and connect it. You just say, okay, my model matches. know that the company does OEE in another location. Their model matches my model. I download it. I apply it. It works. Which yeah, Speaker 3 (24:41) no, yeah, but that's the, that's the typical scaling problem you'll, you'll, you'll find like it's, it's, it's for so many, for so many, for so many people, it's, it's much easier to introduce another custom scripts uh to do another quick fix. ah You know, term we call technical depth. So, you know, every time like, Let's just quickly do that and we'll solve it later. uh If you take the other direction and you go like, yes, but we're going to work standards based, we're going to normalize stuff, we're going to make it easy, accessible, et cetera, et cetera. If you do that right, the benefits or the future benefits are course gigantic. Not to mention the... I would say the potential benefits you are unlocking which you are currently unaware of. I think that's also a really big thing. Speaker 2 (25:36) But those are invisible. think this is touching about the reason probably why you're also doing this. Of course, there's the rules and governance and security. It's also about scalability because there's this big expectation, everything that has to do with technology. Why can we not simply roll it out? I mean, if I have one program, just copy paste it everywhere. If you have, of course, that mindset, like it's not my problem. And in a sense, it isn't for a plant. ah I just want to do my thing and you have no structural rules about it. You'll find out you cannot copy paste because you'll have different definitions. You'll have different naming conventions. You'll have different protocols, different ideas, even of data. And even a small project will suddenly become a super complex behemoth and you'll end up lagging. I mean, if implementing as... Speaker 1 (26:28) wrong choices and increasing your technical debt. Like David said, there's a lot of things that you can do. There's a lot of choices that you have to make within this process. And they are not per se the right or wrong choices, but they'd really depend on the argumentation that you have behind it. But making the wrong choice early on can lead you in a road that you are missing different artifacts, different items that you need to operate functionally. which is your technical debt that you then later on have to fix. So minimizing this technical debt, I don't believe that you can have no technical debt, but minimizing this is part of the exercise. Speaker 2 (27:04) I think if you would give like a physical equivalent, it'd be like saying like I have no standard sizes of piping for example. Each plant has its own custom diameters and materials and every new flange, every new valve that I buy is going to have to be custom made because our diameter is unique for our plants. Without standards, any modification would be a cost of fortune. Well, now you can go on a standard, you go there, you buy to install it and you know it fulfills certain rules. Does it? Speaker 1 (27:38) you don't have one standard, but you have three different sizes, can at least, least you can enable the scalability. can say, I've documented all the types of standards there are, there are three. And if you want to expand from factory A to factory B, then the first thing you have to check is, the piping the same? Is the standard the same? If yes, then we can easily apply this. If no, then we have to modify. Speaker 2 (27:58) I don't know any engineer that's going to say, my God, I need to have for my plant, need to have custom diameter sized piping everywhere up to the micrometer because that's the most optimal thing. Speaker 3 (28:14) Hey, but I have a totally different, well, not totally different, but I have another question, um which I don't know whether there is gonna be an easy answer. Where does data governance live in the sense that, like we've been talking now about the fact that we need to write stuff down. We need to have, well, Let's take the UNS as an example. So that means that you have a certain structure in your, whatever platform broker you are applying. But like, where does the information live? Where does a single sort of truth live? Where does the master data model live? How do you keep that information up to date? Yeah. Speaker 1 (29:03) And this is where this organization comes in. You need to have a defined ownership role of someone that is responsible for keeping that information up to date on one side on keeping, making sure that this is in place. And this is usually by delegating the responsibility and saying, Hey, I need the recipe information from you. Make sure that is correct. If it's not correct, I call you, but it's, it's more than just that. Of course you need the system for it to live in. I mean, in practice, it needs to live in a system. needs to live in your broker landscape. needs to live in your way where you standardize and balance that model needs to live in your data lakes. And it needs to be maintained by people. And then the third one is the artifacts, the documentation, the rules that you really write. They have to live in a good structure. And this is something David and where we've spoken about before, where we've had a lot of discussions because there, there's not really a set platform for this type of documentation management. But I see that in a Jira and an Atlassian or sometimes even in a SharePoint, if you build a good structure where all your rules and your responsibilities are defined, not one without the other, you need the rules and the responsibilities and they need to be a formalized structure where you say, okay, these are the rules, these are the people responsible for the rules, that you have that in a good and intuitive structure. So they're trying to match the intuitivity of the UNS is definitely something that we try to do. We tried to say, I want to be able to go into this document repository or whatever I'm using. And I need to be able to see in one glance, ah, I need to look there for these rules, for these responsibilities. I want to see the model. Okay, I look into the data architecture data model. Speaker 3 (30:45) No. Which also brings us to the start small or start big type of question. um think Willem, we have a joint experience from the past where we were going to implement a data management practice for a couple of hundred thousand different data points. And I remember the discussions we had like... was like, where do you even start? So um it's this also again, this balance, very small, but risking to miss the bigger picture or bigger, but risking to be working for years on data governance. Yeah. I am definitely a supporter. Speaker 1 (31:38) Yeah. I'm definitely a supporter of the start small team. But at the same time, don't start too small. So the example that I am very involved in right now uh is a program where they have a set of use cases that are only being used in South America. And there, those use cases, in our opinion, they are globally applicable. So there's a regional manager that looks at these use cases and he wants to compare the OEE or different factories and he already has a report and it's not really filling the standards. It's not really following the right rules and building that out to a location where it does work is one of the use cases. Taking into account this data governance and applying it to an already existing situation, you already have your sponsor because the guy that is using it, he wants to use it. And if he can follow the rules and use it, he's going to win. And then if he wins and his solution also gets spread over the world because it's following the rules, then he wins double. So this already creates a sort of internal sponsor that you need to run this program forward and help in the culture that you need. Speaker 3 (32:46) Well, uh must say, I'm also uh part of team small, don't get me wrong. uh There is one sentence I um think I heard that, I don't know who said it to me, but in any case, the sentence is uh in start small, think big, think big is not optional. Like you need to know where you're heading towards. But you also want to make sure that you allow for rework. And I think that's also something typical in operational setup. uh Obviously, uh engineers, we wanna build, yes, I get it. If we take the piping example again, you wanna uh draw, you wanna design, you wanna make sure that you build the right pipe, who exactly fits where it should fit, right? Full stop. But in these types of projects you need to allow for rework. I think you need to learn from learning. Speaker 1 (33:54) Yeah. And you have different phases in these kinds of projects. You have the phase where you start up the governance, where you say, okay, this is my base layer of rules and documentation that we have. You have your design of your solution. And then when you have that finished, you have your starting base of your living documents. And I call them living documents because even though they are the base that you operate out of, they will still change over time. But when you have them, I think a large chunk of the work is done. And then when you have an operational team that follows up on the implementations and the executions and the support, then that team can take care of growing the documents that you already have. So this, this governance and design is really planting the seeds that you need in order to have your right documentation. And then in your operation and in your implementation, you grow those out to a fully grown network and of the organization that you need to cover those bases. Speaker 2 (34:55) Okay, now uh we're gonna have to close here. So maybe one final question is how do you get people on board on this topic? How do you not scare them away? know, you're the data police coming with more rules. Speaker 1 (35:14) I think that 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, oh, instead of doing half a year or a year long project, I can just download it and it works. That's really good. And if we have that on the horizon, then people are on one hand more likely to see why they want to do it, but they also get more excited about getting closer to that goal. Speaker 3 (35:42) Getting people on board thing is extremely important. Being transparent on what you're doing. um ITOT cooperation is here also really, really uh important. um We didn't really touch this point and there's maybe something for another episode, not um the us versus um them. um Was that together with you, Willem? I don't remember that anymore, but I've been in meetings. where there was really somebody from IT who was tasked to start building something in a cloud system. IT was fully managing and there was a data governance uh person being assigned going to a plant asking data governance questions to the plant manager. And the plant manager just went in full defensive modes and went like, yeah. Speaker 2 (36:39) I think that happens everywhere, David, that has happened everywhere. So I'm pretty sure it happened with us, but it's happening all the time. Speaker 1 (36:47) It's no longer just technical. There's also a large part of, and we didn't touch much of that this time, but there's also a large part of culture and large part of people business and some politics that is involved in this side of the technical scope. You have to have these technical classes, but at the same time, you have to meet with people. You have to convince them. You have to present the right thing and use the right words. Speaker 3 (37:11) Yeah, yeah, no, for sure. 100%. um And yes, so other things we can discuss in future episodes. So I'm sure that's gonna happen or at least when we just our paths cross again, they often do. um So that's another uh wrap of this episode of the IT/OT Insider Podcast. Wybren, thank you very much for sharing your insights. Thank you for having me. And to our listeners of course, again thank you for tuning in, if you enjoyed the conversation make sure to subscribe at itotinsider.com and also discover our trainings at itot.academy. See you next time when we bring you more insights in bridging IT and OT and until then, take care, bye bye!