ITIL wird als Ziel definiert - nicht das, was man eigentlich erreichen sollte

ITIL – Begrabt nicht die Botschaft!

ITIL wird gerade in letzter Zeit stark kritisiert. Es gibt viel zu viele misslungene Service Management Implementationen, welche auf Basis der Good Practice Empfehlungen von ITIL aufgebaut wurden. Beispielsweise sind gerade mal 5% der CMDB-Umsetzungen ihren Namen wert. Selten gibt es gut funktionierende Problem Management Prozesse – und noch seltener gibt es Organisationen, welche ihren Change Management Prozess so umgesetzt haben, wie er im ITIL-Buch beschrieben wird. Eine viel zu hohe Fehlerrate für einen Good Practice Leitfaden.

Und auch im deutschen Sprachraum tun sich derzeit viele sehr schwer mit ITIL. Gerade die bücherschleppenden, von Tür-zu-Tür pilgernden Berater, die Alles-out-of-the-box Verkäufer und noch mehr die selbsternannten Service-Analysten welche ihre eigene Lehre verbreiten wollen, weisen die Schuld der schlechten Erfahrungen in der Umsetzung gerne den ITIL-Büchern zu. Zugegeben, die Bücher sind keine Garantie-Formel und erst recht kein Kochbuchrezept. Den Weg zum Gipfel müssen alle selber gehen.

Wir werden ITIL installieren - das wird doch wohl nicht so schwierig sein

Wir werden ITIL installieren – das wird doch wohl nicht so schwierig sein

Ja, wenn Service Management Implementationen misslingen, dann ist das mit Bestimmtheit irgendjemandes Schuld:

  • Berater, welche bloss Theorie predigen und nichts wirklich überführen
  • Verkäufer, welche zu viel verkaufen oder Prozesse out-of-the-box versprechen
  • Das Management, welches unrealistische Ziele setzt (z.bsp. alle ITIL V3 Prozesse in 9 Monaten, oder die finanziellen Mittel nicht sprechen, oder den Support verweigern)
  • Die Arbeit wird an Lieferanten vergeben, welche auf Basis der produzierten Papiere oder irgendwelcher erreichter Projektmeilensteine gemessen werden
  • Die Einkaufs-Spezialisten, welche gemachte Erfahrungen ignorieren und diese bei der Vergabe von Aufträgen nicht berücksichtigen
  • Die Mitarbeiter-Aspekte wie Einstellung, Verhalten und Kultur werden ignoriert und dadurch nichts verändert

ITIL ist ein Leitfaden, eine Empfehlung – keine Norm. Ein englisches Sprichwort besagt: „Guidance is for the wise, Rules for the foolish”.

Schuld ist also nicht die Methode, welche ITIL empfiehlt. Vielmehr sind es die übereifrigen, pingeligen, aufdringlichen, fehlgeleiteten, geschwollenen, dogmatischen, theoretischen, abgehobenen (…) Menschen, die die Fehler verursachen.

Ein Beispiel solcher dogmatischen Diskussionen sind im folgenden Xing-Thread nachzulesen, welche nach der Publikation eines simplen ITIL-Glossars entstanden sind.

ITIL wird als Ziel definiert - nicht das, was man eigentlich erreichen sollte

ITIL wird als Ziel definiert – nicht das, was man eigentlich erreichen sollte

Gründe dazu gibt es viele. Sicherlich hat die ITIL-Industrie selbst dazu beigetragen. Gerade die ITIL-Zertifizierungsprogramme helfen dem Einzelnen zwar, die richtige Antwort auf dem Prüfungsbogen anzukreuzen – aber selten Fragestellungen aus der Praxis zu beantworten. Darauf habe ich in einem meiner früheren Posts bereits hingewiesen (ITIL experimentell erlernen – spielerisch, dafür nachhaltig).

Service Management ist komplex. Das Business ist in den letzten 10 Jahren auch komplexer geworden. Es gibt nicht die eine einzige Lösung, welche für alle passt. Service Management muss adaptiert werden – und ITIL ist dabei ein Leitfaden, wie das gemacht werden kann. „Adapt and adopt“ ist die Devise. Und ITIL ist nicht in Stein gemeisselt. Es ist jeder aufgerufen, Verbesserungen einzubringen. Gerade der letzte Update Edition 2011 ist aus Feedbacks der Öffentlichkeit entstanden.

IT denkt, man muss das Business nicht verstehen

IT denkt, man muss das Business nicht verstehen

