Traditionell konzentrierten sich IT-Organisationen vor allem auf Software und Hardware. Die Anforderungen der Kund*innen standen nicht unbedingt im Vordergrund. ITIL^® vertritt seit Ende der Achtziger Jahre den Kerngedanken, dass IT-Services sich an den Bedürfnissen der Kund*innen ausrichten müssen und Unternehmen die zu erbringenden Services explizit mit ihren Kund*innen vereinbaren sollten. Dabei spielen effektive Prozesse und klar definierte Verantwortlichkeiten eine entscheidende Rolle. 
Da sich unter IT-Verantwortlichen zunehmend ein Bewusstsein für Service- und Kundenorientierung bildet, hat sich ITIL^® in den vergangenen Jahren zum weltweiten De-facto-Standard für das IT-Service-Management durchgesetzt.  
Die ITIL^®-Empfehlungen sind sehr allgemein gültig – so spiegeln sich die Anforderungen der meisten Unternehmen und Organisationen unabhängig von ihrer Größe oder Branche darin wider. 

ITIL^® wird ständig weiterentwickelt. Im Frühjahr 2020 erschien mit Version 4 die aktuelle Version des Kataloges, die das Thema End-to-end-Service-Management – von der Nachfrage bis zur Wertschöpfung in den Mittelpunkt rückt. 
Die Rolle der IT-Abteilung eines Unternehmens hat sich über die letzten Jahre grundlegend geändert. Heutzutage muss sie sich neben der hauseigenen Soft- und Hardware auch noch um IT-Services von verschiedensten zuliefernden Unternehmen kümmern. Das kann eine Software für die Gehaltsabrechnung sein, ein extern gebuchtes Ticketingsystem oder die Steuerung der Brandschutzanlage. Dazu muss eine Unternehmens-IT das Zusammenspiel der intern und extern ausgeführten Services orchestrieren, planen und überwachen: Sie übernehmen das IT-Servicemanagement (kurz: ITSM). 
Im Rahmen dieser Entwicklung besteht die große Herausforderung in der Kommunikation: Das IT-Servicemanagement ist gefordert, unternehmensübergreifende Prozesse zu entwickeln. Um hierbei Missverständnisse bei allen Beteiligten zu vermeiden, ist eine einheitliche Kommunikationsebene mit klar definierten Begriffen und einer gemeinsam festgelegten Zielsetzung essenziell. 
Gerade deswegen ist ITIL^® als gängiger Quasi-Standard heute wichtiger denn je. 

Bei der Vorgängerversion ITIL^®V3 kam die Kritik auf, dass die beschriebenen Prozesse zu starr für eine sinnvolle Umsetzung in der Praxis seien.

Daher wurde bei der Überarbeitung der ITIL^®-Standards viel Wert auf unternehmens- und branchenspezifische Flexibilität gelegt. Außerdem sind in ITIL^®4 Evaluationszyklen vorgesehen, damit Organisationen besser auf Trends und Umwelteinflüsse reagieren können. Damit hat Axelos, der Macher von ITIL^®, bei der Entwicklung des neuesten Best-Practice-Katalogs auf einen stärkeren Praxisbezug gesetzt und auf die Bedürfnisse von IT-Dienstleistungsunternehmen reagiert. 

Auch die Themen Cloud, IT-Security und moderne Kommunikations-Tools werden behandelt.

Das Service Value System beschreibt übergeordnete Abhängigkeiten und Grundprinzipien beim Service-Management, die für alle Organisationen gelten sollen. Wie insgesamt bei ITIL^®4 zielt das SVS auf eine Wertsteigerung ab. Aus einer Nachfrage bzw. Chance (Opportunity/Demand) heraus werden konkrete Handlungsanweisungen und prozessspezifische Praktiken angewendet. Ziel ist dabei die kontinuierliche Optimierung von Services sowie deren Wertsteigerung (bessere Qualität oder Ressourceneinsparungen).

