Change Management von IT Applikationen

Eine Nutzwertanalyse bei den Berliner Stadtreinigungsbetrieben

Tobias Schwartz, B.Sc.

Abstract

Der laufende Wandel von Unternehmensprozessen und veränderte technologische

Möglichkeiten führen zur Notwendigkeit, auch die IT Applikationen laufend anpassen zu

müssen; diese Art des Change Management muss möglichst reibungslos, d.h. fehlerfrei und

schnell verlaufen. Die vorliegende Arbeit untersucht einen konkreten Prozess bei den BSR

mithilfe des Instrumentes Nutzwertanalyse, unter Verwendung der Frameworks ITIL und

ASL. Das Ergebnis dieser Untersuchung ist eine konkrete Handlungsempfehlung für den

Praxispartner, insbesondere zur Erstellung eines Service-Kataloges.

1

1 Einleitung „Nicht jede Änderung bedeutet eine Verbesserung, aber jede Verbesserung ist eine Änderung“.1

Dies gilt besonders für die Entwicklung der IT in den Unternehmen. Es wurden traditionell viele

Individuallösungen für die IT-Prozesse und Methoden in den Unternehmen eingeführt. Diese

waren speziell an die Unternehmensbedürfnisse angepasst. Jedoch müssen sich die

Unternehmen heutzutage immer konsequenter und schneller an den Markt anpassen. Die

individuellen IT-Prozesse stoßen hierbei schnell an ihre Grenzen.2 Genau hier setzt das IT

Service Management (ITSM) an. Es dient dazu die Prozesse zu standardisieren und transparent

zu gestalten.3 ITSM wird in verschiedenen Frameworks und Standards konkret ausgeprägt. Ein

Framework, welches sich in dem Zusammenhang seit Ende der 90er Jahre zu einem de-facto

Standard entwickelt hat, ist die IT Infrastucture Librabry (ITIL).4

ITIL bietet einen ganzheitlichen, prozessorientierten Ansatz zur Effizienzsteigerung der IT-

Prozesse. Dadurch wird dem Kunden der IT-Organisation eine optimale Unterstützung seiner

Geschäftsprozesse durch IT-Services geboten.5 Ein großer Teil dieser IT-Services basiert auf IT-

Applikationen. Einerseits gibt es standardisierte Desktop-Software, wie z.B. MS-Office, und

andererseits komplexe Anwendungen, wie z.B. das ERP-System SAP R/3. Je

geschäftskritischer die Anwendung ist, desto wichtiger ist die Betreuung dieser Anwendung

durch die IT-Organisation.

Die dynamischen Märkte und das daraus wachsende Bedürfnis nach Flexibilität bedingen

schnelle Anpassungen der Applikationen durch gezielte Änderungen.6 ITIL konzentriert sich

stark auf das Management von technischen Infrastrukturkomponenten und die Entwicklung

neuer Anwendungen, weniger auf das Change Management von Anwendungen.7 Darauf hat

sich das Framework Application Services Library (ASL) spezialisiert. ASL befasst sich

schwerpunktmäßig mit der Erweiterung, Erneuerung und dem Betrieb von IT-Applikationen.

Diese Arbeit beschäftigt sich mit der Optimierung des „Change-Prozesses von IT–Applikationen“

bei den BSR. Dazu wird eine Nutzwertanalyse verschiedener optimierender Maßnahmen

durchgeführt. Grundlage für diese Maßnahmen sind eine Betrachtung der Schwachstellen im Ist-

Prozess sowie der Frameworks ITIL und ASL.

1 Fischer, Arne/ Stolpmann, Björn Eric (2005), S. 53 (siehe Internet- / Intranetverzeichnis). 2 Vgl. Kresse, Michael u.a. (2005), S. 6. 3 Vgl. Renner, Bernhard u.a. (2006), S. 4. 4 Vgl. Kresse, Michael u.a. (2005), S. 8. 5 Vgl. ebenda, S. 9. 6 Vgl. Van der Pols, Remko (2004), S. 9. 7 Vgl. Meijer, Machteld u.a. (2005), S. 1 (siehe Internet- / Intranetverzeichnis).

2

Motivation Die BSR betreiben eine umfangreiche Anwendungslandschaft. Dabei wird im Kern die

Zielsetzung verfolgt, zentrale Unternehmensapplikationen auf der Grundlage der SAP-

Infrastruktur- und Systempalette zu realisieren, zentral zu betreiben und zu betreuen.

Wesentliche Ausgangspunkte aus Sicht der BSR-IT-Geschäftseinheit sind:

• eine etablierte und funktionierende zentrale Anwendungsbetreuung und

• ein in weiten Teilen an standardisierter IT-Service-Erbringung ausgerichteter

Rechenzentrumsbetrieb.

Ein großes Tätigkeitsspektrum der zentralen Anwendungsbetreuung ist das Change

Management der Anwendungen. So gab es im Jahr 2006 ca. 1700 Änderungen an der

überwiegend SAP-basierten Anwendungslandschaft. Die Änderungen werden größtenteils von

externen Software-Entwicklern durchgeführt und von den ca. 20 Mitarbeitern der zuständigen IT-

Abteilung betreut. Das für die externen Entwickler bereitgestellte Budget war sehr hoch.8

Angesichts dieser hohen Kosten ist es wünschenswert, Effizienz-steigernde Maßnahmen im

Change-Prozess zu etablieren. Weiterhin gibt es im Rahmen der Entwicklung des IT-Service

Managements, des Applikationsmanagements sowie unternehmensweiter

Prozessmanagementansätze Bestrebungen, den Änderungsprozess zu optimieren. Besonders

die geplante stärkere Anlehnung der gesamten IT-Geschäftseinheit an das ITIL Framework ist

hierbei zu benennen.

Zielsetzung Die vorliegende Arbeit verfolgt die durch den Kunden (BSR) geforderten nachstehenden Ziele:

• Die spezifischen, ursachenbezogenen Schwachstellen des Ist-Change-Prozesses von IT-

Applikationen sollen identifiziert werden.

• Es sollen unter Betrachtung der Frameworks ITIL und ASL sowie aus BSR-spezifischen

Ansätzen optimierende Maßnahmen extrahiert werden.

• Unter dem pragmatischen Ansatz „maximaler Nutzen bei adäquatem Aufwand“ soll eine

Handlungsempfehlung entstehen, welche die wertvollsten Maßnahmen in ihrer

Umsetzungsreihenfolge aufzeigt.

Vorgehensweise Abbildung 1 illustriert die Vorgehensweise der Arbeit. Das methodische Vorgehen orientiert sich

an dem Verfahren der Nutzwertanalyse. Kapitel 2 erläutert zunächst die Methode der

Nutzwertanalyse. Im Anschluss führt Abschnitt 2.2 in grundlegende Aspekte zur

Anwendungsbetreuung ein. Darauf aufbauend werden die beiden Frameworks ITIL und ASL mit

den für diese Arbeit relevanten Prozessen vorgestellt. 8 Konkrete Zahlen dürfen aus Gründen der Geheimhaltung nicht veröffentlicht werden.

3

Ausgehend von dem übergreifenden Ziel, den Change-Prozess von IT-Applikationen zu

optimieren, werden die Ergebnisse der Ist-Analyse in Kapitel 3 beschrieben. Die Ist-Analyse

besteht aus der einleitenden Vorstellung der BSR-Anwendungslandschaft und des Ist-

Prozessablaufs. Daran anschließend werden die Interviews mit den Mitarbeitern und die

Auswertung der Datensätze aus dem BSR-Änderungs-Ticketsystem dargestellt. Daraus ergeben

sich die Schwachstellen im Change-Prozess.

Die identifizierten Schwachstellen sind die Ausgangsbasis für die Bestimmung von Zielkriterien

der Nutzwertanalyse. Kapitel 4 ordnet die identifizierten Schwachstellen definierten Kategorien

zu. Diese Kategorien stellen die Zielkriterien dar. Anschließend werden die Kategorien

hinsichtlich ihrer Kritikalität bewertet. Dadurch findet eine Gewichtung der Zielkriterien statt.

