IT-organisation eines konzerns

Einleitung

Motivation

Als eigenständig agierende IT-Organisation eines Konzerns, der weltweit operiert, bestehen zahllose Herausforderungen bezüglich der Messbarkeit, Kontrollierbarkeit und Transparenz der angebotenen IT-Services. Bezugnehmend auf die Entwicklungen der jüngeren Vergangenheit hat sich das kontrollierte Prozessmanagement als hilfreiches Werkzeug, diese Anforderungen abdecken zu können, etabliert. Klar definierte Maßnahmen und Vorgehensweisen stellen mittlerweile, neben bedarfsgerechter Ressourcenplanung sowie interner und externer Leistungsverrechnung, eine der Grundsäulen des stabilen IT-Betriebs dar. Bei der Leistungserbringung von IT-Services lässt sich mitunter eine weitere Tendenz verzeichnen, nämlich, dass der wirtschaftliche und betriebliche Fokus in Richtung der Kundenorientierung wächst. Das Bestreben seinen Endbenutzern qualitativ hochwertige Services zur rechten Zeit, am rechten Ort und zu einem lukrativen Preis anbieten zu können steht im Vordergrund vieler IT-Organisationen. Einhergehend mit der Etablierung des gezielten Prozessmanagements als eigene Managementdisziplin verstärken sich ebenfalls die Möglichkeiten der Prozessoptimierung, die neben der organisationalen auch die wirtschaftliche Betrachtung, des Themas interessant macht. Das Grundprinzip Leistung zu messen um Steigerung zu forcieren ist seit jeher eine vielseitig aufgegriffene Managementdirektive. Das messbar machen von Dienstleistungen und Vorgängen birgt jedoch weitaus mehr Potential als eine reine Optimierung der Kapazitäts- oder Ressourcenauslastung. Durch das Verwenden standardisierter Prozesse eröffnet sich, im Sinne der Kundenorientierung, eine neue Möglichkeit für Transparenz. Diese zeichnet sich durch klar definierte Verantwortlichkeiten und Schnittstellen sowie mit dem Kunden oder Anwender vereinbarte Dienstleistungen aus. Dies limitiert außerdem Interpretationsmöglichkeiten bei der Leistungserbringung, was in direkter Folge den Ausgang des Prozesses plan- und kontrollierbarer macht. Diese und weitere Vorteile, die sich durch das Einsetzen von Prozessmanagement ergeben, stellen eine nicht außer Acht zu lassende Motivation für Unternehmungen dar ihre Prozesswelt zu kultivieren und zu optimieren.

Werkzeuge

Bei der Umsetzung dieses Unterfangens stehen den Organisationen jedoch Werkzeuge zur Verfügung, die die Einführung, Entwicklung und Kontrolle von Prozessen erleichtern. Eines dieser Instrumente, das sich über die letzten Jahre hinweg, am Markt der IT-Serviceerbringung etabliert hat ist das ITIL (IT Infrastructure Library) Framework. Unter Zuhilfenahme dieser Best-Practice-Sammlung werden im Zuge dieser Arbeit neue Prozesse entwickelt und in einer realen IT-Organisation eingeführt. Um die Praxisrelevanz dieser These zu unterstreichen wird diese im Rahmen der Firmentätigkeit des Autors im Bereich Infrastrukturmanagement der UniCredit Direct Services GmbH erstellt. Dem ist hinzuzufügen, dass keine Umsetzung der gesamt gesammelten ITIL Maßnahmen angedacht ist, sondern lediglich ein isoliertes Auswählen von Vorgehensweisen um angebotene Dienstleistungen stabiler, transparenter und anwenderfreundlicher zu gestalten. Unterstützend begleitet wird dieses Vorhaben durch den Einsatz einer Softwarelösung der Firma ConSol, die bedarfsgerecht abgeändert und ebenfalls eingeführt wird.

Methodik & Vorgehensweise

Die Aufteilung dieser Arbeit kann folgendermaßen vollzogen werden: Nach einer Einführung in die verwendeten Werkzeuge und theoretischen Grundlagen der Materie, wird ein Ist-Zustand der vorhandenen Prozesswelt ermittelt. Diese Momentaufnahme wird analysiert und mit einem Reifegradmodell versehen. Aus diesem Modell wird der Handlungsbedarf zur Optimierung einzelner Prozesse aufgezeigt. Anschließend werden zwei ausgewählte Prozesse unter Zuhilfenahme des ITIL-Frameworks innerhalb der UniCredit Direct Services GmbH eingeführt. Bei der weiterführenden Betrachtung der entwickelten Prozesse werden schlussendlich die wirtschaftlichen Aspekte beleuchtet sowie ein Resümee über den Verlauf und den Ausgang des Projekts gezogen.

Bei der verwendeten didaktischen Methode handelt es sich um eine vergleichende Literaturrecherche von Fachliteratur und firmeninternen Unterlagen, welche analysiert werden und maßgeblich die Gestaltung des theoretischen Teils beeinflussen.

Situationsbeschreibung

Firmentext UCDS

Problemstellung

Problembeschreibung

ITIL Framework

Um ein Grundverständnis für ITIL (IT Infrastructure Library) als Werkzeug im gezielten Prozessmanagement herzustellen wird in diesem Abschnitt auf die geschichtliche Entwicklung, den Aufbau sowie einzelne Prozesse eingegangen. Bei der Beschreibung handelt es sich allerdings streng um jene Prozesse, die in der ITIL Version 2 angeführt sind. Dies begründet sich dadurch, dass sich jene Prozesse vor allem auf IT Service Delivery und IT Service Support konzentrieren.

Entstehung

Auf Initiative des britischen Amts CCTA (Central Computer and Telecommunications Agency) wurde um 1980 ein Verfahren entwickelt, das sich mit dem Management von IT Ressourcen auseinandersetzt. Ziel war es einen möglichst zweckmäßigen und wirtschaftlichen Umgang mit den vorhandenen Kapazitäten zu forcieren und eine Unabhängigkeit gegenüber Dienstleistern zu etablieren.

„Das Verfahren sollte sicherstellen, dass die Unabhängigkeit gegenüber Dienstleistern gewährleistet wird. Dieser Auftrag mündete letztendlich in der Information Technology Infrastructure Library, kurz ITIL: eine Sammlung von »Best Practicesù, welche im Bereich der IT-Services Anwendung fanden. [...] Bereits Mitte der 1990er Jahre lagen schon mehr als 40 Bände vor. Seit 2000 erfolgt die Herausgabe der Buchreihe durch das OGC (UK Office of Government Commerce). Und die Entwicklung von ITIL läuft ständig weiter."

Bis heute wird die ITIL Bibliothek von verschiedenen Einflüssen maßgeblich geprägt. Abbildung 1 zeigt eine übersicht verschiedener Faktoren, die bei der Gestaltung der ITIL-Bücher Einfluss haben.

Der nachfolgende Abschnitt widmet sich den treibenden Kräften, die hauptsächlich an der Aktualierung von ITIL beteiligt sind.

Hauptakteure hinter ITIL

Um die ständige Weiterentwicklung der ITIL Bibliothek sicherzustellen haben sich über den Verlauf der letzten Jahrzehnte vor allem vier Organisationen, die mittlerweile als Grundpfeiler der ITIL Architektur gesehen werden können, etabliert.

OGC

„ITIL war ursprünglich ein Produkt der CCTA (Central Computer and Telecommunications Agency), einer Organisation der britischen Regierung. Seit 2001 ist die CCTA in die OGC übergegangen, die damit neuer Eigentümer von ITIL wurde. Die OGC fördert die Anwendung von »Best Practicesù und ist Herausgeber von IT Infrastructure Library, kurz ITIL."

Es ist dabei zu Betonen, dass das OGC als unabhängige Behörde der britischen Regierung agiert, die in erster Linie für die Beschaffungsplanung eingesetzt ist. Unterstellt ist das OGC lediglich dem britischen Finanzministerium.

itSMF

1991 wurde das erste IT-Service.Management-Forum (itSMF) in England gegründet. Mittlerweile findet sich das itSMF in zahlreichen Nationen (GB, USA, DE, AUS, CAN usw.) wieder. Das itSMF ist eine unabhängige Non-Profit-Organisation, die vollständig durch die Mitglieder (Privatpersonen, Unternehmen, Behörden, Hersteller) betrieben und kontrolliert wird.

Das itSMF versteht sich als Netzwerk von internationalen ITIL Spezialisten, die einen koordinierten Ansatz für das Thema IT Service Management vertreten.

EXIN & ISEB

„EXIN (Exameninstituut voor Informatica) und ISEB (Information Systems Examination Board) sind international tätige, unabhängige und von der OCG beauftragte Anbieter von IT-Prüfungen, die sich u.a. mit der Entwicklung von Qualifizierungsstandards für ITIL beschäftigen. Sie entwickeln gemeinsam in Zusammenarbeit mit der OGC und dem itSMF Zertifizierungsprüfungen für ITIL."

