IT-Frameworks und Methoden - Servicemanagement

Aus FernFH MediaWiki
Version vom 30. August 2022, 14:17 Uhr von JUNGBAUER Christoph (Diskussion | Beiträge) (Die Seite wurde neu angelegt: „<span id="it-service-management"></span> = IT Service Management = '''Ziele der Lektion''' <ul> <li><p>Kennenlernen von etablierten IT Service Management Konzepten</p></li> <li><p>Verständnis für die Prozesse in IT Service Management</p> <ol style="list-style-type: decimal;"> <li><span id="grundsätzliches-konzept"></span> == Grundsätzliches Konzept == </li></ol> </li></ul> Unter IT Services können geschäftsprozessunterstützende IT-Funktionen, di…“)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Zur Navigation springen Zur Suche springen

IT Service Management

Ziele der Lektion

  • Kennenlernen von etablierten IT Service Management Konzepten

  • Verständnis für die Prozesse in IT Service Management

    1. Grundsätzliches Konzept

Unter IT Services können geschäftsprozessunterstützende IT-Funktionen, die sich den Nutzern meist als geschlossene Anwendungen präsentieren, verstanden werden. Die Nutzer müssen dabei durch die IT Services, wann immer sie es benötigen, bei ihrer Zielerreichung unterstützt werden.

Das bedeutet, dass ein IT Service dem Nutzer nur dann einen bestimmten Wert oder Nutzen liefern kann, wenn das IT Service sowohl zweckdienlich (WAS bekommt der Kunde?), als auch zur richtigen Zeit und in der richtigen Qualität verfügbar (WIE bekommt der Kunde die Leistung?) ist.

Datei:Media/image21.emf

Abb. 6.1: Utility und Warranty von IT Services in ITILv3 [ISS07, Seite17]

Ein IT Service kann dann als zweckdienlich (Utility) angesehen werden, wenn das IT Service durch die angebotenen Funktionalitäten die Leistungsfähigkeit oder die Flexibilität des Nutzers erhöht.

Damit das IT Service dem Nutzer in einer angemessenen Qualität (Warranty) zur Verfügung gestellt werden kann, müssen Verfügbarkeitszeiten, ausreichende Kapazitäten, Wiederherstellungsmaßnahmen im Katastrophenfall und hinreichende Sicherheit gewährleistet werden.

Wesentlich ist das Verhältnis zwischen der Zweckdienlichkeit und angebotener Qualität.

Datei:Media/image22.png

Abb. 6.2: Verhältnis zwischen angebotener Qualität
und Nutzen von IT Services [eigene Darstellung]

Hier muss ein vernünftiges Gleichgewicht gefunden werden. Ein IT Service, das jederzeit leistungsstark angeboten wird, für den Nutzer allerdings keinen Zweck hat, ist für den Nutzer genauso wertlos, wie ein IT Service das zwar alle Anforderungen des Nutzers abdeckt, jedoch nur außerhalb der Geschäftszeiten verfügbar ist.

Die Aufgaben des IT Service Managements umfassen somit die Planung, Entwicklung, Überwachung und Steuerung von IT Services über ihren kompletten Lebenszyklus mit dem Ziel, die Geschäftsprozesse des Unternehmens effektiv und effizient zu unterstützen. Darüber hinaus sollen die IT Services den Kunden zu angemessenen und marktüblichen Preisen angeboten werden.

Für ein erfolgreiches IT Service Management müssen bei der Optimierung der Erbringung der IT Services immer drei zentrale Zielgrößen im Auge behalten und dabei auf die richtige Balance zwischen den folgenden drei Größen geachtet werden:

  • Servicequalität
  • Zeit
  • Kosten

Datei:Media/image23.png

Abb. 6.3: Dreieck Servicequalität - Zeit – Kosten,
angelehnt an Tiemeyer [ETI05, Seite 8]

Dieses Dreieck kann durchgängig für die Planung, die Steuerung und die Kontrolle der IT Service Management Prozesse herangezogen werden. Ändert sich eine der Größen z.B. durch externe Einflussfaktoren, so kann das positive, aber auch negative Auswirkungen auf die anderen Größen haben [ETI05].

Beispielsweise kann die Qualität eines neuen IT Services gesteigert werden, indem mehr Zeit in die Entwicklung investiert wird. Dies hat aber zwangsläufig auch einen Anstieg der Entwicklungskosten zur Folge. Wird andererseits zu viel Augenmerk auf die Reduktion von Kosten gelegt, kann sich das gegebenenfalls negativ auf die Qualität der bereitgestellten IT Services auswirken.

