IT/OT-Integration bei Liebherr: Wie eine Plattformstrategie die Digitalisierung in der Produktion beschleunigt

Heute zu Gast ist die Firma Liebherr-Hydraulikbagger GmbH, stellvertretend heute durch Lukas Scholze, Technical Solution Architect IoT, zusammen mit ihrem IoT-Partner Cybus, heute stellvertretend mit dabei Peter Sorowka, CEO. Wir sprechen über die Herausforderungen, Erfolge, aber auch den ganzen Weg zu einer erfolgreichen IT/OT-Integration. Was waren die größten Learnings von Liebherr aus den letzten 2 Jahren? Was macht die IT-Architektur hier so besonders? Wie kommt man von isolierten Einzellösungen hin zu einer integrierten Smart Factory? Und wie befähigt Liebherr hier die Organisation zur Umsetzung von Use Cases, Stichwort: Change Management? Wir teilen hier einmalige Best Practices sowie Erkenntnisse aus der Praxis. Was ihr bei der Umsetzung beachten solltet und alle Infos zur Umsetzung findet ihr wie immer unter www.iotusecase.com. Und damit würde ich sagen, let’s go ab ins Podcaststudio.

Hallo Peter, hallo Lukas, herzlich willkommen im IoT Use Case Podcast! Peter, ich starte mit dir: Wie geht’s dir, und wo erreiche ich dich gerade?

Peter

Hallo Madeleine, danke, dass ich wieder dabei sein kann – mittlerweile zum dritten Mal in deinem Podcast. Mir geht es sehr gut. Das neue Jahr startet aufregend. Trotz der schwierigen wirtschaftlichen Lage, insbesondere in Deutschland, bleibt Digitalisierung, Modernisierung und Investition ein aktuelles Thema. Wir sehen hier keine Verlangsamung und helfen gerne weiter. Du erreichst mich heute in unserem Büro in Hamburg – einer der wenigen, die regelmäßig vor Ort sind. Auch wir arbeiten mittlerweile hybrid, aber ich bin typischerweise hier.

Sehr schön! Liebe Grüße nach Hamburg. Ich habe noch mal nachgeschaut: Peter war das erste Mal in Folge 8 zu Gast – das ist schon lange her, am 20. September 2020. Dann hatten wir noch Folge 69, die auch schon eine Weile zurückliegt. Umso mehr freue ich mich, dass du heute wieder dabei bist. Lukas, wie geht’s dir, und wo bist du gerade unterwegs?

Lukas

Mir geht’s wahnsinnig gut. Ich bin mit neuen Zielen und Aufgaben ins Jahr gestartet. Du erreichst mich gerade in der Nähe unseres Standorts in Kirchdorf bei.

Kirchdorf – genau, ich muss das mal kurz nachschauen. Das ist die Liebherr‑Hydraulikbagger GmbH, richtig? Wenn man sich die Route anschaut – Memmingen ist in der Nähe. Was gibt es sonst noch in der Umgebung? Der Bodensee ist ja auch nicht allzu weit entfernt, oder?

Lukas

Genau, genau – Kirchdorf an der Iller in dem Fall. Ja, mehr oder weniger zwischen Ulm und dem Bodensee.

Schön! Habt ihr dort ein Werk oder mehrere?

Genau, das ist sogar der Gründungsort von Liebherr.

Cool! Da kommen wir sicher gleich noch drauf zu sprechen. Aber zuerst eine kurze Frage: Deine Rolle ist ja etwas speziell – du bist Technical Solution Architect. Liebherr ist ein großes Unternehmen, was genau bedeutet deine Rolle?

Lukas

Man muss das einordnen: Ich repräsentiere nicht die gesamte Liebherr-Gruppe, sondern die Liebherr‑Hydraulikbagger GmbH. Wir produzieren Baumaschinen wie Bagger, Muldenkipper und Materialumschlagmaschinen. Meine Rolle ist in der IT angesiedelt, und ich bin für die Umsetzung von IT- und IoT-Use-Cases in unserem Produktionsbereich zuständig. Das bedeutet, ich unterstütze die unterschiedlichen Produktionsbereiche bei der technischen Lösungsfindung, berate zu geeigneten Technologien, um Mehrwerte zu schaffen, und begleite den gesamten Lösungsweg für unsere internen Kunden.

Superspannend! Ich würde später noch mal darauf zurückkommen, weil eure Organisationsstruktur und euer Ansatz zur Digitalisierung wirklich interessant sind. Aber zunächst, damit man euer Kerngeschäft besser versteht: Du hast bereits erwähnt, dass es um die Liebherr‑Hydraulikbagger GmbH geht und kurz umrissen, was ihr produziert. Wer sind eure typischen Kunden? Und als Anschlussfrage: Was ist eure Vision – sowohl für euch selbst als auch für eure Kunden – im Bereich IoT?

Lukas