Es bleibt darauf hinzuweisen, dass es sich bei EXIN und ISEB lediglich um jene Organisationen handelt, die Zertifizierungsprüfungen gestalten. Die Abnahme dieser Zertifikate kann durchaus von externen Partnern durchgeführt werden. Im deutschsprachigen Raum wäre dies zum Beispiel die Informationstechnologiegruppe des TüV Süd.

Aufbau von ITIL

Die fünf Hauptbereiche, in die untergliedert wird, sind wie folgt benannt:

  • The Business Perspective (Die geschäftliche Perspektive)
  • Service Delivery (Planung und Lieferung von IT-Services)
  • Service Support (Unterstützung und Betrieb der IT-Services)
  • Infrastructure-Management (Management der Infrastruktur)
  • Applications-Management (Management der Anwendungen)

Business Perspective

Wie Bock et al., Seite 23 ff, zeigen, behandelt diese Bücherreihe jene Themenkreise, die sich mit dem Verständnis und der Verbesserung der IT-Services als integrale Bestandteile des Management eines Unternehmens (Business-Management) befassen. Verwandte Gebiete sind aus der wirtschaftlichen Perspektive ebenfalls:

  • Kontinuitäts-Management
  • Partnerschaften und Outsourcing
  • Bewältigung von änderungen

Freilich sind diese Prozesse nicht nur aus geschäftlicher Perspektive zu betrachten. Durch die rege Vernetzung der verschiedenen ITIL-Disziplinen stehen diese Best-Practices unter starker Abhängigkeit mit anderen Bereichen der fünf Hauptgebiete.

Service Delivery

Dieser Prozess spielt vor allem im operativen Bereich von IT Organisationen eine maßgebende Rolle. Durch die Bestimmung wie IT-Services geplant und geliefert werden, wird an der positiven Etablierung des IT Dienstleisters, sei dieser extern oder intern, als kalkulierbarer Mehrwert für das Gesamtunternehmen gearbeitet. Dieser Prozess inkludiert Tagesgeschäft, sowie strategische Aufgabenbereiche, die von Bock et al., auf Seite 24, wie folgt zusammengefasst werden.

  • Service-Level-Management
  • Financial-Management
  • Capacity-Management
  • Availability Management
  • Continuity-Management

Da dieser Prozess für die Umsetzung dieser Arbeit essentiell ist, wird auf die angeführten Punkte noch in einem eigenen Kapitel eingegangen.

Service Support

Unter dem Begriff Service Support versteht ITIL jene Maßnahmen, die für den reibungslosen Betrieb der angebotenen IT-Services, vorgesehen sind. Bock et al. klassifizieren auf Seite 25ff folgende Managementdisziplinen, die dem Prozess Service Support untergeordnet sind:

  • Service Desk
  • Incident-Management
  • Problem-Management
  • Configuration-Management
  • Change-Management
  • Release-Management

Ebenso wie der Service Delivery Prozess, ist der Service Support unerlässlich beim Betreiben eines kundenorientierten Service Dienstleisters, weshalb diesem ein eigenes Kapitel gewidmet ist.

Infrastructure-Management

Der Prozess des IT-Infrastructure-Managements besteht aus einer Vielzahl von Unterprozessen, die sich mit der Aufrechterhaltung und Bewahrung von IT Infrastrukturen befassen. ITIL betrachtet hierbei sowohl einen operativen als auch einen organisatorischen Ansatz. Grob lassen sich die dem Infrastructure-Management zugeteilten Prozesse in folgende Management Disziplinen unterteilen:

  • Network-Service-Management
    • umfasst die Planung und Steuerung von Kommunikationsnetzwerken
  • Operations-Management
    • umfasst die Verwaltung und den Betrieb von Hardware und System-Software
  • Computer Installation and Acceptance
    • umfasst die Erstellung von Richtlinien zur Planung der Abnahme, der Installation und der Deinstallation von Computersystemen innerhalb der IT Infrastruktur
  • Management of Local Processors
    • umfasst die Planung von dezentralen IT-Systemen mit dem Ziel, die IT-Services vor Ort beim Kunden beziehungsweise Anwender zu unterstützen
  • Systems-Management
    • umfasst die Planung von IT-Systemen mit dem Ziel einer optimalen Betreuung der einzelnen Systeme
  • Environmental-Management
    • umfasst die Planung der optimalen Umgebungsbedingen nach den geltenden Richtlinien für die IT-Infrastruktur (zum Beispiel: Strom, Klima, etc ...)

Applications-Management

Das Applications-Management beschreibt den Umgang mit der Veränderung von IT-Services. Für einen geordneten Ablauf dieser änderungen sieht ITIL, wie Bock et al. auf Seite 27, zeigen, zwei Hauptprozesse vor.

  • Software-Lifecycle-Support
  • Hierbei versteht man die Festlegung einer abgestimmten Vorgehensweise bezüglich sämtlicher Arbeiten an einem Programm während des gesamten Lebenszyklus. Sämtliche Phasen des Lebenszyklus wie zum Beispiel Entwurf, Erstellung, Testen, Einsatz bzw. Betrieb, Wartung und letztendlich Deinstallation bedürfen spezieller Vereinbarungen innerhalb der IT und natürlich auch Vereinbarungen mit dem Anwender selbst.

  • Testing an IT-Service for Operational Use
  • Dieser Vorgang beschreibt die überprüfung neuer oder geänderter IT-Services vor dem Einsatz. Es wird dabei mittels System-, Installations- und Abnahmetests untersucht, ob die entwickelte Anpassung funktioniert, korrekt installiert ist und zur restlichen IT-Infrastruktur passt. Ebenfalls gilt es, alle mit dem Auftraggeber vereinbarten Funktionen des IT-Services zu testen.

Service Delivery

In Anbetracht des Vorhabens ITIL Prozesse in einer bestehenden IT-Organisation einzuführen, müssen bestimmte Rahmenbedingungen erfüllt sein, sodass ein entwickelter Prozess praktikabel ist und vor allem gelebt wird. Diese Maßnahmen haben maßgeblichen Einfluss auf die Qualität, Transparenz und Nachhaltigkeit der eingesetzten IT-Services. Unter dem Namen Service Delivery sammelt ITIL Ansätze, die den Fokus auf verschiedene Details bei der Vollziehung der Leistungserbringung gerichtet haben. Um ITILs Service Delivery Bücher als Werkzeug sinnvoll anwenden zu können, ist es notwendig sich einen groben überblick über die darin enthaltenen Prozesse zu verschaffen.

Service-Level-Management

Frank und Holger, Seite 71, beschreiben das Service-Level-Management als die Aufgabe, externe und interne Dienstleistungen zu definieren, Service Levels zu den Dienstleistungen mit den Kunden zu vereinbaren und diese Vereinbarungen zu überwachen, auszuwerten, zu verbessern und zu berichten. Als wichtigstes Werkzeug zur Bemessung und Kontrolle der erbrachten Leistung dienen Services Level Agreements (SLA). Diese vertraglichen Festlegungen regeln die Verantwortlichkeiten zwischen Serviceerbringer und Servicekonsument, sowie welche Leistungen involviert sind. Abbildung 3 zeigt den Zusammenhang von Kunden, Service Level Agreements, Service Level Management und den angebotenen Services.

ITIL unterscheidet drei verschiedene Arten von Service Level Agreements.

  • Service Level Requirements (SLRs)
    • umfassen eine Sammlung und Dokumentation aller Kundenanforderungen (hierbei kann es sich um externe sowie interne Leistungsabnehmer handeln)
  • Underpinning Contracts (UCs)
    • umfassen vertragliche Vereinbarungen mit Lieferanten, die zur Leistungserbringung beisteuern.
  • Operational Level Agreements (OLAs)
    • umfassen die Messung und überwachung hausintern erbrachter Leistungen.

Ein weiteres wichtiges Werkzeug für die Steuerung des Service-Level-Managements ist der IT-Service Katalog. Diese Aufstellung von angebotenen IT-Leistungen bietet die Grundlage für die Erstellung jedes SLAs. Das Ziel ist es in einem strukturierten Ansatz jedwede Dienstleistung einer IT-Organisation zu identifizieren und in geeigneter Form einem Abnehmer zu präsentieren. Ein Beispiel, wie die Verwendung eines Service Katalogs in der Praxis gestaltet werden kann, wäre die Aushändigung eines Dienstnotebooks. In Form eines eigenen Portals kann das Gerät, vergleichbar mit einem webbasierten Shop, angefordert werden. Es werden sowohl Verrechnungspreis, übrige Stückzahl, sowie womöglich gewünschte Extraleistungen angezeigt. Eng an dieses Gerät und seine Konfiguration sind Service Level Agreements geknüpft, die mit der Verwendung, Ausfallszeit oder Verrechnung des Notebooks in Verbindung stehen. Das Ziel das mit dem Führen eines IT-Service Katalogs verfolgt wird ist das Schaffen von Transparenz und Unterstützen weiterer Prozesse wie der Bedarfsplanung (Capacity-Management) oder dem Financial-Management.

Nutzen

