Categories
Management @de

Die sieben häufigsten Fehler im SLA-Management

Die Experten für softwaregestütztes Business-Service-Management von der fusionPOINT GmbH haben die sieben häufigsten Fehler im Management von Service-Level-Agreements (SLAs) ausfindig gemacht. Ein Hauptgrund ist das sehr geringe Bewusstsein für das Thema innerhalb des Unternehmens. Denn die Schnittstellen zwischen dem Business und den IT SLAs müssen aktiv gesteuert und kontrolliert werden.

Fehler Nr. 1

Anbieter und Kunde vereinbaren keine SLAs.
Auf beiden Seiten herrschen in diesem Fall nur vage Vorstellungen darüber, welche Leistung eingekauft und welche geliefert wird. Da der Kunde ohnehin 100 Prozent möchte und der Lieferant nur das liefern kann, was seine Infrastruktur hergibt, sind Unstimmigkeiten vorprogrammiert, sobald der Kunde mit einer Leistung unzufrieden ist.

Fehler Nr. 2

Es gibt SLAs, aber diese sind beim Kunden und beim Anbieter nicht ausreichend kommuniziert.
Trotz schriftlicher Vereinbarungen sind die Details der zu erbringenden Leistung den betroffenen Personen häufig nicht bekannt oder wurden im Vorfeld nicht mit ihnen abgestimmt. In der Konsequenz ist es dann nur Zufall, wenn das geleistet wird, was der Kunde erwartet.

Fehler Nr. 3

SLAs enthalten schwammige Begriffe wie maximale Kundenzufriedenheit oder höchste Verfügbarkeit.
Kein Unternehmen wird jedoch Positionen wie „1 mal maximale Kundenzufriedenheit“ auf einem Lieferschein aufführen. SLAs müssen für beide Seiten zweifelsfrei messbar sein. In einem Reporting lässt sich dann automatisiert dokumentieren, wie die Leistungserbringung konkret aussah. Schwachstellen in der Leistungserbringung können so schnell aufgespürt und beseitigt werden.

Fehler Nr. 4

Es gibt SLAs mit messbaren Werten – aber niemand hält sich dran.
Häufig ist sich der Kunde trotz schriftlich fixierter Werten nicht bewusst, dass er keine 100 Prozent abgeschlossen hat oder nicht bereit, eine Mehrleistung zu honorieren. Umgekehrt ist der Lieferant nicht bereit, ein Servicedesign zur Erreichung der spezifischen SLAs zu machen und hierfür zu investieren. Auch hier muss die vereinbarte Leistung in beiden Unternehmen klar und transparent kommuniziert werden.

Fehler Nr. 5

SLAs werden von der Leistungsfähigkeit der IT nach oben zusammengebaut.
Hier stimmt der Ansatz nicht. Ein Business-SLA muss immer vom Geschäftsprozess des Kunden top-down abgeleitet werden. Es wird oft nicht gefragt „Was wird gebraucht?“, sondern „Was kann geleistet werden?“ Will ein Dienstleister seine Kunden zufrieden stellen, muss er die Kundenorientierung in den Vordergrund stellen.

Fehler Nr. 6

Das SLA-Management beim Anbieter erfordert zu viele manuelle Tätigkeiten.
Was nicht automatisiert ablaufen kann, benötigt zu viel Zeit und ist fehleranfällig. Das Reporting zum Kunden ist stets nachträglich und somit nur als Vergangenheitsbewältigung möglich. Eine aktive Steuerung der SLAs ist wichtig, um die eigene Leistung auf einem hohen Niveau zu halten und Verlässlichkeit zu demonstrieren. Auch die Risikominimierung und die Vermeidung von Pönalen wird hiermit gesteuert.

Fehler Nr. 7

Leistung wird nicht kundenbezogen kontrolliert, sondern nur bezogen auf die internen Leistungseinheiten.
Mit diesem Ansatz kann einiges schieflaufen. So kann es beispielsweise vorkommen, dass die geforderte Verfügbarkeit einer Leistungseinheit von x Prozent über alle Kunden eingehalten wurde und damit im grünen Bereich ist. Sind die Ausfälle aber ungleichmäßig verteilt, schreiben manche Kunden bereits die Rechnungen über Pönalen. Wichtig ist daher, auf SLA-Ebene zu managen und für jeden Kunden die spezifizierten Leistungen sicher zu stellen.


