IT/OT integration at Liebherr: How a platform strategy is accelerating digitalization in production

Today’s guest is Liebherr-Hydraulikbagger GmbH, represented today by Lukas Scholze, Technical Solution Architect IoT, together with their IoT partner Cybus, represented today by Peter Sorowka, CEO. We talk about the challenges, successes and the entire path to successful IT/OT integration. What were Liebherr’s biggest learnings from the last 2 years? What makes the IT architecture here so special? How do you move from isolated individual solutions to an integrated smart factory? And how does Liebherr enable the organization to implement use cases, keyword: change management? We share unique best practices and insights from practice. As always, you can find out what you should bear in mind when implementing and all the information on implementation at www.iotusecase.com. And so I would say, let’s go to the podcast studio.

Hello Peter, hello Lukas, welcome to the IoT Use Case Podcast! Peter, I’ll start with you: how are you and where can I reach you right now?

Peter

Hi Madeleine, thanks for having me again – this is actually my third time on your podcast! I’m doing very well. The new year has kicked off in an exciting way. Despite the challenging economic situation, especially in Germany, digitalization, modernization, and investment remain highly relevant topics. We’re not seeing any slowdown in these areas, and we’re happy to support companies on this journey. Today, you’re reaching me at our office in Hamburg – one of the few who regularly work on-site. Even though we’ve also adopted a hybrid work model, I’m usually here.

Great! Sending greetings to Hamburg. I checked back: Peter first joined us in Episode 8, which was quite a while ago—on September 20, 2020. Then we had Episode 69, which was also some time back. All the more reason I’m excited to have you here again today! Lukas, how are you, and where are you right now?

Lukas

I’m doing fantastic! I started the year with new goals and challenges. Right now, I’m near our site in Kirchdorf, close to Memmingen.

Kirchdorf – right, let me quickly look that up. That’s Liebherr-Hydraulikbagger GmbH, correct? Looking at the map, Memmingen is nearby. What else is around? Lake Constance isn’t too far away, is it?

Lukas

Yes, more or less between Ulm and Lake Constance.

Nice! Habt ihr dort ein Werk oder mehrere?

That’s actually Liebherr’s founding location.

Cool! I’m sure we’ll get back to that in a moment. But first, a quick question: Your role is quite specific—you’re a Technical Solution Architect. Liebherr is a large company, so what exactly does your role entail?

Lukas

To clarify, I don’t represent the entire Liebherr Group, but specifically Liebherr-Hydraulikbagger GmbH. We manufacture construction machinery, including excavators, dump trucks, and material handling machines. My role is within the IT department, where I’m responsible for implementing IT and IoT use cases in our production environment. This means I support different production areas in finding technical solutions, advise on the right technologies to create added value, and oversee the entire solution journey for our internal customers.

I’d like to come back to this later because your organizational structure and approach to digitalization are really interesting. But first, to better understand your core business: You’ve already mentioned that we’re talking about Liebherr-Hydraulikbagger GmbH and briefly outlined what you produce. Who are your typical customers? And as a follow-up question: What is your vision—both for yourselves and for your customers—in the field of IoT?

Lukas

You can think of our production as a classic heterogeneous manufacturing mix. We have our own steel fabrication, assembly areas—many of our machines are assembly-intensive—as well as large logistics areas with complex logistics concepts for various components. An important internal customer is also our maintenance department, which ensures the smooth operation of our plants.

Interesting!

Interesting! So, your own plants are essentially your internal customers?

Lukas

We work exclusively internally and provide our solutions only to our own departments.

I see. Und wie sieht eure Vision für IoT in diesen Werken aus?

Lukas

We started with the typical challenges that many industrial companies face. Our vision is to create greater transparency through IoT and data generation, to better understand our processes, and to react more quickly—all with the overarching goal of increasing efficiency.

Great! So, your role is focused on the shop floor and the production plants in general, but it’s also about integrating OT data with IT and implementing the right use cases, correct?