Das OGC nennt in seiner Best-Practice-Sammlung Service Delivery, Seite 29, folgende Kriterien, die als Anreiz für den Einsatz des ITIL-Prozesses Service-Level-Management sprechen:

  • IT-Services sind entworfen um den Service Level Requirements zu entsprechen
  • Verbesserung der Beziehung zwischen Kunden und Serviceerbringer
  • Durch die klare Definition der Rollen und Verantwortlichkeiten werden Missverständnisse und Versäumnisse unterbunden
  • Mit der Vorgabe messbarer Ziele kann die Service Qualität gemessen, beobachtet und berichtet werden, was wiederum dabei hilft Schwachstellen zu identifizieren
  • Die Erwartungen bezüglich der Serviceerbringung sind sowohl auf der Ausführenden als auch Empfangenden Seite bekannt
  • SLAs können als Verrechnungsgrundlage verwendet werden und dem Kunden den Wert der erbrachten Leistung vor Augen führen

Diese Punkte sind freilich nur ein Auszug der Beweggründe diesen Prozess in einer IT-Organisation einzuführen.

Financial-Management

Der Prozess des Financial-Managements betrachtet die wirtschaftlichen Aspekte der Leistungserbringung einer IT-Organisation. Im Wesentlichen werden hierzu vier Subprozesse bedient:

  • Budgetierung
    • Planung der Finanzmittel für die IT Services. Hier geht es um die Planung und Kontrolle der Verwendung der Gelder innerhalb einer Organisation. Dazu gehören z. B. die periodische Festlegung der Budgets für einen bestimmten Zeitraum (meist jährlich) und die operative Verwaltung des aktuellen Budgets.
  • Accounting
    • Die Berechnung der Kosten der IT Services. Das IT-Accounting fasst alle Prozesse zusammen, welche es einer Organisation erlauben, die Art und Weise der Ausgaben zu erfassen und zu überwachen (beispielsweise Kosten pro Kunde, Kosten pro Service, Kosten pro Aufgabe, ...).
  • Charging
    • Alle Aspekte der Leistungsabrechnung der bereitgestellten Services mit den Kunden. Dies beinhaltet alle Prozesse, welche sich mit der Verrechnung von Leistungen gegenüber den Kunden beschäftigen. Eine Voraussetzung für den Einsatz von IT-Charging ist das Durchführen von IT-Accounting in der für Rechnungsstellung benötigten Detail-Tiefe.
  • IT Portfolio Management
    • Egänzend beschäftigt sich das IT Portfolio Management mit der Betrachtung des Return on Investment der IT Services."

Ohne diese Unterprozesse ist das Führen einer rentablen und kontrollierbaren IT-Organisation aus sich von ITIL nicht möglich. Für die Gesamtprozesswelt bleibt hinzuzufügen, dass das Financial-Management wesentlichen Einfluss auf andere Prozesse, wie beispielsweise das Capacity- oder das Configuration-Management hat, welche in den folgenden Kapiteln behandelt werden. Um die Vernetzung der Teilprozesse besser zu verdeutlichen zeigt Abbildung 4 den Financial-Management-Lifecycle, wobei das IT Portfolio Management außen vor gelassen wird, da es in das Tagesgeschäft nicht unmittelbar involviert ist.

Durch die Budgetierung kann eine ungefähre Aussage getroffen werden wie viel Geld für ein Service über einen vorher definierten Zeitraum verwendet werden kann. Das Accounting unterstützt die Organisation dahingehend, dass Berechnungen durchgeführt werden, was das Anbieten des Services kostet. Mit dem Charging werden die Kosten des Anbietens gedeckt und zusätzlich noch finanzieller Gewinn verzeichnet.

Nutzen

Bei der Analyse der Vorteile, die der Prozess mit sich bringt, wird vor allem auf die Wirkung eines sinnvoll implementierten Financial-Management-Prozesses eingegangen:

  • Bei einer akkuraten übersicht über die Servicekosten können IT Investmententscheidungen unterstützt werden
  • Es ist möglich die Total Cost of Ownership (TCO), die den finanziellen Aufwand eines Objekts über dessen gesamte Laufzeit darstellt, für laufende Services zu bestimmen
  • Der Umgang mit den IT-Ressourcen wird effizienter, sobald aufgezeigt wird, dass gewisse Leistungen, die selbstverständlich scheinen, einen internen Preis zugewiesen haben

Capacity-Management

Laut Bock et al., Seite 201, ist das Capacity-Management dafür verantwortlich, die richtigen Kapazitäten zu vertretbaren Kosten entsprechend den bestehenden zukünftigen Bedürfnissen der Kunden zeitoptimiert bereitzustellen. Demnach befasst sich das Kapazitätsmanagement mit der Gratwanderung zwischen dem Vermeiden von über- und Unterkapazitäten. Einerseits sollten überkapazitäten vermieden werden, da dadurch unnötig Kapital gebunden wird und andererseits darf es zu keiner Minderung der Servicequalität durch Kapazitätsengpässe kommen. Das Capacity-Management nach ITIL berücksichtigt bei der kurz-, mittel- und langfristigen Planung sowohl Hardware- und Softwarekomponenten, Netzwerkequipment, Peripheriegeräte sowie menschliche Ressourcen.

Das OGC definiert im Band Service Delivery, Seite 124, für den Einsatz des Kapazitätsmanagements drei Subprozesse:

  • Business Capacity-Management
    • Trendanalysen, Prognosen, Modellierung, Ermitteln der zukünftigen Kundenbedürfnisse
  • Service Capacity-Management
    • IT-Services überwachen, analysieren, tunen und Bericht erstatten, Demand-Management und Schwellendefinitionen
  • Ressource Capacity-Management
    • IT-Komponenten überwachen, analysieren tunen und Bericht erstatten, Demand-Management und Schwellendefinitionen

Beeinflusst werden diese Prozesse von der angewandten Businessstrategie, die die Zielvorgaben für die IT-Organisation vorgibt. Kernthematik für das Kapazitätsmanagement bleibt jedoch, dass alle für die Geschäftsprozesse notwendigen Ressourcen akquiriert werden, sodass etwaige Geschäftsfälle zur Zufriedenstellung des Auftraggebers oder Kunden abgewickelt werden können.

Nutzen

Das OGC identifiziert den Mehrwert des Capacity-Management-Prozesses folgendermaßen:

  • Freiere Budgetgestaltung
    • Werden Kosten für die Neuanschaffung von Geräten in einen späteren Zeitraum verlegt, ergeben sich unverbrauchte Budgets, die anderweitig eingesetzt werden können.
  • Selektion der Services
    • Das Capacity-Management richtet sich immer nach dem aktuellen Business Need aus, sodass Ressourcen nur für tatsächlich benötigte Services bereitgestellt werden. Nicht mehr benötigte Services werden fallen gelassen, was eine Verschlankung des Ressourcenbedarfs zur Folge hat.
  • Planmäßige Beschaffungsszenarien
    • Ein geplanter Einkauf ist strategisch stets billiger als ein Panikkauf aufgrund eines Ressourcenengpasses.

Availability-Management

Um die Arbeit einer IT-Organisation so effizient wie möglich zu gestalten, ist es notwendig, dass IT Leistungen so konstant und stabil wie möglich abrufbar sind. Das ITIL Availability Management verschreibt sich der Aufgabe, durch hohe Erreichbarkeit der angebotenen Services, eine den Zufriedenheitsgrad der Endkunden konstant auf hohem Niveau zu halten. Die Abhängigkeit von IT Leistungsfähigkeit und der Durchführung essenentieller Geschäftsprozesse ist unübersehbar, da ein Ausfall der IT Landschaft oder eines einzelnen Dienstes meist eine komplexe Kettenreaktion zur Folge hat, was sich wiederum auf die Durchführbarkeit des Kerngeschäfts niederschlägt.

Die nun folgende Aufzählung bietet einen Ausschnitt der Hauptziele, die das Buch Service Delivery, Seite 212, beschreibt:

  • Sicherstellung, dass die angebotenen IT-Services so erreichbar sind, das das Kerngeschäft jederzeit reibungslos abgewickelt werden kann
  • Implementation eines Reportingsystems, das die IT Erreichbarkeit mess- und auswertbar macht, sodass verhandelte Verfügbarkeitslevels überprüft werden können
  • Optimierung der Infrastrukturverfügbarkeit um kosteneffiziente Verbesserungen für den Endkunden zu schaffen
  • Nachhaltige Verbesserung der Zeitperioden in denen aufgrund eines Störfalls Teil- oder Komplettsysteme ausfallen, sowie Verminderung der Auftrittsfrequenz von Störungen, die Einfluss auf die IT Verfügbarkeit haben

Gesteuert werden diese Ziele und die in direkter Verbindung stehenden vereinbarten Maßnahmen über Service-Level-Verträge.

Nutzen