• Grundprinzipien: Im SVS werden 7 allgemeingültige Leitsätze genannt, die für jede Branche, für jedes Unternehmen und für jeden Service praktische Handlungsanweisungen liefern.
• Governance: Im Bereich Governance werden Anregungen für eine gute Unternehmensführung gegeben, da die oberste Führungsebene in Fragen der Kommunikation und der strategischen Ausrichtung der erste Ansprechpartner und Kontrollorgan ist.
• Service-Wertschöpfungskette: Die Service-Wertschöpfungskette (Service Value Chain) beschreibt eine Reihe von verknüpften Aktivitäten, wobei die Rolle von Prozessbeteiligten und Abhängigkeiten der enthaltenen (Teil-)Aktivitäten beschrieben werden. Die Kette startet bei der Idee oder Planung, beinhaltet sämtliche prozessbezogene Kommunikation, das Design, die Erstellung eines Produkts oder einer Dienstleistung und stellt das Ergebnis bereit. Aus diesem Gesamtablauf wird ein Wert generiert.
• Practices: Insgesamt 34 Praktiken behandeln unterschiedliche Themenbereiche und werden weiter untergliedert in 3 Kategorien:
  • 17 Service-Managementpraktiken
  • 14 allgemeine Managementpraktiken
  • 3 technische Managementpraktiken

Im SVS werden 7 Grundprinzipien festgelegt, die für jeden Service-Prozess gelten und allgemeine, branchenunabhängige Empfehlungen beinhalten:

• Wertorientierung: Bei jeder Aktivität und jedem Prozess steht die Generierung von Wert im Vordergrund. Ein Wert kann beispielsweise eine Qualitätssteigerung oder eine Kostenreduktion sein.
• Dort beginnen, wo man steht: Bestehende, funktionierende Strukturen und Prozesse sollen nicht komplett neu aufgebaut werden, sondern zielgerichtet weiterentwickelt werden.
• Iterative Weiterentwicklung mit Feedback: Prozesse unterliegen einem ständigen Wandel, wobei regelmäßige Bewertungen der Optimierung dienen. Dieser Wandel geschieht schrittweise, damit Erfolge auch zuverlässig gemessen werden können.
• Zusammenarbeiten und Transparenz fördern: Abteilungssilos (isoliertes Arbeiten) gilt es aufzulösen, da für Innovationen das kombinierte Knowhow einer Firma zur Verfügung stehen muss. Ziel ist ein gelenkter Austausch zwischen allen Interessengruppen.
• Ganzheitlich denken und arbeiten: Bei Entscheidungen über Prozessveränderungen sollten alle Abhängigkeiten und Rahmenbedingungen berücksichtigt werden. Hierbei ist eine transparente Kommunikation innerhalb der Organisation sowie mit Kunden und Lieferanten zu empfehlen.
• Auf Einfachheit und Praktikabilität achten: Die Anzahl an Teilschritten ist so weit wie möglich zu reduzieren. Das verbessert das Verständnis von Prozessen und Abhängigkeiten sind leichter erkennbar. Im Standardablauf muss es nicht für jede Ausnahme eine Lösung geben.
• Optimieren und automatisieren: Sobald Abläufe verschlankt wurden, sollten sie so weit wie möglich automatisiert werden, wenn dies sinnvoll ist. Trotz einer Automatisierung sollten Compliancebestimmungen, Budgetgrenzen und andere Faktoren berücksichtigt werden.

Zu Beginn eines ITIL^®-Projekts empfiehlt es sich, die Services zu bestimmen, die abgedeckt werden sollen.
Der Hauptbeweggrund für die Einführung von ITIL^® ist immerhin eine stärkere Servicefokussierung.

Dabei sollte zwischen für Kund*innen erbrachten Services und solchen unterschieden werden, die nur innerhalb der Service-Provider-Organisation sichtbar sind (den sogenannten unterstützenden Services). Kund*innen-Services zeichnen sich hierbei dadurch aus, dass sie einen Wert für die Kund*innen darstellen.

Möchte ein*e Kund*in also einen funktionierenden Internetzugang (Kund*innen-Service), ist es im Grunde genommen unwichtig, welche Art von technischer Infrastruktur dafür benötigt wird (unterstützender Service).

Zu Beginn sollten Sie eine Liste aller Business-Services aus vorhandenen Vereinbarungen und Dokumentationen erstellen. Sobald feststeht, welche Services für Kund*innen erbracht werden, können Sie die nötigen unterstützenden Services festlegen. Oft sind diese direkt mit bestimmten Teilen der technischen Infrastruktur wie beispielsweise einer SAP-Plattform verbunden.

Mit der Liste aller Services müssen Sie nur noch deren Beziehungen zueinander festhalten, um die Servicestruktur zu definieren.
Diese Servicestruktur ist später eine wichtige Grundlage für die Implementierung des Servicekatalog-Management-Prozesses.

