denisismagilov - stock.adobe.com
Root-Cause-Analyse erfordert Abstimmung und Teamkoordination
Was hat das Problem verursacht und wo? Wenn die IT das wissen will, braucht sie mehr als ein Team, um es herauszufinden. Wählen Sie einen von drei kollaborativen RCA-Ansätzen.
Die IT-Welt und die weite Welt haben eine entscheidende Wahrheit gemeinsam: Schlechte Entscheidungen werden oft getroffen, weil gute, vollständige Daten fehlen.
Beim Fehlermanagement im Allgemeinen und bei der Ursachenanalyse (Root Cause Analysis, RCA) im Besonderen, wird dieses Problem oft durch die Trennung der Verantwortlichkeiten in den meisten Unternehmen verursacht. Die meisten Anwender berichten, dass ihre Organisationen die RCA-Aktivitäten zwischen den Teams nicht effektiv koordinieren, und stimmen gleichzeitig zu, dass dies hilfreich, ja sogar unerlässlich ist.
Es gibt zwei Gründe, den Prozess der Ursachenanalyse abzustimmen:
- Wenn verschiedene Teams beteiligt sind, werden oft getrennte Datensätze für jedes Team gesammelt und analysiert. Das hat zur Folge, dass niemand ein vollständiges Bild der Situation hat.
- Die Schritte zur Problembestimmung und -behebung können, wenn sie von unabhängigen Teams durchgeführt werden, miteinander kollidieren, was wiederum eine Reihe von Problemen mit sich bringt.
Bedeutet dies, dass die Fehleranalyse im Rahmen der Ursachenanalyse von einem multidisziplinären Team durchgeführt werden muss? Nicht unbedingt – und in der Tat ist das vielleicht nicht die effizienteste Option. Anwender, die sich der Herausforderung der Datenerfassung für Root Cause Analysis erfolgreich gestellt haben, berichten, dass es drei mögliche Ansätze gibt, von denen einer wahrscheinlich ideal für Ihre eigene Organisation ist.
1. Daten zentral und nicht pro Team sammeln
Bei diesem Ansatz müssen die vollständigen Rohdaten allen Teams zur Verfügung stehen. Die meisten Organisationen, die ihre RCA-Bemühungen koordinieren, verwenden diese Strategie.
Wenn ein beliebiges Team eine Ursachenanalyse durchführt, hat es Zugriff auf alle Ereignisse, die mit dem vorliegenden Problem in Verbindung stehen könnten, einschließlich der Sicherheitsereignisse und der Ergebnisse der Entwicklungstests. Dies hat den Vorteil, dass eine Single Source of Truth in Bezug auf Betriebs- und Fehlerdaten erzwungen wird. Die begrenzte gemeinsame Nutzung von Daten durch die Teams führt zu blinden Flecken bei der Ursachenanalyse; mit mehr Perspektiven und Wissenssätzen, die gemeinsam genutzt werden, kann die Zusammenarbeit redundante Datenerfassung und -speicherung überflüssig machen.
Es gibt jedoch zwei Probleme mit diesem Ansatz: Erstens müssen die Teams Rohdaten bewerten, die mit Zuständigkeiten außerhalb ihrer eigenen Erfahrungen und Fähigkeiten verbunden sind. Kann beispielsweise der IT-Betrieb die Sicherheitsinformationen auswerten, oder wäre es klüger, dies den Spezialisten zu überlassen?
Zweitens könnte die allgemeine Verfügbarkeit von Daten dazu führen, dass dieselben Probleme parallel analysiert und sogar korrigiert werden, was im besten Fall Verschwendung und im schlimmsten Fall destruktiv ist.
2. Ergebnisse der Fehleranalyse zentralisieren
Das Ziel dieses zweiten Ansatzes ist es, diese Probleme zu beheben. Hier tauschen die IT-Teams die Ergebnisse der Fehleranalyse aus und nicht die Rohdaten wie bei der ersten Methode. Bei diesem Ansatz führen die Teams weiterhin spezialisierte Datenerhebungen und Ergebnisanalysen durch, erstellen jedoch einen gemeinsamen Speicher für die Ergebnisse und können die Rohdaten bei Bedarf in größerem Umfang gemeinsam nutzen.
Die effektivste Grundlage für diese gemeinsame Nutzung und Zusammenarbeit sind die Trouble-Ticket-Systeme der Teams. Trouble-Tickets enthalten Problemberichte, Analyseergebnisse und Abhilfemaßnahmen, die in einem Status wie gelöst gipfeln. IT-Teams müssen ihre Trouble-Ticket-Verfahren dahingehend anpassen, dass ihre Analyseergebnisse auf die spezifischen Rohdatenquellen verweisen müssen, die zu ihnen beitragen. Dadurch wird eine Verbindung zwischen dem Trouble Ticket und den Leistungsstatistiken hergestellt. Auf diese Weise werden die Teamanalyse und die Rohdaten miteinander verknüpft und im Kontext ausgetauscht.
3. Ein spezielles Team oder Arbeitsablauf definieren
Die größte Herausforderung bei diesem Ansatz besteht darin, eine kohärente Zusammenarbeit aller am Trouble-Ticket-Prozess beteiligten Teams zu gewährleisten. Um diesen Übergang reibungslos zu gestalten, sollten Sie eine Person aus jedem Team auswählen, die auf die Trouble Tickets anderer Teams zugreift, um sie koordiniert zu analysieren. Bei diesem Ansatz trägt das Team, das einen Fehlerbericht erstellt, die Verantwortung für die Überprüfung des Materials eines anderen Teams.
Es gibt auch andere Möglichkeiten, diesen Ansatz umzusetzen. Ein IT-Administrator könnte zum Beispiel die Problemberichte anderer Teams regelmäßig überprüfen und eine koordinierte Reaktion einleiten. Oder Sie bilden ein zusammenhängendes Team, das einen Problembericht erstellt.
Dieses Team entscheidet dann, ob ein anderes den Bericht prüfen muss, und leitet ihn gegebenenfalls an eine bestimmte Person weiter. Schließlich kann ein Unternehmen ein spezielles Überprüfungsteam benennen, das alle neuen Problemberichte sichtet und den Zugriff auf die zugehörigen teamspezifischen Berichte und damit auch auf die zugehörigen Rohdaten koordiniert.
Die ersten beiden Ansätze setzen voraus, dass mindestens ein Team ein bestimmtes Problem erkennt und dann einen Problembericht sowie eine Analyse veranlasst. Die dritte umfassende Option für die RCA-Koordination umgeht diese Bedingung und stützt sich stattdessen auf eine statistische oder sogar KI-Algorithmus-gestützte Überprüfung der Rohdaten, die auf den Eingaben der einzelnen Teams basiert, um die zu kennzeichnenden Bedingungen zu ermitteln.
Manchmal ist es einfacher, eine KI zu trainieren, als ein Support-Team umzuschulen, ganz zu schweigen von mehreren unabhängigen Teams. Aber auch ohne KI-Unterstützung können IT-Teams alle Quellen von Leistungsdaten analysieren, um die Ursachenanalyse zu erleichtern. Die wichtigste Voraussetzung ist die Synchronisierung des Timings, um Probleme rechtzeitig zu erkennen und im richtigen Kontext zu analysieren.
Die IT-Abteilung kann dieses neue korrelierte Protokoll regelmäßig überprüfen, um potenzielle unentdeckte Probleme aufzudecken, oder wenn eines auftritt, die Bedingungen aller beteiligten Teams in Beziehung setzen. Diese Strategie funktioniert in Verbindung mit den beiden anderen Ansätzen und führt zu einer optimalen Teamkoordination für den Prozess der Ursachenanalyse, die Ihr Unternehmen erreichen kann.