Um einen überblick über die Kernaussagen des Availability-Management-Prozesses zu haben gibt folgende Aufzählung einen übersicht über die im Buch Service Delivery, Seite 222, angeführten Vorteile diese ITIL Prozesses.

  • Etablierung eines Prozesseigners und somit klar abgesteckte Verantwortungsbereiche innerhalb der IT Organisation
  • IT Services sind so entworfen, dass sie sich an den IT Verfügbarkeitsanforderungen orientieren
  • Verfügbarkeitslevels (beispielsweise prozentuelle Verfügbarkeit über einen Gesamtzeitraum) sind mit Kostenziffern hinterlegt
  • Definierte Verfügbarkeitslevels sind abgestimmt, gemessen und beobachtet um den Service-Level-Management Prozess zu unterstützen
  • Engpässe bei der Planung der Verfügbarkeit werden aufgedeckt und entsprechend korrektive Gegenmaßnahmen identifiziert und implementiert

Die im Verfügbarkeitsmanagement beschriebenen Vorgangsweisen behandeln vor allem jene Vorfälle und Szenarien, die im Rahmen des üblichen IT Betriebes entstehen. ITIL geht jedoch einen Schritt weiter und implementiert einen Prozess, der ähnlich dem koordinierten Krisenmanagement, Lösungen und Maßnahmen bei außergewöhnlichen Umständen anbietet - das Continuity-Management.

Continuity-Management

Die Sicherstellung eines stabilen IT-Betriebs ist eines der erklärten Ziele jeder IT-Organisation. Das Continuity-Management versucht vorrausschauend Störungen und Katastrophen durch proaktives Risikomanagement abzuschätzen und je nach Dringlichkeit des betroffenen Systems oder Geschäftsprozess geeignete Maßnahmen zu implementieren. Bock et al. definieren die Begriffe Störung und Katastrophe wie folgt:

Im Unterschied zu normalen Störungen werden beim Eintritt einer Katastrophe die Standardprozeduren außer Kraft gesetzt. Je nach Größe des Notfalles werden die weiteren Maßnahmen durch den Prozessverantwortlichen Continuity-Manager allein oder durch ein allfälliges Notfallteam koordiniert und festgelegt.

Die Zielsetzung ist es die Auswirkungen von Störungen und Katastrophen so klein als möglich zu halten um die Wiederaufnahme bei Ausfällen oder den laufenden Betrieb der IT-Systeme zu unterstützen. Zur Umsetzung dieser Ziele stellt ITIL einen eigenen Business Continuity Management Lebenszyklus (BCM Lifecycle) vor, der auf Abbildung 5 dargestellt ist.

Die Eingangsphase (Phase I) des BCM-Prozesses sieht die Definition eines Rahmenwerks vor, in dem Begriffe, Referenzen und Abgrenzungen festgemacht werden. Zusätzlich richtet sich der Fokus dieses Abschnitts auf das Allokieren etwaiger Ressourcen. In Phase II wird eine Analyse der Ist-Situation betrachtet und anhand dieser eine Risikoabschätzung durchgeführt. Die Business Continuity Strategie wiegt grundsätzlich den Faktor der Eintrittswahrscheinlichkeit des Risikos mit dem Faktor der Kritikalität des betroffenen Systems ab und beziffert dadurch die Schwere eines Störfalls oder einer Katastrophe. Ausgehend von dieser Analysephase, widmet sich Phase III der Entwicklung und Implementation von Maßnahmen. Es ist besonders hervorzuheben, dass der Lebenszyklus, wie er in Abbildung 5 dargestellt ist, die letzte Phase (Operationales Management) außen vor lässt, da es sich hierbei weniger um das konzeptionelle als um das ausführende Continuity-Management handelt. Die Anzahl an Möglichkeiten diese operativen Tätigkeiten durchzuführen würde den Rahmen dieser Kurzeinführung sprengen und ist aus Sicht des konzeptionellen BCM vernachlässigbar.

Nutzen

Zusammenfassend bietet folgende Aufzählung einen überblick über die Hauptargumente für den Einsatz des Prozesses Continuity-Management im Rahmen der ITIL Best Practices:

  • Potentiell niedrigere Versicherungsprämien durch aktives Risikomanagement
  • Regulative Anforderungen bezüglich der Wiederherstellung von Services sind in vielen Branchen bereits Standard
  • Positive Selbstdarstellung der IT-Organisation bei Eventualfallszenarien

Nach diesem kurzen überblick über die Prozesse, die ITIL im Rahmen ihrer Best-Practices im Buch Service Delivery abhandelt, widmet sich das folgende Kapitel jenen Prozessen, die dem Endbenutzer ein produktives Arbeiten in der jeweiligen Produktivumgebung ermöglichen. Gesammelt sind diese Maßnahmen und Vorgehensweisen im Buch Service Support.

Service Support

Die im Buch Service Support behandelten Best-Practices fassen vor allem Tätigkeiten aus dem Tagesgeschäft einer IT-Organisation auf und versuchen diese bestmöglich zu optimieren. Bei der Anwendung, der im Laufe des folgenden Kapitel vorgestellten Prozesse, ist es dringend anzuraten einen toolunterstützten Ansatz zu wählen, um die Effizient der Services gleichbleibend hoch zu halten.

Service Desk

Im Eigentlichen wird der ITIL Service Desk weniger als Prozess sondern mehr als Funktion gesehen, die bei der Leistungserbringung eine wichtige Rolle spielt. Als genereller Ansprechpartner für etwaige Störungsmeldungen oder Infrastrukturänderungen stellt der Service Desk die Schnittstelle zwischen den Endbenutzern und der IT-Organisation dar.

Essenziell für einen funktionierenden Service Desk und für professionelle Ausübung der im Folgenden beschriebenen Prozesse ist es, dass der Service Desk als Single Point of Contact ernst genommen wird und keine Kommunikationskanäle am Service Desk vorbei, z. B. zwischen bestimmten Anwendern und ihren schon lange bekannten und vertrauten Spezialisten existieren.

Die angesprochenen Kommunikationskanäle können variieren, jedoch besteht in der Regel die Möglichkeit das jeweilige Anliegen mittels E-Mails, eines eigens dafür eingerichteten Tools oder persönlich mitzuteilen. Sobald eine Meldung am Service Desk einlangt wird diese klassifiziert und je nach Auswirkung auf die Durchführung der Geschäftsprozesse oder auf das betroffene System priorisiert. Nach erfolgreichem Abschluss dieses Vorfalles übernimmt der Service Desk die Dokumentation des Störfalls und legt diese für ein mögliches Wiedereintreten intern ab.

Nutzen

Das Einsetzen eines Service Desks bietet sowohl für den Endbenutzer als auch für die IT-Organisation selbst Vorteile, die auszugsweise in folgender Aufzählung dargestellt werden:

  • Klare Ansprechpartner garantieren Nachverfolgbarkeit
  • Repetitive manuelle Aufgaben können mit Hilfe des Service Desks automatisiert werden (Standard Services wie Passwortrücksetzungen)
  • Eingemeldete Störfälle werden registriert und können im Bedarfsfall eskaliert werden
  • Managementinformationen werden mittels des Service Desk automatisch gesammelt
  • Wiederkehrende Störfälle können schneller behoben werden, da der Service Desk bereits gelöste Fälle dokumentiert

Der Service Desk reiht sich bei vielen Prozessen des Service Supports als handelnder Akteur ein. Durch die enge Verbindung zum operativen Bereich eignet er sich ebenfalls als Ansprechpartner für infrastrukturelle oder prozessuale änderungen. Bedingt durch die Tatsache, dass änderungen in einer IT-Organisation keinesfalls unorganisiert durchgeführt werden dürfen, führt ITIL einen eigenen Prozess dazu ein - das Change-Management.

Change-Management

Für den organisierten Austausch von Geräten oder die Umsetzung von Veränderungen ist ein Prozess notwendig, der diese Vorgänge überwacht und möglichst transparent für den Endbenutzer ist. Das ITIL-Framework definiert, so wie auch Bock et al. auf Seite 168, den Prozess Change-Management als das zur Verfügung stellen standardisierter Methoden und Verfahren zur Bearbeitung von änderungen. Konkret geht es um die Verwaltung sogenannter Configuration Items (CI). Unter diesem Begriff fasst ITIL jegliche Art von Hardware, Software, Peripherie oder andere Ressourcen, die für den Betrieb notwendig sind, zusammen. Abbildung 6 zeigt den Veränderungsprozess schematisch aus Sicht des Projektmanagements und des Veränderungsmanagements.

