Entwicklung eines Vorgehensmodells für agiles Application Lifecycle Management nach ITIL


Diplomarbeit, 2011

87 Seiten


Leseprobe


Inhaltsverzeichnis

Abbildungsverzeichnis

Abkürzungsverzeichnis

Anlagenverzeichnis

1. Einleitung
1.1 Motivation
1.2 Problemstellung und Zielsetzung der Arbeit
1.3 Aufbau der Arbeit

2. Einführung in die IT Infrastructure Library
2.1 Herkunft und Entwicklung
2.2 Zielsetzung der ITIL
2.3 Aufbau und Inhalte der ITIL V3
2.3.1 Einführung in das ITSM Lifecycle Modell der ITIL V3
2.3.2 Die Phase Service Strategie
2.3.3 Die Phase Service Design
2.3.4 Die Phase Service Transition
2.3.5 Die Phase Service Operation
2.3.6 Die Phase Continual Service Improvement
2.4 Einführung in das Application Lifecycle Management
2.5 Herausforderungen an das ALM nach ITIL V3

3. Agile Vorgehensmodelle
3.1 Einführung und bisherige Entwicklung
3.2 Die agilen Grundprinzipien
3.3 Vorstellung agiler Vorgehensweisen
3.3.1 Kanban
3.3.2 Scrum
3.3.3 Agile Managementmethoden
3.4 Vor- und Nachteile agiler Methoden
3.5 Auswirkungen auf das ALM

4. Entwicklung eines agilen Application Lifecycle Management
4.1 Anforderungen an ein agiles Application Lifecycle Management
4.2 Agile Grundprinzipen als Basis des aAML
4.3 Beschreibung des agilen Application Management Lifecycle
4.3.1 Grafische Darstellung des Modells
4.3.2 Ausrichtung auf den Kunden
4.3.3 Einführung eines Kanban
4.3.4 Teamarbeit und Selbstorganisation
4.3.5 Knowledgemanagement als zentraler Prozess
4.3.6 Integration der Optimierung
4.3.7 Synchronisation der Abläufe und Timeboxing

5. Beschreibung der Prozesse des aAML
5.1 Der Prozess ,Requirement'
5.1.1 Zielsetzung des Prozess
5.1.2 Grafische Darstellung
5.1.3 Input, Aktivitäten, Output
5.2 Der Prozess ,Design'
5.2.1 Zielsetzung des Prozess
5.2.2 Grafische Darstellung
5.2.3 Input, Aktivitäten, Output
5.3 Der Prozess,Build & Test'
5.3.1 Zielsetzung des Prozess
5.3.2 Grafische Darstellung
5.3.3 Input, Aktivitäten, Output
5.4 Der Prozess ,Deploy'
5.4.1 Zielsetzung des Prozess
5.4.2 Grafische Darstellung
5.4.3 Input, Aktivitäten, Output
5.5 Der Prozess ,Operate'
5.5.1 Zielsetzung des Prozess
5.5.2 Grafische Darstellung
5.5.3 Input, Aktivitäten, Output

6. Fazit und Ausblick
6.1 Erreichte Ziele
6.2 Notwendige Weiterentwicklungen des Modells
6.3 Fazit

Literaturverzeichnis

Anlagen

Abbildungsverzeichnis

Abb. 1: ITSM Lifecycle nach ITILV3 - Quelle: Taylor 2007a.

Abb. 2: Deming Cycle - Quelle: Bulsuk 2009.

Abb. 3 Application Lifecycle Management

Abb. 4: Scrum im Überblick

Abb. 5: Management 3.0 - Quelle: Appelo 2011:13.

Abb. 6: agilerApplication Management Lifecyle

Abb. 7: Story-Card - Quelle: Eigene Erstellung.

Abb. 8: Kanban-Board - Quelle: Eigene Erstellung.

Abb. 9: Aufgaben-Karte

Abb. 10: The 7-Step Improvement Process

Abb. 11: Prozessdarstellung Requirement

Abb. 12: Prozessdarstellung Design

Abb. 13: Prozessdarstellung Build & Test

Abb. 14: Prozessdarstellung Deploy

Abb. 15: Prozessdarstellung Operate

Abb 16: Verwendete BPMN 2.0 Symbole

Abbildung in dieser Leseprobe nicht enthalten

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Anlagenverzeichnis

Anlage 1: Prinzipien hinter dem Agilen Manifest

Anlage 2: Erklärung der verwendeten Symbole der BPMN 2.0

1.Einleitung

1.1 Motivation

Wie die industrielle Revolution weitreichende Auswirkungen auf das produzierende Gewerbe hatte, so hat auch die Industrialisierung der IT weitreichende Folgen auf diese Branche. Die Leistungsbereitstellung in der Informationstechnologie wandelt sich immer weiter von der zur Verfügungstellung technischer Produkte hin zu einer umfassenden Dienstleistungserbringung (vgl. Zarnekow 2007: 11f.). Darüber hinaus ergibt sich ein massives Spannungsfeld zwischen immer höher werdendem Kosten- bzw. Zeitdruck und weiter steigenden Ansprüchen an die Qualität der Dienstleistung.

Diese Anforderungen beanspruchen eine größere Flexibilität von Prozessen und eine Ausweitung des Blickwinkels aller Unternehmenseinheiten auf die Kundenbedürfnisse (vgl. Bernhard et al. 2003: 318).

Die hierfür erforderliche effiziente und effektive Erbringung von IT- Services stellt viele IT-Abteilungen vor große Herausforderungen. Eine der wichtigsten Voraussetzungen, um diese zu meistern, ist eine konsequente Standardisierung der Leistungserbringung. Hier liegt nach wie vor ein großes Optimierungs-und damit Kosteneinsparungspotential (vgl. Linnartz 2004: 26).

Für die Informations- und Telekommunikationsbranche stellt die IT Infrastructure Library (ITIL) den am weit verbreitetsten Best-Practice Ansatz dar, um diese Anforderungen umzusetzen (vgl. Ebel 2008: 35f.).

„Service Management seeks to align IT with the business, a fancy way of saying they give the business what it needs not what IT wants to give it" (England 2009: 6). ITIL liefert eine Sammlung von Modellen, Prozessen sowie Vorschläge für die Aufbauorganisation und mögliche Werkzeuge, um eine qualitativ hochwertige Bereitstellung von IT-Services zu ermöglichen (vgl. Beims 2010: 15). Eines der in ITIL

beschriebenen Vorgehensmodelle ist der Application Management Lifecycle (AML) und die dazugehörige Aufgabe des Application Lifecycle Managements (ALM) (vgl. Taylor et al. 2007a: 132f.). Es beschreibt sowohl die Konzeptionierung und Softwareentwicklung mit den Phasen ,Requirement', ,Design' und ,Build & Test' als auch den sich daran anschließenden IT-Betrieb in den Phasen ,Deploy', ,Operate' und ,Optimize' und bildet damit alle Phasen der IT-Leistungserbringung ab (vgl. Taylor et al. 2007a: 132f.).

Durch diesen integrativen Ansatz forciert das Modell eine stärkere Verzahnung dieser beiden, bisher stark getrennt betrachteten Aufgabenbereiche und weitet den Blick auf eine durchgängige Leistungsbereitstellung von IT-Services.

