Service Request Management

Beschreibung

Service Request Management wickelt alle Anfragen der Benutzer bezogen auf einen Service ab. Service Request Management Prozess kontrolliert und berichtet über die vereinbarten Key Performance Indicators (KPIs) für den Kunden und für das interne Management. Service Request Management Prozess ist verantwortlich für die Bereitstellung von regelmäßigen Informationen an den Benutzer (User). Der Service Desk ist für die Annahme, das Akzeptieren, die Klassifikation und das Abwickeln des Request (Anfrage) verantwortlich ist. Der Prozess Request Fulfilment in ITIL V3 behandelt die Service Requests und ist der korrespondierende Äquivalent zum hier beschriebenen Service Request Management Prozess.

Ziele

Gegenstand des Service Request Managements ist es, Service Requests zu akzeptieren, zu registrieren und den Request entsprechend seiner Dringlichkeit zu bearbeiten. Vor allem ist es Ziel des Service Request Management die Zufriedenheit des Users sicherzustellen.

Rollen & Funktionen

Service Request Management spezifische Rollen

Statische Prozessrollen

Service Request Management Prozessverantwortlicher (Process Owner)
Initiator des Prozesses. Er ist verantwortlich für das Definieren der prozessstrategischen Ziele und das Bereitstellen aller erforderlichen Ressourcen. Siehe auch Continual Process Improvement Management für eine detaillierte Beschreibung dieser Aktivitäten. Meist gibt es nur eine Prozessverantwortlicher (Process Owner) für alle Service Management Prozesse.

Service Request Management Prozess Manager (Service Request Manager)
Manager des gesamten Prozesses. Er ist verantwortlich für seine Effektivität und Effizienz. Siehe auch Continual Process Improvement Management für eine detaillierte Beschreibung dieser Aktivitäten. Meist identisch mit dem Incident Management Prozess Manager.

Dynamische Prozessrollen

Diese Rollen werden während der Ausführung des Service Request Management Prozesses dynamisch belegt.

Service Request Verantwortlicher (Owner)
Das Attribut im Record (Ticket) beinhaltet den Namen der Person oder Gruppe die gegenwärtig für den Service Request (aber NICHT für den Service Request Management Prozess) rechenschaftspflichtig (accountable) ist. Der Service Request Verantwortliche kann durch eine Hierarchische Eskalation verändert werden.
Service Request Bearbeiter (Agent)
Das Attribut im Record (Ticket) beinhaltet den Namen der Person oder Gruppe die gegenwärtig für eine Aktivität oder einen Task innerhalb des Lebenszyklus eines Requests verantwortlich ist. Der Service Request Bearbeiter kann durch eine Funktionale Eskalation verändert werden, wenn dies die Regeln erlauben

Servicespezifische Rollen

Rollen die von einem betroffenen Service abhängen findet man in der Service Beschreibung (Description) Die Service Beschreibung inklusive der servicespezifischen Rollen, wird vom Service Portfolio Management geliefert.

Service Experte und Service Spezialisten
Übernimmt die dynamische Rolle des Service Request Bearbeiters (Agent).

Service Verantwortlicher (Owner)
Dies ist die Person, die für einen Service, wie er in der Service Beschreibung definiert ist, verantwortlich ist. Übernimmt bei einer hierarchischen Eskalation die Rolle des Service Request Verantwortlichen, kann aber auch als Service Request Bearbeiter (Agent) eingesetzt werden.

Kundenspezifische Rollen

Rollen, die von den betroffenen Kunden abhängen findet man in den Service Level Agreements (SLA). Das Service Level Agreement für kundenspezifische Rollen wird durch das Service Agreement Management gepflegt.

Kunden (customer)
Kunden des betroffenen Service mit einem gültigen SLA

Benutzer (User)
Verbraucher des Service und zur Abgabe von Service Requests durch den Kunden berechtigt

Service Desk
Funktion die die dynamische Rolle des Service Request Bearbeiters (Agent) anfänglich übernimmt, sofern dies nicht anders definiert ist. Die Funktion kann auch servicespezifisch definiert sein.

Informationsdokumente

