Information Technology Reference
In-Depth Information
Praxistipp:
Achten Sie bei persönlichen Zielvereinbarungen darauf, dass die vereinbarten
Ziele sich aus den IT-Zielen ableiten, nur so wird ein echter Beitrag gemessen.
Achten Sie zudem auf die interpretationsfreie Messbarkeit dieser Ziele, um
Diferenzen bei der Errechnung des Zielerreichungsgrades zu vermeiden.
Solche Diskrepanzen können schnell demotivierend wirken und so den Nutzen der
Zielvereinbarungen ins Gegenteil verkehren. Persönliche Ziele sollten zudem ein-
fach, transparent und nachvollziehbar gestaltet werden und sie sollten durchaus
ambitioniert, aber realistisch sein. Ziele, die nie erreicht werden können, haben
langfristig keinerlei positive Auswirkungen.
5.1.3■IT-Kennzahlen gestalten
Kennzahlen entwickeln
Die Gestaltung adäquater Kennzahlen für das IT-Service Management ist eine große Heraus-
forderung für den IT-Service Provider und gehört zu den wohl am häuigsten unterschätzten
Aktivitäten in diesem Umfeld. Der Grund dafür liegt auf der Hand: Kennzahlen müssen
sich auf ein Ziel bzw. einen CSF (vgl. Abbildung 5.1) beziehen, der durch sie gemessen
werden soll. Sie lassen sich allerdings nicht einfach mathematisch ableiten, was u. a. darin
begründet liegt, dass Ziele bzw. CSF qualitativ, nicht quantitativ formuliert sind. Es gilt
also, messbare Faktoren zu identiizieren, mit denen die Erreichung eines CSF nachgewie-
sen werden kann, und daraus die jeweilige Kennzahl zu konstruieren. Je nach Art des zu
messenden Objektes kann diese Konstruktion unterschiedlich komplex sein. Kennzahlen für
das Service Reporting werden entsprechend der in den SLA vereinbarten Messgrößen, wie
z. B. Verfügbarkeit oder Antwortzeiten, ermittelt. Soll die Qualität eines Prozesses gemes-
sen werden, so muss zunächst exakt formuliert werden, was durch diesen Prozess erreicht
werden soll. Die Kennzahlen müssen dann so gewählt werden, dass sie tatsächlich durch
den gemessenen Prozess beeinlusst werden. Auch der mögliche Einluss anderer Prozesse
spielt hier eine Rolle.
Soll zum Beispiel die Qualität des Problem-Management-Prozesses gemessen werden, so
ist eine beliebte Kennzahl dafür die Dauer bis zur Problemlösung. Aber wird hier wirklich
nur der Problem-Management-Prozess gemessen? Was ist mit dem Change Management,
das die Lösung bewerten und freigeben muss? Was ist mit dem Release- und Deployment
Management, das die Implementierung vornimmt? Es kommt also darauf an, wo die Mess-
punkte für eine Kennzahl gesetzt werden. Im genannten Beispiel wäre es sinnvoller, die
Zeit zwischen Problemidentiizierung und RFC zu messen statt der Zeit bis zur Schließung
des Problemtickets (nach der Implementierung). Zumindest dann, wenn ausschließlich
die Qualität des Problem Management gemessen werden soll. Natürlich hat die andere
Variante auch einen Nutzen: Sie misst die Zeit, bis ein Problem wirklich beseitigt ist, kann
also auch sehr nützlich sein, wenn man sich bewusst ist, dass mehrere Prozesse gemessen
werden. Die Gestaltung von Prozesskennzahlen hängt also stark von der jeweiligen Zielset-
zung ab.
