Wie Unternehmen unnötige Abhängigkeiten von Werkzeugen vermeiden

Beherrschbarkeit ist wichtiger als die Eigentumsform eines Werkzeugs

Unnötige Abhängigkeit entsteht, wenn ein Anbieter nicht nur eine Funktion bereitstellt, sondern faktisch Eigentümer über Datenzugang, Prozesswissen oder betriebliche Handlungsfähigkeit wird.

Unternehmen reduzieren dieses Risiko durch dokumentierte Zuständigkeiten, exportierbare Daten, offene oder zumindest dokumentierte Schnittstellen, unabhängige Zugänge, nachvollziehbare Verträge und ein realistisches Exit-Szenario. Vollständige Unabhängigkeit ist selten wirtschaftlich. Beherrschbare Abhängigkeit ist das Ziel.

Ausgangslage

Bis Ende 2022 war die digitale Werkzeuglandschaft vieler Unternehmen deutlich gewachsen. Website, Newsletter, CRM, Analyse, Terminbuchung, Projektmanagement, Dateiablage und Kampagnen wurden häufig über spezialisierte Dienste verbunden.

Diese Arbeitsteilung hatte klare Vorteile. Funktionen konnten schneller eingeführt werden. Interne Entwicklung war nicht für jeden Anwendungsfall notwendig. Updates, Sicherheit und Betrieb lagen teilweise beim Anbieter.

Gleichzeitig entstanden Abhängigkeiten, die erst bei einem Wechsel, einer Preiserhöhung, einem Ausfall oder dem Ende einer Dienstleisterbeziehung sichtbar wurden. Zugangsdaten lagen bei Einzelpersonen. Daten konnten nur unvollständig exportiert werden. Automatisierungen waren nicht dokumentiert. Inhalte waren an proprietäre Seitenelemente gebunden. Eine zentrale Funktion hing von einer einzelnen Erweiterung ab.

Das Problem war nicht der Einsatz externer Werkzeuge. Es war die fehlende Architekturentscheidung darüber, welche Teile auslagerbar und welche Grundlagen unternehmenseigen beherrschbar bleiben müssen.

Was hinter dem Problem liegt

Funktion und System werden verwechselt

Ein Werkzeug löst eine konkrete Aufgabe. Ein System verbindet Aufgaben, Daten, Rollen und Übergaben. Wird die Werkzeugentscheidung ohne Systemperspektive getroffen, optimiert jede Abteilung ihren Ausschnitt.

Das CRM passt zum Vertrieb, das Formular zum Marketing und die Website zum aktuellen Design. Ob Datenformate, Einwilligungen, Zuständigkeiten und Schnittstellen zusammenpassen, wird später geklärt. Die Abhängigkeit entsteht dadurch nicht nur zum Anbieter, sondern zur gewachsenen Kombination.

Bequemlichkeit verdeckt Wechselkosten

Ein Dienst kann im Alltag sehr einfach sein und im Wechsel erhebliche Kosten erzeugen. Entscheidend sind nicht nur Lizenzgebühren. Zu den Wechselkosten gehören:

• Datenbereinigung und Migration
• Neubau von Schnittstellen
• Schulung und Prozessanpassung
• Verlust historischer Daten oder Metadaten
• Rekonstruktion undokumentierter Automatisierungen
• technische Nacharbeiten an Website oder Formularen
• vorübergehende Betriebsrisiken

Diese Kosten sind nicht grundsätzlich ein Argument gegen ein Werkzeug. Sie müssen vor der Entscheidung sichtbar sein.

Datenexport wird mit Portabilität gleichgesetzt

Viele Systeme bieten einen Export. Ein Export allein garantiert jedoch keine praktische Wechselmöglichkeit. Daten können unvollständig, schlecht dokumentiert oder in einem Format vorliegen, das Beziehungen und Historie verliert.

Portabilität verlangt deshalb mehr: Welche Daten werden exportiert? Sind Anhänge, Zustände, Zuordnungen und Einwilligungsnachweise enthalten? Können sie in einem anderen System sinnvoll importiert werden? Ist die Struktur dokumentiert?

Wissen bleibt bei Dienstleistern oder Einzelpersonen

Eine technische Lösung kann formal dem Unternehmen gehören und praktisch trotzdem nicht beherrschbar sein. Das geschieht, wenn nur eine externe Person Zugänge, Hosting, Erweiterungen, Schnittstellen oder Sonderlogik kennt.

Abhängigkeit ist dann kein reines Produktthema. Sie ist ein Dokumentations- und Verantwortungsproblem.

Strategische Einordnung

Offene Standards schaffen Wechsel- und Verbindungsmöglichkeiten

Offizielle Leitlinien zu offenen Standards betonen seit Jahren Interoperabilität, Datenaustausch und die Vermeidung unnötiger Anbieterbindung. Offene Standards garantieren keine einfache Migration. Sie erhöhen aber die Chance, dass Systeme über dokumentierte Formate und Schnittstellen verbunden oder ersetzt werden können.

Für Unternehmen bedeutet das nicht, ausschließlich offene Software einzusetzen. Proprietäre Dienste können fachlich und wirtschaftlich sinnvoll sein. Entscheidend ist, ob kritische Daten und Prozesse in verständlichen, zugänglichen Strukturen verbleiben.

Kern und Module müssen getrennt werden

Eine belastbare Architektur unterscheidet zwischen unternehmenseigenem Kern und austauschbaren Modulen.

Zum Kern gehören typischerweise:

