The Things Industry 4.0 Got Wrong: The Organizational Problem Technology Can't Solve

Welcome to the Industry 4.0 Club's fireside chat. The club's purpose is to engage the power of diverse worldwide talent to accelerate the global evolution to Industry 4.0. We accomplish this by hosting and supporting respectful, thoughtful, and interdisciplinary open conversations and creating quality content on wide-ranging Industry 4.0 topics to expand the reach of our community. My name is Mike Ungar, and I'm the CEO of the club. I have over 40 years of leadership and management experience, most of that with Michelin. I'm joined today by my co-host, Mike Yost. Mike, would you mind introducing yourself, please? Not at all.

Thank you, Mike. Welcome, everybody. As Mike said, my name is Mike Yost. I am the volunteer chairman of the Industry 4.0 Club and Mike's co-host here on our fireside chats. I've been in industry a little over 35 years myself, a good bit of time on the industrial solution provider side and the last 15-plus years on the industrial nonprofit side. So I really enjoy meeting folks and getting their perspectives, as Mike talked about, on wide-ranging topics around Industry 4.0. So we're really excited today that we have David Arians and Wilhelm von Lammeren, who are co-authors of the book, The IT/OT Handbook: The Practitioner's Guide to IT and OT Cooperation in Manufacturing. Today's topic for our conversation will be what Industry 4.0 got wrong. organizational problems that technology can't solve. So let me introduce our guests here just quickly, and then we'll jump into the conversations. David is an Industry 4.0 and IT/OT thought leader, has deep experience in industrial digitalization, data analytics, and cybersecurity. During his career at BASF, he led Industry 4.0 initiatives across Europe and ultimately oversaw industrial digitization teams at the company's Antwerp complex. Today, he's a co-founder of the IT/OT Insider and the IT/OT Academy, helping manufacturers bridge the gap between IT and OT. Welcome, David.

Thanks for having me again.

Yes, yes. And along with David, we have Wilhelm, who is an IT/OT and digital transformation leader with nearly 2 decades of experience spanning manufacturing operations, operational technology, IT infrastructure, and enterprise systems. Today, he serves as the Industrial AI Product Manager at ScienceCo, where he guides the development of the company's operational data lake while also maintaining a strong connection to the production floor. Like David, he's a co-founder of the IT/OT Insider and the IT/OT Academy, helping manufacturers bridge the IT/OT divide and build the organizational capabilities needed for successful digital transformation. So we're really looking forward to these conversations here today with our guests. If you are live with us on LinkedIn, please go ahead. If you have any questions or comments, go ahead and put them into the comments section and we will do our best to integrate them into the conversation. So welcome, gentlemen.

Thanks for inviting us.

Of course.

It's great to have you guys, and can't wait to talk more about what Industry 4.0 got wrong. So that'll be really interesting. I know, let's jump, let's just right into that if we can. So, you know, we talked about Industry 4.0, it's been framed as a technology transformation, but I know you guys really talk about and argue that many of its biggest failures are organizational. So I think that's an interesting question. So really, when you get down to it, what did Industry 4.0 get wrong? And why do IT and OT still struggle to work together despite, you know, this is not a new topic, years of investment in digital transformation? I'll leave that. Who would like to start us off with that? David?

I'll kick it off. Well, years, almost decades. I think the term Industry 4.0 has been coined around 2010-ish.

2011.

2011. There you have it. So I think it's fair to say that at that time, we clearly had a technology problem to solve. If you look back to the state of IT technology back then in OT, there was clearly a gap to solve. I think today the technology problem has been solved. It took us some years, but we have plenty of technology. And I think the first statement I want to make here is that we kind of, at least in the last years, we kind of confused connectivity with transformation.

Huh.

So it's a bit of a bold statement, but like, and Willem, you just begin wherever you want, but I've been in so many conversations where the problem is still very technical. We need to connect system A to system B. We need to build a unified namespace, whatever that may mean. We need to build such and such. We need to have a cloud system. We need to dump data in our AI platform, blah, blah, blah. But that's where we say, like, yeah, but connectivity is not equal to transformation in Industry 4.0. So that's, I think, problem number one.

