• Home / Suche / News
• Expertise
• Projekterfahrung
• Vita
• Fachartikel

o DB Schema Migration
o Web Präsenz Server
o SSD und Disk Cloning
o Win or Web?
o Totalschwierigkeit
o Agile Werte
o SEU-Plattformen
o ERD Werkzeuge
o IT-Betriebskonzepte
o Requirements MM
o Doku-Management
o SLA-Management
o BI - Die 2. Revolution
o DWH Integritaet
o Crashkurs DB
o IT Theologie

• Kontakt - Impressum

Grundlagen der Service Level Agreements

Erfolgreich ist, vom Nutzen eines Dienstes auszugehen, den Dienst in seiner Bedeutung klar zu erfassen und diesen bedarfsgerecht und wirtschaftlich zu optimieren. Anwendungen, IT Betrieb, Hardware erhalten erst dann ihre ausgewogene Beurteilung, wenn diese als Teile des Dienstes betrachtet werden, den sie leisten. Die wirtschaftliche Service-Orientierung ist gekennzeichnet durch folgende Dimensionen:

• Nutzen: Was bringt der Dienst?
• Qualität: Wie gut deckt der Dienst den Bedarf? Welche Potenziale sind noch nicht genutzt
• Verfügbarkeit: Was bedeutet eine Ausfallzeit im betrieblichen Ablauf?
• Betriebssicherheit: Was ist die Sicherstellung des Services im Zeitablauf wert?
• Schutz gegen Missbrauch: Was kann an diesem Dienst schief gehen? Wie ist ein Missbrauch zu beurteilen? Welche Schutzmaßnahmen sind sinnvoll?
• Kosten: Welcher Aufwand ist zuordenbar? Welche Kosten würden durch Alternativen (Oportunitätskosten) entstehen?

Erst die Gesamtsicht auf den IT-Service ermöglicht sachgerechte Entscheidungen. Ein scheinbar kostengünstiges System ist zu teuer, wenn es keinen entsprechenden betriebswirtschaftlichen Nutzen leistet.

Gerade die Darstellung des Nutzens bereitet vielen Organisationen große Bewertungsprobleme. Obwohl diese häufig nicht trivial lösbar sind, sind realistische Bewertungen unabdingbar. Wenn sie nicht bewusst getroffen werden, dann sind individuelle Bewertungseinschätzungen implizit aus den Entscheidungen ableitbar … allerdings darf die Güte dieser Bewertungen bezweifelt werden.

Wenn Services im Mittelpunkt stehen, so gilt es, diese Services in wirtschaftlich sinnvollem Level sicherzustellen. Alle weiteren Einheiten wie Hardware, Software / Anwendungen, Netzdienste etc. ordnen sich im Service-Gedanken unter. Als Kernbegriff hat sich hier Service-Level-Agreement (SLA) eingeführt.

Schritte zu optimierten IT Services:

• Service Orientierung: Bedarf und Definition. Nach welchem Konzept werden Dienste benötigt?
• Service Level Verhandlung: Was benötigt der Service-Nehmer? Was leistet der Service-Geber? Wo ist ein wirtschaftlicher Kompromiss?
• Service Level Management: Ausgehend von den vereinbarten Service Leveln müssen die Services geliefert, überwacht und angepasst werden.

SLM ist keineswegs nur ein aktueller Hype oder eine notwendige Pflicht in einer veränderten Anforderungslandschaft. Es ist ein neuer Blickwinkel auf die Arbeit und Rolle der IT, vergleichbar mit dem Wechsel von der Manufaktur zu industrieller Fertigung in der Warenwirtschaft.

Das Dienstleistungsgeschäft erfordert eine klare Orientierung auf die Lieferung in vereinbartem Umfang. Es unterscheidet sich grundsätzlich von einer Warenlieferung. Darum müssen entsprechende Verfahren dieses sicherstellen.

