AnyWeb AG

Transkript

1

2 ITSM Practice Circle ΩΣΠβ Metriken für IT Service Management Mike Portworsnick Zürich,

3 Agenda Warum Kennzahlen messen und berichten? Kennzahlen für das Management Ausgangslage Warum Metriken keine SLAs sind Schlechte Metriken Metriken entwickeln und implementieren Beispiel: Configuration Management Metriken einsetzen Metriken Design Berechnen und berichten von Metriken Risiken Die nächsten Schritte

4 Ziel der Präsentation ist Den Unterschied zwischen Metriken, KPIs und SLA sowie deren Zusammenspiel zu vermitteln Zu verstehen, warum und wie die IT Service Management Prozesse überwacht und gesteuert werden Aufzuzeigen, wo und wie Metriken zur Prozesskontrolle und Steuerung eingesetzt werden müssen Grundlagen zu Entwicklung von Metriken zu vermitteln

5 Warum Kennzahlen messen und berichten? Um die IT an Geschäftsziele ausrichten zu können ISO Zertifizierung Continuous Service Improvement Process Den IT Betrieb und die gesamte IT Service Organisation ständig zu verbessern

6 Warum Kennzahlen messen und berichten? ITIL definiert Service Delivery um dem Kunden einen Service zu liefern die Qualität wird über KPIs in einem SLA überwacht ITIL definiert aber auch den Betrieb der einzelnen Prozesse, und diese werden über Metriken überwacht. Die Ziele der Prozesse sind CSF, um SLAs einhalten zu können. Fazit: Mit KPIs wird das Ziel überwacht und mit Metriken der Weg.

7 Kennzahlen als Management Information Es gibt drei Arten von Kennzahlen aus der IT 1. Direktes berichten von Kennzahlen aus der IT heraus 1. SAP Bericht für Verkaufszahlen 2. Kennzahlen für Service Delivery von Diensten aus dem Service Katalog 1. KPIs aus SLAs um CSF zu überwachen 3. IT selbst ist ein wichtiger Geschäftsprozess. Messen, kontrollieren und steuern von IT Prozessen ist unabdingbar für den Geschäftserfolg!

8 Metriken als Management Kontrolle Wenn bei der Arbeit etwas gemessen wird, dann wird sich das Verhalten der gemessenen Person oder das des Teams ändern. insbesondere wenn diese Person oder das Team für diese Messung verantwortlich ist Menschen sind sehr kreativ, wenn es darum geht, genau das zu machen was von ihnen gefordert und (durch Metriken) überwacht wird Erfüllt der Mitarbeiter seine Metrik Ziele, obwohl sein Verhalten den Geschäftszielen nicht dient, dann sind die Metriken UND NICHT DER MITARBEITER das Problem!

9 Ausgangslage - Metriken in ITSM Metriken, Kennzahlen, KPIs, SLA {Problem} Zuviel, zuwenig und falsch gemessen {Auswirkung} Nicht klar, warum gemessen wird {Ursache} So ist es besser {Lösung} Das sollten die nächsten Schritte sein {Aktionen}

10 Ausgangslage - Metriken, KPIs, SLA Alle reden heute von Metriken KPIs SLA Alle wollen Tools, die alles messen können und Berichte in allen möglichen Variationen erstellen Verantwortliche sollen aufgrund von diesen Berichten Entscheidungen treffen, wissen aber nicht welche Unternehmen finden es schwierig Metriken richtig einzusetzen

11 Auswirkungen - Zuviel, zuwenig und falsch gemessen Es werden Tools angeschafft, die alles mögliche messen können Es werden ganze Abteilungen damit beschäftigt, Berichte zu erstellen Die richtigen Zahlen sind doch nicht dabei um eine Entscheidung treffen zu können Menschen passen ihr Verhalten an die Metriken an, an denen sie gemessen werden Dieses Verhalten ist selten im wirklichen Sinne des Unternehmens

12 Ursache - Nicht klar, warum gemessen wird Kaum einer kann die Frage beantworten, warum etwas gemessen wird und welche Entscheidung aufgrund einer Metrik getroffen wird Es herrscht die Meinung vor, Metriken müssen von Technikern entwickelt werden. Es ist unklar, wer eigentlich Kunde ist

13 Warum Metriken keine SLAs sind Der Service Level Manager verhandelt ein oder mehrere SLA zwischen dem Kunden und der IT. Diese SLAs halten fest, welche Service Qualität IT liefern wird. Der SLM benutzt die SLAs um OLA und UC zu definieren Die CSF für die IT werden vom OLA abgeleitet Für Service Delivery zum Kunden sind die CSF die wichtigen Massstäbe Aus diesen CSF werden dann KPIs abgeleitet, die aufzeigen ob ein CSF erfüllt wurde

14 Warum Metriken keine SLAs sind Kundenanforderung SLA OLA/UC CSF KPI Monatlicher Report

15 Warum Metriken keine SLAs sind KPIs sind für SLA Überwachung CSF bestimmen die KPIs Metriken sind für die Prozess-Überwachung und Steuerung Für die unterschiedlichen Prozesse sollten ähnliche Metriken oder die gleiche Anzahl von Metriken entwickelt werden, um die Prozesse besser vergleichen zu können