Bildquelle: http://auditagency.com.ua

Categories
Analysen

Die Herausforderungen des Cloud Computing: Service Level Agreements

Mit der Adaption von Cloud Computing Technologien und Services stehen Unternehmen Herausforderungen gegenüber, die es zu bewältigen gilt. Zum einen müssen organisatorische Voraussetzungen geschaffen und Aufklärungsarbeit innerhalb des Unternehmens geleistet werden, um die Akzeptanz und das Verständnis zu stärken. Zum anderen treffen aber auch viele “Widerstände” von außen auf das Unternehmen. Das sind neben Fragen bzgl. der Sicherheit und des Datenschutz ebenfalls Themen zur Verfügbarkeit und Performanz des ausgewählten Cloud Service sowie dessen Integrationsfähigkeit in die bereits bestehende IT-Infrastruktur und die nahtlose Unterstützung der vorhandenen Geschäftsprozesse. Und wie auch schon aus den klassischen Sourcingmöglichkeiten bekannt, besteht auch im Cloud Computing die Angst, in die Abhängigkeit eines einzigen Anbieters zu verfallen. So müssen auch hier die Interoperabilität und die Schnittstellen des Anbieters sowie ein Vergleich zu anderen Anbieteren vorgenommen werden.

Ist die Entscheidung für die Nutzung des Cloud Computing gefallen, ist es für Unternehmen zunächst an der Zeit, eine Ist-Analyse der bestehenden IT-Infrastruktur und Systeme vorzunehmen, um auf Basis dieser zu planen, welche Cloud Services adaptiert werden sollen. Hier kann bspw. eine Kosten-/ Nutzen-Analyse weiterhelfen, bei der auch eine Risikobewertung nicht fehlen sollte. Um erste Erfahrungen auf dem Cloud Computing Gebiet zu sammeln, sollte ein Pilotprojekt initiiert werden, welches auf Grund des Cloud Computing Konzepts schnell und kostengünstig gestartet werden kann. Dieses sollte einem Gesamtverantwortlichen “Cloud” untergeordnert sein, der als zentrale Stelle innerhalb der Organisation für die Adaption und Beratung der einzelnen Abteilungen für dieses Thema zuständig ist. Mit den gesammelten Erfahrungen können dann weitere Projekte gestartet werden und die Adaption unterschiedlicher Cloud Services sukzessive vorgenommen werden.

Service Level Agreements

In einem Service Level Agreement (SLA) werden die von einem Anbieter zu erbringenden Leistungen und Abrechnungen fest vereinbart, wodurch die Dienstgüte zwischen dem Anbieter und seinem Kunden vertraglich und rechtsbindend festgelegt wird. Dabei wird der gemeinsame Vertrag aus der Sicht des Kunden beschrieben und der Anbieter hält im Gegenzug die Eigenschaften, den Umfang und die Qualität seiner Leistungen in einem Katalog fest.

Neben den Verfügbarkeiten der Leistungen sind in einem SLA ebenfalls die Ressourcenzuteilungen, die Verfügbarkeitsquote, die Reaktions- und Wartungszeiten sowie Vereinbarungen über Sicherheiten, Priorisierungen, Garantien und Abrechnungsmodelle enthalten. Des Weiteren werden ebenfalls Regelungen bzgl. des Supports und Fehlerbehebungen über bestimmte Fehlerklassen definiert und Reaktions- und Problemlösungszeiten festgelegt. Die entsprechenden Vereinbarungen werden jeweils über einen so genannten Key Performance Indikator (KPI) festgehalten und gemessen.

Darüber hinaus werden in einem SLA Regelungen festgehalten, die bei einem Verstoß des Anbieters gegen die zugesagten Leistungen, Rechtsfolgen nach sich ziehen. Bei der Nichteinhaltung der Verfügbarkeit wird hier z.B. das Malussystem eingesetzt. Aber auch die Pauschalisierung von Schadensersatzregelungen und die Voraussetzungen für eine beiderseitige Kündigung werden hier festgehalten.

