• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Datenbanken
  • Server
  • IT-Security
  • Speicher
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
  • Künstliche Intelligenz
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
• Aktuelles
• Termine
• IT-Jobs

• Entwicklung
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Service Level Agreements (SLAs) effektiv managen gelingt, wenn der IT-Betrieb geregelt ist und wenn die IT-Services klar umrissen sind. Erst auf dieser Basis können die SLAs wirksam zusammengestellt werden. Ziel dieses Artikels ist es, ein Konzept aufzuzeigen das den Zuschnitt der SLA-Dokumente gestaltet und die IT-Servicebeschreibung strukturiert.

Ein neuralgischer Punkt dabei ist die Problematik, IT-Services zu beschreiben. Dies soll an einem einfachen Vergleich verdeutlicht werden. Die Autoindustrie, Druckerei, Weberei haben es gezeigt. Nur Produkte von der Stange lassen sich massenfähig anbieten und absetzen. Dieser Schritt ist in der IT ebenfalls nachzuholen. Doch sind Automobile, Bücher und Kleidung anfassbare einzukaufende Produkte, die in der IT erst klarer umrissen werden. Es finden sich Analogien bei der Übertragung oder beim Hosting. Dies verhält sich bei Applikationen anders, sie sind vielfältig und müssen in ein Schema eingepasst werden, damit eine konfektionsnahe Leistungserbringung möglich ist. 

Die kommenden Abschnitte zeigen, welche Strukturen geschaffen werden müssen, um die Vielfalt an Leistungen so zu kanalisieren, dass ein Konzept entstehen und produktiv zum Einsatz gebracht werden kann. Hierzu ist es besonders wichtig, die Transparenz von IT-Services zu untersuchen.

1. Analyse der Transparenz von IT Leistungsbeschreibungen

Die Leistungskategorien, die sich in der Praxis bewähren, sind ein zentraler Ausgangspunkt in dieser Analyse. Dabei müssen wir u.a. unterscheiden, welche Aspekte in Zusammenhang gebracht werden dürfen. 

Die derzeitigen Leistungsbeschreibungen zeigen das Dienstleistungsspektrum von Betreibern im Gesamten auf. Häufig findet man, dass die betrieblichen Abläufe (z.B. Einkauf) mit dem technischen Dienstleistungsspektrum, z.B. Email-Service, gekoppelt sind – in der Form, dass die Verfügbarkeit eines Arbeitsplatzes sich zusammensetzt aus der Bereitstellungszeit eines Arbeitsplatzes mit Emailbetrieb. Eine Trennung des Email-Services und eine Leistungsbeschreibung der Arbeitsplätze ist erforderlich, um einen Überblick zu behalten. In dem genannten Beispiel würde sich ein negatives Feedback von Kunden des Rechenzentrums nicht klar zuordnen lassen. Ist der Kunde unzufrieden, weil der Service Email nicht wie vereinbart läuft oder weil der Arbeitsplatz nicht ordnungsgemäß funktioniert? Solchen Unschärfen gilt es entgegenzutreten. Zu vermeiden ist die Vermischung der betriebswirtschaftlichen Herangehensweise mit Qualitätsaspekten. Die fehlende Trennung zwischen Abläufen und technischen Leistungen erschwert eine servicenehmergerechte Auswertung der im laufenden IT-Betrieb erbrachten Leistung. Das Ergebnis: Ist mit der IT unzufrieden – und diese Haltung ist subjektiv und schwer verbesserbar.

Diese Situation ist so zu strukturieren, dass Betreiber und deren Kunden ein gemeinsames Verständnis über die erbrachten, bzw. ausgelagerten Dienste erhalten. Im Folgenden wird ein Modell zur Strukturierung der Leistungsaspekte vorgestellt, das anschließend zu einer Standardisierung führt und in Service Level Agreements übernommen werden kann. Um dies zu erreichen, werden die technischen und betrieblichen Sichten aufeinander abgestimmt, um die Unterschiede in der Herangehensweise zu verdeutlichen und die neuralgischen Punkte zu erkennen.

Hierzu müssen für folgende Punkte Festlegungen getroffen werden: 

1. Definition der zu modellierenden Dienstleistungen;
2. Bestimmung des Niveaus der Dienstmodellierung.