Für den Erfolg einer ITIL^®-Implementierung ist von entscheidender Bedeutung, dass die Personen, die später Verantwortung für die Durchführung bestimmter Prozesse übernehmen, schon direkt zu Beginn bei der Konzeption dieser Prozesse mitwirken. So können Sie gewährleisten, dass so viel Erfahrung wie möglich in die Prozessdefinition einfließt und sich die Inhaber*innen der Rollen mit den Änderungen im Arbeitsablauf identifizieren können, die ITIL^® mit sich bringt.

Die benötigten Rollen leiten sich direkt aus den neu einzuführenden ITIL^®-Disziplinen ab. Soll beispielsweise das Problem Management eingeführt werden, muss die Rolle des*der Problem Managers besetzt werden.
Gerade in großen Unternehmen kann es auch vorkommen, dass ITIL^®-Rollen noch einmal in weitere Unterrollen aufgeteilt werden müssen, wenn sich zum Beispiel ein*e Problem Manager allein nicht mit allen anfallenden Aufgaben dieser Position befassen kann.

Die Rollen müssen in diesem Schritt noch nicht direkt in allen Einzelheiten festgelegt werden. Das geschieht implizit im Zuge der Detaildefinition der Prozesse in späteren Projektphasen.

Jeder ITIL^®-Neueinführung und Prozess-Reorganisation sollte eine Analyse der aktuellen Situation vorausgehen. So können Sie leichter entscheiden, bei welchen Prozessen dringender Handlungsbedarf besteht und welche gegebenenfalls beibehalten werden können. Dadurch lässt sich oft Zeit sparen.
Allerdings sollen für die Analyse nicht sämtliche Prozesse bis in alle Einzelheiten erhoben und dokumentiert werden, da dieser Aufwand meistens nicht in sinnvollem Verhältnis zum Ergebnis steht.

Ein ITIL^® Self Assessment erfolgt in der Regel in Form strukturierter Interviews mit dem IT-Management und ausgewählten fachlichen Verantwortlichen. Dabei führen die Interviewer*innen die Befragten durch den Fragebogen und helfen bei Bedarf mit Hintergrundinformationen zu bestimmten Fragen.

Die anschließende Auswertung umfasst die Punkte:

• Erreichter Reifegrad in den einzelnen ITIL^®-Disziplinen,
• Abweichungen in der Einschätzung der Prozesse durch einzelne Interviewpartner*innen,
• Schwachstellen in den derzeitigen Prozessen, einschließlich der zugrunde liegenden Ursachen sowie die Chancen.

Dieser Schritt baut auf den Ergebnissen der Ist-Analyse aus Schritt 4 auf und dient dazu, die Ziel-Prozess-Struktur festzulegen.

Zunächst sollten Sie eine Liste der ITIL^®-Prozesse und Sub-Prozesse erstellen, die es einzuführen oder zu verbessern gilt. Damit wird gleichzeitig festgelegt, wie die Prozess-Struktur inklusive deren Unterprozesse letzten Endes aussehen soll.

In der Regel leiten sich die neu einzuführenden ITIL^®-Prozesse direkt aus den spezifischen Zielen des Implementierungsprojektes ab.

Wenn beispielsweise der User-Support ausgebaut werden soll, muss das Incident Management implementiert oder verbessert werden. Aufgrund der engen Verknüpfung mit dem Incident Management sollten auch das Problem und das Configuration Management mit in den Projektumfang aufgenommen werden.

Genau diese Auswahl von ITIL^®-Prozessen steht in diesem Projektschritt im Vordergrund.
Die Soll-Prozess-Struktur enthält noch keine detaillierten Prozessbeschreibungen. Diese werden erst in einem späteren Schritt entwickelt.

In diesem Schritt wird festgelegt, welche Inputs die einzelnen ITIL^®-Prozesse von anderen erhalten und welche Outputs sie liefern müssen, damit Folgeprozesse funktionieren können.

Schwachstellen treten besonders häufig dort auf, wo ein Prozess endet und ein anderer beginnt. Wenn die für einen reibungslosen Ablauf notwendigen Informationen nicht wie vorgesehen ausgetauscht werden, äußert sich das oft durch Unterbrechungen im Datenfluss oder durch Systembrüche.

