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 die Durchführung von IT-Projekten, insbesondere zur Entwicklung von Softwaresystemen. Heute gilt es als Gegenpol zu Methoden agiler Softwareentwicklung. Das V-Modell XT definiert den Projektverlauf vom Projektantrag bis zum Betrieb der entstandenen Systeme und Anwendungen (vgl. Roemer 2012).
CMMI steht für »Capability Maturity Model Integration« (siehe auch Abschnitt 2.3.5) und umfasst eine Familie von Referenz- bzw. Verbesserungsmodellen für unterschiedliche Anwendungsgebiete. Das primäre Ziel der CMMI-Modelle ist es, eine kontinuierliche Prozessverbesserung zu unterstützen. Über CMMI ist auch die Überprüfung eines Reifegrades möglich. In diesem Sinne kann CMMI auch als Reifegradmodell fungieren. Es gibt fünf verschiedene Reifegrade: CMM 1 (initial) als niedrigster, CMM 5 (optimiert) als Spitzenwert.
Six Sigma ist eine Methode des Qualitätsmanagements, die versucht, Produkte und Dienstleistungen möglichst fehlerfrei zu erstellen bzw. anzubieten. Die »Null-Fehler-Philosophie« im Unternehmen wird bei Anwendung dieses Konzepts konsequent verfolgt (vgl. Kaufmann 2012, Rehbehn/Yuedakuhl 2005).
PRINCE2 (PRojects IN a Controlled Environment) als eine Methode für strukturiertes Projektmanagement stammt ebenso wie ITIL ursprünglich aus dem Hause der OGC und bietet ein vorgehens- und ergebnisorientiertes Phasenmodell. Die Prozesse von PRINCE2 decken den Projektverlauf von der Vorbereitung bis hin zum Projektabschluss ab.
Das COBIT Framework (Control OBjectives for Information and related Technologies) ist ein von der ISACA (Information Systems Audit and Control Association), dem internationalen Berufsverband der IT-Prüfer und -Prüferinnen, entwickeltes Modell für die IT-Governance (http://www.isaca.org/cobit). Es zielt auf eine effizientere und effektivere Steuerung (Governance) und das Management der IT ab, die stärker auf die Unterstützung der geschäftlichen Anforderungen eines Unternehmens hin ausgerichtet