• Domains und zentrale Konten
• freigegebene Inhalte und Dateien
• Kunden- und Kontaktdaten im rechtlich zulässigen Rahmen
• Dokumentation von Prozessen und Schnittstellen
• Rollen und Zugriffsrechte
• Messdefinitionen
• vertragliche und technische Nachweise

Module können Hosting, CMS, Newsletter, Terminbuchung, Analyse oder Automatisierung sein. Sie dürfen wichtig sein. Sie sollten den Kern aber nicht unzugänglich machen.

Exit-Fähigkeit gehört zur Auswahlentscheidung

Ein Wechselplan ist keine Ankündigung, den Anbieter bald zu verlassen. Er ist eine Prüfung der eigenen Handlungsfähigkeit.

Vor einer kritischen Einführung sollten Unternehmen klären:

• Welche Daten und Inhalte müssen vollständig exportierbar sein?
• Welche Schnittstellen werden genutzt?
• Wer besitzt administrative Zugänge?
• Welche Vertragsfristen und Zusatzkosten gelten?
• Wie lange kann der Betrieb ohne den Dienst weiterlaufen?
• Welche Ersatzlösung wäre grundsätzlich denkbar?

Diese Fragen verbessern oft bereits die laufende Nutzung.

Perspektive aus der Praxis

Abhängigkeiten werden häufig bei Website-Relaunches sichtbar. Inhalte lassen sich zwar exportieren, aber Seitenstrukturen, Formulare oder individuelle Module fehlen. Das Unternehmen besitzt seine Texte, aber nicht die Funktionslogik.

Ein ähnliches Muster entsteht bei Automatisierungen. Ein Ablauf funktioniert über Jahre. Sobald die verantwortliche Person ausfällt, ist nicht mehr nachvollziehbar, welche Daten an welches System übertragen werden und wie Fehler erkannt werden.

Die praktische Gegenmaßnahme ist keine vollständige technische Eigenentwicklung. Sie ist eine belastbare Mindestdokumentation: Systemzweck, Eigentümer, Zugänge, Datenarten, Schnittstellen, Abhängigkeiten, Sicherung, Kosten, Vertragsfristen und Exit-Möglichkeit.

Die unternehmenseigene Systembasis

Handlungsrahmen

1. Kritikalität bestimmen

Bewerten Sie, welche Werkzeuge für Umsatz, Kundenkommunikation, Website-Betrieb oder Nachweispflichten entscheidend sind. Je kritischer die Funktion, desto höher die Anforderungen an Zugriff, Dokumentation und Wechselmöglichkeit.

2. Administrative Kontrolle sichern

Zentrale Konten, Domains, Hosting und Abrechnung sollten dem Unternehmen zugeordnet sein. Externe Partner erhalten passende Rollen, aber nicht die einzige Kontrolle.

3. Export praktisch testen

Verlassen Sie sich nicht auf eine Funktionsbeschreibung. Führen Sie bei kritischen Systemen einen Testexport durch und prüfen Sie Vollständigkeit, Format und Wiederverwendbarkeit.

4. Schnittstellen dokumentieren

Halten Sie fest, welche Daten wohin fließen, welche Auslöser gelten und wie Fehler erkannt werden. Dokumentieren Sie auch manuelle Übergaben.

5. Exit-Szenario festlegen

Definieren Sie, wie ein geordneter Wechsel ablaufen könnte. Das Szenario muss nicht bis ins letzte technische Detail ausgearbeitet sein. Es muss zeigen, dass Daten, Zugang und Verantwortlichkeit nicht vollständig beim Anbieter liegen.

Was Unternehmen nicht tun sollten

Unternehmen sollten Abhängigkeit nicht allein an Lizenzkosten oder dem Begriff „Cloud“ festmachen. Eine lokal betriebene, undokumentierte Sonderlösung kann stärker binden als ein gut dokumentierter Cloud-Dienst mit offenen Schnittstellen.

Ebenso falsch ist die Annahme, jedes Werkzeug müsse jederzeit ohne Aufwand austauschbar sein. Spezialisierung erzeugt bewusst Abhängigkeiten. Die strategische Frage lautet, ob Nutzen, Risiko und Wechselkosten transparent und verantwortbar sind.

Konsequenz für Unternehmen

Digitale Souveränität entsteht nicht durch den Verzicht auf Anbieter. Sie entsteht durch klare Eigentums-, Zugriffs- und Architekturentscheidungen.

Ein Unternehmen bleibt handlungsfähig, wenn es seine Daten kennt, Prozesse dokumentiert, zentrale Zugänge kontrolliert und Wechselmöglichkeiten realistisch beurteilen kann. Dadurch werden Werkzeuge zu Modulen des Systems, nicht zu dessen Eigentümer.

Fachlicher Anschluss

Systemabhängigkeiten vor Ausbau oder Wechsel prüfen

Eine digitale Systemarchitektur ordnet kritische Daten, Werkzeuge, Schnittstellen, Rollen und Wechselrisiken. SDC-Discovery kann diese Ausgangslage vor einem Relaunch, einer Konsolidierung oder der Einführung neuer Systeme strukturiert erfassen und priorisieren.

Digitale Systemlandschaft und Abhängigkeiten klären

Autor

Über Göke Frerichs

Göke Frerichs verbindet seit 1999 digitale Strategie, Kommunikation, Technologie und Umsetzung. Als Digitalstratege und Smart Digital Creative unterstützt er inhabergeführte B2B-Unternehmen dabei, aus einzelnen Maßnahmen klare und belastbare digitale Systeme zu entwickeln. Seine Perspektive beruht auf langjähriger Beratungs- und Umsetzungspraxis in DACH und Nordamerika.

Mehr über Göke Frerichs