Eine termingerechte Bereitstellung der gewünschten IT Services gehört zu den zentralen Zielen des IT Service Managements, wobei hier aber auch auf die gelieferte Qualität und die entstehenden Kosten zu achten ist. Um das zu ermöglichen, legt das IT Service Management Funktionen und Prozesse für die Strategie, den Entwurf, die Entwicklung, den Betrieb und die stetige Verbesserung von IT Services fest. Innerhalb des IT Service Managements sehen sich die beteiligten Personen, sowohl Lieferanten als auch Konsumenten von IT Services mit einer Reihe von Herausforderungen konfrontiert.

So sind die Ergebnisse (Outputs) von Serviceprozessen immateriell und nicht „greifbar“. Eine Messung, Validierung der Prozessleistung und Steuerung gestaltet sich daher als schwierig. Die Nachfrage nach IT Services und deren Umfang hängt sehr stark von den Anforderungen der Kunden hinsichtlich deren Nutzer, Prozessen, Anwendungen etc. ab. Der direkte Kontakt zwischen Servicelieferant und Servicekonsument lässt kaum Platz für Toleranzbereiche bei Beeinträchtigungen. Kunden wollen sichergehen, dass IT Services immer zur Verfügung stehen.
IT Services können allerdings nicht „auf Vorrat“ produziert werden, was direkten Einfluss auf das Management von Bedarfen und Verfügbarkeiten hat.

Es wurden viele Methoden, Modelle und Werkzeuge für die Unterstützung von IT Service Management entwickelt, wobei sich lediglich ein Ansatz flächendeckend etablieren konnte. Das „Best Practice“ Regelwerk ITIL wurde Ende der Achtzigerjahre von der britischen Regierung initiiert, um den effektiven und effizienten Einsatz von IT-Mitteln sicherzustellen und konnte sich als De-facto-Standard durchsetzen.

ITIL bietet ein generisches Rahmenwerk für die zu implementierenden IT-Prozesse. Ziele, Aktivitäten, Inputs und Outputs der verschiedenen Teilprozesse innerhalb der IT-Organisation werden zwar beschrieben, die konkrete Ausgestaltung der Prozesse bleibt den Unternehmen jedoch selbst überlassen. ITIL in der Version 3 besteht im Wesentlichen aus fünf Teilen, in welchen jeweils empfohlene Prozesse und Vorgehensmodelle für die Phasen des Lebenszyklus von IT Services vorgestellt und beschrieben werden.

Ziele des IT Service Managements

Die Zielsetzung im IT Service Management liegt darin, dem Business die benötigten IT Services zum richtigen Zeitpunkt, in einer angemessenen und vereinbarten Qualität und zu marktfähigen Preisen bereitzustellen.

Für das Unternehmen bedeutet das eine optimale Unterstützung seiner Geschäftsprozesse und die Steigerung der Produktivität der Nutzer. Im besten Fall sollen neue Geschäftsbereiche ermöglicht werden und ein Wertbeitrag von der IT für das Unternehmen geliefert werden.

Aus Sicht der IT werden hauptsächlich IT Services bereitgestellt, für die es auch einen Bedarf und eine Nachfrage gibt. Auf IT- und Business-Seite besteht Klarheit über die Qualität, mit der die IT Services bereitgestellt werden müssen. Die Prozesse für die Bereitstellung und Betreuung der IT Services werden definiert, was zu klaren Verantwortungen und einer effizienteren Bearbeitung von Änderungen und Störungen von IT Services führt. Durch einen kontinuierlichen Verbesserungsprozess werden die IT Services und die IT Serviceprozesse stetig an die Unternehmensbedürfnisse angepasst. Für die IT bedeutet das ein gesteigertes Ansehen sowie Reduktion von Kosten innerhalb der IT. Die IT soll sich somit von einem Cost Center zu einem Business Enabler wandeln.

Service Level Management