Für beide Punkte liegen nur isolierte Arbeiten vor. Der Anspruch eines generischen Modells wird dabei nicht erreicht. Im SOUSIS-Ansatz ist das Verständnis über die Geschäftsbeziehung zwischen zwei Outsourcing-Partnern geprägt. In 2015 wurde das entworfene SOUSIS-Modell im vom Bundesministerium für Forschung und Entwicklung geförderten SLA-Richtliniendokument für Cloud-Services neben COBIT, ISO und ITIL zu den Standards gezählt. Das Akronym SOUSIS des Modellnamens steht dabei für:

Was ist die Leistung am Kunden? Diese Frage ausführlich zu behandeln, führt zu einem gemeinsamen Begriffsverständnis, auf das sich beide Seiten verständigen, um im Falle einer Unzufriedenheit die IT-Leistung beim Namen nennen zu können. 

2. Vorgehensmodell zur Beschreibung von IT-Leistungen

Jedes IT-Unternehmen sollte in einer transparenten Form die Leistung, die zum Kunden hin angeboten wird, formulieren. Viele Modellierer sind im Einsatz, um die Leistung und die zugehörigen Prozesse zu beschreiben. Einige Gremien kümmern sich darum, wie dies aussehen kann. So ist das Ergebnis für bestimmte Zielgruppen entweder sehr generisch, wie bei ITIL, oder nur für eine einzige Zielgruppe, wie bei eTOM, beschrieben. Ein leicht verständliches Gesamtkonzept ist wichtig. Dieses Gesamtkonzept ist für den IT-Betrieb wichtig und wird in diesem Abschnitt vorgestellt.

Ziel des Vorgehensmodells

Das Vorgehensmodell greift diese Problematik auf und definiert entlang der Anforderungen praktikable und betriebssichere Strukturen. Der Einsatz dieser Strukturen muss auf die Geschäftswelt anwendbar sein, also verschiedene Betriebsabläufe sowie Vertragsbeziehungen berücksichtigen und zugleich die Technik so beherrschen, dass die IT-Services kundenorientiert konfektioniert werden können.  

Im Folgenden werden die essentiellen Anforderungen für das Vorgehensmodell definiert. Das Vorgehensmodell muss für die Konfektionierung von IT-Services die Anforderungen aus diesen drei Bereichen abdecken. Abb.1 verdeutlicht dies.

Die Betriebsstrukturen, Geschäftsstrukturen und die Technologien stellen unterschiedliche Anforderungen, die im Folgenden beschrieben sind:

Anforderungen aus bestehenden Betriebsstrukturen

Anforderungen an das Vorgehensmodell ergeben sich aus Betriebsstrukturen. Diese Strukturen werden im Rechenzentrum aufgebaut, um einen kontrollierten Ablauf im Betrieb zu gewährleisten. Dieser kontrollierte Ablauf ist insbesondere bei der Konfektionierung von Leistungen zu gewährleisten. Hierfür muss das Vorgehensmodell eine probate Lösung liefern.

Die Betriebsstrukturen unterscheiden sich in jedem IT-Betrieb, auch wenn Standards wie ITIL eingehalten werden. Das Vorgehensmodell muss einerseits den Standards genügen, andererseits genügend Flexibilität aufweisen, um generisch anwendbar zu sein. Folgende Anforderungen werden an das Vorgehensmodell gestellt.

Befindet sich das Rechenzentrum in der Rolle, dass es von externen Unternehmen Leistungen beziehen muss, um die Leistung gegenüber dem Kunden zu erbringen, so sind die nach ITIL definierten "Underpinning Contracts" (UC) erforderlich. Diese müssen ebenfalls mit dem SLA des Rechenzentrums, das als Generalunternehmer gegenüber dem Kunden auftritt, abgestimmt sein. Hierfür müssen besonders die Service Levels (SL) entsprechend kalkuliert sein. 

Die Abb.2 zeigt, wie das Vorgehen im Gesamten dargestellt ist.