Somit ist ein Überblick vorhanden, welche Kategorien schwerpunktmäßig durch die Optimierung

zu adressieren sind.

In Kapitel 5 werden in Anlehnung an ITIL und ASL sowie aus BSR-spezifischen Ansätzen

Maßnahmen zur Optimierung diskutiert. Diese Maßnahmen werden kurz beschrieben und nach

den Aspekten Nutzen und Aufwand bewertet. Daraus resultieren die bevorzugten Maßnahmen

unter Berücksichtigung des pragmatischen Ansatzes in der Zielstellung.

Kapitel 6 ermittelt die Abhängigkeiten und Zusammenhänge zwischen den präferierten

Maßnahmen und versucht, durch Kombination bestimmter Maßnahmen eine weitere

Nutzenmaximierung zu erreichen. Das Ergebnis ist eine Handlungsempfehlung für das IT-

Management der BSR, welches die Reihenfolge der Umsetzung der Maßnahmen erläutert.

Darauf folgt eine kritische Betrachtung der Ergebnisse. Kapitel 7 rundet die Arbeit mit einem

resümierenden Fazit ab.

Abbildung 1: Vorgehensweise der Arbeit, Quelle: eigene Darstellung.

4

2 Theoretische Grundlagen

2.1 Nutzwertanalyse Die Nutzwertanalyse, auch unter den Begriffen „Multifaktorentechnik“, „Punktwertverfahren“ oder

„Utility Analysis“ bekannt, ist ein Verfahren zur Bewertung verschiedener Lösungsalternativen.9

Sie wird aufgrund der einfachen Handhabbarkeit häufig in der Praxis verwendet.10 Der Weg

besteht darin, geeignete Kriterien zu identifizieren, diese zu gewichten und ausgesuchte

Lösungsalternativen anhand dieser Kriterien zu bewerten.11 Tabelle 1 zeigt eine Struktur, wie sie

typischerweise für eine Nutzwertanalyse eingesetzt wird.

Die folgenden Phasen charakterisieren die Vorgehensweise der Nutzwertanalyse ausgehend

von einer Problemdefinition:

1. Entwickeln von Lösungsalternativen zu diesem Problem.12

2. Zielkriterien auswählen, die möglichst unabhängig voneinander sind.13 Hierfür bietet das

Erstellen eines hierarchischen Zielsystems, bei dem die Zielkriterien in eine logische Struktur

ausgehend von einem Hauptziel gebracht werden, eine gute Unterstützung.14

3. Gewichtung dieser Zielkriterien nach einer definierten Skala, z.B. 1-5.Hierbei ist auf das

Verhältnis der Kriterien zueinander zu achten. Es wird der prozentuale Anteil an der Summe

aller Kriterien ermittelt.15

4. Bestimmung von Zielerträgen der Lösungsalternativen zu den einzelnen Kriterien nach einer

definierten Skala, z.B. 1-5.

5. Wertsynthese durch Berechnen der Teilnutzen und Gesamtnutzen der

Lösungsalternativen.16

9 Vgl. Schultetus, Wolfgang (2005), S. 1 (siehe Internet- / Intranetverzeichnis). 10 Vgl. Schneider, Karl-Heinrich (2004), S. 218. 11 Vgl. Wazeck, Jürgen (2005), 1. Abschnitt (siehe Internet- / Intranetverzeichnis). 12 Vgl. Scholles, Frank (2006), Abschnitt 6.5.3 (siehe Internet- / Intranetverzeichnis). 13 Vgl. Wazeck, Jürgen (2005), 1. Abschnitt (siehe Internet- / Intranetverzeichnis). 14 Vgl. Schultetus, Wolfgang (2005), S. 2 (siehe Internet- / Intranetverzeichnis). 15 Vgl. Wazeck, Jürgen (2005), 2. Abschnitt (siehe Internet- / Intranetverzeichnis). 16 Vgl. Schultetus, Wolfgang (2005), S. 2 (siehe Internet- / Intranetverzeichnis).

Tabelle 1: Struktur einer Nutzwertanalyse, in Anlehnung an: Schneider, Karl-Heinrich (2004), S. 219.

5

6. Bestimmen der Rangfolge der Alternativen nach dem Gesamtnutzen.

7. Interpretation des Ergebnisses und gegebenenfalls Durchführen einer Sensitivitätsanalyse.

Mit dieser kann festgestellt werden, wie sensibel das Ergebnis auf Veränderungen der

Kriteriengewichtung oder Bewertung reagiert.17

8. Zusätzlich kann unter Einbeziehung des Aufwands eine Betrachtung des Aufwand-Nutzen-

Verhältnisses der Alternativen getätigt werden, um die optimale Alternative zu ermitteln. 18

Durch dieses Verhältnis ist ein pragmatischer Vergleich möglich.

Der Vorteil einer Nutzwertanalyse liegt in einer transparenten und systematisierten

Entscheidungsfindung. Besonders das Zielsystem kann wichtige Erkenntnisse über die eigene

Situation liefen. Nachteile und Risiken bestehen in einer subjektiven Bewertung sowie in dem

großen Aufwand bei einer gründlichen Durchführung.19

2.2 Information Technology Infrastructure Library (ITIL) ITIL stellt einen Leitfaden zur Planung, Erbringung und Unterstützung von IT-Service-Leistungen

bereit und wurde im Auftrag der britischen Regierung durch die Office of Government Commerce

(OGC) entwickelt. ITIL ist mittlerweile ein internationaler de-facto-Standard. Unternehmen

können sich nach der ISO 20000 Norm zertifizieren lassen, welche eng mit den ITIL-

Kernmodulen Service Support und Service Delivery abgestimmt ist. 20 Neben diesen

unternehmensbezogenen Zertifizierungen gibt es noch die personenbezogenen

Qualifizierungen. Es gibt die drei gängigen Zertifizierungsstufen „ITIL Foundation“, „ITIL

Practitioner“ und „ITIL Manager“.21 ITIL bettet sich in den Kontext des IT Service Management

(ITSM) ein. ITSM umfasst die Standardisierung der Prozesse und Methoden im Unternehmen,

um diese nach einer servicegerichteten Sichtweise an die Geschäftsanforderungen

anzupassen.22 Bei der Diskussion um ITSM stellt sich unweigerlich die Frage nach der Definition

eines IT-Service. ITIL bietet hier eine recht pragmatische Beschreibung: Ein Service sind ein

oder mehrere IT-Systeme, die einen Geschäftsprozess ermöglichen.23 Bei der Einführung von

ITIL in einem Unternehmen gilt es folgende sechs Erfolgsfaktoren zu berücksichtigen:

• Die Geschäftsprozesse der IT-Kunden sind deren Kerngeschäftsprozesse, die durch IT-

Services unterstützt werden.

• Die Kunden der IT sind nicht die Anwender, sondern die Personen, die mit der IT-

Organisation die Konditionen zu den Services vereinbaren und letztendlich auch bezahlen.

• Die Mitarbeiter und das Management der IT sind die Rollen in der IT-Organisation.

• Das ITSM Toolset sind ITSM-konforme Tools, deren Terminologie und Workflows an ITSM

angepasst sind. 17 Vgl. Schultetus, Wolfgang (2005), S. 2 (siehe Internet- / Intranetverzeichnis). 18 Vgl. ebenda S. 2. 19 Vgl. ebenda, s. 1. 20 Vgl. Glenfis AG (2006), (siehe Internet- / Intranetverzeichnis). 21 Vgl. Färbinger, Peter [Hrsg.] (2007 b), S. 68. 22 Vgl. Kresse, Michael u.a. (2005), S. 91. 23 Vgl. Office of Government Commerce (2003 a), Abschnitt 4.4.1.

6

• Das Kultur- und Organisationsmodell ist die Zuordnung von Verantwortlichkeiten und die

unternehmensspezifisch gewachsene Kultur.

• Das Prozessmodell beinhaltet die Prozesse der IT-Organisation.24 Im Vorfeld einer ITIL-Einführung sollten diese Faktoren im Unternehmen konkret analysiert

werden. Die Erfolgsfaktoren werden in den verschiedenen ITIL-Büchern schwerpunktmäßig