Besonders im Rahmen der Softwareentwicklung und im IT-Projektmanagement finden vermehrt agile Ansätze Anwendung. Diese Methoden konzentrieren sich vor allem auf die Kundenbedürfnisse und auf die für deren Befriedigung notwendigen Personen. Sie berücksichtigen Änderungswünsche des Kunden auch noch in späten Realisierungs​phasen und maximieren so den Nutzen des Endprodukts (vgl. Meyer et al. 2007: 307f). Die hauptsächlich in der Automobilindustrie im Rahmen der Lean Production entwickelten und erprobten Handlungsweisen werden hier auf die IT- Leistungserbringung übertragen. Der Grundstein für die Anwendung agiler Modelle in der IT wurde 2001 im Agilen Manifest gelegt, das in diesem Jahr seinen zehnten Geburtstag feiert (vgl. heise Developer 2011).

1.2 Problemstellung und Zielsetzung der Arbeit

Der Satz „Ohne Geschäftsprozess gibt es keinen IT-Prozess, ohne IT-Prozess kann kein Geschäft generiert werden" (Beims 2010: 18) macht die Abhängigkeit eines Unternehmens von der IT-Dienstleistung deutlich. Die IT ist ein wesentlicher Erfolgsfaktor für das Kundengeschäft, wobei die Leistung nicht mehr nur innerhalb des eigenen Unternehmens erbracht wird, sondern vermehrt externe IT-Dienstleister genutzt werden. Diese Servicedienstleister stehen vor der großen Herausforderung, immer schneller auf neue Unternehmensbedürfnisse zu reagieren. Besonders für den IT- Betrieb entsteht hieraus die Schwierigkeit, trotz der ständigen Veränderungen, eine stabile Leistungserbringung im Rahmen der vereinbarten Servicelevel zu gewährleisten (vgl. Feidicker et al. 2005: 199f.). Die Best-Practices zur Sicherstellung eines stabilen IT- Betriebs und einer qualitativ hochwertigen Leistungserbringung sind im Rahmen der ITIL beschrieben (vgl. Wischki 2009: 3). Dieser Fokus auf hohe Stabilität und Verfügbarkeit kann den Wunsch des Kunden nach schnellen Anpassungsmöglichkeiten eines IT- Services an neue Anforderungen nicht mehr ausreichend abdecken (vgl. Walter 2009: 7f.). Auch der IT-Betrieb muss zukünftig flexibler und schneller auf neue Anforderungen reagieren können. Besonders die technischen Weiterentwicklungen wie Virtualisierung, Cloud-Computing und Serviceorientierte Architekturen erfordern einen neuen Ansatz für die IT-Leistungserbringung. Es gilt ein Dienstleistungsverständnis zu schaffen, in dem zum einen die eigene Leistungserbringung mit externen Dienstleistungen kombiniert und darüber hinaus die Produktentwicklung und der IT-Betrieb als je ein Teil desselben Prozesses verstanden werden. Die beiden Bereiche dürfen nicht mehr als einzelne Silos gesehen werden, sondern müssen übergreifend zusammenarbeiten.

Dies fordert ein einheitliches und durchgängiges Managementmodell über den gesamten Lebenszyklus eines IT-Services. Bisher werden hier grundverschiedene Ansätze verfolgt. So wird in der Softwareentwicklung primär auf Methoden des Projektmanagements wie z.B. Prince2 oder PMI zurück gegriffen, während im IT-Betrieb vor allem die Ansätze des IT-Servicemanagements nach ITIL zum Tragen kommen (vgl. Madhukar et al. 2011: 167ff.). Das Modell muss darüber hinaus in der Lage sein, auf die immer kürzeren Time-to-Market Zeiten und die deshalb immer häufiger vom Kunden eingebrachten Änderungswünsche zu reagieren. Die klassischen, eher starren Instrumente sind deshalb wesentlich beweglicher zu gestalten. Im Umfeld der Softwareentwicklung wurde bereits vor längerer Zeit auf diese Herausforderungen reagiert und entsprechende Ansätze der sogenannten agilen Softwareentwicklung entwickelt. Basierend auf dem agilen Manifest entstanden so umfassende agile Methoden, die eine dynamische und kundenorientierte Softwareentwicklung ermöglichen (vgl. Schatten et al. 2010: 62). Für den Bereich des IT-Servicemanagements, dessen Kernaufgabe der stabile Betrieb von IT-Services ist, stehen bisher noch keine agilen Vorgehensweisen zur Verfügung. Darüber hinaus sind die Ansätze der agilen Softwareentwicklung mit den Ansätzen der ITIL bisher nicht abgestimmt.

Ziel dieser Arbeit ist die Entwicklung eines auf ITIL basierenden Vorgehensmodels für agiles Application Lifecycle Management (aALM). In diesem Modell sollen die Phasen des AML nach ITIL um agile Methoden erweitert und so eine Kombination agiler und klassischer Ansätze ermöglicht werden. Hierfür wird auf die in der Softwareentwicklung bereits erprobten Vorgehensweisen Kanban, Scrum und auf das agile Projektmanagement zurückgegriffen. Diese Methoden werden analysiert und für die Nutzung im Rahmen des IT-Servicemanagements adaptiert. Final entsteht so das Modell eines agilen Application Management Lifecycle (aAML).

1.3 Aufbau der Arbeit

Zu Beginn dieser Arbeit wird die ITIL vorgestellt. Hierzu werden zunächst die Herkunft und die bisherige Entwicklung dieser Büchersammlung erläutert. Die darauf folgende Beschreibung der Zielsetzung der ITIL erleichtert das Verständnis für die aktuelle Version 3 (ITIL V3), die sich an einem sog. IT-Servicemanagement Lifecycle (ITSM Lifecycle) ausrichtet. Die Bereitstellung eines IT-Services erfolgt nach ITIL innerhalb der fünf Phasen Service Strategie, Service Design, Service Transition, Service Operation und Continual Service Improvement. Diese einzelnen Phasen werden anschließend detailliert beschrieben. Aus Sicht der ITIL besteht ein Businessservice vor allem aus einem eher technischen IT-Service. Dieser wiederum setzt sich aus einzelnen Komponenten und Applikationen und aus der zugehörigen Dienstleistung zusammen (vgl. Taylor et al. 2007a: 132). Da der IT-Service ein sehr wichtiger Teil des Gesamtservices ist, wird hierfür eigens ein spezifisches Managementmodell, der Application Management Lifecycle (AML) definiert (vgl. Taylor et al. 2007a: 130f.). Dieses Modell sowie der Begriff, die Aufgaben und die Zielsetzung der für die Umsetzung des AML zuständigen Rolle Application Lifecycle Management (ALM) werden anschließend erläutert. Hierbei werden die unterschiedlichen Definitionen des Begriffs, die sich teilweise erheblich von der Definition nach ITIL unterscheiden, gegenüber gestellt und der Umfang des Aufgabengebiets des ALM neu definiert. So entsteht eine genaue Vorstellung, welche Anforderungen und Aufgaben sowohl ITIL als auch der Kunde an das ALM stellen. Dies dient im weiteren Verlauf der Arbeit als Basis für die Ableitung der Zielsetzung und Aktivitäten in den einzelnen Teilprozessen des AML, die durch das agile Vorgehensmodell zu unterstützen sind. Um darüber hinaus auch die kritischen und bisher nicht zur Zufriedenheit gelösten Problematiken der ITIL im aAML zu berücksichtigen, werden diese zum Abschluss des Kapitels anhand der Literatur analysiert.