Standardablauf 
Den Einstiegspunkt beim Standardablauf bietet der Servicekatalog. Die zentralen im IT-Betrieb vorliegenden IT-Services müssen erhoben werden. Dabei werden vom Servicekatalog wesentliche Strukturen vorgegeben, sodass eine einfache Erhebung der Services aus dem IT-Betrieb möglich ist. Zu jedem Dienst liegen nach Fertigstellung des Servicekatalogs die zentralen Parameter zu Serviceklasse, -betrieb und -überwachung, unabhängig von einer konkreten Kundenbeziehung, vor. Diese Vorarbeit ist zwingend im Vorfeld zu leisten, um die Service Levels und weitere relevante Parameter miteinander vergleichen zu können. Ebenfalls gelten unternehmensweite Service Levels, die im Servicekatalog als übergeordnete Service Levels gekennzeichnet sind und für alle Services gelten.

Aus dem Servicekatalog heraus, werden die Leistungen für das Service Level Agreement zusammengestellt. Der Servicekatalog ist als Vorstufe für das Service Level Agreement zu verstehen. Die einzelnen Dienste sind atomar aufgebaut, sodass sie wie Module behandelt und für den Kunden individuell zusammengestellt werden können. Durch die Normierung können die Werte zu den Diensten nach der Zusammenstellung miteinander abgeglichen werden, sodass eine homogene Kundenlösung entsteht. Müssen mehrere Dienste gegenüber einem Kunden für getrennte Geschäftszwecke – z. B. Callcenter, Buchhaltung, Logistik – gekoppelt werden, so können diese in einem SLA zusammengefasst sein oder in mehrere SLAs aufgetrennt werden. 

Um die Homogenität der Lösung für den Kunden zu gewährleisten, können die Wertebereiche der übergeordneten Service Levels nur reduziert werden, nicht jedoch ausgeweitet werden. Eine Ausweitung kann eine starke Beeinflussung für den täglichen Betriebsablauf des IT-Personals bedeuten. 

Nachdem die Leistungen des Servicekatalogs im SLA abgestimmt sind, werden die Verantwortlichkeiten zwischen beiden Vertragsparteien verhandelt. Dabei sind die Punkte Verantwortung, Durchführung, Mitwirkung und Informationspflicht zur kontinuierlichen Leistungserhaltung und -erbringung gemeinsam zu klären. 

Nachdem das Service Level Agreement in seiner Ausprägung umfassend beschrieben ist, wird es dem entsprechenden IT-Rahmenvertrag zugeordnet. Somit sind im Wesentlichen die technischen Rahmenbedingungen festgelegt. Eine Weiterführung der organisatorisch abzustimmenden Werte erfolgt im IT-Rahmenvertrag. Im vorliegenden Ansatz wurde darauf geachtet, dass das SLA und der IT-Rahmenvertrag überschneidungsfrei aufgebaut sind. Dies erleichtert die Handhabung bei Änderungen durch neu hinzukommende, sich ändernde oder wegfallende Leistungen. Eine Besonderheit ist z. B. die Trennung von Verantwortlichkeiten im SLA und den Verantwortlichen im IT-Rahmenvertrag, die namentlich erwähnt sind und gegenzeichnen müssen. Somit bleiben auch Änderungen auf den IT-Rahmenvertrag begrenzt und sind dadurch ebenfalls beherrschbar.

Der IT-Rahmenvertrag verweist u. a. auf bestimmte unternehmensinterne Dokumente, die z. B. bestimmte Abläufe definieren. Ein zentrales Dokument, dem hier eine besondere Stellung zukommt, ist die Minderungsregelung. Hier wird definiert, wie bei Leistungsverzögerung oder -ausfall im konkreten Fall vorgegangen wird. Dies sind meist Regelungen, die erst ab einem festgelegten Niveau der Leistungsminderung eintreten und eine Reduzierung der Leistungsverrechnung ergeben.

OLA-Erweiterung
Nachdem der Standardablauf erfolgt ist, kann es wie oben genannt zu Erweiterungen kommen. Der interne Betrieb größerer Rechenzentren ist meist in einzelne IT-Abteilungen für z. B. Serverbetrieb und Applikationshosting aufgeteilt. Werden gegenüber Kunden komplexe Leistungen angeboten, die aus den IT-Services der jeweiligen Abteilungen zusammengesetzt werden, so sind Operation Level Agreements nach ITIL zu definieren. Das Modell greift diese Tatsache auf und setzt es über ein gemeinsames Template um. Sowohl die Strukturen des Servicekatalogs, als auch die im Service Level Agreement enthaltenen, kommen hier analog zum Einsatz. Es sind auch die Basisleistungen der IT in einem oder mehreren Servicekatalogen zu definieren. Nach dem Angebot aus dem Servicekatalog, können die einzelnen IT-Abteilungen ein oder mehrere Services in einem OLA zusammenstellen und diesen abstimmen. Basierend auf diesen OLAs, können jetzt die Werte und Service Levels mit einem Service Level Agreement verglichen und abgestimmt werden. 