Heinz Schick hat dazu einen Katalog mit zwanzig Eckpunkten erstellt, auf die bei der Erstellung eines SLAs geachtet werden sollte.

  1. Systembeschreibung: Detaillierte Anforderungsbeschreibung eines Services durch den Nutzer.
  2. Gültigkeitszeitraum für die SLAs: Festgelegter Zeitraum, in dem die Leistungen erfüllt werden müssen.
  3. Hauptrollen in dem SLA: Zuständigkeitsverteilung, die festlegt, wer für welche Aufgabe verantwortlich ist.
  4. Nutzerzufriedenheit: Spiegelt die Erwartung des eigentlichen Anwenders wieder.
  5. Verfügbarkeit: Legt Zeiträume fest, in denen der Anwender auf den Service uneingeschränkt zugreifen kann.
  6. Geplante Ausfallzeiten: Festgelegte Zeiträume, in denen Wartungen und Notfallübungen vorgenommen werden.
  7. Serviceschnittstellen: Wechselwirkungen zwischen den unterschiedlichen IT-Diensten werden untersucht und detailliert beschrieben.
  8. Zuverlässigkeit: Misst, wie häufig ein System ausfällt und wie lange benötigt wird, bis der Dienst nach der vereinbarten Dienstgüte wiederhergestellt ist.
  9. Leistungserwartung: Beschreibt z.B. die erwarteten Antwortzeiten und Durchsatzraten.
  10. Problem-Reporting und -lösung: Der Betrieb eines Services muss festgehalten werden. Dazu muss zu jedem KPI ein Messverfahren fest definiert und der Umfang des Reporting festgelegt werden.
  11. Benachrichtigungs- und Eskalationswege: Die Eskalationswege im Fehlerfall müssen festgelegt werden. Zudem sollte ein Anbieter bereits frühzeitig auf Probleme hinweisen.
  12. Wartung: Die Systeme müssen regelmäßigen Wartungszyklen unterzogen werden.
  13. Wachstum und Veränderungen: Der Anbieter muss auf Grund seiner eigenen Planungssicherheit von dem Kunden über das erwartete zukünftige Wachstum informiert werden.
  14. Backup und Wiederherstellung: Dabei gilt es Backup- und Recovery Prozesse einzuhalten und über entsprechend ausgebildetes Ersatzpersonal zu verfügen.
  15. Archivierung und Datenspeicherung: Die gesetzlichen und betrieblichen Archivierungsregeln müssen erfüllt werden. Des Weiteren muss ein Archivierungskonzept für die Speichersysteme vorhanden sein.
  16. Business-Recovery und -Continuity: Beschreibt einen Maßnahmenkatalog und eine Notfallplanung im Fehlerfall inkl. der Auswirkung auf die Geschäftsprozesse und einer Risikobewertung.
  17. Security: Ganzheitliche Maßnahmen und Konzepte zum Thema Sicherheit für einen Service.
  18. Regelmäßige Lagebesprechung: Intensive Kommunikation zwischen dem Kunden und dem Anbieter. Dazu gehören ebenfalls die monatliche Überprüfung der KPIs und Diskussionen über weitere Anforderungen und Verbesserungsvorschläge.
  19. Unterschrift: Der Anbieter übernimmt die Verantwortung für die bei ihm gehosteten und von ihm bezogenen Services.
  20. Kontinuierliche Administration: Permanente Kontrolle durch den Kunden. Dazu gehören das Überprüfen der Berichte und Abrechnungen.

Dienstleistungen und Produkte können kostengünstig angeboten werden, wenn sie standardisiert werden. Diesem Konzept bedienen sich auch Cloud Computing Anbieter. Neben ihren Infrastrukturen, Services etc. sind sie auch dazu übergegangen Standard-SLAs anzubieten, die für jeden Kunden gleichermaßen gelten. Auf Nachfrage, je nach Unternehmensgröße und gegen Aufpreis können die SLAs jedoch nachverhandelt und den Unternehmensbedürfnissen angepasst werden.

Daher gilt es für ein Unternehmen, eine sorgfältige Leistungsbeschreibung auf Basis des genutzten Services vorzunehmen. Hier kann sich das Unternehmen zunächst an die unterschiedlichen Servicearten des Cloud Computing, Infrastrucuture-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS) orientieren, um zu bestimmen welche Dienstgüte für welchen genutzten Service benötigt wird.