Anschließend führt der Autor in die bestehenden agilen Methoden ein. Hierzu sind zunächst Herkunft und Entstehung dieser Methoden sowie die geschichtliche Verbindung zu den von Toyota entwickelten Ansätzen der Lean-Production zu erläutern. Daraus wurden im Jahr 2001 erstmalig agile Grundprinzipien für die Softwareentwicklung definiert und im agilen Manifest schriftlich fixiert. Auf dieser Basis entwickelten sich im weiteren Verlauf eine große Zahl verschiedener Methoden der agilen Softwareentwicklung. Für diese Arbeit wurden diejenigen Methoden ausgewählt, die aus Sicht des Autors am besten für die Entwicklung des aAML adaptiert werden können. Diese sind Kanban, Scrum und agile (Projekt-)Managementmethoden, die im folgenden erläutert werden. Anschließend werden die Vorteile agiler Ansätze und vor allem ihr Nutzen zur Lösung der in Kapitel 1.1 geschilderten Problemstellungen für die IT-Leistungserbringung erläutert. Das Kapitel schließt mit einer Analyse der Nachteile agiler Methoden, die im weiteren Verlauf als Optimierungspotential in die Entwicklung des aAML eingehen.

Kapitel 2 definiert die Anforderungen, die an ein umfassendes ALM gestellt werden. Das dritte Kapitel liefert mögliche Werkzeuge, um diesen Anforderungen gerecht werden zu können. In Kapitel 4 wird auf Basis dieser beiden Bausteine ein Modell für ein aALM entwickelt. Hier wird zunächst das bisher auf die agile Softwareentwicklung ausgerichtete agile Manifest auf die vollständige IT-Leistungserbringung erweitert. Anschließend wird der AML nach ITIL umgestellt und erweitert, um ihn für den Einsatz agiler Werkzeuge nutzbar zu machen. Hierbei wird dieser in seiner Struktur erhalten; er wird allerdings auf Basis der agilen Grundannahmen neu ausgerichtet. Darüber hinaus wird der wesentliche und bisher nicht ausreichend berücksichtigte zentrale Prozess Knowledge Management ergänzt. Um das Gesamtverständnis zu erleichtern, wird der aAML grafisch dargestellt. In Kapitel 4.3 werden die zentralen Optimierungen des Modells sowie die daraus folgenden operativen Veränderungen beschrieben.

In Kapitel 5 werden die einzelnen Prozesse des aAML detailliert aufgezeigt. Für jede der Teilprozesse ,Requirement', ,Design', ,Build & Test', ,Deploy' und ,Operate' wird ihre jeweilige Zielstellung erarbeitet und die einzelnen Aktivitäten grafisch dargestellt. Es wird die Umsetzung der Phase mit agilen Methoden sowie die Inputs und Outputs jedes Prozesses erläutert und die Aufgaben, die innerhalb der einzelnen Teilprozessen zu erledigen sind, spezifiziert und den verantwortlichen Rollen zugeordnet. Final liefert die Arbeit eine Beurteilung des Autors, wie ein agiles Application Lifecycle Management umgesetzt werden kann. Darüber hinaus werden weitere Anknüpfungspunkte für eine detailliertere Betrachtung dieses sehr weitreichenden Themenkomplexes erläutert, die im Rahmen dieser Arbeit nicht berücksichtigt werden konnten. Als Fazit nennt der Autor seine Einschätzung zum Modell des aALM.

2 Einführung in die IT Infrastructure Library

2.1 Herkunft und Entwicklung

Die ITIL wurde erstmals Ende der achtziger Jahre erarbeitet und wird seither kontinuierlich weiterentwickelt und gepflegt. Ursprüngliches Ziel war die Verbesserung der Erbringung öffentlicher Dienstleistungen der britischen Regierung, auf Basis einer service- und qualitätsorientierten Nutzung der IT (vgl. Beims 2010: 23). Mittlerweile wird die ITIL vom Office of Government Commerce (OGC) weiterentwickelt, das ihre Stellung wie folgt beschreibt: „The IT Infrastructure Library® (ITIL) is the most widely accepted approach to IT service management in the world. ITIL is a cohesive best practice framework, drawn from the public and private sectors internationally. It describes the organization of IT resources to deliver business value, and document processes, functions and roles in IT Service Management (ITSM)" (OGC: 2011).

Während die Version 1 in der Praxis fast keine Anwendung fand, legte die OGC in der Version 2 (ITIL V2) den Schwerpunkt auf die Praxisrelevanz der Inhalte und entwickelte so einen Best-Practice-Ansatz.

Besonders die Bücher ,Service Support' und ,Service Delivery' sind mittlerweile als de-facto Standard in vielen Unternehmen etabliert (vgl. Wischki 2009: 4). Der wesentliche Mehrwert, den ITIL liefert, ist die Einführung eines einheitlichen Sprachschatzes, der ein unternehmensübergreifendes Vokabular fest definiert und so ein einheitliches Verständnis verschiedener IT-Leistungserbringer möglich macht.

Darüber hinaus ermöglicht ITIL die Messbarkeit der Prozessergebnisse und somit eine Qualitätssicherung und Verbesserung sowohl der internen Leistungserbringungsprozesse als auch der bereitgestellten Services (vgl. Wischki 2009: 6). Die Fokussierung weg von der technischen Lösung hin zu den Anforderungen des Kunden sorgt für eine bessere Unterstützung der Geschäftsprozesse des Kunden und somit auch für dessen Nutzensteigerung. Allerdings wurden in der ITIL V2 mit der Wartung, der Überführung in den laufenden Betrieb und dem End-of-Life von IT-Services drei wesentliche Teile der IT-Leistungserbringung nicht ausreichend berücksichtigt (vgl. Wischki 2009: 3ff.). Diese wurden bei der Weiterentwicklung der im Frühsommer 2007 erschienenen ITIL Version 3 (ITIL V3) ergänzt, während zu ca. 60% die Inhalte der ITIL V2 übernommen wurden (vgl. Beims 2010: 87).

2.2 Zielsetzung der ITIL

„Das Ziel von ITIL ist, Ansätze, Methoden und Architekturen (Prozesse) für den Betrieb und für die Betreuung der zu liefernden IT-Services [...] anzubieten und damit eine optimierte, serviceorientierte und qualitätsgesicherte IT-Service-Struktur zu ermöglichen" (Wischki 2009: 3). Hierzu definiert sie Leitlinien zur Planung und Erbringung von IT-Services, die allerdings nicht 1-zu-1 in jede Organisation übernommen werden können, sondern eher als Vorlagen verstanden werden müssen. Auf Basis dieser Muster kann eine IT-Organisation ihre eigenen Prozesse ableiten und ein auf ihre Bedürfnisse zugeschnittenes Modell der IT-Leistungserbringung entwickeln. Durch die Standardisierung der Prozesse soll hierbei eine gleichbleibend hohe Qualität des bereitgestellten IT-Services sichergestellt werden (vgl. Beims 2010: 20). Grundsätzlich beschreibt die ITIL, was hierzu getan werden muss, sie beschreibt jedoch nicht, wie diese Prozesse im eigenen Unternehmen genau zu gestaltet sind (vgl. Beims 2010: 23f.). Dies wird vor allem in der ITIL V3 deutlich, da sich „die Detailtiefe der Prozessbeschreibungen [..] sich mit der Weiterentwicklung zur ITIL V3 um bis zu zwei Drittel verringert [hat]" (Beims 2010: 87). Die Aufgabe einer ITIL-Einführung liegt darin, den theoretischen und allgemeinen Ansatz der ITIL in ein konkretes Umsetzungsmodell für das jeweilige Unternehmen zu transformieren (vgl. England 2009: 85).

