Viele ITIL Berater sagen, wenn wir schon Incident Management einführen, können wir auch direkt Request Fulfilment einführen. Service Anfragen gehen sowieso immer über den Service Desk.

Wenn es um IT Fragen, Hilfen oder Zurücksetzen eines Passworts geht, gilt die Antwort – „ja“. Aber der Prozess ist doch etwas mehr. Warum sollte es im Prozessmodell sonst die Frage nach „finanzieller Freigabe“ geben. Für mich verbirgt sich hinter dem Prozess eher der „Materialentnahmeschein“ für das Lager. Ein Prozess, der eigentlich in jedem Unternehmen schon immer läuft. Oft sogar mit eigenen Formularen, ob in  Papierform oder  elektronisch, z.B. als Workflow in Lotus Notes.

Daher die Frage: Macht es Sinn, einen bereits bestehenden und funktionierenden Prozess in die ITIL-Schablone und in ein Service Management Tool zu stecken? Kommt darauf an, sagt schon „Radio Eriwan“. Es gibt Beispiele, wo es durchaus Sinn macht. Dann liegt allerdings hinter dem Prozess ein Service- bzw. Produktkatalog.

Ein Beispiel: Ein Pharmaunternehmen will die Bestellung von Verbrauchs- und Ausrüstungsmaterial seiner Forschungslabore über Request Fulfilment abwickeln. Das Unternehmen hat mehrere Standorte und will das Bestell- und Lagerwesen zentralisieren, sowie seine Lieferanten einbeziehen. Jetzt sagen bestimmt viele: Das gibt es doch schon von SAP. Warum also etwas Neues erfinden? (vgl. Compliance Magazin 2008).

Der Charme liegt zum einen in der normalerweise einfacheren Einrichtung in einem ITSM Tool (Webinterface, Webformular, Integration in andere Prozesse wie Change und Configuration Management) (vgl. Simons, S. 76; vgl. Majer, s. 108) und zum anderen in den  geringeren Kosten (Customizing, Lizenzen).

Damit dies funktioniert, muss aber ein Service- oder Produktkatalog verfügbar sein, aus dem die Anwender auswählen können. Hier ist der Zugang entscheidend. Web-Publishing wird in diesem Zusammenhang immer wichtiger (vgl. Lauer). Viele ITSM Tools haben eine Web-Schnittstelle zu Online Katalogen oder verwenden Webtechnologie zur Darstellung von Produktkatalogen. Ein ganz wesentlicher Aspekt: Anwender müssen nicht nur das Produkt auswählen können, sondern sie müssen auch die Kosten dafür kennen (vgl. Schmidt/ Dohle, S. 67).

Unter diesem  Gesichtspunkt wird Request Fulfilment zu einem recht komplexen Prozess: Definition der Services bzw. Produkte, deren Unterstützung in  den jeweiligen Geschäftsprozessen, der finanzielle Freigabe-Workflow, Definition der Kosten und Abrechnung und der Serviceerbringung, unter Umständen mit Hilfe externer Dienstleister… alles in allem ein sehr komplexer Prozess.

Ein weiteres Anwendungsbeispiel ist die Baustellenausrüstung der Firma Strabag. Die gesamte IT-technische Ausrüstung einer Baustelle wird über Request Fulfilment abgewickelt. Es gibt einen Produkt- und Servicekatalog, der den Bauleitern über ein Webformular zur Verfügung steht. Hintergrund ist eine bessere und planbarere IT-Ausstattung der Baustellen (vgl. Omninet Anwendertreffen 2010).

Kommen wir zurück zur Ausgangsfrage: Sollte man Request Fulfilment zusammen mit Incident Management einführen? Vor dem Hintergrund, dass Request Fulfilment i.d.R. ein bestehender und funktionierender Prozess ist, ein klares Nein. Incident Management alleine ist bereits komplex genug. Darüber hinaus gibt es Prozesse, die wesentlich wichtiger für den Unternehmenserfolg sind und viel weniger ausgeprägt als Request Fulfilment, z.B. Change und Configuration Management.

Autor: Dr. Guido Hoffmann

Quellen:

Rainer Schmidt, Helge Dohle, „ITIL® V3 umsetzen“, Symposion Publishing GmbH, 2009

Christion Simons, „IT Service Management mit ITIL® V3“, 2010

Frederic Majer, „Semantisches Informationsmodel für die Betriebsunterstützung“, 2010

Compliance Magazin, www.compliancemagazine.de, 05.09.2008

Johann Lauer, www.web-publishing.biz

Omninet, Anwendertreffen 2010, www.omninet.de