Häufige Fallstricke, die es zu meiden gilt
- 7 Minuten
Die Roadmap, die wir für die ersten Schritte mit dem Prozess der Incidentanalyse erläutert haben, ist nützlich, aber es kann auch hilfreich sein, sich über einige der Probleme zu informieren, die in diesem Verlauf auftreten können.
In dieser Lektion erfahren Sie mehr über häufige Fallstricke, in die andere während der Incidentanalyse geraten sind, und wie Sie sie vermeiden können.
Fallstrick 1: Zuschreibung zu „menschlicher Fehler“
Möglicherweise erinnern Sie sich, dass „Pilotenfehler“ (auch bekannt als „menschlicher Fehler“) die Schlussfolgerung war, zu der die ersten Ermittler in der B-17-Geschichte gelangt sind, mit der wir dieses Modul begonnen haben. Kehren wir zu dieser Geschichte zurück.
In dieser Einführung haben wir die Möglichkeit aufgebracht, dass die erzielten Schlussfolgerungen Sie unzufrieden zurücklassen. Sie waren definitiv nicht zufriedenstellend für Alphonse Chapanis, einen Militärpsychologen, der von der US-Air-Force mit der Untersuchung dieser Incidents beauftragt wurde. Er bemerkte unter anderem, dass diese Unfälle für die B-17 und eine kleine Anzahl anderer Flugzeuge spezifisch waren. Es gab Tausende von C-47-Transportflugzeugen, die gleichzeitig in Westeuropa im Einsatz waren, aber keine C-47 hatte jemals einen ähnlichen Incident erlebt.
Daher interviewte er Piloten, und basierend auf dem, was er von ihnen erfahren hat, schaute er sich die B-17-Cockpits an. Er stellte fest, dass es zwei Schalter gab: den Schalter „Gang“ und den Schalter „Klappen“. Die Schalter waren ungefähr 8 cm voneinander entfernt im Cockpit positioniert. Ihre Bedienung war identisch. Sie waren einfach zu leicht zu verwechseln, und genau das passierte bei diesen Incidents. Wenn Sie gerade ein Flugzeug gelandet haben, werden die Klappen ausgefahren sein, und vor dem Parken fahren Sie sie ein. Deshalb hat Chapanis etwas anderes ausprobiert.
Er fixierte ein kleines Gummirad an dem Schalter für die Gangschaltung und eine harte Drehklappe an dem Schalter für die Klappen, und so passierten keinerlei Unfälle mehr.
Er ist mittlerweile als einer der Gründer des Gebiets der Ergonomie – das Studium der Bedeutung von Gestaltungsfaktoren für die menschliche Leistung – bekannt, und er hat eine einfache Beobachtung gemacht: das Design des Cockpits kann sich auf die Wahrscheinlichkeit menschlicher Fehler auswirken. Diese Methode hat die Konstruktion aller modernen Flugzeuge verändert. Die beiden Schalter in aktuellen Flugzeugen sind jetzt sehr unterschiedlich, wie es durch das Bundesgesetz in den USA vorgeschrieben ist.
Warum haben wir Ihnen diese Geschichte erzählt?
Menschen machen Fehler. Jedoch sind menschliche Fehler keine Ursache, sondern ein Symptom. Wenn ein menschlicher Fehler als Grund für ein Versagen angesehen wird, wird die Untersuchung an diesem Punkt beendet, statt dass der Incident weiter analysiert wird.
Das Design des Systems, der Organisationskontext und der persönliche Kontext wirken sich allesamt darauf aus, wann, wie und mit welchen Auswirkungen Menschen Fehler machen. „Menschlicher Fehler“ ist eine Bezeichnung, die bewirkt, dass Sie die Untersuchung an einem bestimmten Punkt beenden, gerade wenn Sie eigentlich im Begriff sind, etwas Interessantes über Ihr System herauszufinden.
Das Problem mit der Schlussfolgerung „menschlicher Fehler“ bei Untersuchungen besteht darin, dass Sie vergessen, dass das, was Menschen zu diesem Zeitpunkt gemacht haben, für sie durchaus einen Sinn ergeben hat. Fehler sind definitionsgemäß nicht beabsichtigt, deshalb wollten sie keinen Fehler machen.
Wenn wir einen „menschlichen Fehler“ sehen oder hören, ist dies ein Signal dafür, dass wir genauer hinsehen müssen. Wenn wir dazulernen möchten, dürfen wir die Untersuchung nicht beenden, sobald wir einen menschlichen Fehler finden. Doch dies ist oft der Fall. Wie uns die Geschichte mit den B-17-Fliegern zeigt, lernen wir genau dann interessante Dinge über unser System, wenn wir über den menschlichen Fehler hinausblicken.
Fallstrick 2 Kontrafaktische Argumentation
Kontrafaktisch bedeutet „gegen die Fakten“, und kontrafaktische Argumentation bezieht sich auf das Erzählen einer Geschichte von Ereignissen, die nicht stattgefunden haben, um die Ereignisse zu erklären, die geschehen sind. Dies ist nicht sinnvoll, und es wird auch dadurch nicht sinnvoller, dass Menschen dazu neigen, es immer wieder zu tun.
Sie können kontrafaktische Statements anhand von Schlüsselformulierungen erkennen:
- Könnte
- Sollte
- Hätte
- Fehler bei
- Nicht
- Wenn doch nur
Einige Beispiele für kontrafaktische Statements im Zusammenhang mit Incidentanalysen:
„Das Überwachungssystem hat das Problem nicht erkannt.“
„Der Techniker hat die Gültigkeit der Konfiguration vor der Anwendung nicht überprüft.“
„Dies könnte in der Canary-Umgebung übernommen worden sein.“
Das Problem mit diesem Argumenttyp bei einer Incidentanalyse besteht darin, dass Sie über Geschehnisse sprechen, die nicht vorgefallen sind, statt sich die Zeit zu nehmen, zu verstehen, wie das, was passiert ist, geschehen ist. Aus einer solchen Spekulation lernen wir nichts.
Fallstrick 3 Normative Sprache
Normative Sprache impliziert häufig, dass es eine „offensichtlich richtige“ Vorgehensweise gab, die die Betreiber hätten befolgen müssen, und die Handlungen dieser Betreiber werden im Nachhinein beurteilt.
Normative Sprache kann normalerweise an der Nutzung von Adverbien wie etwa „unangemessen“, „fahrlässig“ oder „eilig“ identifiziert werden.
Normatives Denken führt Sie dazu, Entscheidungen auf der Grundlage von daraus resultierenden Ergebnissen zu beurteilen. Diese Vorgehensweise ist nicht logisch, da das Ergebnis die einzige Information ist, die für die Betreffenden nicht verfügbar war, als sie die Entscheidungen und Urteile getroffen haben.
Normative Sprache kann auch im umgekehrten Sinn verwendet werden. Benutzer können die Betreffenden loben, dass sie etwa „angemessen“ agiert haben. Aber auch hierbei wird das Urteil häufig unter dem Vorteil getroffen, dass inzwischen Informationen vorliegen, die die betreffenden Personen nicht hatten.
Das Problem bei der normativen Sprache ähnelt dem Problem bei der kontrafaktischen Argumentation: Wenn wir Urteile basierend auf Informationen treffen, die während des Incidents für die beteiligten Personen nicht verfügbar waren, werden wir nicht verstehen, inwiefern die Handlungen der Betreiber zu diesem Zeitpunkt für sie sinnvoll waren.
Fallstrick 4 Mechanistische Argumentation
Mechanistische Argumentation bezieht sich auf das Konzept, dass ein bestimmtes Ergebnis aus dem Eingriff abgeleitet werden kann. Manchmal wird dies auch als Einmischungssyndrom (Meddling-Kids-Syndrom, ein von Jessica DeVita geprägter Begriff) bezeichnet; hier liegt die Annahme zugrunde: „Unser System hätte einwandfrei funktioniert…wenn sich niemand eingemischt hätte.“
Wenn Sie im Rahmen einer Incidentanalyse mechanistisch argumentieren, bauen Sie Ihre Schlussfolgerungen auf dem Irrtum auf, dass die Systeme, mit denen und innerhalb derer Sie arbeiten, im Grunde ordnungsgemäß funktionieren und der Fehler nicht aufgetreten wäre, wenn sich niemand eingemischt hätte.
So funktionieren Systeme jedoch nicht.
Um diesen Punkt zu veranschaulichen, stellen Sie sich folgendes Szenario vor: Sie arbeiten an einem Produktionsdienst. Nun wird Ihnen mitgeteilt, dass Sie diesen Dienst nicht mehr anrühren oder nicht mehr mit diesem Dienst arbeiten dürfen. Alles außerhalb Ihres Teams arbeitet weiterhin wie zuvor: Kunden verwenden weiterhin den Dienst, externe Abhängigkeiten ändern sich weiterhin, das Internet funktioniert normal.
Sie können jedoch keine Änderungen am Code oder an der Konfiguration vornehmen. Keine Bereitstellungen, keine Vorgänge auf Steuerungsebene – nichts.
Glauben Sie, dass Ihr Dienst nach einem Tag weiterhin erwartungsgemäß ausgeführt wird? Nach einer Woche? Nach einem Monat? Nach einem Jahr? Wie lange können Sie realistischerweise erwarten, dass Ihr Dienst ohne menschliches Eingreifen weiterhin ausgeführt wird? In den meisten Fällen wäre dies nicht der Fall.
Diese Denkübung führt uns zu einem wichtigen Schluss:
Menschliche Anpassungsfähigkeit ist erforderlich, um unsere Systeme am Laufen zu halten.
Der einzige Grund, aus dem Ihre Systeme überhaupt laufen, sind Handlungen von Menschen im Regelkreis. Nur durch menschliche Handlungen und die Fähigkeit, sich an veränderte Umstände anzupassen, kann das System weiterhin funktionieren.
Daher ist es ein Irrglaube, zu schlussfolgern, dass das System „im Grunde funktionierte…wenn sich niemand eingemischt hätte.“ Die Zuverlässigkeit Ihres Dienstes ist in der Tat nicht unabhängig von den Menschen, die daran arbeiten. Sie ist vielmehr ein direktes Ergebnis der Arbeit, die Menschen daran täglich ausführen.
Das Problem bei der mechanistischen Argumentation besteht darin, dass Sie zu der Annahme verleitet werden, den menschlichen Fehler aufzudecken hieße das Problem zu erkennen. Der gleiche menschliche Fehler hat jedoch schon seit Wochen und Monaten laufend improvisiert und sich so angepasst, dass das System noch weiterlaufen konnte. Diese Rolle ist möglicherweise so wichtig, dass sie in Ihrer Incidentanalyse berücksichtigt werden sollte.
Nun, da Sie einige Problematiken kennen, die bei einer Incidentanalyse vermieden werden sollten, können wir mit der nächsten Lektion fortfahren. Hier werden wir einige Methoden untersuchen, die bei einer solchen Überprüfungen hilfreich sind.