Die wahrscheinlich am weitest verbreitete Methode für das Messen von IT ist der Einsatz eines strukturierten Service Level Managements. Nicht zuletzt aufgrund der immer stärkeren Dienstleistungsorientierung und dem gestiegenen Outsourcinggrad von IT kommt dem Service Level Management eine zentrale Bedeutung zu. Es liegt auf der Hand, dass bei einer ausgelagerten IT an eine andere Organisationseinheit oder sogar einem anderen Unternehmen grundsätzliche Auffassungsunterschiede sowohl in strategischer, taktischer, aber auch operativer Hinsicht entstehen. Ein anderes Unternehmen verfolgt andere Ziele, richtet sich anders aus und versucht die Aktivitäten anders zu skalieren als eine interne IT, die sich voll und ganz auf das eigentliche Kerngeschäft des Unternehmens ausrichten kann. In den schlimmsten Management-Auffassungen widergespiegelt kann es sogar sein, dass IT nur als notwendiges Übel gesehen wird und ausschließlich „zu funktionieren hat“. IT-Dienstleister wenden in der Regel das Minimalprinzip an, sie wollen einen möglichst hohen Output mit dem geringsten Aufwand und das auch skaliert über alle Kunden. Ein Dienstleistungsnehmen will größtmögliche Qualität und vollste Ausrichtung auf seine Ansprüche. Dieser offensichtliche Diskrepanz kann nur mit guten konkreten bilateralen Vereinbarungen – den Service Level Agreements (SLA) – begegnet werden.

Vertragsformen (Rechtliche Grundlagen)

Service Level Management ist wohl eine ganz eigene Disziplin, es bildet ein Herzstück des IT Service Managements, da es die zentrale Kommunikationsschnittstelle mit dem Kunden und damit die schriftliche Grundlage der Kunden-Dienstleister-Beziehung darstellt. Es stellt sicher, dass alle IT Service Management Prozesse, interne Vereinbarungen mit Organisationseinheiten desselben Unternehmens – Operational Level Agreements (OLA) – und Underpinning Contracts (UC) mit externen Sublieferanten für die Erbringung der gesetzten Service-Ziele und damit die Einhaltung der Service Level Agreements (SLA) gegenüber dem Kunden des IT-Dienstleisters angemessen definiert wurden. Die SLAs definieren Qualität und Menge der zu erbringenden definierten Dienstleistung über einen vereinbarten Zeitraum und bestimmen die finanziellen Zahlungen an den Dienstleister für die Serviceerbringung. Neue Kundenanforderungen an Aspekte des IT-Services – Service Level Requirements (SLR) – werden formuliert und dabei versucht, die Geschäftsziele mit den IT Service Zielen in Einklang zu bringen und die Erwartungen auf ein realistisches Maß zu bringen. Der Service-Dienstleister kann dadurch auch die Erwartungen des Kunden in gewisser Weise steuern, sodass es ihm möglich ist, möglichst standardisierte Services anzubieten, die er mit den eingesetzten Mitteln skalieren kann. Oft weiß der Kunde nicht definitiv, was er möchte und muss ein gemeinsames Verständnis mit seinem Dienstleister erst erarbeiten. Das daraufhin vereinbarte SLA steht sozusagen für den Kompromiss, was der Dienstleister erbringen und der Servicenehmer akzeptieren kann, sodass dieser seine Geschäftsziele erreichen kann. Zusätzlich werden im Rahmen des Service Level Management Prozesses operative Aktivitäten subsumiert, also die Vereinbarungen verhandelt, abgeschlossen, überwacht, berichtet, auditiert und ständig verbessert [NIT08, Seite 56][WAL06, Seite 10f].

Service Level Management setzt zusammenfassend also mit SLAs ein Instrument ein, mit dem die Leistung einer IT-Organisation gemessen werden kann. Es umfasst einen Zyklus aus Planung, Koordination, Abfassung, Vereinbarung, Leistungsmessung, Berichtswesen und Entwicklung von Verbesserungen, um die IT Service Qualität sicherzustellen und ständig weiterzuentwickeln. Es stellt die schriftlich definierte Kundenbeziehung zum Service-Dienstleister dar [TSD06, Seite 29].

Service-Katalog-Gestaltung

Viele Unternehmen haben allerdings schon bei Schaffung einer ersten Voraussetzung für ein funktionierendes Service Level Management – dem Erstellen eines Service Katalogs – durchaus Schwierigkeiten. Um die Services überhaupt messen zu können, muss man die Services zuerst benennen und überhaupt definieren, was unter einem Service verstanden wird. Viele setzen ein IT-Service mit einem IT-System gleich. In vielen Fällen setzen sich die Services aus anderen Services (oder Servicebausteinen) zusammen, z.B. wird das Netzwerk-Service für viele andere Services eine Basisgrundlage darstellen. Das mag trivial klingen, in einem gewachsenen Umfeld ist diese strukturierte Sicht allerdings nicht eingängig. Das heißt also, dass man sich als IT-Organisation Gedanken zu seinen Services aus Kundensicht (die End-to-End-Sicht) machen und diese in einem Servicekatalog zusammenfassen soll. Diese Services bestehen wiederum aus einzelnen Komponenten oder Bausteinen, die sich mitunter für verschiedene Services wiederholen und zusammenspielen. Das kann beliebig granularer werden, eine dreiteilige Abstufung in Service, Servicemodul und Service-Element erscheint sinnvoll, um eine praktikable Abstufung der Servicebausteine zu erhalten [RBK08].