In gewachsenen Strukturen haben sich bestimmte implizite Erwartungen eingestellt, die den Eindruck erwecken, eine aufwendige Strukturanpassung sei nicht erforderlich. Allerdings ist zu beobachten, das diese Erwartungen kundenseitig häufig nicht zufrieden gestellt werden. Wechsel des Serviceproviders, Verlagerung in Off-Shore-Services oder pauschale Preisdiskussionen sind die Folge. Sachgerechte Entscheidungen sind allerdings nur dann möglich, wenn Leistungsumfänge klar beschrieben sind – ein ausgeprägtes Service Level Management wird unverzichtbar. Es ist nicht hinreichend, einfach eine mehr oder minder präzise Vereinbarung zwischen Anwender und Dienstleister zu treffen, sondern diese Vereinbarung muss auch Überwacht und angepasst werden.

Näheres ist in ITIL beschrieben:

Zuweilen wird zwischen SLA und Operational Level Agreement (OLA) unterschieden. Ich halte dies jedoch eher für verwirrend. Denn wenn das SLA eine vertragswirksame Beziehung zwischen dem Endkunden und dem Service-Geber ist, und OLA die interne Leistungsvereinbarung, dann ist die Sprachverwirrung komplett, wenn die Interne IT-Abteilung mit dem Fachbereich als Profit Center ein SLA(?) oder OLA(?) abschließt, dieses sich aber auf externe Dienstleister SLA(?) oder OLA(?) als underpinning Contracts beziehen. Letztlich können sich ganze Ketten von unterschiedlichen Einheiten in einer Hierarchie aus beliebig gemischten internen und externen Dienstleistern zur Bereitstellung eines Service für den Endkunden zusammen finden. Auch ist die Sicht des Endkunden aus Sicht des Sub-Dienstleisters eine Andere als die des Endanwenders.

Ich schlage darum vor, ausschließlich von SLA's zu sprechen, die in ihrerer Beschreibung sowohl die hierarchische Stellung, als auch die rechtlichen Aspekte behandeln. Auch wenn formaljuristisch ein internes SLA eine anderen Status hat als ein Vertrag mit einem Drittunternehmen, so ist dies aus Sicht des Endanwenders wenig relevant. Er erwartet einen zuverlässigen Service, der klar vereinbart wurde.

Als erster Schritt in die Richtung Service-Orientierung ist der IT-Service-Katalog zu sehen. Alle Standard-Services sind hier knapp und präzise beschrieben. Überprüfbare Fakten z.B. Servicezeiten, Regel-Antwortzeiten etc. werden mit einen verbindlichen Preis ausgewiesen. Die Entwicklung von verursachergerechten, für den Kunden nachvollziehbaren Pricing-Modellen sollte darin im Mittelpunkt stehen. IT-Servicekataloge haben sich als ausgezeichnetes Mittel erwiesen, die Kommunikation zwischen IT und Fachabteilung zu verbessern, die Leistungsansprüche der Kunden mit der Leistungsfähigkeit der IT zu harmonisieren und das Denken in standardisierten Dienstleistungen auf beiden Seiten zu fördern.

Als Marketinginstrument stellt der IT-Servicekatalog die Leistungen der Serviceeinheit klar heraus und ermöglicht ein echtes Profit-Center-Denken. Leistungsfähigkeit und Kundenorientierung können dem Service-Nehmer vermittelt werden.

Zum Betrieb von Anwendungen ist eine punktgenaue Kommunikation zwischen IT- Servicegebern und Anwendern (Servicenehmern) unabdingbar. Die Definition der Anforderungen ist in der Regel kaum einseitig ohne Spezialkenntnisse befriedigend realisierbar. Auch bewegen sich die Anforderungen nicht unabhängig von der Kostenstruktur der Servicegeber: Ist ein Mehr an Service sinnvoll?

Die Einführung von SLAs und Service Level Management ist keine triviale Aufgabe. Deshalb haben wir hierfür eine systematische, modulare Vorgehensweise entwickelt, welcher ITIL-konform ist . Mit Hilfe dieses Einführungsprozesses wird der Weg zum Erfolg von Service Level Management und Service Level Agreements erreichbar.

