Prozessautomatisierung in der Praxis

Das Erfüllen von Anwenderanfragen aller Art sowie deren oft sehr grosse Menge stellt viele IT-Organisationen vor Herausforderungen. Das Management dieser Vielfalt kann durch ein durchdachtes Vernetzen aller beteiligten Prozesse verbessert werden. Als Resultat erhält man einen höheren Grad von Automatisierung, wovon nebst dem Anwender auch die IT selbst profitiert.

Von der ITIL^® Version 2 zur ITIL^® Version 3 – die Geburt des Request Fulfilments

In der ITIL^® Version 2 findet man nur unbefriedigende Informationen zum Thema Request Fulfilment, also zur Erfüllung von IT-Anwenderanfragen aller Art. Die Behandlung von Service Requests ist im Incident-Prozess integriert, mit der Begründung, dass diese in der Praxis ähnlich gehandhabt werden wie Ausfälle der Infrastruktur oder Serviceanforderungen[1].
ITIL® V3 «ehrt» diese Thematik mit vier Seiten und gesteht ihr losgelöst vom Incident Management einen eigenständigen Prozess zu. Gemäss Definition beinhaltet Request Fulfilment die Prozesse zur Bearbeitung der Service Requests von Anwendern.
«Der Begriff ‹Service Request› ist eine allgemeine Bezeichnung für die vielen unterschiedlichen Bedarfskonstellationen, mit denen Anwender die IT- Abteilung konfrontieren.»[1]
Man kann einen Service Request aber auch etwas anders auffassen und nach dem Ausschlussverfahren definieren: alle Anfragen von Anwendern, die sich nicht um Störungen (Incidents) oder Beschwerden (Complaints) drehen, sind Service Requests.

Die Praxis geht über ITIL^® hinaus

Was in der Definition einfach tönt, ist in der Praxis relativ komplex. Einerseits können Service Requests von einfachen Dingen wie Passwortzurücksetzungen oder Verbrauchsmaterialbestellungen bis hin zu umfangreichen Beschaffungen von IT-Komponenten alles sein – die Bandbreite an möglichen Geschäftsfällen ist enorm!
Andererseits vernachlässigt ITIL^® verwandte Themengebiete wie z. B. Supply Chain Management (dem Management aller Aufgaben bei Lieferantenwahl, Beschaffung und Logistik), welche für das Request Fulfilment aber unerlässlich sind. Beschaffungsrichtlinien oder gar Vorinventarisierungsprozesse werden in ITIL^® nicht behandelt, in der Praxis ist man jedoch auf das Zusammenspiel dieser Disziplinen angewiesen.

Request Fulfilment – ein Prozess mit vielen Rädern

Kaum ein anderer ITIL^®-Prozess beherbergt dermassen viele Schnittstellen und «Stolpersteine». Request Fulfilment muss interdisziplinär betrachtet  werden, da es von der Anfrage bis zur Erfüllung eines Requests meist ein weiter Weg ist. Das Zusammenspiel der verschiedenen Disziplinen kann man mit einer Maschine vergleichen. Die Maschine läuft aber nur einwandfrei, wenn die verschiedenen Räder richtig und lückenlos ineinandergreifen.

Der Ankurbler
Der Prozess beginnt und endet immer bei einem Endanwender. Dieser hat ein Begehren und möchte dieses platzieren; dabei darf nicht vergessen werden, dass die Anwender meist über keine ITIL^®-Kenntnisse verfügen und nicht unterscheiden können, ob sie dabei einen Incident, einen Service Request oder  einen Standard- oder Normalen Change ausfüllen müssen.
Hier kann man den Endanwender unterstützen, indem die Anlaufpunkte für ALLE seine Begehren zentral ausgelegt sind (in Form eines Webportals oder eines Service Desk) und er seine Anfragen einheitlich platzieren kann.
Die Formulare für einen Service Request (gegebenenfalls unterstützt durch einen Beschaffungsantrag) sollten am besten elektronisch bearbeitbar sein. So kann die Anfrage einerseits ohne Medienbruch an alle involvierten Stellen verteilt werden und andererseits kann die nachgefragte Leistung direkt gegenüber dem Service- und Produktkatalog validiert werden.

Service- und Produktkatalog