Die Servicebausteine des Service Katalogs werden einzeln soweit wie möglich für die drei Abstufungen beschrieben und enthalten

  • Kataloginformationen zur Einordnung in die Gesamtstruktur, Gültigkeit und Verantwortlichkeiten;
  • Leistungsbeschreibung, welche das Service hinreichend spezifizieren soll, indem das angestrebte Service-Ergebnis, verwendete Servicebausteine, Service Level Parameter wie Beschreibung, Ausprägung, Mengenangaben, Pakete, Messmethoden und -zeitpunkte niedergeschrieben und damit definiert werden;
  • organisatorische Regelungen wie Eskalationsverfahren, Fragen des Change Managements und des Supports (Erreichbarkeit, Reaktions- und Lösungszeiten in Bezug auf Incidents), Reporting und Preis-, Pönale- und Verrechnungsfragen, aber auch das Thema regelmäßige Service Level Reviews und Serviceverbesserung

Durch die aufgestellte hierarchische Struktur kann der Service-Dienstleister feststellen, ob und mit welchen Servicebausteinen er die Kundendienstleistung erbringen möchte und ob das unter den gegebenen Voraussetzungen (Ressourcen, Aufwand, Kosten) auch theoretisch möglich ist. Es gibt andere Strukturvorschläge, die zwischen Rahmen-SLA auf Unternehmensebene, Standard-SLA auf Kundengruppenebene und Individual-SLA auf einzelne Kunden und/oder Services unterscheiden. Man muss für die jeweilige Situation die bestmögliche Struktur wählen. Allen Strukturmöglichkeiten gemein ist jedenfalls, dass eine konsistente Gestaltung des Servicekatalogs unabdingbar ist [RBK08][NIT08, Seite 56ff][TSD06, Seite 38f].

Wird der Service Katalog dann noch um die vorgelagerte Service Pipeline erweitert, spricht man insgesamt laut ITIL vom Service Portfolio. Die Service Pipeline behandelt die Frage, wie Services von der Marktidee über das Design entwickelt und in einen laufenden Betrieb überführt werden. Aus dem Service Katalog herausfallende Services werden schließlich noch stillgelegt, wodurch der Service Life Cycle nach ITIL abgeschlossen wird. Salopp formuliert, behandelt die Service Pipeline das Change Management des Services [ISD07, Seite 73ff].

Service Levels

Auf Basis dieser Definitionen ist es nun möglich, eigene Kundenpakete zu schnüren und die Leistung zu beschreiben (Service Levels) und damit quantitativ und qualitativ mit dem Kunden zu vereinbaren, also ein SLA abzuschließen. In den Service Levels fließen sozusagen die gegenseitigen Erwartungen ein. Zusätzlich bekommt der Service-Dienstleister ein konkretes Bild seines erforderlichen internen Aufwands für die Erbringung des Services und kann also eine Leistungsverrechnung innerhalb seiner Organisation auf Basis des Service Level Managements etablieren. Um messbare Größen zu haben, müssen in den SLAs Aspekte wie z.B. Verfügbarkeit pro Zeitperiode, Supportzeiten mit Behandlungsverfahren, Festlegen der erforderlichen Informationen bei Neuimplementierungen oder Zielzeiten, usw. konkret in Zahlenwerten festgelegt werden. Diese Ziele sollen realistisch, erreichbar und wirtschaftlich formuliert sein. Es kann dadurch die Serviceerbringung – und darauf bezieht sich der hier dargestellte Aspekt des Messens hauptsächlich – regelmäßig überwacht, berichtet und dadurch ständig geprüft werden, ob die zuvor vereinbarten Service Level Agreements in der untersuchten Zeitperiode auch tatsächlich eingehalten wurden.

