Obwohl viele Business Continuity-Standards die Bedeutung der Nachverfolgung von Korrekturmaßnahmen zur Behebung identifizierter Probleme betonen, verlangt die kürzlich veröffentlichte ISO 22301 (und zuvor BS 25999-2) auch die Durchführung einer Ursachenanalyse – also nicht nur die Betrachtung eines Problems, sondern auch dessen Ursache und die Frage, wie es in Zukunft verhindert werden kann. 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 letztlich das erneute Auftreten des unerwünschten Ereignisses in der Zukunft zu verhindern. Dies ist zwar in Disziplinen üblich, die sich mit extremer Präzision und dem Schutz von Leben befassen (z.B. Qualität und Umweltschutz), aber es gibt 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. Dieser Artikel erläutert die Ursachenanalyse und zeigt auf, wie Unternehmen 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 mögliche 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, reaktiv auf ein Problem zu reagieren – zukünftige Probleme mussten verhindert werden, und die Ursachenanalyse war der Weg, um eine verbesserte Leistung und Risikominderung zu ermöglichen, indem die wahren Ursachen und nicht nur die Symptome beseitigt wurden. 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, d.h. die wiederholte Frage nach dem „Warum“ eines Problems, bis Sie scheinbar die Grundursache für das Scheitern gefunden haben. Der Schlüssel dazu ist eine disziplinierte 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 beispielsweise so aussehen:

  1. Problem: Das IT-Wiederherstellungspersonal konnte das SAP-System des Unternehmens während des IT-DR-Tests von letzter Woche …. nicht innerhalb der angestrebten Wiederherstellungszeit von 24 Stunden wiederherstellen. Und warum?
  2. Das IT-Wiederherstellungspersonal sagte, dass die SAN-LUNs nicht korrekt zugeordnet waren, was den Beginn der Wiederherstellung von der Festplatte drastisch verzögerte … Warum?
  3. Das Personal des Anbieters, das für die Vorbereitung der Ausrüstung verantwortlich war, 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 genügend Details enthielten, um die Schritte auszuführen, 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 Tests haben die Mitarbeiter die vorhandenen Planunterlagen nicht vollständig genutzt… Was hat sich diesmal 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 verantwortlich war, führt häufig Tests vor Ort durch, ohne die Dokumentation zu verwenden, da er über umfangreiche Erfahrung 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 durchführt. Bei der weiteren Untersuchung des Problems stellte sich heraus, dass die neueren Mitarbeiter, die mit Wiederherstellungsaufgaben betraut sind, weitaus weniger erfahren sind und noch keine angemessene Sensibilisierungsschulung erhalten haben. 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 Fachbereich 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). Gemeinsam können diese Maßnahmen sicherstellen, dass die gesamte IT-DR-Dokumentation während der Tests sowohl von internen als auch von externen Ressourcen effektiv genutzt werden kann.

Obwohl dies in der Theorie einfach ist, kann es in der Praxis schwierig sein, die tatsächliche Ursache zu identifizieren und herauszufinden, wann Sie weit genug gegangen sind. 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 beheben können. In den meisten Fällen besteht das größte Problem für die meisten Unternehmen 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 Beseitigung der Ursache die Leistung und Wiederherstellbarkeit in anderen Bereichen verbessern könnte.

Im Rahmen der Business Continuity 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 dies wiederum voraussetzt, dass die Probleme weiter zurückverfolgt werden, 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 Quelle des Problems, einer detaillierten Beschreibung, eines Identifikationsdatums und eines Feldes zur Erfassung der Ursachenanalyse. 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 das Problem zugewiesen werden kann oder die einen Einblick in das Problem geben können, und dann sollte die Gruppe versuchen, das Problem gemeinsam zu seinem Ursprung zurückzuverfolgen.

Im Bereich Business Continuity gibt es zahlreiche Ursachen, die zu einer Vielzahl von Problemen oder Komplikationen führen können. In der folgenden Tabelle finden Sie einige Beispiele sowie die wahrscheinlichen Ursachen, 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, anstatt nur einer direkten Ursache nachzugehen, um alle Einflussfaktoren zu identifizieren.

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 zwangsläufig 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.

Im Zuge der Weiterentwicklung von Business Continuity Management-Systemen wird die Ursachenanalyse zu einem leistungsstarken Werkzeug für Business Continuity-Experten, um die Ursache von Problemen eingehend zu untersuchen und die Möglichkeit zu bieten, diese zu korrigieren, bevor sie erneut auftreten.