betrachtet. Es empfiehlt sich bei der Einführung von ITIL in kleinen Schritten vorzugehen.25

Abbildung 2 zeigt die sieben Hauptbücher von ITIL. In diesem Kapitel werden die Bücher

„Service Delivery“ mit dem Schwerpunkt Service Level Management und „Service Support“ mit

dem Fokus Change Management und das „Application Management“ vorgestellt.26

2.3 Application Services Library (ASL) Das ASL Framework bietet Unternehmen einen Leitfaden zur Strukturierung und Verbesserung

ihres Application Managements.27 ASL versteht unter Application Management die Wartung,

Erweiterung und Erneuerung von IT-Applikationen sowie das Anordnen und Steuern dieser

Tätigkeiten. Das Framework wurde 2001 in den Niederlanden von der ASL Foundation

veröffentlicht und findet wachsendes Interesse28 ASL trennt das Application Management von

den zwei weiteren Management Disziplinen „Functional Management“ und „Technical

Management“29.

24 Vgl. Kresse, Michael u.a. (2005), S. 8. 25 Vgl. ebenda, S. 8. 26 in der Bachelor Thesis nachzulesen 27 Vgl. Meijer, Machteld/ Meijer, Harry (2004), S. 1 (siehe Internet- / Intranetverzeichnis). 28 Vgl. Meijer, Machteld u.a. (2005), S. 2 (siehe Internet- / Intranetverzeichnis). 29 Vgl. Van der Pols, Remko (2004), S. 13.

Abbildung 2: Das ITIL Framework und seine Bestandteile, Quelle: Office of Government Commerce (2006), S. 1.

7

Für das Functional Management steht das Geschäft im Fokus. Es ist primär auf ein

ausgeglichenes Verhältnis zwischen dem Geschäftsprozess und dessen Kosten ausgerichtet.30

Es repräsentiert die User-Organisation.31 Das Technical Management ist für den Betrieb der

Informationssysteme bestehend aus Hardware, Software und Datenbanken verantwortlich. Es

stellt den Betrieb des Rechenzentrums mit seinen Infrastrukturkomponenten sicher. ITIL ist in

diesem Bereich ein oft verwendetes Framework.32

Abbildung 3 zeigt die von ASL definierten Prozessbereiche. Der flexible Geschäftsbetrieb

braucht keine komplexen Organisationen oder Prozesse. Besser sind kleine, abgeschlossene

Einheiten, wie sie die ASL-Prozesse aufzeigen. Bei der Implementierung eines Frameworks ist

es vorteilhafter, in kleinen Schritten vorzugehen. So ist das Risiko der Erfolglosigkeit geringer,

die Mitarbeiter akzeptieren die Neuheiten eher und es ist mehr Zeit vorhanden, den nächsten

Schritt zur Optimierung zu planen. Diese kleinen, Erfolg versprechenden Schritte werden als

Quick Wins bezeichnet.33 Das ASL Framework ist nicht als detaillierte Anleitung zur Einführung

eines funktionierenden Application Management anzusehen, sondern eher als Checkliste bei der 30 Vgl. Van der Pols, Remko (2004), S. 148. 31 Vgl. ebenda, S. 13. 32 Vgl. ebenda, S. 14. 33 Vgl. Rigall Juan, Wolters Georg (2005), S. 160.

Abbildung 3: Überblick über die Prozesse des ASL Frameworks, Quelle: ASL Foundation (2005) (siehe Internet- / Intranetverzeichnis).

8

Umsetzung eines IT-Prozessmodells.34 Ein zentraler Bestandteil, um den Anforderungen an ein

gut funktionierendes Application Management gerecht zu werden, ist das Definieren von SLA’s.

Hier werden Service Levels, Kriterien zur Messbarkeit der Qualität und Haftungsverhältnisse

zwischen Kunde und IT-Organisation vereinbart. Dabei ist das grundlegende Prinzip, dass die

heutigen und zukünftigen Anforderungen des Kunden mit angemessenen Kosten umgesetzt

werden. Daher ist es sehr wichtig, dass die Kosten für einen Service vorhersagbar, prüfbar und

nachvollziehbar sind.35.

ASL nutzt an vielen Stellen die gleichen Begriffe und Konzepte wie ITIL. Viele ASL-Prozesse

weisen Gemeinsamkeiten zu den ITIL-Prozessen auf. Tabelle 2 zeigt welche ITIL-Bücher

Berührungspunkte zu den entsprechenden ASL-Prozessen haben. Im Anhang befindet sich eine

detaillierte Übersicht zu den Schnittstellen von ASL und ITIL. ASL kann als ein mit ITIL

abgestimmtes Framework gesehen werden, dass sich speziell auf IT-Applikationen bezieht.36

Den Prozessen aus dem operativen Bereich wird innerhalb des ASL Frameworks die größte

Bedeutung beigemessen.37 In den folgenden Abschnitten werden die operativen Prozesse

Maintenance, Enhancemant and Renovation sowie die Connecting Processes näher

vorgestellt.38

34 Vgl. Van der Pols, Remko (2004), S. 159. 35 Vgl. Van der Pols, Remko (2004), S. 17. 36 Vgl. Meijer, Machteld u.a. (2005), S. 1 (siehe Internet- / Intranetverzeichnis). 37 Vgl. Van der Pols, Remko (2004), S. 24. 38 in der Bachelor Thesis nachzulesen

Tabelle 2: Berührungspunkte der ITIL-Bücher und ASL-Prozesse, in Anlehnung an: Smalley, Mark (2006), S.2 (siehe Internet- / Intranetverzeichnis).

9

3 Ist-Analyse

3.1 Die Geschäftseinheit Informationstechnologie Die Geschäftseinheit Informationstechnologie (PT) ist der unternehmensinterne IT-Dienstleister

der BSR und ihrer Tochterunternehmen. Ca. 2000 Arbeitsplätze an über 40 Standorten werden

mit Netzwerk- und Kommunikationsdiensten versorgt. Außerdem werden die zentralen IT-

Anlagen sowie die im Unternehmen eingesetzten IT-Applikationen durch die Geschäftseinheit

betreut. Dabei wird auf ein ausgewogenes Verhältnis kostengünstiger, einheitlicher

Standardsoftware einerseits und Unterstützung spezifischer Geschäftsprozesse andererseits

geachtet.

Abbildung 4 zeigt den strukturellen Aufbau der Geschäftseinheit Informationstechnologie. Die

Abteilung „IT-Services“ (PTT) stellt die Netzwerk- und Kommunikationsdienste sowie auf den

Clients zu installierende Desktopanwendungen, wie z.B. MS-Office, bereit.

Die Abteilung „SAP AWISION“ (PTI) hat die Betreuung des ERP-Systems SAP R/3 als

Kernkompetenz. Dabei ist das Team „Innovation und Beratung“ für die Weiterentwicklung und

Wartung des ERP-Systems und dessen Umfeld, also den wesentlichen Teil des Change-

Prozesses, zuständig. Das Team „SAP und DB Services“ (SAP-Basis) ist für die technische,

hardwarenahe Betreuung des ERP-Systems verantwortlich.

3.2 Ist-Prozessablauf Im Folgenden wird der Änderungsprozess für das SAP-System und -Umfeld grob beschrieben.

Der Prozess wird durch das Tool REMEDY, in welchem die einzelnen Workflows für das

Änderungsmanagement hinterlegt sind, unterstützt. In diesem Prozess werden alle SAP-

Applikationen betreut sowie Applikationen, die mit den ERP-System kommunizieren, z.B. DMS,

CMS, Web Anwendungen (z.B. für Intranet- und Internetpräsenz) und das REMEDY System

Abbildung 4: Aufbau der Geschäftseinheit Informationstechnologie, Quelle: eigene Darstellung.

10

selbst. Bis auf den Anwender hat jede der am Prozess beteiligten Rollen (siehe Prozesskette in

Abbildung 5) einen REMEDY-Zugang und entsprechend der Rolle bestimmte Berechtigungen.

Der Prozess ist in Abbildung 5 stark vereinfacht dargestellt. Der Anwender meldet zunächst

einen Incident zu einer der oben genannten Anwendungen. Er meldet dies dem zuständigen