Man kann sich unsere Produktion als einen klassischen heterogenen Fertigungsmix vorstellen. Wir haben eine eigene Stahlbaufertigung, Montagebereiche – viele unserer Geräte sind montageintensiv – sowie große Logistikbereiche mit komplexen Logistikkonzepten für verschiedene Bauteile. Ein wichtiger interner Kunde ist auch die Instandhaltung, die den Betrieb unserer Werke sicherstellt.

Interessant! Das heißt, eure eigenen Werke sind quasi auch eure internen Kunden?

Lukas

Genau, wir arbeiten ausschließlich intern und bieten unsere Lösungen nur für die eigenen Abteilungen an.

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

Lukas

Wir sind mit den typischen Herausforderungen gestartet, die viele Industrieunternehmen kennen. Unsere Vision ist es, durch IoT und Datengenerierung mehr Transparenz zu schaffen, unsere Prozesse besser zu verstehen und schneller darauf reagieren zu können – mit dem übergeordneten Ziel der Effizienzsteigerung.

Sehr gut! Deine Rolle bezieht sich also auf den Shopfloor und die Werke allgemein. Es geht aber auch darum, OT-Daten mit IT zu integrieren und entsprechende Use Cases umzusetzen, oder?

Lukas

Genau. Anfangs haben wir die Aufgaben klar aufgeteilt: Eine klassische OT-Rolle kümmert sich um die Anlagen, während meine Rolle an der Schnittstelle zur IT liegt, um die Daten dort nutzbar zu machen.

Cool! Wie sieht dein Team konkret aus? Wie arbeitet ihr zusammen, und wie vernetzt ihr euch intern?

Lukas

Zu Beginn haben wir klassisch in einer Projektorganisation gearbeitet – mit Teams aus verschiedenen Fachbereichen, die als interne Kunden auftraten, sowie IT-Experten. Meine Rolle war es, das Projekt initial zu begleiten. Inzwischen befinden wir uns in einer operativen Phase, wodurch sich unsere Arbeitsweise verändert hat. Unsere IT fungiert als interner Dienstleister, bleibt aber eng an den Kunden. Einige Rollen sind direkt in den jeweiligen Abteilungen angesiedelt. Wir versuchen, eine Balance zwischen Zentralisierung in der IT und der Kundenorientierung zu halten.

Ihr seid, glaube ich, auch ein recht junges Team. Neue Rollen, neue Ansprechpartner das ist auch ein bisschen besonders, oder?

Lukas

Genau. Unsere Rollen wurden neu geschaffen – sowohl meine als auch die meines Kollegen, der ebenfalls für das Thema zuständig ist. Für uns beide ist es der erste Job, und es macht Spaß, sich in das Thema einzuarbeiten, neue Bereiche zu erschließen und aktiv mitzugestalten.

[07:25] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Total cool! Bevor wir auf die Use Cases eingehen, noch eine Frage: Peter, ihr arbeitet mit Cybus schon eine ganze Weile zusammen. Kannst du uns abholen, worum es bei eurem gemeinsamen Projekt mit Cybus und Liebherr-Hydraulikbagger GmbH genau geht?

Peter

Genau. Cybus ist ein Softwareanbieter für Shopfloor-Vernetzung. Mit Cybus Connectware bieten wir eine Integrationsplattform für Live-Daten zwischen OT und IT an. Manche nennen es Unified Namespace, andere ein Gateway – wir bezeichnen es als Smart Factory Integrationsplattform. Eine einheitliche Begriffsdefinition gibt es noch nicht. Mit Liebherr arbeiten wir seit etwa zwei Jahren zusammen, richtig, Lukas?

Lukas

Genau, wir haben im Sommer 2023 mit dem Projekt gestartet.

Peter

Genau. Als wir euch damals kennengelernt haben, wart ihr in einer spannenden Phase. Ich erinnere mich an eine Aussage von euch – nagelt mich nicht auf die genaue Zahl fest –, aber sinngemäß hieß es: Wir wollen unsere Fabrik digitalisieren. Sie besteht aus vielen unterschiedlichen Gewerken, und wir haben eine Longlist mit etwa 78 Use Cases. Natürlich könnten wir jeden einzeln umsetzen, aber selbst wenn wir schnell sind, dauert das pro Use Case ein halbes Jahr. Das bedeutet, wir wären in 39 Jahren fertig – das funktioniert so nicht. Lukas, korrigiere mich, aber damals habt ihr gesagt, dass ihr einen Plattform-Ansatz braucht. Ihr wolltet weg von der projektbasierten Organisation, stattdessen Gemeinsamkeiten konsolidieren und eine einheitliche technische Infrastruktur schaffen. So lassen sich Use Cases schneller und parallel umsetzen. Andernfalls wäre man entweder zu langsam oder viele, vermeintlich kleine Use Cases würden gar nicht realisiert, weil sie nie eine Projektfreigabe erhalten. Das war die Ausgangssituation. Wir haben uns damals als Anbieter vorgestellt, und ihr hattet bereits Erfahrungen mit verschiedenen Open-Source-Tools gesammelt. Also haben wir beschlossen, einen Proof of Concept (PoC) zu machen: Innerhalb von drei Monaten wollten wir die ersten drei Use Cases umsetzen. Tatsächlich waren wir nach zwei Monaten fertig und haben dann das Go erhalten, um auf dieser stabilen Basis weiterzuarbeiten.

