Die Vergangenheit und Zukunft von IT Service Management

Lesezeit: 13 Minuten

(Originalartikel von Stuart Rance, übersetzt von Amelie Yong (Mai 2021)):

Sagen Sie es weiter:

Ich bin schon seit den 1970er Jahren im IT Service Management tätig und habe seitdem viele Veränderungen miterlebt. Hier ist meine Zusammenfassung, woher ITSM kommt und wohin es sich meiner Meinung nach entwickeln wird.

Ein rein technischer Fokus in den 1970ern

Mein erster Job in der IT war in den späten 1970ern. Ich habe in einer Support Rolle gearbeitet, in der ich kaputte Hardware repariert habe. Nach kurzer Zeit habe ich zu Jobs gewechselt, bei denen ich mich mit der Lösung von Incidents und Problems auf einem breiten Spektrum von Hardware und Software Produkten befasste. Wie andere auch, die in ähnlichen Bereichen in der IT gearbeitet haben, bin ich zu vielen Trainings und Kursen gegangen, wo ich über verschiedene Hardware und Software Produkte und wie man sie repariert gelernt habe, aber da waren keine Trainings bezüglich Prozessen, Services oder Kund:innenerfahrung. Wenn mich jemand fragte, wie ich meinen Lebensunterhalt verdiene, habe ich geantwortet: „Ich repariere Computer“, oder vielleicht „Ich löse Computerprobleme“. Damals hatte ich noch nie von ITSM gehört und ich habe auch keinesfalls darüber nachgedacht, Störungen von Ursachen zu unterscheiden.

ITIL in den 1990ern

Mitte der 1990er Jahre stieß ich auf ITIL (das führende Best Practice Framework für ITSM) und es war eine Offenbarung. Es war wie die Entdeckung einer Familie, von der ich nie wusste, dass ich sie hatte. Konzepte wie Availability Management, Service Continuity Management, Change Management und Problem Management beschrieben Aktivitäten, die ich bereits selbst entdeckt hatte. Jetzt hatte ich aber ein Framework von Ideen, das ich verwenden konnte, um mehr Konsistenz und Sorgfalt in meine Arbeitsweise zu bringen, UND ich hatte eine gemeinsame Sprache, die die Kommunikation mit meinen Kolleg:innen und Kund:innen vereinfachte. Ich besuchte ITIL Foundation und „ITIL Service Manager“ Trainingskurse und wurde schlussendlich ein ITIL Trainer. So konnte ich diese großartigen Ideen an andere Menschen weitergeben, um ihnen zu helfen, in ihren Karrieren erfolgreich zu sein.

Damals war ITIL größtenteils auf Prozesse fokussiert und lieferte das Framework für deren Erstellung. In Unternehmen, die ITIL verwendeten, hörten IT Support Teams auf, von Vorfall zu Vorfall, von Krise zu Krise zu stolpern und auf die Leute zu reagieren, die am lautesten schrien, anstatt auf diejenigen, die am meisten Hilfe brauchten. Stattdessen steckten sie ihre Energie in die Vereinbarung von Service Levels mit ihren Kund:innen. Dann sorgten sie dafür, dass diese Service Levels eingehalten wurden, indem sie das ITIL-Framework nutzten, um wiederholbare Prozesse zu schaffen, die sicherstellen, dass die vereinbarten Services konsistent geliefert werden.

Die ITIL 2007 Edition („ITIL V3“)

Im Jahr 2007 kam eine neue Version von ITIL heraus. Die größte Änderung war, dass ITIL um einen Lebenszyklus herum strukturiert war. Das bedeutete, dass es nun ein viel besseres Verständnis dafür gab, wofür Services da sind und ein klarerer Fokus darauf bestand, was für die Kund:innen wichtig ist. Es wurde viel mehr Wert auf Strategie und Design gelegt und es gab ein ganzes Buch über die kontinuierliche Serviceverbesserung.

