Change Management von IT Applikationen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
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 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 nachzulesen9 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 nachzulesen12
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
beschrieben14 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