Deshalb muss die Definition der Schnittstellen noch vor dem Festlegen detaillierter Prozessabläufe als separater Schritt erfolgen.
Erst einmal muss feststehen, auf welchen Inputs aus den vorausgehenden Prozessen man aufbauen kann und welche Outputs für den Nachfolgeprozess notwendig sind, bevor man die eigentlichen Aktivitäten innerhalb eines ITIL^®-Prozesses festlegt.

Diese Bestimmung notwendiger Prozess-Schnittstellen baut auf der im vorhergehenden Projektschritt entwickelten Prozess-Struktur auf.

Eine besondere Herausforderung bei der Schnittstellendefinition stellt die Tatsache dar, dass normalerweis nicht alle ITIL^®-Prozesse auf einmal eingeführt werden. Das führt häufig dazu, dass einige der für einen Prozess benötigten Inputs noch nicht zur Verfügung stehen.
Zum Beispiel könnte die Praktik Datenschutz-Sicherheitsmanagement noch nicht explizit definiert sein, während der Service-Desk aber schon Inputs wie Sicherheitswarnungen (Security Alerts) benötigt.

Sobald die ITIL^®-Prozess-Strukturen festgelegt und die Schnittstellen definiert sind, kann das Prozess-Controlling eingerichtet werden. Erst wenn feststeht, welche Qualitätskriterien ein Prozess erfüllen muss, kann dessen Ablauf sinnvoll ausgestaltet werden.

Das Controlling legt geeignete Methoden fest, um sicherzustellen, dass die Prozesse die an sie gerichteten Erwartungen erfüllen. Ein gut durchdachtes Konzept dient hier nicht nur als Instrument zur Bewertung der Zielerreichung, es liefert auch langfristig notwendige Kennzahlen zur kontinuierlichen Verbesserung innerhalb des Service-Lifecycles.

Um entscheiden zu können, ob ein Prozess „gut läuft” oder nicht, müssen objektive Qualitätskriterien (sogenannte Key Performance Indicators, kurz KPIs) festgelegt werden.
Dafür müssen die übergreifenden Ziele des ITIL^®-Vorhabens feststehen – zum Beispiel eine möglichst hohe Erstlösungsquote im Service-Desk. Mit diesen Zielen vor Augen können Sie die für die Beurteilung einer erfolgreichen Prozessdurchführung geeigneten Kennzahlen bestimmen.

Welche KPIs schlussendlich gewählt werden, hängt unter anderem von den im Unternehmen verfügbaren Ermittlungsmöglichkeiten ab. Im Idealfall werden die Kennzahlen automatisch über ein Service-Desk-System errechnet. Die hier definierten Messverfahren stellen daher gleichzeitig auch Anforderungen an die zu implementierenden Systeme dar.

Generell gilt aber: mehr ist nicht immer besser. In der Praxis zeigt sich oft, dass eine zu komplexe Kennzahlen-Struktur einen unverhältnismäßig großen Aufwand nach sich zieht, wenig Akzeptanz findet und deshalb schon nach kurzer Zeit nicht mehr angewandt wird.
Stattdessen sollten Sie lieber einige wenige, dafür aber aussagekräftige Kennzahlen definieren, um den Ermittlungsaufwand und das Reporting in einem vertretbaren Rahmen zu halten.

Außerdem ist es empfehlenswert, in der Anfangsphase noch keine festen Zielwerte vorzugeben, sondern erst einmal geeignete Qualitätskennzahlen zu definieren und Messwerte zu ermitteln. Wenn dann nach einiger Zeit eine statistisch aussagefähige Anzahl an Messergebnissen vorliegt, können Zielwerte auf einer soliden Basis definiert werden.

Dieser Schritt legt fest, welche Aktivitäten innerhalb jedes Prozesses durchgeführt werden müssen und welche Checklisten und Leitlinien zur Unterstützung der Durchführung genutzt werden.

In der Regel werden die Prozessverantwortlichen mit dieser Aufgabe betraut, es sollten jedoch alle betroffenen Parteien einbezogen werden, insbesondere die Mitarbeiter*innen, die die Prozesse künftig ausführen. So stellen Sie sicher, dass das größtmögliche Maß an Erfahrung und Wissen in die Konzeption der Abläufe einfließt.