Üblicherweise ist bei Services die Kostenbelastung einer typischen Sättigungskurve: Je nach Anwendung kann bis 95 % der mögliche Nutzen kostengünstig bereit gestellt werden. Erst bei Themen wie Hochverfügbarkeit steigen die die Kosten rapide an. Der Bedarf im Einzelfall und die spezifischen Kosten dafür sind Gegenstand der Abstimmung und Verhandlung zum SLA.

Dieser steinige Weg der Abstimmung wird entweder unterschätzt oder ist abschreckend für einen reifen Vertragsabschluss in beidseitigem Interesse. Das SLA-Management muss darum bereits den Verhandlungs- und Change-Prozess zu den SLAs unterstützen.

Wichtig sind die Vereinbarung präziser Rules:

• Zu welchen Zeiten sind welche KPIs einzuhalten?
• Was ist mit Ausnahmen? Z.B. bei Problem-Multiplikation innerhalb von Zeitfenstern?
• Wie sind Wartungsfenster zu beantragen und zu genehmigen, z.B. für Change-Management? Welche Regeln gehören dazu?
• Werks- und Feiertagskalender und abweichende Verfügbarkeiten.
• Sekundäre Servicezeiten mit abweichenden KPI-Thresholds: Erreichbarkeit in der Nacht eingeschränkt?
• Verursachergemäße Störungszuordnung - Definition der Abstimmprozesse.
• Abgestufte Vereinbarungen zu Vertragsstrafen.

Sind die Leistungsmerkmale definiert und der Katalog festgeschrieben, kann die Ermittlung der erforderlichen Aufwendungen geschehen. Diese stellen die entsprechenden Kosten dar und decken entsprechende Risiken und Lastspitzen ab: Wenn nur ein Third-Level-Experte bereit steht, kann dieser nicht zwei oder mehr Probleme parallel bearbeiten. Wird aber vereinbart, dass Wartezeiten in diesem Fall nicht akzeptiert werden, ist mit einer Vorhaltung von zwei oder mehr Experten zu rechnen. Das aber treibt die Kosten ...

Vereinbarungen abstimmen und Kalkulation der Kosten ist in der Regel ein iterativer Prozess, der sich zur Vereinfachung auf Standardisierung beziehen.

Ein nicht unerhebliches Problem ist das Thema Vertragsstrafen. Wie hoch sollen diese sein, wenn das SLA nicht eingehalten wird? Im einfachsten Fall werden keine Vertragsstrafen vereinbart. Dann aber wird der SLA unverbindlich und oft genug nicht wirklich ernst genommen. Auch ist die Drohung, einen anderen Service-Geber zu beauftragen oft stumpf, denn die Mobilität komplexer technischer Services - meist im Bündel einer Vielzahl der Services - ehre verschwindend gering.

Seriös ist die Vereinbarung von bis zu 50% bis 100% der monatlichen Service-Fee bei entsprechend gestaffelter Verletzung des SLA. In diesem Fall ist natürlich ein präzises SL-Measurement und Service Reporting erforderlich. Der Service-Geber muss darum einen Aufschlag berechnen, um die Sicherstellung des Services und die Risiko-Absicherung zu Finanzieren. Somit kann ein beidseitiges Interesse befriedigt werden, denn die Service-Fee ist an den Business-Value geknüpft und führt kein isoliertes Eigenleben.

Eine Vertragsstrafe in Höhen des finanziellen Risikos eines Produktionsausfalles kann im Kundeninteresse liegen, stellt aber ein hohes finanzielles Risiko für den Servicegeber dar, das er dann allerdings über ein Versicherungsunternehmen absichern muss. Denn unwägbarkeitensind nicht völlig auszuschließen und abzusichern - Beispiel: Der einfach besetzte Experte hat in der Nachtzeit ein gesundheitliches Problem und der Service kann über Stunden nicht erbracht werden ... die Schicht eines Automobilherstellers liegt lahm ... wie soll dafür die Risiko-Prämie berechnet werden? Die entsprechenden Verträge sind dann allerdings äußerst komplex und die Versicherungsleistungen werden möglicher Weise den Preis des Services übersteigen. Ein Zustandekommen eines derartigen Vertrages mit Einbezug von Versicherungsunternehmen dürfte allerdings wesentlich zu teuer für die Vertragsparteien werden, so dass der Service-Nehmer seine Produktionsrisiken nur zu geringem Teil auf den Service-Geber abwälzen kann. Der Service-Nehmer sollte allerdings durch die Drohung im Rahmen der Service Fee liegenden Kosten über das starke Interesse des Service-Gebers an der Einhaltung der Vereinbarungen überzeugt sein.

