3 Dimensionen von Vendor Lock-in
Technischer Lock-in
Proprietäre Formate, geschlossene APIs, herstellerspezifische Programmiersprachen oder Plattform-Runtime – all das bindet euch technisch an einen Anbieter.
Beispiele
- Daten liegen in proprietärem Format ohne Standard-Export
- Workflows/Automatisierungen nur innerhalb des Ökosystems nutzbar
- Keine offenen APIs oder nur eingeschränkter API-Zugang
- Herstellerspezifische Skriptsprache statt Standard (JavaScript, Python, SQL)
Gegenmaßnahmen
- Offene Standards bei der Auswahl priorisieren (REST, GraphQL, JSON, CSV)
- Datenexport-Möglichkeiten vertraglich festhalten (Format, Vollständigkeit, Frequenz)
- API-Dokumentation vor Vertragsschluss prüfen (nicht nur 'vorhanden', sondern vollständig)
Kommerzieller Lock-in
Langfristige Verträge, steigende Lizenzkosten, migrationshemmende Preismodelle – hier wird die Abhängigkeit über den Geldbeutel erzeugt.
Beispiele
- Mehrjahresverträge mit automatischer Verlängerung und hohen Ausstiegshürden
- Preiserhöhungen ohne Leistungssteigerung ('Inflation Adjustment')
- Kosten für Datenexport oder API-Zugang bei Kündigung
- Rabatte nur bei Commitment auf weitere Jahre/Module
Gegenmaßnahmen
- Vertragslaufzeiten auf maximal 1–2 Jahre begrenzen
- Exit-Klauseln verhandeln: Kosten, Datenherausgabe, Übergangszeitraum
- Preiseskalationsklauseln deckeln (z.B. max. 5% p.a.)
- Total Cost of Ownership vor Vertragsschluss realistisch rechnen
Operativer Lock-in
Eure Prozesse, Schulungen und Organisationsstruktur sind um ein bestimmtes System herum aufgebaut. Ein Wechsel würde massive Disruption bedeuten.
Beispiele
- Alle Mitarbeitenden sind auf ein bestimmtes UI trainiert
- Prozessketten sind auf die Logik des Systems zugeschnitten
- Integrationen mit anderen Systemen laufen über herstellerspezifische Konnektoren
- Reporting und BI-Layer sind direkt an die Datenstruktur gekoppelt
Gegenmaßnahmen
- Prozesse tool-agnostisch dokumentieren (BPMN, nicht 'Klick-Anleitung')
- Integrationsschicht (iPaaS / Middleware) zwischen Systemen einsetzen
- Stammdatenmodell unabhängig vom System definieren (MDM-Ansatz)
- Schulungen auf Prozessverständnis aufbauen, nicht nur auf Klickpfade
Lock-in-Check: Bewertungsmatrix
Nutzt diese Kriterien, um Anbieter in Bezug auf Lock-in-Risiko einzuordnen.
| Kriterium | Niedriges Risiko | Hohes Risiko |
|---|---|---|
| Datenexport (vollständig, maschinenlesbar) | Jederzeit, vollständig, Standard-Formate | Nur auf Anfrage, nur Teilexporte, proprietär |
| API-Zugang | Offene, dokumentierte REST/GraphQL-API inklusive | API als kostenpflichtiges Add-on oder undokumentiert |
| Vertragslaufzeit & Exit | Monatlich/jährlich kündbar, klare Exit-Terms | Mehrjährig, automatische Verlängerung, Exit-Gebühren |
| Datenformat & Modell | Standards (JSON, XML, CSV, EDIFACT), offenes Datenmodell | Proprietäres Binärformat, kein Schema dokumentiert |
| Integrationsfähigkeit | Standard-Konnektoren, Webhook-Support, iPaaS-kompatibel | Nur herstellereigene Konnektoren, kein Webhook-Support |
| Migrationshilfe bei Wechsel | Unterstützung bei Datenübernahme, Dokumentation | Keine Kooperation, Erschwerung des Wechsels |
Häufige Fragen
Anbieterunabhängig entscheiden
Ich unterstütze bei der Bewertung von Lock-in-Risiken, Vertragsverhandlung und der Architektur einer herstellerunabhängigen Systemlandschaft.
Erstberatung anfragen