ITIL 2011

<seo metakeywords="itil 2011, itil 2011 edition, vergleich itil 2011 2007, unterschied itil 2007 itil 2011, unterschiede itil 2011 2007" metadescription="Was ist neu in ITIL 2011, der im Juli 2011 veröffentlichten, neuen ITIL Edition." />

in English - ITIL 2011

 

Vier Jahre nach der Einführung von ITIL V3 gibt es ein Update zu den IT-Service-Management-Leitlinien. Auf dieser Seite haben wir für Sie die mit der neuen Version ITIL 2011 verbundenen Änderungen und Anpassungen zusammengestellt.

 

Wozu eine neue ITIL 2011 Edition?

Die offiziellen FAQs zu ITIL 2011 stellen klar, dass es sich bei ITIL 2011 um ein Update, nicht aber um eine neue ITIL-Version handelt [1]. So heißt es, dass keine grundlegend neuen Konzepte hinzugekommen seien. Vielmehr liege das Ziel des Updates darin, bestehende Fehler zu beseitigen und Inkonsistenzen im Text und in den Darstellungen zu beseitigen.

Für viele Neuerungen in ITIL 2011 waren das Feedback der Anwender und Hinweise aus der Schulungs-Community ausschlaggebend.

 

Neue Bezeichnungen für die ITIL Editionen

Die aktuelle ITIL-Version wird als "ITIL 2011" oder auch einfach "ITIL" bezeichnet, während der Begriff "ITIL 2007" für die ursprüngliche ITIL-V3-Edition benutzt wird. ITIL V2 hat derzeit kaum noch Bedeutung und läuft allmählich aus.

 

Unterschiede zwischen ITIL 2007 und ITIL 2011

Eine Zusammenfassung der Änderungen in ITIL 2011 gegenüber ITIL 2007 gibt es zum Download auf der offiziellen ITIL-Webseite: Das Paper enthält eine Übersicht zu den wichtigsten Änderungen und deren Zielrichtung, jedoch keine vollständige und detaillierte Aufstellung aller Änderungen.

ITIL 2011 Update

Obwohl keine grundsätzlich neuen Konzepte in ITIL 2011 hinzugekommen sein sollen, fällt sofort auf, dass die Bücher zu ITIL 2011 deutlich umfangreicher sind als die der vorhergehenden Edition - tatsächlich sind die ITIL-Bücher also ganz beträchtlich inhaltlich erweitert worden, und es wäre aus unserer Sicht vorschnell, diese Modifikationen als "rein kosmetisch" abzutun.

Einige neue Prozesse sind hinzugefügt worden, während andere jetzt in größerer Detailtiefe als zuvor behandelt werden. Abgesehen von solchen umfangreicheren Anpassungen gibt es an vielen Stellen im Gesamt-Werk kleinere Änderungen und Erweiterungen, die recht hilfreich sind, um Einzelaspekte zu verdeutlichen. Das heisst aber auch: Es ist fast unmöglich, die beiden Editionen 1:1 zu vergleichen und eine detaillierte Komplett-Liste aller Änderungen herauszugeben.

Nichtsdestotrotz können wir hier aber die wichtigsten Unterschiede aufzeigen.

Zur Zeit passen wir unsere ITIL-Prozesslandkarte (und das ITIL-Wiki) an ITIL 2011 an und dokumentieren die Modifikationen in einem Change Log. Mit Hilfe dieses Change Logs können wir am einfachsten darstellen, was sich in ITIL 2011 geändert hat. Wir haben uns darum entschlossen, ihn hier in komprimierter Form zu veröffentlichen. Im Zuge unseres Upgrades auf ITIL 2011 wird diese Seite peu-à-peu ergänzt.

 

Prozesse ITIL 2011

Änderungen zwischen ITIL 2007 und ITIL 2011 in Service Design

Design-Koordinierung

• Als neuer Prozess in ITIL 2011 wird Design Coordination (Design-Koordinierung) eingeführt. Dieser Prozess ist verantwortlich dafür, die durch andere Service-Design-Prozesse auszuführenden Design-Aktivitäten miteinander abzustimmen und in Einklang zu bringen. Für diese koordinierenden Tätigkeiten war in ITIL 2007 noch das Service Level Management zuständig.

• Damit ein einheitlicher Ansatz für alle Service-Design-Aktivitäten verwendet wird, gibt es nun die Service-Design-Richtlinie.

 

