Abhängigkeit von Anbietern – Vendor Dependency oder Anbieterabhängigkeit – bezeichnet den Grad, in dem eine Organisation in ihrer Funktionsfähigkeit, Entscheidungsfreiheit oder Kostenstruktur von einem externen Anbieter abhängt. Hohe Anbieterabhängigkeit bedeutet, dass der Anbieter Preise erhöhen, Service degradieren oder Bedingungen ändern kann, ohne dass die Organisation kurzfristig ausweichen kann – weil der Wechselaufwand zu hoch ist. Anbieterabhängigkeit ist verwandt mit Lock-in, geht aber weiter: Sie beschreibt nicht nur die Wechselschwelle, sondern auch die operative Abhängigkeit im täglichen Betrieb.
In Automatisierungsinfrastrukturen ist Anbieterabhängigkeit strukturell unvermeidbar: Jede Integration erzeugt eine Abhängigkeit. Das Ziel ist nicht die Eliminierung aller Abhängigkeiten, sondern das bewusste Management: Welche Abhängigkeiten sind akzeptabel? Welche erfordern Mitigierung? Und für welche brauchen wir eine Exit-Option?
Abhängigkeitsstufen nach Kritikalität
Kritisch Anbieter-Ausfall stoppt Kerngeschäft sofort: Primäre Workflow-Engine, Produktionsdatenbank, Haupt-Cloud-Anbieter. Muss Redundanz, Fallback und BCM-Plan haben. Keine Produktionssysteme ohne Ausweichoption.
Hoch Anbieter-Ausfall führt zu signifikanter Betriebseinschränkung: KI-API, primärer E-Mail-Dienst, Monitoring-Tool. Fallback-Anbieter identifiziert, Wechsel in Tagen möglich. Regelmäßige Bewertung der Anbieter-Stabilität.
Mittel Anbieter-Ausfall ist störend aber beherrschbar: Sekundäre Integrations-APIs, ergänzende Tools. Manueller Workaround für begrenzte Zeit möglich. Wechsel in Wochen realisierbar.
Niedrig Anbieter-Ausfall hat minimale operative Auswirkung: Komfort-Tools, nicht-kritische Ergänzungen. Wechsel jederzeit möglich ohne Betriebsunterbrechung. Kein aktives Risikomanagement nötig.
Anbieterabhängigkeiten reduzieren
- Multi-Vendor-Strategie: Für kritische Dienste zwei Anbieter parallel qualifizieren. Nicht notwendigerweise beide gleichzeitig aktiv – aber der zweite ist getestet und bereit
- Abstraktionsschichten: Direkte API-Calls nicht überall im Code – stattdessen Adapter/Wrapper, die einen einfachen Anbieterwechsel ermöglichen ohne die gesamte Geschäftslogik zu ändern
- Open-Source bevorzugen: Bei gleicher Funktionalität Open-Source-Lösungen vorziehen: kein Anbieter kann den Dienst einstellen, und Self-Hosting ist immer möglich
- Datenportabilität sicherstellen: Alle gespeicherten Daten müssen exportierbar sein – in Standardformaten, ohne Einschränkung. DSGVO Art. 20 schreibt Datenportabilität vor
Praxisbeispiel
Ein Automationsdienstleister stellt fest, dass 80 Prozent seiner Produktionsinfrastruktur auf einer einzigen AWS-Region läuft. Anbieterabhängigkeits-Analyse: AWS als Haupt-Cloud: kritische Abhängigkeit. n8n Cloud: hohe Abhängigkeit. Stripe (Zahlungen eines Kunden): kritische Abhängigkeit ohne Fallback. HubSpot API: mittlere Abhängigkeit. Mitigierungs-Roadmap: AWS: Multi-AZ-Deployment sofort, Multi-Region-Failover Q3. n8n: Self-hosted Backup-Instanz aufgesetzt, kann in 15 Minuten aktiviert werden. Stripe: Zahlungs-Abstraktionsschicht implementiert, PayPal als Fallback-Integration bereit. HubSpot: Adapter-Layer erstellt, Salesforce als getestete Alternative. Ergebnis: Kritische Abhängigkeiten von 3 auf 0 reduziert. Alle Fallbacks in den letzten 3 Monaten mindestens einmal erfolgreich getestet.