If I can go to number 2, is—

Please.

We can dig deeper into each one of those as long as you want, but let's take the second one. Is I'd say 4.0 was more of a vision, like where do we want to be in the future? It didn't come with a manual, it didn't come with a roadmap on like these are the 7 steps you need to do to get to that vision, to get to that end goal. And if you're honest, the goalpost just keeps moving because in the beginning it was like, wow, we can get data from our automation systems into a central server in IT and we can make a dashboard. Then it became, we need to integrate IoT data. Now it's about how do I connect my AI systems to the shop floor? So to say that nothing really happened is wrong.

Yeah, absolutely.

And there's also no real endpoint to this 4.0 story, so to speak. So it gives you a sense that you're never getting there, while in reality you're just continuously evolving.

Playing a game of catch-up, maybe.

Yeah, I've said that for a number of years. That I can remember when we were selling— actually, I can remember when we went from DOS computers to Windows computers in production environments, and that was a big deal well before cloud and AI and the stuff we're talking about today. But today, I think there was a hesitation by industry because there were a lot of missteps. There were a lot of times where people applied technology, maybe coming from the IT world, put it into an OT environment, and it didn't didn't hold up. We had memory leaks and we had network communications issues, right? We had all sorts of challenges like that. So it seemed to me at the time that as an industry, manufacturing sort of hunkered down and said, well, we're different. And so that technology might fit somewhere else, but it doesn't fit with us. And so it ingrained a mindset of us that really we were waiting for the technology to be ready for us. And then to your point, David, it got ready and it got to the point where now we're trying to play catch-up, right? Does that resonate with you guys?

Absolutely. Just a couple of days ago, I was in a conversation with a manufacturer. And so the good thing about working in— well, the good thing— the easy thing about working in OT from a leader perspective, when we both had the leadership role at BASF, for example, was we always joked that The only thing we needed to do was look at the IT world, then have those ideas, you know, write them down, wait a couple of years, and then, and then with a delay of a couple of years, the best ones would triple down into the OT world. And we would have been— we are seen as like these, these futuristic guys who know what is happening, but we were just looking at what happened In the IT world, so there was always this delay. And whether it's five years or ten years, if you just look at the technologies and you know VMs and cloud and containers, and you there is always this delay. But now people expect us to play this really quick game of catch up because all of a sudden everybody would wants to start using these latest AI models, agentic AI, etc., almost at the speed they are made available to the market. And that is something. In my opinion, which is new for us.

Yeah, it would have been, let's say, the normal feedback. For example, you would say cloud solutions should be part of our architecture. I don't know about you, Mike, one of the Mikes, but people were allergic, like, no, I mean, I'm not going to depend on systems that are sitting somewhere else. What if the network breaks down? I mean, it took years for them to get used to those ideas and even virtual machines. I remember vendors saying, we don't support virtual machines.

We go like clockwork.

I'm talking 2020, so it wasn't new technology. Now with AI, you see that hesitation is gone. They want to try out what's possible with AI. I'm not talking about closed loop, but they want to see their systems connected with AI and see what's possible. So that hesitation that we saw before is gone. And now we really need to speed up.

Yeah, I'm sorry, Mike.

Go ahead.

I was just gonna add an anecdote that I used to lead a nonprofit called Mesa International. And I always tell everybody that at Mesa, we never had a conversation about the cloud, because it went overnight from being a technology that manufacturers will never use to a technology that every manufacturer was using. It was, it was crazy to me, to your point of how quickly, quickly that happened. So I'm sorry, Mike, you have a question there?

No, I was just gonna kind of talk a little bit more about this, you know, thinking a little bit to the next topic for a second. So we talked about IT and OT. So, you know, I know in my day, the IT guys focused on making sure that we had good cybersecurity and, you know, that we always had the networks running and they were always up and running and good uptime and, you know, things could talk to one another. The OT guys were looking at, you know, how do we improve productivity? You know, what tools do we have? So they really were looking at almost different problems, right?