Wie aus Abbildung 6 hervorgeht ist das klassische Projektmanagement sehr eng mit dem ITIL Prozess Change-Management verbunden. Nach Eingang eines Request for Change, kurz RFC, wird eine initiale Klassifikation des zu verändernden Systems durchgeführt. Nach dieser Anfangsphase liefert das Change-Management direkten Input für die Planung des Services. Hier kann es sich beispielsweise um eine Systemerneuerung, einer Ablösung oder um ein eigenes Projekt handeln. Bevor die entwickelten Pläne in die Tat umgesetzt werden können, müssen diese noch aus Sicht des Change-Mangements abgenommen werden. Dies bedeutet, dass sie auf ihre Machbarkeit und Sinnhaftigkeit geprüft werden. Sobald eine formale Absegnung seitens des Veränderungsmanagements vorliegt, werden die geplanten Lösungen entwickelt, angeschafft oder installiert, sowie gründlich in einer dafür geeigneten Umgebung getestet. Nachdem das Change-Management mit den vorliegenden Tests restlos einverstanden ist, wird eine Freigabe für die Implementation der Lösungen erteilt. Unabhängig davon wird die implementierte Lösung in regelmäßigen Zeitabständen evaluiert, um einen etwaigen Handlungsbedarf zu ermitteln und gegebenenfalls einen weiteren RFC-Zyklus zu starten.

Nutzen

Welchen Nutzen ein koordinierter Veränderungsprozess hat wird aus der folgenden Aufzählung ersichtlich:

  • Verbesserung der Ausrichtung der IT-Services auf geschäftliche Anforderungen
  • Erhöhte Absprache bei Veränderungen zwischen Endkunden und IT-Organisation
  • Verbesserung der Risikoabschätzung (siehe Abbildung 6)
  • Verbesserte Verfügbarkeit der Services durch koordinierte Changes

Um das Veränderungsmanagement so effizient wie möglich durchführen zu können, ist es nötig eine Form von Kontrolle über die verwendeten Betriebsmittel zu haben. Das ITIL-Framework widmet diesem Vorgang den Prozess Configuration-Management.

Configuration-Management

Das Configuration-Management, wie es im Buch Service Support von ITIL beschrieben wird, trägt die Verantwortung für alle eingesetzten IT Assets. Unter dem Begriff Asset werden sowohl IT Infrastruktur, als auch IT Services verstanden, die es zu kontrollieren, dokumentieren und gegebenenfalls mittels Change-Managements ersetzen gilt. Als Hilfestellung beim Erreichen der eben genannten Ziele bietet dieser Prozess ein logisches Modell der organisationsweiten IT-Infrastruktur. Mittels der Configuration-Management-Database, kurz CMDB, wird eine ganzheitliche Abbildung aller verwendeten Configuration-Items (CIs) ermöglicht, die als ineinandergreifende Plattform für die Planung, die Fehlerbehebung und den Betrieb der Betriebsmittel agiert. Abbildung 7 verdeutlicht die Rolle der CMDB im Zuge des Configuration-Managements.

Wie aus Abbildung 7 hervorgeht, hält die CMDB sämtliche Beziehungen zwischen den einzelnen CIs und steht in starker Wechselwirkung mit sämtlichen Service Support Prozessen. Bei der Implementation der CMDB bleibt zu beachten, dass es sich bei dieser Datenbank mehr um ein logisches Modell, als eine physische Datenbank handelt. In der Praxis könnte dieser schematische Abriss durchaus auch durch mehrere Datenbanken oder Applikationen realisiert werden. Hervorzuheben ist, dass durch die CMDB die Vernetzung sämtlicher IT-Ressourcen forciert wird. Neben wichtigen Daten, wie letzte Fehlerbehebung, Verantwortlichkeit für das CI, Verbindungen zu anderen Services oder momentaner Status des Geräts ist es möglich Dokumentationen CI-spezifisch in die CMDB einzupflegen. Dies ermöglicht das Schaffen einer organisationsinternen Wissensdatenbank, die abgesehen von der Historie des angebotenen Services, den Wissensaustausch- und Aufbau der CMDB-Nutzer fördert.

Nutzen

Neben den bereits angeführten Vorteilen, ergänzen die folgenden Punkte jene Gründe, die aus Sicht von ITIL, für das Einsetzen dieses speziellen Prozesses sprechen.

Akkurate Informationen über CIs und deren Dokumentationen
  • Kontrolle über den Verbleib von IT-Assets
  • Akkurates digitales Inventar
  • Hilfe bei der Bedarfsplanung (siehe Capacity-Management)
  • Hilfe bei der Auswirkungsanalyse von Changes (Effizienz- und Effektivitätskontrolle)

Mit dem Configuration-Management bietet ITIL einen durchdachten Prozess für die Verwaltung angebotener IT-Services. Für den planmäßigen Austausch oder die Erneuerung von Configuration-Items ist im ITIL Framework ein weiterer Prozess verantwortlich - das Release-Management.

Release-Management

Bock et al. erklären, dass das Release-Management nach ITIL, Seite 178 ff, zuständig für die Freigabe, Kontrolle und Verteilung der eingesetzten Software- und Hardware ist. Weiters wird erläutert, dass dieser Prozess in erster Linie dafür verantwortlich ist, dass Veränderungen von Hard- und Software produktreif gestaltet werden. Benötigt wird ein koordiniernder Austauschprozess vor allem aufgrund immer kürzerer Produktlebenszyklen. Es ist zu beachten, dass der Gesamtprozess des Release-Managements eingebunden ist in den des Change-Managements. Angestoßen aufgrund eines Request-for-Change (RfC), umfasst ein Release in der Regel mehrere Fehlerbehebungen oder Serviceverbesserungen, die je nach Dringlichkeit zeitnah implementiert werden. In der folgenden Tabelle werden sowohl die im Release-Management verwendeten Termini, als auch deren Bedeutung erläutert.

Ausgehend von einem Request for Change, der über den Service Desk oder den Endnutzer selbst eingespielt werden kann, wird der änderungswunsch aufgegriffen und vom Change-Management autorisiert. Bei einer positiven Bearbeitung des Request wird dieser weitergegeben an das Release-Management. Hier wird geplant in welcher Form der Release vollzogen werden soll und den Vorstellungen entsprechend designt. Anschließend wird in einer isolierten Testumgebung, die ein Abbild der Produktivsysteme ist, der Release eingespielt und getestet. Nach erfolgreichem Abschluss aller durchzuführenden Tests und einer Prüfung der Abhängigkeiten von bereit installierter Soft- oder Hardware, wird der Release abgenommen. Da das Release-Management den gesamten Weg der änderung bis hin zur Produktreife begleitet, wird ein Plan für die Ausbringung erstellt, sodass die vorbereitete Soft- oder Hardware problemlos verteilt werden kann. Abschließend wird eine gesamtheitliche überprüfung des ausgebrachten Releases durchgeführt und, so benötigt, Nachbesserungen durch das Change-Management getroffen.

Nutzen

Zusammenfassend kann der Nutzen des geregelten Release-Managements wie folgt aufgeführt werden:

  • Größerer Erfolg bei der Ausbringung neuer Soft- und Hardware und damit eine Steigerung der Servicequalität
  • Minimierung der Störungen von Services, die durch nicht abgestimmte Packages resultieren
  • Stabile Test- und Produktivumgebungen ermöglichen eine niedrigere Auswirkung auf die Geschäftstätigkeit
  • Leichtere Erkennung nicht autorisierter Software oder abweichenden Versionsnummern
  • Risikoreduktion bezüglich des Einführens schadhafter Software durch vorgeschnürte Standardpakete
  • Möglichkeit, unterstützt vom Change-Management, eine hohe Anzahl an Veränderungen zu implementieren ohne die IT-Servicequalität negativ zu beeinflussen

Eine der Hauptinputquellen, die das Release-Management anstoßen sind die im Betrieb aufgetretenen Störfälle, die gemanagt und behoben werden müssen. ITIL stellt genau zu diesem Zweck den Prozess des Incident-Managements vor.

Incident-Management

Der Prozess des Incident-Managements stellt mitunter die größte Herausforderung in der Aufrechterhaltung eines stabilen IT-Betriebs dar. Weitläufig lässt sich der Begriff Incident als Störfall eines IT-Systems übersetzen. Die im Buch Service Support, Seite 71, angeführte Definition eines Incidents lautet wie folgt:

Jedes Ereignis, das nicht Teil der Standardoperationen eines Services ist, und vielleicht eine zu einer Unterbrechung oder Minderung der Service Qualität führt.

Beispiele für Incidents sind:

  • Applikation
    • Service nicht verfügbar
    • Applikationsfehler der den Benutzer vom Arbeiten abhält
    • überschreitung der vorhandenen Speicherkapazität
  • Hardware
    • System ausgefallen
    • Automatischer Alarm
    • Drucker druckt nicht
    • Konfiguration unerreichbar
  • Serviceabfragen
    • Frage um Dokumentation / Information / Rat
    • Passwortrücksetzungen

Der Prozess des Incident-Managements kümmert sich demnach um jene Maßnahmen, die die schnellstmögliche Wiederherstellung eines bestimmten Services unterstützen. Es wird ausdrücklich darauf hingewiesen, dass im Incident-Management keine, unter Umständen aufwändige, Ursachenforschung betrieben wird. Abbildung 8 gibt einen stark vereinfachten Lebenszyklus eines Incidents wieder.