Aus diesem Grund ist und kann kein SLA gleich sein. Das betrifft auch die Standard SLAs eines jeweiligen Anbieters. Nutzt ein Unternehmen bspw. eine ERP Anwendung auf Basis von SaaS, interessiert hier u.a. die Verfügbarkeit und eine schnelle Antwortzeit der Anwendung. Die Verfügbarkeit der darunter liegenden virtualisierten Umgebung, auf der sich die Anwendung befindet, ist nicht von Interesse. Wird hingegen Infrastruktur auf Basis von IaaS genutzt, ist die Verfügbarkeit eines virtuellen Servers von besonderer Bedeutung. Ebenfalls die Verfügbarkeit aber vor allem die Zuverlässigkeit bei der Nutzung eines Cloud Storage Service muss betrachtet werden. Die Anforderungen an die jeweiligen Cloud Services unterscheiden sich also grundlegend in ihren Eigenschaften und ihrer Abstraktionsebene.

Die folgenden grundlegenden Bereiche, sollte ein Cloud Computing SLA beinhalten:

  • Überblick: Nennt und beschreibt die Parteien (Kunde, Anbieter), die Gegenstand des SLA sind und erläutert grob den Inhalt und die vereinbarten Services, die bezogen werden sollen.
  • Umfang der Arbeiten: Eine ausführlichere Übersicht über die Services, die dem Kunden bereitgestellt werden.
  • Leistungsmessungen: Definition von Metriken, die regelmäßig gemäß den Vereinbarungen überprüft werden müssen. Dazu gehören z.B. die Betriebszeiten, der Durchsatz und die Anzahl der Benutzer, die parallel versorgt werden können. An dieser Stelle gilt es für das Unternehmen sehr genau die Metriken und Messpunkte festzulegen, die den Unternehmensanforderungen im Detail gerecht werden.
  • Vorgehen im Problemfall: Vom Unternehmen muss fest vorgegeben werden, wie sich der Anbieter im Fehlerfall verhält. Also in welchem Zeitraum er den Fehler dem Unternehmen mitteilt und wie er vorgeht, um das Problem zu lösen.
  • Gebührenstruktur: Legt im Detail die Preise fest, die der Anbieter dem Unternehmen für eine entsprechende Leistung abrechnet.
  • Pflichten des Kunden: Legt fest, wie und mit welchen Umfang das Unternehmen den Anbieter mit Informationen versorgt.
  • Zusicherungen/ Garantien: Der Anbieter muss dem Unternehmen gegenüber garantieren und erklären, wie er sicherstellen wird, die Vereinbarungen einzuhalten.
  • Security: Beschreibt die Sicherheitsfunktionen der Services inkl. den Maßnahmen, die vorgenommen werden, wenn es zu einer Sicherheitsverletzung kommt.
  • Compliance: Viele Unternehmen müssen branchenspezifische und regulatorische Anforderungen erfüllen, wie Informationen ausgetauscht werden müssen und wie dieses im Detail sichergestellt wird. Der Anbieter muss dem Unternehmen gegenüber versichern, dass er sich an diese Regelungen ebenso exakt halten wird und einen Notfallplan vorlegen, was vorgenommen wird, wenn es zu einer Außnahmesituation kommt.
    Vertrauliche Informationen und geistiges Eigentum: Es muss im Detail festgehalten werden, wem welches geistige Eigentum obliegt. Ebenso ist der Umgang mit vertraulichen Informationen für beide Seiten zu klären.
  • Haftungsschutz: In einer Cloud befinden sich die Daten eines Unternehmens über viele Standorte hinweg verteilt und werden ggf. von mehreren anderen Unternehmen weiterverarbeitet. Daher muss an dieser Stelle der Haftungsschutz eindeutig festgelegt werden. Dazu gehört neben dem Spezifizieren der Standorte, an denen die Daten des Unternehmens möglicherweise verarbeitet werden könnten ebenso das Sicherstellen, dass jedes weitere Unternehmen, das an dem Verarbeitungsprozess der Daten beteiligt ist, ebenfalls compliant zu den regulatorischen Anforderungen ist.
  • Regelmäßige Überprüfung: Um sicherzustellen, dass unvorhergesehene Probleme noch während der Vertragslaufzeit aufgedeckt werden, müssen feste Termine für regelmäßige Überprüfungen festgelegt werden.
  • Kündigung: Wie es in jedem Vertrag üblich ist, muss auch in dem SLA festgehalten werden, wie der Vertrag von beiden Seiten gekündigt werden kann. Dazu gehören ebenfalls die Schritte nach der Kündigung inkl. einer Beschreibung, wie die Daten in eine neue Umgebung übertragen werden, zusammen mit einem dazugehörigen Zeitplan.
  • Umsetzung: Es muss ein Zeitplan erstellt werden, auf den sich beide Parteien geeinigt haben. Darin wird festgehalten, wann die Übertragung zu dem neuen Service beginnt, der Zeitpunkt, zu dem der neue Service starten soll sowie die wichtigsten Meilensteine und Ergebnisse für beide Seiten.

