Umgekehrtes Fehlermodell

Frühwarnzeichen bei Medikationsfehlern

Fragen Sie nicht, warum Fehler passieren – fragen Sie, wie sie garantiert wieder passieren. Die tödlichste Annahme ist: „Wir arbeiten nach Standard, also liegt es am Einzelnen." Schulung ist kein Schutz, sondern eine Illusion von Kontrolle.

Die drei wiederkehrenden Fallen auf Stationen sind: Verwechslung ähnlicher Medikamentennamen, Unterbrechungen während der Gabe und Übergaben mit unvollständigen Informationen. Prüfen Sie rückwärts: Wo genau stirbt der Prozess? Nicht im Endschritt, sondern in den Schnittstellen – beim Umschreiben, Abzeichnen, Übergeben.

Frühwarnzeichen erkennen Sie nicht an der Fehlerquote, sondern an den Beinahe-Fehlern, die niemand meldet. Ein System, das nur registrierte Zwischenfälle zählt, ist blind. Führen Sie eine wöchentliche „Beinahe-Fehler-Runde" ein, in der jede Abweichung ohne Schuldzuweisung genannt wird. Achten Sie auf Muster: Häufen sich Unterbrechungen zur selben Schichtzeit? Steigen Doppelkontrollen, weil Misstrauen wächst?

Die tödlichste Haltung ist: „Wir haben alles nach Vorschrift gemacht."

Prüfen Sie die Umgebung, nicht die Menschen. Wenn Sie herausfinden, wie der Fehler mit Sicherheit entsteht – durch Lärm, Zeitdruck, unklare Etiketten –, können Sie die Bedingungen ändern. Das ist wirksamer als jede weitere Schulung.

Todesursachen Ihrer nächsten App

Ihr letztes Projekt starb nicht an zu vielen Baustellen – es starb daran, dass Sie die tödlichen Optionen nicht vorher ausgeschlossen haben. Stellen Sie die Frage um: „Wie wird diese App mit Sicherheit sterben?" Nicht „Was könnte schiefgehen?", sondern „Was muss passieren, damit wir garantiert scheitern?"

Die drei häufigsten Todesarten bei Apps: kein echter Nutzerbedarf, Zersplitterung der Ressourcen und Gründerkonflikt. Letzteres ist die stillste und tödlichste. Prüfen Sie rückwärts: Wann genau haben Sie und Ihr Mitgründer zuletzt eine Grundsatzfrage anders beantwortet? Wenn Sie keine klare Antwort haben, ist das ein Frühwarnsignal.

„Sag mir, wo ich sterben werde, und ich gehe nie dorthin."

Schließen Sie vor dem Start drei Dinge aus: Erstens, dass Sie ohne validierten Bedarf bauen (Minimum: 20 zahlungswillige Nutzer vor dem ersten Code). Zweitens, dass Sie mehr als eine Kernfunktion parallel entwickeln. Drittens, dass Sie keine wöchentliche Konfliktregelung institutionalisieren. Wenn Sie diese drei tödlichen Pfade blockieren, bleibt nur noch normales Risiko – das ist überlebbar. Lähmung ist der vierte Fehler: Wer alle Risiken ausschließen will, handelt nie.

Von Fehlern rückwärts zu Auslösern

FMEA und Fault Tree bleiben vage, weil Sie von Ursachen ausgehen, statt von der Todesart. Drehen Sie die Kette um: Definieren Sie zuerst den endgültigen Schadensfall – nicht „Anlage fällt aus", sondern konkret: „Druckbehälter berstet, Personenschaden." Erst dann fragen Sie: „Was muss unmittelbar davor passieren?" Das ist die unterste Ebene.

Das Problem mit Abstraktionsebenen: Sie springen zwischen Physik, Verfahren und Organisation, ohne die Ebenen zu trennen. Nutzen Sie eine feste Kaskade: Physikalischer Auslöser → technischer Defekt → Verfahrensfehler → organisatorische Bedingung. Jede Ebene beantwortet nur eine Frage. Auf der physikalischen Ebene: „Welches Material versagt?" Nicht: „War der Mitarbeiter geschult?" Diese Vermischung erzeugt Vagheit.

Die tödlichste Falle: Man sucht die Ursache dort, wo man sie am bequemsten findet.

Arbeiten Sie mit Gegenproben: Nehmen Sie an, der Schaden ist eingetreten, und schreiben Sie rückwärts die plausibelste Kausalkette. Dann prüfen Sie, ob diese Kette durch FMEA-Daten gedeckt ist. Wenn nicht, fehlt ein Glied. Wiederholen Sie das, bis jede Kette auf einer messbaren physikalischen Größe endet – Temperatur, Druck, Materialermüdung. Wenn Sie auf „menschliches Versagen" stoßen, haben Sie die Ebene gewechselt. Stoppen Sie dort und fragen Sie: „Welche physikalische Bedingung machte das Versagen möglich?" So bleiben Sie konkret, ohne sich in Details zu verlieren.