Eine Inventarliste beantwortet nicht jede Frage
Server, Anwendungen und Geräte zu erfassen ist wichtig. Die Liste zeigt jedoch nicht automatisch, welche Leistung ausfällt, wenn ein einzelner Dienst nicht verfügbar ist. Kritisch werden Systeme durch ihren Zusammenhang mit Prozessen, Menschen, Daten und externen Partnern.
In der Praxis findet man häufig sehr ordentliche Listen, deren Einträge einzeln korrekt sind. Was fehlt, ist die Verbindung. Das Warenwirtschaftssystem steht in Zeile 42, der Identitätsdienst in Zeile 87 und der externe Support in einer anderen Datei. Dass ohne den Identitätsdienst niemand an das Warenwirtschaftssystem kommt und der Support nur über denselben Zugang arbeitet, wird erst sichtbar, wenn etwas ausfällt. Der Vorfall übernimmt dann freundlicherweise die Modellierung.
Mich interessiert deshalb immer das Warum: Warum ist dieses System wichtig? Welche Leistung hängt daran? Wer benötigt es, welche Daten fließen hindurch und was geschieht, wenn es einen Tag nicht verfügbar ist? Erst diese Fragen machen aus technischem Bestand ein Lagebild.
Beim Geschäft beginnen
Die Analyse beginnt mit einer verständlichen Leistung: Aufträge annehmen, produzieren, liefern oder abrechnen. Danach wird gefragt, was dafür benötigt wird und wie lange ein Ausfall tragbar wäre. So werden technische Details zu betrieblichen Entscheidungen. Alles hängt mit allem zusammen – die Kunst besteht darin, die wichtigen Verbindungen zuerst zu sehen.
Dabei lohnt es sich, Menschen aus verschiedenen Bereichen an einen Tisch zu holen. Die IT kennt Systeme und Schnittstellen, der Fachbereich kennt Ausnahmen und tatsächliche Abläufe, der Einkauf kennt Verträge und die Geschäftsleitung kennt Prioritäten. Jeder besitzt einen Teil des Bildes. Das Organigramm legt zwar gelegentlich nahe, Zusammenhänge hielten sich an Abteilungsgrenzen. Die Wirklichkeit wurde darüber offenbar nicht informiert.
- Kritische Leistungen und maximale Ausfallzeiten benennen.
- Notwendige Anwendungen, Daten und Identitäten zuordnen.
- Menschen, Standorte und Dienstleister einbeziehen.
- Gemeinsame Engpässe und Einzelabhängigkeiten markieren.
- Ersatzverfahren und Wiederanlauf praktisch testen.
Nicht jede Verbindung ist gleich kritisch
Eine vollständige Landkarte ist verlockend und selten fertig. Sinnvoller ist ein schrittweises Vorgehen entlang der wichtigsten Leistungen. Erkenntnisse werden dokumentiert und bei Veränderungen ergänzt. Ein gepflegtes unvollständiges Bild ist nützlicher als eine perfekte Zeichnung, die seit drei Jahren niemand aktualisiert hat.
Priorisierung bedeutet, Wirkung und Zeit zusammenzubringen. Ein System kann technisch bedeutend sein, aber für einige Stunden ersetzbar. Ein unscheinbarer Dienst kann dagegen Produktion, Kommunikation und Anmeldung gleichzeitig blockieren. Besonders interessant sind gemeinsame Engpässe: dieselbe Internetverbindung, derselbe Administrator, derselbe Cloud-Anbieter oder derselbe Standort.
Neue Cloud-Dienste, Schnittstellen und Dienstleister kommen oft schrittweise hinzu. Ein einzelner Wechsel wirkt überschaubar; nach einigen Jahren ist der ursprüngliche Zusammenhang kaum wiederzuerkennen. Deshalb sollte die Karte nicht nur im Projekt entstehen, sondern bei wesentlichen Veränderungen mitgepflegt werden. Dokumentation ist kein Denkmal. Sie soll beim nächsten Problem helfen.
Auch personelle Abhängigkeiten gehören dazu. Wenn nur eine Person weiß, wie ein Verfahren funktioniert oder wo ein Zugang liegt, ist das ein reales Risiko. Wissen lässt sich nicht vollständig in Handbücher gießen, aber Vertretung, Übungen und gemeinsam verstandene Abläufe reduzieren die Abhängigkeit erheblich.
Der Test entscheidet
Eine angenommene Abhängigkeit wird durch einen Test konkret. Kann ein Prozess ohne das Hauptsystem weiterlaufen? Sind Sicherungen erreichbar, wenn die zentrale Anmeldung ausfällt? Kann ein Dienstleister im Notfall tatsächlich helfen? Ein Wiederanlaufplan, der noch nie mit der Realität in Kontakt kam, ist zunächst Literatur. Vielleicht gute Literatur, aber noch kein Nachweis.
Tests müssen nicht immer groß und teuer sein. Schon eine moderierte Übung mit Fachbereich, IT und einem wichtigen Dienstleister kann zeigen, wo Annahmen auseinandergehen. Der Fachbereich erwartet vielleicht vier Stunden Wiederanlauf, während der Vertrag zwei Werktage vorsieht. Beide Angaben können für sich korrekt sein. Zusammen ergeben sie trotzdem ein Problem – und zwar eines, das sich vor dem Ausfall angenehmer besprechen lässt.
Aus der Landkarte werden Entscheidungen
Das Ziel ist nicht die schönste Darstellung, sondern eine bessere Entscheidung. Welche gemeinsame Abhängigkeit muss zuerst abgesichert werden? Wo brauchen wir eine Alternative, zusätzliche Kompetenz oder eine vertragliche Klärung? Manche Risiken lassen sich technisch reduzieren, andere organisatorisch auffangen. Wieder andere werden bewusst akzeptiert. Entscheidend ist, dass diese Entscheidung auf einem verstandenen Zusammenhang beruht.
Eine gute Abhängigkeitsanalyse hilft auch bei Veränderungen. Wird ein Dienst ersetzt oder ein Standort aufgegeben, lässt sich prüfen, welche Verbindungen betroffen sind. Dadurch wird sie zum Arbeitsmittel für Projekte, Betrieb und Krisenvorsorge. Alles hängt mit allem zusammen, aber nicht alles ist gleich wichtig. Genau diese Unterscheidung macht aus Komplexität eine handhabbare Aufgabe.
Praktisch bewährt sich eine einfache Verantwortung für die Pflege: Wer eine kritische Leistung verändert, prüft auch deren Abhängigkeiten. Das muss kein eigenes Großprojekt werden. Ein kurzer, verbindlicher Schritt in Beschaffung, Projektabschluss oder Änderungsprozess genügt häufig. Ohne einen solchen Auslöser altert die beste Landkarte still vor sich hin. Sie bleibt dann optisch eindrucksvoll und operativ ungefähr so hilfreich wie ein alter Stadtplan bei einer neu gebauten Umgehungsstraße.
Kurz gesagt
Informationssicherheit braucht mehr als Bestandslisten. Wer Abhängigkeiten von der Geschäftsleistung aus betrachtet, erkennt Prioritäten, Engpässe und sinnvolle Rückfallwege.
Quellen und weiterführende Informationen
Zuletzt fachlich geprüft: