Leitfaden zur Analyse der Geschäftsauswirkungen

Nicht jeder weiß, wo und wann er mit der Implementierung von Business Continuity-Plänen beginnen soll. Normalerweise sage ich Folgendes: Wenn die möglichen Verluste höher sind als die Kosten für die Bekämpfung der Bedrohung, ist es Zeit, Maßnahmen zu ergreifen, die Kosten sind angemessen. Umgekehrt. Wenn die Kosten der Gegenwirkung mehr oder weniger klar sind, ist die Schätzung von Verlusten keine triviale Aufgabe. Ich lade Sie in die Backstage eines Projekts ein, um die Auswirkungen von Notfällen auf ein Unternehmen zu bewerten (Business Impact Analysis - BIA) und eine Strategie zur Gewährleistung der IT-Kontinuität am Beispiel eines großen Einzelhändlers zu entwickeln. Also lass uns gehen.

Starten Sie

Wir haben am Projekt der X5 Retail Group teilgenommen - dem größten Einzelhändler in Russland. Das Unternehmen verwaltet die Netzwerke von Pyaterochka, Carousel und Crossroads.

Sie hatte bereits ihre eigene Richtlinie zum Management von Unterbrechungsrisiken, die Folgendes umfasste:

1. Risikoversicherung;
2. Bildung von Krisenmanagement;
3. Minimierung der Risiken für Leben und Gesundheit von Menschen;
4. Kontrolle der Risiken der Geschäftsverwaltbarkeit;
5. Erstellung von Notfallwiederherstellungsplänen für IT-Systeme.

In Übereinstimmung mit dieser Richtlinie erforderte eine zentralisierte IT-Infrastruktur die Entwicklung von Plänen für die Kontinuität von IT-Diensten und Disaster Recovery. Die ideale Lösung wäre, ein Backup-Rechenzentrum aufzubauen, eine synchrone Replikation einzurichten, eine Automatisierung für die Notfallübertragung einzurichten und nach einer Stunde „H“ zu sehen, um zu sehen, wie IT-Systeme zum Backup-Rechenzentrum wechseln und grüne Lichter aufleuchten, um zu signalisieren, dass keine Gefahr für das Geschäft besteht.

Angesichts der Wirtschaftlichkeit des Prozesses schlug das Unternehmen jedoch vor, nur die kritischsten IT-Systeme zu reservieren, um eine angemessene Notfallmaßnahme zu erreichen, ohne die die Filialen nicht betrieben werden könnten und erhebliche finanzielle Verluste im Unternehmen entstehen würden. Es stellt sich eine wichtige Frage: Welche Systeme und wie lange sollten wiederhergestellt werden?
Die IT-Abteilung des Kunden bestimmte die Klassifizierung der IT-Systeme und die akzeptable Wiederherstellungszeit für jedes System. Später wurde jedoch beschlossen, eine vollständige Bewertung der Auswirkungen von Notfällen auf das Geschäft des Unternehmens (BIA) gemäß ISO 22301 und Best Practices durchzuführen.

Volumen und Grenzen

Das Theater beginnt mit einem Kleiderbügel, und die BIA beginnt mit der Definition des Arbeitsumfangs. Dazu müssen Sie die Geschäftsprozesse, Dienstleistungen, Abschlüsse, Beziehungen zu Partnern, Kunden und Auftragnehmern des Unternehmens untersuchen. Identifizieren und koordinieren Sie dann die wichtigsten Geschäftsprozesse und Services, die innerhalb der Projektgrenzen liegen. Die Dauer und die Kosten der BIA hängen vom Volumen ab. Darüber hinaus legen unsere Erfahrungen nahe, dass Sie das Projekt nicht länger als 9 Monate verlängern sollten.

In unserem Fall hat der Kunde die Grenzen bereits durch Auswahl der wichtigsten Geschäftsprozesse für Handelsaktivitäten festgelegt.

Das Interview

