Die Website „Scripped“ war ein Drehbuchdienst, der cloudbasierte Schreibwerkzeuge, Online-Speicher und eine Community zum Lesen und Kritisieren von Drehbüchern in Arbeit bot. „War“ ist das Schlüsselwort in diesem Satz. Letzten Frühling meldeten sich registrierte Benutzer auf einer leeren Seite an, die die erschreckende Meldung enthielt, dass ihr Browser „festgestellt hat, dass der Server die Anfrage für diese Adresse auf eine Weise umleitet, die niemals abgeschlossen wird.“
Kein Aprilscherz oder Trick-or-Treat; Bald zeigte eine Meldung auf der Startseite an, dass nach einem kürzlichen Eigentümerwechsel der Website der reguläre Sicherungsprozess fehlschlug – und dabei alle vorherigen Sicherungen gelöscht wurden. Die früheren Eigentümer hatten ihre Sicherungen zerstört, sodass von der gesamten gemeinsamen Arbeitsdatenbank der Community nur noch ein Server-Image aus dem Jahr 2010 übrig blieb.
Laut der (inzwischen entfernten) Seite, wenn Autoren keine Sicherungskopie ihrer Arbeit aufbewahrten, „bedauern wir, [ihnen] mitteilen zu müssen, dass sie nicht mehr existiert.“ Man müsste annehmen, dass die meisten Benutzer lokale Sicherungen ihrer Arbeit aufbewahrten und sich nicht vollständig auf Cloud-Speicher für ihre Drehbücher verlassen würden; dennoch muss der Verlust ihrer kreativen Leistung verheerend sein. (Ich habe einen Freund, einen talentierten Fernsehautor, der bei einem ähnlichen Ereignis im Jahr 2011 jahrelange Materialien verlor; meines Wissens hat er seitdem nicht mehr geschrieben.)
Jedes Mal, wenn wir die Kontrolle über unsere Daten aufgeben oder unser geistiges Eigentum auslagern, setzen wir uns und unsere Existenz aufs Spiel. Bei Kepner-Tregoe schulen wir unsere Kunden darin, ein Tool namens „Potenzielle Problemanalyse“ zu verwenden, um solche Bedrohungen zu reduzieren. In sechs Schritten können Kunden Aktionspläne erstellen, die sowohl die Wahrscheinlichkeit eines katastrophalen Ereignisses verringern als auch schnell erkennen, wann es an der Zeit ist, einen (definierten) „Plan B“ einzusetzen.
Die Analyse beginnt mit der spezifischen Formulierung der zu schützenden Aktion. Spezifisch zu sein ist wichtig: „Betreiben eines webbasierten Dienstes“ ist weit gefasst und kann es schwierig machen, eine klare Liste von Risiken zu identifizieren; „Erstes vollständiges Backup auf neuen Servern durchführen“ ist besser, um die Art des kreativen Denkens anzuregen, die zu Ergebnissen führt.
Als Nächstes holen wir Experten (und Skeptiker) hinzu, um Ideen zu sammeln und „Potenzielle Probleme zu identifizieren“, indem wir fragen: „Was kann schiefgehen, wenn wir dies tun?“ Auch hier ist Spezifität entscheidend. Wir sehen häufig Teams, die ein mögliches Problem wie „Backup schlägt fehl“ angehen. Aber welche verschiedenen Fehlermodi gibt es? Sind sie alle gleichermaßen wahrscheinlich? Gleichermaßen katastrophal? Wird auf sie identisch reagiert? Wenn die Antwort auf eine dieser Fragen „Nein“ lautet, sollte das potenzielle Problem weiter präzisiert werden.
Im Allgemeinen erfordert das Auflisten von „was schiefgehen kann“ nicht viel Aufwand; die Zeit oder die Ressourcen, um alles auf dieser Liste zu bewältigen, schon. Viele Organisationen haben ihre eigenen FMEA-ähnlichen Matrizen zur Priorisierung von Risiken. Eine Alternative besteht darin, zwei verschiedene Dimensionen zu identifizieren – die Wahrscheinlichkeit eines Fehlers und separat dessen Auswirkungen –, um sich auf die kritischsten Risiken zu konzentrieren.
Von dort aus ist es nur natürlich, sofort handeln zu wollen; wir ermutigen Kunden, innezuhalten und die „Wahrscheinlichen Ursachen“ der hochprioritären potenziellen Probleme zu identifizieren. Wenn wir eine Ursache eliminieren oder zumindest ihre Wahrscheinlichkeit verringern, haben wir einen großen Schritt getan, um sicherzustellen, dass das potenzielle Problem nicht auftritt. Auf die Gefahr hin, redundant zu sein: Je spezifischer die wahrscheinliche Ursache, desto besser die Chance, sie zu verhindern – „Hardwarefehler“ ist offen für Interpretationen; „SSE-Controller fallen aus“ ist etwas, das beherrschbar ist. Indem wir die Grundursache verstehen, gehen wir das potenzielle Problem direkter und gezielter an.
Wir erlauben uns dann, Maßnahmen zu ergreifen – „Vorbeugende Maßnahmen“, was genau das bedeutet, was der Name impliziert. Die Absicht ist, die wahrscheinliche Ursache zu verhindern und so unseren Plan zu schützen. Vorbeugende Maßnahmen können entweder die wahrscheinliche Ursache direkt angehen oder einfach verhindern, dass die Ursache das potenzielle Problem erzeugt. (Es mag beispielsweise unmöglich sein, einen Netzausfall zu verhindern, aber vorbeugende Maßnahmen wie die Installation von unterbrechungsfreien Stromversorgungen können verhindern, dass dieser Ausfall Geräte stilllegt).
Viele Organisationen, die des „Feuerlöschens“ müde sind, hören hier auf. Nach der Entwicklung einer perfekten Lösung und der Installation unzähliger Maßnahmen zur Problemvermeidung scheint es unvorstellbar, dass tatsächlich schlimme Dinge passieren könnten. Kluge Teams wissen, dass sie dieser Kombination aus Hochmut und mangelnder Vorstellungskraft nicht zum Opfer fallen dürfen.
Der vorletzte Schritt einer guten PPA beginnt damit, sich vorzustellen, dass das Problem aufgetreten ist und es an der Zeit ist, seine Auswirkungen zu minimieren – die Festlegung von „Notfallmaßnahmen“ ist das, was benötigt wird. Die Herausforderung besteht nicht darin, sich Gedanken darüber zu machen, warum das Problem aufgetreten ist, sondern zu fragen: „Was werden wir tun, wenn es passiert?“ Häufig finden Teams keine tiefere Antwort als „rückgängig machen“ (CABs wollen immer den „Rollback-Plan“ wissen); manchmal ist das nicht möglich, und andere Male ist es klüger, in den metaphorischen Schleudergang zu gehen, um zu entkommen. Die Ironie hierbei ist, dass Backup-Lösungen eine Notfallmaßnahme sind – sie werden ausgelöst, wenn die primären Daten entweder zerstört oder gelöscht werden.
(Es ist sicherlich eine Binney-Regel, wenn auch noch nicht zu einem Binney-Gesetz erhoben: Sie werden immer, irgendwann, Notfallmaßnahmen ergreifen; es ist besser, dies in einem Konferenzraum zu tun, gemütlich Kaffee vor einem Whiteboard schlürfend, als wenn alles schiefgegangen ist, Kollegen in Panik geraten, Geräte schmelzen und Auftragnehmer auf die Uhr schauen).
Maßnahmen ohne Verantwortlichkeit nützen niemandem. Das Festlegen klarer Auslöser liefert eine eindeutige Benachrichtigung, dass ein potenzielles Problem tatsächlich aufgetreten ist, und zeigt sowohl die zu ergreifende Notfallmaßnahme als auch, wer sie ergreifen sollte.
Übersicht der potenziellen Problemanalyse:
- Verfassen Sie eine klare, spezifische Aktionsaussage;
- Listen Sie die potenziellen Probleme bei der Ausführung dieser Aktion auf – und priorisieren Sie sie;
- Identifizieren Sie die wahrscheinlichen Ursachen der hochprioritären potenziellen Probleme;
- Entwickeln (und zuweisen) Sie vorbeugende Maßnahmen, die die wahrscheinliche Ursache beseitigen;
- Planen Sie Notfallmaßnahmen, die die Auswirkungen des potenziellen Problems mindern, falls es eintreten sollte; und
- Legen Sie Auslöser fest, die anzeigen, wann die Notfallmaßnahme eingeleitet werden sollte.
Hätten die neuen Eigentümer von Scripped erkannt, „was schiefgehen könnte“ mit ihrem Backup, mit dem Verständnis, dass sie keine früheren Backups besaßen, hätten sie wahrscheinlich vorbeugende Maßnahmen ergriffen, um das Debakel zu vermeiden. Andernfalls, wenn sie ein oder zwei klare Notfallmaßnahmen identifiziert hätten, hätten sie kritische Daten retten können, bevor es zu spät war. Stattdessen sind sie zu einem von zu vielen warnenden Beispielen geworden.
