Request Fulfilment - Incident, Change oder Workorder verwenden

Wer das BMC Service Request Management einführt, schafft für Endbenutzer die Möglichkeit,  auf deinem Self-Service Portal Anfragen an die IT selbständig zu erstellen und einzureichen.
Doch welches Modul der BMC ITSM Suite eignet sich am besten, um diese Anfragen weiter zu bearbeiten?
Dieser Beitrag soll einen Ansatz für die Entscheidung geben.

Welche BMC Remedy ITSM Module stehen überhaupt zur Verfügung?

• Change Management
• Incident Management
• Work Order Management

Jedes dieser Module ist unterschiedlich ausgestaltet und hat unterschiedliche Schwerpunkt.
Handelt es sich bei der Anfrage des Endbenutzers um eine Störung, so ist sehr einfach zu entscheiden, dass Incident Management das Mittel der Wahl ist.
Doch welches Modul ist geeignet, um Standard "Bestellungen" wie die Bereitstellung einer neuen Applikation auf einem Notebook zu verarbeiten?

Viele Unternehmen definieren Changes folgendermaßen: Wird eine Veränderung an einem CI vorgenommen, welches dem Configuration Management unterliegt, so handelt es sich definitiv um einen Change.
Hierfür wäre also das Change Management Modul der ITSM Suite am besten geeignet, denn es bietet mit der Abbildung der Change Prozess Phasen und Schritte sowie Genehmigungen und Risikobewertungen die optimale Unterstützung für das Change Management.

Doch wenn ein Unternehmen für Clients kein Configuration Management betreibt, kann es durchaus möglich sein, hierfür einen der beiden folgenden Wege zu nutzen:

1. Incident Management mit dem Incident Type "User Request"

Hierbei wir das Incident Management Modul verwendet. Das ist insbesondere dann sinnvoll, wenn die Tätigkeit in der Regel durch einen Service Desk Mitarbeiter erledigt wird, der generell mit dem Incident Management arbeitet. Bekommt er einen neuen Anruf, so erfasst er in aller Regel die Kontaktinformationen des Anrufers bereits im Incident Management und hätte einen deutlichen Mehraufwand, im späteren Verlauf aus dem Incident Management in ein anderes Modul zu wechseln.
Der Type "User Request" stellt hierbei insbersondere die Möglichkeit der differenzierten Auswertung bei Reporting zur Verfügung.

2. Work Order Management

Wird kein expliziter Change Management Prozess und unterliegt das CI nicht dem Configuration Management, so kann auch das Work Order Management genutzt werden. In aller Regel wird dieses Modul für "Non-IT Aufgaben" wie die Bestellung eines neuen Schreibtisches genutzt. Es verfügt auch über die Möglichkeit, mit Tasks zu arbeiten.

BMC Remedy Action Request System (ARS)

Das Action Request System (ARS) von BMC Software ist die Basis der ITSM Suite. Es dient sowohl als Applikationsserver sowie als Entwicklungsplattform. Damit ist es die Grundlage für die Applikationen, mittels welcher die IT Service Management Prozesse abgebildet werden.

Früher wurden viele individuelle Service Desk Applikationen individuell auf Basis von ARS entwickelt. Heute geht der Trend eher in Richtung Standardisierung. Die BMC ITSM Suite 8.1 ist die aktuelle Version. Hier werden die ITIL Prozesse in Standard Modulen abgebildet.

Der besondere Vorteil der ITSM Suite auf Basis der ARS Plattform ist, dass sich hier sehr schnell ein sehr durchdachtes und umfangreiches System einführen lässt. Die Wartungskosten werden im Vergleich zu Eigenentwicklungen wesentlich reduziert, da Fehler und neue Produkt-Features über Updates kostenfrei bzw. vergleichsweise günstig bereitgestellt werden. Trotzdem muss nicht auf die Flexibilität verzichtet werden, da sich Anpassungen und Erweiterungen auf der ARS Plattform integrieren lassen.

BMC Release Management zur Unterstützung des Change Managements

BMC Release Management ist ein Modul der BMC Remedy ITSM Suite. Viele Kunden haben das Release Management Modul bereits mit dem Change Management lizenziert, sind sich dessen aber gar nicht bewusst.
Release Management ermöglicht die Planung mehrerer Changes, die in einem engen Zusammenhang stehen. Hier können Überschneidungen und Abhängigkeiten dargestellt und geplant werden. Der Change Calendar der aktuellen Version der ITSM Suite stellt ebenfalls einen Release Calendar dar. Hier könnten also neben allen Changes auch alle Release angezeigt werden.

Innerhalb eines Releases können Phasen und Meilensteine beplant werden. In diesen Phasen wiederum können Changes und sogenannte Activities geplant werden. Activities stellen alle Release-relevanten Aufgaben dar, welche keinen Change erfordern. Ein Beispiel für eine Release Activity ist das erstellen einer Präsentation zur Einführung des Release.

Das BMC Release Management ist damit das richtige Werkzeug, wenn die Anzahl und Wechselwirkungen der Changes sehr hoch sind, eine weitere Planungsebene einzuführen, um bei der Planung, Durchführung und das Testen der Changes Synergien zu nutzen und auf Mehrfacharbeiten wie Integrationstests zu verzichten.

Zusammenspiel Incident Management und Problem Management