Dieser Bereich beschreibt Dokument die während der Ausführung eines Service Request Managements Prozesses entstehen und Dokumente die zur Ausführung des Prozesses benötigt werden, sofern sie nicht von einem anderen Prozess bereitgestellt werden müssen und daher in der diesbezüglichen Prozessbeschreibung definiert werden

Service Request Record

Der Service Request Record ist das Informationsdokument, das alle für das Management relevanten Informationen inklusive der Historie eines spezifischen Requests (Prozessinstanz) enthält. Beim durchlaufen des Prozesses wird er mit Informationen gefüllt. Nach Abschluss der Prozessinstanz darf der Record nicht mehr verändert werden.

• Service Request ID (Ticket ID) – Eindeutige Bezeichnung (Unique identifier)
• Anfangsdatum (Opening date) – Zeitpunkt für die Aufnahme des Service Requests
• Status – Zustand innerhalb des Lebenszyklus eins Requests. Der Statusübergang findet statt, wenn eine Kontrollaktivität positiv passiert wurde.
• Betreff (Subject) – Kurzbeschreibung der Anfrage
• Lösungsbeschreibung (Solution Description) – Beschreibung der Lösung
• Service Request Beschreibung (Service Request Description) – Beschreibung des Service Request und Dokumentation der einzelnen Schritte
• Service Request Verantwortlicher (Owner)
• Service Request Bearbeiter (Agent)
• Kunde (customer) – Kunde(n) die von diesem Request betroffen sind
• Benutzer (User) – der oder die Benutzer die vom Request betroffen sind
• Antragsteller (Requester) – Name der Person die den Service Request auslöst, oft identisch mit Benutzer
• Services – Service(s) die von diesem Request betroffen sind
• SLA – Informationen zum relevanten Service Level Agreement (SLA)
• betroffenes CI – Hardware oder Software CI, dass von der Anfrage betroffen ist
• Priorität – Priorität auf Basis des relevanten SLA
• Medium – Beschreibt das Medium das zum Auslösen des Service Requests genutzt wurde. Wird auch als bevorzugter Informationskanal für die weitere Kommunikation verwendet
• ausgelöste Changes – Liste der durch den Service Request ausgelösten Veränderungen
• Endtermin (Resolution date) – Der Endtermin (Zeitpunkt) hängt von der Priorität des Requests ab
• Weiterleitungen (Times Forwarded Agent) – Anzahl der funktionalen Eskalationen eines Service Requests
• Hierarchische Eskalation (Times Forwarded Owner) – Anzahl der hierarchischen Eskalationen eines Service Requests
• Anmerkungen – Informationsfeld in dem die einzelnen Arbeitsschritte kommentiert werden und zusätzliche Informationen hinzugefügt werden kann
• Abschluss Anmerkung (Closing Comment) – Zusätzliche Information bezogen auf die Abschlussaktivität
• Anhänge (Attachments) – Andere Dateien, Dokumente, Screenshots etc.

Service Request Meldung (Notification)

Information die dem Melder und/oder Benutzer aktiv oder passiv zur Verfügung gestellt wird.

• Service Request ID
• Status Betreff
• Priorität
• Endtermin Service Request Beschreibung
• Lösungsbeschreibung

Schlüsselkonzepte

Service Request Klassifikation

Der Service Request muss klassifiziert werden und ein Endtermin muss definiert werden. Diese Klassifikation ist eine fortlaufender Aktivität bis der Request erfüllt ist. Der Endtermin muss so festgesetzt werden, dass sichergestellt ist, dass das vereinbarte Service Level nicht übertreten wird.

Priorität

Priorität ist eine Steuergröße und unterstützt das Management die Ressourcen effizient zu einzusetzen. (z.B. Personal, Kapazität, Zeit).

Service Request Lebenszyklus

Status	Status	Beschreibung
neu	new	Der Service Request Management Prozess ist ausgelöst. Der Record ist erstellt und es wurde eine eindeutigen ID generiert.
registriert	registered	Die für die Aktivität „Registrierung“ notwendigen Information (Minimum: definierte Pflichtfelder) sind im Record eingefügt
klassifiziert	classified	Der Request wurde klassifiziert. Die Steuergrößen sind definiert und eingetragen. Die richtige Klassifikation des SR hat höchste Priorität und muss angepasst werden, falls neue Informationen vorliegen
abgebrochen	aborted	Die Bearbeitung des SR wurde abgebrochen. Der Grund ist dokumentiert.
Anfrage erfüllt	request fulfiled	Der Service Request wurde aus der Sicht des Providers erfüllt.
abgeschlossen	closed	Der SR wurde erfüllt, aus der Sicht des Benutzers erfüllt. alle vorgeschriebenen Aktivitäten sind dokumentiert.