In diesem schematischen Abriss ist erkennbar, dass ein Benutzer einen Incident an den Service Desk einmeldet. Dies geschieht im Regelfall über verschiedene Kommunikationskanäle (E-Mail / Telefon / eigens vorgesehenes Tool). Am Service Desk wird die Fehlermeldung klassifiziert und je nach Dringlichkeit des betroffenen Systems priorisiert. Unter der Zuhilfenahme einer Wissensdatenbank oder der historisch aufgezeichneten Daten auf der CMDB, werden nach Lösungen gesucht, die dem Endnutzer noch während der Kommunikation angeboten werden können. Sollten über den aufgetretenen Fehler keine Informationen verfügbar sein, so wird das eröffnete Incident-Ticket an jene Person weitergeleitet, die die Produktverantwortung für besagtes System trägt. Gegebenenfalls nimmt diese Person mit dem betroffenen Kunden Kontakt auf um sich den Fehler detaillierter schildern zu lassen oder behebt, aufgrund seines Produktwissens, den Incident sofort. Für den Servicenutzer endet hier der offizielle Prozess des Incident-Managements, da das beanstandete Service nun wiederhergestellt ist. Abschließend werden von den an der Lösung des Incidents beteiligten Akteuren noch Nacharbeiten, wie das Pflegen der Wissen- oder Configuration-Management-Datenbank, vollzogen, sodass beim Wiederauftreten eines ähnlichen Fehlers eine schnellere Lösungsfindung erreicht wird.

Nutzen

Dieser nun sehr rudimentär beschriebene Prozess ermöglicht viele Vorteile im laufenden IT-Betrieb. Einen Auszug bietet die folgende Auflistung:

  • Verminderung der Auswirkung von Incidents durch rasche Resolution selbiger steigert die Effektivität bei er Durchführung der Geschäftsprozesse
  • Gewinnen von wichtiger Information, die gegebenenfalls auf einen SLA anwendbar gemacht werden kann (Ausfallszeiten, Wiederherstellungszeiten, etc...)
  • Verbesserung der Serviceüberwachung und Steigerung der Servicequalität
  • Verhindern des Verlusts von Incidents oder einer Anfrage durch obligatorische Dokumentation
  • Akkuratere CMDB-Informationen durch fortwährende Pflege- und Nacharbeiten
  • Stabilerer IT-Betrieb durch dokumentierte Verfahren zur Wiederherstellung

Die hier zusammengefassten Punkte gehen von der Tatsache aus, dass das betroffene Service in einem akzeptablen Zeitrahmen wiederhergestellt werden kann. Das Incident-Management per se behandelt jedoch weder die Ursachen der Störung noch entwickelt es Maßnahmen zur Verhinderung des Wiederauftretens derselben Störung - hierfür setzt ITIL den Prozess des Problem-Managements ein.

Problem-Management

Für die Anwendung des ITIL-Frameworks ist es essenziell zwischen Incidents und Problems zu unterscheiden. Während ein Incident ein vorübergehender Ausfall oder Serviceminderung, dessen Ursache bekannt ist, darstellt, so beschreibt ein Problem etwas grundlegend Anderes.

Im Problem-Management kommen drei neue Begriffe zur Anwendung: Problem, Known Error und Workaround.

  • Ein Problem wird dabei als unbekannte Ursache für eine oder mehrere Störungen definiert. Jede Störung bzw. jeder Incident aus dem Incident-Management, dessen Ursache nicht bekannt ist, ist demnach ein Problem.
  • Kann die Ursache zu der Störung bzw. zu den Störungen identifiziert werden, so spricht man von einem Known Error. Man kennt also die Ursache des Problems bzw. weiß, was die Störung ausgelöst hat. Die endgültige Lösung des Problems ist noch offen.
  • Ist die Ursache bekannt, so kann eine temporäre Lösung bzw. ein Workaround im Problem-Management erarbeitet werden. Ein Workaround definiert also eine Vorgehensweise zur vorübergehenden Behebung der Störung. Dass die gleiche Störung jedoch nicht mehr auftritt, kann durch den Workaround nicht sichergestellt werden. Erst wenn das Problem vollkommen gelöst ist, kann sichergestellt werden, dass dieselbe Störung nicht wieder auftritt.

Die Prozesse des Incident- und Problem-Managements arbeiten also Hand in Hand für die Verbesserung der Servicequalität bei möglichst hoher Serviceverfügbarkeit. Bei den aktiven Akteuren des Problem-Managements handelt es sich meist um Produktspezialisten, mit tiefer gehendem Fachwissen, beziehungsweise um, eigens dafür abgestellte, Service Desk Mitarbeiter. Bei der Analyse der eingetroffenen Incidents kann beispielsweise ein Trend festgestellt werden, dass ein spezieller Störfall mehrmals oder in wiederkehrenden Intervallen auftritt. Dies ist eine geeignete Indikation, dass es sich dabei um ein Problem handelt, dass an die zuständige Einheit oder Einzelperson mittels Eröffnung eines Problem-Tickets weitergeben werden muss. Je nach Dringlichkeit des Problems wird für die Lösungsfindung ein entsprechender Zeitrahmen veranschlagt. Sobald eine nachhaltige Behebung des Problems sichergestellt ist, arbeitet das Problem-Management eng mit Change- und Release-Management zusammen um die endgültige Behebung organisationsweit auszurollen. Es bleibt darauf hinzuweisen, dass die Möglichkeit das Problem-Management von der exakt selben Personengruppe wie das Incident-Management abdecken zu lassen nur bedingt empfehlenswert ist. Die Problematik, die mit dieser Personalbesetzung erwächst, ist die Sicherstellung, dass möglicherweise aufwendigere Lösungsfindungen nicht Ressourcen, in diesem Fall Mitarbeiter, für die Incidentbehebung blockieren.

Nutzen

Die folgende Aufzählung verdeutlicht wie eine IT-Organisation vom Einsatz eines Problem-Managementprozesses profitieren kann:

  • Verbesserung der IT-Servicequalität durch nachhaltige Lösungsentwicklung
  • Verminderung von Incidents, die den Betrieb stören aufgrund von Ursachenforschung
  • Permanente Lösungen anstatt einfacher Wiederherstellung des Services
  • Sammeln von Erfahrungswerten wird durch historische Daten, die wiederum zur Trendanalyse herangezogen werden können

Das Kapitel Problem-Management beschließt die Einführung in die Prozesse des Buches Service Support, sowie die Einführung in die Prozesse des ITIL-Frameworks. Diese Sammlung an bewährten Techniken ermöglicht eine effizientere Gestaltung des IT-Betriebs und aus Sicht der IT-Organisation eine erhebliche Erleichterung im Tagesgeschäft. Dass diese Maßnahmen, bedingt durch ihre Komplexität, nicht plötzlich in eine Organisation eingeführt werden können ist verständlich. Zuerst bedarf es einer Erhebung des momentanen Ist-Zustandes, auf dessen Basis eine vereinheitliche Strategie zur Verbesserung interner und externen Prozesse erfolgen muss. Mit Hilfe dieser Momentaufnahme sollen anhand einzeln ausgewählter Prozesse Problematiken aufgezeigt werden, die sowohl im strategischen als auch im operativen Bereich, auftreten. Durch das Einsetzten verschiedener Ansätze, die aus dem ITIL-Framework bekannt sind, sollen im Verlauf dieser Arbeit zwei der im nächsten Kapitel vorgestellten Prozesse ausgewählt und aktiv durch eine Neugestaltung effizienter gestaltet werden.

Prozesslandschaft der UniCredit Direct Services

Einleitung

Die im Zuge dieser Arbeit vorgestellten Prozesse sind ein Auszug aus den Hauptprozessen der UniCredit Direct Services (UCDS). Der Fokus liegt vor allem auf jenen Prozessen, die entweder von der Abteilung Infrastruktur (IFS) gesteuert oder maßgeblich beeinflusst werden. Einleitend muss erwähnt werden, dass bei der Ausprägung der einzelnen Abläufe große Unterschiede bezüglich Komplexität und Dokumentation auftreten. Dieser Umstand ist durch das Kerngeschäft der UCDS, das ausschlaggebend von den Regulationen des Bankenwesens betroffen ist, zu erklären. Aufgrund des sehr hohen Standards bei der Geschäftsabwicklung mit Geldinstituten sind diese Prozesse umfangreicher und besser dokumentiert, während von organisationsinternen Vorgängen meist organisierte Beschreibungen fehlen oder das vorhandene Material unvollständig ist. Eine weitere Herausforderung, die sich bei der Koordination der eingesetzten Abläufe ergibt, ist die Tatsache, dass einige Prozesse in den verschiedenen Standorten unterschiedlich definiert und gelebt werden. Bei der Erarbeitung der Prozesslandschaft wird auf eine Länderebene herunter gebrochen und repräsentativ für die Länder Deutschland und österreich ein Beispielstandort gewählt. Als österreichischen Standort wird das Communication Center Wien analysiert während als deutsches Pendant das Communication Center München untersucht wird. Um eine einheitliche Betrachtung zu ermöglichen wird nach der Präsentation der Prozesse ein Reifegradmodell vorgestellt, das den jeweiligen Entwicklungsgrad des Einzelprozesses abbildet, sowie eine erste Indikation gibt, welcher Vorgang Entwicklungsfelder aufweist. Konkret wird diese Arbeit folgende Prozesse vorstellen:

  • Auftragseinsteuerung aus Sicht des externen Kunden
  • Auftragseinsteuerung für die Abteilung IFS
  • Qualitätssicherungsprozess für die Abteilung IFS
  • Projektbudgetkontrollprozess für die Abteilung IFS
  • Service Level Agreements für Deutschland
  • Service Level Agreements für österreich
  • Fehlermeldeprozess in Deutschland
  • Fehlermeldeprozess in österreich