Yep.

At the same time. And so, and even different languages to some degree because the IT guys were spending their time With servers, and the OG guys were spending their time on the machines, right? So talk about the differences between these 2 worlds. And even today, I know some of these differences exist. What needs to change organizationally? Because, because you still have these missions that exist, they're real missions, right? What needs to change to get this genuine collaboration we're trying to do? Yeah, I think, you know, To really bring it together rather than just calling it a convergence.

A loaded word.

A loaded word. Willem, do you want to take this one?

So I mean, there's tons of ways you could explain that IT and OT are different. I mean, I guess you both could invent 10 of them. One that we're taking recently, one take, is the acronyms that they use when it comes to their priorities. Within IT, you have CIA, which is about confidentiality, integrity, availability. I mean, you don't want your data to leak, you want your data to be correct, not tampered with, and if all that's accomplished, you know, it's nice if it's available. If you go to production, that changes completely and you get another acronym, SIAC, where the first one is safety. It's like the human, the person's You don't want people to die. That's number one. I mean, in IT, you can say go fast and fail fast and break things. In production, you know, when things break, you might break along. So safety is on top. Then comes integrity, but we're talking about another integrity. It's not data integrity, it's like the asset integrity. Then comes, uh, asset availability. Again, we're not talking data availability, asset availability. And at the bottom, confidentiality. Now, those last 3 might change. I mean, if you're like a pharmaceutical company with a secret recipe, it's different than when you're making plastic cups. But those priorities are not going to change. That means that good IT and good OT are inherently different. And trying to pretend that we're going to make that one single way of thinking is, I mean, it's not realistic. We're not going to turn IT into OT or vice versa.

Yeah.

That doesn't mean you need to give up and say like, screw that cooperation. I mean, and keep on saying that the other side is super annoying. I think the big change that needs to come, to be honest, that's something that IT stole from manufacturing and that we kind of forgot, is that you need to take a look at the way that you work and see it not as something personal. It's like, Mike, why can't you cooperate better with IT? But rather see that as a system that you need to design as an organization. How do decisions get made? How do people work together? And how do you make sure that those incentives are aligned? You can't align them on those top priorities, but you can align them on lower levels, setting up the structures you need to make that happen. Because I don't know about you, but if change needs to happen and you need to get people to work together, the least effective way is to have a town hall, stand there and say, guys, from now on we're gonna cooperate.

Yeah, one team. Well, we used to— one way we overcame that, or at least one, one thing I had heard a colleague describe, is we used to ask IT if we could do something And we used to get a yes or no answer, right? You know, and so the— what we realized is that we needed to ask a different question. I'm talking from the OT side, okay? Not, not can we do it, but what does it take to do it? What are the, what are the conditions we need to meet so we can do it? So in other words, we were beginning to drive solution development, not asking for permission. And I think that, that began to change the conversation a bit. Have you seen the same sort of thing in your work with the companies you work with?

Yeah, absolutely. It's, well, in hindsight, it's kind of obvious that if you're asking a question which is, to your average IT counterparts, a very exotic question, like, we need to support this legacy protocol, or, yeah, we really need a functional user account here, and IT would go like, yeah, but that's against the policy. And then you go like, yeah, But these HMIs, they are always logged on. You know, we can't change that. We can't have an operator first log on before he's able to shut down the line, for example, just as a very, I would say, black and white example. So you do need to translate those requests. And then maybe we have 3 things or 3 important domains where we believe people need to work around. First gonna say them and then we can dig a bit deeper. And that is, first of all, we need to build, uh, build connective tissue between IT and OT. So we need to build those, those connections, and it comes from both sides. So number one is build the connective tissue. It's a bit like what you already said, Mike, about explaining a problem, not just saying like, give me something. Um, number 12— number 2 is we need to build a common architecture. And especially in the IT/OT domain, we are sitting in the middle, which means that we can't expect to have only IT components in our OT systems. Never going to work. But vice versa as well. We can't have only— we can't just port all our OT equipment into IT systems. So we need to build this this intermediate IT/OT architecture. And then the third one is we need to build the skills to do so. And then it, of course, comes back to personnel and knowledge and education, et cetera, et cetera.

