Manchmal kann schon die kleinste Änderung in einer täglichen Routine tiefgreifende Auswirkungen auf ein Unternehmen haben. Betrachten Sie das Rätsel des wöchentlichen Systemausfalls am Donnerstagnachmittag.
Situation – Die IT-Systeme eines Börsenmaklers verzeichneten langsame Transaktionszeiten, gefolgt von einem vollständigen Ausfall des Transaktionssystems um 15:20 Uhr an einem Donnerstagnachmittag. Ein Neustart des Transaktionssystems behob das Problem und alle konnten wieder arbeiten … bis dasselbe am darauffolgenden Donnerstagnachmittag erneut passierte.
In den folgenden Wochen traten identische Symptome auf. Das Problem ließ sich stets durch einen Systemneustart beheben, doch die Frustration wuchs – insbesondere auf dem Trading-Floor, wo verlorene Zeit zu entgangenen Gewinnen führen kann. Als dieses wöchentliche Ereignis dem Vorstand bekannt wurde, wies er den IT-Direktor an, dem Thema höchste Priorität einzuräumen. Er stellte ein Problemlösungsteam zusammen, um die Ursache zu finden, und das Team nutzte die Kepner-Tregoe-RCA-Methodik, um seine Arbeit zu strukturieren.
Problem identifizieren – In dem Bewusstsein, dass man zur Lösung eines Problems zunächst klar benennen muss, worin es besteht, begann das Team damit, das Problem von der allgemeinen Aussage „Transaktionssystem ist langsam“ zu trennen und zu präzisieren – hin zur spezifischeren Formulierung „Transaktionen laufen in ein Timeout“. Diese Problemformulierung half dem Team, die Suche auf die Informationen zu fokussieren, die zur Ermittlung der tatsächlichen Ursache erforderlich waren, statt Zeit mit interessanten, aber irrelevanten Informationen zu verlieren.
Problem beschreiben– Eine klare Problemformulierung ist notwendig, aber nicht ausreichend, um falsche Ursachen auszuschließen und wahrscheinliche Ursachen zu erkennen. Daher begann das Team, Informationen darüber zu sammeln, was, wann, wo und in welchem Ausmaß das Problem beobachtet wurde – und wo nicht.
- Das Problem trat bei allen über das System ausgeführten Transaktionen auf – Abfragen, Berichte und Trades
- Das Problem bestand konkret in Timeouts – es wurden keine Fehlermeldungen erzeugt
- Das Problem betraf alle Mitarbeitenden; es war nicht auf eine bestimmte Nutzergruppe oder einen geografischen Standort beschränkt
- Das Problem trat erstmals am Donnerstag, dem 6. September, um 15:20 Uhr auf – zuvor war es nicht aufgefallen
- Das Problem trat nur donnerstags zwischen 15:00 und 15:30 Uhr auf. Es gab eine Ausnahme: Am Donnerstag, dem 4. Oktober, wurde das Problem nicht gemeldet
- Das Problem trat nur einmal pro Tag und einmal pro Woche auf
Indem sich das Team zunächst die Zeit nahm, das Problem zu beschreiben, konnte es schnell die unmittelbare Ursache finden und anschließend die systemische Ursache
Mögliche Ursachen identifizieren– Mit einer belastbaren Problembeschreibung konnte das Team die Falle vermeiden, alle Änderungen in Betracht zu ziehen, die das System möglicherweise beeinflussen könnten; die gesuchte Ursache betraf das gesamte System, jedoch nur donnerstags zwischen 15:00 und 15:30 Uhr. Der vorhersehbare Zeitpunkt dieser Abweichung während der normalen Arbeitszeit deutete darauf hin, dass die Ursache wahrscheinlich auf eine menschliche Interaktion mit dem System zurückzuführen war. Darauf richtete sich der Fokus.
Die Prüfung der Dienstpläne lieferte keine brauchbaren Hinweise, doch Gespräche mit Teamleitenden ergaben schließlich eine mögliche Verbindung. Es gab eine Mitarbeiterin im Rechnungsstellungsteam, die jeden Donnerstagnachmittag früher ging, um ihre Tochter zum Ballettunterricht zu bringen. Mitglieder des Problemlösungsteams befragten sie dazu, wie sie mit dem System arbeitete. Dabei stellten sie fest, dass sie jeweils kurz vor dem Gehen einen Bericht startete, den sie am nächsten Morgen benötigte. Normalerweise lief dieser Bericht um 17:30 Uhr, da sie üblicherweise dann die Arbeit verließ. Zu dieser Tageszeit war die Börse geschlossen und nur wenige andere Personen nutzten das System. Donnerstags stellte sie den Bericht wie gewohnt so ein, dass er beim Verlassen gestartet wurde – sie ging jedoch gegen 15:15 Uhr. Der eine Donnerstag, an dem das Problem nicht auftrat, fiel mit einem Tag zusammen, an dem ihre Tochter auf einem Schulausflug war und nicht zum Ballett ging.
Indem sich das Team zunächst die Zeit nahm, das Problem zu beschreiben, konnte es schnell die unmittelbare Ursache und anschließend die systemische Ursache finden: Der Bericht wurde ohne Parameter ausgeführt, sodass die gesamte Transaktionsdatenbank durchsucht wurde, und der Bericht hatte eine höhere Priorität als alle anderen Transaktionen – kein Problem, wenn die Börse geschlossen war. Um 15:15 Uhr jedoch führte dies dazu, dass das ohnehin stark ausgelastete System extrem langsam wurde und schließlich in Timeouts lief, wodurch die Verbindung zur Börse abbrach.
Grundursache beseitigen – Die schnelle Lösung bestand darin, die Mitarbeiterin anzuweisen, den Bericht nicht auszuführen, solange die Börse geöffnet war. Sie zeigte einer anderen Person, wie diese den Bericht donnerstags am Tagesende für sie ausführen konnte. Damit wurde die unmittelbare Ursache des Problems beseitigt und ein erneutes Auftreten verhindert. Anschließend befasste sich das Team mit der systemischen Ursache: dem Ausführen eines Berichts ohne Parameter, der mehr Kapazität des Transaktionssystems beanspruchte als nötig.
Um die systemische Ursache zu beseitigen, nahm ein Entwicklungsteam Änderungen am System vor, sodass Berichte zwingend spezifische Parameter erfordern und jeder Bericht, der die Systemleistung potenziell beeinträchtigen könnte, während der Handelszeiten der Börse nicht ausgeführt werden kann. Nun laufen Börsentransaktionen reibungslos durch das IT-System – sogar donnerstags –, während am anderen Ende der Stadt eine Gruppe kleiner Mädchen in rosa Strumpfhosen Ballett lernt. Rätsel gelöst.