Sobald die Grenzen und Rahmenbedingungen der BIA festgelegt sind, wird eine Liste der Stakeholder aus dem Unternehmen und anderen Abteilungen festgelegt, mit denen Sie ein Interview führen möchten. Es ist sehr wichtig, Informationen aus verschiedenen Abteilungen zu sammeln, um ein objektives Bild der Prozesse im Unternehmen zu erhalten, ihre Funktionsweise zu verstehen und eine Einschätzung darüber zu erhalten, was passieren wird, wenn .... In dieser Phase erhalten wir Informationen darüber, wie genau Geschäftsprozesse von der IT abhängen, und erstellen eine Matrix dieser Abhängigkeiten. Außerdem bewerten Unternehmensvertreter und am Geschäftsprozess interessierte Parteien die Konsequenzen, möglichen Schäden und möglichen Szenarien. Zu diesem Zweck haben wir einen speziellen Fragebogen entwickelt und etwa 50 Befragte befragt (50 Präsentationen über das Projekt selbst präsentiert, alle ausgefüllten Fragebögen durchgeführt, empfangen und verarbeitet).

Geschäftsprozesse

Parallel zu den Befragungen haben wir Geschäftsprozesse beschrieben, wobei wir die Zeit für die Fertigstellung einzelner Vorgänge und die Tiefe der Ausarbeitung berücksichtigt haben, die für die weitere Analyse ausreicht. Die Aufteilung eines Prozesses in kleinere Komponenten und bestimmte Vorgänge ist erforderlich, um zu verstehen, wie sich ein IT-System auf einen bestimmten Prozess zu verschiedenen Tageszeiten und zu verschiedenen Jahreszeiten auswirkt. In dieser Phase ist es wichtig zu verstehen, dass wir Geschäftsprozesse nicht nach GOST oder einer anderen Methodik beschreiben. Wir optimieren Geschäftsprozesse nicht und geben im Allgemeinen keine Empfehlungen zur Verbesserung von Geschäftsprozessen, zumindest innerhalb der BIA. Wir beschreiben Geschäftsprozesse so detailliert, dass wir die Methode zur Berechnung von Verlusten begründen und Verluste nach mehreren Kriterien bewerten können. Für eine grafische Beschreibung wurden die Notationen EPC, ARIS und MS Visio als Werkzeuge verwendet.

Schwellenwerte

Um die objektive Zielwiederherstellungszeit zu bestimmen, müssen wir uns am Ufer auf die Kriterien einigen, anhand derer wir den Schaden bewerten, und auf ihre Schwellenwerte. Wenn diese Schwellenwerte überschritten werden, betrachten wir den Schaden als kritisch und das Zeitintervall, in dem der Schwellenwert erreicht wird, wird zur Zielwiederherstellungszeit. Es wurden zwei Optionen vorgeschlagen:

• RTO anhand eines Kriteriums bestimmen - finanzielle Verluste;
• Bestimmen Sie die RTO anhand von drei Kriterien: finanzieller Verlust, Reputationsverlust, Verlust der Kontrollierbarkeit von Geschäftsprozessen.

Die erste Option mit einem Kriterium scheint vorzuziehen zu sein, da Verluste bedingt in Geld umgewandelt werden können - die Hauptsache ist, sich auf eine Neuberechnungsformel zu einigen. Wie die Praxis zeigt, rechnet niemand Reputationsverluste speziell in finanzielle Verluste um, und die Genehmigung einer solchen Formel kann eine unbestimmte Zeit in Anspruch nehmen. Es wurde beschlossen, die Wiederherstellungszeit für beide Optionen zu berücksichtigen, und in der Phase der Präsentation der Ergebnisse wird der Kunde selbst bestimmen, welche die Realität objektiver widerspiegelt.



Mit Blick auf die Zukunft möchte ich sagen, dass sich bei Verwendung der ersten Option mit einem Kriterium herausgestellt hat, dass die RTO im Preisfindungsprozess beispielsweise 10 Tage erreichen kann. Bei der Berechnung der zweiten Option hat die RTO 24 Stunden nicht überschritten. In jedem Fall bleibt die Entscheidung des Managements - welche Verluste zu berücksichtigen sind und welche nicht - beim Kunden.

Die Risiken

Gemeinsam mit dem Kunden haben wir die Liste der operationellen Risiken festgelegt. Das heißt, diejenigen, die sich auf die IT auswirken, und diejenigen, die sich wiederum auf Geschäftsprozesse auswirken, die ... nun, Sie verstehen. Diese Phase ist wichtig, da ein Notfall nicht als kugelförmiges Pferd im luftleeren Raum betrachtet wird. Sie sagen, was mit dem Mutterland und uns passieren wird, wenn wir die IT verlieren. Die Risiken wurden in globale und lokale Risiken unterteilt. Für jeden von ihnen wurden unter Berücksichtigung der Ergebnisse des Interviews ein Entwicklungsszenario und Auswirkungen auf die Unternehmensprozesse ermittelt. Natürlich kann dasselbe IT-System im Falle eines Ausfalls mehrere Geschäftsprozesse beeinflussen, aber wir waren schrecklich besorgt über nur zwei Prozesse im Projekt. Dann haben wir die Ansprüche gemäß den folgenden Parametern bewertet:

