Blogmeldung anzeigen

Best Practice nach ITIL oder das teure Kratzen an der Oberfläche

13:02:54 10.10.2015 gepostet von helmut.steigele@cascadeit.ch um 13:02:54 10.10.2015

Warnung an den Leser:

Die folgenden Zeilen können weh tun - und das ist gut so!

Vorher aber noch eine kleine Einführung. Im Rahmen eines Abklärungsgespräches mit einem mittelgrossen internen IT-Provider kamen folgende Projektziele zur Sprache:

 

  • Verbesserung der Incident- und Request-Prozesse wegen laufendem Anstieg des Betriebsbudgets
  • Nachdokumentation und Komplettierung der Servicemanagement-Prozesse nach ITIL
  • Neugestaltung der Lieferantenlandschaft
  •  

Nun kamen Fragen zum "Aufwärmen": Warum, wollen Sie dieses Projekt, warum die Neugestaltung der Lieferantenlandschaft und warum die Nachdokumentation.

Die Antwort kam prompt: Das Business verlangt immer mehr Leistung bei gleichbleibendem Budget! Und es gibt immer wieder zum Support und zur Servicequalität Beschwerden - das muss endlich abgestellt werden.

Die schicksalshafte Frage kam nun: Um die Prioritäten in der Reihenfolge korrekt zu setzen: Was muss denn Ihr Support eigentlich alles leisten, gibt es so was wie einen Service- bzw. im Detail gesehen einen Leistungskatalog (was leistet die interne IT, was leisten die Lieferanten) ?


Auch hier kam eine Antwort: Um den Servicekatalog müsse man sich nicht kümmern, es wäre wohl sinnvoller sich zuerst um die Incident- und Requestprozesse zu kümmern und im nächsten Schritt die Low Performer in der Lieferantenlandschaft auszuräumen, damit kann man die Kosten nachhaltiger in den Griff bekommen. 

Just an dieser Stelle (der umsatzorientierte Kaufmann schaltete sich in mir ein), verfiel ich in Schweigen und dachte mir folgendes:

  1. Der Grossteil eines negativen Outcomes bei einem Service entsteht durch:
    • Unkoordiniertem Ablauf im Leistungsfluss zwischen Serviceabnehmer - internen Leistungsträgern und Leistungsbeiträgen von Lieferanten
    • Dieses Ungleichgewicht entsteht in der Regel durch instabile Servicedesigns, welche in Betrieb genommen wurden
    • Die Instabilität liegt vor allem in der mangelnden Beschreibung, was innerhalb des Services wie von Support, Betrieb und Lieferanten geleistet werden soll
    • weil sich die meisten auf die technischen Topologien - aber nicht auf das konzentrieren, was mit dem Service wirklich getan wird.
    • dieses "Wie" lässt sich aber mit global dokumentierten Incident- und Request-Prozessen sicher nicht beschreiben
    • Kosten sparen kann man damit auch nicht....

Danach schaltete sich wieder mein Sprechwerkzeug wieder ein, nun mit einem Vorschlag:

  • Darf ich anhand des problemträchtigsten Service auch abklären, an welchen Schnittstellen zum Incident- und Request-Prozess Mehrkosten und Verzögerungen verursacht werden?
  •  

Die Einwilligung kam prompt. Nach 6 Wochen folgendes Ergebnis:

 

  • Die Endbenutzer des problemträchtigsten Service (Arbeitsplatzbewirtschaftung) beschwerten sich vor allem darüber, dass die am Arbeitsplatz bereitgestellte Software gar nicht auf Ihren Einsatzzweck abgestimmt war
  • Die Softwareupdates zum Arbeitsplatz erfolgten just am Beginn von Arbeitstagen 
  • Die Virenscanner und die Software blockieren sich permanent
  • Ein Nachbestellen von PCs dauere ewig lang, bis alles bewilligt sei.
  • Bis zum Lieferanten Anwendungslisten, Systemanforderungen und Qualitätskritieren übermittelt werden, dauert es ewig
  • Die Lieferanten selbst argumentieren immer mit dem selben Argument: Wir tun unser bestes, aber wir wissen nie wirklich genau was der Kunde will..
  • weitere Beispiele könnten hier noch folgen, die Liste war lang....