Lukas

Exactly. At the beginning, we had clear role separations: A traditional OT role took care of the equipment, while my role sat at the interface with IT, ensuring the data could be effectively used.

Cool! Cool! What does your team structure look like? How do you collaborate and stay connected internally?

Lukas

Initially, we worked in a classic project organization—with teams from different departments acting as internal customers and IT experts supporting them. My role was to guide the project from the start. Now that we’re in an operational phase, our way of working has changed. Our IT department acts as an internal service provider but remains closely connected to the customers. Some team members are even embedded directly within specific departments. We strive to maintain a balance between centralized IT management and close collaboration with our internal customers.

You are quite a young team, right? New roles and points of contact make your way of working quite unique, don’t they?

Lukas

Exactly. Our roles were newly created—both mine and that of my colleague, who is also responsible for this topic. For both of us, this is our first job, and it’s exciting to dive into the topic, explore new areas, and actively shape the development.

[07:25] Challenges, potentials and status quo – This is what the use case looks like in practice

Really cool! Peter, you’ve been working with Cybus for quite some time now. Can you give us an overview of what your joint project with Cybus and Liebherr-Hydraulikbagger is all about?

Peter

Exactly. Cybus is a software provider for shopfloor connectivity. With Cybus Connect, we offer an integration platform for live data between OT and IT. Some call it a Unified Namespace, others a gateway—we refer to it as a Smart Factory Integration Platform. There isn’t a single, standardized definition for this yet. We’ve been working with Liebherr for about two years now, right, Lukas?

Lukas

Yes, we kicked off the project in summer 2023.

Peter

Exactly. When we first met, you were in a very interesting phase. I remember one of the things you said—don’t quote me on the exact number—but essentially: “We want to digitalize our factory. It consists of many different areas, and we have a long list of about 78 use cases. Of course, we could implement them one by one, but even if we were quick and did one every six months, it would take 39 years—and that’s just not feasible.” Lukas, correct me if I’m wrong, but back then, you realized you needed a platform approach. Instead of working project by project, you wanted to consolidate commonalities and establish a unified technical infrastructure. This way, use cases could be implemented faster and in parallel. Otherwise, the process would be too slow, and many seemingly small use cases would never even get approved as projects. That was the starting point. When we introduced ourselves as a provider, you already had experience with various open-source tools. So, we decided to run a Proof of Concept (PoC): within three months, we aimed to implement the first three use cases. In reality, we finished in just two months, which led to the green light to continue working on this solid foundation.

And that’s exactly what it’s about—a Smart Factory is never truly finished; it is in constant evolution. Today, after almost two years of collaboration, we have already achieved a lot operationally.

Thank you for sharing your experiences here on the podcast! It’s fascinating to learn from real-world applications and discuss best practices—especially since many companies face similar challenges. I have another question: You mentioned 78 use cases. Lukas, earlier you talked about process optimization, transparency, etc.—but what exactly do you define as a use case?

Lukas

Great question! The definition of a use case can vary. For us, a use case essentially represents a requirement—sometimes from an entire organization, sometimes from a single person—that can be solved using IoT. A use case can be very small, like visualizing a single KPI, or very large, such as implementing a comprehensive tracking system in logistics. From our experience, there are countless use cases—the list has probably grown even longer by now. That’s why our focus is on providing a solid data infrastructure. We can’t address each use case individually and sequentially; instead, we need a technical foundation that allows us to implement new requirements quickly and efficiently. After all, new technologies, ideas, and changes are constantly emerging, making a sequential approach impractical.

Thanks for the clarification! So, when you talk about use cases, you mean internal requirements that create value through IoT—whether by increasing transparency or improving efficiency. What I also find interesting is that intralogistics is not just about production within the factory, but also involves broader value streams that you consider across different areas.

Lukas

Exactly! Many companies start with individual production processes, but the most exciting use cases emerge when they connect multiple areas and enable cross-functional integration.

