Software Katalog in ITSM 7.6.04 und Neuerung in 7.7

In der aktuellen Version ITSM 7.6.04 ist die Abbildung des Software Kataloges für die Enduser im Request Management noch sehr kompliziert. In der neuen Version 7.7 (2. Hj. 2012)werden sehr gute neue Templates mitgeliefert. Hier sollte im Zweifelsfall auf kurzfristiges Customizing verzichtet werden.

Sprachen in BMC ITSM Suite - weniger ist mehr

Eine Installation der ITSM sollte möglichst schlank gehalten werden. Dies beinhaltet auch die installierten Sprachen. Wir empfehlen in der Installation der ITSM daher unbedingt auf unnötige Sprachen zu verzichten und ausschließlich Englisch zu installieren. Damit sind einige Vorteile verbunden:

• kürzere Installationszeit
• kürzere Updatezeiten - dadurch höhere SLAs durch kürzere Wartungsfenster
• wenige Updateaufwand
• weniger Aufwand in der Erstellung von Manuels und Schulungsunterlagen
• weniger Missverständnisse durch unterschiedliche Begriffe

Sollten Sie später gezwungen sein, eine weitere Sprache zu Installieren, so ist dies nachträglich möglich. Anders herum lassen sich einmal installierte Sprachen nicht wieder aus dem System entfernen.

Daher: Tobt euch bei der Mehrsprachigkeit in der Erziehung eurer Kinder aus - aber lasst die ITSM davon verschont!

Abgrenzung Incident & Problem

Wie ist die Abgrenzung von Incident Requests und Problem Records definiert?

Steht ein Service einem Nutzer ungeplant nicht mehr zur Verfügung, so schränkt ihn dies in seiner Tätigkeit ein. Um diese Einschränkung möglichst schnell zu beheben, meldet der Nutzer die Störung dem Service Desk. Diese Einschränkung wird als Incident bezeichnet. Die Meldung der Einschränkung bezeichnet man als Incident Request. Nun soll also der Service schnellst möglich wieder hergestellt werden. Der Incident Request wird nun unterschiedliche Bearbeitungsphasen durchwandern. Jetzt könnte es sich um ein besonders kniffliges Problem handeln und ein Techniker beißt sich daran die Zähne aus. Es ist klar absehbar, dass er die Ursache des Incidents nicht in der vereinbarten Wiederherstellzeit beseitigen kann. Genau wenn dies absehbar wird, sollte aus dem Incident Management ein Problem Record erfasst werden.

Incident

Service Einschränkung oder Service Unterbrechung, welche es schnellstmöglich, ggf. durch Workarounds, zu beheben gilt. Der Fokus liegt nicht auf der besten Lösung sondern auf der schnellen Wiederherstellung der Funktion.

Problem

Besonderen Fällen muss man auf den Grund gehen. Um vorzubeugen und um das Problem bei der Wurzel zu packen. Diese Fälle müssen genau analysiert werden und unterschiedliche Lösungsmöglichkeiten müssen abgewogen werden. Dies steht im Gegensatz zur schnellen Vorgehnsweise beim Incident Management. Daher wird nach ITIL hier das Problem Management eingebunden, welches sich nach eigenem Prozess und Rollen um genau diese Fälle kümmert.

Abgrenzung

Die Abgrenzung von Incident und Problem liegt demnach in der unterschiedlichen Zielsetzung der Prozesse:
Incident - schnell
Problem - nachhaltig

Abgrenzung Incident und Service Request

Wie unterscheiden sich Incident Requests von Service Requests?

Incident Request: Service Unterbrechung
Beispiel: Der E-Mail Service ist unterbrochen. Es können keine Mails mehr gesendet oder empfangen werden.

Service Request: Generelle Service Anfrage
Beispiel: Der Mitarbeiter in der Produktion hatte bislang keinen E-Mail Service, benötigt zukünftig aber auch E-Mails.

Service Requests sind also häufig Anforderungen für die Service-Bereitstellung oder Änderungen an bestehenden Services. Sie können daher zur weiteren Ausführung einen Change anstoßen.

Gelegentlich treten auch Service Requests in Form von reinen Informationsanfragen auf.

SLA Messung für Service-Verfügbarkeit

In diesem Blogbeitrag möchte ich die unterschiedlichen Methoden zur SLA Messung der Service Verfügbarkeit mit den jeweiligen Vor- und Nachteilen darstellen.

SLA Messung "Incidents von Meldung bis Lösung"
Vorteile
Einfache Messmethode, da kein zusätzlicher Aufwand für die Ermittlung der Service Verfügbarkeit entsteht.

Nachteile
Es wird eigentlich nicht die tatsächliche Downtime sondern die Bearbeitungszeit von Incidents gemessen. Es kann also zu Abweichungen der ermittelten und tatsächlichen Verfügbarkeit kommen.

SLA Messung "Service Downtime"
Vorteile
Unabhängig der Incident Bearbeitungszeit wird die Service Downtime im Incident manuell durch den Incident Bearbeiter erfasst.

Nachteile
Die Bearbeitungsdauer ist abhängig von der Disziplin der Erfassung von Service Downtimes und Restores. Es kann also zu Abweichungen der eingetragenen und tatsächlichen Verfügbarkeit kommen.

SLA Messung "System- und Service-Monitoring"
Vorteile
Die Messung der Serviceverfügbarkeit erfolgt automatisiert und stetig. Es werden also auch Serviceunterbrechungen erfasst, welche nicht als Incident gemeldet werden. Sobald die Service Verfügbarkeit wieder hergestellt ist, wird auch dies erfasst. Es ist also eine sehr genaue und umfassende Messmethode.