Es wurde mir nun klar, dass die Erfüllung eines SLAs nicht das Wichtigste für eine IT-Organisation ist. Es kam viel zu häufig vor, dass die SLAs eingehalten wurde, während unsere Kund:innen trotzdem enttäuscht, frustriert oder wütend waren. Was wir eigentlich brauchten, war ein Fokus auf Service. Wir mussten unsere Kund:innen und Anwender:innen verstehen und sicherstellen, dass unsere Services ihnen auch tatsächlich Wert bringen.

Also habe ich meine Arbeitsweise verändert.

Ich habe immer noch versucht, die Zielvorgaben zu erfüllen, aber wenn die Umstände es verlangten, habe ich verstanden, dass es besser wäre, die Zielvorgabe zu ignorieren und mich stattdessen darauf zu fokussieren, was der/die Kund:in tatsächlich wollte. Die wichtigen Dinge waren die Kund:innenzufriedenheit und die Kund:innenerfahrung. Natürlich braucht es für das angemessene Anwenden dieses Ansatzes eine IT Organisation mit reifen Prozessen und erfahrene Mitarbeiter:innen, die souverän und ohne starke Abhängigkeit von Routine und wiederholbaren Prozessen arbeiten können.

Viele Menschen fanden den Übergang von einem Prozessfokus auf einen Servicefokus sehr schwierig; wir haben immer noch Menschen im ITSM, die darauf bestehen, SLAs zu erfüllen, auch wenn es schlecht für ihre Kund:innen ist. Ich hatte viele Gespräche mit diesen Menschen, face-to-face und über soziale Netzwerke, in denen ich versucht habe, sie davon zu überzeugen, diesen altmodischen prozessfokussierten Ansatz hinter sich zu lassen. Manchmal war ich erfolgreich, aber oft haben sie einfach auf dieselbe Art und Weise weitergearbeitet und so Probleme für ihre Kund:innen verursacht.

Was kommt als nächstes?

Währenddessen entwickelt sich ITSM wieder weiter. Die Welt der Softwareentwicklung hat Ideen wie Agile und DevOps eingeführt. Viele Menschen im ITSM erkennen, dass wir uns auch weiterentwickeln müssen, wenn wir den besten Wert für unsere Kund:innen erzielen wollen. Hier sind einige der Dinge, von denen ich denke, dass sie die Zukunft von ITSM beeinflussen werden. Ich habe nicht genug Platz, um all diese Ideen komplett zu entwickeln, aber hoffentlich wird es ausreichen, um Ihr Interesse zu wecken und Sie dazu zu bringen, etwas mehr darüber zu recherchieren.

Agile

Das Manifest für Agile Softwareentwicklung kam im Jahr 2001 heraus. Es betonte, dass:

  • Individuen und Interaktionen wichtiger als Prozesse und Tools,
  • Funktionierende Software wichtiger als umfassende Dokumentation,
  • Zusammenarbeit mit dem/der Kund:in wichtiger als Vertragsverhandlungen und
  • Reagieren auf Veränderung wichtiger als das Befolgen eines Plans sind.

Das Ergebnis ist ein flexibler und schneller Ansatz, der zu enormen Verbesserungen in der Qualität neuer Software geführt hat und die Möglichkeit bietet, schnell auf sich ändernde Geschäftsanforderungen zu reagieren.

Dieselben agilen Ideen werden nun auch auf ITSM angewendet. Sie verändern die Vorstellungen darüber, was die beste Art und Weise ist, ITSM zu implementieren und zu verbessern (keine mehrjährigen ITSM Projekte mehr); und auch darüber, den besten Weg zu finden, um Kund:innen zu unterstützen (Individuen und Interaktionen sind wichtiger als Prozesse und Tools).

Lean 

Lean ist ein Managementansatz, der die Wichtigkeit der Schaffung von maximalem Wert für den/die Kund:in mit minimaler Verschwendung betont. Sie können Artikel im Internet über Lean Manufacturing, Lean Produktentwicklung und Lean Softwareentwicklung finden, wenn Sie mehr darüber lesen wollen.