Peter

That’s exactly where we see a significant shift. Connecting machines, extracting data from a controller or sensor, displaying it on a dashboard, or storing it in a database—none of that is new. This has been done for 20 or 30 years already. The problem for a long time was the siloed, project-driven approach. No one intentionally created data silos, but if a company, for example, sets up a quality management database, it typically buys specialized software that only handles quality data. Maintenance data or energy data isn’t captured there—so another data silo is created. Liebherr’s new approach tackles exactly this issue: Instead of isolated systems, they pursue an integrated platform approach. This allows use cases to be implemented holistically. One example: If a traceability system is already being implemented, an additional requirement—such as energy management—can be built on top of it. The carbon footprint can then be calculated almost automatically, as the necessary data already exists and just needs to be linked. That’s the real power of cross-functional thinking in industrial IoT.

Before we dive into the technical architecture, let’s stay on the organizational side for a moment—I find this aspect particularly exciting in your project. Liebherr is pursuing a holistic approach here. I’d love to discuss best practices for organizational structure and change management. Lukas, how did you get started? How is your organization structured to implement use cases like traceability? And what happens when someone comes to you with a new requirement? Can you walk us through that?

Lukas

Absolutely, our approach has evolved over time. In the beginning, we first had to gain an overview: What use cases even exist? From a knowledge perspective, we were starting from scratch—not just as an organization but also on a personal level. At first, the entire process had a clear project structure: We ran large workshops, yctively searched for use cases, and directly engaged with the departments. Of course, the initiative wasn’t driven by IT alone—the ideas came from the departments themselves. Our goal was to include everyone and not just focus on individual departments, but rather to develop a cross-functional perspective. Now, things have shifted: Departments are actively approaching us, presenting ideas and requirements, and asking whether implementation is possible. This change happened once we had built the necessary expertise—both technologically and organizationally. Departments now know that we can provide solutions, so they bring targeted requests to us.

Just a quick follow-up: When you say expertise, do you mean knowledge about technologies and solutions—for example, which systems you use or which solutions are approved for procurement? Does that mean you can now accurately assess which use cases can be implemented with which technologies and what data is required?

Lukas

Exactly, that plays a big role. At the same time, it’s also about placing use cases on a timeline. Many ideas are theoretically feasible, but the real question is whether they make sense at a given time. Some use cases are ahead of their time technologically or don’t yet fit into the existing strategy. Additionally, resources are limited, so we have to prioritize.

So, project management and prioritization are key parts of the process? Okay, Peter, let me ask you something: You work with many companies like Liebherr. Do you see a general pattern of organizations evolving in this direction, or is this specific to Liebherr? What’s your perspective?

Peter

Great question! We actually see companies that we call frontrunners—those that don’t see Industry 4.0 as an innovation project but as a business-critical transformation and are already capable of rolling it out, either at a single site or even across multiple locations. These companies have realized that digitalization in production is not primarily a technology problem but, first and foremost, an organizational challenge. Companies that struggle often face a deep divide between OT and IT. From an IT perspective, OT is the area that doesn’t comply with security standards. From an OT perspective, IT is the enemy that won’t open the firewall. These two sides first need to find a common language and sit at the same table. What is OT particularly good at? OT knows the machines inside out—their processes, settings, setup times, and maintenance. IT, on the other hand, specializes in deploying technology efficiently and at scale. In a smart factory, it’s no longer about spending a year developing a single use case. Instead, the technological foundation must be in place to continuously implement new digitalization applications at a fast pace. A use case can be tiny, like a machine automatically sending a fault message to maintenance. Or it can be massive, such as implementing a cloud-based MES or equipping workers with digital assistance systems. Without the professionalism and governance of an IT-supported approach, this quickly spirals out of control—simply because it becomes too much to handle.