Ein SLA ist sehr speziell und sollte daher nur für eine bestimmte Art eines Cloud Computing Services gelten. So liegt bspw. bei der Nutzung einer SaaS Applikation das Bereitstellen der Internetverbindung im Verantwortungsbereich des Unternehmens. Allerdings ist speziell die Leistung wie der Durchsatz und die Antwortzeiten sowie die Verfügbarkeit bei der Nutzung einer SaaS Applikation sehr kritisch. Eine performante und verfügbare Internetverbindung des Kunden kann der Cloud Computing Anbieter jedoch nicht garantieren. Hier muss der Kunde mit seinem Netzanbieter über ein separates SLA eine entsprechende Vereinbarung festlegen und Übergabepunkte definieren.

Categories
News

openQRM ab sofort mit Service Level Agreements & Professional Services

Die openQRM Enterprise aus Köln bietet ihren Kunden und Nutzern von openQRM per sofort professionelle Service Level Agreements (SLA) auf Basis der Level Basic, Standard und Premium.

Durch die Einführung dieser SLAs setzt sich die openQRM Enterprise damit selbst das Ziel, hochqualitativen Support für die Cloud Computing Plattform openQRM zu liefern, wodurch Kunden direkten Kontakt mit dem openQRM Enterprise Support-Team herstellen können und weiterhin Zugriff auf einen Bug-Tracker erhalten.

Abgerundet werden die SLAs mit Professional Services, mit denen eine direkte Unterstützung bei der Einführung und der Lösung von Problemen mit openQRM geboten wird. Dazu gehören ebenfalls die regelmäßige Unterstützung durch das openQRM Enterprise Support-Team, um den einwandfreien Betrieb und die Wartung (Updates) von openQRM zu gewährleisten und die Entwicklung spezieller und spezifischer Funktionen und Anforderungen durch den Kunden.

Service Level Agreements

  • Vollständiges Zugriff auf das openQRM Enterprise Bug-Tracking System
  • Updates durch die openQRM Enterprise
  • Zertifizierung der openQRM Umgebung durch die openQRM Enterprise
  • openQRM Enterprise Newsletter
  • Monatliche Berichte inkl. Besprechung
  • Direkter Kontakt zum openQRM Enterprise Support-Team

Professional Services

  • Unterstützung der openQRM Umgebung auf Basis der eigenen Anforderungen
  • Automatische openQRM Updates
  • Entwicklung neuer Funktionen für openQRM – auch auf Basis eigener Anforderungen
  • Zertifizierung der openQRM Umgebung durch die openQRM Enterprise
  • openQRM Enterprise Newsletter

openQRM Updates ab sofort durch die openQRM Enterprise

Weiterhin wird die openQRM Enterprise die aktive Entwicklung von openQRM übernehmen, wodurch die Qualität und Innovation von openQRM weiter verbessert werden soll und wichtige Updates zeitnah veröffentlicht werden können.

Wichtig hierbei ist, dass die openQRM Enterprise alle Änderungen und Releases weiterhin auf dem Open-Source Repository von SourceForge.net zur Verfügung stellen wird, so dass jeder openQRM weiter frei nutzen kann.

Quelle

  • openQRM
  • openQRM Enterprise