Fokussiert wird in der ITIL nicht die Technologie, sondern der Nutzen, den diese dem Kunden durch die Unterstützung seines Businessprozesses mit einem IT-Service stiftet. Die ITIL definiert den Begriff 'Service' wie folgt: „A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks" (Taylor et al. 2007b: 309). Hier liegt die große Herausforderung, da die oft von einem technologisch geprägtem Blick geleitete IT- Abteilung hin zu einem Servicedienstleister entwickelt werden muss, was eine weitere Hauptaufgabe bei einer Einführung von ITIL darstellt. „Service Management is about turning the IT department around 90 so they look outwards at the services they provide to the business instead of looking in at the layers of their technology" (England 2009: 31). Dies erfordert vor allem ein Umdenken der Mitarbeiter. „It is the change of mindset to a service orientation. It is changing people" (England 2009: 105).

2.3 Aufbau und Inhalte der ITIL V3

2.3.1 Einführung in das ITSM Lifecycle Modell der ITIL V3

Der wesentliche Unterschied im Aufbau der ITIL V3 zur ITIL V2 besteht darin, dass die Prozesse nun in einem neuen Prozessmodell gegliedert sind, das die Lebenszyklusphasen von IT-Services abbildet (vgl.Beims 2010: 87). Dieses beinhaltet die Phasen Service Strategie, Service Design, Service Transition, Service Operation und Continual Service Improvement (vgl. Taylor et al. 2007a: 14). Im Folgenden sind die Phasen grafisch dagestellt:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1: ITSM Lifecycle nach ITILV3 - Quelle: Taylor 2007a.

Der ITSM Lifecycle beschreibt die Beziehung der einzelnen Phasen und der zugehörigen Prozesse zueinander. Die einzelnen Prozesse, die für eine IT-Leistungserbringung aus Sicht der ITIL relevant sind, werden jeweils zu der Phase zugeordnet, in der sie die meiste Anwendung finden. Ziel dieser Ausrichtung ist es, eine größere Dynamik und Flexibilität der Services zu ermöglichen um damit höhere Mehrwerte für den Kunden liefern zu können (vgl. Kresse et al. 2011: 68f.). Selbstoptimierende Prozesse werden ebenfalls erst durch die Implementierung eines Lifecycle ermöglicht (vgl. Beims 2010: 18f.). Im Folgenden werden die einzelnen Phasen und zugehörigen Prozesse näher erläutert.

2.3.2 Die Phase Service Strategie

Die in Abb. 1 gezeigte Anordnung der einzelnen Phasen kann als Rad interpretiert werden. Die Phase Service Strategie hat hierbei einen zentralen Charakter, der für die Festlegung strategischer Vorgaben und Ziele verantwortlich und somit für die restlichen Phasen wegweisend ist. „Service Strategy is the axis around which the lifecycle rotates" (Iqbal etal. 2007: 24).

Im Mittelpunkt steht die Feststellung, dass der Kunde keine Services kauft, sondern eigentlich die Erfüllung seiner Bedürfnisse wünscht. Deshalb ist es sehr wichtig, die Kundenerwartungen genau zu ergründen, um eine hohe Kundenzufriedenheit und langfristige Bindung zu ermöglichen. Darüber entscheidet letztendlich ausschließlich die persönliche Wahrnehmung des Kunden über den Nutzen, den ihm der Service bietet (vgl. Beims 2010: 36ff.). Die Zielsetzung dieser Phase ist eine übergreifende Betrachtung von Kunden, den Absatzmärkten, der Wertschöpfung, des Portfolios und die daraus folgende Entwicklung und Implementierung von Strategien über alle Phasen des IT- Servicemanagement hinweg (vgl. Iqbal et al. 2007: 65). Service Strategie stellt darüber hinaus die notwendigen Richtlinien und Grundlagenstrukturen für das Design, die Entwicklung und die Implementierung von Services bereit.

Diese Richtlinien beeinflussen alle Phasen des ITSM-Lifecycle. Entscheidungen, die im Rahmen der Service Strategie getroffen werden, haben weitreichende Auswirkungen auf das gesamte Unternehmen und die von ihm angebotenen Services (vgl. Iqbal et al. 2007: 8f.).

Bevor ein Unternehmen überhaupt Services am Markt etabliert, muss es zunächst im Rahmen des Prozess Service Portfolio Management definieren, welche Geschäftsprozesse des Kunden überhaupt unterstützt werden sollen. „A Service Portfolio describes a provider's services in terms of business value. It articulates business needs and the provider's response to those needs" (Iqbal et al. 2007: 119). Dies vermeidet die Verzettelung durch eine zu hohe Anzahl von angebotenen Services. „Grundsätzlich ist ein Unternehmen bemüht, die Services zur Verfügung zu stellen, die einen maximalen Ertrag bei einem akzeptablen Risiko erwirtschaften" (Iqbal et al. 2007: 120). Die letztendliche Entscheidung für oder gegen die Bereitstellung eines Services ist davon abhängig, ob die Investitionen im Verhältnis zum Risiko auf mittlere Sicht einen Gewinn erwarten lassen (vgl. Taylor et al. 2007a: 131). Ein Service liefert einen direkten Mehrwert für seinen Kunden. Er wird durch einen IT-Service technisch unterstützt. Im Unterschied zu einem Business Service stellt ein IT-Service eine Teilleistung bereit, die nur indirekt vom Kunden wahrgenommen wird (vgl. Iqbal et al. 2007: 120f.).

2.3.3 Die Phase Service Design

Nachdem im Rahmen der Service Strategie definiert ist, welche Services grundsätzlich angeboten werden, sind diese im Rahmen der Phase Service Design näher zu spezifizieren. „[...] [T]he design and planning activities are even more essential to the overall delivery of quality service" (Taylor et al. 2007b: 16). Hauptziel ist die detaillierte Spezifikation eines neuen oder geänderten Services, der am Markt positioniert werden soll. Die Services werden im sog. Servicekatalog beschrieben, der eine sehr wichtige Funktion wahrnimmt. „Service Catalogue drives your people. It is a key mechanism in cultural change, the foundation of customer" (England 2009: 91). Bei der Neu- und Weiterentwicklung eines spezifischen Services ist zu beachten, dass die Änderung eines Aspekts häufig umfassende Auswirkungen auf alle anderen Elemente des Services nach sich zieht. So müssen z.B. bei der Installation einer neuen Applikation auch die Auswirkungen auf bestehende Applikationen, Tools, Managementsysteme, Architekturen, Technologien, den Service Management Prozess und die Messmethode zu Ermittlung der Servicequalität berücksichtigt werden. Ein Blick ausschließlich auf die funktionalen bzw. technischen Elemente der Leistungserbringung ist bei weitem nicht ausreichend. Vielmehr ist eine End-to-End Sicht, ausgehend von den zu unterstützenden Geschäftsprozessen des Kunden, über den bereitgestellten Business Service hin zum unterstützenden IT-Service und dessen einzelnen Komponenten und den umliegenden Bereitstellungs- und Betriebsprozessen notwendig (vgl. Taylor et al. 2007b: 23).