Ergänzend kann als Anreiz zu einem exzellenten Service nicht nur ein Malus, sondern auch ein Bonus vereinbart werden, wenn die vereinbarten Leistungen deutlich übertroffen werden.

Der Service Manager kümmert sich um die Organisation um die SLA's. Er koordiniert, stimmt die einzelnen Leistungen ab und organisiert ein Service-Team, dass sich um die Sicherstellung des Services kümmert. Er betreibt ein Service Reporting und sichert die Gesamtqualität des Services. Der Service Manager interessiert sich nicht persönlich für Echtzeit-Monitoring-Tools, die den Status des Services zeitnah darstellen, aber er kümmert sich darum, dass sein Service Team über derartige Werkzeuge verfügt. Auch sind die Methoden zur schnellen Störungsanalyse und Fehlerbehebung nicht das Arbeitsfeld des Service Managers, aber er ist daran interessiert, dass seine Techniker darüber verfügen.

Die Werkzeuge eines Service-Manager sind nicht nur ein Dokumentations-System, sondern ein formalisierter Regel-Editor, mit dem er die Abbildung der Vereinbarungen so IT-technisch darstellen kann, dass dass diese Regeln zu automatisierten Berichten auf einem KPI-Repository führen. Eingeschlossen sind auch Service-Controling, dass den Aufwand in beziehung setzt zur erbrachten Service-Qualität.

Capacity Manager, Change Manager und Continuity Manager liefern für die Bereitstellung der Services Komponenten und Informationen, die helfen, den Service bedarfsgerecht zu sichern.

Operator / Betriebsführer kümmern sich dagegen Online um die Systemüberwachung. Mit guten Werkzeugen und der passenden Organisation können sie proaktiv Trends und sich anbahnende Probleme erkennen, bevor es zu einem Störfall / Serviceanfrage / Incident kommt. Operator beseitigen Routine-Probleme und einfache Fälle selber, kennen aber vor allem den Eskallationspfad, mit dem sie Probleme von Spezialisten weiter bearbeiten müssen. Dieser ist für die möglichen Problembereiche recht unterschiedlich: Netzwerk-Spezialisten haben andere Bereiche als ein DBA, und Anwendungsspezialisten arbeitne nicht in Berechen des Betriebssystems und Storage-Management.

User Help Desk ist der Begriff der IT-Telefonseelsorge und des diesbezüglichen First-Level-Supports. Es benutzt primär ein Tiketiing Systems wie z.B. Remedy ARS. Eingehende Anfragen (Incidents) werden verfolgt und ggf. an die zuständigen Stellen eskaliert.

Der Spezialisten und Techniker beseitigen Probleme und komplexe Störfälle als Second oder Third Level Support. Diese treten zuweilen in Personalunion mit der Entwicklerrolle auf. Allerdings wird oft eine strikte Trennung von Produktion und Entwicklung gefordert. Darum wird hier auf eine klare Rollenzuordnung und Berechtigung geachtet. Ungeachtet dessen benötigen die Spezialisten leistungsfähige Werkzeuge, um die Problemanalyse effizient und zeitnah durchführen zu können.

Monitoring und Analysewerkzeuge haben allerdings Beziehungen zu Ticketing und Reporting-Werkzeugen, zumindest was die logische Bearbeitung angeht.

Im Systems Management werden häufig durch geeignete Werkzeuge (Monitore / Console) bereits das Systemverhalten überwacht, so dass zeitnah auf Fehlentwicklungen reagiert werden kann. Diese Daten könnten eine hervorragende Basis liefern, um die Vereinbarung zu den jeweiligen Service Leveln zu verfolgen. Einige davon machen bereits historische Aufzeichnungen, die sich als Grundlage für Periodenberichte und Trendberichte eignen. Man spricht hier auch von Metrics - also Messwerte. Wenn die Metrics Aussagen über die Performance liefern, ist die Bezeichnung dieses Metrics als Key-Performance Indicator (KPI) angemessen.

