Obwohl viele Business-Continuity-Normen die Bedeutung der Nachverfolgung von Korrekturmaßnahmen zur Behebung festgestellter Probleme betonen, verlangt die kürzlich veröffentlichte ISO 22301 (und zuvor BS 25999-2) auch die Durchführung einer Ursachenanalyse, bei der nicht nur ein Problem, sondern auch seine Ursache und die Möglichkeiten seiner künftigen Vermeidung untersucht werden. Die Ursachenanalyse (Root Cause Analysis, RCA) ist ein Ansatz, der darauf abzielt, das erneute Auftreten desselben unerwünschten Ereignisses oder Systemfehlers proaktiv zu verhindern, indem die kausalen Zusammenhänge eines Fehlers bis zu seinem wahrscheinlichsten Ursprung zurückverfolgt werden und dann Maßnahmen ergriffen werden, um die zugrundeliegenden Ursachen abzuschwächen, um letztendlich das erneute Auftreten des unerwünschten Ereignisses in der Zukunft zu verhindern. Während dies in Disziplinen üblich ist, die sich mit extremer Präzision und dem Schutz von Leben befassen (z. B. Qualität und Umweltgesundheit und -sicherheit), gibt es keinen Grund, warum die Business Continuity-Disziplin nicht von einem ähnlichen Ansatz profitieren kann, insbesondere für Praktiker, die die ISO 22301 vollständig umsetzen wollen. In diesem Artikel wird die Ursachenanalyse erläutert und aufgezeigt, wie Organisationen von der Umsetzung des Konzepts im Rahmen der Geschäftskontinuität profitieren können.

Das Konzept der Ursachenanalyse wurde ursprünglich von Sakichi Toyoda (dem Gründer der Toyota Motor Corporation) entwickelt, der einen Prozess namens "Five Whys" entwickelte, um potenzielle Ursachen für Probleme zu verstehen, die über das unmittelbar Offensichtliche hinausgehen. Die Ursachenanalyse wurde formalisiert, als sie als Leistungsfaktor in verschiedene Bereiche integriert wurde, z. B. Sicherheit, Qualität, Betrieb und Informationssicherheit. In jedem dieser Bereiche reichte es nicht aus, auf ein Problem zu reagieren - künftige Probleme mussten verhindert werden, und die Ursachenanalyse war der Weg zur Leistungsverbesserung und Risikominderung durch Beseitigung der wahren Ursachen und nicht nur der Symptome. Die Einbeziehung der Ursachenanalyse in bestehende Korrekturmaßnahmen im Zusammenhang mit der Geschäftskontinuität könnte die Wahrscheinlichkeit künftiger Störfälle sehr wohl minimieren und die Wiederherstellungszeiten verkürzen.

Manchmal ist die Durchführung von RCA so einfach wie die Anwendung der fünf Warum-Fragen, indem man wiederholt fragt, warum etwas aufgetreten ist, bis man scheinbar die Grundursache für das Auftreten des Fehlers gefunden hat. Der Schlüssel liegt in der disziplinierten Anwendung von bohrenden Fragen. Die Analyse der Grundursache, warum ein Unternehmen bei einem kürzlich durchgeführten Test das Ziel einer 24-stündigen Wiederherstellungszeit für seine SAP-Umgebung nicht erreicht hat, könnte zum Beispiel folgendermaßen aussehen:

  1. Problem: Das IT-Wiederherstellungspersonal konnte das SAP-System des Unternehmens während des IT-DR-Tests der letzten Woche .... nicht innerhalb der angestrebten Wiederherstellungszeit von 24 Stunden wiederherstellen. Warum?
  2. Das IT-Wiederherstellungspersonal gab an, dass die SAN-LUNs nicht korrekt zugeordnet waren, was den Beginn der Wiederherstellung von der Festplatte drastisch verzögerte ... Warum?
  3. Das für die Vorbereitung der Ausrüstung zuständige Personal des Lieferanten hat die Einrichtung nicht entsprechend den dokumentierten Erwartungen durchgeführt ... Warum?
  4. Die Mitarbeiter des Anbieters gaben an, dass die Anweisungen widersprüchlich zu sein schienen und nicht so detailliert waren, wie es für die Ausführung der Schritte erforderlich war, so dass sie eine grundlegende Standardeinstellung verwendeten ... Warum?
  5. Bei der Analyse wurde festgestellt, dass die Dokumentation mehrere wichtige Schritte auslässt, die für diese komplexe LUN-Zuordnung erforderlich sind ... Warum wurde dies nicht früher entdeckt?
  6. Bei früheren Prüfungen hat das Personal die vorhandene Plandokumentation nicht vollständig genutzt ... Was hat sich dieses Mal geändert?
  7. Die Person, die für die Dokumentation des Plans und die Durchführung früherer Tests verantwortlich war, war nicht verfügbar, und die Mitarbeiter, die diesmal die Tests durchführten, gaben an, dass sie nicht ordnungsgemäß in der Anwendung der Pläne geschult waren und auch nicht darüber unterrichtet wurden, wie sie Probleme mit den Wiederherstellungsprozessen eskalieren sollten.