Genau darum geht es – eine Smart Factory ist nie fertig, sondern befindet sich in kontinuierlicher Entwicklung. Heute, nach fast zwei Jahren gemeinsamer Arbeit, haben wir operativ schon viel erreicht.

Danke, dass ihr eure Erfahrungen hier im Podcast teilt! Es ist spannend, aus der Praxis zu lernen und über Best Practices zu sprechen – besonders, weil viele Unternehmen vor ähnlichen Herausforderungen stehen. Ich habe noch eine Frage: Ihr sprecht von 78 Use Cases. Lukas, du hast anfangs gesagt, es geht um Prozessoptimierung, Transparenz usw. – aber was genau versteht ihr unter einem Use Case?

Lukas

Gute Frage! Die Definition eines Use Cases kann variieren. Bei uns entspricht ein Use Case letztlich einer Anforderung – mal von einer gesamten Organisation, mal von einer einzelnen Person –, die sich mithilfe von IoT lösen lässt. Ein Use Case kann sehr klein sein, beispielsweise eine einzelne Kennzahl visualisieren, oder sehr groß, wie ein umfassendes Tracking-System in der Logistik. Unsere Erfahrung zeigt, dass es eine Vielzahl an Use Cases gibt – die Liste ist inzwischen vermutlich sogar noch länger. Deshalb liegt unser Fokus darauf, eine belastbare Dateninfrastruktur bereitzustellen. Wir können nicht jeden Use Case einzeln und nacheinander lösen, sondern brauchen eine technische Grundlage, mit der sich neue Anforderungen schnell und effizient umsetzen lassen. Schließlich entstehen ständig neue Technologien, Ideen und Veränderungen, sodass ein sequenzieller Ansatz nicht praktikabel wäre.

Danke für die Klarstellung! Ihr meint also mit Use Cases konkret Anforderungen, die intern gestellt werden und mit IoT einen Mehrwert schaffen – sei es durch mehr Transparenz oder Effizienzsteigerung. Interessant finde ich auch, dass Intralogistik nicht nur die Produktion im Werk betrifft, sondern auch andere Wertströme, die ihr übergreifend betrachtet.

Lukas

Genau! Oft startet man mit einzelnen Produktionsprozessen, aber die wirklich spannenden Use Cases entstehen, wenn sie übergreifend wirken und mehrere Bereiche miteinander vernetzen.

Peter

Genau das ist der Punkt, an dem wir eine signifikante Verschiebung sehen. Maschinen zu vernetzen, Daten aus einer Steuerung oder einem Sensor auszulesen, auf einem Dashboard anzuzeigen oder in eine Datenbank zu schreiben – das ist nichts Neues. Das wurde bereits vor 20 oder 30 Jahren gemacht. Das Problem war lange Zeit die siloartige, projektgetriebene Herangehensweise. Niemand hat absichtlich Datensilos geschaffen, aber wenn ein Unternehmen beispielsweise eine Qualitätsmanagement-Datenbank aufbaut, dann wird dafür eine spezialisierte Software gekauft, die ausschließlich Qualitätsdaten verwaltet. Instandhaltungs- oder Energiedaten werden dort nicht erfasst – und schon entsteht ein weiteres Datensilo. Das Umdenken bei Liebherr setzt genau hier an: Statt isolierter Systeme verfolgen wir einen integrierten Plattformansatz. Dadurch lassen sich Use Cases übergreifend umsetzen. Ein Beispiel: Wird bereits ein Traceability-System implementiert, kann ein weiteres Erfordernis – etwa Energiemanagement – direkt darauf aufbauen. So fällt der Carbon Footprint praktisch kostenlos mit ab, da die relevanten Daten bereits vorhanden sind und nur noch zusammenfassen muss. Genau das ist die große Stärke eines gewerkeübergreifenden Denkens.

Bevor wir auf die technische Architektur eingehen, bleiben wir noch kurz bei der organisatorischen Seite – die finde ich in diesem Projekt besonders spannend. Liebherr verfolgt hier ja einen ganzheitlichen Ansatz. Ich würde gerne Best Practices zur Organisationsstruktur und zum Change-Management besprechen. Lukas, wie seid ihr gestartet? Wie ist eure Organisationsstruktur aufgebaut, sodass Use Cases wie Traceability umgesetzt werden können? Was passiert, wenn jemand mit einer neuen Anforderung auf euch zukommt? Kannst du das einmal erklären?

