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