Innerhalb der OLA-Erweiterung ist ein Service Level Kalkulator aufzubauen, der zur Darstellung und gegenseitigen Berechnung von Service Levels dient. Aus dem Kalkulator werden anschließend die Werte in den jeweiligen OLAs oder SLAs übernommen. Aufgrund des Szenarios, dass Leistungen von "unten" eingekauft und "oben" angeboten werden, ergibt sich meist die Richtung, dass die OLAs maßgeblich das SLA beeinflussen und entscheiden.

UC-Erweiterung
Werden externe Unternehmen bei der Erbringung von IT-Services vertraglich eingebunden, so spricht man lt. ITIL von Underpinning Contracts. Letztlich sind diese Verträge analog zu SLAs zu verstehen. Denn Verträge kommen u. a. auch durch andere Umstände zustande, sodass der direkte Bezug zu einem aktuellen Kundenprojekt zum Vertragsabschluss nicht gegeben war. Wird z. B. eine Netzleistung eingekauft und später mehrfach für den Transport von IT-Applikationen verwendet, so wird aus der Sicht des Providers aus dem SLA ein Underpinning Contract. Die UC-Erweiterung ist flexibel in das gesamte Vorgehensmodell einfügbar. Es sind jedoch einige Besonderheiten besonders zu berücksichtigen. 

• Die Leistungen sind meist nicht in einem IT-Servicekatalog definiert. Jedes Unternehmen definiert eigene Services. Für diesen Fall müssen die Services dennoch entsprechend normiert werden. Die UC-Erweiterung leistet dies indem das UC das SLA-Template verwendet und somit konform zum OLA und SLA wird. Über diesen Mechanismus lassen sich heterogene, von externen Unternehmen kommende Leistungen normieren.
• Die UC-Erweiterung setzt sich aus dem Standardablauf und der OLA-Erweiterung zusammen. Vom Standardablauf werden das SLA-Template und das Konzept zur inhaltlichen Trennung im IT-Rahmenvertrag übernommen. Im IT-Rahmenvertrag können ggf. andere Aspekte auftreten, sodass eine inhaltliche Trennung als kleinster gemeinsamer Nenner umsetzbar ist. 
• Aus der OLA-Erweiterung wird der Service Level Kalkulator verwendet, um die Abstimmung zwischen SLA und OLA vornehmen zu können. 

Für das Vorgehensmodell gilt, dass zum Standardablauf die OLA-Erweiterung sowie die UC-Erweiterung dynamisch hinzugefügt werden können. Dies ist insbesondere dann wichtig, wenn bereits Verträge neu verhandelt werden oder bereits bestehen und zur Anwendung kommen. 

3. Servicekatalog

Der Servicekatalog dient dazu, die IT-Leistungen, die das Rechenzentrum anbietet, in einer einheitlichen Systematik zu beschreiben. Dabei werden alle relevanten Leistungen einem Service zugeordnet. Ziel ist es, die Erstellung von SLAs adäquat zu unterstützen und stark zu formalisieren. 

Der Servicekatalog ist eine Leistung der IT-Produktion. Die Pflege und Aktualisierung wird innerhalb der IT-Produktion in Absprache mit den internen IT-Abteilungen vorgenommen. Weitere Zuständigkeiten sind nicht definiert und gesondert abzusprechen. 

Struktur des Servicekatalogs

Der Servicekatalog ist ein wichtiges Hilfsmittel, um auf Kundenanforderungen optimal zu reagieren oder Service Level Agreements präzise erstellen zu können.

In Abb.3 sind die wichtigsten Elemente und deren Anordnung dargestellt.

Die folgende Konzeption wurde für den Aufbau des Servicekatalogs verwendet. 