Lukas

Genau, das hat sich bei uns im Laufe der Zeit verändert. Am Anfang mussten wir uns erst einmal einen Überblick verschaffen: Welche Anwendungsfälle gibt es überhaupt? Wir sind wissenstechnisch quasi bei Null gestartet – nicht nur die Organisation, sondern auch wir selbst in der IT. Anfangs hatte das Ganze einen klaren Projektcharakter: Große Workshops, gezielte Suche nach Use Cases, direkte Ansprache der Fachbereiche. Natürlich wurde das Thema nicht allein von der IT vorangetrieben – die Ideen kamen aus den Fachbereichen selbst. Unser Ziel war es, alle mit einzubeziehen und nicht nur einzelne Abteilungen zu betrachten, sondern eine bereichsübergreifende Sichtweise zu entwickeln. Mittlerweile läuft es andersherum: Die Fachbereiche kommen aktiv auf uns zu, präsentieren Ideen und Anforderungen und fragen, ob eine Umsetzung möglich ist. Dieser Wandel fand in dem Moment statt, als wir das nötige Know-how aufgebaut hatten – sowohl technologisch als auch organisatorisch. Die Fachbereiche wissen jetzt, dass wir Lösungen bereitstellen können, und kommen gezielt mit Anfragen auf uns zu.

Nur eine kurze Zwischenfrage: Mit Know-how meinst du das Wissen über Technologien und Lösungen, also beispielsweise welche Systeme ihr nutzt oder welche Lösungen bei euch im Einkauf gelistet sind? Bedeutet das, dass ihr inzwischen genau abschätzen könnt, welche Use Cases sich mit welchen Technologien umsetzen lassen und welche Daten dafür erforderlich sind?

Lukas

Genau, gleichzeitig geht es aber auch darum, Use Cases auf einer Zeitschiene einzuordnen. Viele Ideen sind grundsätzlich umsetzbar, aber die Frage ist, ob sie zum jeweiligen Zeitpunkt sinnvoll realisierbar sind. Manche Use Cases sind technologisch ihrer Zeit voraus oder passen noch nicht in die bestehende Strategie. Zudem sind Ressourcen begrenzt, sodass wir Prioritäten setzen müssen.

Also steckt dahinter auch ein Projektmanagement mit entsprechender Priorisierung? Okay, Peter, eine Frage an dich: Ihr arbeitet mit vielen Unternehmen wie Liebherr zusammen. Siehst du ein allgemeines Muster, dass sich Organisationen zunehmend in diese Richtung entwickeln, oder ist das speziell bei Liebherr der Fall? Wie ist deine Einschätzung?

Peter

Gute Frage! Tatsächlich sehen wir Unternehmen, die wir als Frontrunner bezeichnen – also diejenigen, die Industrie 4.0 nicht als Innovationsprojekt, sondern als geschäftskritische Transformation betrachten und bereits in der Lage sind, sie auszurollen. Sei es an einem Standort oder sogar standortübergreifend. Diese Unternehmen haben erkannt, dass Digitalisierung in der Produktion kein primäres Technologieproblem ist, sondern in erster Linie ein organisatorisches Problem. Firmen, die sich schwertun, kämpfen oft mit einer tiefen Kluft zwischen OT und IT. Aus IT-Sicht ist OT der Bereich, der Sicherheitsstandards nicht einhält. Aus OT-Sicht ist IT der Feind, der die Firewall nicht öffnet. Diese beiden Seiten müssen erst einmal eine gemeinsame Sprache finden und an einem Tisch sitzen. Was kann OT besonders gut? OT kennt die Maschinen in- und auswendig – ihre Prozesse, Einstellungen, Rüstzeiten und Instandhaltung. IT wiederum ist darauf spezialisiert, Technologie effizient und in großem Maßstab bereitzustellen. In der Smart Factory geht es nicht mehr darum, sich ein Jahr lang mit der Entwicklung eines einzelnen Use Cases zu beschäftigen. Vielmehr muss die technologische Grundlage geschaffen werden, um in hoher Taktung kontinuierlich neue Digitalisierungsanwendungen umzusetzen. Ein Use Case kann winzig sein, etwa wenn eine Maschine automatisch eine Störungsmeldung an die Instandhaltung sendet. Oder er kann riesig sein, wie die Einführung eines cloudbasierten MES oder die Ausstattung von Werkern mit digitalen Assistenzsystemen. Ohne die Professionalität und Governance einer IT-gestützten Herangehensweise gerät das schnell außer Kontrolle – einfach weil es zu viel wird.

