Eine belegte Prozessursache ermitteln, ohne die Schuld einer Person zuzuweisen
Eine nützliche Definition der Ursache (Root Cause) unterscheidet drei Dinge: das beobachtete Symptom, eine Rahmenbedingung, die das Auftreten begünstigt hat, und die durch Belege gestützte Ursache. Bei einem Gemeinschafts-Bastelworkshop könnte das bedeuten: Zwei Personen erhalten Bestätigungen für denselben Platz; telefonische und Online-Buchungen werden in separaten Systemen geführt; und eine verzögerte Aktualisierung führt dazu, dass ein Platz online verfügbar bleibt, nachdem er bereits telefonisch reserviert wurde. Die letzte Aussage ist nur dann eine Ursache, wenn die Datensätze diesen Mechanismus belegen. Dies ist ein pragmatischer Ansatz, um ein kleines Prozessproblem zu beschreiben, und kein Anspruch darauf, dass jede Analyse zwingend dieselben festen Bezeichnungen verwenden muss.
Was bedeutet „Ursache“ (Root Cause) in einem kleinen Projekt?
Die American Society for Quality (ASQ) definiert eine Ursache als einen Faktor, der eine Nichtkonformität verursacht hat und durch Korrekturmaßnahmen behoben werden sollte. Sie beschreibt die Ursachenanalyse (Root-Cause-Analysis) als eine Methode, um aufzudecken, warum ein Problem aufgetreten ist, und weist darauf hin, dass die Ereignis- und Kausalfaktorenanalyse Belege und eine Zeitleiste verwendet, um kausale und beitragende Faktoren zu identifizieren. Diese Ideen unterstützen eine einfache Arbeitsdefinition: Eine Ursache ist ein durch Belege gestützter Teil eines Prozesses, der erklärt, wie das genannte Problem entstanden ist, und der durch eine praktische Änderung behoben werden kann. Leitfaden zur Ursachenanalyse der ASQ
Der Begriff „Wurzel“ (Root) kann den Eindruck erwecken, dass es nur eine einzige Ursache gibt. Bei echten Prozessproblemen wirken jedoch oft mehrere Faktoren zusammen. Die ASQ selbst spricht von kausalen und beitragenden Faktoren; daher kann eine sorgfältige Ausarbeitung auch mehr als eine Ursache identifizieren, sofern die Belege dies stützen. Vermeiden Sie es, eine bequeme Erklärung einfach deshalb zu wählen, weil sie der erste Vorschlag war.
Wie unterscheiden sich ein Symptom, eine beitragende Bedingung und eine Ursache?
Diese Bezeichnungen tragen dazu bei, eine kurze Problembeschreibung klarer zu formulieren. Sie sind eine Formulierungshilfe, kein Ersatz für die Untersuchung der eigentlichen Vorgänge.
Eine Rahmenbedingung kann zum Problem beitragen, ohne den gesamten Mechanismus zu erklären. Beispielsweise kann ein hoher Andrang im Workshop mit einer verzögerten Aktualisierung zusammenfallen, aber die Tatsache, dass „viel los war“, erklärt für sich genommen noch nicht, warum eine zweite Bestätigung überhaupt möglich war. Die Formulierung der Ursache sollte den Prozess mit dem Ergebnis verknüpfen und sich auf überprüfbare Fakten stützen: Zeitstempel, Buchungsdatensätze oder das schrittweise Durchgehen der Reservierungsabläufe. Fehlen diese Belege, bezeichnen Sie die Erklärung als mögliche Ursache, bis sie überprüft wurde.
Eine kurze Abfolge von Fragen, um eine belegte Ursache zu finden
Beginnen Sie mit dem Ereignis und nicht mit einem Urteil über eine Person. Die ASQ empfiehlt, methodisch eine Zeitleiste zu erstellen und Ursachen und Wirkungen zu analysieren; die folgenden Fragen wenden diesen Ansatz auf ein kleines Buchungsproblem an. Übersicht der ASQ zur Ursachenanalyse
Dies ähnelt einer „5-Why“-Untersuchung, fünf ist jedoch keine zwingende Zahl. Hören Sie auf, wenn Sie eine spezifische, überprüfbare Prozess-Erklärung haben, die das Ereignis erklärt und als Leitfaden für den Test einer Behebung dienen kann. Wenn eine Frage eher zu Spekulationen als zu Belegen führt, markieren Sie die Unsicherheit und suchen Sie nach einer Aufzeichnung oder beobachten Sie den Prozess, bevor Sie die Antwort als gesichert betrachten.
Den Befund formulieren, ohne zu übertreiben
Ein prägnanter Bericht kann diesem Muster folgen:
> Symptom: [Beobachtbares Ergebnis.] Begünstigende Bedingung: [Umstand, der es wahrscheinlicher gemacht hat.] Durch Belege gestützte Ursache: [Prozessmechanismus sowie die Belege, die ihn stützen.]
Angewandt auf das obige Beispielszenario:
Das Beispiel ist hypothetisch; seine Belege sind Teil der Veranschaulichung, kein Bericht über einen echten Workshop. Ersetzen Sie bei einer tatsächlichen Untersuchung den angenommenen Ablauf durch von Ihnen überprüfte Datensätze. Wenn Sie noch nicht nachweisen können, dass eine telefonische Buchung vor der zweiten Bestätigung erfolgte oder dass die Online-Liste den Platz noch als frei anzeigte, schreiben Sie „mögliche Ursache“ und geben Sie an, was Sie noch verifizieren müssen.
Wählen Sie eine reversible Lösung und prüfen Sie, ob sie den Wirkungsmechanismus angeht
Für einen risikoarmen Testlauf könnte der Workshop ein einziges gemeinsames Verfügbarkeitsverzeichnis für alle Buchungskanäle nutzen. Das Personal würde eine Reservierung erfassen und den Platz als nicht verfügbar markieren, bevor er bestätigt wird – unabhängig davon, ob die Anfrage per Telefon oder online einging. Dies zielt auf den vermuteten Mechanismus ab – zwei Kanäle bestätigen auf Grundlage unterschiedlicher oder veralteter Stände –, ohne dass eine dauerhafte Systemänderung erforderlich ist.
Testen Sie das Verfahren für eine begrenzte Anzahl anstehender Termine mit einem klaren Start- und Endzeitpunkt. Vergleichen Sie jede Bestätigung mit dem gemeinsamen Verzeichnis und fragen Sie das mit den Buchungen betraute Personal, ob es den Ablauf durchgehend einhalten konnte. Wenn weiterhin doppelte Bestätigungen auftreten oder das Verzeichnis vor der Bestätigung nicht zuverlässig aktualisiert wird, hat der Testlauf nicht belegt, dass diese Änderung die Ursache beherrscht. Überprüfen Sie die Schritte und Belege erneut; gehen Sie nicht davon aus, dass die Wiederholung derselben Lösung einen anderen Mechanismus beheben wird.
Eine gute Definition leistet daher mehr, als nur ein Problem zu benennen. Sie ermöglicht es einer anderen Person zu erkennen, was beobachtet wurde, welcher Umstand möglicherweise dazu beigetragen hat, welche Prozesserklärung durch die Belege gestützt wird und wie eine kleine, reversible Änderung diese Erklärung überprüfen könnte.
Quellen und Geltungsbereich
Das ursprüngliche Doppelbuchungsbeispiel folgt Belegen hin zu einem reversiblen Prozesstest. Die aufgeführten Quellen stützen die genannten Fakten; Beispiele und Übungen sind eigenständige redaktionelle Anwendungen.