Im Kontext von ITSM sind die wichtigsten Aspekte von Lean die folgenden:

  • Identifizieren Sie die end-to-end Wertschöpfungskette(n), von denen Sie ein Teil sind
  • Stellen Sie sicher, dass alles, was Sie tun, Wert für die Kund:innen schafft
  • Eliminieren Sie Verschwendung in jeder Aktivität, verringern Sie Prozessschritte zum absoluten Minimum, das zur Schaffung von Wert benötigt wird

Automatisierung 

Automatisierung war immer schon ein Teil des IT Managements. Sogar als ich damals in den 1970ern angefangen habe, haben wir Tasks automatisiert, wo auch immer es möglich war. Was sich verändert hat, ist die Verfügbarkeit von Tools, die Automatisierung unterstützen und möglich machen. Wir können nun fast alles automatisieren, wenn wir uns dafür entscheiden.

Es gibt einige Dinge, die nicht automatisiert werden sollten, weil sie menschliches Urteilsvermögen als einen Teil des Entscheidungsprozesses benötigen, aber wir sollten alles automatisieren, was möglich ist, solange:

  • Wir die Aktivität wirklich verstehen
  • Die Aktivität einfach genug ist, dass sie klar dokumentiert werden kann
  • Es etwas ist, das oft genug gemacht wurde, damit wir die Automatisierung verfeinern und verbessern können
  • Die Automatisierung nicht das menschliche Urteilsvermögen mit unflexiblen Regeln ersetzt („Computer says no“)

DevOps 

DevOps verwendet Ideen von Agile, Lean und Automatisierung, um den Weg der Software von der Entwicklung bis zum/zur Kund:in zu verbessern. DevOps betont die drei Wege:

  • Flow – Verstehen Sie, wie Sie in eine end-to-end Wertschöpfungskette passen, beseitigen Sie Engpässe, begrenzen Sie gerade laufende Arbeit
  • Feedback – Bieten Sie schnelle Feedback-Schleifen, um schlechte Qualität so schnell wie möglich zu erkennen und zu beseitigen, ohne viel Aufwand zu betreiben
  • Experimentieren und Lernen – Erstellen Sie Hypothesen, machen Sie Vorhersagen, testen Sie sie, lernen Sie daraus und verbessern Sie sich.

Die Kombination dieser drei Wege mit intensiver teamübergreifender Zusammenarbeit und einem sehr hohen Automatisierungsgrad kann zu einer extrem schnellen Bereitstellung von neuer und geänderter Software mit einem sehr hohen Maß an Flexibilität und Kundenzufriedenheit führen.

DevOps automatisiert typischerweise viele der Tasks, die früher von den Menschen ausgeführt wurden, die Software Changes implementiert haben. Es umfasst jedoch neben der Softwareentwicklung auch operative Aspekte. ITSM muss sich das zu eigen machen. Wir müssen zur Evolution von neuen Ideen beitragen und dazu beitragen, dass bei einer massiv gesteigerten Automatisierung von betrieblichen Routineaufgaben das menschliche Urteilsvermögen über den gesamten end-to-end Prozess erhalten bleibt.

Enterprise Service Management

Viele der Ideen, Tools und Prozesse, die ITSM entwickelt und unterstützt haben, sind genauso nützlich, wenn Services unterstützt werden, die nichts damit zu tun haben. Enterprise Service Management (ESM) ist die Verwendung von diesen Ansätzen in der ganzen Organisation, einschließlich dem Facility Management, der Personalabteilung, dem Auftragswesen, der Rechtsabteilung und andere Abteilungen, die Services erbringen. Durch die Verwendung von gemeinsamen Tools, Prozessen und Ansätzen können wir bessere Services in der ganzen Organisation erbringen.

Effektives ESM dreht sich nicht nur um die Bereitstellung von ITSM Tools für die Nutzung durch andere Abteilungen, sondern beinhaltet die Zusammenarbeit und das Lernen in der gesamten Organisation. Oft hat die IT-Abteilung genauso viel zu lernen, wie sie zu teilen hat.

Stuart Rance

Stuart Rance ist Berater, Trainer und Autor mit internationalem Ruf als Experte für ITSM und Informationssicherheit. Er war Autor für ITIL® Practitioner Guidance, Hauptautor von RESILIA ™: Cyber ​​Resilience Best Practice und Autor von ITIL Service Transition, Ausgabe 2011. Stuart schreibt Blogs und White Papers für viele Organisationen, einschließlich seiner eigenen Website.

