In nahezu jedem 2ten Gespräch, welches man in der IT-Branche zum Thema IT-Doku mit Kunden führt, ist unklar, welche Dokuformen es in der IT geben sollte.
3 Zitate dazu in etwa wiedergegeben:
„Wir brauchen ein Notfallhandbuch, die Geschäftsführung fordert das von uns als IT ab“
„Der Auditor bemängelt, dass wir kein Betriebshandbuch haben“
„Wir möchten BCM einführen, doch die Geschäftsführung sieht hier keinen Bedarf“
Nehmen wir beide einmal genauer unter die Lupe und beschäftigen wir uns damit.
Zur Aussage 1, dem Notfallhandbuch –> Es wirft Fragen auf:
- Gibt es eigentlich „DAS EINE“ Notfallhandbuch (das allumfassende Kompendium einer Firma)?
- Ist die IT-Abteilung hierfür zuständig?
- Kann man pauschal ein solches erstellen?
- Ist man als externer Dienstleister in der Lage dieses zu erstellen?
Tatsächlich kann man zusammenfassen, dass es im Unternehmen zwar EIN Notfallhandbuch geben kann, dieses aber im BCM (Business-Continuity-Management) verankert ist. Und eben dieses Business beantwortet Frage 2: es ist Sache der Geschäftsführung und obliegt in der vollen Verantwortung eben derer. Und da sich Geschäftsprozesse (das böse Wort, sofern es welche gibt) eben auch kurzfristig ändern können, beantwortet sich hieraus Frage 3 von selbst: Pauschal gibt es kein Notfallhandbuch und es muss immer individuell dem Business gerecht erstellt und regelmäßig angepasst werden. Die Frage 4 beantwortet sich somit auch von selbst: ein externer Dienstleister kann nur der „Trainer am Spielfeldrand“ sein, niemals der Erbringer eines solchen.
Kommen wir zur Aussage 2 –> Schön, dass wenigstens jemand danach fragt
Auch hier gibt es Fragestellungen:
- Kann es „DAS EINE“ Betriebshandbuch geben?
- Wer ist dafür eigentlich zuständig?
- Wie aktuell muss das ganze sein?
Um Frage 1 kurz zu beantworten: NEIN, denn tatsächlich sollte es etliche Betriebshandbücher im Unternehmen geben. Im Zuge der IT gibt es PRO FACHANWENDUNG ein Betriebshandbuch, welches von oben (der Anwendung) nach unten über die nötigen Services zu den nötigen Assets kommt und deren Wiederanlaufschritte, Backup- und Wiederherstellungsregelungen, Wiederbeschaffung und Bereitstellung sowie die nötigen Personen & Dienstleister beschreibt. Das bedeutet, das Betriebshandbücher auch nicht nur in der IT vorhanden sein sollten (!!!). Und somit beantwortet sich die Frage 2: Zuständig ist jeweils der Verantwortliche für die Fachanwendung und ein Vertreter, welche in Zusammenarbeit mit den nötigen Stakeholdern diese erarbeiten. Die Frage 3 ist somit auch völlig logisch: Es muss regelmäßig, kontinuierlich und idealerweise dynamisch automatisiert werden.
Die Aussage 3 –> Ein Schwergewicht!, auch hier gibt es Fragen:
- Kann eine IT-Abteilung beschließen, BCM einzuführen?
- Und kann sich eine Geschäftsführung weigern, ein BCM zu etablieren?
- Ist BCM eine einmalige Sache?
Oh je, da haben wir jetzt den ganz dicken Brocken zu schieben, wenn man wie ich obendrein noch als externer Dienstleister dazu involviert wird. Aber fassen wir mal zusammen und antworten auf Frage 1: Nein, die IT ist der völlig falsche Initiator des BCM, weil diese allenfalls für die Anforderungen aus ITSCM (IT Service Continuity Management) verantwortlich ist und diese als Baustein Richtung BCM beisteuern kann. Die Frage 2 ergibt sich nach dem Business der Firma: Sofern Auflagen (ISO, Kritis, B3s, NIS2 etc.) ein BCM erfordern, ist die Geschäftsführung verpflichtet, eine „Geschäftsfortführung in Krisen & Notfallsituationen“ zu gewährleisten. Nebenbei bemerkt: Diese nicht zu haben, ist wie das Autofahren ohne Haftpflichtversicherung und Gurt (kann gut gehen, muss es aber nicht). Und somit kann auch Frage 3 einfach beantwortet werden: Nein, BCM ist eine allgegenwärtige Sache, erfordert regelmäßige Bewertung, Übung und Anpassung!
Ordnen wir das Ganze mal etwas besser ein
Was ist eigentlich ganz grob BCM und ITSCM? Hierzu eine Grafik:
Quelle der Grafik (mit KI generiert): https://chatgpt.com
Und kurz die Abkürzungen erklärt (Quelle der Tabelle,mit KI generiert: https://chatgpt.com)
| Begriff | Bedeutung | Beschreibung |
|---|---|---|
| RTO (Recovery Time Objective) | Wiederanlaufzeit-Ziel | Maximale Zeitspanne, in der ein Service nach einem Ausfall wiederhergestellt sein muss. |
| RPO (Recovery Point Objective) | Datenverlust-Ziel | Maximal tolerierbarer Datenverlust in Zeit (z. B. 15 Minuten Backuplücke). |
| MTD (Maximum Tolerable Downtime) | Maximal tolerierbare Ausfallzeit | Zeit, nach der der Schaden für das Unternehmen nicht mehr akzeptabel ist. |
| WRT (Work Recovery Time) | Nachbereitungszeit | Zeit, die benötigt wird, um nach der technischen Wiederherstellung den Service wieder vollständig betriebsbereit zu machen (z. B. Datenprüfung, Tests, Benutzerfreigabe). |
Was man daraus entnehmen kann: Die IT ist also nur Erfüllungsgehilfe des BCM. Und im ITSCM steckt bewusst das Wort „Service“. Denn: Eine Anwendung ist ein Service, welcher wiederum von SUB-Services abhängig ist und auf Assets aufbaut. Wichtig erst einmal: Es gibt verschiedene Servicearten, diese sollten aber nicht zu weit ausufern (ideal 3 -4 Servicearten). Klingt kompliziert, ist es aber nicht. Dazu ein vereinfachtes Beispiel als onPrem (also nicht Cloud) eines kleinen Herstellers für Blechteile:
Anwendung:
- Warenwirtschaftssystem –> Servicetyp = „Anwendung“
Benötigte Voraussetzungen:
- Server (Windows) für die Software –> Servicetyp = „Anwendung“
- Datenbank (SQL) –> Servicetyp = „Anwendung“
- Datenverzeichnisse –> Servicetyp = „Anwendung“
- Datensicherung
Und nun kommt das Ganze, was man nicht direkt sieht:
- Eine Datenbankinstanz auf einem eigenen Windows-Server → Servicetyp = „Anwendung“
- Virtualisierungsumgebung, damit ERP-Server, Datenbankserver, Fileserver nutzbar sind → Servicetyp = „Anwendung“
- Hardware, damit man virtualisieren und ein Backup erstellen kann → Servicetyp = „Technischer Service“
- Netzwerk damit die Systeme und Endanwender mit dem ERP kommunizieren können → Servicetyp = „Technischer Service“
- Strom & Kühlung, damit die Server laufen, eventuell Feuerschutz → Servicetyp = „Technischer Service“
- Server-Rack, damit die Server nicht in der Luft schweben → Servicetyp = „Nicht technischer Service“
- Raum, in dem der Rack steht → Servicetyp = „Nicht technischer Service“
Alles klar? Es ist zusammengefasst eine Kette von Dingen, welche aufeinander aufbauen. Mein Beispiel berücksichtigt noch gar nicht, dass man nach extern kommunizieren muss für Warenbestellung, Rechnungsversand oder Logistikbeauftragung! Aber was kann man daraus ableiten:
a) Viele Dinge kann die IT-Abteilung in einem Servicekatalog dokumentieren und in etwa eine realistische Wiederherstellungszeit nennen (diese ist aber von verschiedenen Faktoren und Prüfszenarien variabel).
b) Damit alle Faktoren der Services einfließen, müssen andere Fachabteilungen (z.B. Facility-Management) in Erstellung und Prüfung involviert werden.
c) Diese Services münden alle im Initiator: Der „Anwendung ERP“, welche ein völlig eigener Service ist (könnte man auch Servicetyp = Fachanwendung setzen).
d) Ein Service ist ein Baustein für einen Prozess. Beispiel ERP (Warenwirtschaftssystem) ist ein Unterstützungsprozess zur Nutzung in einem oder mehreren Kernprozessen (z.B. für die Warenherstellung).
Und nun meine wirklich fiesen Fragen:
- Wer in der IT kann denn sagen, wie lange der Kernprozess „Warenherstellung“ maximal ausfallen darf, damit die Firma keinen existenziellen Schaden davonträgt?
- Wer außer der Geschäftsführung kann Summen beziffern, wann ein Schaden hoch oder niedrig ist?
- Wer ist denn dafür am Ende verantwortlich, wenn die Produktion steht, weil die IT keine Ressourcen und genehmigte Mittel hat, um die neue ERP-Version zu installieren? Wichtig dabei: Die IT sollte den Nachweis der Anforderung protokollieren und dokumentieren.
- Warum kann man denn nun eigentlich nicht „DAS NOTFALLHANDBUCH DER IT“ pauschal mal eben so erstellen lassen?
- Was kann denn die IT an Zeitfaktoren besiteuern?
Antworten kurz und knapp darauf:
- Definitiv die Geschäftsführung in nicht autokratischer Abstimmung mit den Fachabteilungen
- Auch die Geschäftsführung, welche bei Bedarf Wirtschaftsprüfer, Auditoren oder Finanzberater hinzuziehen kann/sollte.
- Die Geschäftsführung aus reinem Eigeninteresse und der Belegbarkeit an die externen Anforderungen (Auditierungsauflagen).
- Weil dieses einen Servicekatalog, eine BIA (Business Impact Analyse), Prozessbenennungen, Personenkreise (Notfallstab, BCM-Manager) erfordert, welche erst einmal mühsam zusammengetragen werden müssen.
- Die IT kann nur den WRT in etwa benennen, die Summe der WRT’s geben Aufschluss darüber, wie lange ein Service benötigt, bis er wieder Online ist!
Und was gibt es sonst noch für Dokus?
Betriebshandbücher und Notfallhandbuch sind somit erklärt. Bleibt noch die frage: was sonst moch?
Hier die möglichen Dokumentationsformen:
- IT-Strategiehandbuch → erklärt die Technische Ausrichtung, ideal für neue Kollegen zum Einarbeiten und für das Grundverständnis ein „must have“
-
- IT-Koordinationsplan → beschreibt die organisatorischen Schritte unter Berücksichtigung der organisatorischen Vorgaben aus den Kritikalitäten
- IT-Notfallplan → NUR auf IT-Technik erstellte kleinere Sammlung von Doings und Maßnahmen
- System- und Anwendungsdokumentationen → Wie und was auf technischer Basis von Komponenten und Anwendungen
- IT-Landkarten → Pläne und Abhängigkeiten der Systeme
-
Fazit
Damit die ganze Geschichte funktioniert, reicht es also nicht aus, wenn ein Einzelner losrennt und mal eben schnell einzelne Punkte aus einem aktuellen Bedarf erfüllt.
Definitiv ist es eine Gesamtgeschichte des Unternehmens und erfordert, neben dem reinen Willen, eine konkrete Planung (Prozesskenntnisse und Benennung, Erstellung Servicekatalog (beides in Form über eine BIA zu definieren), Ressourcenbereitstellung (Personen, Zeit, Finanzen) und einen konkreten Umsetzungszeitrahmen für die Initiativerstellung.
Die Aktualität muss daher auch zwingend gelebt werden innerhalb des Unternehmens.