Auch wenn es den Anschein hat, dass die Grundursache gefunden wurde, stellt die bloße Korrektur der Dokumentation nicht sicher, dass die künftige Dokumentation korrekt sein wird. Der frühere IT-Experte, der für die Dokumentation der Verfahren zuständig war, führt häufig Tests vor Ort durch, ohne die Dokumentation zu verwenden, da er über umfangreiche Erfahrungen auf diesem Gebiet verfügt und der Meinung war, dass er die Aufgaben schneller erledigen kann, wenn er die Wiederherstellung auf der Grundlage seiner Erfahrung und nicht auf der Grundlage dokumentierter Verfahren vornimmt. Bei der weiteren Untersuchung des Problems stellte sich heraus, dass neuere Mitarbeiter, die mit Wiederherstellungsaufgaben betraut wurden, weit weniger erfahren waren und noch keine angemessene Sensibilisierungsschulung erhalten hatten. In diesem Zusammenhang gab der IT-Direktor zu, dass er nie andere Mitarbeiter zur Validierung der Dokumentation aufforderte, da das Testen Zeit von der Produktionsunterstützung abzieht und der Einsatz von "Experten" in jeder Phase die Testzeit verkürzt.

Ein Teil der Lösung könnte darin bestehen, dass alle dokumentierten Verfahren mindestens einmal jährlich von einem anderen IT-Mitarbeiter aus einem anderen Fachgebiet validiert werden müssen. Ein zweiter Teil der Lösung könnte darin bestehen, dass sowohl die alternativen internen Mitarbeiter als auch die für die Ausführung des Plans verantwortlichen Lieferantenressourcen im Vorfeld entsprechend geschult werden (wobei der Schwerpunkt auf der Vertrautheit mit den Plänen und der Kenntnis der Eskalationsverfahren liegt). Mit diesen Maßnahmen kann sichergestellt werden, dass die gesamte IT-DR-Dokumentation sowohl von internen als auch von externen Ressourcen während der Tests effektiv genutzt werden kann.

Obwohl es in der Theorie einfach ist, kann es in der Praxis schwierig sein, die tatsächliche Ursache zu ermitteln und herauszufinden, wann man weit genug gegangen ist. Um die primären Ursachen zu verstehen, müssen Sie immer wieder Varianten des "Warum" (und einige andere bohrende Fragen) stellen und dann nach der Antwort suchen, die das Problem am wahrscheinlichsten beeinflusst hat. Die Ursachenanalyse ist zwar keine "harte Wissenschaft", aber je tiefer Sie nach den Ursachen suchen, desto wahrscheinlicher ist es, dass Sie Probleme finden, die Sie lösen können. In den meisten Fällen besteht das größte Problem für die meisten Organisationen darin, Probleme gar nicht erst zu erforschen! Unser Beispiel zeigt dieses Problem bei der Wiederherstellung von SAP. Es ist jedoch wahrscheinlich, dass dieses Problem (die Abkürzungen) auch in anderen Bereichen besteht, und die Behebung der Ursache könnte die Leistung und Wiederherstellbarkeit in anderen Bereichen verbessern.

Im Rahmen der Geschäftskontinuität gibt es mehrere Bereiche, die in der Regel als Grundursachen für Probleme bei der Risikominderung, Reaktion und Wiederherstellung identifiziert werden können, auch wenn es wiederum erforderlich ist, Probleme weiter zurückzuverfolgen, als die meisten Fachleute es tun. Um die Ursachenanalyse ordnungsgemäß in die Aktivitäten zur kontinuierlichen Verbesserung zu integrieren, sollte jedes Problem angemessen dokumentiert werden, einschließlich der Problemquelle, einer detaillierten Beschreibung und eines Identifizierungsdatums, und es sollte auch ein Feld zur Erfassung der Ursachenanalyse vorhanden sein. Anstatt dass eine einzelne Person versucht, die Grundursache zu ermitteln, sollten die für die Geschäftskontinuität zuständigen Mitarbeiter Diskussionen organisieren und moderieren, an denen Fachexperten teilnehmen, denen Probleme zugewiesen werden können oder die einen Einblick in ein Problem geben können, und dann sollte die Gruppe versuchen, das Problem gemeinsam zu seinem Ursprung zurückzuverfolgen.

Im Rahmen der Geschäftskontinuität gibt es zahlreiche Ursachen, die zu einer Vielzahl von Problemen oder Komplikationen führen können. In der folgenden Tabelle sind einige Beispiele mit den wahrscheinlichen Ursachen aufgeführt, wobei diese Liste bei weitem nicht vollständig ist. Wie bei den Wurzeln eines Baumes, die sein Wachstum fördern, kann es mehr als eine Ursache geben, die sich auf ein System auswirkt und zu einem Problem führt. Daher ist es wichtig, alle potenziellen Wege zum Ursprung eines Problems zurückzuverfolgen und nicht nur eine direkte Ursache zu verfolgen, um alle Einflussfaktoren zu ermitteln.

Auch hier geht es bei der Ursachenanalyse nicht nur um die Lösung eines Problems, sondern auch um die Suche nach Möglichkeiten, das Auftreten eines Problems in Zukunft zu verhindern. Sobald der Ursprung eines Problems identifiziert ist, ist es wichtig, alle Bereiche des Unternehmens zu bewerten, um andere Risikobereiche zu identifizieren und sicherzustellen, dass geeignete Maßnahmen zur Risikominderung ergriffen werden. Eine Lösung in einem Bereich muss nicht unbedingt auf alle anderen Bereiche eines Unternehmens anwendbar sein. Aber selbst wenn dies nicht der Fall ist, schärft die Identifizierung ähnlicher Risikobereiche das Bewusstsein und ermöglicht es dem Unternehmen, zusätzliche Lösungen zu entwickeln, die sinnvoll sind und diese Risiken angehen, bevor sie zu zukünftigen Problemen oder Ausfallzeiten führen.

Da die Systeme für das Management der Betriebskontinuität immer ausgereifter werden, wird die Ursachenanalyse immer wichtiger. ein leistungsfähiges Werkzeug für Business-Continuity-Experten um die Ursache von Problemen eingehend zu untersuchen und die Möglichkeit zu bieten, sie zu korrigieren, bevor sie erneut auftreten.