Es bleibt darauf hinzuweisen, dass eine ganzheitliche Lösungserarbeitung für alle Prozesse den Rahmen dieser Arbeit bei Weitem sprengen würde. Bei der Erfassung des Ist-Zustandes der Prozesswelt soll vielmehr oberflächlich das Verbesserungspotential einzelner Vorgänge aufgezeigt werden. Für die Umsetzung der herausgearbeiteten Maßnahmen kann, aus Sicht des Autors, momentan nicht garantiert werden. Bedingt durch die Tatsache, dass die Vielzahl der hier gezeigten Prozesse sinnvoll durch den Gebrauch von eigens dafür konzipierten, jedoch noch nicht in der Organisation vorhandenen, Software-Tools unterstützbar sind, wird die Umsetzung der gelieferten Vorschläge durch die finanzielle Charakteristik der Lösung beschränkt. Bei Vorhandenseien einer verwendbaren Toolunterstützung, so wie es für den Fehlermeldeprozess in österreich oder den Auftragseinsteuerungsprozess für die Abteilung Infrastruktur der Fall ist, wird im Anschluss eine adäquate Umsetzung präsentiert.

Auftragseinsteuerung (UCDS)

Der Prozess der Auftragseinsteuerung übersieht den Lebenszyklus eines an die UniCredit Direct Services gestellten Auftrags. Dies könnte die Umsetzung eines Kundenwunsches oder die Ausweitung eines bereits bestehenden Auftrags sein. Wie aus Abbildung 9 hervorgeht, handelt es sich hierbei um einen gut dokumentierten Prozess, der in der gezeigten Ausprägung auch vollständig gelebt wird. Bei der Auftragseinsteuerung handelt es sich um einen Vorgang der für externe Kunden wie Banken, externe Auftraggeber oder Mitglieder der UniCredit Group verwendet wird.

Als erster Schritt für die Umsetzung der Auftragseinsteuerung muss ein planmäßiger Auftrag definiert werden. Dies bedeutet in erster Linie den Inhalt des umzusetzenden Projekts mit dem Kunden abzustimmen. UCDS-intern werden die Kundenanforderungen analysiert und auf ihre Umsetzbarkeit geprüft. Konkret bedeutet dies eine Kontrolle ob fachlich, technisch und zeitlich verlangte Aufgabenstellungen seitens der UCDS abgedeckt werden können. Bei der Auseinandersetzung mit dem nachgefragten Auftrag handelt es sich lediglich um einen oberflächliche Betrachtung der involvierten Themengebiete. Weiters wird in dieser Eingangsphase ein nach außen klar definierter Ansprechpartner gewählt, der mit dem jeweiligen Kunden eine detaillierte Auftragsbeschreibung erarbeitet und diesen gleichzeitig über die Ergebnisse der Machbarkeitsanalyse informiert. Im Rahmen des ganzen Prozesses liegt die Kommunikation mit dem Auftragsteller im Aufgabenbereich des gewählten Ansprechpartners. Jegliche andere Art der Kontaktaufnahme mit dem Kunden, außerhalb der definierten Schnittstellen, ist zu unterbinden. Abgeschlossen wird diese Anfangsphase durch das Festlegen eines klar definierten Auftragsinhalts. In weiterer Folge werden UCDS-intern Ressourcen für die Bearbeitung der Anforderungen akquiriert, sowie eine grobe Vorauswahl über den Ausführungsstandort getroffen. Nach einer gründlichen technischen Prüfung der Umsetzbarkeit, wird ein Angebot erstellt, das gegebenenfalls beim Auftraggeber nachverhandelt und angepasst wird. Bei diesem Angebot handelt es sich beispielsweise um die Festlegung wie der umzusetzende Pilotbetrieb abgewickelt werden soll. Im nächsten Prozessschritt werden die eingeforderten Leistungen mit Zahlen hinterlegt. Das Mindestziel dieser Verhandlungen muss die ökonomische Deckung des Pilotbetriebs zur Folge haben. Sobald der Kunde das ihm gestellte Angebot angenommen hat, wird der Auftrag unter Einbindung aller involvierten Abteilungen eingesteuert. Hierbei werden sowohl operative Abteilungen, wie beispielsweise der Costumer Care Bereich des jeweiligen Landes als auch Stabsabteilungen, wie Controlling und Projektmanagement eingebunden. Gemäß des erhaltenen Auftrages wird nun mit der Lösungsentwicklung begonnen, sowie vertragliche Rahmenbedingungen entworfen. Fortgesetzt wird der Prozess mit der Durchführung eines Pilotprojektes, das im Anschluss als Auswertungsgrundlage den Weg für den Produktivbetrieb vorgibt. Der Verlauf des Pilotbetriebes entscheidet ob die entwickelte Lösung flächendeckend ausgebracht wird. Hierzu erstellt das Projektteam in Zusammenarbeit mit dem Endkunden einen Rollout-Plan. Sobald dieser im beidseitigen Einverständnis anerkannt ist, wird ein Angebot an den Kunden übergeben. Nachdem jeglicher finanzielle Aspekt der Geschäftsabwicklung geregelt ist, wird der Auftrag an die ausführenden Abteilungen zur Gesamteinführung übergeben und der Prozess der Auftragseinsteuerung abgeschlossen.

Potential

Bezugnehmend auf den grundsätzlichen Prozess, besteht aus Sicht der UCDS kaum Verbesserungspotential, da sich dieser sowohl strategisch als auch operativ bewährt hat. Durch die klare Definition von Ansprechpartnern und ständige Projektstatusevaluierungen vermindert aus Sicht des Kunden und der Organisation das Risiko von missverständlicher Kommunikation beziehungsweise Fehlentwicklungen. Ein weiterer Faktor, der dies hinterlegt, ist die verpflichtende Pilotierungsphase von Projekten in der Aufträge anhand eines definierten Szenarios ohne großen Aufwand auf ihre Praxistauglichkeit untersucht werden können. Lediglich hinsichtlich der Unterstützung beim Projektablauf weist dieser Ablauf klare Verbesserungsmöglichkeiten auf. Bei den eingesetzten Kommunikationsmedien handelt es sich im Wesentlichen um zahllose E-Mails, die von Abteilung zu Abteilung beziehungsweise zwischen den Ansprechpartnern versandt werden. Ein konkreter Vorschlag zur Verbesserung dieser, oft äußerst unkoordinierten, E-Mail-Flut wäre das Einsetzen eines Workflow-Management-Systems. Durch eine zentralisierte Ansicht des momentanen Projektstatus- beziehungsweise Fortschritts verringert sich der E-Mail-Overhead auf ein Minimum. Weiters wird durch die Einführung eines solchen Tools sichergestellt, dass ein Auftrag zu jeder Zeit dokumentiert nachvollziehbar für die jeweiligen Abteilungsverantwortlichen ist. So wird gleichzeitig das Risiko von, aufgrund von unklar definierten Verantwortlichkeitsbereichen, zu lange andauernden Projekten eingeschränkt.

Auftragseinsteuerung (IFS)

Im Gegensatz zum Auftragseinsteuerungsprozess der UniCredit Direct Services, weist der Prozess zum Auftragseingang für die Abteilung Infrastruktur weniger komplex und unbürokratischer ab. Abbildung 10 verdeutlicht die Abläufe für einen Auftrag der vom Team IFS umgesetzt werden soll.

Einleitend muss erwähnt werden, dass es sich bei dem Begriff „Auftrag" im Fall der Infrastrukturabteilung in den meisten Fällen um Wartungs- oder Betriebsanfragen handelt, die im Rahmen des Tagesgeschäfts auftreten. Für die Umsetzung eigener Projekte, die eigenständig von IFS durchgeführt werden, allerdings einen externen Kunden betreffen, wird der eingangs dieses Kapitels angeführte Einsteuerungsprozess verwendet. Das Hauptkommunikationsmittel für die Auftragseinsteuerung für das Infrastrukturteam ist E-Mail. Nach einer Anfrage, die an den jeweiligen Gruppenpostkorb des anzusprechenden Teams, gestellt wird, erfolgt eine Selektion durch die Mitarbeiter selber oder dem jeweilig aktuellen Ressourcenstand. Aus dem Postkorb heraus wird das Auftragsmail von einem Mitarbeiter anschließend in seinen eigenen E-Maileingang verschoben. Je nach Größe des umzusetzenden Projekts schätzt der zuständige Mitarbeiter alleine oder unter Mithilfe seiner Kollegen den mit dem Auftrag in Verbindung stehenden Aufwand. Das Schätzergebnis wird sowohl an den beauftragenden Kunden, als auch an den Kostenartenverantwortlichen weitergegeben. Aus Sicht der Abteilung IFS ist die Auftragseinsteuerung an diesem Punkt beendet.