• Bedrohungsausbreitung;
• die Fähigkeit zu alarmieren;
• Expositionsdauer;
• Eintrittswahrscheinlichkeit;
• geschätzter Schaden.

Als Ergebnis erstellten sie eine Heatmap, auf der jede Anwendung eine Bewertung erhielt, wie heiß das Unternehmen während seiner Ausfallzeit brennen könnte. Zum Beispiel erhält das Unternehmen für 4 Stunden Ausfallzeit einzelner SAP-Module immer noch keine ernsthaften Probleme, aber selbst die ersten Stunden Ausfallzeit von Registrierkassensoftware auf der Heatmap sind feuerrot markiert.

Es muss klargestellt werden, dass die Risikobewertung und das weitere Ranking mithilfe einer Expertengruppe erstellt werden und erforderlich sind, um die kritischsten Situationen für den Kunden zu ermitteln.

Eventualrisiko und Szenario. Feuer im Rechenzentrum: Der Serverraum ist vollständig durchgebrannt, das am Nachschubprozess beteiligte SAP-Modul ist nicht verfügbar. Dies bedeutet, dass bis zur Wiederherstellung des verbrannten SAP-Moduls täglich die Produktpalette reduziert wird. Dies betrifft zum einen verderbliche Produkte, zum anderen stark nachgefragte Produkte (z. B. Getreide und Brot) und zum anderen Haushaltschemikalien. Offensichtlich wird diese Situation zu einem Umsatzrückgang in den Filialen führen. Dies ist jedoch nicht ganz offensichtlich: Der Käufer, der wegen Bier und Zigaretten gekommen ist, kann ohne eine der Waren höchstwahrscheinlich nichts kaufen. Ähnliches gilt für den Preisfindungsprozess. Wenn ein bedingter Kunde, der am Mittwoch um 12:00 Uhr von Rabatten erfahren hat, am Nachmittag im Geschäft ankommt und der Prozess „Preisgestaltung“ nicht funktioniert (dh Preise ohne Rabatte), dann:

A) kauft nichts (= finanzieller Verlust);
B) beschuldigt das Geschäft des Betrugs (= Reputationsverlust)
B) beschwert sich bei der Aufsichtsbehörde (= Strafe für unfaire Werbung).

Verlustschätzungstechnik

Wie Sie wahrscheinlich aus dem oben Gesagten verstanden haben, ist es zur Berechnung der finanziellen Verluste erforderlich, eine Methodik und Formeln für deren Berechnung zu entwickeln, die Rabatte, Sonderangebote, Tageszeit und Hochsaison (z. B. Aufregung Ende Dezember) berücksichtigen. Die Methodik sollte einen beschreibenden Teil (woher er kommt und warum er mit Gewichten multipliziert wird) sowie Tabellen und Grafiken zur Klarheit der Wahrnehmung enthalten.

Die Technik beschreibt auch:

• Wie die Wiederherstellungszeit für einen Geschäftsprozess bestimmt wird
• Wie sich die Wiederherstellungszeit für einen Geschäftsprozess in RTO / RPO für IT-Systeme niederschlägt
• Kritikalitätsklassen und Wiederherstellungsklassen - warum ist dies erforderlich?

Wir gehen weiter.

RTO-Berechnung

Nachdem alle Interviews durchgeführt wurden, werden Geschäftsprozesse beschrieben, Risiken bewertet, eine Methodik definiert und genehmigt und Verluste berechnet. Da sich das Geschäft von Pyaterochka, Carousel und Crossroads zumindest in der Größenordnung unterscheidet, haben wir für jedes Netzwerk unsere eigenen Tabellen, unsere eigenen Zeitpläne und Verlustberechnungen entwickelt.

