.jpg){kind=avatar}
Als die Reise Anfang 2019 losging, erschien alles glasklar: Die ERP-Migration in die Cloud hatte man gerade verdaut. Ein teures, aber notwendiges Übel, um angesichts des ewigen Technologiewandels die Nase vorne zu halten.
Dahingehend strahlte das nächste Großprojekt einen ganz anderen Reiz aus. Eine Investition in die Zukunftsfähigkeit des Unternehmens. Die eigene Fertigung, ein Paradebeispiel datengetriebener Effizienz. Die Einführung einer Industrial IoT (IIoT)-Plattform sollte den Einzug des mittelständischen Automobilzulieferers in eine neue Ära zementieren.
Als mittelständischer Automobilzulieferer in die Industrie 4.0-Ära
Die Zerspanung, die Stanzautomaten und die Presse sollten alle auf OPC-UA-Standard nachgerüstet werden, damit man einheitlich auf diese zugreifen, sie loggen und in einer zentralen Datenbank im Unternehmensnetzwerk abspeichern konnte. Die zentrale Datenbank wiederum sollte über eine Struktur verfügen, die perfekt auf das Unternehmen und dessen Prozesse ausgerichtet ist - wie in unzähligen Workshops, von externen Softwarearchitekten moderiert, mit allen Stakeholdern detailliert ausgearbeitet. Die Integration mit dem etwas in die Jahre gekommenen MES war genau ausdefiniert. Eine perfekte Planung.
Doch vor allem wollte man dieses Mal richtig machen, was im zurückliegenden Projekt für viel Frustration gesorgt hatte. Die Berater des langjährigen Softwarepartners hatten das kostspielige Migrationsprojekt als nahezu alternativlos dargestellt. Eine Zusatzoption hier, eine Anpassung dort - mit jedem Koordinationstreffen im Planungskreis schienen sich die Kosten ein Stück weiter aufzublähen. Nie wieder Vendor-Lock-In. Es stand außer Frage, dass diese Software selbst gebaut werden sollte. Denn besitzt man die Software und ihren Quellcode, ist man frei – frei von Abonnements, frei von absurden Preiserhöhungen und befreit von dem Gefühl, bei jedem Kontakt zum Lieferanten einen Versuch des Upsellings abwehren zu müssen.
Heute blickt man etwas differenzierter auf die 2019 getroffene Entscheidung. Natürlich hatte man die Plattform nicht selbst gebaut. Weder die Kapazitäten noch alle erforderlichen Kompetenzen waren im eigenen Unternehmen vorhanden. Der Auftrag zur Implementierung war nach gründlicher Evaluierung an einen spezialisierten Entwicklungsdienstleister gegangen. Der offerierte Preis im unteren sechsstelligen Bereich blieb sogar unter dem Budget. Die Implementierung wurde sauber umgesetzt, soweit man das beurteilen konnte. Die Software war zwar ordentlich dokumentiert worden, aber so ganz war der Plan nicht aufgegangen, dass die zuständigen Projektleiter und die eigene IT-Abteilung nach Implementierungsende die eigene Software übernehmen konnten. Zu häufig war das Tagesgeschäft während der Implementierung dazwischengekommen, und der Weiterbildung sowie dem Wissenstransfer stand im Weg. Die zwei eingeplanten Spezialistenstellen in der IT konnten während Corona nicht besetzt werden und waren 2023 angesichts rückläufiger Aufträge wieder gestrichen worden.
In den zurückliegenden Jahren hatte die Praxis gezeigt, dass der perfekte Planungsprozess doch nicht in der Lage gewesen war, jede Anforderung im Vorfeld zu antizipieren. Viele kamen hinzu, andere entpuppten sich als unnötig. Umsetzen konnte ausschließlich der Entwicklungsdienstleister. Hinzu kommen die notwendigen Sicherheitsupdates und kleinere Bugfixes. Selbst der interne Support für die Software konnte schlussendlich von der eigenen IT nicht gestemmt werden. Aus Mann-Tagen des Dienstleisters wurden Mann-Wochen und schließlich Mann-Monate. Bis heute hat sich keiner getraut, das tatsächliche Preisschild des Projektes aufzuaddieren.
Der eigene Quellcode – mehr Verbindlichkeit als Vermögenswert
Als Softwareentwickler fühlen wir uns häufig an dem Tag am produktivsten, an dem wir netto eine negative Menge Code geschrieben haben - also mehr Codezeilen gelöscht als geschrieben haben. Denn wir wissen aus Erfahrung: Code kostet. In seiner Wartung. In seiner Bereitstellung. Und in seiner Weiterentwicklung.
Die eigene Unternehmenssoftware selbst zu programmieren, kann Sinn ergeben. Damit Software im Unternehmen ihr Wertversprechen einlösen kann, muss sie schließlich nahezu perfekt auf jene Prozesse abgestimmt sein, die sie vereinfacht, automatisiert oder mit Informationen bereichert. Die Vorstellung, eine Lösung von der Stange könne eine Problematik so abstrahieren, dass sie in verschiedenen Unternehmen anwendbar ist, dabei jedoch hinreichend spezifisch bleibt, um nützlich zu sein, mag in der Buchhaltung zutreffen, wo gesetzliche Vorgaben und Richtlinien eine Vereinheitlichung der Vorgehensweisen der Unternehmensgrenzen hinweg erzwingen. Gerade in der über Jahrzehnte der Optimierung gewachsenen Individualität deiner Fertigung und ihrer Prozesse könnten jedoch entscheidende Wettbewerbsvorteile liegen.
Ich schätze meine Mitgründer und Kollegen für ihren Pragmatismus als Softwareentwickler und ihre Bereitschaft, sich als Berater individuell in Problemstellungen, Prozesse und sogar die Funktionsweise der Maschinen unserer Kunden hineinzuversetzen. Wie im Falle des zuvor erwähnten Entwicklungsdienstleisters dürfen wir einen wesentlichen Teil unseres Umsatzes den individuellen Bedürfnissen unserer Kunden zurechnen. Die vorangegangene Anekdote mag einen Einzelfall beschreiben, jedoch einen, der sich in ähnlicher Form heute in Tausenden von mittelständischen Fertigungsunternehmen bei der Realisierung eigener IIoT-Plattformen im DACH-Raum abspielt.
Innerhalb des Spektrums der Extreme “Buy vs. Build” nehmen wir unter Mittelständlern eine unvorteilhafte Tendenz zur Eigenentwicklung weiterer Teile der eigenen Datenplattform wahr – nachteilig für die Unternehmensfinanzen und den Projekterfolg. Die Ursache verorten wir im Mangel an Transparenz in einem Markt, wo Produktkategorien und ihre Funktionsmerkmale diffus ineinander verschwimmen, gepaart mit der geringen Praxiserfahrung vieler Unternehmen in der Digitalisierung. Im Zuge der Entscheidung, welche Teile deines Lösungskonzepts dein Unternehmen selbst baut oder bauen lässt und welche Standardlösungen ihr als Bausteine dienen, möchte ich dir nahelegen, drei grundlegende Fragen in deinem Evaluierungsprozess zu berücksichtigen.
1. Wo genau liegt die Einzigartigkeit meiner Anforderungen?
„Verbinden, sammeln, speichern, analysieren, visualisieren“ – laut Industrie-4.0-Vordenker Walker Reynolds sind dies die Grundfunktionen, die eine IIoT-Plattform auszeichnen. Doch genau hier setzt die Frage nach der Einzigartigkeit deiner Anforderungen an. In unseren Projekten haben wir auf Basis dieser Grundfunktionalitäten maßgeschneiderte Lösungen für verschiedenste Industrien entwickelt – von der Schwerindustrie bis hin zur Getränkeindustrie. Dabei haben wir unterschiedliche Anwendungsfälle realisiert, wie die Überwachung kritischer Komponenten, Fehlervorhersagen mittels künstlicher Intelligenz, nutzungsbasiertes Abrechnen, Maschinenferndiagnosen und Rezeptemanagement.
Wenn man über die standardisierten IIoT-Plattformen hinausblickt und diese mit den Baukästen von Systemintegratoren vergleicht, erkennt man oft eine ähnliche Technologiewahl und ähnliche Implementierungsentscheidungen. Allerdings bringen Erstere die Kinderkrankheiten einer unerprobten Lösung mit sich und machen keinen Gebrauch von den umfangreichen Erfahrungen, die durch zahlreiche Implementierungen gewonnen wurden. Insbesondere bei den Grundfunktionen wie dem Verbinden, Sammeln und Speichern der Daten sind Robustheit und Sicherheit entscheidend – Aspekte, die stark von Skaleneffekten profitieren. Die notwendige Individualität lässt sich jedoch durch hohe Konfigurierbarkeit erreichen, die es deinen Mitarbeitern ermöglicht, das zugrundeliegende Datenmodell an die Realität deiner Produktion anzupassen und darüber hinaus auch Datensätze jenseits des Standards zu speichern.
Die wahre Einzigartigkeit deiner Lösung zeigt sich meist nur in der proprietären Logik, mit der Daten analysiert und den Nutzern visualisiert werden. Diese Individualität, die in firmeneigenen Algorithmen, Prozessmodellen und Bedieneroberflächen implementiert ist, entspringt einem tiefgreifenden Verständnis deiner eigenen Prozesse und Kundenbedürfnisse. Allerdings macht sie im Gesamtkontext nur einen Bruchteil des Lösungsumfangs aus. Selbst diese individuellen Komponenten greifen bei unseren Kunden stets auf dieselben Grundfunktionalitäten zurück. Daher stellt sich die Frage: Ist es effizient, die eigenen Kapazitäten und Ressourcen zu verwässern, um Module zweitrangiger Qualität auf Kosten der eigentlichen Differentiatoren selbst zu entwickeln?
2. Was kostet die Lösung unterm Strich?
Ein häufiger Irrglaube ist, dass die Eigenentwicklung sich nach wenigen Jahren bereits amortisiert, wenn man den kompetitiven Pauschalpreis mit der Kostenkalkulation einer Standardlösung inklusive notwendiger Anpassungen vergleicht. Doch hierbei muss man genau hinschauen: Sind wirklich alle Kosten eingeplant? Müssen neue Mitarbeiter in spezialisierten Rollen eingestellt werden, um die eigene Lösung betreiben und weiterentwickeln zu können? Oder ist ein Wartungsvertrag erforderlich, der zusätzliche Kosten verursacht?
Oftmals führt der sogenannte „Partner-Lock-In“ in der Praxis zu Mehrkosten, die innerhalb von drei bis fünf Jahren die ursprüngliche Investition erreichen können. Diese zusätzlichen Kosten entstehen durch notwendige Anpassungen, Wartungen und Weiterentwicklungen, die über die anfänglichen Planungen hinausgehen. Es ist wichtig, diese langfristigen finanziellen Auswirkungen zu berücksichtigen, bevor man sich für eine Eigenentwicklung entscheidet. Nur so lässt sich sicherstellen, dass die Lösung nicht nur kurzfristig, sondern auch langfristig wirtschaftlich tragfähig bleibt.
3. Wie kann ich Abhängigkeiten reduzieren, ohne den Standard zu verlassen?
Bei der Evaluierung von Standardlösungen für deine IIoT-Plattform stellt sich die Frage, wie stark diese mit den hochoptimierten Diensten großer Cloud-Anbieter wie AWS, Google oder Microsoft verknüpft sind. Die nahtlose Integration mit den Services dieser Anbieter mag auf den ersten Blick hocheffizient erscheinen, doch schließt sie dich gleichzeitig in Abhängigkeiten ein, die teuer zu lösen sind, wenn du dich in Zukunft entscheiden solltest, den Anbieter zu wechseln. Eine bewusst anbieter-agnostische Plattform bietet den Vorteil, dass du von der Skalierbarkeit und Flexibilität der Cloud-Infrastruktur profitieren kannst, ohne dich langfristig an einen einzelnen Anbieter zu binden.
Ebenso gilt es, die Abhängigkeit zum Plattformanbieter selbst zu hinterfragen. Obwohl nahezu jede Plattform als „offen“ beworben wird, offenbart sich die dahinterliegende Geschäftsstrategie des Anbieters oft erst im Detail. Dient die Plattform dazu, dein eigenes Softwareportfolio in ein größeres Ökosystem einzubetten und lockt mit dem Versprechen eines „One-Stop-Shops“, erhöht sich gleichzeitig die Abhängigkeit? Oder ist die Plattform tatsächlich als sinnvoller Baustein in deiner Lösung gedacht, sodass du die Implementierung selbst nachvollziehen und gegebenenfalls anpassen könntest?
Ein weiterer Aspekt ist die Konfigurierbarkeit und Flexibilität der Plattform. Funktionen wie eine offene Datenschnittstelle, eine eigene Skriptsprache oder die Möglichkeit, eigene Anwendungen als Docker-Container bereitzustellen, sind heutzutage oft indiskutable Anforderungen. Doch entscheidend ist, wie diese Funktionalitäten umgesetzt werden. Der Lackmustest: Würdest du dich entschliessen, morgen den Plattformanbieter auszutauschen, welche Services und eigenen Applikationen, die dein Unternehmen auf dieser Plattform aufgebaut hat, müssten von Grund auf neu geschrieben werden?
"Es geht nicht nur um die digitale Infrastruktur. Digitalisierungsprojekte sind für Unternehmen auch immer eine Chance, das Verständnis der eigenen Mitarbeiter für Daten weiterzuentwickeln."
- Till Schöpe
Till Schöpe hat als "Datenarchitekt" bei Alpamayo mit Startups und Konzernen im Aufbau ihrer digitalen Infrastruktur zusammengearbeitet. Ein wesentlicher Teil seiner Arbeit liegt in der engen Zusammenarbeit mit den Mitarbeitern der Fachabteilungen. Dabei gehe es nicht nur darum, Bestandsaufnahmen zu machen und sich auf die Anforderungen an die Lösung zu einigen. Jedes Unternehmen sei auf unterschiedliche Art in die Umsetzung von Digitalisierung eingebunden, denn jedes Unternehmen starte mit seinen individuellen Strukturen und Kompetenzen. Wichtig sei jedoch, dass Digitalisierungsprojekte bewusst genutzt würden, um die Datenkompetenzen der eigenen Mitarbeiter zu verbessern.
In dieser Denkweise liegt ein Kernunterschied zwischen der Digitalisierung einer Organisation und deren digitaler Transformation: nicht die Technologie steht im Mittelpunkt, sondern die Organisation selbst, und deren Fähigkeit, die Potenziale neuer Technologien voll auszuschöpfen.