Das operative Service Level Monitoring kann unter Beteiligung des Kunden in Echtzeit über eine Kundenplattform erfolgen oder wird über ein z.B. monatliches Reporting durch den Dienstleister gewährleistet. Auch hier muss zuvor in der Leistungsbeschreibung genau definiert werden, was wie und wie oft überprüft werden soll und welche Zielwerte gesetzt werden. Durch die Charakteristik der Services, wenn sie aus vielen Bausteinen zusammengesetzt sind, besteht eine hohe Anforderung des Monitorings aus Kundensicht, also ein End-to-End-Monitoring. Zusätzlich muss im Bedarfsfall schnell eruiert werden können, welcher Baustein die gesetzten Toleranzlevels überschreitet und somit den SLA gefährdet. Spezielle komplexe Monitoring-Tools mit Drill-Down-Funktionalität können dabei unterstützen. Das Monitoring muss also sozusagen die abgestimmte Wahrnehmung des Service-Dienstleisters und des Kunden repräsentieren, was in vielen Fällen keine leichte Aufgabe ist. Auch punktuelle Audits (Service Reviews) und Kundenzufriedenheitsanalysen mit dadurch initiierten Verbesserungsmaßnahmen – Service Improvement Programs (SIP) – sollen die qualitative Serviceerbringung unterstützen und weiterentwickeln. Damit werden die „weichen“ Aspekte der Kundenbefindlichkeit abgedeckt. Um auch einen Anreiz für die ständige Weiterentwicklung der Servicequalität zu schaffen, sollten z.B. jährliche Service Level Reviews im SLA festgelegt sein [TSD06, Seite 43f].

Werden Abweichungen festgestellt, muss es Instrumente geben, wie diese behandelt werden. In der Regel gibt es Service Management Runden zwischen Dienstleister und Kunden, wo technische und kommerzielle Aspekte bei Bedarf diskutiert und Lösungen vereinbart werden, die Partnerbeziehung und Kommunikation gepflegt und der Ausblick auf kommende Ereignisse – etwa geplante Serviceausfälle zwecks Durchführung von Wartungsarbeiten – besprochen werden.

Sowohl der Servicedienstleister als auch der Servicenehmer tun gut daran, die Leistungserbringung anhand der Messgrößen regelmäßig zu kontrollieren. Das heißt, beide Organisationen müssen sich den operativen Aktivitäten ausgiebig widmen, regelmäßig Daten überwachen und erheben, SLA-Einhaltung feststellen, in Berichte oder Key Performance Indicators (KPI) zusammenfassen und SLA-Verletzungen behandeln und Verbesserungen initiieren und durchführen. Ein gewisser bürokratischer Aufwand ist somit unumgänglich, soll das Service Level Management ja nichts weniger leisten als die üblicherweise mehr oder weniger divergierenden Ziele der Organisationseinheiten oder Unternehmen soweit im Zaum zu halten, sodass die Service-Erbringung insgesamt qualitativ hochwertig und für die Geschäftszielunterstützung des Kunden optimal erfolgt. Dies ist eine Schlüsselfunktion für das Service Level Management, das auch als ein kompliziertes Bausteinsystem identifiziert werden kann. Es versucht, gegenseitige Abhängigkeiten von einzelnen Servicebausteinen zu identifizieren und die Konsistenz zueinander sicherzustellen, um – schließlich – den Kunden in seinen Geschäftszielen optimal mit IT-Services zu unterstützen. Es übersetzt Kundenerwartungen in für die IT verarbeitbare Messgrößen und bildet die begleitenden Prozesse dazu ab (Plan, Build, Run). Dieses System ist ständig Änderungen und Adaptierungsbedarf unterworfen, womit sich der Service Level Manager als Koordinationsstelle zwischen Endkunden und internen Organisationseinheiten bei entsprechender Organisationsgröße durchaus einer hohen Auslastung konfrontiert sieht. Wird die Kunden-Servicedienstleister-Beziehung nicht solcherart restriktiv festgelegt – bleiben also genügend Freiräume und Interpretationsspielraum – ist man sehr oft mit Eskalationen, Klärungen, Diskussionen und Subvereinbarungen konfrontiert. Eine ideale Beziehung zwischen den beiden Interessensparteien wird wohl nicht möglich sein, denn in der Praxis ist es nur eine Frage des Ausmaßes, wieviel Energie man in die Interpretation der Vereinbarungen stecken muss. Aus Praxissicht trifft daher die Daumenregel zu: Je dürftiger die Vereinbarung ist, desto mehr Aufwand muss für die tägliche Koordination von Eskalationsfällen eigesetzt werden.

Wiederholungsaufgaben

  1. Beschreiben Sie jene zwei Aspekte, die bei der kundenorientierten Bereitstellung von IT Services aus Sicht der IT beachtet werden müssen?
  2. Welche Unterschiede bestehen zwischen SLA, OLA, UC?
  3. Sie wollen einen SLA mit ihrem Dienstleister abschließen. Wie gehen Sie prinzipiell vor?

Die Lösungen zu den Wiederholungsaufgaben finden Sie in Anhang A.