Hierarchische Eskalation

Eine Hierarchische Eskalation muss ausgelöst werden, wenn die Anfrage auf einem “regulären” Weg nicht erfüllt werden kann. Dieser Fall tritt ein wenn folgenden Punkte absehbar sind: Die verfügbaren Ressourcen reichen nicht aus Die Vereinbarungen z.B. Endtermin im relevanten Service Level bzw. SLA könne nicht erfüllt werden.

Eskalationslevel

Sofern im Service Level bzw. Service Level Agreements nicht anders definiert, gelten folgende Eskalationsstufen

• Erster Eskalationsstufe: Service Request Manager
• Zweiter Eskalationsstufe: Service Request Manager und Service Verantwortlicher. Der Serviceverantwortliche muss entscheiden, ob der weitere Personen (Kunde, Kundenverantwortliche) informiert werden muss.

Eine Eskalation kann in jedem Bearbeitungsschritt erfolgen. Die Eskalation muss eingeleitet werden, wenn 75 % der geplanten Dauer eines Service Request aufgebraucht sind. Die geplante Dauer errechnet sich durch den geplanten Endtermin – Zeitpunkt des Auslösens der Anfrage. Bei jeder hierarchischen Eskalation wird der entsprechenden Zähler im Record um eins erhöht.

Prozess

Prozessüberblick

Diese Abbildung zeigt den Service Request Management Prozess und seine Aktivitäten und die dazugehörigen Kontrollaktivität (Status).

Service Request Management Prozess

Kritische Erfolgsfaktoren

Kritische Erfolgsfaktoren (Critical Success Factors (CSF)):

• Registrierung aller Anfragen als Record
• Kontinuierliche Überprüfung der Service Request Klassifikation und des geplanten Endtermins
• Kooperation mit dem Change Management
• Kooperation mit dem Service Portfolio, Service Level und Service Level Agreements Management
• Hohe Benutzer- und Kundenzufriedenheit
• Hoher Anteil an erfüllten Service Requests innerhalb der vereinbarten Zeit

 

Key Performance Indicators (KPI)

Definition

• offener Service Requests = alle Service Requests die NICHT den Status „abgeschlossen“ haben
• gelöster Service Requests = alle Service Requests die den Status “ Request erfüllt“ haben
• geschlossener Service Requests = alle Service Requests die den Status „abgeschlossen“ haben
• Service Request Registrierungsdauer = ZS „registriert“ – ZS „neu
• „Service Request Klassifikationsdauer = ZS „klassifiziert“ – ZS „registriert“
• Service Request Bearbeitungsdauer = (ZS „Request erfüllt“ – ZS „klassifiziert“) oder (ZS „abgebrochen“ – ZS „klassifiziert“)
• Service Request Abschlussdauer = ZS „abgeschlossen“ – ZS „Request erfüllt“ oder ZS „abgeschlossen“ – ZS „abgebrochen“
• Lösungsdauer des Service Requests = Service Request Registrierungsdauer + Service Request Klassifikationsdauer + Service Request Bearbeitungsdauer
• Gesamtdauer des Service Requests = Service Request Registrierungsdauer + Service Request Klassifikationsdauer + Service Request Bearbeitungsdauer + Service Request Abschlussdauer

Die Dauer jeder Aktivität ist via Zeitstempel (ZS) beim setzten des Kontrollstatus messbar.

Auswertung

• Anzahl der aktuell offene Service Requests
• Anzahl der durchschnittlichen offene Service Requests pro Tag/pro Monat
• Anzahl der geöffneten Service Requests pro Tag/pro Monat
• Anzahl der gelösten Service Requests pro Tag/pro Monat
• Anzahl der geschlossenen Service Requests pro Tag/pro Monat
• Anzahl erfüllte Service Requests (Lösungsdauer des Service Requests <= vereinbarte Lösungsdauer für alle gelösten Service Requests pro Tag/pro Monat)