16 Schlechte Metriken Kann ich den Call schliessen? Sie können ja einen neuen Call eröffnen, wenn es immer noch nicht funktioniert Mitarbeiter in diesem SD werden daran gemessen, wie schnell sie ihre calls schliessen Der Preis dafür: Kundenzufriedenheit Warum ist es so wichtig die calls so schnell zu schliessen? Weil der Kunde dann zufrieden ist, da der Incident schneller behoben wurde? -> wohl kaum, wenn dafür ein neuer call aufgemacht wird Das SD kann mehr Calls mit gleichbleibendem Headcount bearbeitetn? -> wohl auch nicht, da viele calls einfach den gleichen Incident betreffen

17 Schlechte Metriken Hat der Prozess Verantwortliche dieser Metrik überhaupt zugestimmt? Wurde überhaupt die anderen Interessengeruppen z.b. die Anwender, der Kunde gefragt, ob sie den call zu kurz wie möglich halten wollen? Wohl kaum, da es den Kunden eigentlich nicht interessiert, ob ein call open oder closed ist. Der Kunde möchte nur den Incident oder Service Request gelöst haben.

18 Metriken implementieren Sämtliche IT Mitarbeiter vom Management bis zum Mitarbeiter müssen verstehen was Prozess Metriken, KPIs und SLAs sind. Metriken können erst entwickelt und eingeführt werden, wenn es einen Prozess gibt, der damit überwacht und gesteuert werden soll. Ein Prozess sollte von Anfang so entwickelt werden, damit an den richtigen Stellen die richtigen Prozess Zustände mit einer Messung überwacht werden können.

19 Metriken implementieren Menschen die mit einem Prozess arbeiten, müssen verstehen welche Einflussmöglichkeiten sie haben, um die Metrik zu verbessern und sie sollten eine Motivation haben, diese Verbesserung anzustreben. Wenn du nicht weißt, wohin du gehen möchtest, dann kannst du auch nicht viel tun, um dorthin zu kommen Es ist wichtig ein Management System wie in ISO beschrieben zu etablieren, welche Service Management Richtlinien, Ziele und Pläne definiert

20 Metriken implementieren Bei der Entwicklung der Metriken muss darauf geachtet werden, dass diese an die entsprechenden Prozess Ziele ausgerichtet werden Dies ist absolut wichtig, nur so entstehen auch brauchbare und nicht nur messbare Metriken

21 Beispiel: Configuration Management Prozess Ziele: Die Pflege eines gesicherten Datenbestandes über Betriebsmittel und IT-Services der Organisation Die Beschaffung und Bereitstellung genauer Informationen und Dokumentationen über diese Betriebsmittel und IT-Services zur Unterstützung aller anderen Service Management Prozesse Hiervon kann ein einziges Metrik Ziel abgeleitet werden Informationen über IT Betriebsmittel und deren Beziehungen - entsprechend der Geschäftsbedürfnisse und vereinbarten Richtlinien - sorgfältig und wirksam identifizieren und verwalten

22 Metriken - Configuration Management Kundenzufriedenheit Kundenumfrage / unmittelbar nachdem etwas getan wurde / wöchentliches meeting Anzahl der unbenutzten Lizenzen Anzahl abgelehnter RFCs aufgrund fehlerhafter CMDB Einträge Anzahl nicht genehmigter Konfigurationen

23 Metriken - Configuration Management (cont.) Anzahl Incidents, verursacht durch Changes, die aufgrund falsch dokumentierter CIs gescheitert sind Anzahl SLA Verletzung verursacht durch Fehler in der CMDB Anzahl RFCs bei denen die dazugehörigen CIs nicht aktualisiert wurden Anteil (%) fehlerhafter / ungenauer CIs

24 Metriken einsetzen - Timing Timing Wie oft messe ich etwas Bei den meisten Metriken wird die Zeit zwischen zwei Zuständen gemessen Operational kurzer Zeitraum Tactical mittlerer Zeitraum Strategic langer Zeitraum

25 Metriken einsetzen - Messen Prozessschema Serie von Prozesszuständen Prozesszustand Was ist wichtig um das Prozessziel innerhalb des SLA zu erreichen

26 Metriken einsetzen - Kontrollieren Prozesszustände Einige werden von anderen Abteilungen kontrolliert Mehrere Messungen Um gezielt verbessern zu können

27 Metriken einsetzen - Steuern Um einen Prozess steuern zu können, muss klar sein, wohin es gehen soll Benchmarking (Performance Ziele) einführen und Abweichung ermitteln Plan erstellen, wie diese Abweichung eliminiert werden kann So kann in Richtung Ziel gesteuert werden

28 Metriken Design Tools können viele Metriken schon out-of-thebox messen. Das ist einfach Nur das eine Metrik einfach gemessen werden kann, ist kein guter Grund dies auch zu tun. Sehr wahrscheinlich wird nur etwas gemessen, was nicht verbessert werden kann oder soll Es muss entschieden werden, was das Beste für das Unternehmen ist, wenn Metriken eingeführt werden Am besten werden eigene Metriken entwickelt und dann geschaut, wie die Metriken aus dem Tool angepasst werden können