Ergänzende Informationen liefert das Incident Management und Problem Management (nach ITIL): Werden die diesbezüglichen Service Level eingehalten – z.B. Erreichbarkeit? Wurden die Störungen im Rahmen der vereinbarten maximalen Ausfallzeiten behoben? Wer ist verantwortlich für die Störung? Wie können ähnliche Störungen künftig vermieden werden?

Häufig fehlt eine geordnete End-to-End Prüfung auf Anwendungsebene. Für den Service-Nehmer ist es meist zweitrangig, wie hoch die Verfügbarkeit des Betriebssystems ist, wenn die Datenbank ausfällt, oder die Stabilität des Netzwerkes, wenn die Anwendung nicht verfügbar ist. Auch bei dem Verdacht auf unzureichende Verarbeitungsgeschwindigkeit empfiehlt sich der periodische Testeiner oder mehrerer Referenz-Transaktionen, die repräsentative Aussagen über die Systemleistung am Endpunkt machen kann, ohne die reguläre Nutzung unzulässig stark zu belasten.

Kreuzreferenz-Tests sichern die verursachergemäße Zuordnung, insbesondere bei verteilten Internet-Anwendungen: Ist ein allgemein verfügbarer Dienst zum Störungszeitpunkt ebenfalls langsam oder nicht verfügbar? Wenn ja, so liegt ggf. eine Internet-Störung vor, die außerhalb des Service Level Agreements liegt.

Werden alle diese Daten geordnet übernommen und gespeichert, so ist die Beurteilung, ob Regelkonformität vorliegt, eine komplexe Herausforderung. Ein Regel-Beispiel mag das erläutern:

• Pingzeit (im 5 Min Takt):
  • > 50 ms in 98% der Messwerte
  • > 200 ms in 99,8% der Messwerte
• Servicezeit: Werktags gemäß Werkskalender A, von 06:30 – 19:45
• Ausnahmen: Vereinbarte Wartungsfenster
• Berechnungsperiode: 1 Monat