Prozessdesigns werden normalerweise als Flussdiagramme dokumentiert. So können Sie die erforderlichen Aktivitäten und deren Reihenfolge anschaulich darstellen, ohne zu sehr ins Detail zu gehen. Die Diagramme spezifizieren auch, welche Rollen für die Ausführung der Aktivitäten zuständig sind.

Um die Prozessdiagramme nicht zu überfrachten, sollten Sie zusätzliche Informationen zur Unterstützung der Prozessausführung als Checklisten und Dokumentvorlagen an die Diagramme anhängen.
Das könnten beispielsweise detaillierte Anweisungen für die Registrierung und Weiterleitung von Incidents und Service-Requests im 1st-Level-Support sein.

Nachdem das Prozessdesign abgeschlossen ist, kann die Implementierung beginnen.

Wenn eine neue oder geänderte technische Infrastruktur erforderlich ist, um die Prozesse zu unterstützen, wird diese jetzt beschafft und eingerichtet. Die einzelnen dazu nötigen Schritte hängen ganz von Ihrem Projekt und den dadurch implementierten Prozessen ab. Deshalb beschreibt das folgende Beispiel lediglich die Anforderungsdefinition von Anwendungssystemen.

Funktionale Anforderungen an die unterstützende Infrastruktur können oft aus dem Prozessdesign abgeleitet werden. Das Design definiert, welche Arbeitsschritte von den Anwendungen unterstützt werden müssen.

Die Definitionen der Prozess-Inputs und -Outputs beschreiben, welche Daten von den Systemen zu verarbeiten sind. Beispielsweise erzeugt der Incident-Management-Prozess Incident Records. Das System, das diesen Prozess unterstützt, muss deshalb in der Lage sein, solche Daten zu verwalten.
Zu guter Letzt müssen auch nicht-funktionale Anforderungen aufgenommen werden.

Daraus ergibt sich für den Anforderungskatalog folgende Struktur:

• Funktionale Anforderungen
  • Verweis auf die detaillierten Prozessmodelle
  • Zusätzliche Anforderungen an die Funktionalität
  • Definitionen der Prozess-Outputs (Datenstrukturen)
  • Funktionen des Berichtswesens
• Nicht-funktionale Anforderungen
  • Anforderungen bezüglich Kapazitäten und Mengen
  • Performanz und Durchsatz
  • Skalierbarkeit/Erweiterungsfähigkeit
  • Verfügbarkeit
• Anforderungen aus betrieblicher Sicht
  • Anforderungen aus Sicht der IT-Sicherheit
  • Schnittstellen zu anderen Systemen
  • Anhang
    • Prozessmodelle
    • Zu importierende Daten aus bereits bestehenden Systemen
       

Sobald der Katalog komplett ist, extrahieren Sie daraus eine nach Prioritäten geordnete Liste mit Einzelpunkten, die als Bewertungsmatrix zur Auswahl eines geeigneten (externen) Systems dient. Die Anforderungen sollten wie im folgenden Beispiel nach Kategorien geordnet sein:

• K.o.-Kriterien (Priorität 1)
• Wichtige Anforderungen (Priorität 2)
• Wünschenswerte Anforderungen (Priorität 3)

Wenn alle wesentlichen Parteien in die Gestaltung der Prozesse mit einbezogen wurden, sollten den verantwortlichen Mitarbeiter*innen die neuen Prozesse nicht weiter erläutert werden müssen.
Allerdings kann es notwendig sein, Ihr Team in der Nutzung neuer Anwendungssysteme zu schulen.
Zusätzlich müssen möglicherweise die Kunden informiert werden, wenn beispielsweise eine neue Supportgruppe im 1st-Level-Support eingerichtet wurde und sich deshalb die Prozedur für das Melden von Incidents geändert hat.

Abschließend gilt auch für die Zukunft:
Teilen Sie Änderungen in Prozessen unbedingt frühzeitig allen beteiligten Parteien mit. Werden Prozess-Beteiligte erst in der letzten Phase des eines ITIL^®-Projekts über neuen Prozessabläufe informiert, ist mangelnde Akzeptanz vorprogrammiert. Daher sollten möglichst viele der später betroffenen Mitarbeiter*innen schon während der früheren Projektphasen an der Ausgestaltung der Prozesse beteiligt werden.

Diese Praktik befasst sich mit der Steuerung der in der Organisation verwendeten Technologien.

Die Praktik Software Development and Management gibt einen Überblick über die Aktivitäten von Software-Entwicklung und ‑Management