29 Metriken Design SMART Prinzipien Specific Wird durch die Metrik ein bestimmter Prozess oder nur ein Teil eines Prozesses gemessen? Measurable Ist die Metrik überhaupt messbar? Achievable Ist der vorgegeben Wert der Metrik überhaupt erreichbar? Realistic Wird durch die Metrik etwas aus der Realität gemessen? Timely Erfolgt die Messung der Metrik zeitgerecht?

30 Metriken Design KISS Prinzipien Keep it Simple Stupid Metriken müssen richtig erklärt werden und auch wie eine Verbesserung erreicht werden kann Ansonsten ist die Tür offen für Widerstand Ernüchterung Und flüchtige Ausreden für die Nicht-Einhaltung

31 Metriken Design KISS Beispiel Die Durchschnittliche Anzahl Incidents pro Problem, welches mit einem Change Request in Verbindung gebracht wird. Sollten hier mehr Change Request für Probleme sein, die eine Menge Incidents verursachen? Oder sollten die Probleme unterteilt werden, damit weniger Incidents damit in Verbindung gebracht werden? Es ist einfach nicht klar, was hier wichtig ist und wie etwas verbessert werden kann

32 Metrik Design - Anforderungen Prozesse sollten so entwickelt werden, dass die geeigneten Zustände von Anfang an beinhaltet sind Wenn Änderungen am Prozess vorgenommen werden muss die Kommunikation und ggf Training sichergestellt sein. Es sollte keine catch-all Kategorie eingebaut sein Es werden viel öfter Kategorien anstatt die Zustände geändert Die richtige Benutzung von Kategorien und Zuständen muss überwacht und gesteuert werden

33 Metrik Design - Customer Relationship Modell Wer ist der Kundes eines Prozesses Welches Prozessziel ist für diesen Kunden wichtig? Mit welchen Metriken überwache ich dieses Prozessziel?

34 Metrik Design - Customer Relationship Diagram Ist eine Vereinfachung der komplexen Kunden Beziehungen, die jeder Prozess hat Ziel ist es den wichtigsten / direktesten Kunden eines Prozesses zu identifizieren Damit kann herausgefunden werden, wo Metriken für Kunden Zufriedenheit erhoben werden können Natürlich gibt es viele Interessengruppen / Kunden für einen Prozess Bei jedem Prozess muss eine Metrik für Kunden Zufriedenheit erhoben werden Das ist der ausschlaggebene Punkt für die Wirksamkeit eines Prozesses!

35 Customer Relationship Modell (Beispiel)

36 Metriken entwickeln und implementieren Alle Stakeholder mit einbeziehen Metriken müssen an Prozess Ziel ausgerichtet sein KISS SMART

37 Reporting - Metriken Tabelle Nur eine Metrik pro Prozess Durch Gewichtung priorisieren Gesamtwert = Σ Pn*Rn -> 23 von +36 bis -36 möglichen Punkten P= Prio R= Resultat Gesamtresultat unabhängig von Anzahl Metriken pro Prozess: 23/8 = 2.9 von max 4.5 Oder 2.9/4.5 = 64%

38 Reporting - Prozesse vergleichen Dieser Ansatz unterstützt die Weiterentwicklung von Prozessen und somit auch die der gesamten IT Service Organisation

39 Risiken Metriken zeigen Schwachstellen im Prozess auf Dies löst Bedenken bei Mitarbeitern aus, da Schwachstellen nun aufgedeckt werden Aber nochmal, damit soll der Prozess verbessert werden und kein Druck auf Mitarbeiter ausgeübt werden

40 Risiken Prozess Metriken zeigen Schwachstellen auf, dass sind jedoch Prozess Schwachstellen und keine auf Menschen bezogene Es ist viel besser Service Delivery durch Prozess Verbesserung zu erreichen anstatt durch Investment in mehr Mitarbeiter, Computer oder Tools

41 Die nächsten Schritte Committment, Awareness und Training Customer Relationship Modell entwickeln Metriken für Pilot Prozess zusammen mit Stakeholdern entwickeln Kommunikationsplan aufsetzen Unterstützung anfordern

42 Backup - Metriken Vorlage Ziel des Prozess beschreiben Einsatzauftrag / Leitbild für die Metriken definieren Prozess Verantwortlichen benennen Metrik Ziele beschreiben Metrik definieren: (dies für jede Metrik in diesem Prozess) Metrik benennen Beschreiben der Metrik Metrik spezifizieren Rechtfertigung der Metrik Zielgruppe Grenzen Gefahr Wert Ziel Wert Mögliche Werte

43 Backup - Beispiel Metriken Incident Management Percentage of Incidents resolved by 1st Line Support Average call time with no escalation Percentage of Incidents incorrectly asigned Average time to resolve Incidents Percentage of incidents incorrectly categorized Percentage of incidents reassigned Customer satisfaction Percentage of calls that are Service Requests Percentage of incidents solved rightly the first time Percentage of proactively solved incidents Percentage of time 1st line support bypassed Average Time for second level support to respond