Manchmal hilft es, sich auf die Grundlagen zu besinnen. Zum Beispiel, indem wir uns den Zweck von Incident Response (IR) vor Augen führen. Die Antwort ist einfach: den Geschäftsbetrieb aufrechtzuerhalten. Doch diese Einfachheit ist trügerisch. Es handelt sich um eine ungeheure Verantwortung, wie Sie wissen, falls jemals etwas bei Ihrer Fähigkeit, auf einen Major Incident zu reagieren, schiefgelaufen ist. Laut Gartner kostet jede Minute, in der Ihre Systeme ausfallen, im Durchschnitt 5.600 $, was sich auf mehr als 300.000 $ pro Stunde summiert. Das ist viel Geld und bedeutet einen enormen Druck.
Bei KT haben wir unsere Köpfe zusammengesteckt und sieben Best Practices entwickelt, um den Erfolg Ihres IR-Programms sicherzustellen. Diese umfassen operative, technische und organisatorische Vorschläge, die alle dazu beitragen, ein erstklassiges IR-Team aufzubauen.
Warum Incident Response?
ITIL beschreibt einen Incident als jede Unterbrechung oder Störung des normalen IT-Betriebs. Wir können dies spezifischer auf Ihr Unternehmen beziehen und sagen, dass ein Incident jeder Umstand ist, in dem ein System so agiert, dass es Ihre Kunden negativ beeinflusst. Es muss sich dabei nicht um einen kompletten Systemabsturz handeln. Nehmen wir ein langsames E-Mail-System. Stellt das einen Incident dar? Nach unserer Definition auf jeden Fall, denn langsame E-Mails bedeuten langsamere Reaktionen auf Kundenservice-Anfragen, verzögerte Reaktionen auf Ausschreibungen (RFPs), eine verlangsamte Produktentwicklung und beeinträchtigen so gut wie jede gewinnorientierte Aktivität Ihres Unternehmens.
IR ist Ihr Prozess zur Reaktion auf diese Incidents (wobei sich Incidents von Problemen unterscheiden, was wir später besprechen werden). Eine erfolgreiche IR – was bedeutet, dass sie sowohl schnell als auch effektiv ist – führt zu einer verbesserten Effizienz von Mitarbeitern und Prozessen, höherer Produktivität und letztlich zu höheren Umsätzen für das Unternehmen. Es handelt sich dabei wirklich um eine geschäftskritische Operation.
7 Best Practices für eine hervorragende Incident Response
Hier sind acht Best Practices, mit denen Sie Ihr IR-Team auf Höchstleistung trimmen können.
1. Kommunizieren, kommunizieren, kommunizieren
Historisch gesehen gab es oft eine Kommunikationskluft zwischen der IT und dem Rest der Organisation – insbesondere zwischen der IT und den Nutzern. Dies führt zu Problemen beim Versuch, eine exzellente IR zu liefern, da viele, wenn nicht sogar die meisten Ihrer Incidents von Ihren Nutzern gemeldet werden. Diese müssen eine einfache Möglichkeit für diese Meldungen haben, damit Sie so früh wie möglich von Incidents erfahren. Anschließend müssen Sie sie in Echtzeit über die Behebung des Incidents auf dem Laufenden halten. All dies ist notwendig, um ihr Vertrauen zu gewinnen, damit sie bei künftigen Vorfällen enger mit Ihnen zusammenarbeiten – eine Kooperation, die unerlässlich ist. Eröffnen Sie zu Beginn mehrere Kanäle, über die Nutzer problemlos Tickets erstellen können. Sie sollten beispielsweise in der Lage sein, das IR-Team per E-Mail, Chat, über ein Portal oder ein soziales Unternehmensnetzwerk wie Yammer zu benachrichtigen. Sie sollten zudem Self-Service-Mechanismen einrichten, damit Nutzer einfache Incidents selbst lösen können. Machen Sie den Self-Service leicht zugänglich und klären Sie die Nutzer über die Vorteile der Selbsthilfe und der Nutzung der Wissensdatenbank zur eigenständigen Problemlösung auf.
Während das IR-Team an der Behebung des Incidents arbeitet, ist es essenziell, alle Beteiligten in Echtzeit über den Fortschritt zu informieren. Zwei Informationen sollten dabei jederzeit prominent angezeigt werden: der Incident-Status (aktueller Stand der Behebung, einschließlich der geschätzten Zeit bis zum Abschluss) und die Priorität des Incidents (wie wichtig die Behebung im Vergleich zu anderen Incidents ist).
Automatisierung kann helfen, indem sie während des gesamten Lebenszyklus von Major Incidents automatische Updates versendet. Klare und sichtbare Benachrichtigungen verhindern zudem, dass Nutzer Duplikate von Tickets erstellen und den Helpdesk überlasten. Selbst wenn es nichts Neues zu berichten gibt, teilen Sie dies Ihren Stakeholdern stündlich oder halbstündlich mit. Richten Sie zudem eine dedizierte Leitung ein, um sofort auf Major Incidents zu reagieren und allen Betroffenen Unterstützung anzubieten.
2. DevOps-Prozesse einführen
Bevor DevOps zum Mainstream wurde, war das IR-Team im Grunde auf sich allein gestellt. Sie waren für alle Incidents verantwortlich und nicht die Personen, die die Systeme tatsächlich gebaut hatten. Es gab beispielsweise keine Rückkopplungsschleife an die Entwickler, wie repetitive Störungen bei einer bestimmten Anwendung behoben werden könnten. Es fand kaum Kommunikation zwischen den Erstellern der Systeme und denjenigen statt, die für deren Reparatur bei Fehlern zuständig waren. Tatsächlich war ein Grund für die Entstehung von DevOps die Beseitigung dieser organisatorischen Silos. Dies ist aufgrund der Komplexität heutiger Systeme unerlässlich – sie sind alle miteinander vernetzt, und was das eine beeinflusst, wirkt sich wahrscheinlich auch auf andere aus.
Mit einer etablierten DevOps-Struktur leisten Entwickler bessere Arbeit beim Aufbau ihrer Systeme, da sie nun wissen, dass sie diese auch unterstützen müssen – Probleme werden nicht mehr einfach über den Zaun geworfen, damit sich eine andere Gruppe darum kümmert. IR-Teams erhalten Unterstützung und verfügen – wenn DevOps richtig umgesetzt wird – in der Regel über eine klare Dokumentation, wie komplexe Systeme am Laufen gehalten werden.
3. Erkennen, wann „Swarming“ erforderlich ist
Obwohl die meisten Unternehmen eine gestufte Struktur für den Umgang mit Incidents haben – Tier 1 ist der Helpdesk, Tier 2 umfasst Anwendungsspezialisten und Tier 3 sind im Allgemeinen die System-Experten und Entwickler –, sollten Sie diese Struktur bei der Lösung von Major Incidents nicht universell erzwingen. Geben Sie Ihrem Team die Freiheit zum „Swarming“ (Ausschwärmen), wenn es nötig ist.
Dies ist meist dann erforderlich, wenn ein Problem massive Auswirkungen auf das Geschäft hat. In solchen Fällen sollten Sie von den normalen gestuften IR-Prozessen abweichen. Swarming ersetzt diese Struktur durch ein Modell der vernetzten Zusammenarbeit. Das Konzept stammt von Cisco, das 2008 im Whitepaper „Digital Swarming“ darüber schrieb. Das Konzept wurde später vom Consortium for Service Innovation übernommen und zu einer Vision namens „Intelligent Swarming“ weiterentwickelt.
Die Grundidee hinter Swarming ist, dass man anstelle einer Eskalation alle Personen, die zur Lösung eines Incidents beitragen könnten, gleichzeitig in das IR-Team holt. Dort betreiben sie Brainstorming, tauschen Ideen aus und nutzen die Gruppendynamik, um frische und innovative Lösungen für schwierige IR-Probleme zu finden.
Zu den Kernprinzipien des Swarming gehören:
- Die Support-Stufen („Tiers“) werden aufgehoben.
- Es gibt keine Eskalation von einer Gruppe zur nächsten – alle benötigten Teammitglieder sind von Anfang an dabei.
- Der Fall sollte direkt an die Person oder Personen übergeben werden, die am ehesten in der Lage sind, ihn zu lösen.
- Die Person, die den Fall übernimmt, begleitet ihn bis zur endgültigen Lösung.
4. Eine „Nicht-noch-einmal“-Policy implementieren
Sie sollten zudem darauf achten, nicht immer wieder dieselben Brände zu löschen. Das bedeutet, den Unterschied zwischen IR und Problem Management zu kennen. IR kümmert sich darum, den Normalzustand wiederherzustellen, selbst wenn dies nur eine vorübergehende Lösung bedeutet. Problem Management findet statt, wenn Sie die Ursache des Incidents ermitteln und diese dauerhaft beheben.
Beachten Sie, dass man das Auftreten von Incidents niemals ganz verhindern kann; das ist unrealistisch. Durch effektives Problem Management können Sie jedoch vermeiden, wiederholt Lösungen für dasselbe Problem bereitstellen zu müssen.
5. Problembeschreibung und Priorität korrekt festlegen
Die wohl wichtigste Maßnahme ist es, zu verstehen und zu artikulieren, was der Incident beinhaltet. Dies wird als Incident-Klassifizierung bezeichnet. Dabei müssen Sie über die Einordnung in eine Basiskategorie hinausgehen und die Problembeschreibung extrem genau und präzise spezifizieren. Dies sollte Parameter umfassen wie die betroffenen Systeme, den geografischen Standort, die Anzahl der betroffenen internen Nutzer und die spezifischen Auswirkungen auf den Geschäftsbetrieb.
Erst wenn Sie eine klare Problembeschreibung haben, können Sie Prioritäten setzen. Eine korrekte Klassifizierung hilft bei der Fehlersuche und verbessert die Lösungszeit. Die Priorisierung stellt dann sicher, dass die geschäftskritischsten Probleme zuerst angegangen werden.
6. Eine „No-Blame“-Kultur fördern
Dies ist essenziell. Anstatt nach Schuldigen zu suchen, wenn etwas schiefgeht – sei es bei der IR-Reaktion selbst oder beim zugrunde liegenden Systemproblem –, sollten Sie sich schlicht auf das Problem und die Suche nach der wahren Ursache konzentrieren. Eine Kultur der gegenseitigen Beschuldigung („Blame-and-Shame“) nützt Ihnen nichts und kann die IR-Reaktion sogar verlangsamen, da die Mitarbeiter aus Angst vor Fehlern gehemmt sind.
7. Die richtigen KPIs festlegen und verbessern
Key Performance Indicators (KPIs) sind unglaublich wichtig, da sie messen, wie Sie abschneiden, und Ihnen einen quantitativen Maßstab bieten, um Verbesserungen festzustellen. Seien Sie jedoch vorsichtig bei der Auswahl Ihrer KPIs. Manche vermitteln ein falsches Bild von der Leistung Ihres IR-Teams und können dazu führen, dass Sie die falschen Prioritäten setzen. Zum Beispiel misst die First Call Resolution (FCR), eine gängige Kennzahl, wie viele Incidents beim ersten Anruf gelöst werden können. Manchmal führt dies jedoch zu voreiligen Entscheidungen und Handlungen, wenn die Servicequalität eigentlich wichtiger wäre.
Richten Sie daher realistische Kennzahlen ein und messen Sie diese für eine ständige Verbesserung. Hier sind einige vorgeschlagene KPIs zur Nachverfolgung:
- Incident-Volumen (pro Problemkategorie, Priorität, Status, Anforderer usw.)
- Mittlere Zeit bis zur Lösung (Mean Time to Resolution)
- Mittlere Zeit bis zur Reaktion (Mean Time to Respond)
- SLA-Quote in %
- Ohne Eskalation gelöste Incidents
- Durchschnittliche Kosten pro Incident
- Wiedereröffnungsrate von Incidents
Fazit: Vorteile eines effektiven Incident Managements
Wir alle kennen die Folgen einer mangelhaften IR – das Unternehmen leidet. Umgekehrt sind die Vorteile einer korrekt durchgeführten IR vielfältig. Sie haben reibungslose Geschäftsabläufe. Sie erreichen eine verbesserte Effizienz und Produktivität sowohl innerhalb des IT-Teams als auch in der gesamten Organisation. Sie erzielen eine viel höhere Nutzerzufriedenheit, da Sie Ihre SLAs einhalten. Und je besser Sie in der IR werden, desto eher können Sie proaktiv Major Incidents identifizieren und verhindern, indem Sie potenzielle Vorfälle erkennen, bevor sie von Nutzern oder Kunden gemeldet werden. Das ist eine echte Win-Win-Win-Situation.
Über Kepner-Tregoe
Kepner-Tregoe ist seit mehr als 60 Jahren Branchenführer für Problemlösungs- und Service-Excellence-Prozesse. Die Experten von KT haben Unternehmen dabei geholfen, ihr Leistungsniveau im Incident- und Problem-Management durch Tools, Training und Beratung zu steigern – was zu hocheffektiven Service-Management-Teams führt, die bereit sind, auf die kritischsten Probleme Ihres Unternehmens zu reagieren.