Ja, das bringt uns zu einer interessanten Frage: Was kommt zuerst – der Use Case oder die Organisationsstruktur? Eine Zeit lang war das eine große Debatte. Ich hatte mal eine Folge dazu gemacht: Kommt zuerst die Connectivity oder der Use Case? Jetzt kommt mit der Organisationsstruktur noch eine weitere Dimension dazu. Viele Unternehmen stehen genau vor dieser Herausforderung. Deshalb finde ich es spannend zu sehen, wie Lukas und sein Team sich intern aufgestellt haben – als Berater, aber auch als Umsetzer, um solche Projekte tatsächlich auf die Straße zu bringen. Gibt es Best Practices, die du Unternehmen in einer ähnlichen Situation empfehlen würdest? Was sollte man auf jeden Fall tun?

Peter

Ich sehe in Unternehmen alle möglichen Extreme. Es gibt Firmen, die haben über Jahre Change-Management-Beratung von großen Namen wie PwC erhalten und am Ende eine 30- bis 40-köpfige, standort- und funktionsübergreifende Projektorganisation aufgebaut – quasi ein Digital Enabler. Das funktioniert, ist aber extrem aufwendig und teuer. Am anderen Ende des Spektrums gibt es Unternehmen, in denen eine einzige Person – oft jemand, der gerade noch seine Masterarbeit im Unternehmen geschrieben hat – von der Geschäftsführung beauftragt wurde: Du bist jetzt unser Digital Owner, kümmere dich darum! Das ist die Minimalvariante. Lukas, ich würde sagen, ihr liegt irgendwo dazwischen. Alle Ansätze können funktionieren, je nach Organisation – je nachdem, ob es um mehrere Standorte geht oder wie groß das Unternehmen ist. Wichtig ist aber ein klarer Transformationsauftrag von der Geschäftsführung. Ob CEO, CIO oder COO – es braucht jemanden, der wirklich dahintersteht und sagt: Wir müssen uns darauf vorbereiten, datengetrieben zu produzieren. Dafür muss auch ein entsprechendes Budget bereitgestellt werden. Ein Plattformansatz hat einen entscheidenden Nachteil: Der initiale Aufbau ist eine Investition. Ich vergleiche das oft mit einer Autobahn – sobald sie steht, kann man schnell und effizient in alle Richtungen fahren. Doch der Bau selbst erfordert erstmal Zeit und Geld. Wer bei diesem Investitionsaufwand sofort nach einem direkten ROI fragt, landet schnell in einer Sackgasse. Das sehen wir häufig in klassischen Industrieeinkaufsprozessen, wo es noch immer schwerfällt, in Softwarelösungen zu investieren. Das sind die Muster, die wir beobachten.

Lukas, eine Frage an dich: Viele, die diesen Podcast hören, sind mitten in der Umsetzung – ähnlich wie du. Sie treiben Use Cases in ihren Organisationen voran. Hast du bestimmte Fallstricke oder No-Gos erlebt, auf die man unbedingt achten sollte? Was hast du in deiner Rolle gelernt, das du hier teilen kannst?

Lukas

Ein wichtiger Punkt, bei dem wir Lehrgeld gezahlt haben, ist das Wartungsmanagement. Anfangs klingt alles vielversprechend – man präsentiert innovative Lösungen, führt erste Workshops und Ideengespräche. Doch von der ersten Idee bis zur tatsächlichen Umsetzung vergeht Zeit, vor allem wenn man bei Null startet. In dieser Phase verlieren manche das Interesse – besonders jene, die ohnehin skeptisch waren. Sie später wieder ins Boot zu holen, ist schwierig. Deshalb ist es entscheidend, von Anfang an transparent zu kommunizieren, was realistisch möglich ist. Eine Organisation, die gerade erst mit Digitalisierung beginnt, kann im ersten Jahr nicht sofort einen KI-gestützten, vorausschauenden Wartungsprozess implementieren. Es handelt sich um eine Evolution – und genau das muss von Anfang an klar sein.

Noch eine technische Frage: Du hast vorhin die zentrale IT angesprochen. Wenn wir über IT-Infrastruktur sprechen, gibt es oft zwei Ansätze: Entweder ein zentral gemanagtes System mit einheitlichen Standards, klaren Richtlinien und zentraler Steuerung – oder eine dezentrale Struktur, bei der einzelne Werke eigenständig Entscheidungen treffen, etwa weil sie alt oder besonders sind. Peter hat vorhin das Thema Silo-Applikationen angesprochen, die in unterschiedlichen Systemen laufen. Wie geht ihr mit dieser Herausforderung um? Habt ihr das in eurem Projekt auch erlebt?

Lukas

Definitiv. Wir nutzen beispielsweise zentrale Service-Connectoren, die in der IT verankert sind. Damit gelten auch alle IT-Governance-Regeln, um einen sauberen und reibungslosen Betrieb sicherzustellen.

Also haltet ihr euch an die einheitlichen Standards, die ihr intern definiert habt – auch in Abstimmung mit dem Einkauf?

Lukas

