Transcript of Behind the (podcast) scenes: David and Willem

Willem (00:00) Welcome! You’re listening to the IT/OT Insider Podcast. We’re your hosts, Willem… David (00:07) And I’m David. Willem (00:08) And together we bring you the latest insights shaping the world of industry 4.0 and smart manufacturing. In today’s episodes we’ll go over a presentation we recently gave to an IT public, not an OT public. And it was an introduction about why manufacturing digitalization matters. And we think it could be interesting to share those thoughts to you guys. So David, we started that presentation with an introduction. I think that may be also interesting because I don’t think people know us. Maybe it’s the first time they see me, for example. So let’s start with you. David (00:41) Absolutely. And it’s also the very first time we do this, we do this, this just the two of us podcast. So this definitely makes sense. Well, for those who don’t know me yet. So I started my career in 2010, working for BASF. I graduated as a mathematical engineer. So I at that time, I still knew how to solve a differential equation. today. Please don’t give those anymore to me. Wouldn’t be able to solve them. But I started as a mathematical engineer doing data science projects. I was actually one of their very first people who worked on mathematical problems, which was really cool to do. But I quickly went to more the systems side of things. BASF wanted to invest in cybersecurity quite heavily and this was something which was really interesting to me as well. So I remember 2010, also the year where the first OT virus, Stuxnet, hit the world. Quite a lot of people got nervous, especially in the larger industrial corporations. So I ran their industrial cybersecurity program for EMEA for a couple of years. super cool time, I learned a lot. I will also do a podcast on that topic in one of the future episodes so for those interested make sure to subscribe. After that I really went to the IT/OT side and that formed the rest of my career until today. I always worked I would say from that point on in the intersection where OT operations meets IT. So building data platforms, building data pipelines, working with people on the shop floor, but also people on the business side. And this is a really interesting domain. That’s also where the two of us first met. Now, after that, so two years ago, I switched to the dark side. So from customer, I went to supplier. I’m part of the bigger AVEVA ecosystem right now. AVEVA is one of the… world’s largest industrial digitalization providers. And I’m running now a company called Analytics for Industry and with that company we build data platforms. Over to you Willem. Willem (03:04) Okay, so I’m also an engineer by training, but a chemical engineer. So I’ve always felt close to chemical plants, etc. But let’s say I started before you. I started working in, I mean, like a good Belgian person, I started working first in chocolate, then I worked in beer. But then I returned back to the chemical industry with BASF where I joined in IT actually. And since I was the guy in IT who knew what a plant looked like, I sort of got pushed into everything that had to do with that area of intersection between IT and production. I got also a little bit of a trauma there. It was like the old school way of managing and doing work with lots of handovers, large cap boards. I mean, everything that’s not agile, I’d say we did there. And looking for something else, I went to Antwerp, to one of the biggest sites of BASF, where you were also working. After dabbling a little bit in logistic projects and lab projects, we started to manage this growing area that was gaining a lot of importance also at the time. So that’s now in the past. I’m currently doing the same thing in Solvay. It’s another big multinational chemical company where we’re working on digitalization every day. David (04:37) And the thing which really, I would say, the bound between us, what we really loved to do was talking about organizations, building teams, running products. And I still remember when we both left BASF, we needed to find a reason to keep on meeting each other. It’s actually just a good reason to go to a restaurant or drink a coffee or so. But so we just kept on talking. why are we doing the things we are doing and how should we organize this and how can we actually make digitalization really a topic within manufacturing? That’s also the reason why we started writing the IT/OT Insider. So just very, very good excuse to keep meeting each other. But, and now we come back to the presentation. So Willem (05:21) To keep meeting each other, yeah. David (05:27) one of the publishing companies which really influenced the way we think is IT revolution with books like the Phoenix Project, the Unicorn Project, Team Topologies and so on. These books are written from an IT perspective, but we always try to apply these concepts to the OT world. And… They organized a conference just recently, we applied and we were very happy to be talking there. But Willem, this was also, at least for me, the very first time I needed to talk to an IT-centric audience. Willem (06:06) Yes, it was also like a shift in our thinking. Like we suddenly had to talk to people who, you know, they come from other industries. I mean, banking or logistics or something like that. Normally you don’t see a lot of people from manufacturing in those kinds of conferences. So we needed to adjust our languages and try to bring the message from another way. But in the end, I think we managed it. I think… the entry point was like, why should you care about manufacturing? Because it’s like this, isn’t this something that’s already solved? Isn’t it done? I mean, we’re talking about companies, hundreds of years old, factories, decades, they’ve been there for decades. So why should you care? Well, that was like one of the questions, David. David (06:58) So I think the first observation is that we somehow are in like this perpetual pilot mode. People are suffering from pilotitis, if that’s a medical condition which might exist. Willem (07:13) I think it should be a medical condition. No, but I think maybe even before that, I think we made the observation that even though there’s like a lot of efforts, a lot of money, a lot of people, a lot of attention is going towards this domain of how can we bring this digitalization to the shop floor, where to be honest, not seeing that much of an effect compared to the effort that’s being put in. And… It’s not only something that we’re saying, I mean, we’re hearing it everywhere. It’s individual companies, colleagues, big consultancy companies. I mean, everybody’s sort of admitting like ever since they launched the term 4.0, we’ve been trying hard, but it feels like we’re still stuck in industry 2.0. What’s stopping us? I mean, if there’s one domain that’s moving faster than light, then it’s IT. I mean… Yesterday blockchain was the word of the year, this year it’s AI. I have no clue what’s going to come next. But if you go into a plant, you’ll still find a guy who is reading a meter, writing something in his notebook, going to the room next door, typing this in, and if you ask him why, he has no clue why it’s happening. So the first step was acknowledging this gap, like what’s stopping us? And we saw like two big observations. The first one is we have problems scaling. So you have this tendency to have a lot of pilots. Like you get an initial project, an initial idea, and in the beginning everything works fine. But once you start rolling out, the problems start. I mean, you’ve done several of those projects. You go to a site and you see that they use a different software. or a different data source. Okay, you can adapt your platform or your solution to that. You go to the next one and I’m not kidding here. I’ve seen companies that were running on a collection of connected Excel macros and there was like some AS400 print server that was sitting under somebody’s desk that was also involved in the architecture. We had no clue what it was doing there, but it wasn’t working, nothing worked. So. It’s a bit harder to connect to those kinds of environments. And then there’s those where you get a competitive advantage if you keep them air gapped, because security was clearly not a topic the moment the network was built. All those things, they hinder you. David (09:50) I still. Yeah, I still remember a project where we were introducing a data platform. And one of the tasks of the team was to go to different plan by plant, user by user, and figure out whatever they needed from that data platform. And typically what we had to do is we had to look to their excels and then rebuild them or hopefully migrate them to, I would say, one of the products we’ve been introducing. And I remember one of the quotes going like, an Excel here and I have to push this button every morning and the Excel does stuff. I don’t know what it does but my colleague who already left the company told me that every morning my job is to push that button. Willem (10:39) And that was not the only story, I’m sure. I mean, you see that everywhere. So yeah, those situations that you really find, the problem is also they’re different from plant to plant. And what happens is like the initial speed and velocity that you seem to have during the initial deployment, very often the expectation is, hey, it’s IT, of course it’s scalable, like click, click next, next deploy install should be ready. No? David (10:44) Yeah. Willem (11:08) And that’s not the case. It slows down, enthusiasm wanes, costs go up. And by the time you’re like a third away in your deployment, something else shiny pops up, gets the attention and gets the resources because that’s of course much better than the solution that didn’t work out. And if it happens once, that’s okay. But you usually see places where it’s some sort of perpetual cycle of pilots that didn’t manage to scale. I think that was like one observation we had. I see it more as a technical problem. David (11:42) Yeah, absolutely. And then a second observation and then we come back to the organizational, cultural part is that although we’ve been talking about IT/OT convergence for I don’t know how many years but probably as many years as industry 4.0 has been invented. What I see happening is that I see actually more divergence happening than actual convergence. So I see that the shop floor OT tend to grow apart from IT at a higher speed than before. And if we just, and this is also an article we’ve written a couple of months ago and I’ll share that in the show notes. But what we see is that IT and OT, they are, yeah, still. silos. IT reports typically to the CIO, OT typically reports to COO in most cases. So that means that the common reporting points of both of those silos actually at the CEO level, which means that if something needs to be escalated, it’s the CEO who is responsible. Now I think most people in larger organizations don’t want to bother the CEO with every small integration problem we are suffering. not so much escalation is actually happening. And what we see is that between those silos, you see that there is no trust or limited trust. It’s always us versus them. We see a problem with, yeah, there are no shared goals. That makes sense because you have the CIO and the COO and yeah, obviously they have their own targets, but also not really shared ways of working and really limited shared technology. And that’s… That’s very much of a problem because that means that although people will say that they can probably do a better job, bridging those two worlds isn’t that easy. And what we see happening is that if you do not form some kind of a team structure which is able to break those silos, that one side will typically claim. And IT is probably the side who claims fastest, I guess. just because of the fact that they are sitting on the new technology, as you already mentioned, and they are sitting on these new ways of working. And also data problems nowadays are typically owned by CIO, CDO, so in the data area, right? Willem (14:17) I think, and it’s super logical in a sense, if you tell IT guys, from IT’s perspective, how hard can it be to create just another dashboard? It’s just another data source. I mean, we do the finance departments, we do whatever department there is. We collect the data, we have a data lake or data pool houses. I don’t know what they have. And… If we can manage 24-7 global applications that are like super critical, for sure we can manage this one dashboard. But on the OT side, you’ll also see this like, guys, we know our business, we know… we can manage like huge plants they cost hundreds of millions, they run 24-7. I mean, you’re not going to tell me that it’s super hard to create some dashboard left and right or to do some data analytics. I mean, we have tons of smart people in engineering. And you see that if you start with those kinds of mindsets that are not really acknowledging the expertise or knowledge of the other side, those initiatives, they tend to fail. They might never be called a failure for political reasons, but they will never become a success at least. And especially the thing is also like you mentioned the CIO, COO discrepancy. It’s also harder to get C level people to work together than people within the same department, for example. So there’s a lot of distance there that you start with and it’s hard to bridge that. David (15:31) Yeah. Absolutely, and they also have so many so many things on their plate. So you don’t you don’t want to be that one guy who always goes like, yeah, but how hard can it be? So we do see a big risk of creating an IT/OT divergence, but there is hope. Willem (15:58) Yeah, just work together. Make it happen. There is hope. David (16:14) There is hope. So we’d love to talk about our three-step plan. Willem (16:22) Well, it was a presentation of 20 minutes. You know, you want to give your audience something a bit concrete, something a bit, you know, you cannot go too deep in 20 minutes. So we said, you know, what about we give like a three-step plan telling you how do you start to bridge that gap if you start from a bad place? And just to be clear, I mean, there’s enough places where they’re closing that bridge. I think the more mature an enterprise company is in how they manage a shop floor. problems with digital solutions, the more you see that, I wouldn’t say convergence of IT and OT because I still don’t know what that means. Does it mean that PLCs will be something you do in Amazon? I don’t know, but you will see that cooperation and that clear delineation of roles and expertise happening. So that’s definitely there. Anyway, the three-step recipe, David, tell me, what do I need to put in my kitchen to get manufacturing digitalization up and running? David (17:22) All good presentations have a three-step plan. That’s so… So step one is start with cooperation, really important. Step two is then once we cooperate, let’s, I would say we go from understanding to actually working together. And then step three, we’re gonna introduce ways of working. Willem (17:26) So. David (17:46) Agile ways of working, for example. So those are the three steps. Let’s focus on the first step first. So cooperate first. Willem (17:54) Yeah, the assumption here is like there’s usually like some distance, some mistrust. And starting on this huge project or setting crazy ambitious targets from the beginning might backfire, especially if there are already like some bad experiences in the past. So our first recommendation is like guys, if you can, start small and start building trust. I think it’s important that within your organization, you start to cultivate the people, the relationships that you will need later on. So we have a couple of patterns there where you could say like, I create like, I would say liaisons, I don’t know the English word for liaison. Anyway, you create like translators from one side to the other. So you start small, you will have the translator. negotiating between the two worlds of IT and OT. And from there you start to build up the common language, the relationships and the understanding of each other’s problems. I think that’s like step one. And depending on how deep the, let’s say the mistrust is, the longer it takes, of course, but it could also be quite fast, like maybe a couple of months, six months could maybe even be enough. David (19:14) Yeah, so and here again I’d like again to reference the blog for the people who like to have the full article here. Now at this point in time, we have started to build some trust. It’s also really important that these translators translate the lingo from one side to the other. Then we go to the second step. The second step is that we really go from understanding to working together. Willem (19:47) Yep. That’s my favorite part, to be honest. I mean, that’s the part that I love in my job is starting to redefine teams instead of the classical engineering side. I mean, engineering, it’s all about, in a plant, it’s about being efficient. You need to eke out those latest percentages of efficiency because that makes a difference for a chemical plant. People are not plants. People are not machines. So… Our organizations very often are organized in the same way as we would treat the plant. So what we want to do here is nothing special. It happens all the time in IT. Everybody’s talking about it. I mean, so many books about this topic. It’s just about creating cross-functional teams working on a common problem. And you want to make those teams as autonomous as possible. So there’s nothing exotic in there. I think we started doing this… based on gut feeling that it seemed logical to do this. But I think we really started working with those ideas once we got involved in, once we started reading Team Topologies also brought out by IT Revolution, because that book sort of like gave us the language to put into words, to be able to draw and discuss with other people what we were like feeling on an intuitive level. And this is hard work, just to be clear. If you’re going to a manufacturing environment and you’re telling guys, I’m taking one guy from here, one guy from there and one person from there, I’m going to put them full-time together in a cross-functional team. People do not understand it in the beginning. They think you’re crazy. Are you making a project? Do you need him 20% or 50%? And of course it will only take six months, for example. Like those first teams, to make them, that’s really hard. But once you get that first team rolling and they start showing results and people start to actually also thrive in that environment, then… David (21:42) Mm-hmm. Willem (21:53) I think you’re underway to creating the basis of what you would call even an agile or a digital transformation in your organization. David (22:02) And that’s also very important what you said, this doesn’t even require an organizational change. So it’s not needed that we form another organization just to be able to start these projects. It’s maybe even counterproductive to first do an organizational change and then try to work in a new way. Willem (22:23) Yeah, it’s like those big agile initiatives where they say with a waterfall chart, they will say, then we will have so many squads and then we will do this. It helps. You need your management on board. Let’s be clear about that. You cannot say we’re going to work this way if management says, no way. We’re organized this way. You’re not doing this. But I also think going this big bang approach and writing everything down from a big master plan is… actually completely against the idea of organizing yourself in an agile way. So I like to start small with very concrete things, with very concrete projects or problems we have and start to build those teams out. And you’re right. I don’t need no reorganization. I just want to treat the way we work as a software. If we want to change it, great. We change it. I’m not going to be the one that says like we need to work differently. I would like the teams to say, Hey, Willem, this is not working. If John would go together with this team, it would be much better. If we change the scope of our team, it would be better. Let’s make the way we work also something owned by the team, not by the managers. David (23:37) treat people or treat teams like software. I like that quote, gonna remember that. And then I would say once we have this understanding, then we can go to step three, where we really introduce agile ways of working. Willem (23:54) Yeah, I think I’m currently in the same process within Solvay, for example, where we’re still working in the same way as before, but we’re organizing ourselves slightly different. pre-defining everything but we’re not saying that we’re doing everything in an agile way we still have PMO we have a yearly budget we have scopes we need to achieve so those things are still in place I think it doesn’t help to start to impose on a team specific ways of working if they’re too intrusive if they don’t solve the problems of the team you’re not really helping them A second reason why you wait with these ways of working is where would you implement them? If you don’t have the right team structures, what sense does it make to start to implement a Kanban in a team if you know that it’s just 15 handovers between silos? Okay, you’re optimizing each team and maybe flow will become better, but nothing will replace… the benefit of not having any handovers because everybody’s in the same team, for example. So, solve first the biggest problem, don’t change too much at once, and keep that part of changing the ways of working of the team. Feel when the team is ready for that. It might take some time. Some are more open to it, others not. I don’t see a need to force them directly. David (25:27) amazing and I think also with that it’s about time that we wrap up our first joint podcast. Let’s look forward. So we’ve talked a bit about the things we written. They are highly influenced obviously by the stuff we encountered and the books we read and the people we spoke in the past. Our plan now is we’re going to do this podcast more often. We’re going to invite people, readers of the IT/OT insider, people we know from our network to also talk about these topics. We really like to understand what other people are doing. What are the recipes for success? What are the recipes for disaster? How can you avoid them? So that’s our plan for the. The months and maybe even years to come, who knows. Willem (26:19) Yeah, I’m looking ahead for episode 150 or something like that. David (26:23) Yeah, we should. Yeah, let’s already plan a special event for episode 100. We could do a big giveaway Absolutely. Well, thanks for joining me in this call. And for our listeners, thank you for tuning in. And make sure to subscribe on our YouTube channel on Spotify and on Apple Podcasts or on Substack. Thanks. Willem (26:28) We will do a big giveaway then. Talk to you later. Bye.