Yes, that brings us to an interesting question: What comes first—the use case or the organizational structure? For a while, this was a big debate. I once did an episode on this: Does connectivity come first, or the use case? Now, with organizational structure, we have yet another dimension to consider. Many companies are facing exactly this challenge. That’s why I find it fascinating to see how Lukas and his team have positioned themselves internally—not only as consultants but also as implementers who actually bring these projects to life. Are there best practices you would recommend to companies in a similar situation? What should they absolutely do?

Peter

I see all kinds of extremes in companies. There are firms that have received years of change management consulting from big names like PWC and, in the end, built a 30- to 40-person cross-functional, cross-site project organization—a sort of digital enabler. That works, but it’s extremely complex and expensive. At the other end of the spectrum, you have companies where a single person—often someone who just finished their master’s thesis at the company—has been assigned by management: You are now our Digital Owner. Take care of it! That’s the absolute minimal approach. Lukas, I’d say you fall somewhere in between. All approaches can work, depending on the organization—whether it involves multiple locations or how large the company is. But what’s crucial is a clear transformation mandate from top management. Whether it’s the CEO, CIO, or COO, there needs to be someone who truly stands behind it and says: We need to prepare ourselves for data-driven production. And that requires the right budget. A platform approach has a significant drawback: The initial setup is an investment. I often compare it to a highway—once it’s built, you can move quickly and efficiently in all directions. But the construction itself takes time and money. If you immediately start demanding a direct ROI on this investment, you quickly hit a dead end. We see this a lot in traditional industrial procurement processes, where it’s still difficult to justify investments in software solutions. These are the patterns we observe.

Lukas, a question for you: Many of our listeners are in the middle of implementation—just like you. They are driving use cases forward within their organizations. Have you encountered any pitfalls or no-go’s that people should be aware of? What have you learned in your role that you can share here?

Lukas

One important lesson we’ve learned the hard way is maintenance management. At the beginning, everything sounds promising—you present innovative solutions, conduct initial workshops, and have brainstorming sessions. But there is always a time gap between the initial idea and actual implementation, especially when starting from scratch. During this phase, some people lose interest—particularly those who were skeptical from the start. Bringing them back on board later is difficult. That’s why it’s crucial to communicate transparently from the beginning about what is realistically achievable. An organization that is just beginning its digitalization journey cannot implement an AI-driven predictive maintenance process within the first year. It’s an evolution—and that needs to be clear from day one.

When it comes to IT infrastructure, there are usually two approaches: Either a centrally managed system with unified standards, clear policies, and centralized control—or a decentralized structure where individual plants make their own decisions, often because they are older or have unique requirements. Peter previously mentioned the challenge of siloed applications running on different systems. How do you handle this challenge? Have you encountered it in your project?

Lukas

Definitely. We use central service connectors that are embedded in IT. This ensures compliance with all IT governance rules, providing a clean and seamless operation.

So, you adhere to the unified standards you’ve internally defined—in coordination with procurement as well?

Lukas

Exactly, this applies to procurement and all related administrative processes. However, on the OT side, much more flexibility is required, as each machine has different requirements. While we use a standardized edge device that we developed in-house, it’s crucial to clearly define the interface between standardized and flexible areas. In my opinion, allowing flexibility in certain areas is important—but it’s equally essential to establish a clear handover point where standardization takes effect. Whether you use an edge device or integrate a PLC from a specific manufacturer via OPC UA is secondary. What matters is that the overall system remains integrable and scalable. This allows you to decide flexibly which processes should be centrally managed and where decentralized control makes more sense.

Interesting! One more question for you, Peter: How do you see the balance between central governance and the freedom to manage things decentrally? What do you think is the right balance?

Peter