Genau, das betrifft den Einkauf und alle administrativen Prozesse drumherum. Auf der OT-Seite hingegen ist deutlich mehr Flexibilität gefragt, da jede Anlage unterschiedliche Voraussetzungen hat. Wir setzen zwar ein standardisiertes Edge-Gerät ein, das wir selbst entwickelt haben, aber die Schnittstelle zwischen standardisierten und flexiblen Bereichen muss klar definiert sein. Meiner Meinung nach ist es wichtig, an bestimmten Punkten Flexibilität zuzulassen – aber ebenso entscheidend ist es, genau festzulegen, wo der Übergabepunkt liegt und ab wann Standardisierung greift. Ob man dann ein Edge-Gerät nutzt oder eine SPS eines bestimmten Herstellers über OPC UA integriert, ist zweitrangig. Entscheidend ist, dass das Gesamtsystem integrierbar und skalierbar bleibt. Dann kann man flexibel entscheiden, welche Prozesse zentral gesteuert werden und wo eine dezentrale Steuerung sinnvoll ist.

Spannend! Noch eine Frage an dich, Peter: Wie siehst du das Verhältnis zwischen zentraler Governance und der Freiheit, Dinge dezentral zu steuern? Wo siehst du die richtige Balance?

Peter

Das ist wahrscheinlich der größte Knackpunkt der IT/OT-Konvergenz. Und dabei reden wir hier nur über einen Standort – bei mehreren Standorten wird es noch schwieriger. Nichts sorgt für mehr Widerstand als eine Group-IT, die Vorschriften macht. Ein Kunde hat das mal ganz treffend Freedom in the Box genannt. Die IT muss unternehmensweit Standards und mindestens Konventionen für Datenmodelle definieren: Wie werden Daten benannt? Nach welcher Hierarchie werden sie strukturiert? Ohne solche Vorgaben lassen sich Use Cases nicht skalierbar wiederverwenden, und unkontrollierter Wildwuchs entsteht. Gleichzeitig hat jeder Bereich seine eigene Digitalisierungsagenda. Die IT ist keine treibende Kraft, die Digitalisierung durchdrückt, sondern eine Support-Organisation. Sie stellt als Shared Service die benötigte Infrastruktur bereit, um den internen Kundenbedarf zu erfüllen. Ich formuliere es immer so: Die IT muss alles zentralisieren, was notwendig ist, um eine gewisse Qualität zu gewährleisten. In dem Moment, in dem Lukas’ Kunden anfangen, sich auf die Daten zu verlassen, und er diese plötzlich nicht mehr bereitstellt, wird sein Telefon klingeln. Dann geht es nicht mehr nur um Daten, sondern um Service Level Agreements (SLAs). Damit SLAs eingehalten werden können, braucht es klare Standards. Gleichzeitig muss sichergestellt sein, dass IT-Lösungen genau das bieten, was die internen Kunden tatsächlich benötigen.

Das macht total Sinn! Ich sehe das auch bei anderen Unternehmen: IT sollte eng mit dem Einkauf verzahnt sein. Die Abhängigkeiten sind so komplex, dass man sie erst einmal richtig verstehen muss. Vielleicht sollte der Einkaufsansatz generell erweitert werden.

Peter

Wie läuft das bei euch? Einige unserer Kunden haben ihr Procurement und Ausschreibungswesen in die Digitalisierungsstrategie integriert. So wird sichergestellt, dass neue Maschinen oder Systeme mit der bestehenden Infrastruktur kompatibel sind – damit das nächste MES nicht plötzlich sein eigenes Gateway mitbringt und Insellösungen entstehen. Wenn man alle relevanten Abteilungen frühzeitig einbindet, kann man wirklich eine Smart Factory aus einem Guss schaffen. Habt ihr diesen Ansatz auch bei euch verfolgt?

Lukas

Ja, bei uns war das in der Vergangenheit etwas anders. Wenn eine neue Anlage angeschafft wurde, war die IT oft erst ganz am Ende involviert – wenn es darum ging, sie anzuschließen. Das hat sich inzwischen komplett gewandelt. Das Bewusstsein ist gestiegen, dass die IT frühzeitig eingebunden werden muss. Das gilt nicht nur für Maschinen, sondern auch für Applikationen. IT ist heute nicht mehr nur Dienstleister, sondern spielt eine zentrale Rolle bei der Umsetzung und Standardisierung. Spätestens wenn eine Cloud-Software nicht genutzt werden kann, weil ein Sicherheitsaspekt nicht erfüllt ist, merkt man, wie wichtig es ist, die IT von Anfang an einzubeziehen. Wir sind inzwischen immer involviert – auch bei physischen Anschaffungen wie Maschinen. Dabei bringen wir unsere Expertise gegenüber den Lieferanten ein: Was ist technisch möglich? Was kann der Hersteller tatsächlich liefern? Gerade im Sondermaschinenbau gibt es nicht immer standardisierte Lösungen. Aber unser Ziel ist es, eine langfristige Lösung zu finden – damit eine Anlage, die 10, 15 oder 20 Jahre in Betrieb ist, auch über ihre gesamte Lebensdauer hinweg datentechnisch angebunden bleibt.

