Nail It, Then Scale It: What Ontology Actually Means on a Factory Floor

Bob (00:00) The engineering manager said we had a hydraulic failure in our plant. It took them two weeks to find. We used a large language model to say, can you explain why this hydraulic system is playing up? After about three minutes of analysis, Claude said to us, it is this proportional valve. We were able to take all the individual relationships from PLC data and we passed all of those little relationships of Latalogic instructions and put it into the knowledge graph. Clients buy painkillers, not multivitamins. You need to find the pain and you need to start building your knowledge there. Willem (00:50) To the ITOT Insider podcast. David, this time I think we went above and beyond. We really want to have a global reach. So we reached all the way to New Zealand to find Bob, right? Bob (01:05) Yeah. David (01:06) Yes, yes, yes. We can we can reach. super interesting podcast ahead. first of all, Bob, thanks for joining us. Bob (01:19) To be here. David (01:21) we'll be talking about graphs, ontology, knowledge, that type of thing. Talking about knowledge, first a small plug, our ITOT Academy, our next one starts September 18th. registrations are open. We'd love to see you there. Take a look to the website ito.academy. Our program is renewed. it's even more exciting than it already was. so we're looking forward to kicking off a new cohort really, really soon. but said that, and I'm not gonna make any more promotion. Bob, welcome all the way from New Zealand, talking about ontologies, graphs and all the fun stuff. but first of all, quick introduction from yourself. Bob (02:03) Okay. Well, Willem, David, thank you for having me. First of all, it's really good to be part of this. I've I've watched from afar and I reached out to you because I'm really impressed by the stuff that you're doing. I got a little preview from your book and that's equally been very relevant for the things that are about to unfold. And and so yeah, so very very pleased to be here. I am originally Dutch, immigrated all the way to New Zealand. I am the CEO and co-founder of a company called Thred. we have a product called ThredCloud, which is a very fast to deploy knowledge graph that is yeah, being adopted by clients in the US and Europe and Australia and New Zealand. David (02:59) So in theory, Willem, we could record this podcast in D Although it's not gonna help us with the reach, I see. Willem (03:07) huh. David (03:13) No no anyways, so we started talking, Bob, about a topic which is getting more and more traction right now. I think talking about ontologies has been away has been around for a very long time, but all of a sudden it's now on everybody's plate. so I think let's work a little bit backwards. Like first of all, why are we talking about graphs and ontologies right now? maybe more from a higher level and then let's start talking about what it means to build such a yeah such a thing. Bob (03:49) Yeah, brilliant. that's that's a good background. So even referring to your book, you've given a great history and timeline as to how we got here. We my background for the last twenty five years was consulting, continuous improvement consulting. You know, I've done a lot of good work in Belgium actually, which we talked about earlier. The challenge for me was always I'm trying to get improvement in a business. I'm trying to fix a business up. I see a lot of behavioral dysfunctional things going on. I'm I'm seeing plant breaking down. I'm seeing you know performance is not very visible. because performance is not in visible, the the organization becomes ambiguous and political and reactive and and and all those types of things. Got nothing to do with data. But The modus operandi was I would go into an organization and say, I can fix this, but we have to start measuring your business better. And once we start measuring the business better, we start to develop a common language and meaning around how we solve problems. And that was always very, very difficult, especially when it came to OT data. I was naive when I first started. I thought data was data. and you just, you know, go to a SQL server and you know, grab some data and visualize it and and and you're good to go. But the real good stuff was always in the OT data. And I had to go and talk to different people, usually people with overalls on that weren't were more interested in automating plant than data. And they would give me this raw data. Either out of a historian or some CSV file, and I would have to sort of muck around for hours on end to come up with some insight. and we formed Thred for the very reason that everyone was talking about industry four and this OTIT convergence, and that was very exciting for us. But the problems that had been solved up to that point was, well. Connecting to data is a lot cheaper now, right? And and and those problems were solved. Moving that data, storing that data in time series, all those technical problems were solved. But the big problem back in 2020 was we still don't have rich enough context in that OT data for it to actually be meaningful and to actually drive thinking and improvement. But then when we looked at why that context was missing, well, you go into factories, you've got all sorts of different data sets, you've got data silos, you've got OEM equipment, you've got, you know, PLC logic that, you know, Harry did when before he retired. And so it's it's all a mess. And at best, you will get context that's hierarchical. In other words, this tag sits in this folder that belongs to that asset, belongs to that bigger asset in that department. That's about as good as it is, which is kind of like me trying to understand who David is by understanding what his dad is, right? Because it's parent child. And so we needed something completely different to actually enrich context. And we came across the whole idea of knowledge graphs. And knowledge graphs allowed us to kind of transcend the hierarchical modeling of data into something much richer. The scaffolding allowed you to essentially connect nodes and edges together. And those edges would be relationships. And that's really what spurred our thinking around okay, we can we can build all sorts of context around our data, but actually we need a theory of knowledge and we need to understand how to apply that. and that's really the background as to where we came from. Willem (08:05) That's really going back to the foundational idea of what's behind ontologies, I'd say. we like to keep things practical, and it's nice in theory to build graph models of knowledge, but what kind of application would it have in in a day-to-day? where does it really start to shine compared to just like a hierarchical structure that many people have? Bob (08:39) Yeah, sure. Well, when we look at relationships, right, of data, we say essentially what we're saying, this bit of data is meaningful in these ways. And the relationships are essentially the ways those data can be made useful. And to to explain that practically, say you and this is this is I've used this in an earlier podcast, but it's still such a great success story. What we did is we connected data from a factory. That data was sitting there just in raw tags. What we did was we were able to take all the individual relationships from PLC data, right? So we take ladder logic and we passed all of those little relationships of ladder logic instructions and put it into the knowledge graph. We then did the same with P and ID relationships and we started to use Engineering artifacts to draw these relationships. And essentially what you're doing there is to say this data is relevant as far as it pertains to the PLC code this way, or as far as it relates to PN IDs. Underneath it, you've got your time series data collecting. And once we had both the relationships and the time series data, we could feed it up into MCP and Claude. And we were able to all of a sudden do very powerful root cause analysis. And the story that have I've raised before was, and this was, you know, about six months ago when we were just before we were releasing our tool, the engineering manager said we had a hydraulic failure in our plant. And I'm sure you guys have had plenty of problem experience with hydraulic stuff. It's a pain in the backside. it took them two weeks to find that. that root cause. And the way they found it was eliminating things, right? The process of elimination, well, it can't be this, trial and error, go and do this, run the press again, et cetera, et cetera. We used a large language model to say, can you explain why this hydraulic system is playing up? And the LLM was able to then fetch both the relationships that we'd drawn with the time series data to rule out what was possible and what wasn't. After about three minutes of analysis, Claude said to us, it is this proportional valve. The failure mode is contamination as most probable, or it's leaking, or it's completely failing. But the the time series data suggested it was proportional valve. I waited th what, twenty seconds and asked the engineering manager, was it that? And he said, yes, it was that. How did you do that? And it was because the relationships allowed us to find the needle in the haystack. The relationship explain how the data explains your factory and how it's put together. David (11:48) But you need to get to those relationships. So and and that's for me always a little bit Well there are two sides of this co of of the coin here, right? So there is there is a a part of the world who says like we're gonna model. And and then there is a part of the world who says we're gonna discover on which side are your or is is it a bit of both? Bob (12:13) It's a bit of both. I mean, for starters, right, you you have you have knowledge imparted in in in all sorts of places. There is relevant relationships in your PLC code, in your PN IDs, in your engineering documents, but you're exactly right. There's another portion of knowledge that emerges through discovery. Things you don't know until you start thinking. There are defects that come up in a factory that are really, really hard to figure out what's going on. There is no documentation. There might not even be tribal knowledge about why that happens. It is a process of scientific discovery where you're starting to form hypothesis. Those hypotheses need to be supported by certain relationships in the knowledge graph. And then you find evidence and you turn. that emergent exploratory knowledge into known knowledge. In other words, we discover ontology. David (13:19) In our book, we r also write about the the challenge of there is this the w what what operations, what manufacturing is really good at, as you know, Bob, is executing projects. And we are very used to having a a a Capex-driven, you know, Gen chart of you know what we're gonna do? So we have this problem we're gonna solve, so we're gonna We're gonna map out a mega project for the coming months, I know, or the coming years. I I know Will Will and has also some some stories to share there. and then you know when we've executed the project, we'll have the perfect graph. Like does that work or doesn't that work? Bob (14:05) no, it doesn't work. And what we're finding is that people have gone down that it was a good setup there, David, but you knew the answer that was coming. so what we what happens is you you you start to be build these massive what we call boil the ocean projects. Mm-hmm. If we just build the perfect knowledge graph, if we build the perfect data model, but we have to wait for three years before we get any value. That's not how it works. Our view very strongly is you start at your biggest pain points. And I always say clients buy painkillers, not not multivitamins. And so you need to have you need to find the pain and you need to start building your knowledge there. I'm very skeptical of people that say you can be very prescriptive about ontology. Whether it's following ISI ninety five standards. I'm not dismissing nine ISI ninety five standards, incredibly useful, but don't limit your knowledge to just that. David (15:13) I said there are two sides of the coin and and I think it's it's it's it's interesting it's interesting to talk about to talk about different perspectives. on the other hand, Willem it's also something we've talked about so many times. The problem is just defining w what is knowledge, what like what do we even wanna reach, yeah? Bob (15:33) Absolutely. And I think that's what happens with you know, when I read your book about OT IT and and you kick off a project and you look at how you're gonna work together and you have your seven patterns that you you put together there. The the why of why you're doing this is never clearly defined. And because of that, IT have a very different idea or OT have a very different idea because it's very abstract and we don't really pin down The why. When you don't figure out the why, you start to focus on who's right rather than what's right. And so when you figure out the why, it is when you start small and you say, I have a pain point, this business is losing money because of this area. Don't try and do everything else. We start there, but we are absolutely focused on nailing that problem. And we're going to get all the the knowledge, discovered knowledge, testing it, don't complicate it, don't make it expensive. And then once you do quantify the improvements, then you can scale and you can get out of that pilot purgatory that you also have led to. The reason why you get pilot purgatory is because people go, why don't we give it a go? Why don't we just take the tech for a spin? That's BS. You haven't done the work up front to really figure out what you're trying to do. And once you've done that, and that's why we believe so strongly you start small. You don't know what you don't know until you start discovering. And if you try and be too prescriptive, too prog programmatic, then you're gonna get into very hot water. Willem (17:16) It sounds yeah. I think it's a story that a lot of s hear, but it's keeps on being a difficult one to sell. trying to sell the unknown, having to do the annoying work up front of why you're exactly going to do something compared to just getting a shiny new toy. I think it's not gonna disappear anytime soon. David (17:39) No, but but but what what like I'm you know this is a podcast so but but I'm I'm showing here our our our graph our scaling graph on on pilot purgatory and it's also it's also on our blog but I think this is the graph when when when I'm in workshops with people with companies all over the world this is the one graph I always draw on the whiteboard. Mm-hmm like because I want them to ex I want them to understand those basics. It's it's but but you're right Willem, like obviously. You still have a couple of people in the room going like Bob (18:11) Yeah. David (18:13) butts. Willem (18:14) I think it's human nature to want easy solutions and technology often sells as the easy solution to their more complex problems. Bob (18:23) Yeah. And I think I think it's also just even expenditure approval processes and things like that. you know, we often go, Well, we want to cap hex this. And you go, Okay. I don't know if you're ready to capex it, but well, you know, tell me more. And then they say, Well, you're gonna have to give us a return of investment. And we say, Well, we don't know yet because we have to measure things to understand the performance gap. And that's what you believe, you know, you measure. Meta is Veta, as we say in Dutch and in Flemish. but some people just wanna jump that hurdle. And the reason is is because their internal processes mean they have to fill out a document that has a an area where you have to put a business case and SAP approvals won't allow you to move it through the workflows. It's th it's ridiculous things like that. And so then salespeople are forced to put in, I'll give you twenty percent improvement. And we all know we're lying. And we never measure the delivery of those projects at the end, because most of these organizations like us, after you've done the project, do you measure the return of investment? And they say, No, we're on to our next one. And and really, if you do go down that road, you bacon the skepticism, the disbelief. And and and the sources for OT IT fighting, the old coat of arms, it was his fault why the the project didn't work. You ha and and I'm very strongly so the best way to do this is to start small. But don't but starting small doesn't mean increasing the risk of going into pilot purgatory. You you David (20:12) Have a philosophy type of background as well. We always talk about let's we're gonna build systems to help us do our job better, but shouldn't it be the other way around? Should it be first ask ourselves like, but how do we as humans want to learn? How can we learn? Is there some link to be discovered? Bob (20:35) Well, I think that when you look at how knowledge forms in an organization, it's not through data scientists sitting in a room building a data model. That's not how it works. Knowledge is created everywhere. It's it's kept in in tribal in tribes, right? It's it's it's sometimes not codified. It's sometimes sitting there as tacit knowledge. It's it's understood through heuristics and herbeneutics and things like that. And so for us the challenge and and one of my bugbears is that when we sell software, we go, Well, who does the data modeling? Who does the context? we've got a group of data scientists over there that do that. They're gonna tell you the world that you think, you know, that is yours. And and it doesn't work that way. What we really actually want to do is we want to democratize the process of a context building. So we want to make these tools available to everyone in the organization when they start to think and explore about how knowledge can be useful from a fitter and an electrician trying to figure out what's going on to their plant to meeting in a daily production meeting where we're trying to do root cause analysis. Knowledge can come from anywhere if we just democratize those tools. We talked a lot in the in the last five years about democratizing data. That's not what it's about. It's democratizing context to say, I want to frame something. I don't know what I yet know. I've got a hunch, but let me frame it. Let me validate it. Let me get evidence. yes. Okay. This is where my thinking is going. That's how great knowledge emerges. And we need to build tools to do that. And so all the talk about ontology is usually done by data scientists and data engineers. And that's that's what frustrates me. ontology is discovered through the process of doing, right? Every day when you're coming into a manufacturing business, you encounter all sorts of problems. And we have all these great learning opportunities. to create knowledge that we can then bank back into the knowledge graph as this repository, a flow wheel of of knowledge. and I think that's gonna be the real challenge. Can we build tools that everyone can use to think and and and inform knowledge, if that makes sense. Willem (23:12) Sense, but it still feels how should I say? It sounds very abstract to me. Getting the data or knowledge from a daily stand-up or root cause analysis, how do we need to see that? How would it work? because there's so many dimensions. Like, what is that knowledge that you want to capture? What are the relations you're looking for? Bob (23:34) Absolutely. And so a knowledge graph should have layers of relationships that are derived from many different things, from engineering documents, from different roles in an organization to different issues, like a you know, a a parti particular hypothesis you're trying to test. And so again, I wasn't here to talk about my about Thred's product, but it's about representing relationships and where they come from, where are they derived from. And so for instance, we use Claude, we use an LLM both in a in a group setting, but also individually, where you begin. I've done this many times. In fact, two weeks ago I signed up a customer. They told me a very clear business problem. we got into a room with a group of people. We drew it up on the whiteboard, the whole model of this big sawmill. we'd already collected all the data. We went into Claude and said, Here's what we're trying to do. Claude said, okay. Yeah, yeah, yeah. I can see the data. I can see the time series data, but you need these relationships to understand that this is related to this in order to do this, in order to do that. Would you like me to draw those relationships in your knowledge graph? And we said, Yeah, sure. And that Claude drew the relationships. And then we went, okay, now tell us, is there something there? Yes, there was something there. And then we went, Wow, okay. We kind of understand how cause and effect now happen in an organization that we didn't really realize before. David (25:16) Might now be asking a stupid question, so please correct me if I do. but like somehow that that that brings me back to the years where everybody was creating Excel sheets and copies of data, and you know, but I have I have a slightly different opinion on that. So let me just copy that Excel and make that into my version. We've all seen it. Yes. and then all of a sudden, and and I I I can still remember also an engineering project where you know you had the piping engineers and you had And you had the the the whatever the the scaffolding engineers and you had the whatever and all of them had but I do it like this and I have those documents. So if I in my own small little world try to to to transpose what I've seen over there to what we've doing right now, the like the most important question which comes to my mind is if we just start firing away tools to identify relationships? Aren't we getting to a point where we're also just inventing stuff or fitting noise basically, right? Where it it's just again a whole bunch of relationships. It's difficult for me to understand that. Where where will this end up and and is there a is there a limit or or how should we govern that or Bob (26:36) Yes. Indeed, they g this gets to the heart of the debate, which is some people say, well, you can't just draw relationships between your data willy-nilly. Then you can just that's just a a recipe for creating chaos and and nonsense and contradictions and so forth. And that's why we must follow IC ninety five standards. Right? Because we have to control the truth. You know? I have a different view. I think like we've built this whole a methodology called veracity testing, right? Which ensures that you create a knowledge graph that still can cohere and doesn't create nonsense. But we give the freedom of people to explore relationships, test them, validate them and say, are these relationships useful? Are they are they f allowing us to find insights that we couldn't do before? And anyone that's been in operations, by the way, has found that if you've got a production problem, it's never just a maintenance problem. It'll be a maintenance problem, it'll be an operator problem, it'll be a an a lack of management problem, it'll be a poorly designed alarm system problem. And so the impulse in sort of very linear root cause analysis is to go and find very simplistic root causes when in actual fact that's not how organizations really work. And I've got a classic example of that. the other day with one of my clients, I went into Claude and I said, I'm really interested in upset production conditions because I know from a health and safety point of view, upset production conditions lead to health and safety. In fact, if you look at the statistics, as soon as you get an upset production condition, you're gonna your chances of how having a healthy safety. And I said to Claude, look, just find me all the all the light curtain breaches, all the e stops that were pushed, all the interlocks that were breached. Just tell me the story. and then start telling me another story about other relationships that were going on. What was maintenance doing at the time? what were operators doing? What was the production stats doing? And we actually found that a lot of parts of that factory were the health and safety systems weren't doing the job they were meant to do. Right? And why? Because the bloody production thing wasn't fixed. Someone had created a work order, you know, five weeks ago and they didn't do it. And the operator keeps breaching the light curtains to reach in and and manually turn the, you know. And well, the health and safety people say, yep, where we've got tick, we've got all the light currents, got all the health and safety practices. the operator is barely surviving and every hundredth time he might get a limb cut off. Right. And these are the types of things, you know, problems are multidimensional and we need to understand how they really operate in in the world of operations. David (29:54) There is one more topic I'd like to discuss, and that is not the entire part two of the book that you already mentioned it, cooperation. I didn't count the number of times you mentioned Claude, Bob. But that's like in an organizational point of view, that's an IT tool. At least it's governed by IT, right? We know how much our world is still living in silos. the patterns you you mentioned are our race or our attempt to bring guidance from really really silo to really really well integrated. What we didn't really touch upon by design, and we also explained why, was let's just imagine that there is no difference between IT and OT anymore. Let's let's let's let's blur align the ways. Like do we need to blur align the ways to make this happen? Or what like what is your opinion on that? Bob (30:54) Well, I mean, we learn a case by case. And I that's why I love that part of your book in terms of framing how people try and organise OT and IT. It's very, very useful. And I have found that some of our clients I think that the model seven or the pattern seven that you put in your book is probably the the best that we have so far. But it really I mean you guys articulated the history of how IT sees the world and OT sees the world. I I couldn't have written it better. So is it you did a great job. And then the fact is one of them goes through the COO and the other one goes through the CIO. And then the CEO has to kind of pick, you know, who's right. I and I think that you know, we're starting to see more and more OT people that are IT literate. And we're seeing IT people more OT literate. so which is really encouraging. Not everywhere. but you know, I've written a bunch of articles recently. One of them was why do we have breaks so that we can go faster? and that was a real challenge to IT. You know, sometimes you have the department of no, no, you can't have fraud, you can't do this. You can't do okay, fine. But I would challenge them. We have brakes so we can go faster. Brakes are important, but we're not there to stop. I just I just think we're moving the right direction, but it really comes down to that organizational leadership. And we've we've had some fantastic examples of business people that say, Look, it's not about OT and IT, it's about a business problem we're trying to solve. And If you guys can't cooperate, then we have a problem. And and once you set that tone, magically cooperation happens. Willem (33:00) I think also it's personally my favorite part in the book is is is that cooperation part. rarely the problems are truly technical. very often it's more about how we work together and and how you can or can make it work or can make it fail. Bob (33:17) Yeah. Success has many fathers and failure is an orphan, as they say. Willem (33:23) Yeah. Bob (33:25) So so yeah, so you know, once you get that and again it goes back to starting small, right? Get small wins, celebrate them together, make sure that everyone gets the QDOS, nail it and scale it is is much more of a approach we take. we we were talking to someone in a very big department, 70 data scientists trying to deploy a a knowledge graph that wasn't threads. But they were at it for four years and they've got no wins. They've they've got no wins on the board. Imagine the kind of questions they're getting from senior people to say, what was this worth? And that's like you said, Willem, that's when the blaming starts to come out. It makes a lot more sense where we said we we did something small, but we saved half a million dollars. And then we did this, and then we we we got our prize of a million dollars. It's not it shouldn't be is OT in charge or is IT in charge. Neither of them should be in charge. Right? Business people should be in charge. David (34:33) You you gave us the title for the podcast, Bob. Nail it, don't scale it. Bob (34:40) Yeah, the king of one liners says Yeah. David (34:45) I love I love one-liner, so that's that's that that's gonna be it. So something like knowledge graphs or whatever, nail it and scale it. perfect. Perfect. What is for me still difficult to really visualize, but I can understand why, is the fact that knowledge is getting discovered. Somehow you wanna make sure that you also have this governance layer in place to not make that explode somewhere, so it's again impossible. impossible to scale or impossible to maintain. and I think in the well no, I'm not I'm not thinking. I'm sure that in the years to come we'll see a lot, a lot of content popping up on on knowledge graphs, on ontology, because that's apparently now the the the next best the next best thing we're all we're all talking about. So with that, Bob, thank you very much for joining us. Very insightful. Yeah. Bob (35:36) Okay. Pleasure meeting you both and let it not be our last discussion. David (35:41) I'm sure it won't. Also for or to our audience, thank you again for for tuning in. make sure to subscribe to our podcast and to our blog because we do these types of conversations on a more or less weekly basis. We talked about our book, which is now available for pre-order. Go to itotbook.com, available early October with some pre-order bonuses. So make sure to let us know if you pre-ordered it. or go to itot.academy to learn more about all the Cool stuff in bringing IT and OT together, The corporation patterns, the the architectures, maybe blurring some lines, who knows? Bob (36:22) let me vouch for the book. It's a it's a good read. David (36:25) Thank you so much. Thank you so much. Willem, thanks for joining us well. Bob also thank you and take take care and until we meet again. Bye. Bye bye. Bob (36:33) Okay, I did.