IT-Incident-Management und Incident-Management-Software

Was ist ein Incident?

Ein Incident im Sinne der IT ist ein stattfindendes Ereignis, das nicht Teil der normalen Operationen ist und das die Aktivitäten eines Nutzers oder einen Geschäftsprozess stört. Ein Incident beginnt, wenn die normalen Operationen gestört werden und dauert an, bis die normalen Operationen wieder hergestellt sind. Incidents sind Technologieereignisse, die die geschäftlichen Aktivitäten stören und zum Lösen gewöhnlich eine Art von Eingriff erfordern. Ein Incident kann mit einem Versagen einer technischen Komponente oder einer Funktion zusammenhängen. Es kann sich auch um ein Problem der Integrationen zwischen Komponenten handeln oder das Versagen von Workflows, die für ein System konfiguriert wurden. Hier einige Beispiele für Incidents:

Beispiele für Software-Incidents

• Service nicht verfügbar – Dies ist ein Incident, der häufig bei Software als Service (SaaS) auftritt. Der Nutzer versucht dann, auf den Service zuzugreifen und kann sich entweder nicht verbinden oder erhält eine Fehlermeldung, die besagt, dass der Service nicht verfügbar ist.
• Datenproblem – Der Zweck der meisten Software ist es Daten aufzuzeichnen, zu speichern, zu aktualisieren und zu präsentieren. Datenprobleme sind häufig softwarebedingt. Formularanpassung – Passen Sie Incident-Formularvorlagen an, um die richtigen Informationen abzufragen. So können Sie die Quote der Lösung beim ersten Anruf (First Call Resolution – FCR) erhöhen und das Ticket dem richtigen Agenten zuweisen.
• Anwendungs-Bug– Software-Bugs und -Fehler beeinträchtigen den Nutzer bei der Ausführung normaler Aufgaben und werden nach ihrem Auftreten als Incidents behandelt.
• Bericht nicht ordnungsgemäß formatiert – Daten spielen bei der Entscheidungsfindung eine zentrale Rolle. Ein Fehler in den Berichtfunktionen kann daher zu erheblichen Geschäftsstörungen führen.
• Applikation führt dazu, dass sich das Betriebssystem aufhängt – Softwarekompatibilität, Applikations-Bugs und Umweltprobleme können zu Störungen in einem einzelnen Softwareteil oder einem ganzen System führen.

Hardware-Incidents

• System außer Betrieb – Serverprobleme, Ausfälle von Komponenten und Probleme mit der Infrastruktur (etwa Stromversorgung und Kühlung) können die Verfügbarkeit und die Leistung von Hardwarekomponenten beeinträchtigen.
• Verbindung zur Ressource kann nicht aufgebaut werden– Netzwerkprobleme können der Grund dafür sein, dass Nutzer nicht auf zentralisierte Ressourcen wie Server oder Softwaredienste zugreifen können.
• Kapazitäts- und Ressourcennutzungsalarme – Software-Bugs und -Fehler beeinträchtigen den Nutzer bei der Ausführung normaler Aufgaben und werden nach ihrem Auftreten als Incidents behandelt.
• Bericht nicht ordnungsgemäß formatiert – Daten spielen bei der Entscheidungsfindung eine zentrale Rolle. Ein Fehler in den Berichtfunktionen kann daher zu erheblichen Geschäftsstörungen führen.
• Drucker druckt nicht – Für viele Unternehmen sind Drucker eine unumgängliche Verknüpfung von digitalen Fähigkeiten und operativen Prozessen. Eine Störung im Druckbetrieb kann ganze Produktionsprozesse unterbrechen.

Nicht alle Incidents sind gleich wichtig, haben die gleichen Auswirkungen und sind gleich dringend. Einige Incidents führen zu ganzen Arbeitsausfällen, während andere nur lästig sind und leicht umgangen werden können. Ein Incident kann eine einzelne Person (oder niemanden), ein Team, einen Standort oder eine ganze Organisation betreffen. Je nach Tageszeit, Stärke der Auswirkungen und Bedeutung der betroffenen Geschäftsfunktionen erfordern Incidents verschiedene Dringlichkeitsstufen und Aufmerksamkeit. Die meisten Unternehmen nutzen formalisierte Service Level Agreements (SLAs) für die Bewertung der Auswirkungen und der Dringlichkeit von Incidents. Anhand der SLAs weisen Sie den Incidents Prioritäts- und Kritikalitätswerte zu, die sicherstellen, dass die Ressourcen so konzentriert werden, dass die dringendsten Incidents zuerst gelöst werden.

