Mit Incident Management in eine neue Ära

Willkommen bei The Hüb – einem Ort, an dem unsere Fachleute offen ihre Meinungen, Ideen, und Erfahrungen sowie ihr Wissen zur Branche, ihrer Zukunft und wichtigen Trends weitergeben.

Wie wichtig ist Incident Management? Welche Standards gelten in diesem Bereich? Hol Dir einen Kaffee, mach Dir entspannende Musik an, und begleite uns zur achten Folge von The Hüb. Diesmal teilt Tijana Krstajić die wertvollen Erfahrungen, die sie während ihrer Arbeit als Project Manager bei Zühlke gesammelt hat, und erzählt, wie sie bei manchen Projekten auch die Rolle als Service Manager übernommen hat.

Wozu braucht man Incident Management?

Ich musste bei einem Projekt das Incident Management auf allen Ebenen organisieren und als Owner die Verantwortung für dieses Framework und alle Unterprozesse übernehmen. Das war schon eine gewisse Herausforderung. Die Geschichte ist vor allem deshalb interessant, weil ich diesen Incident-Management-Prozess für ein Fintech-Unternehmen, eine virtuelle Bank, entwickelt habe. In letzter Zeit tauchen überall Fintechs auf, vor allem Neobanken oder Challenger-Banken, wie sie auch genannt werden. Dabei handelt es sich um rein virtuelle Banken, die keine physische Präsenz auf dem Markt haben, sondern einfach als Systeme existieren, auf die man in der Regel über eine mobile App zugreift.

Unternehmen wie Neobanken, deren größtes Kapital die zentrale Informationstechnik und Automatisierung ist, brauchen viel weniger Menschen, die den Betrieb unterstützen. So kann man aus einer Bank mit 10.000 Angestellten eine Bank mit 50 Leuten machen, die aber durch ihre IT in der Lage ist, dieselben Dienstleistungen zu erbringen. Bei Organisationen mit derart großen Investitionen in essenzielle Technik ist das entsprechende Incident Management extrem wichtig.

Dabei spielt das Incident Management nicht nur für die Engineers eine Rolle. Es geht ja nicht nur um einen Bug in einer Anwendung, durch den vielleicht eine Rechnung nicht sofort bezahlt oder eine bestimmte Informationen nicht am Bildschirm angezeigt werden kann. Es geht hier um wesentlich weitreichendere Folgen. Incident Management ist inzwischen wichtig dafür, wie die Bank von der Kundschaft wahrgenommen wird, und für die eigene Compliance. Auch die Aufsichtsbehörden sind sensibilisiert. In Hongkong zum Beispiel, wo mein Projekt stattfand, müssen CIO, COO und CEO bei einem Sicherheitsvorfall mit enormen Geldstrafen rechnen. Sie können unter Umständen sogar strafrechtlich belangt werden und im Gefängnis landen! Es gibt also eine finanzielle und eine persönliche Haftung in diesem Personenkreis.

Wie fügt sich das Incident Management allgemein in die unternehmerische Wahrnehmung ein?

In modernen Unternehmen verschwindet die klare Trennung von IT und Business langsam, aber sicher. Alle Abteilungen haben eine gemeinsame Vision und ein gemeinsames Ziel – zufriedene Kunden und ein erfolgreiches Unternehmen. Welche Rolle IT bei den Fintechs spielt, habe ich ja schon erwähnt. Bei Banken kommt dazu das potenzielle Ausmaß von Störfällen: Dabei muss man die gesamte Geschäftsgrundlage der Bank betrachten und auch deren Risikobereitschaft. Wir müssen zum Beispiel wissen, wie viele Störfälle tolerierbar sind, um die Erwartungen, die an eine Bank gestellt werden, noch zu erfüllen. Wir müssen auch wissen, wie viele schwerwiegende Störungen, wenn sich zum Beispiel kein Kunde mehr anmelden oder etwas bezahlen kann, wir monatlich verkraften können. Es gab daher viel Austausch mit dem Management und anderen Bereichen der Bank wie Finanzverwaltung, Kundenservice, Risikomanagement und Cybersicherheit. Auf der anderen Seite mussten die Engineers umfassend geschult werden, weil viele keine klare Vorstellung davon haben, was „Incident“ bedeutet und welche Folgen es haben kann, wenn eine für den Betrieb elementare Funktion gestört ist oder gar ausfällt. Ich musste also nicht nur die Rahmenbedingungen schaffen, sondern auch darüber aufklären, was man unter „Incidents“ versteht und welche Konsequenzen sie für eine Bank und deren Kundschaft haben können.

Was sind die offiziellen Standards im Incident Management?

Der bekannteste Standard im Service Management ist ITIL. Incident Management ist ein Prozess innerhalb von ITIL und definiert daher zunächst einmal am besten, was ein Incident ist. Dazu liefert ITIL eine Reihe von Best Practices, die durch das Feedback vieler Unternehmen zustande gekommen sind. Früher hatte ich Vorbehalte gegenüber ITIL, den Vorgaben und strikt definierten Reaktionsweisen. Das hat sich aber seit der vierten Version geändert. Zu strenge Verfahrensanweisungen schränken diejenigen, die auf Störfälle reagieren müssen, zu sehr ein. Sie erzwingen bestimmte Verhaltensweisen, auch wenn diese im konkreten Fall vielleicht nicht zielführend sind. In manchen Situationen muss man einfach die Freiheit haben, situationsabhängig zu entscheiden. Verfahrensanweisungen systematisieren bestimmte Reaktionen, die sich aber nicht für jeden Einzelfall eignen.

