Wie produktiv sind die Root-Cause-Analysis-Meetings Ihrer Organisation? Um diese Frage zu beantworten, ziehen Sie bitte die folgenden Fragen in Betracht: <\/p>\n
1. Wie oft beginnen Ihre Root-Cause-Meetings damit, objektiv Daten zu sammeln, um das Problem zu beschreiben?<\/p>\n
2. Wie oft beginnen Ihre Root-Cause-Meetings mit ausf\u00fchrlichen Diskussionen \u00fcber m\u00f6gliche Ursachen und enden damit, dass die Teilnehmenden gehen, um zahlreiche Theorien zu untersuchen?<\/p>\n
3. Wie oft f\u00fchren Ihre Root-Cause-Meetings zu einer wahrscheinlichsten Ursache?<\/p>\n
Wenn Sie mit \u201eoft\u201c, \u201enicht oft\u201c und \u201eoft\u201c geantwortet haben, sind Ihre Root-Cause-Meetings wahrscheinlich bereits produktiv \u2013 und die Ergebnisse sind der Beweis. Wenn Ihre Antworten hingegen \u201enicht sehr oft\u201c, \u201eziemlich oft\u201c und \u201eselten\u201c lauteten, lesen Sie bitte weiter, denn der Inhalt dieses Artikels k\u00f6nnte Ihr Denken anregen. <\/p>\n
Typischerweise antworten die meisten Menschen auf die Frage, wie viel Zeit sie f\u00fcr diese Art von Meetings einplanen, mit \u201eeine Stunde\u201c. Wenn eine Stunde der durchschnittliche, geplante Zeitrahmen f\u00fcr ein Root-Cause-Meeting ist: Wie sollten diese Meetings strukturiert sein, damit die Teilnehmenden den gr\u00f6\u00dftm\u00f6glichen Nutzen daraus ziehen? Wie lassen sich diese Meetings am besten organisieren, um zu vermeiden, dass Teilnehmende erneut zusammenkommen und in dieselben Diskussionen zur\u00fcckkehren m\u00fcssen, wenn die n\u00e4chsten Schritte unproduktiv sind? Was ist der beste Ansatz, wenn Diskussionen \u00fcber Ursachen so ausufernd sind, dass Meetings kaum etwas erreichen und sp\u00e4ter fortgesetzt werden m\u00fcssen? <\/p>\n
Im Folgenden finden Sie drei h\u00e4ufige Fallstricke bei Root-Cause-Meetings sowie Kepner-Tregoes Empfehlungen, wie Sie diese vermeiden:<\/p>\n
L\u00f6sung:<\/strong> Legen Sie gleich zu Beginn des Meetings ein klares Thema fest (oder kommunizieren Sie es allen Stakeholdern im Vorfeld). Das setzt den Rahmen f\u00fcr die Diskussion und macht deutlich, was nicht zum Umfang geh\u00f6rt \u2013 und spart so Zeit, die sonst f\u00fcr nicht relevante Themen draufginge. <\/p>\n Erstellen Sie innerhalb des thematischen Rahmens eine Liste der Themen. Wenn es mehrere Probleme gibt, halten Sie sie in einem Dokument fest. Kl\u00e4ren Sie die Symptome und richten Sie den Fokus strikt darauf, was beobachtet<\/em> wird, statt darauf, was theoretisiert<\/em> wird. <\/p>\n Wenn es ein klar umrissenes Problem gibt, ist der Einsatz des \u201e5-Why\u201c-Ansatzes hilfreich, um sich auf das Kernproblem zu konzentrieren, dessen \u201eUrsache unbekannt\u201c ist. Wenn Ihr Team sich ausschlie\u00dflich auf das konkrete Thema fokussiert hat, sollte anschlie\u00dfend noch eine weitere Frage betrachtet werden: <\/p>\n Nicht jedes Problem erfordert eine Root-Cause-Analyse. In manchen F\u00e4llen reicht eine Umgehungsl\u00f6sung oder eine adaptive Ma\u00dfnahme aus; dann kann der Rest des Meetings eher zu einer Entscheidungsdiskussion \u00fcber die beste Methode zur Behebung des Problems werden als zu einer Analyse seiner Diagnose. Wenn das Wissen um die Ursache nicht notwendig ist und Sie das Symptom entweder beheben oder damit leben k\u00f6nnen, ist es nat\u00fcrlich Zeitverschwendung, weiter \u00fcber Root-Cause-Analyse zu sprechen. <\/p>\n Sehr h\u00e4ufig kommen Stakeholder mit einer vorgefassten Vorstellung in diese Meetings, was ihrer Meinung nach passiert. Menschen haben ihre \u201eLieblingsursachen\u201c und verfolgen sie mit Leidenschaft. Nachdem das zu l\u00f6sende Problem gekl\u00e4rt ist, m\u00f6chten die meisten ihre Ideen einbringen. In gewisser Hinsicht ist es wichtig, etwas Diskussion zuzulassen, denn andernfalls warten die Teilnehmenden nur darauf, selbst zu sprechen, statt anderen aktiv zuzuh\u00f6ren \u2013 und die Ergebnisse werden nicht gut sein. Die Diskussion m\u00f6glicher Ursachen kann jedoch schnell kontraproduktiv werden, wenn sie so umfangreich wird, dass sie das Meeting dominiert und dazu f\u00fchrt, dass Menschen gehen, um auf Basis ihrer Theorien unkoordiniert zu handeln. Zudem sollte Root-Cause-Analyse, wenn Zeit Geld ist, kein Spiel nach dem Motto \u201eMeine Ursache ist besser als deine, und ich beweise es\u201c sein. Das f\u00fchrt dazu, dass viel Geld ausgegeben wird, h\u00e4ufig viel Zeit verschwendet wird und sich die Umgebung m\u00f6glicherweise so ver\u00e4ndert, dass es noch schwieriger wird, die wahre Ursache zu finden. <\/p>\n Bei wie viel Prozent Ihrer Root-Cause-Meetings spiegelt sich h\u00e4ufig das oben beschriebene Bild wider?<\/p>\n L\u00f6sung:<\/strong> Wenn Sie nur eine Stunde f\u00fcr das Meeting eingeplant haben, lassen Sie eine gewisse Diskussion \u00fcber m\u00f6gliche Ursachen zu \u2013 aber nur so lange, bis die Teilnehmenden alles ausgesprochen haben, was ihnen auf der Seele liegt. Erstellen Sie eine Liste der Theorien, sobald sie genannt werden, damit die Teilnehmenden zufrieden sind, dass ihre Idee notiert wurde. Sobald die Diskussion ins Stocken ger\u00e4t und es im Raum still wird, stoppen Sie das Gespr\u00e4ch und gehen Sie dazu \u00fcber, die bekannten Fakten zum Problem zu kl\u00e4ren. Halten Sie die Teilnehmenden davon ab, vorschnell zu gehen, um Theorien zu untersuchen. Nur weil eine m\u00f6gliche Ursache das beobachtete Symptom logisch erkl\u00e4ren k\u00f6nnte, hei\u00dft das nicht, dass sie tats\u00e4chlich die wahre Ursache ist. <\/p>\n Denken Sie nur einmal nach: Wann haben Sie in der Vergangenheit erlebt, dass andere unn\u00f6tige Ma\u00dfnahmen ergriffen haben, um Ursachen zu untersuchen, die sich als falsch herausstellten?<\/p>\n Das muss kein rigoroser Prozess sein \u2013 aber bedenken Sie die Alternative. Welche potenziellen Auswirkungen hat es, wenn Sie sich zu Beginn nicht ausreichend Zeit nehmen, um das Problem, das Sie erleben, zu beschreiben? <\/p>\n Wie oben erw\u00e4hnt, sammeln Menschen aus Leidenschaft f\u00fcr ihre Lieblingsursachen h\u00e4ufig Daten, um zu beweisen, dass ihre Ursache wahrscheinlicher ist als eine andere. Tats\u00e4chlich k\u00f6nnte in einer Testumgebung vermutlich jemand verschiedene Experimente erstellen, die zeigen, wie viele Theorien die Art von Symptom ausl\u00f6sen k\u00f6nnten, die beobachtet wird. Was jedoch zuerst verstanden werden muss, sind die tats\u00e4chlich vorliegenden Bedingungen. <\/p>\n L\u00f6sung<\/strong>: Teams sollten mindestens 15 Minuten darauf verwenden, gut formulierte, pr\u00e4zise Fragen zu erarbeiten, die die bekannten Fakten des Problems spezifizieren und strukturieren. Wenn die richtigen Expertinnen und Experten bereits im Raum sind und die vorliegenden Daten korrekt sind, sollte das nicht viel Zeit in Anspruch nehmen und ist \u00e4u\u00dferst hilfreich. Sobald die verf\u00fcgbaren Informationen dokumentiert sind, ist der richtige Zeitpunkt gekommen, m\u00f6gliche Ursachen zu betrachten \u2013 mit dem Ziel, sie anhand der Fakten zu bewerten. <\/p>\n Bei Kepner-Tregoe nutzen wir eine leistungsstarke, bew\u00e4hrte Technik zur Erfassung von Problemdaten, die Teams erm\u00f6glicht, falsche Ursachen schnell auszuschlie\u00dfen und mithilfe von Logik eine wahrscheinlichste Ursache abzuleiten. Unsere Erfahrung hat gezeigt, dass dieser Prozess in nur 15 Minuten wirksam sein kann (vorausgesetzt, die von den Teilnehmenden eingebrachten Informationen sind zielf\u00fchrend) \u2013 ein Zeitraum, in dem Teams verf\u00fcgbare Informationen nutzen, um ihre Ursachendiskussionen zu steuern und die n\u00e4chsten Schritte logisch zu planen. <\/p>\n Das positive Verhalten, das wir f\u00f6rdern m\u00f6chten: Vermeiden Sie es, falsche m\u00f6gliche Ursachen zu untersuchen, indem Sie die Fakten des Problems nutzen, um Theorien auszuschlie\u00dfen, die keinen Sinn ergeben. Das Ergebnis sollten ein oder zwei verbleibende Ursachen sein, die auf logischen Annahmen beruhen. Von dort aus k\u00f6nnen Teams besprechen, welche n\u00e4chsten Schritte am sinnvollsten sind. <\/p>\n Das negative Verhalten, das wir verhindern m\u00f6chten: So viele Daten wie irgend m\u00f6glich zu sammeln und ohne Verst\u00e4ndnis daf\u00fcr, wonach Sie suchen, nach Ursachen zu fischen. Denken Sie nur daran: In den meisten Organisationen finden t\u00e4glich Hunderte (wenn nicht Tausende) von Ver\u00e4nderungen in ihrer Umgebung statt, und jede einzelne davon als m\u00f6gliche Ursache zu pr\u00fcfen, w\u00e4re eine enorme Verschwendung von Ressourcen. Eine gute Problembeschreibung kann den Umfang der Informationen, die zur Bestimmung der Ursache bewertet werden m\u00fcssen, schnell eingrenzen und so potenziell Stunden unn\u00f6tiger Arbeit sparen. <\/p>\n Wenn Sie das Obige ber\u00fccksichtigen und es in einen Meeting-Ablauf \u00fcbertragen, k\u00f6nnte ein produktives Root-Cause-Meeting eher so aussehen:<\/p>\n \u00a0<\/p>\n Root-Cause-Meetings sollten logikgetrieben statt impulsgesteuert sein. Reflexartige Reaktionen auf eine vermeintlich gefundene Ursache helfen selten und machen den Prozess oft unproduktiv \u2013 und das Problem schlimmer, insbesondere wenn sie auf Annahmen statt auf Fakten beruhen. Sich die Zeit zu nehmen, das Problem klar zu beschreiben, ist so wichtig; Daten sollten die Annahmen oder Hypothesen st\u00fctzen \u2013 oder aus der Betrachtung ausgeschlossen werden. Letztlich gilt: Wenn Geld f\u00fcr das Testen von Ursachen ausgegeben wird, dann sollte es f\u00fcr diejenigen sein, die erkl\u00e4ren, was tats\u00e4chlich passiert. <\/p>\n","protected":false},"excerpt":{"rendered":" Wie produktiv sind die Root-Cause-Analysis-Meetings Ihrer Organisation? Um diese Frage zu beantworten, ziehen Sie bitte die folgenden Fragen in Betracht: 1. Wie oft beginnen Ihre Root-Cause-Meetings damit, objektiv Daten zu sammeln, um das Problem zu beschreiben? 2. Wie oft beginnen Ihre Root-Cause-Meetings mit ausf\u00fchrlichen Diskussionen \u00fcber m\u00f6gliche Ursachen und enden damit, dass die Teilnehmenden gehen, […]<\/p>\n","protected":false},"author":5,"featured_media":1692,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35],"tags":[],"ppma_author":[163],"class_list":["post-65473","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sonstige"],"acf":[],"yoast_head":"\nM\u00fcssen Sie die Ursache kennen, um wirksame, sinnvolle Ma\u00dfnahmen zu ergreifen?<\/em><\/h4>\n
Fallstrick Nr. 2: Das Meeting setzt sich mit einer ausufernden Diskussion \u00fcber m\u00f6gliche Ursachen fort, die sich als Ablenkung erweisen.<\/h4>\n
Fallstrick Nr. 3: Teams verbringen nicht genug Zeit damit, Fakten zu sammeln, um das Problem zu beschreiben, bevor sie vorschnell auf eine Ursache schlie\u00dfen.<\/h4>\n
\n\n
\n Zeit<\/strong><\/td>\n Besprochenes Thema<\/strong><\/td>\n<\/tr>\n \n 0\u20135 Minuten<\/td>\n Vorstellungsrunde und Meeting-Thema kl\u00e4ren<\/td>\n<\/tr>\n \n 5\u201310 Minuten<\/td>\n Themen und zu behandelndes Problem kl\u00e4ren; bei Bedarf \u201e5 Whys\u201c nutzen, um tiefer zu gehen<\/td>\n<\/tr>\n \n 10\u201320 Minuten<\/td>\n M\u00f6gliche Ursachen anhand des Wissens und der Erfahrung der Teilnehmenden diskutieren und auflisten<\/td>\n<\/tr>\n \n 20\u201335 Minuten<\/td>\n Fakten sammeln, um das Problem zu spezifizieren<\/td>\n<\/tr>\n \n 35\u201350 Minuten<\/td>\n M\u00f6gliche Ursachen erneut betrachten, diejenigen ausschlie\u00dfen, die die Fakten des Problems nicht erkl\u00e4ren, und den Fokus auf die wenigen richten, die es tun<\/td>\n<\/tr>\n \n 50\u201360 Minuten<\/td>\n N\u00e4chste Schritte planen \u2013 basierend auf Ihrer Untersuchung der Ursache, die am logischsten erscheint<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n