„Die größte Herausforderung ist es, genau die Anforderungen des Kunden zu treffen, effektive Service Bereitstellung zu gewährleisten und die zukünftigen Entwicklungen und Änderungen im Kundenumfeld frühzeitig zu berücksichtigen, da eine spätere vollständige Neuentwicklung eines sich in Betrieb befindlichen Services quasi unmöglich ist" (Taylor et al. 2007b: 8). Aufgabe der Phase Service Design ist es, zunächst die Anforderungen an den benötigten Service zu ermitteln und diesen anschließend neu zu entwerfen oder die notwendigen Änderungen an bestehende Services zu beschreiben. Im Rahmen der Anforderungsanalyse muss geklärt werden, ob die bestehende IT- Infrastruktur den neuen oder veränderten Services gerecht werden kann. Darüber hinaus sind die sich aus der Änderung ergebenden Auswirkungen zu erörtern. In dieser Phase wird im Rahmen der Make-or-Buy Entscheidung festgelegt, ob die für die Serviceerbringung benötigten Teilleistungen intern selbst erbracht oder am Markt extern eingekauft werden (vgl. Beims 2010: 39ff.). Neben den fachlichen und qualitativen Anforderungen muss beim Design auch ein angemessener Grad an Sicherheit für die Informationen und Daten erreicht werden. Dieser ist von den Bedürfnissen des Kunden und von gesetzlichen Anforderungen abhängig (vgl. Kresse et al. 2011: 118). Auch die Berücksichtigung von Verbrauchsmuster ist in der Konzeptionierung wichtig, um Kapazitätsengpässe zu minimieren. Im Rahmen des Demand Managements wird deshalb versucht, sich auf die dynamischen Anforderung der Geschäftsprozesse und den sich daraus ergebenden variablen Kapazitäten einzustellen und die Gesamtauslastung zu optimieren. Dies wird häufig durch ein entsprechendes Preismodell unterstützt, das z.B. in lastschwachen Zeiten günstigere Konditionen ermöglicht (vgl. Iqbal et al. 2007: 90f.). Dieser Ansatz verbessert die Wertschöpfung durch eine bessere Auslastung der IT-Services, der hierfür notwendigen Applikationen und der darunter liegenden technischen Komponenten. Die Phase Service Design bildet die Grundlage für die in der Phase Service Transition durchgeführten Entwicklung, das Testen und die Implementierung eines neuen oder geänderten Services (vgl. Taylor et al. 2007b: 15).

2.3.4 Die Phase Service Transition

Die Phase Service Transition ist für die qualitätsgesicherte Überführung der in der Phase Service Strategie bestimmten und im Rahmen des Service Design detailliert spezifizierten Services in den laufenden Betrieb verantwortlich. Hierzu werden Standards vorgestellt, die das Risiko negativer Auswirkungen auf den Geschäftsprozess bei der Inbetriebnahme des Service soweit wie möglich minimieren (vgl. Lacy et al. 2007: 3ff.). Die wichtigsten beiden Herausforderung sind hierbei, zum einen sicherzustellen, dass mit der Neueinführung die Anforderungen des Kunden umfassend berücksichtigt wurden und somit eine hohe Kundenzufriedenheit erzielt wird und zum anderen bei bestehenden Services den laufenden Betrieb bei der Neueinführung nicht zu gefährden (vgl. Beims 2010: 42ff.).

Hierzu werden zunächst im Rahmen des Prozesses Transition Planning and Support auf Basis der im Rahmen des Service Design erstellten Spezifikation die notwendigen Ressourcen- und Kapazitätsplanungen für die Realisierung und Überführung des Services durchgeführt (vgl. Shirley et al. 2007: 35). Das Release Management verantwortet die Durchführung der Änderung bzw. die Bereitstellung des neuen Services. Der Prozess Service Validation und Testing überprüft, ob die vorgenommenen Änderungen oder der neue Service den Anforderungen des Kunden entspricht und die beabsichtigte Wirkung erbringt (vgl. Shirley et al. 2007: 115). Die Ergebnisse der Service Validation werden im Prozess Evaluation überprüft und Abweichungen bei neuen oder veränderten Services bewertet. Diese Bewertung liefert verlässliche Aussagen über die durchgeführten Änderungen und gibt Empfehlungen für das Change Management (vgl. Shirley et al. 2007: 138f.). Um einen ganzheitlichen Blick auf Änderungen an den IT-Services sicherzustellen und sowohl die technischen als auch die organisatorischen Aspekte bei der Bereitstellung bereichsübergreifend zu betrachten und zu beurteilen, hat das Change Management die Aufgabe, Veränderungsprozesse effektiv und effizient zu steuern. Darüber hinaus übernimmt es die abschließende Kontrolle der Implementierung, um festzustellen, ob die gewünschten Anforderungen erfüllt sind (vgl. Shirley et al. 2007: 42ff.). Auch der Prozess des Knowledge Managements wurde in der ITIL Version 3 als neuer, eigenständiger Prozess definiert. Dessen Ziel ist es, die Qualität der Managemententscheidungen durch die Bereitstellung verlässlicher Informationen und Daten zu verbessern.

Hierfür sind primär die Kenntnisse, Ideen und Fähigkeiten der eigenen Mitarbeiter relevant. Diese müssen dokumentiert werden, damit beim mehrmaligen Auftreten gleichartiger Fragestellungen die Lösung nicht mehrmals neu erarbeitet werden muss (vgl. Shirley et al. 2007: 145f.). Während das Knowledge Management das Wissen der Mitarbeiter sichert, ermöglicht der Prozess Service Asset and Configuration Management (in ITIL V2: Configuration Management) einen einheitlichen Überblick über die IT-Komponenten und deren Notwendigkeit für die Erbringung eines Services. Dieses Wissen über die genauen Zusammensetzungen sowie die Abhängigkeiten und Verbindungen der einzelnen IT-Komponenten ist einer der wichtigsten Erfolgsfaktoren für eine zuverlässige Serviceerbringung. Besonders die funktionalen Abhängigkeiten sind z.B. bei einer Störung oder bei einer Konfigurationsänderung wesentlich, um ungewollte Nebeneffekte oder Kettenreaktionen schnell erkennen bzw. bereits pro aktiv vermeiden zu können (vgl. Kresse etal. 2011: 140ff.).

2.3.5 Die Phase Service Operation

Die Phase Service Transition arbeitet im Rahmen des sog. Early Life Support sehr eng mit der darauf folgenden Phase Service Operation zusammen (vgl. Lacy et al. 2007: 3). „Operations started with a successful handover from the transition team" (Arya 2011: 275). Diese Phase beeinflusst die Zufriedenheit bzw. Unzufriedenheit der Anwender und Kunden am meisten. Sie hat zum Ziel, die Einhaltung der im Rahmen des sog. Service Level Agreement vereinbarten Qualitätsmerkmale im täglichen Betrieb sicher zu stellen (vgl. Beims 2010: 45f.). Eine Basis hierfür sind gut durchdachte und implementierte Prozesse die ständig optimiert werden müssen. Der Fokus dieser Phase geht über die Leistungserbringung für den spezifischen Service hinaus und betrachtet auch die internen Service Management Prozesse, die eingesetzten Technologien und die beteiligten Personen. Er bildet die Basis für die kontinuierliche Weiterentwicklung der Leistungserbringung (vgl. Taylor et al. 2007a: 13f.).

