Change Management von IT Applikationen

Die Seite wird erstellt Daniel Mann
 
WEITER LESEN
Change Management von IT Applikationen
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.
Change Management von IT Applikationen
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

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

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.
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.

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

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
                                    16
      Lösungsalternativen.

      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).
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-
                                                                                                                             18
     Verhältnisses der Alternativen getätigt werden, um die optimale Alternative zu ermitteln.
     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-
                                                                                                              20
Kernmodulen Service Support und Service Delivery abgestimmt ist.                                                   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

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

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.
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: Überblick über die Prozesse des ASL Frameworks, Quelle: ASL Foundation (2005) (siehe Internet- /
Intranetverzeichnis).

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.
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

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

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
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.

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

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
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.

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

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).
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
   Abbildung 6: Ursächliche Hauptkategorien der
   Schwachstellen, Quelle: eigene Darstellung.             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).
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:
Kritikalität = Ausmaß × ( AuswirkungTer min + AuswirkungKosten + AuswirkungQualität )
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.

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

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
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.

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

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
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.

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

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

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

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).
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

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

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.
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.

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

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.
18

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

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.

Tabelle 3: exemplarische Darstellung der Nutzwertanalyse

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.
19

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

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.
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.

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

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.
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.
Sie können auch lesen