Ausgewertet wird die maximale, minimale und durchschnittliche Zeitdauer pro Kunde und/oder pro Service.

Prozessauslöser (Trigger)

Ereignisgetriebener Auslöser (event triggered)

Service Requests können durch einen Benutzer (User) oder einen Event ausgelöst werden.

Zeitgetriebener Auslöser (Time Trigger)

Service Request können auch periodisch ausgelöst werden.

Prozessspezifische Regeln

• Jeder Service Request löst das Entstehen eines neuen Service Request Record aus.
• Der Service Request Bearbeiter ist verantwortlich für das Dokumentieren jeder Aktivität im Service Request Record
• Der Service Request Verantwortliche muss den Service Request Bearbeiter kontrollieren.
• Der Service Request Verantwortliche und der Service Request Bearbeiter können ihre Pflichten nur übertragen, wenn die neue Person oder Gruppe damit einverstanden ist.
• Der neu Service Request Verantwortliche oder Service Request Bearbeiter muss dann dementsprechend im Service Request Bericht festgehalten werden.
• Der Service Request Verantwortliche und der Service Request Bearbeiter sollten wenn möglich eine Person und nicht eine Gruppe sein.

Prozessaktivitäten

Service Request Registrierung

Der Record wird erstellt und es wird überprüft ob der Antragsteller die Anfrage stellen darf. Alle Informationen des Antragstellers sind in dem Record zu dokumentieren.

Aktivitätsspezifische Regel

• Die ID wird erzeugt
• Der Status wird auf „neu“ gesetzt
• Der Antragsteller wird auf die Person gesetzt, die den Service Request ausgelöst hat
• Der Bearbeiter wird auf das „Service Desk“ gesetzt, falls keine Person verfügbar ist
• Der Verantwortliche wird auf „Service Desk“ gesetzt, falls keine Person als Verantwortlicher verfügbar ist
• Der Betreff wird ausgefüllt
• die interne und externe Beschreibung wird gefüllt. Das Ticket muss eine aussagekräftige Beschreibung des erwünschten Requests enthalten, genauso wie eine verständliche Aussage bzgl. des Grundes des Requests
• Der Kunde wird gesetzt
• Der Benutzer wird gesetzt
• Das Medium wird dokumentiert
• gegebenenfalls Dokumente anhängen
• gegebenenfalls Anmerkungen dokumentieren

Service Request Klassifikation

Die Klassifikation eines Service Requests bestimmt und dokumentiert die Steuergrößen im dazugehörigen Record.

Aktivitätsspezifische Regeln

• Service und Sub-Service bestimmen
• relevante SLA bestimmen
• Priorität bestimmen
• Endtermin bestimmen
• betroffen CI bestimmen
• gegebenenfalls Dokumente anhängen
• gegebenenfalls Anmerkungen dokumentieren
• Information an den Anwender bzw. Melder

Service Request Bearbeitung (Handling)

• Service Request nach Vorgaben bearbeiten
• gegebenenfalls Dokumente anhängen
• gegebenenfalls Anmerkungen dokumentieren
• wenn nötig bzw. vorgesehen weiterleiten
  o ändern des Bearbeiters auf die neue Personen oder Gruppe
  o erhöhen des Zählers „Weiterleitung“ um 1
• wenn nötig RFC stellen und auf Ergebnis des Changes warten
  o ID des Changes bzw. Der Changes in „ausgelöste Changes“ dokumentieren
• Bearbeitung des Requests überprüfen
• die interne und externe Lösungsbeschreibung wird gefüllt
• gegebenenfalls Dokumente anhängen
• gegebenenfalls Anmerkungen dokumentieren

Service Request Abschluss (Closure)

In dieser Aktivität wird der Erfolg eines Service Request ermittelt.

Aktivitätsspezifische Regeln

• der Bearbeiter wird auf den Verantwortlichen gesetzt
• Der Bearbeiter informiert den Benutzer und Antragsteller und wartet gegebenenfalls sein Zustimmung ab.
• Alle Einträge im Record werden überprüft und korrigiert
• gegebenenfalls werden weiter Dokumente anhängen
• die Abschlussanmerkungen wird dokumentieren