Sehr spannend! Übrigens, wenn ihr den Podcast hört und dazu Gedanken habt, lasst es uns wissen. Wie geht ihr mit diesem Thema in eurer Fertigung oder eurem Betrieb um? Schreibt es gerne in die Kommentare oder kontaktiert uns über LinkedIn – die Links findet ihr in den Show Notes. Ich bin gespannt auf eure Erfahrungen!

Jetzt zum Abschluss noch ein Blick auf die eigentliche Implementierung. Ihr habt irgendwann entschieden: Make or Buy – und euch für Cybus entschieden. Wenn ich es richtig verstanden habe, gab es zuerst ein internes Projekt, das erfolgreich lief. Anschließend habt ihr beschlossen, weiter zusammenzuarbeiten, statt eine eigene Lösung zu entwickeln.

Lukas

Genau. Unser genereller IT-Ansatz ist, bestehende Marktprodukte zu nutzen, wenn sie unsere Anforderungen erfüllen. Nach dem erfolgreichen PoC haben wir uns für Cybus entschieden und nutzen es seither als Integrationsplattform für unsere Daten. Unsere standardisierten Edge-Geräte verbinden Anlagen und Montagesysteme mit der IT-Sicherheit. Für Endanwender setzen wir aktuell auf eine Open-Source-Architektur, um die Kosten im aktuellen Stadium gering zu halten. Gleichzeitig integrieren wir die Plattform in bestehende Systeme wie MES und ERP – die typischen Daten-Silos, die es in vielen Unternehmen gibt.

Okay, eine kurze Nachfrage: Du hast vorhin eure Edge-Computer bzw. die OT-Anbindung erwähnt. Ihr nutzt eine intern entwickelte Box, richtig? Ich glaube, Matthias Morath hatte das in einer früheren Podcast-Folge schon mal angesprochen. Wie heißt die genau?

Lukas

Offiziell heißt sie Liebherr IoT-Cabinet oder einfach IoT-Box. Sie dient als zentrale Schnittstelle und ermöglicht die Übergabe von Daten, indem sie Flexibilität mit Standardisierung auf Daten- und Protokollebene verbindet.

Okay, ich packe den Link dazu in die Show Notes – schaut gerne mal rein, dann könnt ihr euch die IoT-Box genauer anschauen. Von der Architektur her übernimmt die Box unter anderem die Datenerfassung. Die Daten fließen dann in Cybus Connectware, die als zentrale Middleware dient. Daran angebunden sind eure Enterprise-IT-Systeme, aber auch Open-Source-Tools und andere Lösungen, die ihr nutzt, richtig?

Lukas

Genau! Zum Beispiel für Dashboarding, wenn es nicht in bestehenden Applikationen enthalten ist. So können wir flexibel Reports und Live-Dashboards erstellen.

[30:15] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen

Cool! Peter, eine Frage an dich: Cybus Connectware – was macht sie besonders? Es gibt ja viele Möglichkeiten, manche Unternehmen setzen eigene Lösungen ein. Was unterscheidet eure Plattform?

Peter

Wir haben im Wesentlichen versucht, die technischen Aspekte der Datensammlung, Normalisierung und Verteilung in ein Produkt zu überführen – insbesondere in eine Konfigurationsumgebung. Ein typischer Fall ist zum Beispiel das Einsammeln von Daten von einem OPC UA Server. Diese kommen in dem Format an, das der Server vorgibt, das kann eine Companion-Spezifikation sein, aber die sieht etwa im Kunststoff-Spritzgussbereich oder in der Zerspanung auch unterschiedlich aus. Auch die Liebherr IoT-Box hat ihren eigenen Namespace. Das erste Ziel ist also das Sammeln der Daten. Anschließend müssen diese Daten auf einen einheitlichen Standard gemappt werden, also auf einen Unified Namespace mit einer einheitlichen Struktur und einem einheitlichen Datenmodell. So können etwa zwei Zerspanungsmaschinen unterschiedlicher Hersteller identisch repräsentiert werden. Der dritte Schritt ist die Verteilung der Daten. Das kann rein über MQTT erfolgen – wir haben dafür einen skalierbaren Industrie-MQTT-Broker integriert. Allerdings sind viele MES-Systeme oder Enterprise-IT-Anwendungen keine nativen MQTT-Clients, sondern nutzen eigene Datenbanken. Daher müssen die Daten dorthin übertragen werden. Diese drei Aufgaben – Sammeln, Normalisieren und Verteilen – haben wir in einem Produkt kombiniert, das insbesondere IT-Abteilungen entgegenkommt. Unsere Software ist speziell darauf ausgelegt, hochautomatisierbar zu sein. Grundsätzlich sehen wir zwei Ansätze: Low-Code, wie etwa Node-RED, das sich gut für schnelles Prototyping und die Anbindung einzelner Maschinen eignet, aber bei großen Skalierungen an Grenzen stößt. Und Infrastructure-as-Code, bei dem Konfigurationen skriptbar, automatisierbar und versionierbar sind. Das ist besonders für Unternehmen mit vielen Shopfloor-Assets entscheidend. Während es für ein kleineres Werk noch funktionieren kann, jede Maschine manuell zu konfigurieren, ist das bei 20.000 Maschinen nicht mehr praktikabel. Mit einem Infrastructure as Code-Ansatz kann eine IT-Abteilung mit wenig Personal dennoch komplexe Datenorchestrierungsprozesse verwalten und stabil bereitstellen.