Es sind die Vorgänge des Prozesses Service Level Management beschrieben, die erforderlich sind, um den Servicekatalog auf die SLAs anwenden zu können. Zusätzlich sind hier die zentralen Werte, die den Betrieb der Services operativ ermöglichen, explizit genannt. Diese Werte sind die "übergeordneten Service Levels" und gelten für alle Dienste und sollten für spezielle Leistungen nicht verändert werden. 

Das Element "Service" nimmt alle Leistungen mit einem vordefiniertem Template auf. Für das Element Service können zusätzlich Kategorien definiert werden, um bei vielen Services eine Strukturierung zu erhalten. Diese ist nicht bindend und kann ggf. aufgegeben werden. Letztlich kommt nur der Service zum Tragen. Diese Flexibilität ist deshalb wichtig, da Services je nach Anwendungsfall unterschiedlich strukturiert werden müssen. Eine starre Hierarchie ist aus diesem Grund nicht sinnvoll und dauerhaft aufrecht zu halten. 

An das Element Service schließt der Bereich "Begriffe und Definitionen" an. Hier werden ähnlich wie bei einem Glossar die Begriffe eingeführt und kurz erläutert, sowie bestimmte Definitionen für Kennzahlen vorgenommen. 

Das abschließende Element wird gesondert zu den Services definiert und behandelt die Kosten, die für einen Service berechnet werden. Diese komprimierte Darstellung aller Services in einer Preisliste erlaubt ein kontinuierliches Aktualisieren der Kosten. Weiterhin kann der Servicekatalog ggf. auch ohne Preisliste an Kunden zur Ansicht weitergegeben werden. Dies ist szenariospezifisch zu berücksichtigen, denn für eine IT-Lösung mittels Services können und müssen bestimmte Bereiche auch individuell kalkuliert werden, sodass eine starre Preisliste kontraproduktiv und somit nicht zielführend wäre.

Der Servicekatalog kann jedoch nicht als vollständiges Kompendium betrachtet werden, das alle Anforderungen im Speziellen behandeln kann. Die zentralen Charakteristika eines Dienstes werden prägnant beschrieben und bestimmte wiederkehrende Serviceklassen vereinheitlicht dargestellt. Ebenfalls wird die Zuteilung betrieblicher Zuständigkeiten dem Verhandlungsprozess überlassen. Der Servicekatalog dient dazu, die Eckpunkte eines Services festzulegen. In der konkreten Umsetzung müssen diese, wie in "Anwendung des Servicekatalogs" beschrieben, ausgestaltet werden. Der Servicekatalog beschränkt sich auf die Erbringung des Services. Die Auslieferung von Diensten mit Lieferzeiten, werden hier nicht berücksichtigt und sind gesondert im Service Level Agreement beschrieben. 

Im folgenden Abschnitt werden die einzelnen Elemente und deren Flexibilität beschrieben.

SLM-Prozess

Der Service Level Management-Prozess besteht aus einer Vielzahl von Rollen, die sich gemeinsam abstimmen müssen, um die IT-Lösung an den Kunden auszuliefern. Um Unstimmigkeiten über die Art des zu liefernden Services zu vermeiden, dient dieser Prozess zur Präzisierung der gegenseitigen Erwartungshaltung. 

Die Ausprägung des Service Level Management unterscheidet sich deutlich an der Art der IT-Leistungen, die ein Rechenzentrum anbietet. Werden kleinere und stark vorkonfektionierte Lösungen für bestimmte Zielgruppen angeboten, so wählt der Kunde aus dem Servicekatalog aus und anschließend kommt der Vertrag zustande. Anders verhält sich das Service Level Management für große IT-Lösungen – z. B. Outsourcing von 4.000 Servern und 600 Applikationen. Deutlich ist, dass auch hier ein Servicekatalog benötigt wird, um die Komplexität zu beherrschen. Die Abstimmung durch alle Abteilungen ist dennoch erforderlich, da bestimmte Details zu klären sind. Das Service Level Management verringert diesen Anteil, indem der Servicekatalog um entsprechende Parameter ergänzt ist. 

Der Ablauf des Service Level Management sieht wie folgt aus: Der Kunde kann aus einem Servicekatalog, oder einem vorkonfektionierten Serviceangebot, seinen benötigten Service auswählen. Entweder entsteht direkt der Vertrag, oder es sind Treffen einzuberufen, um die Anforderungen seitens des Kunden genauer abzustimmen.

