Video | ITIL 4 Prozessmodell

ITIL® 4, die neueste Ausgabe des bekannten Service-Management-Frameworks, ist hier, und ich werde zurzeit oft gefragt, wann es eine aktualisierte Version unserer ITIL®-Prozesslandkarte für ITIL 4 gibt. Das Problem - oder die Chance, je nachdem, wie man es sieht - ist, dass ITIL 4 keine spezifischen Prozesse mehr definiert, die wir in Prozess-Templates übersetzen könnten. Trotzdem müssen Organisationen natürlich auch in Zeiten von ITIL 4 ihre Prozesse definieren, und deshalb sprechen wir heute darüber, wie wir Prozess-Templates für ITIL 4 bereitstellen können.

Zuerst schauen wir aber noch einmal zurück auf ITIL V3: Es war am Service-Lifecycle ausgerichtet und hat 26 Prozesse definiert. Diese Prozesse konnten in Prozess-Templates übersetzt werden, die wir als die "ITIL-Prozesslandkarte" bereitstellen. Mit ITIL V3 war also alles recht klar.

Bei ITIL 4 ist die Situation etwas schwieriger, weil es keine definierten Prozesse gibt. Stattdessen verfolgt ITIL 4 einen ganzheitlichen Ansatz und stellt das "End-to-End-Service-Management von der Nachfrage bis zur Wertschöpfung" in den Mittelpunkt.

Die Kernkomponenten von ITIL 4 sind

• das Vier-Dimensionen-Modell ['The four dimensions model']
• und das ITIL-Service-Wert-System ['ITIL service value system - SVS'].

Das Service-Wert-System besteht aus mehreren Komponenten:

• Leitprinzipien ['Guiding principles'],
• Steuerung ['Governance'],
• Service-Wertschöpfungskette ['Service value chain - SVC'],
• Praktiken ['Practices']
• und Kontinuierliche Verbesserung ['Continual improvement'].

In diesem kurzen Video kann ich nicht all diese Elemente erklären, aber die ITIL 4-Practices sehen wir uns näher an, weil wir hier viele aus ITIL V3 bekannte Prozesse wiederfinden, wie z. B.:

• Continual Improvement,
• Incident Management,
• Service Level Management.

Auf den ersten Blick sieht diese Sammlung von Practices aus wie eine "aufgebohrte" Version der 26 Service-Lifecycle-Prozesse aus ITIL V3. Man könnte deshalb denken, dass Organisationen jetzt 34 Prozesse implementieren sollen. Das ist aber überhaupt nicht der Fall, denn einige der Practices sind bestimmt keine Prozesse. Hier ist ein Beispiel:

Die ITIL 4-Practice "Organizational Change Management" stellt den Menschen in den Mittelpunkt und befasst sich mit den organisatorischen Aspekten von Veränderungen. Diese Techniken können in vielen Situationen zur Anwendung gebracht werden, und die meisten Organisationen würden sie nicht als einen Prozess verstehen.

Nicht alles, was in ITIL 4 enthalten ist, ist also ein Prozess. Dennoch müssen Organisationen natürlich ihre Prozesse definieren, um zu funktionieren.

Und nun stellt sich die Frage, ob wir Prozess-Templates für ITIL 4 bereitstellen können. Ich glaube schon, denn es gibt immer noch eine Grundmenge an Service-Management-Prozessen, die für die meisten Organisationen Sinn machen. Und für diese Prozesse können wir durchaus Templates erstellen.

Wir haben jetzt sogar mehrere Optionen, da uns ITIL 4 keine Prozesse mehr vorschreibt.

Zunächst bleibt festzuhalten, dass wir die ITIL-Prozesse keineswegs wegwerfen müssen. AXELOS hat erklärt, dass die ITIL V3-Prozesse weiterhin bewährte Empfehlungen darstellen, und unsere (auf ITIL V3 basierende) ITIL-Prozesslandkarte ist nach wie vor verfügbar.

Andererseits sagt ITIL 4 jetzt, dass wir "einfache und praktikable" Lösungen bevorzugen sollen. Es gibt also die Chance auf einen neuen Start mit schlankeren Service-Management-Prozessen. Der Punkt ist, dass die Prozesse einer Organisation verständlich sein müssen, und es sollte einfach sein, die Prozesse an die individuellen Erfordernisse der Organisation anzupassen.

Tatsächlich bieten wir bereits solche schlankeren Prozesse an - unter dem Namen "YaSM®-Prozesslandkarte".