Potential

Dass dieser Prozess in vielerlei Hinsicht entwicklungsbedürftig ist, zeigt die Tatsache, dass er im Wesentlich situativ gelebt wird und Großteils aus der Kundenperspektive nicht transparent oder nachvollziehbar ist. Um einen effektiven Auftragseinsteuerungsprozess leben zu können bedarf es klar vorgegebener Richtlinien und Vorgänge, die aus Kundensicht dokumentiert und, so benötigt, jederzeit einsehbar sind. Die im Vordergrund stehende Problematik bei der Durchführung dieses Prozesses, in seiner momentanen Ausprägung, ist die Verwendung von E-Mailgruppenpostkörben und der aktiven Auswahl der eingesendeten Aufträge durch die Mitarbeiter. Dadurch, dass mehrere Mitarbeiter gleichzeitig lesenden und schreibenden Zugriff auf die Gruppenpostfächer haben entstehen Unklarheiten über den Verbleib eigegangener Aufträge. Verschiebt beispielsweise Mitarbeiter A bereits einen Auftrag in sein eigenes Postfach bevor andere Mitarbeiter dieses E-Mail registriert haben, erfahren sie unter Umständen weder über den Kontext des Auftrags noch seinen Bearbeitungsstatus. Sollte Mitarbeiter A allerdings gerade verhindert sein, sodass sich die Kontaktaufnahme zur Klärung der Auftragsdetails mit dem Kunden verzögert, kann es zur doppelten Einmeldung des Auftrags kommen, da aus Sicht der Kollegen von Mitarbeiter A noch keine E-Mail im spezifizierten Gruppenpostfach eingetroffen ist. Neben der Gefahr von Doppelmeldungen und Mehrfachbearbeitung von Aufträgen sieht der Einsteuerungsprozess keinerlei Kommunikation zwischen Auftragenden und Beauftragtem vor. Sollte sich der Kunde nicht aktiv dazu entschließen den Status des Auftrags zu hinterfragen oder der ausführende Mitarbeiter seitens IFS nicht freiwillig den Prozessfortschritt kommunizieren, kommt es in keiner Form zum Austausch zwischen diesen zwei Parteien. Aus Sicht des Autors ist für die Verbesserung dieses Prozesses der Einsatz eines Workflow-Management-Systems unumgänglich. Erst durch einen klar definierten Prozess, der softwareunterstützt auf seine Einhaltung überprüft wird, kann eine reibungslosere und kundenorientiertere Auftragseinsteuerung ermöglicht werden. Im Laufe dieser These wird der Einsteuerungsprozess erneut aufgegriffen und nach Einführung eines geeigneten Werkzeuges neu modelliert und umgesetzt.

Qualitätssicherungsprozess (IFS)

Der Qualitätssicherungsprozess umschreibt die von der Abteilung Infrastruktur getroffenen Maßnahmen zur Sicherstellung des Betriebs und der damit verbundenen Qualität der offerierten IT-Services. Dieser Prozess beschränkt sich meist auf Vorschläge zur Verbesserung eingesetzter System oder Anforderungen zur Qualitätsprüfung, die durch ein gehäuftes Fehleraufkommen bedingt sind. Abbildung 11 zeigt den schematischen Ablauf dieses sehr rudimentär definierten Prozesses.

Bei dem hier dargestellten Vorgang handelt es sich rein um Systeme, die im Verantwortungsbereich der Abteilung Infrastruktur stehen. Im Wesentlichen wird dieser Prozess ad Hoc und äußerst situativ gelebt. Mittels eines formlosen E-Mails wird dem jeweiligen Produktverantwortlichen Hinweis über diverse, mit dem betroffenen System in Verbindung stehenden, Ereignisse gegeben, mit der Bitte um eine Qualitätsanalyse. In Folge dessen ergreift der jeweils zuständige Mitarbeiter Maßnahmen, die eine Untersuchung des Systems einleiten. Die Ausprägung der gewählten Methoden reichen vom Verfassen ergänzender Dokumentation bis zur Umgestaltung oder Neuentwicklung von Applikationen.

Potential

Welchen gravierenden Entwicklungsbedarf dieser Prozess aufweist lässt sich aus Abbildung 11 erahnen. Weder sind für die qualitätssichernden Maßnahmen wiederkehrende überprüfungen in Form von Audits vorgesehen, noch ist eine klar definierte Vorgehensweise für den gesamten Ablauf während der Untersuchung der betroffenen Systeme dokumentiert oder implementiert. Dieser „auf Zuruf"-Charakter erschwert aussagekräftige Ergebnisse über qualitätssteigernde Maßnahmen auszuwerten, da hierfür regelmäßig Basisdaten als Vergleichswerte herangezogen werden müssten. Ein weiteres Hindernis ist die Tatsache, dass die Hardwareverantwortung für einen Großteil der Systeme an externe Dienstleister ausgelagert ist, sodass für einfache Performanzmessungen externe Hilfe angefordert werden muss. Bedingt durch die meist umständliche Kommunikation mit den für den Betrieb verantwortlichen Externen, entsteht weiteres Chaos in der Durchführung des Prozesses. Die einzige Möglichkeit diesen Ablauf, aus Sicht des Verfassers, effizienter zu gestalten ist das Einsetzen eines Ticketing-Tools, das eigens auf die verwendeten Systeme zugeschnitten ist. Mittels eines, nach Wichtigkeit des Systems definierten, Tickets muss in regelmäßigen Zeitabständen eine Qualitätsanalyse durchgeführt werden. Im Fokus dieser Qualitätsauswertung steht das Abarbeiten einer, mit dem Produktverantwortlichen und dem jeweils zugehörigen operativen Mitarbeitern, entworfenen Checkliste. Durch das Bearbeiten, der auf dieser Liste angeführten Anforderungen, wird zumindest eine gleichbleibende Servicequalität abgedeckt. Zusätzlich muss das eingesteuerte Ticket, die Möglichkeit bieten, pro Qualitätssicherungszyklus, um neu eingemeldete Themen zu wachsen, sodass diese in einem späteren Verbesserungslauf als Teil der Standardcheckliste aufscheinen.

Budgetkontrollprozess (IFS)

Beim Budgetkontrollprozess handelt es sich um jenen Vorgang, der die Rechnungsverwaltung für Projekte der Abteilung Infrastruktur übersieht. Einen schematischen Ablauf des momentan verwendeten Prozesses bietet Abbildung 12. Hier wird der Umgang mit eingehenden Rechnungen und zugehöriger Projektbudgetverwaltung seitens des Teams IFS dargestellt.

Schaubild

Bedingt durch die Tatsache, dass die Abteilung Infrastruktur nahezu in jedem, auch nur annähernd IT-gestützten, Projekt vertreten ist, erfolgt der Rechnungseingang über verschieden Mitarbeiter. Diese, für die jeweilig ausgewählten Projekte, Mitarbeiter repräsentieren in jenen Vorhaben die verantwortliche Schnittstelle zum Team Infrastruktur und haben somit auch die Kostenverantwortlichkeit inne. Beim Eingang einer Rechnung werden die wichtigsten Zahlen vom Mitarbeiter manuell extrahiert und in eine eigens entwickelte Webanwendung eingepflegt. Betrieben und gewartet wird diese Webanwendung von der Abteilung Infrastruktur, wobei es sich lediglich um eine Repräsentationsplattform handelt. Mittels des Webtools lässt sich eine Aufstellung der budgetierten Ressourcen und der bisher verwendeten Mittel wiedergeben. Durch diese Kontrolle wird innerhalb der Abteilung über die Verwendungsmöglichkeiten der Restressourcen entschieden. Abschließend wird die eingegangene Rechnung weiter an die Buchhaltungsabteilung gegeben, sodass diese beglichen werden kann.

Service Level Agreements (GER)

Service Level Agreements (AUT)

Fehlermeldeprozess (GER)

Fehlermeldeprozess (AUT)

Einführung ConSol

Reifegradmodell

Einführung Incident Management

Einführung Auftragseinsteuerung

Wirtschaftliche Aspekte

Ausblick

Fazit

Literaturverzeichnis

  • Balzert, H. (2005). Lehrbuch der Objektmodellierung - Analyse und Entwurf mit der UML 2 (2. Ausg.). München: Elsevier GmbH.
  • Wagner, K. W. (2007). Performance Excellence. Der Praxisleitfaden zum effektiven Prozessmanagement (1 Ausg.). München: Hanser Fachbuch.

Please be aware that the free essay that you were just reading was not written by us. This essay, and all of the others available to view on the website, were provided to us by students in exchange for services that we offer. This relationship helps our students to get an even better deal while also contributing to the biggest free essay resource in the UK!