Yes.

But those are the 3 important ones. So the connective tissue, the architecture, and the skills, those 3 are needed to make this truly happen and truly scale.

What, uh, appreciate those points. I just want to remind everybody that we're talking with, uh, David Ariens and Willem van Lemmeren, um, about what Industry 4.0 got wrong and, uh, organizational problems, uh, the technology can't solve. Um, they are the co-founders of the IT/OT Insider and the IT/OT Academy. A lot of experience bringing these 2 worlds together. Guys, I want to ask you about the IT/OT handbook that you put together. You identified 7 patterns of collaboration between IT and OT. What can you tell us about these patterns, or what can they tell leaders about where their organization is today? And then how can they determine what the next level of maturity should look like for them?

So I'm going to do the— I'm going to start, Willem, and you just Naturally begin. Like I remember three years ago when we were first discussing, like we were having these these conversations about about cooperation and we were looking for for ways to make collaboration visible because it's not there's not one way to work together. Collaboration is also not an on or off switch yet. It's not something like we are either working together or not. There are also levels of collaboration. So we were looking for ways to, to make that visible. And Willem already hinted to that in the IT world, thinking about organizations, and I'm going to use the word DevOps here, is something which has been introduced in IT already many decades ago. And there are other concepts on thinking about teams, etc., which are becoming really commonplace in the IT world. And we took a step back. We looked at all those concepts. We did years of work around them. And then we asked ourselves the question, can we actually port those concepts into our world and keep the things which are really good, but drop the things which are non-relevant for us? And that body of work became what we then called or named our cooperation patterns. And we first published them 3 years ago on our blog. And in the meantime, so in those 3 years, We did a lot of additional research. We had a lot of workshops and we really tried them out. We got feedback from so many different companies who were actually also trying them out inside their company. And that then resulted, Mike, in our, I would say, our final of the things which you can find in the book, our 7 cooperation patterns. So that's a bit the introduction or the backstory to where we are. And now we basically have this, can I say toolbox, Willem?

Yes. I think Handbook is the right title for the book because indeed we're giving— you should see them as patterns. Like, it's not the perfect recipe because every company is different and you have big companies, small companies, your political landscape is different. But these are a couple of recipes you can try out. You can tune them to your own environment, but they're fundamentally quite solid. And they give you a menu of silos, which are actually good if they're used correctly, all the way to super cross-functional, long-lived product teams working on business problems and not on technology.

And everything in between.

And everything in between. So in the book, we really took the time because that's the advantage of writing more than a blog, it's like you're forced and you have the time to go into more detail. So, it says, like, when do you want to use it? When do you not want to use it? How do you get out of it? Those kinds of things is what we really worked on.

If we have time, I want to take one example.

Please, please, please.

One of my favorites, 2 of my favorite cooperation patterns Are do not shoot me, shadow IT, and the other one is called facilitation. And the reason I'm saying don't shoot me is because the the the the the name you you know you you guys are doing shadow IT. You know they have their servers under their desk and they're running applications, and IT goes like yeah. The thing is, OT engineers are very, very, very capable of running servers and network and applications because that's what we do. It's like literally our job. It's different maybe to other domains like people in HR or finance, which might not have that experience, but we in OT, we do. So having OT engineers, giving OT engineers the the goal of, you know what, if you really need that application, or you just do it. That's what we call shadow IT. And there are pitfalls, but there are a lot of good things. And the good thing is that you have fast solutions and you learn, you learn fast, you learn what it takes to have this maybe more IT-ish application up and running. However, shadow IT has its limitations. And the most important limitation is what happens When you cross that IT/OT line, like when you need network connectivity or cloud connectivity, or when you have that vendor coming in. And that's where our second pattern, which is called facilitation, comes into play. And it's a very simple one. And it's basically we have an architect sitting on the OT side, we have an architect sitting on the IT side. They stay in their organizations, but their job now becomes to solve the easy-to-solve problems. Like, that's all they do. The thing they do is they solve problems. And it's so simple to say, but if you see those patterns and you go like, yeah, obviously, like, this is the way we can actually work. And I worked with an energy company who actually did that. So, they were in silos first, and then they said like, okay, we are going to move into Facilitation because they were too far apart, so they designated OT and IT architects to work together. They did that for a while, couple of years. That's built a common understanding, a common list of problems, common list of challenges, and now they are stepping one. They're going one step further, and they're actually going into more integrated teams and other cooperation models. But they really used it as a stepping stone. for better collaboration.