Es empfiehlt sich auch, definierte Rollen im Incident Management zu haben. Eine ganz wichtige Rolle ist die des Incident Commander. Das ist diejenige Person, die bei Störfällen das Sagen hat. Sie kann auf der Grundlage der vorgeschlagenen Lösungen Entscheidungen treffen, die Fehlerbehebung beaufsichtigen und alle Maßnahmen zur Beseitigung des Störfalls koordinieren. Im Normalfall sollte das eine technisch qualifizierte Person sein, aber nicht selten übernehmen auch Service Manager oder Project Manager diese Funktion. Wichtig ist, dass sich die Person mit den größeren Zusammenhängen und den Vorkommnissen in dem IT-Bereich auskennt, für den sie Incident Manager ist.

Wenn es um den Prozess selbst geht, lassen sich leicht Parallelen zwischen Incident- und Projektmanagement ziehen. Ein Incident ist im Grunde wie ein kleines Projekt: Es beginnt, wenn die Störung eines Dienstes auftritt, und endet, wenn die Normalfunktion des Dienstes wiederhergestellt ist.

Bei schwerwiegenden Störungen mache ich grundsätzlich eine komplette Analyse. Das heißt, wir ermitteln, wie die Störung aufgetreten ist, warum sie aufgetreten ist, wie der Lösungsablauf war, ob die richtigen Personen an der richtigen Stelle eingesetzt wurden und was wir beim nächsten Mal anders und besser machen können. Der englische Fachbegriff dafür ist „Incident Postmortem“.

Nachdem wir den zeitlichen Ablauf rekonstruiert haben, schauen wir uns an, wie der Störfall in einem idealen Szenario zu beheben ist. Wir besprechen, wer zu welchem Zeitpunkt hätte hinzugezogen werden sollen, was man hätte anders machen können und – ganz wichtig – die Fehler-Ursachen-Analyse oder Root Cause Analysis. Wenn wir Root Cause Analysis sagen, meinen wir nicht nur Probleme. Ich halte nicht mehr so viel von Problem-Management. Ich verstehe zwar den Sinn und Zweck, wenn es um die Regulierungsbehörden und allgemein die Risikoberichterstattung auf höheren Ebenen bei Geldinstituten geht. Aber für die IT an sich ist es wertlos, weil ein Störfall oder Ausfall in den seltensten Fällen auf eine einzige Ursache zurückzuführen ist. In der Regel ergeben sich solche Situationen aus einer ganzen Reihe von Umständen. Um diese zu beheben und die Wiederholung ähnlicher Vorkommnisse in der Zukunft zu vermeiden, müssen normalerweise verschiedene Maßnahmen ergriffen werden – niemals nur eine. Für gewöhnlich ermitteln wir deshalb, durch welche Maßnahmen sich der Wiederholungsfall verhindern lässt. Außerdem priorisieren wir diese Maßnahmen am Ende des Postmortems, indem wir Owner dafür benennen und die Lösungen zeitlich festlegen.

Welche Herausforderungen gibt es bei der teamübergreifenden Kommunikation?

Ich fange mal damit an, was ich am schwierigsten fand. Wenn man in Großunternehmen arbeitet (vor allem in der Finanzwelt), treffen da unweigerlich zwei Kulturen aufeinander. Denn zum einen haben alle, die bei den Banken im Risikomanagement sind – oder vielleicht alle Leute aus dem klassischen Risikomanagement – eine bestimmte Denkweise. Sie sind aus ihren früheren Jobs bestimmte etablierte Praktiken gewohnt und erwarten nun, dass wir als diejenigen, die nach neuen Lösungen für alte Probleme suchen sollen, uns einfach den vorhandenen Lösungen und Denkweisen anpassen.

Mit viel Überzeugungsarbeit und durch das Reduzieren und Aufdecken von Problemen konnten wir am Ende feststellen, dass wir über dieselbe Sache redeten, nur in unterschiedlichen Sprachen. Sie hatten ihre eigenen Vorstellung, der ich aber nicht folgen konnte, weil sie nicht effizient ist und zu viel Zeit kostet. Um eine Verschwendung von Zeit und Geld zu vermeiden, überredete ich sie, meine Idee ein paar Monate lang zuzulassen, um zu sehen, wie es läuft – einfach um es mal auszuprobieren und auf dieser Basis die weiteren Entscheidungen zu treffen: etwas zu ändern oder zum Altbekannten zurückzukehren. Das ist nicht so einfach, wie ich festgestellt habe. Was aber gut war, war große Unterstützung durch das Management des Projekts, vor allem beim Incident Management. So ist es mit gelungen, mein Vorhaben umzusetzen, nämlich uns für große Störfälle, die nie ganz auszuschließen sind, bestmöglich in Position zu bringen.