In vielen Projekten ist eines der Ergebnisse, die vom Lieferanten als Artefakte bereitgestellt werden, das Servicehandbuch.

 

In vielen Fällen bekommt man in der Angebotsphase oder in der Initiierungsphase dann gesagt. „Wir machen ITIL und wir haben das bei uns etabliert. Auf dieser Grundlage erstellen wir das Servicehandbuch.“

Man könnte jetzt sagen, alles ist gut! Aber leider ist dem nicht so, mitnichten. Auf Grund des Zeitdrucks (man will ja schnell mit dem Projekt anfangen) oder eines nicht etablierten Projektteams beim Auftraggeber (das Projektteam des Auftraggebers ist noch nicht vollständig aufgestellt bzw. eingearbeitet), wird diese Aussage selten hinterfragt.

 

In vielen Projekten, die ich begleitet habe, ist das so passiert. Am Anfang sieht alles gut aus. Man erhält früh einen Entwurf eines Servicehandbuchs vorgelegt, in dem dessen Struktur definiert, aber wenig bis kein Inhalt enthalten ist. Die Struktur ist auch meistens an ITIL angelehnt und das folgende Inhaltsverzeichnis steht exemplarisch für viele Servicehandbuch-Entwürfe, die ich gesehen habe.

 

Vorwort und Einleitung

Referenzdokumente

Begriffsbestimmung

1. Abgrenzung

2. Zielsetzung

3. Prozesse und Leistungen

3.1. Service Strategy

3.1.1. Demand Management

3.1.2. Financial Management

3.2. Service Design

3.2.1. Service Level Management

3.2.2. Capacity Management

3.2.3. Availability Management

3.2.4. Information Security Management

3.2.5. Service Continuity

3.3. Service Transition

3.3.1. Change Management

3.3.2. Release Management

3.3.3. Configuration und Asset Management

3.4. Service Operation

3.4.1. Incident Management

3.4.2. Problem Management

3.4.3. Monitoring / Event Management

3.5. Service Improvement

3.5.1. Kontinuierlicher Verbesserungsprozess

3.5.2. Reporting                          

3.5.3. Qualitätssicherung, Auditierung und Besuchsrecht

3.6. Risikomanagement

 

Leider ist dann in den finalen Servicehandbüchern nur noch ein Teil der Kapitel enthalten, die im ursprünglichen Entwurf enthalten waren. In der Regel findet man folgende Themen ausgearbeitet: Service Level Management, Information Security Management, Change Management, Incident Management, Event Management und Reporting.

 

Aus operativer Sicht sieht das ausreichend aus, aber oft merkt man die fehlenden Prozessbeschreibungen dann, wenn es zu spät ist.

 

Aus Zeitdruck oder anderen Gründen werden diese Themen daraufhin im besten Fall in Mail-Notizen kurz beschrieben oder auf einen späteren Zeitpunkt verschoben. Folglichgeht man dann mit einem unvollständigen Servicehandbuch in den Betrieb.

 

Bei einer Anwendung war das Availability und Service Continuity Management in etwa so beschrieben: „Die Datenbank wird wöchentlich gesichert und kann im Bedarfsfall wieder eingespielt werden“. Nun ist die Datenbank im Betrieb gecrasht und es hat sich herausgestellt, dass nicht die Datenbank, sondern die virtuelle Maschine auf der die Applikation gelaufen ist, gesichert wurde. Zusätzlich ist die Datenbank über einen bestimmten Zeitraum vor dem Crash inkonsistent geworden. Das Wiederaufsetzen des Systems konnte daher nur nach einem längeren Systemausfall, mit großem Aufwand und einem Datenverlust durchgeführt werden. Hier hätte man sich eine Menge Probleme erspart, wenn es ein vernünftiges Availabilty Management gegeben hätte.

 

Bestehen Sie daher schon in der Entwurfsphase auf mehr Inhalt oder Beispielen, bzw. lassen Sie den Dienstleister hier nicht aus seiner Pflicht heraus, auch alle Prozesse ausreichend zu beschreiben. Lassen Sie sich hier auch nicht mit der Phrase „Wir haben die Prozesse an anderer Stelle beschrieben und müssen das nur noch für Sie dann anpassen“ abwimmeln. Kontrollieren Sie den Fortschritt des Servicehandbuchs schon während der Entwicklungsphase anhand von Zwischenversionen, da Sie zu diesem Zeitpunkt noch gut gegensteuern können Und auch eine gute Dokumentation bewahrt Sie nicht vor detaillierten Tests der beschriebenen Prozesse.

 

Februar 2018

Autor: Marcel Choc