Vendor Lock-in – Anbieterabhängigkeit – bezeichnet die Situation, in der ein Unternehmen so tief in die Produkte, Technologien oder Dienste eines bestimmten Anbieters integriert ist, dass ein Wechsel zu einer Alternativlösung prohibitiv teuer, zeitaufwändig oder technisch kaum machbar wäre. Lock-in entsteht oft schleichend: Jede Nutzung eines proprietären Features, jede tief integrierte Anbieterfunktion, jede im Anbieterformat gespeicherte Datenmenge erhöht die Wechselbarriere ein Stück weiter.
Vendor Lock-in ist ein strategisches Risiko, das häufig erst dann offenbar wird, wenn es zu spät ist: wenn der Anbieter die Preise erhöht, das Produkt abkündigt, schlechten Support liefert oder aufgekauft wird. In Automatisierungsinfrastrukturen ist Lock-in besonders heikel, weil die Workflow-Logik oft tief in proprietären Konfigurationsformaten steckt und nicht einfach auf eine andere Plattform portiert werden kann.
Lock-in-Risiken nach Kategorie
Hoch Proprietäres Workflow-Format: Logik nur als Klick-Konfiguration in Anbieter-UI – kein Export, kein alternatives Tool kann sie lesen oder ausführen
Hoch Anbieter-spezifische Datenformate: Alle Daten in proprietären Strukturen ohne Exportmöglichkeit – Daten faktisch gefangen
Mittel Tiefe Plattform-Integrations: Hunderte proprietäre Konnektoren ohne standardisierte Alternativen – Migration erfordert alle Integrationen neu zu bauen
Mittel Wissen und Kompetenz: Das gesamte Team kennt nur eine Plattform – Wissenstransfer bei Plattformwechsel aufwändig
Niedrig Standard-APIs: REST-APIs mit offener Spezifikation – können von alternativen Plattformen gleichermaßen genutzt werden
Niedrig Dokumentierte Logik: Workflow-Logik parallel in BPMN oder Pseudocode dokumentiert – Wechsel bleibt möglich
Lock-in bewusst managen
Vollständiger Lock-in-Vermeidung ist oft unrealistisch und auch nicht notwendig: Manche Anbieterabhängigkeiten sind akzeptabel, wenn der Mehrwert die Wechselbarriere überwiegt und der Anbieter verlässlich ist. Entscheidend ist die Bewusstheit: Jede Lock-in-entscheidung sollte explizit als solche getroffen werden – nicht versehentlich durch unreflektierte Nutzung proprietärer Features. Und kritische Geschäftslogik sollte immer plattformunabhängig dokumentiert sein.
Praxisbeispiel
Ein mittelständisches Unternehmen nutzt seit 4 Jahren eine proprietäre Automatisierungsplattform für 120 Workflows. Preiserhöhung des Anbieters: +180 Prozent. Analyse der Wechselkosten: Alle 120 Workflows liegen nur als proprietäre Konfiguration vor – kein Export möglich. Geschätzte Migrationskosten: 340.000 Euro (komplett neu bauen) + 6 Monate Projektlaufzeit. Entscheidung: Preiserhöhung akzeptieren. Gegenmaßnahme für die Zukunft: Alle neuen Workflows werden parallel in einem plattformunabhängigen Dokumentationsformat beschrieben. Bestehende Workflows: Schritt für Schritt dokumentiert, wenn sie ohnehin überarbeitet werden. Ziel: In 18 Monaten sind 80 Prozent aller Workflows so dokumentiert, dass ein Wechsel in 3 Monaten statt 6 möglich wäre.
