Partner‑Lock‑In statt Vendor‑Lock‑In – pragmatische Plattformstrategien

So senkst du Gesamtkosten, reduzierst Abhängigkeiten und fokussierst auf echte Differentiatoren deiner IIoT‑Plattform.

Partner‑Lock‑In statt Vendor‑Lock‑In – pragmatische Plattformstrategien
Christoph NetschCo‑Founder Alpamayo
1. Juli 2025

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 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.

Drei grundlegende Fragen zur Evaluierung

  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.

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 macht im Gesamtkontext nur einen Bruchteil des Lösungsumfangs aus.

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?

  1. Was kostet die Lösung unterm Strich?

Ein häufiger Irrglaube ist, dass die Eigenentwicklung sich nach wenigen Jahren bereits amortisiert. Doch hierbei muss man genau hinschauen: Sind wirklich alle Kosten eingeplant? Müssen neue Mitarbeiter eingestellt werden, um die Lösung betreiben und weiterentwickeln zu können?

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.

  1. 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.

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.

Ein weiterer Aspekt ist die Konfigurierbarkeit und Flexibilität der Plattform. Der Lackmustest: Würdest du dich entschließen, morgen den Plattformanbieter auszutauschen, welche Services und eigenen Applikationen 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, Datenarchitekt bei Alpamayo

Till Schöpe betont, dass Digitalisierungsprojekte bewusst genutzt werden sollten, 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.