Service Level Management

• Mit der Einführung des neuen Design-Koordinierungs-Prozesses wurde Service Level Management in ITIL 2011 vollständig redesignt: Alle Koordinations-Aktivitäten sind aus dem Prozess herausgelöst worden.

• Service Level Management ist nun vor allem für das Erfassen von Service-Anforderungen verantwortlich. Es prüft, ob die vereinbarten Service-Levels erreicht werden und stellt die Informationen dazu im Service-Level-Bericht bereit.

 

Änderungen zwischen ITIL 2007 und ITIL 2011 in Service Transition

Change Management

• Die Struktur des Change Management Prozesses wurde in ITIL 2011 modifiziert, um deutlicher zu machen, dass signifikante Changes an verschiedenen Punkten ihres Lebenszyklus' autorisiert werden sollen.

• Neu sind Teil-Prozesse zur Bewertung von Change-Vorschlägen und zur Implementierung von Minor Changes. Als Minor Changes werden Changes mit geringem Risiko bezeichnet.

• Zum Zwecke einer formalen Bewertung übermittelt Change Management umfassende Changes (Major Changes) nun an Change-Evaluierung.

• Wichtige Änderungen betreffen den Teil-Prozess Change-Planung: Für die Detail-Planung eines Changes und des entsprechenden Releases ist jetzt das Release Management zuständig.

• In ITIL 2011 spielen die Change-Modelle innerhalb von Change Management eine größere Rolle. Sie werden nun für Standard-Changes (Changes mit geringem Risiko auf Betriebsebene) und auch für wiederkehrende, signifikante Changes verwendet.

 

Change-Evaluierung

• Ein neuer Prozess in ITIL 2011 ist Change Evaluation (Change-Evaluierung). Dieser Prozess verdeutlicht, wie Major Changes evaluiert werden sollten.

• Change Evaluation wird an verschiedenen Punkten innerhalb des Change-Lifecycles immer dann vom Change-Management-Prozess aufgerufen, wenn eine Change-Bewertung durchzuführen ist.

• Die Ergebnisse dieser Change-Bewertung werden im Bericht zur Change-Evaluierung dokumentiert.

 

Projektmanagement (Transition Planning and Support)

• Durch die Überarbeitung in ITIL 2011 wird der Haupt-Verantwortungsbereich des Prozesses Projektmanagement (Transition Planning and Support) klarer herausgestellt: Dazu gehören die Koordination der verschiedenen Service Transition Projekte sowie die Konfliktlösung zwischen diesen.

• Die Initiierung von Projekten erfolgt immer dann, wenn das Service Portfolio Management eine Service-Charter zu einem neuen oder substanziell geänderten Service erstellt und autorisiert hat.

• Der Projektmanagement-Prozess stützt sich nun im Rahmen von Detail-Planungsmaßnahmen auf weitere Prozesse, wie z.B. Design-Koordinierung und Release-Planung.

 

Release und Deployment Management

• In ITIL 2011 wird Release Management vom Projektmanagement-Prozess aufgerufen, um eine Detail-Planung zu erstellen, die die Einzelheiten zur Release-Zusammenstellung (Release Build), den Release-Test und das Ausrollen der Release-Komponenten in die Live-Umgebung umfasst.

• Eine zusätzliche Schnittstelle zu Projektmanagement (Transition Planning and Support) stellt nun sicher, dass Release Management dem Projektmanagement kontinuierlich die aktuellen Planungs-Informationen zur Verfügung stellt.

• Nach den aktuellen ITIL-2011-Richtlinien werden Minor Changes vom Change Management ohne Einbeziehung des Release-Management-Prozesses implementiert.

 

Service-Validierung und -Test

• In ITIL 2011 stellt eine zusätzliche Schnittstelle zwischen Service-Validierung und ITIL-Projektmanagement sicher, dass dem Projektmanagement kontinuierlich die aktuellen Planungs-Informationen zur Verfügung gestellt werden.

• Der ITIL V3 Teil-Prozess "Service-Design-Validierung" wurde gelöscht, da diese Aktivität nun als Teil von Change-Evaluierung ausgeführt wird.

 

Änderungen zwischen ITIL 2007 und ITIL 2011 in Service Operation

Event Management