Jede IT-Abteilung muss ihre Leistungsbezüger mit Services und mit Produkten bedienen. Ein Katalog mit allen verfügbaren Services und Produkten beinhaltet alle nötigen Mittel zur Erfüllung von Standardrequests. Diese sollten von der IT an Lager gehalten werden.
Anfragen, die sich ausserhalb des Katalogs bewegen, werden entweder nicht erfüllt oder werden nur via Individualbestellungen beschafft resp. bereitgestellt.
Der Katalog wird vorzugsweise im Intranet publiziert und ist über einen Webshop oder ein ITSM-Werkzeug mit Webportal für die Anwender zugänglich.
Services und Produkte sollten zur Steigerung des Kostenbewusstseins mit Preisen versehen sein; über Service Level Agreements lässt sich zudem regeln, welche Organisationeinheiten welche Leistungen und in welcher Menge beziehen dürfen.

Service Desk (Request Fulfilment Group)

Ein Single Point of Contact (SPOC), meist ein Service Desk, der über weitreichende Möglichkeiten verfügt und Service Requests auch im Sinne von Bestellungen oder Beschaffungen entgegennehmen kann, ist der Eintrittspunkt in den Prozess. Wie vorgängig ausgeführt, kann die Qualität der Bearbeitung massiv erhöht werden, wenn der Anwender seine Anfrage katalogbasiert in einem Portal für den Service Desk erfasst.
Innerhalb des Service Desk kann zur Bearbeitung ein dediziertes Team eingesetzt werden, das sich der Service Requests annimmt. Mit einem ITSM-Tool können die Service Requests bequem an die für die Erledigung zuständige Person weitergeleitet werden, elektronische Genehmigungen überprüft oder nachträglich eingeholt werden und jederzeit der Umsetzungsstand jedes Service Request nachvollzogen werden.

Materialwirtschaft (Lager und Beschaffung)

Nach der Dokumentation der Anfrage kommt diese an eine legitimierte Stelle. «Materialwesen», «Bestellteam», «Beschaffung» sind hier häufig anzutreffende Begriffe, welche unter dem Begriff «Materialwirtschaft» oder englisch unter Supply Chain Management zusammengefasst werden. ITIL^® behandelt dieses Themengebiet nur am Rande und geht von der Prämisse aus, dass alle für Produkte und Services benötigten Configuration Items (CI) in genügender Menge an Lager sind (Availability Management) und von der IT zeitgerecht beschafft werden.
ITIL^® wird in diesem Punkt der Praxis jedoch nicht gerecht. Fragt ein Anwender z. B. ein IT-Fachbuch oder ein spezifisches Produkt nach, welches nicht im Katalog zu finden ist, so wird ihm dieses in den meisten Fällen bei vorhandenem Budget beschafft. Auch hier ist wichtig, dass die Beschaffung über den Request-Fulfilment-Prozess läuft. Aus diesen Ausführungen lassen sich bereits etliche Aufgaben der Materialwirtschaft ableiten:

• Kontierung/Vorerfassung
• Lieferantenmanagement (-auswahl)
• Bestellung
• Wareneingangskontrolle
• Lagerbewirtschaftung
• Kreditorenmanagement

Configuration Management Database (CMDB)

Sie kennen vielleicht das «Badewannen-Theorem» aus der Finanzwirtschaft? Wenn Sie wissen wollen, wie viele Liter Wasser in einer Badewanne zu Beginn und am Ende einer Periode sind, kann man entweder die Veränderung des Pegelstandes messen oder man misst, wie viele Liter Wasser ein- und ausgelassen wurden (Bestandsveränderung vs. Zu- und Abfluss). Beide Methoden sind sinngemäss anwendbar, will man die Veränderung der Bilanz oder
der Erfolgsrechnung nachvollziehen.
Nun, mit der CMDB verhält es sich ähnlich. Man kann in periodischen Abständen eine Inventur durchführen oder Inventory Tools einsetzen, die einem die aktuell sichtbaren Configuration Items (CI) im Netzwerk zurückmeldet; hier kann allerdings eine beachtliche Fehlerquote auftreten. Dazu kommt, dass jede Zählung nur eine Momentaufnahme widerspiegelt.
Will man die Bewegungen und den Gesamtzustand der CMDB zu jedem beliebigen Zeitpunkt eruieren können, so ist der Schlüssel zum Erfolg das Request Fulfilment, eng gekoppelt mit dem Configuration Management! Egal, ob via einer Beschaffung eine neue Komponente ins System kommt, der PC eines Anwenders ausgetauscht wird oder ein Anwender in ein anderes Büro umzieht: jedesmal müssen die betroffenen CI ergänzt respektive angepasst werden. Jede Veränderung entspricht einem Change und hat einen Einfluss auf die CMDB!