Das YaSM-Modell ist nicht nur an ITIL ausgerichtet, sondern auch an anderen modernen Service-Management- Frameworks und ‑Methoden, wie z. B. VeriSM™, FitSM und SIAM®.

Die Messlatte für die YaSM-Prozesse ist ISO 20000, der internationale Standard für Service-Management. YaSM ist deshalb sehr gut geeignet für Organisationen, die sich nach ISO 20000 zertifizieren lassen möchten.

Und so sieht das YaSM-Prozessmodell aus: Es hat eine klare, pragmatische Struktur mit fünf Service-Lifecycle-Prozessen und einer Reihe von unterstützenden Service-Management-Prozessen. Diese Prozesse kommen Ihnen sicherlich bekannt vor, wenn Sie sich mit ITIL oder anderen Service-Management-Frameworks auskennen.

Für jeden YaSM-Prozess stellen wir detaillierte Templates bereit, damit Sie nicht bei Null beginnen müssen, wenn Sie Ihre Service-Management-Prozesse definieren.

Wenn Sie noch eine oder zwei Minuten Zeit haben, zeige ich Ihnen zwei Beispiele dieser Templates - und wie wir damit die ITIL-Empfehlungen umsetzen können.

Beim ersten Beispiel handelt es sich um das Incident Management - ein Prozess in ITIL V3 und eine Practice in ITIL 4.

Im YaSM-Modell gibt es einen Incident-Management-Prozess mit typischen Kernaktivitäten wie z. B.

• Lösen von Major Incidents,
• Lösen von Incidents im 1st Level Support,
• Lösen von Incidents im 2nd Level Support.

Für jeden von diesen Sub-Prozessen enthält das YaSM-Modell eine weitere Detailstufe in Form eines Swimlane-Diagramms. Dieses hier beschreibt zum Beispiel die Aktivitäten, die im 1st Level Support durchgeführt werden:

• Nach einer ersten Analyse
• wird die Knowledge Base durchsucht,
• der Incident, falls möglich, einem bestehenden Problem zugeordnet,
• ... und so weiter ...

Dies ist klassisches Incident Management, so wie wir es aus ITIL, ISO 20000 und praktisch allen anderen Service-Management-Frameworks kennen.

Mein zweites Beispiel ist Service Design, eine Phase des ITIL-V3-Service-Lifecycles. In ITIL 4 ist Service Design eine Practice und eine Kernaktivität in der Service-Wertschöpfungskette.

ITIL V3 besagt, dass sich Service Design aus mehreren Prozessen zusammensetzt, z. B.

• Design-Koordinierung,
• Service Level Management,
• Availability Management,
• Capacity Management etc.

In ITIL 4 ist Service Design kein Geflecht aus Prozessen mehr, sondern eine Sammlung von Kernaktivitäten wie z. B.

• Planen neuer oder geänderter Services,
• Erstellen von Service-Anforderungen und -Spezifikationen,
• Bestimmen der erforderlichen Service-Komponenten.

Im YaSM-Modell übersetzen wir diese Leitlinien in einen pragmatischen Service Design-Prozess. Wenn wir das ein bisschen vergrößern, sehen wir, dass das Designen eines Service in YaSM recht geradlinig verläuft:

• Zuerst werden die erforderlichen Service-Eigenschaften definiert,
• dann wird die erforderliche Infrastruktur designt,
• das Vorgehen zur Implementierung beschrieben
• und schließlich noch die Service-Implementierung vorbereitet.

Wieder gibt es auf der darunterliegenden Ebene für jeden Sub-Prozess ein Swimlane-Diagramm, wie z. B. dieses hier, das die empfohlenen Schritte zum Designen der erforderlichen Infrastruktur für einen Service darstellt:

• Bestimmen der erforderlichen Infrastruktur und weiterer Voraussetzungen,
• Spezifizieren der erforderlichen Änderungen an der technischen Infrastruktur
• und an den externen unterstützenden Services
• ... und so weiter ...

Ich hoffe, Sie stimmen mir zu, dass das viel einfacher zu verstehen ist als die komplizierten Service-Design-Prozesse, die wir aus ITIL V3 kennen.

Sie haben also die Wahl. Entweder bleiben Sie bei den ITIL V3-Prozessen, oder Sie verwenden unser schlankeres YaSM-Modell.

Wenn Sie mehr zu YaSM und zur YaSM-Prozesslandkarte erfahren möchten, gehen Sie einfach auf yasm.com. Dort finden Sie auch unsere Kontaktinformationen, falls Sie sich mit uns in Verbindung setzen möchten.

Danke fürs Zusehen und bis zum nächsten Mal!