Nachteile
Es muss ein umfangreiches Service-Monitoring implementiert und betrieben werden. Eine fehlerhafte Konfiguration kann zu falschen Daten führen.

Incident Management - die einzelnen Schritte von der Meldung bis zum Abschluss

In diesem Blogbeitrag möchte ich die typischen Schritte eines Incidents von der Meldung bis zum Abschluss darstellen.

Incident Request Registration
Der Incident und die nötigen Informationen für eine schnelle Behebung des Incidents werden aufgenommen. Es erfolgt eine Priorisierung durch Festlegung der Dringlichkeit und Störungsauswirkung.

Incident Request Assignment
Die verantwortliche Gruppe oder Person zur weiteren Bearbeitung wird zugordnet.

Incident Request Tracking
Um die Termingerechte Incident-Bearbeitung sicher zu stellen, wird der Incident kontinuierlich auf mögliche Terminüberschreitungen überwacht.

Incident Request Resolution by Specialist
Die Behebung der Ursache wird durch einen Specialist durchgeführt. Bei Bedarf kann der 3rd Level Support (Supplier) hierzu eingebunden werden.

Incident Escalaton Handling
Kann der Incident durch die Specialists nicht im nötigen Zeitrahmen gelöst werden, so kann er bei Bedarf an das Continuity Management z.B. zur Wiederherstellung in der Recovery Site oder das Change Management z.B. als Emergency Change anstossen.

Incident Request Closure
Nachdem der Incident behoben wurde, wird er nach Bestätigung des Users geschlossen.

Solution Approval
Soll die neue Lösung allen zugänglich gemacht werden, so kann über "Solution Approval" eine neue Lösung aktiviert werden.

Basics rund um Incident Management

Als frisch gebackener Solution Architekt für Incident Management verschaffe ich mir erst einmal die nötigsten Informationen.

Was ist Incident Management?

Eine ordentliche Google-Recherche lässt den Einsteiger einen guten Überblick bekommen. Es könnte sich also um einen Prozess aus ITIL handeln? Dann aber am besten gleich aus ITILv3, denn wir wollen ja up to date sein. Es könnten alle Maßnahmen sein, die zur Steuerung von "Incidents" eingesetzt werden. Nun dann ist erst einmal eine Definition von Incident nötig.

Incident (englisch): Fehler, Vorfall, Ereigniss, - am besten gefällt mir aber "Affäre" ;-)

Es geht also um mehr, als ausschließlich Fehler, das könnte noch mal wichtig sein...

Nun gibt es auch zum Begriff Management viele Definitionen. Im Wesentlichen verstehe ich darunter Organisation und Steuerung. Es soll also vermieden werden, dass die Incidents unkoordiniert bearbeitet oder eben auch gar nicht bearbeitet werden.

Incident Management definiert und steuert also die Vorgehensweise von der Entstehung bis zur abschließenden Erledigung eines Incidents über den gesamten Lebenszyklus.

Wenn wir wissen, was es ist, stellt sich mir noch die Frage, wozu es überhaubt benötigt wird.

Was führt zu einem Bedarf nach Incident Management?

Um diese Frage zu beantworten, sollten wir uns kurz ins Gedächtnis rufen, warum wir überhaupt IT-Services erbringen. Im Wesentlichen wollen wir das Unternehmen durch IT-Services dabei unterstützen, die Unternehmensziele zu erreichen. Wenn wir dieser Anforderung ordentlich nachkommen, ergibt sich hieraus folgender Rückschluss:

Wenn ein IT-Service nur eingeschränkt oder gar nicht funktioniert, dann ist auch die Erreichung der Unternehmensziele gefährdet.

Ziele von Incident Management:

Das wichtigeste Ziel vom Incident Management ist, die Funktion des IT-Services schnellst möglich wieder im vereinbarten Zustand herzustellen.

Nun ist es sicher möglich, die Effektivität und Effizienz von Incident Management durch Kennzahlen zu messen.

Kennzahlen zu Incident Management:

• Anzahl gemeldeter Incidents
• Durchschnittliche Antwortszeit nach Incident Meldung
• Dauer bis zur Behebung des Incidents
• Erstlösungsrate
• Bearbeitung innerhalb der SLAs
• Aufwand der Incidentbearbeitung
• Remote-Lösungsquote durch Fernzugriff
• Anzahl Eskalationen
• Anzahl doppelter Incidents

Besonders wichtig bei der Nutzung und Auswertung von Kennzahlen, ist die ausgewogene Auswahl von Kennzahlen zur Effektivität und Effizienz. Darüber hinaus sollten einzelne Kennzahlen immer im Kontext des Gesamtsystems betrachtet werden. Eine einzelne Kennzahl isoliert zu betrachten, und hieraus direkt Handlungen abzuleiten, wäre sicher zu kurz gesprungen.

Welche Anforderungen müssen für gutes Incident Management erfüllt sein?

• Die vereinbarte Funktion des Services muss bekannt sein.
• Die vertraglichen Vereinbarung im Bezug auf Qualitätsparameter bei der Störungsbehebung müssen bekannt sein.
• Die vom Incident betroffenen Services müssen identifiziert werden.
• Die Wichtigkeit dieser Services muss bekannt sein.

Funktionen vom Incident Management:

• Annahme einer Incident Meldung
• Dokumentation der Incident Meldung
• Spezifizierung der relevanten Informationen zum Incident und für dessen Bearbeitung
• Priorisierung des Incidents
• Behebung - ggf. auch durch Workaround - eines Incidents
• Information über den Bearbeitungsstatus und Erledigung des Incidents

Links:

http://wiki.de.it-processmaps.com/index.php/Incident_Management