Im Service Level Management entsteht der erste Entwurf eines SLAs für den Kunden. Hierfür können ggf. bereichsbezogene Abstimmungen stattfinden. Anschließend wird der intern abgestimmte Entwurf mit dem Kunden diskutiert. Je nach Status des SLA, erfolgt eine neue Iteration, oder es wird der Entwurf als Vertrag formuliert. Die Bereiche Vertragsmanagement und IT-Controlling übernehmen hier die tragende Rolle. Es entsteht der Auftrag und das SLA wird zusammen mit einem IT-Rahmenvertrag verabschiedet. 

Übergeordnete Service Levels

Die übergeordneten Service Levels gelten für alle Services im Servicekatalog. Alle weiteren erforderlichen Service Levels sind bei den einzelnen Services spezifisch festgelegt.

Ziel der übergeordneten Service Levels ist es, einen Betriebsstandard zu prägen und die Erstellung und Verwaltung von SLAs zu vereinfachen. Die Anforderung nach übergeordneten Service Levels resultiert aus der Tatsache, dass bei der Untersuchung von Rechenzentren jeder Service individuell erscheint. Die Analyse zeigt auch, dass eine Diskrepanz zwischen dem tatsächlich gelebten operativen Geschäft und den Betriebsunterlagen existiert. Häufig sind in den Betriebsunterlagen ITIL-konforme Prozesse mit allen potentiellen Ausprägungen beschrieben und bewertet. Das Tagesgeschäft in Rechenzentren zeigt, dass am User Helpdesk und in der Störungsbearbeitung ein Reglement eingehalten wird, man sich intern auf den kleinsten gemeinsamen Nenner geeinigt hat. Die übergeordneten Service Levels nehmen diesen Aspekt auf und definieren dies explizit. Sodass die Werte im Servicekatalog die Rechenzentrumsrealität genauer beschreiben. Sichergestellt werden soll eine kontinuierliche Betriebsstabilität, die auch im Service Level Management bekannt sein muss.  

Die übergeordneten Service Levels fassen somit die wichtigsten Eckpunkte des Betriebs des Providers zusammen. Zu diesen Eckwerten zählen z. B. Zeiten aus dem IT-Betrieb. 

Beispiel
Das nachstehende Beispiel zeigt die Kernzeit im Rechenzentrum und ist als bedienter Betrieb ausgewiesen. Werden Wartungen vorgenommen, so erfolgen diese innerhalb vordefinierter Wartungsfenster. Die Erreichbarkeitszeiten werden klar definiert. In diesem Beispiel wird das Gewicht auf die Transparenz des IT-Betriebs gelegt und die Quantifizierung nicht näher erläutert.

Es ist offensichtlich, dass der Betrieb der Services unabhängig von bestimmten SLAs nach einem definierten Schema abläuft. Dieses Schema wird in den übergeordneten Service Levels klar definiert.

Service

Ein Service wird durch mehrere Aspekte charakterisiert. Jeder Service ist in folgende Kategorien unterteilt: Kurzbeschreibung, Serviceklasse, Servicebetrieb und Serviceüberwachung. Unter diesen Kategorien werden alle relevanten Serviceparameter beschrieben. 

Serviceklasse
Innerhalb der Serviceklasse werden Kennzahlen wie Verfügbarkeit, Antwortzeit und Bandbreite definiert und mögliche Levels zum überwachten Betrieb angegeben.

Die nachstehende Tabelle zeigt ein Beispiel:

Kennzahl	Definition
Verfügbarkeit	Analog zur Antwortzeit gelten die Zeitpunkte für die Messung. Kann keine Antwortzeit ermittelt werden, gilt die Nichtverfügbarkeit. Die Gesamtverfügbarkeit wird pro Monat ermittelt und berechnet sich nach folgender Formel: TSLA-Laufzeit: Dienste, die zwischen Servicegeber und Servicenehmer vereinbart werden, sind zeitlich begrenzt. Der Zeitraum der Messung wird auf die SLA-Laufzeit beschränkt. TWartungsfenster: Zeiträume, in denen der Service durch geplante und abgestimmte Wartungsarbeiten nicht bereitgestellt wird. TNichtverfügbarkeit: Zeitraum, in dem der Service ungeplant nicht zur Verfügung steht. Er berechnet sich aus der Summe der einzelnen Ausfälle.
Reaktionszeit	Die Reaktionszeit wird wie folgt definiert: RZ = EZPReaktion - SZPReaktion RZ: Reaktionszeit SZPReaktion: Der Startzeitpunkt referenziert auf den Zeitstempel im Trouble Ticket System, nachdem eine Störung am Service Desk gemeldet wurde und als Ticket formuliert ist. EZPReaktion: Der Endzeitpunkt ist durch den Zeitstempel im Trouble Ticket System gekennzeichent, nachdem ein Problembearbeiter festgelegt wurde.