In diesem Beispiel wurde mit sehr einfachen Mitteln die Netzwerk-Verfügbarkeit eines Servers definiert. Die korrekte Ermittlung zur Regelkonformität anhand einer Wertereihe aus 8928 Werten (12 / Std * 24 Std * 31 Tage unter Berücksichtigung der Zeiten, Betriebskalender und dynamisch Wartungszeiten kann zu einer großen Arbeitsbelastung führen, vor allem, wenn weitere KPIs und weitere Server und Kunden berücksichtigt werden müssen.

Die Entscheidung, ob ein feinmaschiges Netz an zu überwachenden KPIs geknüpft werden soll, ist von der Verfügbarkeit eines leicht handhabbaren Instrumentariums mit Regelprozessor abhängig. Werden je SLA z.B. weniger als 10 KPIs vereinbart, so ist eine Sicherstellung und Prüfung der Service-Qualität in der Regel kaum möglich. Dies ist auch nicht schädlich, solange der Servicenehmer mit den ‚gefühlten’ Service-Qualitäten und der dafür in Rechnung gestellten Preisen zufrieden ist. Es bleibt jedoch zu befürchten, ob der Servicegeber diese Kundenzufriedenheit auch in einer Konkurrenzsituation dauerhaft halten kann, bzw. neue Aufträge akquirieren kann.

Im Service Level Measurement wurde der Grundstein zu einem effizienten Review, Reporting und Billing gelegt, da alle Werte exakt gemessen wurden. Optional kann der Servicenehmer eine Online-Sicht auf seine Systemdaten erhalten. Dies schafft Vertrauen, Nüchternheit beim Auftraggeber und einen Wettbewerbsvorteil. In diesem Fall kann ein Reporting-Prozess stark reduziert werden: Das Generieren von Service-Reports ist automatisiert möglich.

Handlungs- und Abstimmungsbedarf besteht nur noch im Fall von Störfällen, die die vereinbarten Schwellwerte überschreiten und wenn kein Konsens über den verantwortlichen Verursacher vorliegt.

Im Fall von flexiblen Vergütungsregeln, z.B. Malus oder Bonus, sind dazu korrekte Rechnungen zu erstellen. Eine Weitergabe an CRM und / oder Debitorenbuchhaltung kann angezeigt sein. Vor allem bei kommerziellen Service-Providern mit vielen SLAs empfiehlt sich eine entsprechende Systemlösung zur Generierung der Rechnungen.

Service Level Reviews dienen auch der Bedarfsanpassung. Bei geänderten Rahmenbedingungen sind die SLAs ebenfalls anzupassen. Bei Vorhandensein konkreter Messergebnisse können die Risiken beider Vertragsparteien durch ungenaue Annahmen reduziert werden und ein präziser kosten- und leistungsgerechter Preis ermittelt werden.

Service Level Management (SLM) ist als ein Service Delivery Prozess in ITIL beschrieben. Aus der Notwendigkeit zur Serviceorientierung kommt dem SLM zunehmend eine Master-Rolle in den ITIL Prozessen zu, da dieses den Umfang aller anderen Prozesse bestimmt und überwacht.

Die gezeigten Schritte sind vielfältig: Über den Service-Katalog werden SLAs mit SL-Measurement benötigt, das die anderen Service-Prozesse einbindet. Benötigte Unterstützung bei der Einführung:

• Strategieberatung: Change of Mind Set
• Entwicklung Servicekatalog
• Framework SLA – Muster und Templates
• Tooleinsatz mit SLA-Verwaltung und –Measurement

Bei näherer Betrachtung wird deutlich, das ein geeignetes Toolset die logische Konsequenz aus einem zielorientiertem SLM-Prozess ist. Meiner Kenntnis ist ein geeignetes Tool, welches den Gesamtprozess SLM unterstützt, in einem wirtschaftlichen Rahmen nicht am Markt verfügbar.

Viele Angebote von Tools tummeln sich am Markt, die den Anspruch führen, SLA zu unterstützen. Bei den meisten sind es erweiterte Monitoring Konsolen, die auch beeindruckende Metrics und KPIs sammeln. Manche 'ready to use'-Reports beeindrucken vom Umfang und Ansatz, bleiben aber zurück, wenn es um die Abbildung komplexer Regeln geht. Wie ist denn nun ein Service-Ausfall zu bewerten, wenn es sich um ein geplantes und abgestimmtes Wartungsfenster handelt? Oder regionale Feiertage? Ein Ausfall wegen nicht abgestimmter Kundenaktivitäten? Probleme wegen Bugs im DB-System oder Third-Party-Service-Provider?

Dies zeigt die Problematik eines Service-Reporting - vor allem, wenn es sich um finanziell relevanten Erfüllungsgrade handelt. Hat ein Service-Unternehmen eine Vielzahl von Services mit einem oder mehrerer Kunden ist eine manuelle Aufbereitung jedes Incidents und deren nachvollziehbaren Zuordung hinsichtlich der SLA-Implication ohne dezidierte Unterstützung eines Regelprozessors kaum machbar.

Ein reines Reporting über KPI-Perioden dürfte hier zu kurz greifen. Auch ist die Transparenz hier nur schwer sicherzustellen. Mir sind allerdings keine Werkzeuge bekannt, die hier den Anforderungen voll entsprechen würden. Eine Analyse der verfügbaren Werkzeuge der Service-Sicherstellung kann hilfreiches und sinnvolles bringen, hinterlässt aber noch empfindliche Lücken.

Die methodisch vollständige Analyse führte zur Entwicklung eines Konzeptes iSLA. Sowohl vom iterativen Verhandlungsprozess der Service Level, mit Versionierung und Fortschreibung der Service Level, präziser und automatisierbarer Regelprüfung, bis hin zur Online-Analyse der Messergebnisse sollte mit iSLA eine Bedarfsdeckung erreichbar sein.

Gerne würde ich das Konzept mit Ihnen nach Bedarf vertiefen und umsetzen.