IKS-Koordinator, welcher den Incident analysiert. Entweder der IKS-Koordinator kann dem

Anwender weiterhelfen, z.B. wenn der Incident durch einen Anwenderfehler begründet war, oder

er erstellt eine Anfrage in REMEDY. Die Anfrage im REMEDY ist sinngemäß einem RfC im ITIL-

Kontext gleichzusetzen. Der IKS-Koordinator leitet die Anfrage über REMEDY an den

zuständigen Modulbetreuer aus der Abteilung „SAP AWISION“ weiter.

Der „SAP AWISION“-Modulbetreuer analysiert zunächst den RfC. Anschließend wird in

Zusammenarbeit mit dem IKS-Koordinator, dem „SAP AWISION“-Modulbetreuer und oftmals

auch mit dem Software-Entwickler die Spezifikation des Change erstellt. Die Spezifikation wird

als Anlage in die REMEDY-Maske hinzugefügt. Der Software-Entwickler gibt daraufhin eine

Aufwandsschätzung und in der Regel ein technisches Konzept ab. Diese werden dem „SAP

AWISION“-Modulbetreuer und dem IKS-Koordinator vorgelegt. Der IKS-Koordinator stimmt sich

mit seinem Fachbereich auf Übernahme der Kosten ab. Ist das der Fall, beginnt der Software-

Entwickler mit der Entwicklung. Ist diese abgeschlossen, übergibt der Software-Entwickler den

Vorgang zum Testen an den Tester. Tester ist in der Regel der IKS-Koordinator aus der

Fachabteilung oder von ihm ausgewählte Anwender. Je nach Erfolg des Tests wird der Change

durch den „SAP AWISION“-Modulbetreuer an das Team „SAP-Basis“ weitergeleitet (Ausnahme

sind Nicht-SAP-Anwendungen) oder eventuelle Korrekturen an der Änderung eingearbeitet. Das

Team „SAP-Basis“ überführt den Change in das Produktivsystem.

3.3 Interviews Für die Ist-Analyse wurden ausführliche Interviews mit einigen Mitarbeitern der Abteilung „SAP

AWISION“ und mit einem externen Software-Entwickler durchgeführt. Allen wurden die selben

Fragen zum Change-Prozess gestellt. Aus diesen Interviews ergaben sich ca. 30 unstrukturierte

Schwachstellen im Prozess. Diese sind teilweise als Ursache und teilweise als Symptom

formuliert. Außerdem greifen sie inhaltlich stark ineinander. Die genannten Schwachstellen

bilden die Grundlage zur Bestimmung von strukturierten Zielkriterien in Abschnitt 4.2.39

39 Die genannten Schwachstellen aus den Interviews befinden sich als Excel-Tabelle auf dem beigelegten Datenträger (siehe Anhang).

Abbildung 5. grober Ablauf des Change Prozesses von IT-Applikationen., Quelle: eigene Darstellung.

11

3.4 Auswertung der Datensätze aus dem Ticketsystem Um die Schwachstellen aus den Interviews zu untermauern oder weitere zu identifizieren wurden

die Datensätze aus dem REMEDY-System für das Jahr 2006 analysiert. Es ergaben sich

folgende Schwachstellensymptome.40

• Bei vielen Changes werden keine Dokumente angehängt.

• Die Bearbeitungszeiten sind im Vergleich zur Aufwandsschätzung sehr lang.

• Die Prioritätszuweisung hat kaum Auswirkung auf die Bearbeitungszeit.

• Die Testdauer durch den Fachbereich ist unverhältnismäßig hoch.

40 Aus Gründen der Geheimhaltung werden die Schwachstellen hier nicht konkret benannt und beziffert. in der Bachelor Thesis nachzulesen

12

4 Zielkriterien und Gewichtung

4.1 Methodisches Vorgehen In diesem Kapitel werden die für die Nutzwertanalyse benötigten Zielkriterien identifiziert und die

Gewichtung ermittelt. Dabei klärt dieser Abschnitt die Vorgehensweise mit Bezug zu der

Nutzwertanalyse und schafft damit die Basis zum Verständnis des nächsten Abschnitts. Dieser

beschreibt die Ergebnisse der durchgeführten Phasen der Nutzwertanalyse.41

Wie in Abschnitt 3.5 beschrieben sind die

formulierten Schwachstellen des „Change-

Prozesses von IT-Applikationen“ aus den Interviews

wenig strukturiert und es bestehen viele

Abhängigkeiten untereinander. Da für die

Nutzwertanalyse strukturierte und möglichst

voneinander unabhängige Zielkriterien notwendig

sind, wurden die eher symptombezogenen

Schwachstellen aus den Interviews hinsichtlich ihrer

Ursache bestimmten Kategorien zugeordnet. Bei der Kategorisierung erfolgte eine

grundsätzliche Orientierung an den Erfolgsfaktoren zur Einführung von ITIL (siehe Abschnitt

2.2). Daraus ergaben sich die Hauptkategorien Prozess, Organisation, Mitarbeiter und

Technologie für die Schwachstellen (siehe Abbildung 6). Aus der Orientierung an den BSR-

spezifischen Aspekten der Schwachstellen wurden detailliertere Unterkategorien abgeleitet.

Diese Unterkategorien stellen die Zielkriterien der Nutzwertanalyse dar. Insgesamt gibt es 17

Unterkategorien. Die Kunden der IT wurden zum Teil betrachtet und finden sich als

Unterkategorie in Organisation wieder.

Nach Erstellung der Kategorien wurden nun die formulierten Schwachstellen aus den Interviews

hinsichtlich ihrer Ursachen für jede Kategorie untersucht und beschrieben. Damit ist zum einen

ein guter Überblick vorhanden, welche Schwachstellen in welcher Kategorie vorhanden sind,

und zum anderen ist das durch die Nutzwertanalyse geforderte Zielsystem entstanden.

Die nächste Phase laut der Nutzwertanalyse ist die Gewichtung der Zielkriterien. Die

Gewichtung wird in dem Zusammenhang dieser Arbeit als Kritikalität der Kategorie bezeichnet.42

Zur detaillierteren Bestimmung der Kritikalität wurden die Faktoren Ausmaß und Auswirkung

hinzugezogen. Unter dem Ausmaß ist erstens die Häufigkeit des Auftretens der Schwachstellen

einer Kategorie gemeint. Zweitens wird hier bewertet wie schwerwiegend das Auftreten ist. Zum

Beispiel ist es unterschiedlich schwerwiegend, ob jemand gar nicht dokumentiert, nur mäßig

41 Die vollständige Nutzwertanalyse befindet sich als Excel-Tabelle auf dem beigelegten Datenträger (siehe Anhang). 42 Die Kritikalität ist die Bedeutung die dem Fehlverhalten einer Betrachtungseinheit beigemessen wird. Vgl. Freericks, C. (2006), 2. Abschnitt (siehe Internet- / Intranetverzeichnis).

Abbildung 6: Ursächliche Hauptkategorien der Schwachstellen, Quelle: eigene Darstellung.

13

dokumentiert oder vorhandene Templates zur Dokumentation nutzt. Die Auswirkungen werden

unterteilt in Bezug auf Kosten, Termine und Qualität.