Hierbei gibt es einige Spannungsfelder zu beachten, in der sich die Prozesse der Service Operation bewegen. So muss zunächst die interne Sicht im Vergleich zum Kundenfokus geprüft werden. Es ist nicht relevant, wie der Service aus technischer Sicht erbracht wird, ausschließlich die Wahrnehmung des Nutzers bzw. des Kunden ist entscheidend (vgl. Beims 2010: 36f.). Dennoch muss auf Grund der Komplexität der bereitgestellten Services, die häufig durch mehrere Teams erbracht werden, auch der interne Fokus berücksichtigt werden (vgl. Taylor et al. 2007a: 20). Das zweite Spannungsfeld ist die Aufrechterhaltung eines stabilen Betriebs und demgegenüber die notwendige Flexibilität, um auf Kundenanforderungen schnell reagieren zu können (vgl. Taylor et al. 2007a: 22f.). Dies spielt vor allem im weiteren Verlauf dieser Arbeit eine wesentliche Rolle, da besonders agile Methoden eine hohe Flexibilität erfordern und daraus ein Zielkonflikt zur geforderten Stabilität besteht. Ebenfalls zu beachten ist, dass die oftmals geforderte hohe Qualität mit überschaubaren Ressourcen und optimalen Kosten erbracht werden sollte. Diese Herausforderung wird vor allem bei der Bestimmung des Maßes zwischen Proaktivität und Reaktivität deutlich (vgl. Taylor et al. 2007a: 22f.). Eine ausschließlich reaktiv handelnde Organisation ist immer vom Input des Kunden bzw. des Nutzers abhängig und entwickelt keine eigenen Maßnahmen zur Qualitätsverbesserung. Dies erhöht den Stressfaktor der Mitarbeiter, da reaktives Handeln immer zeitnah erfolgen muss und so einen zeitweilig erhöhten Ressourcenverbrauch verursacht.

Eine proaktive Organisation analysiert ständig ihr Umfeld und sucht nach Signalen zur Verbesserung der Services und verschafft sich daraus Konkurrenzvorteile. Proaktivität bedeutet aber immer auch eine Investition von Zeit und Ressourcen und verursacht höhere Kosten (vgl. Taylor et al. 2007a: 23f.).

Die wesentlichen Prozesse in der Phase Service Operation umfassen die Bearbeitung von Störungen im Incident Management und die langfristige Behebung von Störungsursachen im Rahmen des Problem Management. In der ITILV3 werden diese noch um die Prozesse Event Management und Access Management ergänzt (vgl. Taylor et al. 2007a: 33ff.). Der in ITIL V3 ebenfalls neu definierte Prozess Request Fulfillment behandelt die Anfragen von Nutzern eines IT-Service, die sog. Service Requests und deren Bearbeitung. ITIL bezeichnet als ,Nutzer' denjenigen, der die Dienstleistung in Anspruch nimmt. Im Gegensatz dazu bezeichnet das Wort ,Kunde' den Vertragspartner des IT-Dienstleisters; dieser muss aber nicht zwingend auch Nutzer des Services sein. In der ITIL V2 wurden Service Requests als Kategorie des Incident Management behandelt. Ziel des Prozesses ist es, Anwenderanfragen effektiv zu bearbeiten.

Darüber hinaus sorgt dieser Prozess für die Information der Nutzer über die verfügbaren IT-Services und deren Beauftragungsweg (vgl. Taylor et al. 2007a: 55f.).

2.3.6 Die Phase Continual Service Improvement

Ziel des Continual Service Improvement (CSI) ist es, durch kontinuierliche Optimierung der Leistungserbringung und der Services die Effektivität und vor allem die Effizienz zu steigern und die Kostensituation zu verbessern (vgl. Case et al. 2007: 25). Das Erkennen und Umsetzen möglicher Verbesserungen der Services ist nicht nur Aufgabe im Rahmen der Leistungserbringung der Phase Service Operation, sondern übergreifend in allen Phasen des ITSM-Lifecycle. Darüber hinaus ist CSI auch für die Verbesserung der internen Prozesse der Leistungserbringung zuständig (vgl. Beims 2010: 48ff.).

Um diesem Anspruch gerecht werden zu können, sind für jeden Prozess Messwerte, so genannte Key Performance Indikatoren (KPI) festzulegen, die den für den Kunden zu erreichenden Mehrwert prüfen sollen. „Set KPIs that reflect the real business motivations for the ITIL project. If the business case for the project was to improve availability then measure the project on availability" (England 2009: 63). Diese KPIs werden in regelmäßigen Abständen mit den tatsächlich erreichten Ist-Werten verglichen, um frühzeitig Qualitätsprobleme festzustellen. Das Vorgehensmodell zur Durchführung eines Verbesserungsprozesses ist der in Abb. 2 dargestellte Deming Cycle. Demings Ansatz sieht vier Phasen vor, die kontinuierlich durchlaufen werden und so eine Spirale ständiger Verbesserung ermöglichen (vgl.

Case etal. 2007: 29).

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2: Deming Cycle - Quelle: Bulsuk 2009.

Die erste Phase ist die Planungsphase, in der Verbesserungspotentiale anhand der Abweichung des KPIs erkannt und die zu ergreifenden Maßnahmen definiert werden. Hierauf folgt die Do-Phase, in der die Maßnahmen umgesetzt und getestet werden. In der anschließenden Check-Phase werden die gewonnenen Messergebnisse einem Soll- Ist-Vergleich unterzogen und bei einer erfolgreichen Überprüfung im Rahmen der Act​Phase umfassend eingeführt (vgl. Case et al. 2007: 29f.). Wichtig ist, sicherzustellen, dass die eingeführte Optimierung auch dauerhaft beibehalten wird, um sich nicht wieder zu verschlechtern. „If there is no provision for ongoing maintenance of the processes in the proposal - if they are not "chocking the wheel" of the Deming Cycle to prevent it rolling backwards again" (England 2009: 62).

2.4 Einführung in das Application Lifecycle Management Der in Kapitel 2.3 vorgestellte ITSM Lifecycle fokussiert den Business Service als Ganzes.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 3 Application Lifecycle Management

Dieser Business Service wird unterstützt durch einen IT- Service, der wiederum aus den zugehörigen Applikationen und technischen Komponenten besteht. Das Management der IT-Applikation und der Infrastruktur sowie aller technischen Komponenten ist eine wesentliche Aufgabe, um eine effektive und effiziente Bereitstellung des IT-Services zu gewährleisten und so den Business Service überhaupt erst zu ermöglichen. Die Phase Service Strategie der ITIL V3 definiert die IT-Leistungserbringung und die damit betrauten Personen als ,strategisches Asset', also als einen strategisch wichtigen Wert für das Unternehmen (vgl. Iqbal et al. 2007: 18). „Applikationen sind Teil eines Services mit einem ausgeprägten Fokus in Richtung Technologie und Funktionalität" (Taylor et al. 2007a: 131). Sie bedürfen daher eines spezifischeren Managementmodells, das die ITIL V3 in der Phase Service Operation mit dem Application Management Lifecycle (AML) beschreibt. Der AML gliedert den Lifecycle eines IT-Services in die einzelnen Phasen ,Requirement', ,Design', ,Build & Test', ,Deploy', ,Operate' und ,Optimize' (Taylor et al. 2007a: 130). Hierbei können sich einzelne Teile eines Services in unterschiedlichen Phasen des AML befinden. So kann zur selben Zeit ein Teil der Funktionalität des Services bereits aktiv genutzt werden, während sich ein anderer Teil aktuell in der Phase ,Build & Test' befindet. Jede Komponente des Services muss allerdings alle Phasen des AML durchlaufen. Hierfür sind eine ständige Abstimmung und eine intensive Kommunikation über den Stand der einzelnen Komponenten und deren aktuellem Status im AML notwendig. Darüber hinaus haben Entscheidungen, die in einer Phase des Lifecycle getroffen werden, auch Auswirkungen auf andere Phasen und müssen somit phasenübergreifend betrachtet werden (Taylor et al. 2007a: 132f.).