This is probably the biggest challenge in IT/OT convergence. And we’re only talking about a single site here—things get even more complicated when multiple sites are involved. Nothing creates more resistance than a group IT department that “imposes regulations.” A customer once aptly called this Freedom in the Box. IT must define company-wide standards and at least conventions for data models: How are data points named? What hierarchy are they structured in? Without such guidelines, use cases cannot be reused at scale, and uncontrolled fragmentation occurs. At the same time, every department has its own digitalization agenda. IT is not a driving force that pushes digitalization but rather a support organization. It provides the necessary infrastructure as a shared service to meet internal customer demands. I always put it this way: IT must centralize everything necessary to ensure a certain level of quality. The moment Lukas’ internal customers start relying on data, and he suddenly can’t provide it, his phone will start ringing. At that point, it’s no longer just about data—it’s about Service Level Agreements (SLAs). To ensure SLAs are met, clear standards are essential. At the same time, IT solutions must deliver exactly what the customers actually need.

That makes perfect sense! I see this in other companies as well: IT should be closely integrated with procurement. The dependencies are so complex that they first need to be fully understood. Maybe the procurement approach itself should be expanded.

Peter

How does this work in your organization, Lukas? Some of our customers have integrated their procurement and tendering processes into their digitalization strategy. This ensures that new machines or systems are compatible with the existing infrastructure—so that the next MES doesn’t suddenly come with its own gateway, creating isolated solutions. By involving all relevant departments early on, you can create a truly cohesive smart factory. Have you followed this approach as well?

Lukas

Yes, for us, things used to be quite different. When a new machine was purchased, IT was often only involved at the very end—when it came time to connect it. That has completely changed now. Awareness has grown that IT needs to be involved early on. This doesn’t just apply to machines but also to applications. Today, IT is no longer just a service provider but plays a central role in implementation and standardization. The moment a cloud-based software can’t be used because it doesn’t meet security requirements, you realize how important it is to involve IT from the beginning. By now, we are always involved—even in physical acquisitions like machinery. In these cases, we bring our expertise to the table when working with suppliers: What is technically feasible? What can the manufacturer actually provide? In custom machine building, there aren’t always standardized solutions. But our goal is to establish long-term compatibility—ensuring that a machine that operates for 10, 15, or even 20 years remains digitally connected throughout its entire lifecycle.

Very exciting! By the way, if you’re listening to the podcast and have thoughts on this topic, let us know. How do you handle this in your production or operations? Feel free to leave a comment or reach out to us on LinkedIn—you’ll find the links in the show notes. I’m curious to hear about your experiences!

Now, to wrap things up, let’s take a look at the actual implementation. At some point, you had to decide: Make or Buy—and you chose Cybus. If I understood correctly, there was initially an internal project that ran successfully. After that, you decided to continue working together instead of developing your own solution.

Lukas

Exactly. Exactly. Our general IT approach is to use existing market solutions if they meet our requirements. After a successful PoC, we decided on Cybus and have been using it as our integration platform for data ever since. Our standardized edge devices connect production equipment and assembly systems with IT security. For end users, we currently rely on an open-source architecture to keep costs low at this stage. At the same time, we integrate the platform into existing systems like MES and ERP—the typical data silos that exist in many companies.

You previously mentioned your edge computers and OT integration. You’re using an internally developed box, right? I believe Matthias Morath mentioned it in an earlier podcast episode. What’s the official name?

Lukas

Officially, it’s called the Liebherr IoT Cabinet, or simply the IoT Box. It serves as a central interface, enabling data handover by combining flexibility with standardization at both the data and protocol level.

Okay, I’ll add the link to the show notes—check it out if you want to take a closer look at the IoT Box. From an architectural standpoint, the box handles data acquisition. The data then flows into Cybus Connectware, which serves as the central middleware. Connected to it are your enterprise IT systems, as well as open-source tools and other solutions you’re using, correct?

Lukas

Exactly! For example, for dashboarding, when it’s not included in existing applications. This allows us to create reports and live dashboards flexibly.

[30:15] Transferability, scaling and next steps – Here’s how you can use this use case

Cool! Peter, a question for you: Cybus Connectware—what makes it unique? There are many options out there, and some companies build their own solutions. What sets your platform apart?