Cool! Und Lukas, arbeitest du direkt mit dem Tool oder läuft das eher im Hintergrund? Nutzt du es operativ?

Lukas

Ja, auf jeden Fall! Um Peters Punkt noch einmal zu unterstreichen: Einer der größten Vorteile der Anwendung ist, dass wir automatisierbare Konnektivität nutzen können. Wir müssen nicht für jede einzelne Anlage manuell Services konfigurieren – die sehen ohnehin alle gleich aus, weil sie vorher standardisiert wurden. Diese Automatisierung funktioniert hervorragend und bietet uns einen großen Vorteil: Wir müssen nicht ständig direkt mit dem System arbeiten, sondern können über Standard-IT-Tools interagieren, mit denen wir Software verteilen oder Systeme automatisieren.

Stark! Das bedeutet also, wenn eine neue Person zu euch kommt und einen neuen Use Case oder eine neue Anforderung hat, könnt ihr sofort prüfen, ob die benötigten Daten bereits vorhanden sind oder ob neue Daten erfasst werden müssen. Dann setzt ihr den Use Case über Connectware gemeinsam mit den Kollegen um, richtig?

Lukas

Genau! Und im besten Fall, wenn eine neue Anlage hinzukommt und wir ein neues Edge-Gerät anlegen müssen, reicht ein Klick: Hostname eingeben, und der Prozess läuft automatisch durch – inklusive Datenbankanbindung. Das macht das System extrem attraktiv.

Fantastisch! Vielleicht sollten wir uns das mal live anschauen. Falls ihr als Zuhörer das System ebenfalls sehen möchtet, findet ihr die Kontaktdaten von Peter und Lukas in den Show Notes. Nehmt gerne Kontakt auf und lasst euch das System zeigen. Jeder Use Case ist natürlich individuell, aber ihr seid offen für Anfragen, oder?

Peter

Definitiv! Wir haben verschiedene Demos mit simulierten Daten, die wir jederzeit zeigen können. Zudem gibt es Kunden, die als Referenz zur Verfügung stehen. Ich will Lukas nicht mit zu vielen Anfragen überfordern, aber wir freuen uns über jeden, der das Thema besser verstehen möchte. Manchmal könnten wir fast Eintritt dafür verlangen – aber wir freuen uns immer über Interesse!

Ansonsten seid ihr herzlich eingeladen, unserer Community beizutreten. Dort könnt ihr Best Practices austauschen – Liebherr ist ebenfalls vertreten, aber auch viele andere Unternehmen. Es ist eine gute Gelegenheit, Erfahrungen zu teilen und sich insbesondere im IT-Bereich über Herausforderungen und Lösungen auszutauschen. Ich habe noch unzählige weitere Fragen im Kopf, aber für heute würde ich die Session hier abschließen. Ich glaube, wir haben einen sehr guten Einblick bekommen – sowohl in die Anforderungen und Best Practices beim organisatorischen Wandel als auch in die konkrete Umsetzung von Use Cases mit Cybus Connectware und euren Gateways. Von meiner Seite ein großes Dankeschön an euch beide! Danke, dass ihr heute dabei wart!

Lukas

Vielen Dank für die Einladung! Es hat wirklich Spaß gemacht, über dieses Thema zu sprechen – ich könnte ewig weitermachen. Gut, dass wir eine zeitliche Begrenzung haben, sonst würde ich wahrscheinlich bis in die Nacht hier sitzen. Es macht immer wieder Spaß!

Peter

Auch von mir vielen Dank, Lukas! Ich finde es beeindruckend, was ihr in den letzten zwei Jahren umgesetzt habt. Ihr gehört zu den wenigen Unternehmen, die wirklich so weit sind. Nach zehn Jahren Industrie 4.0 muss ich leider feststellen, dass es immer noch nicht selbstverständlich ist. Viele Firmen tun sich schwer damit, aber ihr seid ein echtes Vorbild. Ihr könnt Use Cases inzwischen in wenigen Tagen umsetzen, anstatt in mehreren Monaten – das ist ein großer Schritt! Ihr seid für mich definitiv ein leuchtendes Beispiel.

Sehr schön! Dann nochmals vielen Dank euch beiden – und euch allen eine schöne Restwoche. Macht’s gut!