Der AML hat Einfluss auf das ganze IT-Servicemanagement, da er bisher in der Praxis stark getrennte Organisationsbereiche in einem vollständigen Lifecycle integriert. Sowohl die Entwicklung als auch der Betrieb haben die gemeinsame Aufgabe, Applikationen bereitzustellen, die den Anforderungen des Kunden gerecht werden (Taylor et al. 2007a: 130f). Damit sind beide Disziplinen Teil desselben Lebenszyklus; lediglich die Tiefe der Integration in den einzelnen Phasen unterscheidet sich (vgl. Pilz 2010). Darüber hinaus muss sich der AML als wesentlicher Teilleistungserbringer für die Bereitstellung des Business Services in den ITSM Lifecycle integrieren; er stellt also eine Ergänzung und keine Alternative zu diesem dar (vgl. Taylor et al. 2007a: 129ff.). Die ITIL V3 beschreibt allerdings nicht, welche Prozesse in welcher Phase des AML umzusetzen sind. Eine 1:1-Zuordnung der Phasen des ITSM-Lifecycle in die Phasen des AML ist bisher nicht erfolgt. Die einzelnen Aufgaben, die im AML zu erledigen sind, werden verteilt über die fünf Bücher in den einzelnen Prozessen des ITSM-Lifecycle erläutert. Die im Rahmen des AML durchzuführenden Aktivitäten werden von einer Rolle war genommen, die in ITIL mit dem Begriff Application Management benannt wird (vgl. Taylor et al. 2007a: 136). In der Literatur wird diese Rolle teilweise auch mit dem synonym zu verwendenden Begriff Application Lifecycle Management (ALM) bezeichnet (vgl. Oecking 2011: 7f.), der auch im weiteren Verlauf genutzt wird.

Die Verbreitung des ALM nimmt immer mehr zu. „Several organizations are actively considering infusing Service Management disciplines into the way they manage their application" (Madhukar et al. 2011: 168).

Trotz der steigenden Verbreitung und Priorität des ALM gibt es in der Literatur keine einheitliche Definition des Umfangs von ALM. Häufig liegt in den Definitionen der Tätigkeitsschwerpunkt auf der Entwicklung neuer Applikationen: „ALM — the coordination of development activities to produce software applications — is an accepted concept" (Schwalber 2006: 1ff.). Einen ähnlichen Umfang definiert Michels mit seiner ebenfalls primär entwicklungsgetriebenen Zielrichtung: „ALM describes the coordination of development lifecycle disciplines, including requirements management, change management, configuration management, integration management, release management and test management. These functions span development phases, including requirements definition, design, code, test and run [...]" (Michael 2011: 7). Linnartz sieht im Gegensatz hierzu ALM als den Betrieb einer fertig entwickelten Applikation bis zu deren End-of-Life: „[...]application management refers to the lifecycle-oriented control of the problem resolution process for operational application systems excluding any fundamental application development services. In particular, application management encompasses user support and the further development of application already in use" (Linnartz 2004: 8).

Nach der Definition der ITIL hat der ALM auch einen operativen Anteil am IT-Betrieb, der durch die Rollen des Technical Managers und des IT-Operations Managers unterstützt wird. „Application Management is responsible for managing applications throughout their lifecycle. The Application Management function supports and maintains operational applications and also plays an important role in the design, testing and improvement of applications that form part of IT services" (Taylor et al. 2007a: 16). Einen weit weniger aktivitätsbezogenen Blickwinkel nimmt das ALM in der Definition nach Forrester ein: „ALM doesn't support specific life-cycle activities; rather, it keeps them all in sync. [...]

ALM ensures the coordination of these activities, which keeps practitioners' efforts directed at delivering applications that meet business needs" (Schwalber 2006: 3).

Aus Sicht des Autors kann keiner der oben genannten Blickwinkel aus einer umfassenden Sicht des ALM ausgeschlossen werden. Damit umfasst das ALM alle operativen, taktischen und strategischen Aufgaben und Maßnahmen, um mit Hilfe von IT-Services den Geschäftsprozess des Kunden bestmöglich zu unterstützen. Das ALM verantwortet hierbei alle Lebensphasen eines IT-Services bis zu dessen End-of-Life.

2.5 Herausforderungen an das ALM nach ITIL V3

In diesem Kapitel sollen die kritischen Meinungen zu ITIL analysiert werden, um sie im weiteren Verlauf als Anforderung und Verbesserungspotenzial in der Entwicklung des neuen Modells für Application Lifecycle Management berücksichtigen zu können. Es ist festzustellen, dass die wenigsten Unternehmen alle in der ITIL beschriebenen Prozesse vollständig eingeführt haben. Dies wird durch die Consultingfirmen gefördert, die ihren Kunden häufig dazu raten, die ITIL Disziplinen schrittweise einzuführen, um so vor allem die Risiken der Implementierungsprojekte beherrschbar zu machen. Viele Projekte entwickeln sich ab einem bestimmten Status quo allerdings nicht mehr weiter, so dass häufig nur die ITIL-Disziplinen eingeführt werden, die weitgehend einfach in die Organisation zu integrieren sind (vgl. Bienert 2005: 1ff.). Teilweise können Unternehmen wenig Nutzen aus den eingeführten Prozessen ziehen. Ein wesentlicher Grund hierfür ist, dass ITIL zu wenig als Basis für Innovation und langfristige Optimierung gesehen wird. So ist nach Ansicht von exagon der grundsätzliche Ansatz der ITIL ein Segen für das ITSM, aber auch kein Wunderwerk. Die Ursache für die Kritik ist nicht ITIL an sich, sondern die Art der Implementierung. Es darf weder das Tool noch der theoretische Ansatz im Mittelpunkt einer ITIL-Einführung stehen, sondern die operative Umsetzbarkeit der Werkzeuge (vgl. Fremmer 2011:1f.).

Es bleibt weiterhin festzuhalten, dass die Integration der verschiedenen Prozesse zu einem Gesamtbild auch in der ITIL V3 nicht umfassend gelungen ist. „Die einzelnen Prozesse existieren weitgehend nebeneinander, es werden höchstens einige Schnittstellen zu anderen Prozessen textlich angeführt, und das immer sehr knapp. Eine detaillierte Schnittstellenbeschreibung fehlt" (Beims 2010: 59). Dies erschwert eine Implementierung, da bei der konkreten Umsetzung ein sehr groß dimensionierter Interpretationsspielraum vorhanden ist, der durch die Minimierung der Detailtiefe der Prozessbeschreibung im Vergleich zur ITIL V2 sogar noch weiter vergrößert wurde. Die detaillierte und auf das jeweilige Unternehmen bezogene Spezifizierung zu einem individuellen Prozessmodell stellt die IT-Abteilungen vor eine sehr große Hürde, weshalb nur die Prozesse eingeführt werden, die einen schnellen Nutzen stiften und weniger komplex gestaltet sind (vgl. Wischki 2009: 6f.).