Der ITSM Experte ist Prüfer für ITIL, Chefprüfer für RESILIA und Ausbilder für ITIL, CISSP und viele andere Bereiche. Er entwickelt und bietet maßgeschneiderte Schulungskurse und hält Präsentationen zu zahlreichen Themen im Zuge von Veranstaltungen wie itSMF-Konferenzen und bei privaten Organisationen.

Sie können ihm hier folgen und seine Originalartikel lesen:

ITSM.tools ist eine ITSM-fokussierte Website und ein Service, die unabhängige Branchenanalysen, Beratung, Inhalte und Beratung bieten. Der Inhalt reicht von ITSM-Tool-Reviews, Blogs und Branchennachrichten bis hin zu ITSM-Tipps und Best Practices.

ITIL Grundprinzipien

In ITIL Version 3 war die neueste Ergänzung zu ITIL der ITIL Practitioner, der im Jänner 2016 veröffentlicht wurde. Diese Publikation unterstützt viele der in diesem Blog beschriebenen Ideen.

Der ITIL Practitioner beschreibt neun Grundprinzipien:

  • Wertorientierung
  • Design für Erfahrung
  • Dort beginnen, wo man steht
  • Ganzheitlich arbeiten
  • Sich iterativ weiterentwickeln
  • Direkt beobachten
  • Transparent sein
  • Zusammenarbeiten
  • Auf Einfachheit achten

Es werden auch drei Kernkompetenzen beschrieben:

  • Metriken und Messung
  • Kommunikation
  • Organizational Change Management

All diese Punkte werden im Kontext der kontinuierlichen Verbesserung von IT Services beschrieben. Wenn Sie mehr über diese Dinge erfahren wollen, empfehle ich Ihnen, die ITIL Pracititioner Guidance zu lesen. Sie könnten auch an der Rezension des ITIL Practitioner von meinem guten Freund Stephen Mann interessiert sein.

Zusammenfassung

Seit Februar 2019 wurde die aktuelle Version ITIL 4 veröffentlicht. In dieser Version gibt es die weiterentwickelten Grundprinzipien.

ITIL 4 beschreibt sieben Grundprinzipien:

  • Wertorientierung
  • Dort beginnen, wo man steht
  • Iterative Weiterentwicklung mit Feedback
  • Zusammenarbeiten und Transparenz fördern
  • Ganzheitlich denken und arbeiten
  • Auf Einfachheit und Praktikabilität achten
  • Optimieren und Automatisieren

ITSM hat vielen IT Organisationen geholfen, sich von Technologieprovidern hin zu Providern von wertkreierenden Services zu verändern. Wir können aber hier nicht aufhören, denn wenn wir eine Lösung aus den 1990er Jahren für die Probleme des 21. Jahrhundert anbieten, werden wir schnell irrelevant werden.

Jede:r der/die IT Services bereitstellt oder unterstützt, muss sich über neue Ansätze auf dem Laufenden halten und neue Ideen übernehmen, die den Wert, den sie ihren Kund:innen bieten, erhöhen. Einige der Konzepte, über deren Übernahme Sie nachdenken sollten, werden in diesem Blog beschrieben, aber es gibt noch viele weitere, die ebenfalls relevant sind. Ich bin ein Fan von Kanban, Cobit 5 und Resilia – welche anderen Praktiken sollten wir Ihrer Meinung nach in Betracht ziehen?

Sie können mehr herausfinden, indem Sie sich über Diskussionen in Sozialen Netzwerken auf dem Laufenden halten

Und indem Sie an Events wie Service Space teilnehmen. Das ist DIE Konferenz für Service Management in Österreich (Hinweis der Editorin).

This article was originally published in English on ITSM.tools.

der passende Kurs zu diesem Thema:

Alle Grundlagenbegriffe, damit Sie vom Gleichen sprechen wie Ihre Kolleg:innen.

zur ITIL 4 Foundation