4. Service & Operation Level Agreement und Underpinning Contracts

Wenn davon ausgegangen wird, dass ein Servicekatalog definiert ist, so stellt sich die Frage, ob dies bereits genügt. Denn wenn der Kunde seinen Service und seine Leistungsklasse gewählt hat, dann wäre alles geregelt? Dies ist nicht der Fall. Das Service Level Agreement nimmt die ausgewählten Bestandteile auf, erweitert diese um zusätzliche Zusicherungen. Die meisten Unternehmen unterschätzen oftmals die Bedeutung der vereinbarten Service Level Agreements. Beispielsweise ist zu regeln, ab wann bei Überschreitung der SLA-Werte die ersten finanziellen Kompensationen geleistet werden. Dabei ist entscheidend, ob absolute, verbindliche Grenzwerte oder Mittelwerte definiert sind und nicht durch Formulierungen wie "in der Regel" oder "normalerweise" verwässert werden. Alle angegebenen Werte sollten genau beschrieben sein, sodass Messungen zum Nachweis zweifelsfrei möglich sind und nicht nur bloße Zahlen im Vordergrund stehen.

Für Service Level Agreements, Operation Level Agreements und Underpinning Contracts wird ein einheitliches Template verwendet. Dieses Template ist in Abb.5 umgesetzt.

7. Zusammenfassung

Durch die Festlegung der Semantik von Begriffen, wird die anschließende Anwendung der Begriffe in der Leistungsbeschreibung zu einer einfachen Handlung, die klar vollzogen werden kann. Ebenfalls bringt der Einfluss aus der Technik einen Beitrag, um ein klares Bild entstehen zu lassen. 

Die zusätzlichen Kennzahlen zeigen, wie man Leistungen parameterisieren kann. Die Kennzahlen sind u.a. von zentraler Bedeutung, denn durch sie wird die IT-Factory gesteuert und die Leistung gegenüber dem Kunden entsprechend geregelt. Sofern dieser sich auch an die Vereinbarung und Mitwirkungspflichten hält. Typisches Praxisbeispiel ist das Beziehen einer höheren Leistung durch mehr Arbeitsplätze, sofern diese der Servicenehmer in seiner eigenen Hoheit hat. Aber auch hier helfen Kennzahlen, wenn das Mengengerüst dadurch auch nach oben hin entsprechend formalisiert wird. 

Innerhalb des oben genannten Abschnitts wurde der Umgang mit den Kennzahlen u.a. noch nicht vorangetrieben. Überlegungen, wie man die Verfügbarkeit steigern kann oder die Antwortzeit verbessert, sind noch außen vor. 

Die Frage wie die Leistung beschrieben werden kann, ist bereits erfolgt. Es fehlen jedoch die im Business gelebten Strukturen, in die diese Basisfunktionen Einzug halten. Der kommende Schritt befasst sich mit der Konfektionierung von Leistungen. Objekte wie Servicekatalog, Kennzahlensystem und Service Level Agreement müssen für den IT-Betrieb definiert werden.

Autor

Dr. Robert Scholderer

Robert Scholderer arbeitet als Service-Level-Manager und Servicekatalog-Manager für Konzerne. Er befasst sich seit Mitte der 90er-Jahre mit Outsourcing-Verträgen. In seiner beruflichen Laufbahn hat er mehr als 1.000 SLAs…
>> Weiterlesen

Das könnte Sie auch interessieren

DevOps und Agile: Synergien im IT-Projektmanagement

Konflikte lösen: Der gute Konflikt

Lean Startup im B2B-Kontext anwenden

Aufarbeitung von Mikrotraumata und struktureller Gewalt

Flaccid Scrum – woran Agile scheitert und wie Sie es verhindern

AI-Office in zehn Schritten: Eine Bauanleitung