Manchmal kann schon die kleinste \u00c4nderung in einer t\u00e4glichen Routine tiefgreifende Auswirkungen auf ein Unternehmen haben. Betrachten Sie das R\u00e4tsel des w\u00f6chentlichen Systemausfalls am Donnerstagnachmittag. <\/p>\n
Situation<\/strong> \u2013 Die IT-Systeme eines B\u00f6rsenmaklers verzeichneten langsame Transaktionszeiten, gefolgt von einem vollst\u00e4ndigen Ausfall des Transaktionssystems um 15:20 Uhr an einem Donnerstagnachmittag. Ein Neustart des Transaktionssystems behob das Problem und alle konnten wieder arbeiten \u2026 bis dasselbe am darauffolgenden Donnerstagnachmittag erneut passierte. <\/p>\n In den folgenden Wochen traten identische Symptome auf. Das Problem lie\u00df sich stets durch einen Systemneustart beheben, doch die Frustration wuchs \u2013 insbesondere auf dem Trading-Floor, wo verlorene Zeit zu entgangenen Gewinnen f\u00fchren kann. Als dieses w\u00f6chentliche Ereignis dem Vorstand bekannt wurde, wies er den IT-Direktor an, dem Thema h\u00f6chste Priorit\u00e4t einzur\u00e4umen. Er stellte ein Probleml\u00f6sungsteam zusammen, um die Ursache zu finden, und das Team nutzte die Kepner-Tregoe-RCA-Methodik, um seine Arbeit zu strukturieren. <\/p>\n Problem identifizieren<\/strong> \u2013 In dem Bewusstsein, dass man zur L\u00f6sung eines Problems zun\u00e4chst klar benennen muss, worin es besteht, begann das Team damit, das Problem von der allgemeinen Aussage \u201eTransaktionssystem ist langsam\u201c zu trennen und zu pr\u00e4zisieren \u2013 hin zur spezifischeren Formulierung \u201eTransaktionen laufen in ein Timeout\u201c. Diese Problemformulierung half dem Team, die Suche auf die Informationen zu fokussieren, die zur Ermittlung der tats\u00e4chlichen Ursache erforderlich waren, statt Zeit mit interessanten, aber irrelevanten Informationen zu verlieren. <\/p>\n Problem beschreiben<\/strong>\u2013 Eine klare Problemformulierung ist notwendig, aber nicht ausreichend, um falsche Ursachen auszuschlie\u00dfen und wahrscheinliche Ursachen zu erkennen. Daher begann das Team, Informationen dar\u00fcber zu sammeln, was, wann, wo und in welchem Ausma\u00df das Problem beobachtet wurde \u2013 und wo nicht. <\/p>\n Indem sich das Team zun\u00e4chst die Zeit nahm, das Problem zu beschreiben, konnte es schnell die unmittelbare Ursache finden und anschlie\u00dfend die systemische Ursache<\/span> Die Pr\u00fcfung der Dienstpl\u00e4ne lieferte keine brauchbaren Hinweise, doch Gespr\u00e4che mit Teamleitenden ergaben schlie\u00dflich eine m\u00f6gliche Verbindung. Es gab eine Mitarbeiterin im Rechnungsstellungsteam, die jeden Donnerstagnachmittag fr\u00fcher ging, um ihre Tochter zum Ballettunterricht zu bringen. Mitglieder des Probleml\u00f6sungsteams 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\u00e4chsten Morgen ben\u00f6tigte. Normalerweise lief dieser Bericht um 17:30 Uhr, da sie \u00fcblicherweise dann die Arbeit verlie\u00df. Zu dieser Tageszeit war die B\u00f6rse geschlossen und nur wenige andere Personen nutzten das System. Donnerstags stellte sie den Bericht wie gewohnt so ein, dass er beim Verlassen gestartet wurde \u2013 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. <\/p>\n Indem sich das Team zun\u00e4chst die Zeit nahm, das Problem zu beschreiben, konnte es schnell die unmittelbare Ursache und anschlie\u00dfend die systemische Ursache finden: Der Bericht wurde ohne Parameter ausgef\u00fchrt, sodass die gesamte Transaktionsdatenbank durchsucht wurde, und der Bericht hatte eine h\u00f6here Priorit\u00e4t als alle anderen Transaktionen \u2013 kein Problem, wenn die B\u00f6rse geschlossen war. Um 15:15 Uhr jedoch f\u00fchrte dies dazu, dass das ohnehin stark ausgelastete System extrem langsam wurde und schlie\u00dflich in Timeouts lief, wodurch die Verbindung zur B\u00f6rse abbrach. <\/p>\n Grundursache beseitigen<\/strong> \u2013 Die schnelle L\u00f6sung bestand darin, die Mitarbeiterin anzuweisen, den Bericht nicht auszuf\u00fchren, solange die B\u00f6rse ge\u00f6ffnet war. Sie zeigte einer anderen Person, wie diese den Bericht donnerstags am Tagesende f\u00fcr sie ausf\u00fchren konnte. Damit wurde die unmittelbare Ursache des Problems beseitigt und ein erneutes Auftreten verhindert. Anschlie\u00dfend befasste sich das Team mit der systemischen Ursache: dem Ausf\u00fchren eines Berichts ohne Parameter, der mehr Kapazit\u00e4t des Transaktionssystems beanspruchte als n\u00f6tig. <\/p>\n Um die systemische Ursache zu beseitigen, nahm ein Entwicklungsteam \u00c4nderungen am System vor, sodass Berichte zwingend spezifische Parameter erfordern und jeder Bericht, der die Systemleistung potenziell beeintr\u00e4chtigen k\u00f6nnte, w\u00e4hrend der Handelszeiten der B\u00f6rse nicht ausgef\u00fchrt werden kann. Nun laufen B\u00f6rsentransaktionen reibungslos durch das IT-System \u2013 sogar donnerstags \u2013, w\u00e4hrend am anderen Ende der Stadt eine Gruppe kleiner M\u00e4dchen in rosa Strumpfhosen Ballett lernt. R\u00e4tsel gel\u00f6st. <\/p>\n","protected":false},"excerpt":{"rendered":" Manchmal kann schon die kleinste \u00c4nderung in einer t\u00e4glichen Routine tiefgreifende Auswirkungen auf ein Unternehmen haben. Betrachten Sie das R\u00e4tsel des w\u00f6chentlichen Systemausfalls am Donnerstagnachmittag. Situation \u2013 Die IT-Systeme eines B\u00f6rsenmaklers verzeichneten langsame Transaktionszeiten, gefolgt von einem vollst\u00e4ndigen Ausfall des Transaktionssystems um 15:20 Uhr an einem Donnerstagnachmittag. Ein Neustart des Transaktionssystems behob das Problem und […]<\/p>\n","protected":false},"author":5,"featured_media":3063,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[35],"tags":[],"ppma_author":[101],"class_list":["post-65538","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sonstige"],"acf":[],"yoast_head":"\n\n
\nM\u00f6gliche Ursachen identifizieren<\/strong>\u2013 Mit einer belastbaren Problembeschreibung konnte das Team die Falle vermeiden, alle \u00c4nderungen in Betracht zu ziehen, die das System m\u00f6glicherweise beeinflussen k\u00f6nnten; die gesuchte Ursache betraf das gesamte System, jedoch nur donnerstags zwischen 15:00 und 15:30 Uhr. Der vorhersehbare Zeitpunkt dieser Abweichung w\u00e4hrend der normalen Arbeitszeit deutete darauf hin, dass die Ursache wahrscheinlich auf eine menschliche Interaktion mit dem System zur\u00fcckzuf\u00fchren war. Darauf richtete sich der Fokus. <\/p>\n