Für den gesamten Geschäftsprozess wird die Wiederherstellungszeit bestimmt (siehe Methodik), wenn Verluste den Schwellenwert überschreiten (siehe Schwellenwerte). Diese Wiederherstellungszeit wird den IT-Systemen zugewiesen, die am Geschäftsprozess beteiligt sind (siehe Interview und Abhängigkeitsmatrix). Es scheint, dass die Parameter der Kontinuität definiert sind - das Projekt ist abgeschlossen (siehe Grenzen und Rahmen). Es reicht jedoch nicht aus zu sagen, dass der Prozess in 12 Stunden wiederhergestellt werden sollte. Es ist wichtig zu bestimmen, wie dies jetzt funktioniert. Wie viele Stunden kann ein IT-System heute wiederbelebt werden? Und was ist, wenn die aktuelle Wiederherstellungszeit länger oder deutlich länger als das Ziel ist? Für diejenigen, die immer noch Vernunft und Konzentration bewahren, willkommen in der GAP!

GAP-Analyse und Aktionsplan

Als Ergebnis der vorherigen Schritte haben wir den Zustand für die Prozesse und TO TO-Systeme bestimmt, dh wie er idealerweise sein sollte. Zum gegenwärtigen Zeitpunkt bestimmen wir den Status von "AS IS". Gleichzeitig berühren wir Geschäftsprozesse in geringerem Maße und konzentrieren uns auf die IT-Komponente. Für den Kunden haben wir seine aktuellen Lösungen im Hinblick auf die Wiederherstellung nach einem Notfall bewertet. Darüber hinaus war es in diesem Fall nicht erforderlich, eine echte Wiederherstellung mit einem Timer durchzuführen. Es war genug, um tief in die Details zu gehen und genug Desktop-Tests, um zu verstehen, dass die Ziel-RTO nicht erreichbar ist.

Danach haben wir eine Reihe allgemeiner Empfehlungen entwickelt (um die IT-Kontinuität zu gewährleisten), die sich direkt auf IT-Systeme und deren Architektur beziehen. Dies sind Skizzen technischer Lösungen und eine grobe Schätzung der Kosten ihrer Implementierung. In der Tat gibt es jetzt eine Grundlage für eine Entscheidung. Auf der einen Seite der Skala - Verluste und auf der anderen Seite - die Kosten der Maßnahmen.
Wenn einige IT-Systeme keiner GAP-Analyse unterzogen werden oder ihre Wiederherstellungszeit länger als das Ziel ist, erstellen wir ein Projektprogramm zur Erreichung des Zielzustands oder, wenn Sie möchten, eine Roadmap mit Begründung der Projektsequenz und einer Zwischenbewertung zur Verbesserung der Nachhaltigkeit der Organisation.

Darüber hinaus haben wir für den Kunden methodische Materialien und Vorlagen für die Erstellung von Kontinuitätsplänen und Disaster Recovery-Plänen entwickelt.

Strategie

Warte, warte, ich bin fast fertig.

Basierend auf den BIA-Ergebnissen haben wir eine IT-Kontinuitätsstrategie entwickelt. Die Kontinuitätsstrategie beschrieb zwei Schlüsselpunkte.

1. Welche IT-Risiken, die sich auf die Aktivitäten des Unternehmens auswirken, berücksichtigt werden und welche nicht (dh wovor wir Angst haben und im Rahmen der Kontinuität entscheiden werden und wovor wir keine Angst haben, und dafür haben wir Incident Management).
2. Welche organisatorischen, architektonischen, infrastrukturellen und anderen Lösungen werden wir gegen Bedrohungen verteidigen?

Durch Strategie schlagen wir zwei Fliegen mit einer Klappe. Erstens versteht jeder im Unternehmen, wie und wovor wir uns schützen werden. Zweitens sieht der Prozess der Budgetierung von IT-Disaster-Recovery-Lösungen für IT-Nichtspezialisten (z. B. Finanziers) transparenter aus. Und egal wie erbärmlich es auch klingen mag, die Strategie hilft dabei, die richtigen Managemententscheidungen zu treffen (es besteht immer die Möglichkeit, kein Geld für DR auszugeben, und jetzt wissen wir genau, wie sich dies im Falle eines Unfalls auf das Unternehmen auswirkt).

Was weiter? Weitere Implementierung der Kontinuitätsstrategie und der Analyse der Geschäftsauswirkungen für andere Geschäftsprozesse und IT-Systeme. Entwicklung von Kontinuitätsplänen, regelmäßige Überprüfung dieser Pläne, aber das ist eine ganz andere Geschichte.

Igor Tyukachev, Berater, Jet Infosystems Design Center