Bei der Umsetzung von Service Management muss das Business im Fokus sein. Wer ITIL versucht zu implementieren, ohne die damit zu lösenden Businessprobleme zu definieren, wird mit Garantie scheitern. ITIL beschreibt wie man designt, betreibt, ausführt, sich verhält, misst und wie man Verantwortlichkeiten zuweist. ITIL ist ein prozessorientiertes Framework – aber es ist selber kein fertiges Prozessmodell. Es ist auch kein Organisationsmodell. Es ist eine Sammlung an Good-Practice Empfehlungen, welche bei der Umsetzung zu berücksichtigen sind. Mehr nicht – aber auch nicht weniger.

Also begrabt nicht die Botschaft von ITIL – schiesst eher auf die unbeholfenen Boten.

 


 

Tags:
9 Comments
  • Peter Bergmann

    4. March 2012 at 16:16

    Sicher, die von Ihnen angesprochenen Ursachen finden sich auch in meinem erlebten Umfeld immer wieder. Aber nicht nur, denn so einfach strukturiert ist die Welt dann auch nicht.
    Klar, die „ITIL-Industrie“ hat jede Mende Leute angelockt, die schnell zertifiziert durch die Gegend laufen und schlicht Unfug produzieren. Das trifft aber auf beide Seiten der (Projekt)-Medaille zu: denn was in den Unternehmen Projekt- bzw. Linienverantwortung in der IT hat, ist oft unzumutbar.
    Kernübel ist nach meiner Erfahrung, dass IT-Organisationen organisatorisch als nicht mehr zu steuernder Tanker durch die wilde See von Veränderungen nicht zu steuern sind.
    Insbesondere hebt sich die Lehmschicht hervor, organisatorische Einflüsse durch Projektergebnisse zu verhindern. Und immer seltener lassen sich IT-Leiter von Service Management Strukturen beeindrucken. Wer kennt einen davon, der den IT-strategischen Wert einer gut geführten CMDB kennt und davon profitieren will – ich nicht.
    Das ITIL-Framework hat aber (trotz des Best-/Good Practice Amsatzes) seine Schwächen und Lücken. Kritik an den Akteuren ergibt eigentlich wenig Sinn. Denn nicht die geforderten und propagierten Modifikationen sind Schuld an den unendlich vielen misslungenen Projekten.
    Gerade in Deutschland führt eine Konsens-Diskussions-(Un)-Kultur zu Projektergebnissen, deren Wert als äußerst fragwürdig angesehen werden müssen. Und immer muss hinterfragt werden, warum Menschen in Projektteams sich damit abgeben, unprofessionelle Arbeit abzuliefern. Aber kaum jemand stört sich an weiterhin unautorisierten Changes, an ein nicht funktionierendes Problem Management und an SLAs, die maximal pro forma formuliert werden.
    Woran liegts?
    – an den ITSM-Systemen? Mitnichten.
    – an den externen Beratern? Oft, zu oft.
    – am Projektauftrag? Ja, selten ausformuliert.
    – an den Stakeholdern? Häufig, kaum mit Rückhalt.
    – am Projektteam? Ja, wer Gurken produziert, gehört in den Biomüll.
    – an den Prozessen? Eher nicht, Kästchen kann nahezu jeder aneinanderreihen.
    – an den Prozessteilnehmern? Nicht direkt, denn ohne Mandant kein sauberer Prozess.
    – an den Linienverantwortlichen? Meistens.
    – am Framework? Bedingt, Lücken müssen geschlossen werden.

    Es gibt als viel zu tun. Ein Gütesiegel für Werkzeuge gibts schon, für externe Berater muss dringend eines her.

    Niemand sollte ein Projekt angehen, wenn das Mandat, das Ziel schwammig oder überhaupt nicht formuliert ist. Jedes Projekt muss abgebrochen werden, wenn das Ergebnis mit dem Ziel absehbar nichts mehr zu tun haben.

    Nach dem Projekt müssen starke Persönlichkeiten in die (Prozess)-Rollen rein. Linienverantwortliche haben Fachmandate an die Rollenverantwortlichen abzugeben und sich nicht permanent einzumischen.

    Streiten wir dafür, denn in vielen Unternehmen sieht es in der IT, trotz (oder wegen) vieler ITSM-Investitionen übel aus.

    Projektgrüße aus München,
    Peter Bergmann

  • Martin Andenmatten

    4. March 2012 at 16:46

    Ich bin voll auf Ihrer Linie, Herr Bergmann. Die notwendigen Strukturveränderungen sind viel zu wichtig, als dass man einfach darüber hinweg schauen kann. Und trotzdem sind hier Menschen am Werk. Rom wurde auch nicht an einem Tag erbaut. Es braucht der erste Schritt – und es braucht die selbst gemachten Erfahrungen, auch die negativen.
    Aber es braucht ein Management mit visionärem Blick fürs Ganze. Und man braucht keine Berater, welche das Blaue vom Himmel verkünden. Welche Rolle die IT künftig in Unternehmen auch immer einnimmt.
    Das ITIL als Framework hat seine Schwächen, zweifelsohne. Aber gerade weil es nicht wasserdicht und nicht vollkommen ist, hat es einen Riesenvorteil gegenüber wissenschaftlichen Modellen: durch die Einfachheit in den Basis-Prinzipien sind werden sie von den meisten Leuten verstanden und sind nachvollziehbar. Es findet der Dialog statt, welcher wichtig ist zum Verständnis. Anstelle nach Fehlern zu suchen, sollte man sich mehr damit auseinandersetzen, wie es für die eigene Organisation angewendet werden kann. Hier geht es nicht um richtig oder falsch.
    Ich bin skeptisch mit Gütesiegeln – speziell für Berater. Ein Berater macht den Erfolg nicht aus – und was an einem Ort funktioniert hat, ist nicht der Beweis, dass es immer funktionieren wird. Ein Berater, der von sich behauptet, alles zu kennen und zu können ist mir von Anfang an suspekt. Ich bin schon über 25 Jahre in der IT und habe etliche Service Management Implementierungen begleitet und unterstützt. Aber jede Organisation und jedes Projekt ist für mich heute noch einzigartig und mit frischen Learnings verbunden. Die Bereitschaft, dazu zu lernen und gemeinsam mit dem Kunden für ihn eine optimale Lösung zu finden, ist das zentrale. Und manchmal geht der Weg über sieben Brücken bis zum Gipfel – auch wenn man als Berater todsichere Abkürzungen kennt. Der Kunde muss den Weg selber gehen – sonst wird er nie ankommen.
    Ja, es gibt viel zu tun. Packen wir’s an.

  • Tom Peruzzi

    4. March 2012 at 18:22

    vielen Dank, spannender Artikel, die Gründe sind vielschichtig und jeder hat sein Scherflein beigetragen, egal ob jetzt Cloud, ITIL, SOA oder sonst irgendeines der IT Buzzwörter der früheren Vergangenheit, erst reden ein paar, dann schreibt die Presse, dann will jeder irgendwie mitspielen, dann das Tal der Tränen und irgendwann sollte man es einfach tun da es zum Business-as-usual wurde. Bei Prozessen ist das halt so eine Sache. Transparenz schön und gut, aber nicht bei mir, übergreifendes Abteilungsdenken, ROIs < 1 Jahr und das auch bei ITSM Einführungsprojekten und vieles mehr erlauben selten, dass man so herangehen sollte wie man wollte, frei von Business-Zwängen sind wir ja ganz selten. Interessanterweise – das hat zumindest bei mir geholfen – wurde es leichter, als ich anstatt über ITIL nur mehr über ITSM gesprochen habe, genauso wie ISMS mehr als BSI oder ISO27k sein kann, es erlaubt einfach wieder aus einer anderen Fülle zu greifen, die "ich mus jetzt ITIL machen weil die anderen machen es auch" Zwänge lasst man hinter sich und man kann sich sehr oft wieder endlich um das kümmern, um was es geht. Wie entsteht ein Service in der IT, wie bekomme ich ihn live, wie pflege ich ihn und wie kommuniziere und eskaliere ich mit dem Kunden, oder hätte ich jetzt doch lieber etliche Prozesse runterschreiben sollen? 🙂

  • Martin Andenmatten

    4. March 2012 at 19:10

    Danke Herr Peruzzi, Pragmatismus ist sicher ein guter Begleiter. Weniger ist oft mehr – da bin ich ganz bei Ihnen. Nur soll man das Kind nicht mit dem Bade ausschütten. Es braucht Klarheit bezüglich Zuständigkeit und Leistungserwartung. Gewisse Definitionen müssen auch mal hingeschrieben werden, damit es für alle klar wird. Aber ja, es muss dem Zweck dienen – nicht der Dokumentation.

  • Philipp Keller

    14. March 2012 at 20:56

    Guten Tag Herr Andenmatten

    Ich habe gerade heute bei Ihnen im Glenfis meinen ITIL Foundation Kurs beendet. Hat mir sehr gefallen.

    Sie schreiben:
    > Beispielsweise sind gerade mal 5% der CMDB-Umsetzungen ihren Namen wert.

    Können Sie mir ein paar Empfehlungen geben?

    Grüsse
    Philipp Keller

  • Martin Andenmatten

    15. March 2012 at 06:17

    Hallo Herr Keller,

    meine Aussage bezieht sich weniger auf das Tooling, sondern mehr auf die Implementation und die Integration mit den anderen Service Management Prozessen. Die meisten Implementationen entpuppen sich als mehr oder weniger gut kontrollierte Inventar-Systeme – eher Datenmüllhalden mit ungewissem Status bezüglich Aktualität und Korrektheit.

    CMDB-Implementationen bedingen eine starke Integration mit dem Change Management Prozess. Change Planung und Change History sind wesentliche Kontroll-Informationen, um Transparenz und Rechenschaft der eingesetzten Ressourcen zu erhalten.
    Bei den meisten Implementationen konzentriert man sich mehr um die Datenbeschaffung via Netzscanner. Beziehungen und Abhängigkeiten zwischen den Komponenten sind in der Regel nicht sichtbar – von einer Sicht, welche Komponenten welchen Service unterstützen ganz zu schweigen.

    So werden solche CMDBs überteuerte Datenmüllhalden – mit viel Geld und teuren Lizenzen aufgebaut. Aber nicht einmal die eigenen System-Spezialisten trauen im Alltag dem Inhalt und schauen lieber selber auf dem IT-System nach, was Sache ist.

    Wer sich eine CMDB beschaffen will, muss sich über die Konsequenzen im Betrieb ganz klar bewusst sein: Keine einzige Änderung an Komponenten ohne ein kontrollierter Change! Wer sich dazu nicht durchringen und das durchzusetzen bereit ist, spart sich das Geld lieber und tut etwas anderes, gescheiteres.

  • Peter Bergmann

    4. April 2012 at 07:12

    Ist ist ja das Traurige im ITSM-Leben: sehr selten, vielzu wenig, wird genau jene Integration erkannt und zum Gegenstand von Projektinhalten.
    „Bring mir ein Tool und schon haben wir ein ‚geiles‘ Service Management.“
    Schwadronierte doch unlängst ein CIO eines nicht so kleinen Unternehmens auf einem IT-Management Kongress über seine tolle CMDB – ja, er stellte eine Datenbank vor.
    Q&A: ich beglückwünschte ihn in meiner Frage zum Projekterfolg und erbat in meiner Frage einige Aussagen zu nicht autorisierten Changes und zum Change Management insgesamt in seinem Umfeld. Die Antwort: pures Stottern.
    Professionalität im IT (Service) Management verlangt nach fähigen Machern und Gestaltern, nach einer Unternehmenskultur, die Entwicklung in der IT zulässt und externe Impulsgeber, die mit ihren Erfahrungen (Wissen ist intern oft vorhanden) einen Auftraggeber WIRKLICH weiterhelfen und nicht nur kosten.

  • Chris

    6. April 2015 at 16:37

    Hallo,

    Interessanter Artikel. Ich stimme dem zu, ITIL könnte helfen, IT Abteilungen zu organisieren, oder auch nicht. Die Umsetzung scheint derzeit sehr dürftig zu sein. Besonders in der BRD, früher schon anfällig für Bürokratie… Mehr braucht es in dem Fall nicht, meiner Meinung nach. Die Landschaft scheint sich dahin gewandelt zu haben, dass man das alte System sowie das „neue“ System behält. Das Alte dabei als Backup falls das Neue nicht klappt. Nur wäre das u.a. schon fast eine Garantie fürs Scheitern.

    Prognose/Vermutung: es werden mehr Firmen mit „außen hui innen pfui“ existieren.

    Meine Frage: wie haben sich IT Abteilungen vorher organisiert/überlebt? Konnte man sie deshalb so „leicht“ beeinflussen, sich zu ändern, weil sie i d Struktur schwach waren, weil etwas wie ITIL gefehlt hat?

    Ist es erlaubt, ITIL zu kritisieren… oder muss man es machen, wenn man etwas auf sich hält, oder muss man es machen, um „cool“ zu sein und bei den coolen Leuten „rumhängen“ zu dürfen?

  • Martin Andenmatten

    8. April 2015 at 06:16

    Hallo Chris,

    es wird immer gerne mit „früher“ verglichen – da ging es ja auch. Stimmt auch. Es geht auch heute irgendwie ohne. Aber vielleicht war früher etwas weniger Komplexität im Spiel -und die Abhängigkeit und Bedeutung der IT für das Gelingen im Business ist etwas anspruchsvoller geworden.

    ITIL darf und soll man hinterfragen und kritisieren. Es ist kein Wundermittel, sondern die Zusammenstellung von Erfahrungen aus der Sicht des professionellen Umgangs innerhalb einer IT Organisation.

    Freundliche Grüsse
    –Maratin Andenmatten

Post a Comment