Kurz - die Rechte Hand wusste offensichtlich sehr oft nicht, was die linke im Detail tat. Unter anderem genau deswegen, weil das "was ist innerhalb des Service zu tun" nie wirklich genau beantwortet wurde. 

Keines dieser Probleme hätte unmittelbar mit einem der zitierten Lehrbuchvorschläge zu den schon zitierten ITIL-Prozessen gelöst werden können.

Hier nun der schmerzhafte Satz eines Mitarbeiters auf niedrigster Ebene (und er hatte Recht):

Da die Betriebskosten eines Service grossteils davon getrieben werden, was im Detail, wann und an welchem Ort geleistet wird, und hier das Wie oft den Unterschied zwischen niedrigen und hohen Kosten bringt, macht es wohl mehr Sinn sich zuerst um dieses Thema zu kümmern, als sich abstrakt und abgehoben davon um Prozesskosmetik nach best Practice zu kümmern  - aber das haben bis jetzt weder Berater, Lieferanten noch das Management wirklich gerafft!

Nun das Projekt ging weiter. 

  1. wurde der Projektfokus geändert (ein Leistungskatalog mit den Definitionen von Prozeduren innerhalb des Servicedesigns pro Service wurde als Lieferobjekt zusätzlich definiert)
  2. Danach wurden die Leistungen im einzelnen analysiert, um rauszufinden, wo welche Kosten verursacht wurden, bzw. durch Neugestaltung weniger Kosten anfielen
  3. Wurde geklärt, wie man mit strukturierten Informationsübergabemechanismen zum Lieferanten Leistung pro Leistung weitere Kosten senken konnte
  4. Wie die im Servicekatalog (inklusive der darin enthaltenen Leistungen pro Service) beschriebenen Dienste, durch die jeweiligen Servicemanagementprozesse gesteuert und gemanagt werden, und damit die Wirkung erfahren, die sich am Ende alle erhoffen 


Bemerkung am Rande: Lieferanten mussten nur wenige ausgemistet werden - und der kritische Mitarbeiter bemerkte am Ende:

Wir haben jetzt endlich unsere Hausaufgaben gemacht und ITIL hat uns nicht einmal dabei behindert...

BlinkList (http://www.blinklist.com) Blogmarks (http://www.blogmarks.net) del.icio.ous (http://del.icio.us) Digg (http://www.digg.com) Facebook (http://facebook.com) Folkd (http://www.folkd.com) Furl (http://www.furl.net) Google + (http://plus.google.com) Google Bookmarks (http://www.google.com/bookmarks/) Linkarena (http://www.linkarena.com) Mister Wong (http://www.mister-wong.de) Newsvine (http://www.newsvine.com) OneView (http://oneview.com) reddit (http://www.reddit.com/) Squidoo (http://www.squidoo.com) Stumble Upon (http://www.stumbleupon.com) Technorati (http://www.technorati.com) Twitter (http://twitter.com) Webnews (http://www.webnews.de) Yahoo My Web (http://myweb2.search.yahoo.com) Yigg (http://www.yigg.de) 
Bewertung
Aktuelle Bewertung BewertungBewertungBewertungBewertungBewertung
Durchschnittliche Bewertung Ø 7.60
Anzahl Bewertungen 5
Ihre Bewertung Bewertung abgeben: 1Bewertung abgeben: 2Bewertung abgeben: 3Bewertung abgeben: 4Bewertung abgeben: 5Bewertung abgeben: 6Bewertung abgeben: 7Bewertung abgeben: 8Bewertung abgeben: 9Bewertung abgeben: 10