That's interesting. Um, you know, those patterns are great. You know, I can't really— you make me want to pick up the book and learn the other ones as well, to really better understand the element. I think it's a— and really, I think for companies, it seems like, you know, you want to look at it so you can see yourself in there.

Yep.

You know, maybe a little bit of this and a little bit of that is one way to think of it, perhaps.

I feel like the way you should— the way you can really use this, and this is the way that David and I, we really also tested those patterns, is as also as a communication tool. I mean, graphically, they're super easy to draw on a whiteboard, on a piece of paper, on, on whatever tool you're using, and it makes it very concrete. So with your counterpart, you can start to discuss, like, we're here, you're there, Who's gonna do this? Who's gonna do that? We're doing this, we're doing that. We used to design teams, actually.

I printed the 7 Venn diagrams just on this small card, which, you know, I can hand out, I can use, because those are the 7 patterns. Now, obviously, you need to have some background, but those are the 7 ones. And then we start drawing on whiteboards or these really big Post-it notes and It just makes it a fun exercise.

Before we get too far, I wanted to— we have a comment. And I want— I don't know that we are able to answer it because I don't know if there's enough information. But I wanted to share something with you really quick. So Sudhakar shared something that he mentioned, they've implemented a project, and there are no benefits. And he adds to that, he adds to it, he understood that benefits are possible with complete new infrastructure. So I think Sudhakar, if I can encourage you, I don't know that we can address it with what you've given us, but I'm sure if you reach out to David or Willem on LinkedIn and connect with them, they'd be happy to talk with you about your particular challenge. Is that okay, guys? Are you willing to do that? Sure, of course, of course. Super. I just want to make sure we thank you for putting those comments in your— in Sudhakar, in LinkedIn, but I don't know that we have enough information But please reach out to David and Willem on LinkedIn and connect with them so that they can maybe give you— get more information from you and give you some more insights to dig into those challenges.

Yeah, and my guess there, just to chime in on that, is along the lines of some of the conversation already, the evolution of the technologies available today. I mean, the infrastructure required nowadays to get value out of technology deployments is a lot lighter than it used to be. And so I'd be quite surprised if there was a ton of infrastructure that needed to be put in place to realize at least some value. But we can let these guys dig in more with you.

So every problem is unique. But I— yeah, but indeed, on average, to your point, there is enough technology available to at least make a meaningful start. Whether it's scalable, that's another story, but at least make a meaningful start.

Right.

You know, we've, we've been talking for the last, uh, almost last 30 minutes now. I kind of wanted to hit, uh, jump to a question about, you know, leaders have things to do. Leaders need to make sure that they're moving their businesses forward, right? So if a manufacturing leader recognizes that their biggest digital transformation challenge isn't technology, but really how the IT, OT, operations, and leadership work together, Could you just finally kind of give us 2 or 3 tips or things they could do, let's say tomorrow even, to begin making a change to how they work together?

There is, there is a very easy one everybody can do tomorrow. And Willem, I'm giving you— yeah, you go ahead.

Leader or not, but especially leaders, if you're from IT, go to production. I mean, IT, especially in big organizations, sits in headquarters. You cannot design solutions if you do not know your users. Go to them, survive the first 30 minutes talking about bad Wi-Fi and some stuff like that, and start to listen what their real problems are, because you might have a completely different view.

