Basiswissen ITIL 4. Nadin Ebel
ist in ITIL 4 Bestandteil der sogenannten Service Management Practices.
Das Access Management der ITIL V3 ist nicht als Practice übernommen worden. Identity and Access Management wird als notwendiger Aspekt im Information Security Management angesehen. Access Requests stellen Service Requests dar und sind daher weiterhin berücksichtigt.
Das Release and Deployment Management wurde wieder aufgeteilt: Release Management (Service Management Practice) zum einen und Deployment Management (Technical Management Practice) zum anderen. Ähnliches gilt für das Service Asset and Configuration Management der ITLV3. Sie werden in zwei getrennten Practices der ITIL 4 berücksichtigt: IT Asset Management und Service Configuration Management (beides Service Management Practices).
Die Technical Management Practice Infrastructure and Platform Management erinnert an die ITIL-V3-Funktion Technical Management. Software Development and Management von ITIL 4 berücksichtigt Aspekte der ehemaligen Funktion Application Management.
Das Event Management der ITILV3 wurde in Monitoring and Event Management umgemünzt. So wird u.a. die explizite Identifikation des Monitorings erleichtert, die früher eher dem Availability-Management-Prozess zugeordnet war.
Der Service Desk wird in ITIL 4 als Practice geführt.
Das Thema der kontinuierlichen Verbesserung, der in der ITIL V3 eine explizite Lebenszyklusphase gewidmet war, wird in ITIL 4 an verschiedenen Stellen aufgegriffen. Ein Beispiel ist das ITIL Continual-Improvement-Modell, das aus ITIL V3 (7-Step-Improvement-Prozess als einziger Prozess der CSI-Phase) übernommen wurde.
Architecture Management wurde in ITIL V3 mehr oder (eher) minder explizit als Teil der übergreifenden Service-Design-Aktivitäten berücksichtigt und ist in ITIL 4 eine eigene Practice.
Measurement and Reporting ist in ITIL 4 eine eigene Practice. Die beiden Themen Service-Reporting sowie Messungen und Metriken wurden in ITILV3 in der CSI-Kernpublikation als CSI-Techniken beschrieben und explizit in der Practitioner-Veröffentlichung berücksichtigt.
Zum Thema Project Management gab es in den bisherigen Versionen nur Verweise auf Projektmanagement-Methoden wie bspw. PMBOK oder PRINCE2. Project Management ist nun eine eigene Practice in ITIL 4.
Das Risk Management ist in ITIL 4 eine explizite Practice als Teil der General Management Practices geworden. In ITIL V3 wurde das Thema Risikomanagement als Teil des IT Service Continuity Management, Security Management oder Availability Management gesehen. Vor allem in der Service-Design-Phase wurde die Etablierung und Anwendung des Risikomanagements gefordert, um Risiken zu minimieren oder zu eliminieren, bevor der neue oder geänderte Service in die Produktivumgebung ausgebracht wird.
Workforce and Talent Management ist ebenfalls eine neue explizite Practice. Dem Mitarbeiter-Thema wurde v.a. als Teil des People-Aspektes im Service-Design – dem allgemeinen Zusammenwirken von Menschen, Prozessen und Technologien – und im Kapitel zu den organisatorischen Aspekten der jeweiligen ITIL-V3-Kernpublikation Raum geschenkt.
Die neue Practice Business Analysis beinhaltet Aspekte eines Anforderungsmanagements. Einzelne Gesichtspunkte kommen aus dem Demand Management, das nicht mehr unter diesem Namen als Practice in ITIL 4 auftaucht.
Exkurs
ITIL stand als Abkürzung für IT Infrastructure Library und wurde in diesem eher technischen Kontext gesehen. Bereits vor der ITILV3 schien der »Infrastruktur«-Anteil im Namen überholt, da andere Aspekte einen weitaus größeren Stellenwert von ITIL ausmachen als die technische Sichtweise. Seit ITIL 4 wird ITIL nur noch als Eigenname von Axelos, dem Lizenzgeber von ITIL, verwendet.
2.2Frameworks und Best Practices als ITIL-Inhalte
IT Service Provider setzen sich mit einer Vielzahl von Disziplinen, Methoden, Entwicklungen und Standards auseinander, die auch ITIL aufgegriffen und dort, wo sich ihre Anwendung bewährte, an geeigneter Stelle als eigene Best-Practice-Inhalte integriert hat (siehe Abb. 2–12). Beispiele für solche Elemente sind:
Die ISO/IEC 20000 ist ein internationaler Standard für das IT Service Management und für alle Unternehmen geeignet, die IT Services für interne und/oder externe Kunden erbringen. Im Rahmen eines Audits der Norm ISO/IEC 20000 muss die IT-Organisation nachweisen, dass sie die Kontrolle über alle IT-Service-Management-Prozesse im Fokus der Norm über ein Service-Management-System ausübt.
Im Fokus von Lean Management als Ansatz zur Prozessoptimierung steht die Vermeidung von Verschwendung. Sie gilt es in den Prozessen der Organisation zu erkennen und zu eliminieren, um eine effiziente Gestaltung der gesamten Wertschöpfungskette zu realisieren (vgl. Gorecki/Pautsch 2013).
Kanban stammt aus der Produktionsprozesssteuerung und wird heute im Projektmanagement eingesetzt. Der Begriff »Kann-ban« kommt aus dem Japanischen und bedeutet »Signalkarte«. Diese Karten werden in der Fertigung genutzt, um Produktionsschritte bzw. Arbeitseinheiten zu kennzeichnen. Die Karten dienen als Signal, um dem vorgelagerten Schritt mitzuteilen, dass er starten und den nachfolgenden Schritt bedienen soll. David Anderson gilt als Begründer von Kanban, die laut seiner Beschreibung eine Methode ist, mit der sich evolutionäre, inkrementelle Prozessverbesserungen durchführen lassen.
DevOps setzt als organisatorischer Ansatz auf eine gemeinsame, ganzheitliche Ergebnisverantwortung von Anwendungsentwicklung und IT-Betrieb mit schnelleren Release-Zyklen, hoher Produktqualität und weitestgehend agil handelnden Teams. Der Begriff setzt sich aus »Dev« für Anwendungsentwicklung (Development) und »Ops« für IT-Betrieb (Operations) zusammen. Anwendungsentwicklung und IT-Betrieb rücken zusammen und werden ein Team. Ziel ist es, dass die neue Organisationsform Software schneller und fehlerfreier entwickeln, bereitstellen sowie besser betreiben kann. Neben den organisatorischen Themen und der notwendigen organisatorischen Veränderung spielen auch Automatisierung, Tools und Aspekte aus Lean und Agile eine wichtige Rolle.Der Begriff wurde erstmalig 2009 auf den DevOpsDays zum Thema agile Methoden in Gent genutzt. Patrick Debois hielt einen Vortrag über die Anforderungen bei agilen Methoden und der sich verändernden Zusammenarbeit zwischen Entwicklern, IT-Experten, Business und dem Betrieb.
Ein gemeinsames Verständnis für Begriffe wie Agile oder Agilität existiert weder in Wissenschaft noch Praxis, auch wenn Agilität in aller Munde ist (vgl. Wendler 2013). Es existiert ein bunter Strauß von unterschiedlichen Ansätzen und Konzepten zur Agilität. Diese können sich auf unterschiedliche Ebenen einer Organisation beziehen, bspw. Agile Manufacturing (agile Fertigung), agile Softwareentwicklung, Agile Organization und Agile Workforce (agile Belegschaft). Agile wird außerdem oft als Sammelbegriff für verschiedene Ansätze und Vorgehensweisen genutzt wie Lean, Management 3.0, DevOps oder Design Thinking. Ausgangspunkte für die Einführung agiler Methoden in Unternehmen sind häufig die Methodik des agilen Projektmanagements sowie auch die Methoden und Prozesse agiler Softwareentwicklung. Dabei geht es um Flexibilität, Anpassungsfähigkeit und schnelle Entwicklung in kurzen iterativen Zyklen. Ziel der agilen Softwareentwicklung ist es, schon frühzeitig ausführbare Software(-bestandteile) zu liefern, schnelles und regelmäßiges Feedback vom Kunden zu erhalten und dieses in die nachfolgenden Entwicklungsschritte einfließen zu lassen. Grundlage agiler Methoden wie Scrum, Extreme Programming (XP) oder Feature Driven Development (FDD) sind die Leitsätze des Agilen Manifests (siehe https://agilemanifesto.org/iso/de/manifesto.html).Ein wichtiger Grundgedanke ist die Annahme, dass sich ein Softwareprojekt vor Projektbeginn nicht bis in alle Detailanforderungen beschreiben lässt und dass eine Kundenorientierung mit Feedback notwendig ist. Dies steht in deutlichem Gegensatz zu klassischen Projektmanagement- bzw. Softwareentwicklungsansätzen wie dem Wasserfall-Modell.
Das V-Modell, ursprünglich im militärischen Umfeld entstanden, hat mit der aktuellen Weiterentwicklung V-Modell XT Einzug in den öffentlichen Bereich gehalten. Es beschreibt ein Vorgehensmodell für