IT funktioniert – bis sie es nicht mehr tut. Solange Systeme laufen und Prozesse nicht ins Stocken geraten, bleibt sie für viele Geschäftsführungen unsichtbar. Das ist nachvollziehbar, denn operative Stabilität signalisiert vermeintlich Kontrolle.
Doch genau in dieser Unsichtbarkeit entstehen Abhängigkeiten, die erst dann sichtbar werden, wenn sie bereits kritisch sind. Ein Administrator, der seit Jahren allein für die gesamte Infrastruktur verantwortlich ist und dessen Wissen nirgends dokumentiert wurde. Ein Cloud-Anbieter, dessen Preismodell sich ändert, während Alternativen fehlen. Strukturen, die über Jahre gewachsen sind, ohne dass jemand sie je systematisch erfasst hätte.
Dieser Beitrag zeigt, wo solche Abhängigkeiten entstehen, warum sie selten rechtzeitig erkannt werden und was das für Entscheider bedeutet, die IT zwar nicht operativ verantworten, aber deren Risiken tragen.
Kontrolle oder Illusion?
Viele Geschäftsführungen gehen davon aus, dass ihre IT unter Kontrolle ist. Es gibt einen Ansprechpartner, Tickets werden bearbeitet, und größere Ausfälle kommen selten vor. Im Alltag reicht das aus.
Kontrolle bedeutet jedoch mehr als funktionierender Betrieb. Sie setzt voraus, dass klar ist, wer für welche Systeme verantwortlich zeichnet, wie Geschäftsprozesse technisch abgebildet sind und was ein Ausfall tatsächlich kosten würde – nicht nur in Stunden, sondern in unternehmerischer Handlungsfähigkeit.
Die Realität sieht in vielen Unternehmen anders aus. IT wird als Betriebsmittel geführt, nicht als Verantwortungsbereich mit strategischer Relevanz. Entscheider erfahren von Problemen erst dann, wenn diese eskalieren. Gespräche über Infrastruktur, Abhängigkeiten oder Weiterentwicklung finden selten statt – und wenn, dann meist nach einem Vorfall.
Wer IT nur als Supportfunktion führt, hat keinen Überblick, sondern eine Blackbox.
Der Kollege, den niemand ersetzen kann
In kleinen und mittleren Unternehmen liegt IT-Wissen häufig bei einer einzigen Person. Der Administrator kennt die Systeme, die Zugangsdaten und die Workarounds, die über Jahre entstanden sind. Er weiß, warum bestimmte Konfigurationen so gewählt wurden – auch wenn das nirgends dokumentiert ist.
Das geschieht selten aus Nachlässigkeit. Meist fehlt schlicht die Zeit, Wissen systematisch festzuhalten, weil das Tagesgeschäft Vorrang hat und neue Anforderungen schneller entstehen, als alte Strukturen aufgeräumt werden können. Solange der Betrieb läuft, stellt niemand Fragen.
Hinzu kommt, dass interne IT-Mitarbeiter selten strategisch eingebunden werden. Sie lösen operative Probleme, sitzen jedoch nicht am Tisch, wenn über Unternehmensentwicklung gesprochen wird. In manchen Organisationen werden sie behandelt wie Haustechniker mit erweiterten Rechten – zuständig für den Betrieb, aber nicht beteiligt an Entscheidungen.
Das funktioniert so lange, bis es nicht mehr funktioniert. Bei Krankheit, Kündigung oder internem Wechsel zeigt sich, was vorher nie sichtbar war: Wissensmonopole, die den gesamten Betrieb gefährden können.
Wann rächt sich fehlende Dokumentation?
Solange der Verantwortliche verfügbar ist, fällt fehlende Dokumentation nicht auf. Sie wird erst dann zum Problem, wenn jemand anderes übernehmen muss – sei es ein neuer Mitarbeiter, ein externer Dienstleister oder im schlimmsten Fall ein Krisenteam.
Ein neuer Administrator erbt dann eine Struktur, die er weder eingerichtet noch verstanden hat. Systeme sind miteinander verbunden, doch die Logik dahinter ist nirgends festgehalten. Zugangsdaten fehlen, Berechtigungen sind unklar, und was als geordnete Übergabe beginnen sollte, wird zu mühsamem Reverse Engineering.
Ich habe Fälle erlebt, in denen selbst grundlegende Passwörter nicht dokumentiert waren. Der Vorgänger hatte das Unternehmen verlassen, und mit ihm verschwand das Wissen über kritische Systeme. Die Folge waren Wochen, in denen externe Spezialisten rekonstruieren mussten, was intern niemand mehr nachvollziehen konnte.
Solche Situationen sind kein Ausnahmefall, sondern das gebilligte Ergebnis einer IT, die über Jahre funktioniert hat – aber im Schatten blieb.
Macht Cloud abhängig?
Cloud-Dienste versprechen Flexibilität, weil sich Ressourcen skalieren lassen, Investitionen in eigene Hardware entfallen und die Wartung beim Anbieter liegt. Für viele Unternehmen klingt das nach weniger Risiko und mehr Beweglichkeit.
Die Realität ist jedoch komplizierter. Wer Infrastruktur in eine Public Cloud verlagert, gibt damit auch Kontrolle ab – an einen Anbieter, dessen Preisentwicklung weder verhandelbar noch vorhersehbar ist. Historisch betrachtet sind die Kosten bei Hyperscalern gestiegen, nicht gefallen. Und wer einmal in einer Umgebung eingerichtet ist, wechselt nicht ohne erheblichen Aufwand.
Dieses Phänomen trägt einen Namen: Vendor Lock-in. Die technische Abhängigkeit von einer Plattform macht den Wechsel teuer, zeitaufwändig oder in manchen Fällen praktisch unmöglich. Was als flexible Lösung begann, wird so zur strategischen Einschränkung.
Inzwischen gibt es eine Gegenbewegung. Unternehmen, die in Public Clouds gestartet sind, prüfen den Rückzug in Private-Cloud-Umgebungen – nicht aus Prinzip, sondern aus betriebswirtschaftlicher Notwendigkeit. Steigende Kosten, unklare Verantwortungsbereiche und der Wunsch nach mehr Kontrolle treiben diese Entscheidung.
Dieser sogenannte Cloud Exit folgt einer strategischen Logik: Die ursprüngliche Entscheidung beruhte auf Annahmen, die sich im laufenden Betrieb nicht bestätigt haben.
Das Dokumentationsproblem löst die Cloud dabei nicht. Sie verlagert es lediglich. Die Frage, wer Strukturen versteht, pflegt und verantwortet, stellt sich weiterhin – nur liegt die Infrastruktur jetzt außerhalb des eigenen Zugriffs.
Wer betreibt die Cloud wirklich?
Public-Cloud-Anbieter übernehmen die Infrastruktur – aber nicht die Verantwortung für das, was darauf läuft. Sie stellen Rechenleistung, Speicher und Netzwerk bereit, doch wie diese Ressourcen konfiguriert, abgesichert und dokumentiert werden, bleibt Sache des Kunden.
Dieses Missverständnis ist weit verbreitet. Viele Unternehmen gehen davon aus, dass mit der Migration in die Cloud auch die Betriebsverantwortung übergeht. In der Praxis sieht das anders aus. Die Verantwortung für Datensicherung, Zugriffsrechte, Monitoring und Compliance liegt weiterhin beim Unternehmen selbst – unabhängig davon, wo die Server physisch stehen.
Wer intern keine Kapazität hat, diese Aufgaben zu übernehmen, steht vor einem Problem: Die Cloud läuft, aber niemand weiß genau, wie. Updates werden verschoben, Sicherheitslücken bleiben unbemerkt, und im Ernstfall fehlt das Know-how für eine schnelle Reaktion.
Cloud-Betrieb erfordert Kompetenz. Der Unterschied zur eigenen Infrastruktur liegt nicht im Wegfall dieser Anforderung, sondern lediglich im Ort, an dem sie erfüllt werden muss.
Wer ist für meine IT verantwortlich?
Die Frage klingt banal, doch in vielen Unternehmen lässt sie sich nicht eindeutig beantworten. Es gibt einen Administrator, vielleicht einen externen Dienstleister, gelegentlich auch beides – aber wer trägt tatsächlich die Verantwortung für Betrieb, Sicherheit und Weiterentwicklung der IT-Infrastruktur?
Verantwortung setzt Sichtbarkeit voraus. Solange unklar ist, welche Systeme existieren, wie sie zusammenhängen und wer sie pflegt, bleibt auch unklar, wer im Ernstfall handlungsfähig ist. Die Geschäftsführung trägt das unternehmerische Risiko, hat aber häufig keinen Einblick in die Strukturen, die dieses Risiko bedingen.
Rechtlich betrachtet ist die Lage eindeutiger, als viele annehmen. Die Geschäftsführung haftet persönlich für die Einhaltung von IT-Sicherheitsstandards – unabhängig davon, ob sie selbst technisch versiert ist oder nicht. Pflichten aus DSGVO, GoBD oder branchenspezifischen Regularien lassen sich nicht delegieren. Wer sie nicht erfüllt, riskiert nicht nur Bußgelder, sondern im Ernstfall auch persönliche Haftungsansprüche.
Diese Unschärfe zwischen operativer Zuständigkeit und rechtlicher Verantwortung ist selten gewollt. Sie entsteht über Jahre, weil IT als operative Funktion behandelt wird und strategische Fragen in den Hintergrund rücken.
- Wer kümmert sich um Dokumentation?
- Wer prüft, ob Sicherheitsstandards eingehalten werden?
- Wer entscheidet über Investitionen in neue Systeme – und auf welcher Grundlage?
Erst wenn diese Fragen beantwortet sind, lassen sich Verantwortungsbereiche sinnvoll verteilen. Zwischen internen Mitarbeitern und externen Partnern, zwischen operativem Betrieb und strategischer Steuerung. Ohne diese Klarheit bleibt IT ein Bereich, der funktioniert, aber nicht geführt wird.
Risiko kennen, dann entscheiden
IT-Abhängigkeiten lassen sich nicht vermeiden. Jedes Unternehmen ist auf Systeme, Anbieter und Mitarbeiter angewiesen, die den Betrieb ermöglichen. Die Frage ist nicht, ob Abhängigkeiten existieren – sondern ob sie bekannt sind.
Wer weiß, wo Wissensmonopole liegen, kann Redundanzen schaffen. Wenn man verstanden hat, welche Kosten ein Anbieterwechsel verursachen würde, kann man diese in strategische Überlegungen einbeziehen. Klarheit über Verantwortungsbereiche hilft, Entscheidungen zu treffen, die auf Fakten beruhen statt auf Annahmen basieren.
Das bedeutet nicht, dass jedes Risiko eliminiert werden muss. Manche Abhängigkeiten sind sinnvoll, weil sie Effizienz ermöglichen oder Komplexität reduzieren. Entscheidend ist, dass sie bewusst eingegangen werden – mit einem Verständnis für die Konsequenzen, die daraus entstehen können.
Für die Geschäftsführung bedeutet das: IT-Risikomanagement beginnt nicht mit Technologie. Es beginnt mit Transparenz. Erst wenn sichtbar ist, wie die eigene IT aufgestellt ist, lassen sich Fragen nach Investition, Auslagerung oder Weiterentwicklung fundiert beantworten.
Die IT muss nicht perfekt sein. Aber sie muss verstanden werden.
