Dejan Kosutic Ist es Ihnen schon passiert, dass Ihr Management Ihnen die Verantwortung für Umsetzung des betrieblichen Kontinuitätsmanagements übertragen hat, nur weil Sie in der IT-Abteilung arbeiten? Warum wird betriebliches Kontinuitätsmanagement in der Regel mit Informationstechnologie in Verbindung gebracht?
Das liegt wahrscheinlich daran, dass betriebliches Kontinuitätsmanagement aus dem ‚Disaster Recovery‘ (DR) entstanden ist, und Disaster Recovery im Grunde auf Informationstechnologie basiert. Vor 20 oder 30 Jahren gab es das betriebliche Kontinuitätsmanagement als Konzept noch nicht, dafür aber Disaster Recovery (DR) – das Hauptanliegen war, im Falle einer Katastrophe die Daten zu retten. Damals war es sehr beliebt, teure Geräte zu kaufen und an einem entfernten Ort aufzustellen, so dass alle wichtigen Daten eines Unternehmens zum Beispiel im Falle eines Erdbebens erhalten blieben. Nicht nur erhalten, sondern auch, dass die Daten mit mehr oder weniger der gleichen Kapazität verarbeitet würden, als ob sie sich am Hauptstandort befunden hätten.
Nach einer Weile wurde jedoch klar – was würde mit den Daten gemacht werden können, falls es keine Geschäftstätigkeit mehr gäbe, um diese Daten zu nutzen? So wurde die Idee des betrieblichen Kontinuitätsmanagements geboren – sein Zweck bestand darin, den fortlaufenden Betrieb des Unternehmens selbst im Falle eines größeren Vorfalls zu ermöglichen.
Definitionen
Werfen wir einen Blick auf die Definitionen – betriebliches Kontinuitätsmanagement ist die „strategische und taktische Fähigkeit des Unternehmens, für Vorfälle Störungen des Geschäftsbetriebs zu planen und auf diese zu reagieren, um betriebliche Abläufe auf einem vorab definierten akzeptablen Niveau weiterzuführen“ (BS 25999-2:2007), während die Wiederherstellung im Notfall die „Prozesse, Leitlinien und Verfahren für die Wiederherstellung oder Fortsetzung der kritischen technologischen Infrastruktur eines Unternehmens nach einer natürlichen oder vom Menschen verursachten Katastrophe“ umfasst (englischsprachige Wikipedia).
Wie Sie den Definitionen entnehmen können, liegt der Schwerpunkt in der DR auf der Technologie, während es im BC vor allem um den Geschäftsbetrieb geht. Daher ist Disaster Recovery Teil des betrieblichen Kontinuitätsmanagements. Sie können DR als einen der wichtigsten Faktoren des Geschäftsbetriebs oder als den technologischen Teil des betrieblichen Kontinuitätsmanagements betrachten.
Vielleicht haben Sie auch etwas anderes bemerkt: Die Definition des BC entstammt der BS 25999-2, der führenden Norm für betriebliches Kontinuitätsmanagement, während die Definition von DR aus der Wikipedia zitiert wird. Eigentlich ist „Betriebliches Kontinuitätsmanagement“ eine offizielle, in Normen anerkannte Bezeichnung, „Disaster Recovery“ ist es dagegen nicht.
Auswirkungen auf Umsetzung
Warum ist es eine schlechte Idee, dass die IT-Abteilung das betriebliche Kontinuitätsmanagement für das gesamte Unternehmen umsetzt? Weil betriebliches Kontinuitätsmanagement vor allem ein Thema für das Unternehmen und kein IT-Problem ist. Falls die IT-Abteilung betriebliches Kontinuitätsmanagement für das gesamte Unternehmen umsetzt, so könnte sie weder die kritische Bedeutung der Geschäftstätigkeit noch die Wichtigkeit von Informationen zu definieren. Außerdem steht infrage, ob die IT-Abteilung das Engagement der geschäftlichen Unternehmensteile erreichen würde.
Der beste Weg, um betriebliches Kontinuitätsmanagement umzusetzen und zu organisieren, besteht darin, dass der geschäftliche Teil des Unternehmens ein solches Projekt leitet – so werden ein größeres Bewusstsein und stärkere Akzeptanz aller Unternehmensteile erreicht. Die IT-Abteilung sollte natürlich ihre Rolle in einem solchen Projekt – eine entscheidende Rolle – wahrnehmen, um Disaster Notfallpläne vorzubereiten.
In diesem Webinar Implementing Business Impact Analysis according to ISO 22301 wird erklärt, wie RTO und RPO für unternehmenskritische Aktivitäten definiert werden.