Peter

Essentially, we’ve tried to translate the technical aspects of data collection, normalization, and distribution into a product—particularly within a configuration environment. A typical use case is collecting data from an OPC UA server. The data arrives in the format dictated by the server, which can vary depending on the Companion Specification—for example, in plastic injection molding or machining. The Liebherr IoT Box also has its own namespace. So, the first goal is data collection. The next step is mapping this data to a unified standard—a Unified Namespace with a consistent structure and data model. This ensures that two machining centers from different manufacturers can be represented in the same way. The third step is data distribution. This can be done entirely via MQTT—we’ve integrated a scalable industrial MQTT broker for this. However, many MES systems and enterprise IT applications are not native MQTT clients but rely on their own databases. So, the data needs to be transferred accordingly. These three tasks—collecting, normalizing, and distributing—are combined into a single product that IT departments, particularly in terms of configuration logic, find highly beneficial. Our software is specifically designed for high automation. In general, we see two approaches: The low-code approach, such as Node-RED, enables rapid prototyping and quick machine integration via drag-and-drop. This works well for smaller implementations but hits scalability limits in large-scale environments. And infrastructure-as-code, where configurations can be scripted, automated and versioned. For customers managing tens of thousands of shopfloor assets, manual configuration is no longer practical. Instead, we rely on Infrastructure as Code—a scriptable, automatable, and versionable configuration. This allows even small IT teams to efficiently manage complex data orchestration processes and provide them reliably.

Cool! Lukas, do you work directly with the tool, or does it run more in the background? Do you use it during operation?

Lukas

Yes, definitely! To reinforce Peter’s point: One of the biggest advantages of this solution is that we can leverage automated connectivity. We don’t have to configure services manually for each individual system—they all look the same anyway because they’ve been standardized upfront. This automation works incredibly well and gives us a huge advantage: We don’t have to interact with the system manually all the time, but instead, we can work with standard IT tools that allow us to distribute software or automate systems.

Impressive! So that means, when a new person approaches you with a use case or a new requirement, you can immediately check whether the required data is already available or if new data needs to be collected. Then, you implement the use case together with your colleagues using Connectware, right?

Lukas

Exactly! And in the best case scenario, if a new system is added and we need to create a new Edge device, one click is enough: Enter the host name and the process runs automatically – including the database connection. This makes the system extremely appealing.

Fantastic! Maybe we should have a look at it live. If you as a listener would also like to see the system, you will find the contact details of Peter and Lukas in the show notes. Feel free to contact us and let us show you the system. Every use case is individual, of course, but you’re open to requests, right?

Peter

Definitely! We have various demos with simulated data that we can show at any time. There are also customers who are available as references. I don’t want to overwhelm Lukas with too many requests, but we welcome anyone who wants to understand the topic better. Sometimes we could almost charge an entrance fee – but we are always happy to see interest!

Otherwise, you are cordially invited to join our community. You can exchange best practices there – Liebherr is also represented, as are many other companies. It is a good opportunity to share experiences and exchange views on challenges and solutions, particularly in the IT sector. I have countless more questions in my head, but for today I would like to end the session here. I think we got a very good insight – both into the requirements and best practices for organizational change and into the concrete implementation of use cases with Cybus Connectware and your gateways. A big thank you from me to both of you! Thank you for joining today!

Lukas

Thank you very much for the invitation! It was really fun to talk about this topic – I could go on forever. It’s a good thing we have a time limit, otherwise I’d probably be sitting here until late at night. It’s always fun!

Peter

Many thanks from me too, Lukas! I find it impressive what you have achieved in the last two years. You are one of the few companies that have really come this far. After ten years of Industry 4.0, I regret to say that it is still not a matter of course. Many companies find this difficult, but you are a real role model. You can now implement use cases in just a few days instead of several months – that’s a big step! You are definitely a shining example for me.

Great! Thanks again to both of you – and have a nice rest of the week. Take care!