In der Praxis stellt sich häufig die Frage, wie man das Zusammenspiel zwischen Incident Management und Problem Management erfolgreich gestaltet. Soll aus dem Incident Management heraus aktiv die Initiierung von Problem Investigations angestoßen werden? Oder lieber anders herum aus dem Problem Management heraus eine Analyse der Incidents erfolgen, aus welcher potentielle Problems einer Untersuchung unterzogen werden?

Problem Management nach dem Push- oder Pull-Prinzip

Je nach Komplexität und Größe Ihres Service Desk macht es in jedem Fall Sinn, nicht auf einen Schlag und ohne dedizierte Schulung alle First und Second Level Mitarbeiter nach eigenem Ermessen Problem Investigations zu generieren. In der Praxis erweist es sich eher als erfolgsversprechend, eine geringer Anzahl an Mitarbeitern im Problem Management zu qualifizieren und durch Auswertungen der Incidents die Generierung von Problem Investigations zu starten.

Fazit

Statt vieler Mitarbeiter ohne weiterführendes Wissen zum Problem Management lieber wenige Mitarbeiter gut qualifizieren und den Kreis zu Beginn schlank halten.

Problem Management in BMC ITSM Suite Service Desk

Hintergrund

Problem Management hat zum Ziel, IT-Probleme dauerhaft zu lösen. Es ist ein Prozess aus ITIL und steht bei der Erkennung von Problems in engem Zusammenhang zu Incident Management. Bei der Lösung der Problems wiederum gibt es eine enge Zusammenarbeit mit dem Change Management. Ein Eintrag eines Problems nennt sich Problem Record.

Ziele des Problem Managements

• Vermeidung potentieller Incidents
• Reduzierung der Auswirkung von Incidents
• dauerhafte Behebung der Ursache von wiederkehrenden Incidents

 

Der Problem Management Prozess

• Identifizierung von Problems
• Erfassung (schriftlich dokumentieren)
• Problem-Kategorisierung
• Problem-Priorisierung
• Problem-Diagnose und -Lösung
• Problem-Überwachung und -Steuerung
• Problem-Abschluss und -Auswertung
• Review von Major Problems
• Reporting
• Pflege der Known Error Database

Die Prozessphasen in der BMC ITSM Suite

• Identification and Classification
• Review
• Investigation and Diagnosis
• Resolution and Recovery
• Closed

Die Status eines Problem Records in der BMC ITSM Suite

• Draft
• Under Review
• Request for Authorization
• Assigned
• Under Investigation
• Pending
• Completed
• Rejected
• Closed
• Cancelled

Known Error Record

Ein Known Error Record bezeichnet im Rahmen von ITIL einen Datensatz, welcher ein Problem mit der Ursache sowie einem verifizierten Workaround beinhaltet.
Im Rahmen der BMC ITSM Suite wird der Known Error Record auch dazu genutzt, das Change Management anzusteuern. Statt aus einem Problem heraus direkt einen Change Request zu generieren, wird ein Known Error Record erstellt und in der Zuständigkeit dem Change Manager zugewiesen. Dieser kann die Lösung des Known Errors dann in seiner Change Planung einfließen lassen.

Incident Management

Incident Management ist die wohl häufigste ITIL Disziplin, die in der Praxis anzutreffen ist. Denn mit Incident Management bekommt man die täglichen kleinen "Brände", die in einer lebendigen IT-Umgebung nun einfach gelegentlich entstehen, in einem strukturierten Prozess gelöscht.

Viele Organisationen hatten vor der Einführung von Incident Management das Problem, dass die IT-Störungen auf Zuruf an den lokalen IT-Ansprechpartner gemeldet wurden. Die IT-Mitarbeiter konnten dann die Prioritäten der Störungen und Vorfälle nicht zentral beurteilen und Ihre Ressourcen nicht zielgerichtet einsetzen. Auch der Ablauf einer Störungsbeseitigung verläuft ohne Incident Management häufig unterschiedlich, je nachdem mit welchen IT-Mitarbeiter man gerade zusammentrifft.

 

Incident Management in der Praxis

Ein Incident wird an einer zentralen Stelle (Service Desk) gemeldet und registriert. Dann erfolgt eine Bewertung des Incidents nach Auswirkung und Dringlichkeit. Aus der gewichteten Kombination dieser Parameter wird die Priorität ermittelt. Dieser Schritt ist besonders wichtig, da User dazu neigen, alle IT-Störungen mit höchster Priorität zu melden. Das entspricht der jeweiligen subjektiven Sicht, ist aber für das Unternehmen als ganzes natürlich zu kurz gedacht. Denn wenn alle IT-Mitarbeitern mit unwichtigen Störungen beschäftigt sind und eine wirklich wichtige zentrale Störung daher nicht beheben können, hätte das Unternehmen dadurch einen unverhältnismäßig hohen Schaden.

Nach der Aufnahme und Bewertung wird der Incident Request an einen zuständigen Bearbeiter zugewiesen. Dieser ist nun für die Behebung der Störung und ggf. Einbindung weiterer Experten zuständig.

Im Incident Request werden Bearbeitungsnotizen hinzugefügt, damit alle Informationen an zentraler Stelle nachgelesen werden können.

Nach Abschluss des Incidents wird üblicherweise eine Nachricht an den Kunden versandt, welche die Incident Nummer und die Lösung des Incidents beinhaltet.