• Event Management wurde um das Konzept der "1st Level Correlation" bzw. "2nd Level Correlation" erweitert.
• Die detaillierteren Empfehlungen der ITIL-2011-Bücher machen eine Ergänzung der entsprechenden Arbeitsabläufe im ITIL-Prozessmodell notwendig.

 

Incident Management

• Innerhalb von Incident Management wurden die Empfehlungen zur "Priorisierung von Incidents" überarbeitet. Die neue Checkliste Incident-Priorität enthält alle wesentlichen Punkte.

• Zusätzliche Arbeitsschritte gibt es im Teil-Prozess Unmittelbare Incident-Behebung durch den 1st Level Support. Es wird deutlich gemacht, dass Incidents (wenn möglich) mit bestehenden Problems und Known Errors in Beziehung gesetzt werden sollen.

• Die Teil-Prozesse "Unmittelbare Incident-Behebung durch den 1st Level Support" und Incident-Behebung durch den 2nd Level Support wurden wesentlich erweitert, um klarer darzustellen, wann genau das Problem Management seitens des Incident Managements eingeschaltet werden soll. Die Betonung liegt nun darauf, Services so schnell wie möglich wiederherzustellen. Die Hilfe des Problem Managements ist dann einzufordern, wenn die eigentliche Ursache des Incidents nicht mit einem Minor Change bzw. in der vorgeschriebenen Lösungszeit behoben werden kann.

• Im Teil-Prozess Incident-Abschluss und -Auswertung wird nun betont, dass unbedingt zu prüfen ist, ob neue Problems, Workarounds oder Known Errors an das Problem Management übermittelt werden müssen.

 

Request Fulfilment

• Der Prozess Request Fulfilment wurde vollständig überarbeitet, um die aktuellen Empfehlungen wiederzugeben. Request Fulfilment setzt sich nun aus fünf Teil-Prozessen zusammen, die gewährleisten, dass alle wesentlichen Aktivitäten und Entscheidungskriterien berücksichtigt sind.

• Hinzugekommen sind Schnittstellen
  • zwischen Request Fulfilment und dem Incident Management (im Falle, dass sich ein Service Request nachträglich als Incident herausstellt) sowie
  • zwischen Request Fulfilment und Service Transition (im Falle, dass die Erfüllung eines Service Requests die Einbeziehung des Change Managements erforderlich macht).

• Es wird nun verdeutlicht, welche Informationen zur Beschreibung eines "Service Requests" notwendig sind. Ebenfalls aufgenommen wurde die Beschreibung des Lifecycles von Service Requests.

• Das Konzept des "Service Request Models" wird umfassender erklärt.

 

Access Management

• Eine neue Schnittstelle zwischen Access Management und Event Management unterstreicht, dass (einige) Regeln für Event-Kategorisierung und -Korrelation vom Access Management entworfen werden sollten - dies ist wichtig, um einen nicht authorisierten Zugriff auf Services aufzudecken.

• Bislang wurde nicht nicht deutlich gemacht, dass Zugriffsrechte - falls erforderlich - zurückgenommen werden können. Eine dedizierte Aktivität sorgt nun dafür.

• Es wird nun klar darauf hingewiesen, dass in den Prozessen Request Fulfilment und Incident Management die Authorisierung des Anfragenden geprüft werden muss.

 

Problem Management

• Eine neuer Teil-Prozess Proaktive Problem-Identifikation hebt die Bedeutung des proaktiven Problem Managements hervor.

• Im Teil-Prozess Problemidentifikation und -kategorisierung wird jetzt deutlicher gemacht, dass die Kategorisierung und Priorisierung von Problems mit dem im Incident Management benutzten Methoden harmonisiert sein sollte - dies trägt wesentlich dazu bei, dass Incidents und Problems einfach in Beziehung zueinander gesetzt werden können.

• Wesentlich prominenter behandelt wird in Problemdiagnose und -lösung die Empfehlung, Problems bei Bedarf zu reproduzieren.

• Der Teilprozess Problemdiagnose und -lösung wurde komplett überarbeitet. Es gibt klare Richtlinien zur Interaktion dieses Prozesses mit dem Incident Management.

• Die neuen ITIL-2011-Bücher enthalten einen deutlich erweiterten Abschnitt zu Techniken der Problem-Analyse sowie Beispiele für Situationen, innerhalb derer die entsprechenden Techniken angewandt werden sollten.