Was ist der Unterschied zwischen einem Incident und einer Anfrage?

Helpdesks und IT-Servicedesks bearbeiten nicht nur Incidents, sondern auch andere Probleme von Nutzern. Eine der häufiger auftauchenden Probleme sind Nutzeranfragen. Während ein Incident eine Störung eines normalen Prozesses ist (etwas ist kaputt), ist eine Anfrage eine Aktivität, zu deren Ausführung der Nutzer Unterstützung benötigt (etwas muss erledigt werden). Beispiele für Anfragen können das Einrichten von Systemen für einen neuen Mitarbeiter, das Gewähren von Zugriff auf Daten oder das Ausführen eines Updates der Systemsoftware sein. Obwohl Incidents und Anfragen oft ähnlichen Prozessen folgen und gegebenenfalls auch die Nutzung derselben Tools für das Nachverfolgen erfordern, sind Anfragen nicht auf ein Versagen oder eine Störung gerichtet. Sie sind vielmehr Teil des normalen Geschäftsganges.

Was ist ein schwerwiegender Incident und wie unterscheidet er sich?

Ein schwerwiegender Incident (auch „Major Incident“ genannt) ist eine spezielle Klassifizierung für Incidents in Krisensituationen. Ein solcher Incident bezeichnet eine weitreichende Störung der Geschäftsoperationen, ein kritisches Sicherheitsrisiko oder die Unfähigkeit des Unternehmens, die Erwartungen der Kunden zu erfüllen. Schwerwiegende Incidents erfordern oft eine erhöhte Einbindung des Managements, um die Auswirkungen zu bewerten und die Kommunikation zu koordinieren. Auch kann ein möglicher Incident-Manager stärker eingebunden sein. Zugleich gelten formalere Entscheidungsfindungsstrukturen. Schwerwiegende Incidents sind hochgradig zeitkritisch und können auch die Einbindung von Ressourcen außerhalb der Geschäftszeiten erforderlich machen, um bei der Diagnose und Lösung des Problems zu helfen.

Was ist der Unterschied zwischen Incident-Management und Problemmanagement?

Die Begriffe „Incident“ und „Problem“ werden häufig synonym verwendet. Es gibt jedoch einen wichtigen Unterschied zwischen beiden. Das Incidentmanagement befasst sich mit den Symptomen und Auswirkungen eines Problems. Das Problemmanagement dagegen befasst sich mit dem Grund und dem Potenzial des wiederholten Auftretens des Problems.

Die Incident-Zeitleiste beginnt, wenn eine Störung der normalen Operationen auftritt und endet, wenn der Service wiederhergestellt ist und der normale Betrieb wieder aufgenommen wird. Eine Problemzeitleiste beginnt zu dem Zeitpunkt, zu dem das unterliegende Problem in das Umfeld gelangt ist (oft durch eine Änderung der Konfiguration, einen Release oder eine Änderung der Nutzung). Sie endet, wenn das unterliegende Problem beseitigt ist (was möglicherweise erst mit einem zukünftigen Release der Fall ist). Problemmanagement umfasst Aktivitäten wie eine Fehler-Ursachen-Analyse, eine Risikobewertung und die Priorisierung sowie die Auswahl einer langfristigen Lösung.

Standards des Incident-Managements

Es gibt zwei Hauptbranchenstandards, die Unternehmen für ihre Incident-Managementprozesse nutzen. Da das Incident-Management so weit verbreitet ist und von nahezu jeder IT-Organisation betrieben wird, gibt es nur wenig Bedarf für Benutzeranpassungen. Standards sind daher hilfreich bei der Einweisung von Organisationen, was getan werden muss und wie der Incident-Managementprozess zu steuern ist.

Die IT-Infrastrukturbibliothek (ITIL) ist die am häufigsten genannte Referenz für das Incident-Management. Sie wird genutzt, um operative Prozesse in Unternehmen zu erstellen. Als Teil des Gesamtbereiches der IT-Serviceoperationen ist ITIL vor allem auf Prozesse des Incident-Managements ausgerichtet, einschließlich Schnittstellen mit anderen Prozessen, etwa dem Änderungsmanagement, dem Problemmanagement und dem Anforderungsmanagement.

ISO 20000-1 ist der internationale Standard für das Incident-Management. Der ISO-Standard wird seltener zum Erstellen von Operationen verwendet, sondern eher zum Schaffen von Vertragsbeziehungen und zum Festlegen von Leistungsstandards für Serviceanbieterorganisationen.