safety & risk solutions Tailoring Safer Systems Das Magazin von safety & risk solutions The magazine of safety & risk solutions

Schlagwort: Resilience Engineering

  • Was es heisst, ein System zu schneidern

    Was es heisst, ein System zu schneidern

    Eine Schneiderei, irgendwo in der Innenstadt. Hinterzimmer, zwei Spiegel, ein Tisch voller Stoffbahnen, Kreide und Stecknadeln auf einer Pinnwand. Ein Mann steht auf einem niedrigen Podest, im Rohzuschnitt aus heller Wolle, und der Schneider geht um ihn herum. Er nimmt nicht nur Mass. Er beobachtet. Er sieht, wie der Kunde das Gewicht verlagert, wie er die Schultern hält, ob die Naht hinten einseitig zieht. Eine Markierung mit Kreide, dort, wo es noch nicht passt. Dann wieder Massband, dann ein Stich, dann ein Probieren. Anpassen. Wieder probieren.

    Was hier passiert, ist nicht das Anlegen eines Anzugs. Es ist ein Gespräch zwischen Stoff, Körper und Gewohnheit. Der Schneider weiss, dass kein Mensch genau so steht, wie das Schnittmuster es annimmt. Er weiss, dass die Nähte, die in der Mitte sitzen sollen, sich verschieben werden, sobald der Mensch sich bewegt. Er rechnet damit. Er baut Reserven ein, an Stellen, an denen er weiss, dass der Stoff sich finden muss. Er ist nicht überrascht, wenn er noch zweimal kommen muss. Das ist sein Beruf.

    Was hat diese Werkstatt mit Sicherheit zu tun? Das ist die Frage, der dieses Magazin den Namen verdankt. Die Pointe habe ich im einleitenden Beitrag Drei Annahmen, die wir hinter uns lassen müssen ausgeführt, kurz wiederholt: Sicherheit entsteht nicht, wenn Menschen sich an Systeme anpassen, sondern wenn Systeme so gestaltet werden, dass sie sich an Menschen anpassen lassen. Tailoring Safer Systems. Was im Englischen wie ein verschmolzenes Doppelwort klingt, ist im Deutschen unhandlicher: Systeme schneidern. Mass nehmen, Schnitt zeichnen, Probieren, Tragen, Nachbessern, der Prozess wiederholt sich, mit anderer Sache. Und genau wie in der Schneiderei ist es kein einmaliger Akt, sondern eine Haltung.

    Was diese Haltung an Konzept und Werkzeug verlangt, will ich hier ausbreiten. Drei Prinzipien, jedes mit einem Begriff, den du aus der Literatur kennst.

    Mass nehmen, nicht annehmen

    Der Schneider, der das Massband nicht aus der Hand legt, weiss etwas, das in vielen Sicherheitsabteilungen als überflüssiger Aufwand gilt: dass die Realität nicht im Schnittmuster steht.

    Steven Shorrock und Claire Williams haben die Unterscheidung, die seit Hollnagel zum Kernvokabular der Human-Factors-Tradition gehört, in Human Factors and Ergonomics in Practice so einfach formuliert, dass sie als Test funktioniert. Work-as-Imagined ist die Vorstellung von Designern, Auditierenden, Geschäftsleitungen davon, wie Arbeit verrichtet wird. Work-as-Done ist, was Mitarbeitende tatsächlich tun. Dazwischen liegt regelmässig eine Lücke. Die Frage ist nicht, ob es sie gibt. Die gibt es immer. Die Frage ist, ob die Organisation sie kennt.

    Wer sie nicht kennt, schneidert in die Annahme hinein. Er entwirft Verfahren auf Grundlage dessen, was sein Modell sagt. Und das Modell sagt, was bequem ist, was nach Massstäben des Audits noch lesbar ist, was geschäftsleitungstauglich klingt. Das Verfahren passt dann zur Annahme, nicht zur Praxis. Nach kurzer Zeit driften Praxis und Verfahren auseinander, ohne dass jemand das wahrnimmt, weil niemand jemals nachgemessen hat, wie der Stoff tatsächlich fällt.

    Was Mass nehmen konkret heisst, ist nicht spektakulär. Es heisst Beobachten. Es heisst Walk-the-Talk: das, was angelsächsisch als Gemba Walk aus der Lean-Tradition bekannt ist und in der Sicherheitswelt unter Begriffen wie «operational learning visit» wandert. Es heisst Shadowing über mehr als eine Schicht. Es heisst Fragen, die offen genug sind, dass sie nicht schon die Antwort enthalten: nicht «Halten Sie sich ans Verfahren?», sondern «Wann hat das Verfahren bei Ihnen das letzte Mal nicht gepasst, und was haben Sie stattdessen gemacht?»

    Diese Fragen produzieren regelmässig Antworten, die niemand sehen will. Mitarbeitende beschreiben Workarounds, die in den Augen der Compliance Verstösse sind und in den Augen des Systems die einzige Methode, an einem Tag durchzukommen, an dem ein Werkzeug fehlt, eine Vertretung neu ist, die Anlage seit dem Update zickt. Die Versuchung ist gross, diese Antworten als Defekt zu lesen. Und damit zu schliessen. Die Anstrengung besteht darin, sie als Befund zu lesen.

    Wer Mass nimmt, akzeptiert, was er sieht. Was er sieht, ist regelmässig nicht das, was im Schnittmuster steht. Genau deshalb steht er da.

    Mass nehmen ist nicht Compliance auf Probe. Es ist die Bereitschaft, etwas zu sehen, was die eigene Annahme widerlegt.

    Den Stoff respektieren

    Nicht jeder Stoff lässt sich beliebig schneidern. Wer einen weichen Strick wie einen festen Wollstoff behandelt, bekommt eine Naht, die nicht hält. Der Schneider kennt die Eigenschaften des Materials, bevor er den Schnitt zeichnet, und passt den Entwurf dem Stoff an, nicht umgekehrt.

    Auf Organisationen übertragen: Kontext, Kultur und Geschichte sind das Material, mit dem ein System geschneidert wird. Was in einer Fluggesellschaft funktioniert, in der Crew Resource Management seit Jahrzehnten als Praxis verankert ist, lässt sich nicht ohne Übersetzung in eine Industrieorganisation tragen, in der Hierarchien anders gelebt werden und «Stop the Line» als Konzept noch erklärt werden muss. Was auf einer Pflegestation greift, an der die Stationsleitung über Jahre eine Meldekultur aufgebaut hat, läuft in einer anderen ins Leere, in der jede Meldung erst durch zwei Schichten Personalabteilung wandert, bevor sie jemand zu sehen bekommt.

    David Snowdens Cynefin-Framework hilft an dieser Stelle. Es unterscheidet, einfach gesagt, zwischen zwei Sorten von Problemen: kompliziert und komplex. Komplizierte Probleme sind solche, bei denen die Beziehung zwischen Ursache und Wirkung mit genug Expertise erkennbar ist: eine Maschine, eine Buchhaltung, ein Bauplan. Best Practices funktionieren hier. Komplexe Probleme sind solche, bei denen Ursache und Wirkung nur retrospektiv lesbar sind, weil das System sich auf jede Intervention hin verändert. Kultur, Risikoverhalten, Lernfähigkeit gehören in diese Kategorie. Best Practices funktionieren hier nicht. Was in einer Organisation gewirkt hat, ist nicht garantiert dasselbe, was in der nächsten wirkt.

    Der häufigste Fehler in Sicherheitsprogrammen, die ich begleite, ist die Verwechslung dieser beiden Sorten. Ein erprobtes Konzept aus einem Best-Practice-Sammelband wird als universelle Lösung verkauft, einer Organisation übergestülpt, die einen anderen Stoff hat. Und jeder ist überrascht, wenn die Naht nicht hält. Was die Organisation gebraucht hätte, war nicht die Lösung. Es war die Diagnose: was für ein Stoff liegt vor uns?

    Den Stoff zu respektieren heisst nicht, alles in Ordnung zu finden, wie es ist. Es heisst, den Schnitt am Material zu prüfen, bevor man die Schere ansetzt. Wer das nicht tut, baut ein Sicherheitsprogramm, das in den Quartalsbericht passt und in der Praxis nicht.

    Anpassung einplanen

    Ein guter Schnitt hat Reserve. Der Schneider zieht den Stoff nicht so straff, dass er beim ersten Atmen reisst. Er weiss, dass der Körper sich verändert, dass der Tag verändert, dass der Stoff sich nach den ersten Trageperioden setzt. Er rechnet das ein. Wo er die Reserve einbaut, wo er sie ausspart, das ist Handwerk. Wer die Reserve abschafft, sich an die exakte Vermessung bindet, baut ein Kleidungsstück, das exakt einmal passt. Im nächsten Moment nicht mehr.

    Erik Hollnagels Arbeit kreist seit Jahren um diese Einsicht in der Sicherheitssprache. In FRAM (der Functional Resonance Analysis Method) argumentiert er gegen die linearen Vorfallmodelle, die Variation als Defekt verstehen. Variation, schreibt Hollnagel, ist nicht das Gegenteil von Funktion. Sie ist eine Bedingung von Funktion. Komplexe sozio-technische Systeme funktionieren, weil ihre Komponenten (Menschen, Werkzeuge, Verfahren) flexibel genug sind, um auf Bedingungen zu reagieren, die nicht im Plan stehen. Wenn das Plansystem versucht, diese Variation auszuschalten, schaltet es zugleich die Adaptionsfähigkeit aus.

    Was das im Alltag heisst, ist konkret: ein gutes Verfahren beschreibt nicht nur den Sollpfad, sondern macht sichtbar, unter welchen Bedingungen es greift. Es kennt die Annahmen, die es macht, und es kennt die Stellen, an denen es brechen wird, wenn die Annahmen nicht stimmen. Ein gutes Verfahren ist sich seiner Grenzen bewusst. Mehr noch: ein gutes System hält Ressourcen frei, die nicht in der Planung gebunden sind (Slack im Personalplan, Zeit in der Schicht, Spielraum in der Kommunikation), weil ohne sie keine Anpassung möglich ist. Was wie Ineffizienz aussieht, ist die Voraussetzung dafür, dass das System überhaupt durch den Tag kommt, an dem die Realität vom Plan abweicht. Und sie weicht ab. Jeden Tag.

    Anpassung einzuplanen heisst, dem System Erlaubnis zur Anpassung zu geben. Nicht hinterher, im Schadensfall, sondern vorher, im Entwurf. Es heisst, Spielraum bewusst zu gestalten und nicht beiläufig zu dulden. Und es heisst, sichtbar zu machen, was sonst unsichtbar bleibt: dass die Workarounds, die niemand zugibt, oft die letzten Anpassungen sind, die ein überstandardisiertes System überhaupt noch zulässt.

    Was Schneidern nicht ist

    Konfektion liegt im Lager und wartet auf jemanden, der hineinpasst. Sie ist effizient, sie ist günstig, sie ist im Reporting sauber. Sie ist eine vollständige Lösung, solange das Mass stimmt. Wenn nicht, wird sie zur Quelle eines stillen Kompromisses: der Mensch passt sich dem Anzug an, hält die Schultern anders, atmet flacher, bewegt sich, als gehörte er ins Schnittmuster. Eine Weile geht das gut.

    Sicherheit aus dem Compliance-Katalog funktioniert nach genau dieser Logik. Sie kommt mit fertigen Verfahren, mit standardisierten KPIs, mit Audit-Schablonen, die zu allem passen, weil sie nichts ansehen. Das Problem ist nicht, dass sie strukturiert. Das Problem ist, dass sie ihre eigene Beschreibung des Systems für das System hält. Wenn die Realität davon abweicht (und sie weicht ab), ist im Katalog keine Anpassung vorgesehen. Was bleibt, ist die Mahnung, sich gefälligst ans Verfahren zu halten.

    Dem gegenüber steht der Schneider, der sein Massband nicht aus der Hand legt. Der weiss, dass er noch zweimal kommen muss. Der die Reserve im Stoff respektiert. Der den Schnitt nicht heute fertig zeichnet, sondern in einem Gespräch mit dem entwirft, was er vor sich hat. Der akzeptiert, dass das Endprodukt nicht perfekt im ersten Versuch ist und dass Nachbessern Teil des Berufs ist, nicht ein Eingeständnis von Fehlern.

    Genau das meint Tailoring Safer Systems. Spielraum gestalten statt abschaffen. Anpassung sichtbar machen, damit das System aus ihr lernen kann. Das ist anstrengender als ein dichter Katalog. Es ist auch das einzige, was unter Bedingungen funktioniert, in denen das nächste Mass schon wieder ein anderes ist.

    Quellen

    • Steven Shorrock & Claire Williams (Hrsg.) – Human Factors and Ergonomics in Practice: Improving System Performance and Human Well-Being in the Real World, CRC Press 2017
    • Erik Hollnagel – FRAM: The Functional Resonance Analysis Method – Modelling Complex Socio-technical Systems, Ashgate 2012
    • David J. Snowden & Mary E. Boone – A Leader’s Framework for Decision Making, Harvard Business Review, November 2007
    • Erik Hollnagel – Safety-II in Practice, Routledge 2018
  • Drei Annahmen, die wir hinter uns lassen müssen

    Drei Annahmen, die wir hinter uns lassen müssen

    Es ist die Nacht zum 28. März 1979, kurz nach vier Uhr morgens. Im Kontrollraum von Three Mile Island, Block 2, leuchtet eine Anzeige: Druckablassventil geschlossen. Die Anzeige sagt das, weil sie keine Stellung misst. Sie zeigt das Steuersignal an, den Befehl, der dem Ventil gegeben wurde, sich zu schliessen. Was das Ventil tatsächlich tut, weiss niemand im Raum. Es ist offen, seit zwei Minuten und dreizehn Sekunden, und es wird die nächsten zwei Stunden offen bleiben.

    In den Stunden, die folgen, werden die Operatoren etwas tun, was die spätere Untersuchung als Hauptursache der Teilkernschmelze identifizieren wird: sie drosseln die Notkühlung. Sie tun es, weil ihre Anzeigen sagen, das System sei überfüllt, und weil ihr Training sie gelehrt hat, genau diese Lage zu vermeiden. Sie handeln rational unter dem, was sie sehen. In den Tagen darauf wird die Presse von «menschlichem Versagen» sprechen.

    Genau dieser Reflex (die Diagnose «menschliches Versagen», die einer Szene wie dieser sofort folgt) sitzt hinter den meisten Sicherheitsdialogen, die ich in der Beratungspraxis erlebe. Nicht, weil die Beteiligten unklug handelten. Sondern weil drei Annahmen so tief in unserer Sicherheitstradition verankert sind, dass sie als Selbstverständlichkeiten gelten. Wir lesen sie anders. Was folgt, sind drei Gegenpositionen, eine pro Annahme.

    «Menschliches Versagen» ist eine Diagnose, kein Befund

    Die Statistik kennt jeder, der in diesem Feld arbeitet: 80 bis 90 Prozent aller Vorfälle gehen auf «menschliches Versagen» zurück. Die Zahl wird seit den 1980er-Jahren in Vorträgen, Audits, Geschäftsleitungs-Reportings zitiert, und sie wirkt: sie macht plausibel, dass die Antwort auf Sicherheitsprobleme bei den Menschen liegen muss. Mehr Training, klarere Standards, schärfere Disziplin. Die Logik ist sauber: wenn das Problem im Cockpit sitzt, muss die Lösung im Cockpit sitzen.

    Das Problem mit dieser Logik ist nicht die Statistik. Es ist die Interpretation. Sidney Dekker formuliert es in seinem Field Guide so scharf, dass es weh tut: «Menschliches Versagen» ist nie das Ende einer Untersuchung, es ist der Anfang. Wer Vorfälle damit erklärt, hat aufgehört zu fragen: er hat ein Etikett gefunden und sich zur Ruhe gesetzt. Lokale Rationalität, das Konzept, das Dekker durchgängig schärft, sagt: niemand kommt zur Arbeit mit der Absicht, einen Reaktor zur Kernschmelze zu bringen, einen Patienten zu schädigen, ein Flugzeug zum Absturz zu bringen. Was aus der Vogelperspektive der Untersuchung wie Versagen aussieht, ergab im Moment der Handlung Sinn, gegeben das, was die Person sehen konnte, gegeben den Druck, gegeben das Training.

    Diesen Sinn zu rekonstruieren, ist die eigentliche Arbeit.

    Hollnagel zieht eine zweite Linie ein. Seine Safety-II-Argumentation lautet, vereinfacht: dasselbe, was wir «Versagen» nennen, ist die Kehrseite einer Anpassungskapazität, ohne die das System keine Stunde funktionieren würde. Menschen schaffen täglich, was Verfahren nicht von selbst leisten: sie interpretieren Kontext, sie improvisieren, wenn die Realität von der Skript-Annahme abweicht (was sie ständig tut), sie füllen Lücken, die Designer und Regelwerke offen gelassen haben. Wer den Menschen als Schwachstelle behandelt, beraubt sich der einzigen Resilienzquelle, die das System tatsächlich hat.

    Zurück in den TMI-Kontrollraum, mit dieser Brille gelesen: die Operatoren drosseln die Notkühlung, weil ihre Anzeigen sagen, das System sei überfüllt, und weil ihr Training sie auf genau dieses Risiko hin sensibilisiert hat. Ihre Entscheidung ist im Moment der Handlung die einzige kohärente Interpretation der verfügbaren Daten. Dass wir heute wissen, das Ventil war offen und das System unter-, nicht überfüllt, das ist die Information der Untersuchung, nicht die Information der Operatoren. Diese Asymmetrie zwischen Untersucher und Akteur, «Hindsight Bias» im Vokabular der Forschung, ist nicht ein methodischer Schönheitsfehler. Sie ist die strukturelle Bedingung, unter der jede Vorfalluntersuchung steht. Wer sie nicht reflektiert, sieht in jeder Vergangenheit, was die Beteiligten hätten tun können. Und übersieht, was sie tatsächlich konnten.

    In Schulungen frage ich Teilnehmende inzwischen routinemässig: Was ist in eurem Betrieb die häufigste Ursache von Zwischen- und Unfällen? Die Antwort kommt jedes Mal, ohne Ausnahme: menschliches Versagen. Sie kommt schnell, sie kommt selbstverständlich, und sie kommt vor der eigentlichen Arbeit der Schulung. Im Lauf der Stunden danach folgt regelmässig der Moment, an dem den Teilnehmenden etwas auffällt. Und es ist nicht ein neuer Begriff, kein zusätzliches Werkzeug, sondern ein Perspektivwechsel: ihre eigenen Vorfalluntersuchungen sind, wie sie selbst feststellen, genau dort zu Ende gegangen, wo sie hätten beginnen sollen. Was das kostet, ist nicht nur eine schwächere Untersuchung. Es ist die Bereitschaft der Mitarbeitenden, beim nächsten Mal überhaupt etwas zu melden.

    Die Frage, die uns näher liegt als «Wie verhindern wir menschliche Fehler?», ist die: Wie unterstützt unser System die Anpassungsarbeit, die Menschen leisten müssen, damit es überhaupt funktioniert?

    Menschliches Versagen ist nie eine Erklärung. Es ist eine Diagnose, die mehr über die Diagnostizierenden sagt als über den Vorfall.

    Compliance ist Mindeststand, nicht Sicherheit

    Die zweite Annahme folgt aus der ersten wie ein Schatten. Wenn der Mensch das Risiko ist, dann sind Vorschriften, Audits und Zertifikate die Kontrollinstrumente. Sicherheit wird zur Frage, ob die richtigen Häkchen gesetzt sind. Geschäftsleitungen lesen Sicherheits-KPIs (Lost-Time-Injury-Rate, Audit-Befunde, Schulungsquoten) und ziehen daraus Schlüsse über den Zustand des Unternehmens. Die Steuerung ist klar, das Reporting ist sauber, die Verantwortung ist verteilt. Es gibt einen Grund, warum dieses Modell so robust überlebt: es ist anschlussfähig an Recht, Versicherung und Konzern-Reporting.

    Das Modell hat nur ein Problem: Compliance und Sicherheit fallen regelmässig auseinander. Boeings 737 MAX hatte eine FAA-Zertifizierung, einen Compliance-Status, der nach jedem auditierbaren Massstab grün war. Und ein MCAS-System, dessen Fehlfunktion 346 Menschen das Leben kostete. Der Bristol Heart Scandal in den 1990er-Jahren zeigte ein Spital, dessen interne Sicherheitsindikatoren keine deutlichen Auffälligkeiten zeigten, während die Mortalität in der Kinderherzchirurgie sich auf das Doppelte des britischen Durchschnitts gehoben hatte. In beiden Fällen wurden die Signale gemeldet, von Insidern, denen niemand zuhören wollte, weil das Compliance-Bild sauber war.

    Was zwischen den Audits passiert, ist die eigentliche Sicherheitsgeschichte. Diane Vaughan hat in ihrer Studie zur Challenger-Katastrophe einen Begriff dafür geprägt: «Normalization of Deviance». Drift entsteht selten als bewusste Regelverletzung. Sie entsteht, weil das System unter realen Bedingungen schrittweise von der Norm abweicht (eine kleine Toleranz hier, ein zeitlich verkürzter Schritt dort) und weil diese Abweichungen in der Mehrzahl gut gehen. Jede Wiederholung ohne Konsequenz erweitert die Bandbreite des Akzeptablen, ohne dass jemand eine bewusste Entscheidung getroffen hätte. Aus Sicht der Audit-Logik ist diese Drift unsichtbar: am Audit-Tag stimmt das Bild wieder, weil alle wissen, was zu zeigen ist. Aus Sicht der Lernkapazität wäre sie sichtbar, wenn die Organisation die Mechanismen hätte, sie zu sehen.

    Was diese Fälle gemeinsam haben, ist nicht ein Compliance-Versagen. Es ist ein Lernversagen. Compliance ist eine Eigenschaft eines Zeitpunkts: sie sagt, dass zum Zeitpunkt X die Regel Y eingehalten war. Sicherheit ist eine Eigenschaft eines Prozesses: sie sagt, dass die Organisation in der Lage ist, schwache Signale aufzugreifen, Annahmen zu revidieren und ihr eigenes Verhalten zu korrigieren, bevor das nächste Audit-Datum die Bühne betritt. Das eine ist ein Ist-Zustand, das andere ist eine Fähigkeit. Eine Organisation kann zu einem beliebigen Zeitpunkt vollständig compliant und gleichzeitig komplett blind für die Drift sein, in der sie sich befindet.

    Die operative Frage, die daraus folgt, ist nicht: «Sind wir compliant?» Sie ist: Werden Schwächen sichtbar, ohne bestraft zu werden? Werden Beinahevorfälle behandelt wie Lerngelegenheiten oder wie Reputationsrisiken? Wird das System nach jedem Vorfall klüger oder nur defensiver? Just Culture, im präzisen Sinn von Reason und Dekker, ist die Voraussetzung dafür. Sie ist nicht das Plakat im Pausenraum.

    Sie ist die gelebte Antwort darauf, was passiert, wenn man etwas zugibt, das man hätte verschweigen können.

    Standardisierung schafft Brittleness, nicht Resilienz

    Die dritte Annahme ist die hartnäckigste, weil sie dem Sicherheitsreflex am tiefsten entspricht. Wenn etwas schiefgeht, erhöhen wir den Standardisierungsgrad. Wir schreiben den nächsten Schritt in die SOP, wir engen den Spielraum ein, wir formalisieren, was zuvor Erfahrungssache war. Die zugrunde liegende Annahme ist sauber-mechanisch: Variation ist Defekt, Vereinheitlichung ist Sicherheit. Was sich nicht abweichend verhält, kann nicht falsch laufen.

    Die Annahme stimmt für einfache, lineare Systeme. Sie stimmt nicht für die Systeme, mit denen wir es in HRO-nahen Kontexten zu tun haben. Erik Hollnagel benutzt für die Folge des Reflexes ein präzises Wort: Brittleness. Ein überstandardisiertes System verliert die Fähigkeit, sich an Bedingungen anzupassen, die seine Designer nicht antizipiert haben. Es funktioniert exakt so lange, wie die Realität dem Skript folgt. Und die Realität folgt dem Skript nie ganz. In dem Moment, in dem die Abweichung kommt, hat das System keine Reserve, keine Improvisationskapazität, kein Repertoire ausser «weiter wie geplant».

    Was die HOP-Bewegung um Todd Conklin und andere seit den 2010er-Jahren immer wieder zeigt, ist banal und folgenschwer zugleich: jede funktionierende Schicht weicht täglich vom Skript ab. Pflegende kombinieren Anordnungen, die formal nicht so vorgesehen sind, weil das Originalverfahren in der konkreten Situation nicht passt. Industrieoperatorinnen und -operatoren legen kleine Workarounds, weil ein Werkzeug fehlt oder ein Schritt unter Zeitdruck eingespart werden muss. Pilotinnen und Piloten interpretieren Checklisten in einer Reihenfolge, die der Lage angemessen ist. Diese Abweichungen sind nicht das Problem. Sie sind die Sicherheit. Sie sind das, wodurch das System überhaupt durch den Tag kommt.

    Dahinter steht eine grundlegendere Einsicht der Resilience-Engineering-Tradition: Sicherheit ist nicht die Abwesenheit von Variation, sondern die Fähigkeit, Variation zu absorbieren. David Woods nennt das «graceful extensibility»: die Frage, wie weit ein System gestreckt werden kann, bevor es bricht, und wie es sich verhält, während es gestreckt wird. Überstandardisierung optimiert für den Normalfall und ignoriert genau diese Frage. Sie macht das System effizient unter Idealbedingungen und sprödbruchgefährdet unter realen.

    Was Tailoring meint, ist genau das: den Spielraum gestalten statt abschaffen. Leitplanken setzen (die Grenzen, jenseits derer es gefährlich wird) und innerhalb der Leitplanken Anpassbarkeit zulassen, sichtbar machen, lernfähig halten. Das ist anstrengender als ein dichtes Regelwerk, weil es Vertrauen, Gespräch und Kontextwissen voraussetzt. Es ist auch das einzige, was unter Bedingungen funktioniert, in denen Variation nicht abgeschafft werden kann. Pilotinnen oder Piloten, die das Handbuch zur Seite legen, können Heldinnen oder Übeltäter sein. Was sie sind, hängt am System, nicht an ihnen selbst.

    Was das für uns heisst

    Daraus folgt die Position, aus der wir schreiben: Sicherheit entsteht nicht, wenn Menschen sich an Systeme anpassen, sondern wenn Systeme so gestaltet werden, dass sie sich an Menschen anpassen lassen: kontinuierlich, im Betrieb, nicht im Audit-Raum. Genau dieses Massschneidern (dieses laufende Anpassen unter realen Bedingungen) ist das Handwerk, das wir hier ausarbeiten wollen. Nicht, weil die New-View-Linie modisch wäre. Sie ist seit über zwei Jahrzehnten in der Literatur etabliert. Sondern weil die operative Lücke zwischen ihr und der täglichen Praxis weiterhin gross ist.

    Praktisch heisst das: Wir schreiben über Vorfälle, um Bedingungen zu rekonstruieren: die Bedingungen, unter denen vernünftige Menschen vernünftige Entscheidungen trafen, die sich im Nachhinein als folgenreich erwiesen. Methoden behandeln wir als Handwerk, das Übung, Urteilskraft und Kontextwissen voraussetzt. Organisationen lesen wir als lernfähige (oder lern-unfähige) Systeme.

    Zurück nach Three Mile Island, kurz nach vier Uhr morgens. Drei Operatoren stehen vor Anzeigen, von denen eine das Steuersignal zeigt statt der Stellung. Sie folgen ihrem Training, sie drosseln die Notkühlung, weil das Verfahren bei vermutetem Überdruck genau das verlangt. Wir können sie als die Schwachstelle des Systems lesen, oder als die letzten Personen, die in dieser Nacht nach den Regeln gehandelt haben, die ihnen gegeben waren. Welche Interpretation wir wählen, entscheidet, was wir das nächste Mal anders bauen.

    Was wir an dieser Stelle anders bauen, ist nicht in erster Linie eine Anzeige, die die Stellung statt des Steuersignals zeigt. Es ist die Bereitschaft, die Frage zu ändern: nicht «Wer hat versagt?», sondern «Was hat das, was hier passiert ist, in dem Moment plausibel gemacht?» Diese Frage ist anstrengender. Sie führt nicht zu einer Person, die man sanktionieren kann. Sie führt zu einem System, das man umbauen muss.

    Quellen

    • Sidney Dekker – The Field Guide to Understanding Human Error, 3. Aufl., CRC Press 2014
    • Erik Hollnagel – Safety-II in Practice, Routledge 2018
    • Todd Conklin – Pre-Accident Investigations, Ashgate 2012
    • Karl E. Weick & Kathleen M. Sutcliffe – Managing the Unexpected, 3. Aufl., Wiley 2015
    • Charles Perrow – Normal Accidents: Living with High-Risk Technologies, Princeton University Press 1999 (zur TMI-Analyse)
    • Diane Vaughan – The Challenger Launch Decision: Risky Technology, Culture, and Deviance at NASA, University of Chicago Press 1996
  • Erreichen einer optimalen menschlichen Leistung durch effektives Systemdesign

    Erreichen einer optimalen menschlichen Leistung durch effektives Systemdesign

    Das Entwerfen von Automatisierung für komplexe sozio-technische Systeme, um eine optimale menschliche Leistung sicherzustellen, ist ein herausforderndes Unterfangen. Insbesondere in sicherheitskritischen Umgebungen muss sich der Mensch möglicherweise schnell an sich ändernde Anforderungen, Komplexität und Unsicherheit anpassen, um eine optimale Leistung, Effizienz und Betriebssicherheit aufrechtzuerhalten. Unter diesen Bedingungen kann der Mensch von der Automatisierung profitieren. In den meisten Fällen ist die Automatisierung so konzipiert, dass sie Aufgaben mit geringem Wert übernimmt, d.h. Aufgaben, die einfach und leicht zu automatisieren sind. Das Entwerfen von Automatisierung zur Unterstützung des Menschen bei kognitiv anspruchsvollen Aufgaben wie Problemlösung und komplexer Entscheidungsfindung ist jedoch aus verschiedenen Gründen schwieriger. Zunächst ist es erforderlich, ein Verständnis für alle übergeordneten Aufgaben und zugrunde liegenden (menschlichen) kognitiven Funktionen zu erlangen und zu ermitteln, inwieweit diese Aufgaben derzeit durch Automatisierung unterstützt werden und welche Ressourcen der Mensch für die Ausführung benötigt. Zweitens muss bei der Automatisierung von Aufgaben die neue Verteilung von (kognitiven) Funktionen zwischen Mensch und Automatisierung auf einer höheren Ebene überdacht werden. Es muss analysiert werden, welche Organisationsstrukturen erforderlich sind und wie die Kognition zwischen Menschen und Automatisierung geteilt wird (d.h. wie Menschen effektiv arbeiten können). Drittens muss verstanden werden, wie die Automatisierung gestaltet werden soll, so dass sie den Menschen bei der Bewältigung komplexer Aufgaben optimal unterstützt, insbesondere wenn Entscheidungen oder Problemlösungen unter sich schnell ändernden Anforderungen, hoher Komplexität und Unsicherheit erforderlich sind. Die Schaffung von Automatisierung zur Unterstützung des Menschen erfordert daher ein tiefes Verständnis der Strategien, die Menschen bei der Lösung komplexer Probleme und bei der Entscheidungsfindung anwenden. Welche Strategien verfolgen sie und was benötigen sie als Automatisierungsunterstützung? Dieser Artikel gibt einen Überblick über die Bewältigung dieser Herausforderungen.

    Schritt 1: Aufgaben und zugrunde liegende (kognitive) Funktionen eines Systems verstehen

    Wir müssen berücksichtigen, dass wir in den meisten Fällen keine Systeme von Grund auf neu entwickeln. Vielmehr bauen wir auf bestehenden Systemen auf, um in Bezug auf Sicherheit, Effizienz oder andere Leistungsdimensionen eine Verbesserung zu erzielen. Dies bedeutet, dass wir verstehen müssen, welche Aufgaben und zugrunde liegenden (kognitiven) Funktionen derzeit existieren und welche Funktionen derzeit von der Automatisierung unterstützt werden. So können wir ermitteln, wo Möglichkeiten bestehen, Aufgaben oder zugrunde liegende (kognitive) Funktionen weiter zu automatisieren oder vorhandene automatisierte Funktionen zu verbessern. Um herauszufinden, welche Automatisierung den Menschen bei komplexen Aufgaben optimal unterstützt (um eine menschenzentrierte Entscheidungsfindung sicherzustellen), müssen wir zunächst alle Aufgaben und entsprechenden (kognitiven) Funktionen identifizieren. Wir müssen auch die aktuelle Verteilung der Aufgaben (und der zugrunde liegenden kognitiven Funktionen) zwischen Menschen und Automatisierung ermitteln. Einige Aufgaben mit verschiedenen Ebenen der Automatisierungsunterstützung können möglicherweise Menschen zugewiesen werden und einige Aufgaben können vollständig automatisiert werden. Es ist aber auch möglich, dass Aufgaben dynamisch automatisiert oder Menschen zugewiesen werden. Es ist notwendig zu verstehen, wie sich eine Änderung der Aufgabenverteilung im Hinblick auf die gegenseitigen Abhängigkeiten zwischen Mensch und Automatisierung auf das Gesamtsystem auswirken kann. Eine kognitive Funktionsanalyse (Cognitive Function Analysis – CFA) (Boy, 1998) ist ein wichtiges Instrument für Human Factors Engineers und Designer (z.B. UX Engineers), um ein Verständnis für alle Aufgaben und zugrunde liegenden Funktionen eines Systems sowie für die Auswirkungen einer Änderung der Funktionsverteilung zwischen Menschen und Automatisierung zu generieren. Bei der Durchführung eines CFA ist es wichtig, eine breite Palette von Techniken, einschließlich Interviews, Beobachtungen sowie Dokumentationsstudien, zu verwenden. Interviews und Beobachtungen sind wichtig, da sich der Mensch in den meisten Fällen so angepasst hat, dass er das System anders verwendet als ursprünglich beabsichtigt, was häufig nicht dokumentiert ist.

    Schritt 2: Verständnis der Auswirkungen der Funktionszuweisung auf die Systemstabilität

    Eine Änderung der Funktionsverteilung zwischen Mensch und Automatisierung kann sich auf die Systemstabilität auswirken (Straussberger et al., 2008). Bei der Automatisierung bestehender Funktionen, die derzeit dem Menschen zugewiesen sind, muss daher bewertet werden, wie sich die Neugestaltung der kognitiven Funktionen von Mensch und Maschine durch zunehmende Automatisierung auf die Gesamtstabilität eines komplexen sozio-technischen Systems auswirkt. Dies bestimmt letztendlich die Resilienz des Systems, auf alle betrieblichen Anforderungen zu reagieren. Stabilität besteht in verschiedenen Schichten. Sie ist das Ergebnis von Organisationsstrukturen, die mit Verfahren und technischen Systemen verknüpft sind, und spiegelt die Fähigkeit des Systems wider, sich nach einer Störung zu erholen. Die Stabilität sozio-technischer Systeme wird durch zwei Prozesse definiert (Straussberger et al. 2008):

    1. Globale sozio-kognitive Stabilität
    2. Lokale sozio-kognitive Stabilität

    Die globale sozio-kognitive Stabilität befasst sich mit der Angemessenheit der dem Menschen oder der Automatisierung zugewiesenen Funktionen, dem Tempo des Informationsflusses und der damit verbundenen Koordination, indem geeignete Strukturen entworfen werden. Diese Strukturen sind verbunden mit:

    • Autorität
    • Verantwortung
    • Kontrollierbarkeit
    • Fähigkeit

    Probleme können auftreten, wenn diese Strukturen nicht angemessen definiert wurden. Zum Beispiel, wenn Menschen formale Verantwortung haben, aber nicht über die Kontrolle oder die Fähigkeit verfügen, bestimmte Aufgaben oder Funktionen auf hoher Ebene auszuführen. Oder es werden Funktionen vollständig automatisiert, der Mensch bleibt jedoch formal für diese Funktionen verantwortlich, während er nicht über die Kontrolle oder Fähigkeit verfügt, in die Ausführung dieser Funktionen einzugreifen. Probleme können auch auftreten, wenn Funktionen dynamisch dem Menschen oder der Automatisierung zugewiesen werden, oder von Menschen an das System delegiert werden, wobei die Bedingungen, die für die Delegierung erfüllt sein müssen, für Menschen nicht transparent oder gar nicht definiert sind.

    Lokale sozio-kognitive Stabilität bezieht sich auf die Arbeitsbelastung des Menschen, das Situationsbewusstsein und die Fähigkeit, geeignete Entscheidungen zu treffen und Maßnahmen zu ergreifen. Die lokale sozio-kognitive Stabilität hängt hauptsächlich von der Fähigkeit des Menschen ab, die Automatisierung zu verstehen und ein mentales Modell des Systems zu erhalten. Automatisierte Systeme müssen so konzipiert sein, dass Menschen in der Lage sind, Reaktionen automatisierter Systeme auf menschliche Eingaben vorherzusagen (zu antizipieren) sowie angemessenes Feedback zu erhalten und bei Bedarf die Autorität wiederzugewinnen (Boy, 1998). Außerdem muss die Transparenz automatisierter Funktionen berücksichtigt werden, damit der Mensch ein gültiges mentales Modell des Systems, seiner Funktionen und seines Verhaltens entwickeln kann.

    Die Gewährleistung sowohl der globalen als auch der lokalen sozio-kognitiven Stabilität wird einen gemeinsamen Bezugsrahmen gewährleisten und das gemeinsame Situationsbewusstsein zwischen Menschen und automatisierten Systemen unterstützen.

    Schritt 3: Designautomatisierung zur Unterstützung von Expertenentscheidungen

    Das Entwerfen einer Automatisierung zur Unterstützung menschlicher makrokognitiver Funktionen beginnt mit dem Verständnis, wie menschliche Bediener auf ein hohes Maß an Komplexität und Unsicherheit reagieren. Menschen müssen sich möglicherweise an sich ändernde Anforderungen anpassen, was voraussetzt, in die Zukunft extrapolieren und eine erfahrungsbasierte Bewertung erstellen zu können. Es kann auch erforderlich sein, vorauszuplanen und Kapazitäten aufzubauen, um Situationen in naher Zukunft bewältigen zu können. Möglicherweise müssen sie auch Strategien entwickeln, um mit zukünftigen Anforderungen und unerwarteten Situationen umgehen zu können. Solche Strategien können dazu dienen, Komplexität und Unsicherheit entweder zu verringern oder zu bewältigen. Beispiele für Strategien zum Komplexitäts- und Unsicherheitsmanagement sind (Corver & Grote, 2016):

    • Vorausschauendes Denken (Extrapolation der aktuellen Situation in die Zukunft basierend auf früheren Erfahrungen mit beobachteten Abweichungen)
    • Adaptive Planung (d.h. Erstellen von Ausweichplänen)
    • Abwägen der Vor- und Nachteile verschiedener Optionen (Vergleich alternativer Lösungen)
    • Vorbeugen (Verbesserung der Bereitschaft, z.B. Ressourcen für zukünftige Anforderungen verwalten)
    • Verringerung der Unsicherheit (z. B. Erhöhung der Genauigkeit und Zuverlässigkeit von Daten durch Integration und Validierung von Informationen aus verschiedenen Quellen)

    Das Verständnis dieser Strategien ist wichtig, um nützliche Automatisierungen zu entwickeln, die die Entscheidungsfindung des menschlichen Bedieners und die Ausführung von Aufgaben in hochdynamischen Situationen mit hoher Komplexität unterstützen.

    Folgende Fragen sollten gestellt werden: Welche Informationen aus welchen Quellen werden benötigt und welche Datengenauigkeit ist erforderlich? Welche Hinweise sind erforderlich, damit menschliche Bediener bei Abweichungen angemessen informiert werden, um schnell angemessen reagieren können? Was berücksichtigen Menschen bei der Analyse einer Situation und bei komplexen Entscheidungen? Automatisierte Support-Tools können so konzipiert werden, dass sie die Fähigkeit des Menschen unterstützen, Einblicke zu gewinnen oder in die Zukunft zu extrapolieren, bei Abweichungen alarmiert zu werden, oder komplexe Entscheidungen auf der Grundlage operativer Kompromisse zu treffen (Corver & Grote, 2016). Schließlich, kann das Verständnis der Aufgaben und des Informationsbedarfs das Design der Automatisierung unterstützen, die den Menschen beim Clustering, Integrieren und Filtern verschiedener Informationen aus verschiedenen Quellen unterstützt, um die Entscheidungsfindung zu verbessern und zu beschleunigen.

    Zusammenfassend kann gesagt werden, dass mittels Identifizierung menschlicher makrokognitiver Strategien verstanden werden kann, wie die Automatisierung die menschlichen Bedürfnisse unterstützen und die Gesamtleistung eines Systems steigern kann.

    ———————————————————————————————————————————————————

    Literatur

    Corver, S.C. & Grote, G. (2016). Uncertainty management in en route air traffic control: a field study exploring controller strategies and requirements for automation. Cognition, Technology & Work.

    Boy, G. (1998). Cognitive function analysis. Westport, CT: Ablex, Greenwood Publishing Group.

    Straussberger, S. et al. (2008). PAUSA for the future – A synthesis of Phase 1. June 2008. Final Report.