Die Kritikalität wurde folgendermaßen berechnet:

)min( QualitätAuswirkungKostenAuswirkungTerAuswirkungAusmaßätKritikalit ++×=

Dabei wurde als Bewertungsskala für jeden Faktor die drei Ausprägungen hoch (3), mittel (2)

und gering (1) gewählt. Im Anschluss wurden die prozentualen Anteile der Kritikalitäten der

Unterkategorien an der Gesamtsumme der Kritikalitäten, welche 100 Prozent entspricht,

ermittelt. Darauf aufbauend wurde die Skala in Abbildung 7 erstellt. Zu sehen ist die

Klassifizierung der Kritikalitäten und die dazugehörigen Häufigkeiten der Unterkategorien. Dabei

wiegt die Kritikalität schwerer als die Häufigkeit.

Die später identifizierten Maßnahmen sollten unbedingt die Unterkategorien mit den höchsten

Kritikalitäten adressieren. Das sind solche mit einem errechneten Kritikalitätsanteil von größer

als 7,5 Prozent.

4.2 Kategorisierung und Bewertung der Schwachstellen Nachdem die methodischen Grundlagen beschrieben wurden, sollen nun die Kategorien und

ihre Kritikalitäten gemäß der Ist-Analyse erläutert werden. Die Hauptkategorien bilden dabei

jeweils den Schwerpunkt. In dieser Zusammenfassung ist exemplarisch nur die Hauptkategorie

Prozess mit ihren Unterkategorien beschrieben.

Die Hauptkategorie Prozess hat als inhaltlichen Kern den Ablauf und die Dokumentation der

Phasen im Change-Prozess. Sie beinhaltet als Unterkategorien die einzelnen Prozessphasen

sowie den Grad der Standardisierung des Prozesses. Abbildung 8 zeigt die Unterkategorien mit

ihren Kritikalitäten.43 Ein für das weitere Verständnis der späteren Maßnahmen wichtiger Fakt

soll hier noch erwähnt werden.

Der dokumentierte Change Prozess differenziert nicht nach Anwendungskategorien. In der

Praxis zeigt sich jedoch, dass sich bezüglich der Anwendungskategorien durchaus Unterschiede

ergeben. Am Beispiel eines SAP-Standardmoduls und einer Eigenentwicklung auf SAP R/3

Basis soll dies verdeutlicht werden.

In einem SAP-Standardmodul, z.B. SAP FI, ist bei einer Änderungsanfrage zunächst zu prüfen

ob der Standard die gewünschten Funktionalitäten per Customizing, also Anpassen der Software

43 Die genauen Schwachstellensymptome der Unterkategorien werden aus Gründen der Geheimhaltung hier nicht weiter beschrieben

Abbildung 7: Klassifizierung der Kritikalitäten und Häufigkeiten, Quelle: eigene Darstellung.

14

ohne Entwicklung, ermöglicht. Dadurch können hohe Entwicklungskosten vermieden werden. Ist

das nicht der Fall, muss recherchiert werden ob in einem zukünftigen Release der Software

solch eine Funktionalität vorgesehen ist. Mit dem Fachbereich, der den Änderungswunsch

geäußert hatte, ist abzustimmen, ob bis zu diesem Release-Stand und dessen Einführung bei

den BSR gewartet werden kann oder ob gleich entwickelt werden soll. Bei einer

Eigenentwicklung, wie beispielsweise der Tourenplanung der BSR, entfällt der Schritt des

Prüfens auf mögliches Customizing sowie die Recherche für das kommende Release.

Stattdessen ist auf eine möglichst wohldefinierte Schnittstellen zu anderen Anwendungen zu

achten, da eine Eigenentwicklung möglicherweise in Zukunft durch eine Standardanwendung

ersetzt wird.

5 Maßnahmen und deren Nutzwert

5.1 Methodisches Vorgehen In der Nutzwertanalyse wurden bisher die Zielkriterien (Schwachstellenkategorien nach

ursachenbezogener Analyse) und deren Gewichtung (Kritikalität) ermittelt.

Nunmehr erfolgt die Entwicklung von Maßnahmen (Lösungsalternativen), die Bewertung dieser

Alternativen im Sinne eines Beitrages zur Lösung von Schwachstellen (Zielerträge), die

Ermittlung des Gesamtnutzens (Wertsynthese) sowie die Gegenüberstellung der Aufwände für

die Umsetzung. Hierzu erläutert dieser Abschnitt das methodische Vorgehen. Abschnitt 5.2 greift

die Maßnahmen und Zielerträge inhaltlich auf. Abschnitt 5.3 subsumiert die Ergebnisse der

Wertsynthese in Kombination mit der Aufwandsbetrachtung.

Das Entwickeln von Lösungsalternativen geschieht nicht wie in den Phasen einer

Nutzwertanalyse vorgesehen in der ersten Stufe, sondern nach den Phasen „Bestimmung“ und

Abbildung 8: Kritikalitäten der Hauptkategorie Prozess, Quelle: eigene Darstellung.

15

„Gewichtung der Zielkriterien“. Grund dafür ist, dass sich erst durch das Erkennen der

tatsächlichen Schwachstellen im Prozess und deren Kritikalitäten konkrete Maßnahmen ableiten

lassen. Die Maßnahmen stellen die Lösungsalternativen einer Nutzwertanalyse dar. Allerdings

sind sie hier nicht als Alternativen zu sehen, sondern als gekapselter Teil eines zu erstellenden

und optimierenden Gesamtkonzepts. Die Maßnahmen wurden so gewählt, dass ihr Nutzen

relativ autark bewertbar ist. Außerdem wurde für jede Maßnahme grob der Aufwand zur

Einführung bei den BSR geschätzt. Hierbei wurden Überlegungen zu Dauer, Ressourcen und

Kosten miteinbezogen. Abbildung 9 zeigt die Skala, die vergeben wurde. Stufe 1 bedeutet

geringer Aufwand und Stufe 5 sehr hohen Aufwand. Dabei hat ein Aufwand der Stufe 5 ca. den

fünffachen Aufwand der Stufe 1.

Die Zielerträge der Maßnahmen zu den einzelnen Schwachstellenkategorien wurden auf einer

Skala von 0 – 3 vergeben. 0 bedeutet die Maßnahme adressiert die Schwachstellenkategorie

überhaupt nicht und 3 bedeutet die Maßnahme würde die Schwachstellen der Kategorie sehr

stark verbessern. Im Abschnitt 5.2 werden die Maßnahmen jeweils mit einer einleitenden

Übersicht zusammenfassend vorgestellt. In Abbildung 10 ist das Gerüst dieser Übersicht

dargestellt. Enthalten sind alle adressierten Kategorien mit einer Kritikalität über 7,5 Prozent und

einem Zielertrag von 2 oder 3.44

5.2 Diskutieren von Maßnahmen In diesem Abschnitt werden geeignete optimierende Maßnahmen identifiziert. Es wird deren

Beitrag zur Adressierung der Schwachstellen hergeleitet und ein dadurch entstehender Soll-

Zustand skizziert. Das geschieht aus verschiedenen Überlegungsperspektiven. Grundlage für

die Identifizierung ist die Orientierung an den Hauptkategorien zu den Schwachstellen, welche

auch gleichzeitig Erfolgsfaktoren zur Einführung von ITIL sind. Die Erfolgsfaktoren spannen

einen vollständigen, aber nicht konkreten Lösungsraum auf, der in den Frameworks ITIL und

ASL Anwendung findet. Diesen Lösungsraum gilt es durch BSR-spezifische Überlegungen zu 44 Alle weiteren adressierten Kategorien können der beigefügten Excel-Tabelle entnommen werden (siehe Anhang).

Abbildung 9: Skala zur Bewertung des Aufwands, Quelle: eigene Darstellung.

Abbildung 10: Gerüst der Abbildungen zu den Maßnahmen, Quelle: eigene Darstellung.

16

füllen. Einerseits sind dafür die formulierten Schwachstellen aus den Interviews zu betrachten.

Andererseits sind die spezifischen Erkenntnisse aus den ITIL-Workshops der Geschäftseinheit

Informationstechnologie von Bedeutung. Letztendlich bilden die entworfenen Unterkategorien

durch ihre aggregierte, ursachenbezogene Sicht auf die Schwachstellen und die Zuordnung zu

den Hauptkategorien (ITIL-Erfolgsfaktoren) eine Schnittstelle zwischen den Frameworks und

dem Ist-Prozess. Abbildung 11 veranschaulicht diese Basis für ein strukturiertes Identifizieren

von Maßnahmen. In dieser Zusammenfassung wird nur eine Maßnahme exemplarisch

beschrieben.45

Einführen von Changetypen und Definieren der Prozesse nach Changetypen ITL und ASL sind prozessbasierte Ansätze. Der Change-Prozess sollte demnach bezüglich

seiner Abläufe, Rollen und Artefakte konkret ausgeprägt werden. Jedoch zeigte sich im Zuge der

Schwachstellenanalyse in den Prozessphasen, dass es Faktoren gibt, die einen

unterschiedlichen Change-Prozess bedingen. Das sind nicht nur die nach ITIL vorgesehenen

Faktoren Auswirkung, Umfang und Ressourcen. Aus den ITIL-Workshops der Geschäftseinheit

Informationstechnologie ergaben sich weitere Einflussgrößen für einen unterschiedlichen

Prozessablauf. Zum einen wird der Ablauf durch die Anwendungskategorie bestimmt, wie das

Beispiel zu Standard- und Nichtstandardanwendung in Abschnitt 4.2 Hauptkategorie Prozess

zeigt. Zum anderen hängt ein unterschiedlicher Prozess auch von den die Anwendungskategorie

unterstützenden Subservices ab, welche z.B. durch die Abteilung „IT-Services“ bereitgestellt

werden. Die Subservices und die mitwirkenden Rollen haben eine Auswirkung auf die

Zusammensetzung des CAB. Unter Berücksichtigung dieser Faktoren werden Changetypen

entwickelt. Jeder Changetyp unterliegt einer größtmöglichen Kapselung gemeinsamer Abläufe

und Rollen. Es sind die ITIL-typischen Kriterien zu Umfang, Ressourcen und Auswirkung zu

definieren und daraus für jeden Changetyp verschiedene Prozessausprägungen zu entwerfen.

45 Die kompletten 9 Maßnahmen sind in der Bachelor Thesis beschrieben.

Abbildung 11: Basis für ein strukturiertes Identifizieren von optimierenden Maßnahmen. , Quelle: eigene Darstellung.

17

Kleine Changes mit geringen Auswirkungen benötigen sicherlich weniger Verwaltungstätigkeiten

als komplexere Changes. Es wird sichergestellt, dass für die entsprechenden

Anwendungskategorien ein jeweils auf diese angepasster und optimierter Prozess entworfen

wird. Abbildung 12 illustriert einen möglichen Ablauf zur Bestimmung nach welchem definierten

Prozess ein Change durchgeführt werden soll. Dies sollte anhand einer Checkliste erfolgen.

Die Aufbereitung und Veröffentlichung sollte über das Intranet stattfinden. Die Checklisten zur

Einordnung des vorliegenden Changetyps mit den zugehörigen Prozessen bilden die Grundlage

für die Strukturierung der angebotenen Services. Verantwortlichkeiten und Aufgabengebiete

werden so klar geregelt. Der Aufwand zur Strukturierung und Erstellung der Prozesse in

Zusammenarbeit mit den Mitarbeitern der Geschäftseinheit Informationstechnologie ist hoch. Die

Mitarbeiter müssen intensiv für die neuen Prozesse geschult werden.

Die Prozessphasen mit den größten Kritikalitäten finden bei der Prozesserstellung besondere

Beachtung und werden entsprechend detailliert definiert. Dadurch ist mit einer Verbesserung der

Anforderungs- und Impactanalyse zu rechnen. Die Prozesse werden zum Standard bei der

Durchführung eines Change von IT-Applikationen. Es existiert ein einheitliches

Vorgehensmodell. Durch die umfangreichen Schulungen aller am Prozess beteiligten Mitarbeiter

ist mit einer besseren Wahrnehmung der Vorgaben zu rechnen.

Abbildung 12: Ablauf zur Bestimmung des auszuführenden Change-Prozesses, Quelle: eigene Darstellung.

18

5.3 Ergebnisse aus Aufwands- und Nutzenbetrachtung In diesem Abschnitt werden die Ergebnisse der Nutzwertanalyse vorgestellt. Es werden die

Phasen „Gesamtsumme der Nutzen der Wertsynthese“, „Rangfolge“ und „Betrachtung des

Aufwands“ abgedeckt. Tabelle 3 zeigt den beispielhaften Aufbau der Nutzwertanalyse nach dem

nach diesen Phasen.

Das Blasendiagramm in Abbildung 14 zeigt die Ergebnisse der Nutzwertanalyse unter

Betrachtung des Aufwands. Die X-Achse repräsentiert den Aufwand und die Y-Achse den

Gesamtnutzen. Die Blasen symbolisieren die Maßnahmen. Dabei wird die Größe der Blasen

durch die Anzahl an Schwachstellenkategorien mit einer Gewichtung größer als 7,5% und einem

Zielertrag von 2 oder 3 bestimmt, analog zu den Maßnahmenabbildungen im vorherigen

Abschnitt. Auf diese Weise gewinnt zusätzlich zum ermittelten Gesamtnutzen einer Maßnahme

auf der Y-Achse die Anzahl adressierter schwerpunktmäßiger Schwachstellenkategorien an

Bedeutung.

Abbildung 13: Maßnahme – „Einführen von Changetypen und Definieren der Prozesse nach Changetypen“, Quelle: eigene Darstellung.

Tabelle 3: exemplarische Darstellung der Nutzwertanalyse

19

Den größten Nutzen bringt das „Einführen von Changetypen und Definieren der Prozesse nach

Changetypen“. Hierbei werden vier Schwachstellenkategorien mit hohen Kritikalitäten adressiert.

Allerdings ist das auch mit einem hohen Aufwand verbunden. Die Maßnahmen, welche mit

relativ geringem Aufwand einen hohen Nutzen erzielen, sind der „Servicekatalog“, die „SLA’s“

und das „SLA Monitoring“. Diese Maßnahmen setzen bei zwei bzw. drei der

Schwachstellenkategorien mit hohen Kritikalitäten an und sind damit die Quick Wins für die

Optimierung des „Change-Prozesses von IT-Applikationen“. Die „CMDB“ und das „Tool zur

Integrierung der Abteilungen“ haben einen sehr hohen Aufwand und eher moderaten Nutzen.

Sie adressieren beide jeweils nur zwei schwerpunktmäßige Schwachstellenkategorien. Der

„Change Manager in Verbindung mit dem FSC“ ist mit einem hohen Aufwand verbunden. Der

Nutzen ist mittelmäßig bis hoch bei drei adressierten Schwachstellenkategorien hoher Kritikalität.

Die „Templates“ haben einen hohen Nutzen, sind aber sehr aufwendig. Sie würden an vier

schwerpunktmäßigen Schwachstellenkategorien ansetzen. Die „Funktion zum Erreichen einer

verursachungsgerechten Kostenzuordnung“ hat einen sehr geringen Aufwand, jedoch auch

einen ebenso geringen Nutzen. Es werden zwei Schwachstellenkategorien hoher Kritikalität

adressiert.

Abbildung 14: Aufwand und Nutzen der Maßnahmen, Quelle: eigene Darstellung.

20

6 Ergebnisanalyse

6.1 Handlungsempfehlung Im vorherigen Kapitel konnte aufgezeigt werden, dass die identifizierten Maßnahmen potenziell

in der Lage sind, kritische Optimierungsbereiche zu adressieren. Die Frameworks ITIL und ASL

bieten gute, aber recht generische Ansätze. Es zeigte sich jedoch, dass eine konkrete

Ausprägung der Maßnahmen nur unter Berücksichtigung der unternehmenseigenen Aspekte der

BSR möglich ist.

Wie in Abschnitt 5.1 angedeutet sind die diskutierten Maßnahmen nicht als komplette

Alternativen zu sehen. Einige Maßnahmen benötigen für ihre Umsetzung andere Maßnahmen

als Voraussetzung. Aus der Kombination verschiedener Maßnahmen kann deren Teilnutzen

einen größeren Gesamtnutzen ergeben. Rechnerisch ist die Bestimmung eines Gesamtnutzens

einer Maßnahmenkombination sehr hypothetisch. Wenn zwei Maßnahmen die gleichen

Kategorien adressieren kann eine Kombination dieser Maßnahmen zu einem doppelten Nutzen

führen, oder aber die Maßnahmen sind substitutiv. Dazu ist eine nähere inhaltliche Betrachtung

der Maßnahmen auf mögliche Kombination und Nutzenerweiterung notwendig. Jedoch sind die

Aufwände einer Maßnahme aufsummierbar. Die Anzahl der Schwachstellenkategorien hoher

Kritikalität, die durch eine Maßnahmenkombination adressiert werden, sind ebenfalls

bestimmbar. Es ist also erstens, unter Beachtung der Abhängigkeiten unter den Maßnahmen,

die Kombination von Maßnahmen herauszufinden, die das beste Aufwand-Nutzen-Verhältnis

ergibt. Zweitens ist die Reihenfolge der Umsetzung der Maßnahmen dieser Kombination zu

bestimmen.

Aus Abschnitt 5.3 können die Maßnahmen mit dem besten Aufwand-Nutzen-Verhältnis ermittelt

werden. Zu diesen Quick Wins zählen der „Servicekatalog“, das „Definieren der SLA’s“ sowie

das „SLA Monitoring“. Um eine schrittweise Optimierung, wie es besonders ASL vorsieht, zu

ermöglichen, sollten diese unbedingt umgesetzt werden. Es treten bei diesen drei Maßnahmen

Abhängigkeiten auf. Der Servicekatalog ist die Grundlage zur Erstellung von individuellen SLA’s

mit den Fachbereichen. Die SLA’s wiederum sind die Voraussetzung für ein SLA Monitoring.

Dabei enthält der Servicekatalog Beschreibungen und Verantwortlichkeiten zu den Services. Die

Grundlage für den Servicekatalog ist eine Strukturierung der Services und deren Komponenten.

Aus Sicht der BSR-Anwendungsbetreuung stellt das „Einführen von Changetypen und

Definieren der Prozesse nach Changetypen“ die Voraussetzung dieser Strukturierung dar. Die

dort vorgesehene Kategorisierung der Anwendungen nach unterschiedlichen Prozessen zu

Changetypen ist die Basis für strukturierte Services der Anwendungsbetreuung. Die konkreten

Verantwortlichkeiten ergeben sich erst durch die wohl definierten Prozesse nach den

Changetypen. Überdies stellen die Prozesse der Changetypen eine auf die spezielle

Anwendungskategorie, die zu integrierenden Rollen und die beteiligten

21

Infrastrukturkomponenten angepasste Optimierung der Abläufe dar. Die Voraussetzung für einen

Servicekatalog einerseits und die Optimierung der Abläufe andererseits machen das „Einführen

von Changetypen und Definieren der Prozesse nach Changetypen“ zu einer unverzichtbaren

Einstiegsmaßnahme bei der Optimierung des „Change-Prozesses von IT-Applikationen“. Die

Maßnahme ist zwar mit einem hohen Aufwand verbunden, hat aber auch den höchsten

Gesamtnutzen von allen diskutierten Maßnahmen.

Mit den Changetypen und den zugehörigen Prozessen als Grundlage lassen sich relativ zügig

die drei Quick Win-Maßnahmen nacheinander umsetzen. Die sich daraus ergebende

Maßnahmenkombination adressiert alle schwerpunktmäßigen Schwachstellenkategorien mit

einer Kritikalität größer als 7,5 Prozent (siehe Abschnitt 5.2). Prinzipiell dienen die drei Quick

Win-Maßnahmen zum nachhaltigen Etablieren der definierten Prozesse nach den Changetypen.

Die Mitarbeiter würden durch die definierten und ausgewerteten SLA-Kennzahlen eine

anhaltende Motivation zur Umsetzung der Prozesse nach Changetypen erfahren. Daher ergibt

diese Maßnahmenkombination inhaltlich eine optimale Ergänzung der einzelnen Nutzen jeder

Maßnahme. Abbildung 15 zeigt die Handlungsempfehlung für die Geschäftseinheit

Informationstechnologie der BSR.

Nach den Kriterien „Nutzenerweiterung nach inhaltlicher Prüfung“, „Summe des Aufwands“ und

„Anzahl adressierter schwerpunktmäßiger Schwachstellenkategorien“ ist die empfohlene

Maßnahmenkombination für die Optimierung des „Change-Prozesses von IT-Applikationen bei

den BSR“ am meisten geeignet.

Abbildung 15: Roadmap zur Optimierung des Change-Prozesses von IT-Applikationen bei den BSR, Quelle: eigene Darstellung.

22

Alle anderen Maßnahmen ergeben nach diesen Kriterien eine weniger optimale Kombination.

Die Handlungsempfehlung könnte als erste Phase der Optimierung des „Change-Prozesses von

IT-Applikationen“ angesehen werden. Nach einer bestimmten Produktivphase könnten auf Basis

des SLA Monitoring erneut Schwachstellen identifiziert werden und darauf aufbauend weitere

optimierende Maßnahmen eingeleitet werden.

6.2 Kritische Betrachtung der Ergebnisse Nachfolgend sollen die Ergebnisse dieser Arbeit eingeordnet und unter besonderer

Fokussierung auf systematische Unschärfen in der methodischen Vorgehensweise kritisch

gewürdigt werden.

Interviews Aus der ursprünglichen Orientierung des Projektes zu dieser Arbeit an dem BSR-Projekt „ITIL

v2“, resultierte die Aufgabe den Change-Prozess innerhalb der Geschäftseinheit

Informationstechnologie zu betrachten. ITIL sieht in dem Zusammenhang das effiziente

Gestalten der IT-Prozesse innerhalb der IT-Organisation vor. Demnach beziehen sich die

Interviews der Ist-Analyse auf die Rollen aus der Geschäftseinheit Informationstechnologie. IKS-

Koordinatoren und Anwender wurden nicht nach Schwachstellen befragt.

Schwachstellenanalyse Die Zielkriterien der Nutzwertanalyse (Schwachstellenkategorien) sind nicht vollständig

orthogonal, so wie es die Nutzwertanalyse vorsieht. Dennoch entstand die Kategorisierung der

Schwachstellen unter der Prämisse größtmöglicher Kapselung gemeinsamer Eigenschaften bei

hohem Detaillierungsgrad der Kategorien. Es wurden möglichst viele, größtenteils voneinander

unabhängige Schwachstellenkategorien entwickelt. Damit wurde eine nahezu autarke

Bewertung der Kritikalitäten der Schwachstellenkategorien ermöglicht.

Maßnahmenidentifikation Die Identifizierung der Maßnahmen erfolgte auf Grundlage der in Abschnitt 5.2 erläuterten

Vorgehensweise. Trotz dieser methodischen Herangehensweise verbleibt ein wesentlicher Anteil

an Brainstorming zur Identifizierung von Maßnahmen. Es besteht demnach die Möglichkeit, dass

es weitere optimierende Maßnahmen gibt, welche nicht berücksichtigt wurden. Das wird

verstärkt durch den Aspekt, dass durch die oben genannte Beschränkung der Interviews auf die

Rollen aus der IT-Organisation einige Maßnahmen nicht in Betracht gezogen wurden. Wären

diese Maßnahmen hinzugenommen worden, so wäre die Bewertung des Nutzens bezüglich der

benannten Schwachstellen und ihrer Kritikalität vermutlich nicht ausreichend untermauert

gewesen. Solch eine Maßnahme ist z.B. die Einführung eines Single Point of Contact für die

Anwendungsbetreuung.

Bewertung von Kritikalität und Maßnahmen Die Parameter der Kritikalität wurden mit dem Wertebereich (1-3) grob gewählt. Eine konkrete

und vollständige Definition eines detaillierten Bewertungsmaßstabes wäre im Rahmen der Arbeit

23

zeitlich nicht möglich gewesen. Da sich die Kritikalität letztlich aus den vier Faktoren Ausmaß

und Auswirkung in Bezug auf Termine, Kosten sowie Qualität zusammensetzt, wurde eine

ausreichende Abstufung erreicht, um kritische Schwachstellenkategorien von weniger kritischen

zu trennen.

Des Weiteren erfolgte die Schätzung des Aufwands für die einzelnen Maßnahmen mit einer

bestimmten Unschärfe. Eine detaillierte Feinplanung und die damit einhergehende Ermittlung

des Aufwands ist erst im Rahmen der Projektplanung für die Umsetzung der Maßnahmen

konkret möglich. Ziel war es, dass die Relationen der Aufwände in der Größenordnung

annähernd stimmen.

Ergebnisse der Nutzwertanalyse In der Nutzwertanalyse wurde aus Zeitgründen auf die Durchführung einer ausführlichen

Sensitivitätsanalyse verzichtet. Mit deren Hilfe hätten die definierten Formeln, gewählte

Bewertungsbereiche und daraus resultierende Ergebnisse auf sich ergebende unterschiedliche

Schlussfolgerungen überprüft werden können. Damit hätte die Robustheit des Ergebnisses

untermauert werden können.

24

7 Fazit Die vorliegende Arbeit fokussiert auf eine Optimierung des „Change-Prozesses von IT-

Applikationen bei den BSR“. Dazu wurde eine Nutzwertanalyse verschiedener optimierender

Maßnahmen durchgeführt. In den Phasen der Nutzwertanalyse wurden die eingangs definierten

Ziele zu einem hohen Grad erreicht.

In der Phase „Zielkriterien und Gewichtung“ wurden die aus den Interviews und der Auswertung

der Datensätze aus dem Ticketsystem extrahierten Schwachstellen ursachenbezogenen

Kategorien zugeordnet. Anschließend wurden diese Kategorien hinsichtlich ihrer Kritikalität

bewertet. Damit ist eine aggregierte, aus der IT-organisationinternen Perspektive vollständige

Übersicht zu den Schwachstellen und deren Bedeutung für eine Optimierung des Change-

Prozesses entstanden.

Die Phase „Maßnahmen und deren Nutzwert“ hatte die Identifikation geeigneter, optimierender

Maßnahmen zum Inhalt. Dazu wurden die Frameworks ITIL, aufgrund seiner Eignung für

standardisierte Service-Erbringung, und ASL, für eine anwendungsfokussierte Sicht dieser

Service-Erbringung, betrachtet. Für die konkrete Ausprägung der Maßnahmen wurden BSR-

spezifische Ansätze, die sich größtenteils aus den identifizierten Schwachstellenkategorien

ergaben, hinzugezogen. Auf dieser Grundlage wurden neun Maßnahmen entwickelt und deren

Potenzial für eine Optimierung (Nutzen) sowie deren Aufwand aufgezeigt.

In der Ergebnisanalyse entstand eine Handlungsempfehlung für die Geschäftseinheit

Informationstechnologie. Hier wurde die grundlegende Maßnahme „Einführen von Changetypen

und Definieren der Prozesse nach Changetypen“ mit den drei Quick Win Maßnahmen in der

Reihenfolge „Definieren eines Servicekataloges“, „Definieren von SLA’s“ und „SLA Monitoring“

verknüpft. Das geschah mittels einer inhaltlichen Betrachtung auf eine Erweiterung des Nutzens

durch Kombination der Maßnahmen.

ITIL und ASL bieten gute strukturelle, aber inhaltlich nicht genügend konkrete Ansätze für eine

Standardisierung und Optimierung der IT-Prozesse bei den BSR. Eine auf das individuelle

Unternehmen bezogene Ausprägung kann nur unter einem erheblichen analytischen und

konzeptionellen Aufwand betrieben werden. Daher ist der, besonders durch das Framework ASL

gegebene, Ansatz zur Verbesserung in kleinen Schritten zu berücksichtigen. Die

Handlungsempfehlung dieser Arbeit setzt diesen Ansatz mit den vier empfohlenen Stufen um.

Eine laufende Messung von Verbesserungen und eine fortgesetzte Neubewertung nach jeder

Phase ist auf jeden Fall angeraten.

25

Literaturverzeichnis

Elsässer, Wolfgang (2006): ITIL Einführen und Umsetzen, 2. erweiterte Auflage, München 2006.

Färbinger, Peter [Hrsg.] (2007 a): IT-Kehraus in der Industrie, in: E-3 – Efficient Extended Enterprise, No. 5, 2007, S. 40.

Färbinger, Peter [Hrsg.] (2007 b): Mit ITIL Zertifizierungen zur optimalen Steuerung, in: E-3 – Efficient Extended Enterprise, No. 5,

2007, S. 68.

Köhler, Peter (2005): ITIL, Berlin u.a. 2005.

Kresse, Michael u.a. (2005): IT Service Management Advanced Pocket Book, Hürth 2005.

Linnartz, Walter u.a. (2004): Application Management Services und Support, Erlangen 2004.

Office of Government Commerce (2003 a): Service Delivery CD-ROM, Grossbritannien/ Norwich 2003.

Office of Government Commerce (2003 b): Service Support CD-ROM, Grossbritannien/ Norwich 2003.

Office of Government Commerce (2006): Application Management, 4. Auflage, Grossbritannien/ Norwich 2006.

Renner, Bernhard u.a. (2006): IT Service Management Transparente IT-Leistungen & messbare Qualität, Rheinfelden/ Schweiz

2006.

Rigall Juan, Wolters Georg (2005): Change Management für Konzerne. Komplexe Unternehmensstrukturen erfolgreich verändern,

Düsseldorf 2005.

26

Schäfer, Marc/ Melich Matthias (2006): SAP Solution Manager, Bonn 2006.

Schneider, Karl-Heinrich (2004): Betriebswirtschaftslehre, Troisdorf 2004.

Van der Pols, Remko (2004): ASL a Framework for Application Management, Niederlande 2004.

27

Internet/ Intranetverzeichnis

Internet

ASL Foundation (2005): ASL Best Practices, abgerufen am: 02.06.2007,

http://www.aslfoundation.org/uk/asl/asl_bestpractices.htm.

Fischer, Arne/ Stolpmann, Björn Eric (2005): IT-Service-Management im IT-Support für Schulen – Einordnung in das IT-Management des

Schulträgers, abgerufen am 12.06.2007,

http://www.egovernment-akademie.de/academy/content/medien/ifib_381-1.pdf.

Freericks, C. (2006): Vorgehensmodell „V-Modell“, abgerufen am 28.05.2007,

http://www.informatik.uni-bremen.de/gdpa/part3_d/p3si.htm.

Glenfis AG (2006): ISO/IEC 20000 IT Service Management Standard, abgerufen am 20.05.2007,

http://www.itil.org/de/isoiec20000/index.php.

Krems, Burkhardt (2004): Nutzwertanalyse, abgerufen am 08.06.2007,

http://www.olev.de/n/nwa-kurz.htm.

Meijer, Machteld u.a. (2005): ASL and ITIL: powerful together, abgerufen am 15.05.2007,

http://www.aslfoundation.org/uk/asl/publicaties.htm#Publications/en_ITSM_BP_2005-

5.5_ASL_and_ITIL_powerful_ together_V2.pdf.

Meijer, Machteld/ Meijer, Harry (2004): How can I improve my application services, abgerufen 15.05.2007,

http://www.aslfoundation.org/uk/asl/publicaties.htm#Publications/en_ITSMF_2004-

20_How_can_I_improve_my_application_services_V2_01.pdf.

Scholles, Frank (2006): Die Nutzwertanalyse und ihre Weiterentwicklung, abgerufen am 08.06.2007,

http://www.laum.uni-hannover.de/ilr/lehre/Ptm/Ptm_BewNwa.htm.

28

Schultetus, Wolfgang (2005): Nutzwertanalyse, abgerufen am 08.06.2007,

http://archiv.tu-chemnitz.de/pub/2005/0025/data/Nutzwert.pdf.

Smalley, Mark (2006): ITIL Interfaces with Global Standards – Asl v2, abgerufen am 15.05.2007,

http://www.aslfoundation.org/uk/asl/publicaties.htm#Publications/ ITIL Interfaces with Global

Standards – Asl v2.pdf.

Thompson, Michael (2006): Have You Catalogued Your IT Services, abgerufen am 25.05.2007,

http://www.servicecatalogs.com/WikiHome/Resources/Resource24.

Wazeck, Jürgen (2005): Projektplanung und Projektoptimierung mit MS Project 2003, abgerufen am 08.06.2007,

http://www.teialehrbuch.de/Kostenlose-Kurse/Projektplanung-mit-MS-Project-2003/25213-

Vorgehensweise-Nutzwertanalyse.html

Intranet BSR (2007): IKS-Koordinatoren, abgerufen am 10.05.2007,

http://intranet.bsr.de/reddot/IKS-Koordinatoren.php.