And here is just a small tip for your average service organization, IT organization, whatever. Just count the number of of people who have PPEs. You are— you'll, you'll be amazed how little people— how I would say, how, like, if you have 100 people in your organization, how, how many of those actually have PPEs? And that means if they don't have them, like, have they ever been on a shop floor? Question mark. Send them there. Um, so that's number one. The, um, the, the, the other one is also a completely different topic. That is, in manufacturing, we are very, very good at doing projects. That's how we work. Every manufacturing organization does projects the entire time. However, when we are implementing digital solutions, digital problems, we typically don't know what the end goal is going to be. It's a moving average. We already discussed that briefly in the beginning of this conversation. So that means that a simple question, another again a very simple thing. If you are currently in a project, in the next steer co meeting, whatever you have, you ask the question: What happens after go live? Or what happens after the project comes to a closure? Very simple. Who owns? Where did the budgets come from? What people are still gonna remain here? Et cetera, et cetera, et cetera. But simple question, what happens after the project closes?

I think also linked to that, besides IT visiting sites, I would say also for on the operations side to get to know the tech world better because it's hard to understand what it takes and what the challenges are if you do not start to really understand what it takes to deploy technology at scale. It's different than deploying manufacturing at scale. Just like David said, the problems are undefined and they're most of the times not solved, which is very different from engineering problems. Because if you're doing the bottlenecking, you know what you're going to do, you know what you're going to change, and you know exactly in what steps you're going to execute at the bottlenecking. I can guarantee you, your next AI project is going to be very different. Like, we're gonna do something with AI, maybe in this domain, maybe in that domain, but you cannot guarantee where you're going to end. And that's a very different mindset and a different way of funding and organizing work. So take some time to get to know that world also.

Yeah, that's very good advice. Yeah, I wanted— go ahead, Mike.

Oh no, I just said that was great advice.

Yeah, right. So guys, I wanted to ask you, as we wrap up here, At the top, Mike mentioned briefly that you guys have a book that's coming out. Can you just talk about the book for just a second? Because I think it contains a lot of things you've shared today. So what's the title of the book again, and maybe where we can find it if we want to get it?

So very simple, it's titled The IT/OT Handbook. Very easy to remember. We had a very complex title in our mind, but our publisher said, um, you know what, guys, I think the IT/OT Handbook is a better one. So, um, that's the title. It's basically, it's basically the book we wish we had, um, when we were doing these types of projects. Um, and it can be found, uh, all across the world, uh, in your, your favorite online bookshop. So Amazon, but, but so many other, uh, platforms as well.

Perfect. And is it available now or is it not quite yet?

In 2 weeks. The official release date is October 6th. So that's just around the corner, especially for us because we've been working on the thing for 3 years. So in our minds, tomorrow.

No, but even though we're live, I'm glad you said the date because even though we're live now, I know some folks will pick up this recording in a little bit. So yeah. October 6th is the date to remember to get it. That's wonderful.

That's excellent.

Well, yeah, so I want to thank you guys, both of you, David and Willem, for sharing your perspectives on addressing— I won't say IT/OT convergence because that would be wrong, but this idea of IT/OT and organizational challenge and ways on how to really focus on the problem solving and bringing together and driving the future of the organization. So thank you for that.

Thank you for having us.

Yeah, the Industry 4.0 Club, we'd like to encourage you to take some action to advance the deployment of Industry 4.0. So read an article, read a book, you just got an example of one that you can take a look at, develop, attend a workshop, or develop a smart manufacturing roadmap for your, your plant or your company, or challenge your organization to do the same. We'd love to hear what you're talking about, what you're doing. Drop us a line on our LinkedIn page or at our website at www.industry4oclub.com and let us know what actions you're taking to advance the deployment of Industry 4.0. We also host conversations like these weekly, so if you'd like to be a guest on a future fireside chat, we'd love to hear from you. Drop us a note and let us know, and we'll do our best to get you scheduled for a future talk. With that, again, David, thank you. Willem, thank you. Mike, thanks for taking your time out of your day, and we look forward to seeing and hearing from you in the future.

Thank you.

Thanks, gentlemen.

Bye.

Thank you.