„ITIL ist als de-facto Standard auf das IT-Servicemanagement und damit den Betrieb und dessen Optimierung beschränkt und hierfür hervorragend geeignet" (Steiger 2009). Einer der größten Kritikpunkte an der ITIL bleibt jedoch die fehlende Synchronisation zwischen Entwicklung und Betrieb.

„ITILfocuses on operations, and mostly ignores development" (England 2009: 9). Diese Lücke und die sich daraus ergebende häufig mangelhafte Zusammenarbeit, haben negative Auswirkungen für die Kunden.

Auch die Implementierung des in Kapitel 2.4 beschriebenen AML zeigt keinen Ansatz auf, wie die Kooperation hier genau zu gestalten ist. So kommt es sehr oft vor, dass Zeitvorgaben innerhalb der Entwicklung nicht eingehalten werden, der aktuelle Arbeitsstand unklar ist und die vom Arbeitsergebnis abhängenden Folgeabteilungen nur noch reaktiv tätig werden, da eine vorausschauende Terminplanung nicht möglich ist. Häufig ist deshalb der IT-Betrieb gefordert schnell zu reagieren, wenn es zu zeitlichen Verzögerungen in der Entwicklung kommt. „Die unterschiedlichen Prozesse müssen über diese Abteilungen hinweg funktionieren, denn Prozesse spielen sich nicht nur in einem Bereich ab" (Beims 2010: 65). In einem übergreifenden ALM, welches auch die Softwareentwicklung berücksichtigt, sind die notwendigen Prozesse jedoch weit schwieriger zu definieren. Hierfür fehlen in der ITIL V3 zwingend notwendige Prozesse für die Priorisierung von Ideen und das Erkennen von Auswirkungen auf laufende Aktivitäten, oder auch für das Planen und Transportieren von Änderungen über mehrere Services hinweg.

Darüber hinaus lässt ITIL ausgereifte und standardisierte Schnittstellen zu den verschiedenen Prozessen und anderen Disziplinen vermissen (vgl. Steiger 2009).

Grundsätzlich ist der Erfolg einer ITIL-Einführung vom Veränderungswillen der Mitar​beiter und deren aktiven Begleitung im Veränderungsprozess abhängig und nicht von Tools, Prozessdefinitionen oder Technologie (vgl. England 2009: 3). „Die besten Prozesse plus ein perfektes ITIL-Tool werden wenig ausrichten, wo das Dienstleistungsverständnis nur eine rudimentäre Ausprägung aufweist" (Bienert 2005: 1). Diese Aussage gilt nicht nur für ITIL sondern allgemein für die Einführung neuer Prozessmodelle. Die Tools sind verhältnismäßig einfach zu integrieren. Weit schwieriger ist die Implementierung neuer Prozesse und Arbeitsweisen. Die größte Herausforderung allerdings stellt der notwendige Kulturwandel ausgehend von einer primär technischen Sichtweise hin zu einer Verknüpfung der technischen Lösung mit den Geschäftsprozessanforderungen des Kunden und einer qualitätsgetriebenen Leistungsbereitstellung dar (vgl. Bergmann 2009). Der erste Schritt muss deshalb immer die Definition der Zielsetzung der Veränderung sein. Auf Basis dieser Zielsetzung werden die Prozesse analysiert und erst dann die entsprechenden Tools definiert. „ALM does not simply rely on using any specific ALM tools suite.

Working with ALM should start with the concepts and ideas behind it" (Michael 2011:17).

Auch die sich immer schneller ändernden internen und externen Anforderungen stellen eine große Herausforderung für ITIL dar. „You don't need ITIL to run a static environ​ment where nothing goes wrong and nothing changes and nothing grows" (England 2009: 1). Häufig bemängelt der Kunde bzw. der Anwender, dass er bei der Gestaltung und Einführung von Prozessen und Rollen zu wenig eingebunden wird. Auch der in ITIL V3 gewählte Ansatz, die Prozesse aus Sicht eines IT-Dienstleisters zu beschreiben und vor allem in der Phase Service Strategie die Mehrwertgenerierung in den Vordergrund zu rücken, geht hier nicht weit genug. Da die ITIL-Einführung unmittelbare und massive Folgen und Auswirkungen für den Kunden hat, müssen zumindest die Schnittstellen zum Kunden mit den angepassten Prozessen des Dienstleisters verknüpft werden (vgl. Beims 2010: 61). Die Prozesse, vor allem in den Büchern Service Strategie und Service Design, wirken zu behäbig, um flexibel und schnell auf neue Kundenanforderungen reagieren zu können. Stellt der Kunde z.B. im Rahmen der finalen Softwareabnahme fest, dass er an seinem Produkt noch geringfügige Änderungen durchgeführt haben möchte, müssen die Prozesse der Phase Service Design und Service Transition nochmals durchlaufen werden. Aus Kundensicht stellt dies eher eine Verschlechterung, als eine Verbesserung der Qualität dar. „There is no value in ITIL; there is only value in service improvement" (England 2009: 88). Diese, immer häufiger auftretenden späten Änderungswünsche, die nicht nur durch den Kunden forciert sondern teilweise auch durch interne Einheiten erst festgestellt werden, müssen dynamischer in den Prozess integriert werden können, um eine aus Sicht des Kunden optimale Leistungserbringung und somit einen maximalen Nutzen für das Business zu erreichen.

„Bei aller Kritik ist festzuhalten, dass die Etablierung von ITIL als Best-Practice- Framework eine Erfolgsgeschichte darstellt" (Bienert 2005: 2). Um dennoch die kritischen Anmerkungen an der ITIL zu optimieren, werden im weiteren Verlauf agile Methoden vorgestellt, die hierfür nützliche Werkzeuge liefern, die in das in Kapitel 4 erstellte Modell eines agilen Application Management Lifecycle mit einfließen.

[...]

Ende der Leseprobe aus 87 Seiten

Details

Titel
Entwicklung eines Vorgehensmodells für agiles Application Lifecycle Management nach ITIL
Hochschule
Hamburger Fern-Hochschule
Autor
Jahr
2011
Seiten
87
Katalognummer
V182179
ISBN (eBook)
9783656056171
ISBN (Buch)
9783656056041
Dateigröße
4301 KB
Sprache
Deutsch
Schlagworte
ITIL, Application Lifecycle Management, Prozessoptimierung, ITSM, Servicemanagement, Kanban, Scrum, agiles Projektmanagement, Lean Management, IT-Servicemanagement, Prozessentwicklung, ITIL V3, Anforderungsmanagement
Arbeit zitieren
Stefan Holhut (Autor:in), 2011, Entwicklung eines Vorgehensmodells für agiles Application Lifecycle Management nach ITIL, München, GRIN Verlag, https://www.grin.com/document/182179

Kommentare

  • Noch keine Kommentare.
Blick ins Buch
Titel: Entwicklung eines Vorgehensmodells für agiles Application Lifecycle Management nach ITIL



Ihre Arbeit hochladen

Ihre Hausarbeit / Abschlussarbeit:

- Publikation als eBook und Buch
- Hohes Honorar auf die Verkäufe
- Für Sie komplett kostenlos – mit ISBN
- Es dauert nur 5 Minuten
- Jede Arbeit findet Leser

Kostenlos Autor werden