Service-Definition - Checkliste

Aus YaSM Service-Management-Wiki

in English


 

Service-Definition Template. YaSM Service-Management Dokument-Vorlagen und Checklisten (Beispiel).
Abb. 1: Service-Definition
(YaSM-Checkliste / Dokument-Vorlage)

Definition: Eine Service-Definition spezifiziert die Eigenschaften eines Service, insbesondere die angebotene Funktionalität und die garantierten Service-Levels. Außerdem beschreiben Service-Definitionen, wie die Ressourcen der Organisation eingesetzt werden, um einen Service zu erbringen. Ein Service kann mit Hilfe eines oder mehrerer anderer (interner oder externer) unterstützender Services erbracht werden.

Verbundener YaSM Service-Management-Prozess: Designen neuer oder geänderter Services

Weitere Checklisten und Dokument-Vorlagen: Service-Management-Checklisten

 


Eine Service-Definition enthält üblicherweise die folgenden Informationen:

Anmerkung: Für bestimmte Services brauchen einige Service-Eigenschaften eventuell nicht beschrieben zu werden (wenn zum Beispiel bei einem Service kein Kundenkontakt besteht, braucht man auch keine Beschwerden zu bearbeiten).

 

Service-Definition - Inhalte
Inhalt Beschreibung
Name / eindeutiger Identifizierer des Service
Hier sollte auch eine Versions- oder Release-Nr. angegeben werden, aus der erkenntlich wird, welche Version eines Service in der Service-Definition definiert ist. In der Regel entwickeln sich Services im Zeitverlauf, d.h. es könnte eine Service-Definition für die derzeit aktive Version eines Service geben sowie eine weitere für die nächste Version.
Verantwortlich (Service-Owner)
Der / die Service-Verantwortliche oder Service-Owner ist derjenige Mitarbeitende, der letztendlich für die Erbringung des Service gemäß Service-Definition verantwortlich ist.
Service-Typ
In diesem Abschnitt wird der Service-Typ spezifiziert (d.h. ob es sich um einen Kundenservice oder einen unterstützenden Service handelt; bei einem unterstützenden Service sollte angegeben werden, ob der Service mit Hilfe interner Ressourcen oder durch einen externen Dienstleister erbracht wird).
Service-Status
Aktueller Lebenszyklus-Status des Service (z.B. "Geplant", "In Entwicklung", "Aktiviert", "Eingestellt").
Beschreibung
Kurzbeschreibung des Service.
Kunden-Nutzen
Beschreibung, auf welche Weise der Service Nutzen für den Kunden schafft.
Funktionalität (Utility)
Beschreibung der Service-Funktionalität, beispielsweise durch Angabe der vom Service bereitgestellten Funktionen, Merkmale und Einsatzmöglichkeiten, mit denen der Service die Kunden und User beim Erreichen ihrer Ziele unterstützt.

Die vom Service gebotene Funktionalität sollte übersichtsartig in der Sprache des Service-Kunden beschrieben werden, ohne zu sehr ins Detail zu gehen. Beispiel: "Die Außendienstmitarbeiter haben uneingeschränkt, d.h. zu jedem Zeitpunkt und von jedem Ort aus, Zugriff auf die Unternehmensanwendungen xxx und yyy." Ausführlichere Spezifikationen müssen eventuell während der Service-Design-Phase erstellt werden, insbesondere, wenn für die Erbringung des Service Software-Anwendungen zu entwickeln sind.

Garantierte Service-Qualität (Warranty)
Beschreibung der angestrebten Ergebnisse des Service in Bezug auf garantierte Servicequalität bzw. Service-Levels. Dies gilt insbesondere für
  • Service-Verfügbarkeit
  • Service-Kapazität/-Performance
  • Service-Kontinuität bei kritischen Ereignissen.

Typische Informationen, die im Abschnitt über Service-Verfügbarkeit enthalten sind:

  • Service-Zeiten
    • Zeiten, zu denen der Service verfügbar sein muss
    • Zeiten, zu denen der Service vorübergehend nicht verfügbar sein kann, beispielsweise für geplante Wartungsarbeiten.
  • Verfügbarkeitsziel (z.B. "99,9 %")
  • Definition, wie die Verfügbarkeit berechnet wird (ein Service kann beispiels-weise nur an bestimmten Standorten nicht verfügbar sein, so dass genau definiert werden muss, was unter "Nicht-Verfügbarkeit" zu verstehen ist, damit bei allen Betroffenen ein einheitliches Verständnis sichergestellt ist)
  • Regeln für die Implementierung von Notfall-Changes (Beschreibung der Umstände, unter denen Notfall-Changes zulässig sind; dies ist notwendig, da die Implementierung von Notfall-Changes zu ungeplanten Service-Unterbrechungen führen kann).

Abhängig von der Art des Service sollte der Abschnitt zur Service-Kapazität/ Performance folgende Angaben enthalten:

  • erforderliche Service-Kapazität (Unter-/Obergrenzen einschließlich täglicher, wöchentlicher oder saisonaler Schwankungen), z.B. hinsichtlich
    • Anzahl und Typen von Transaktionen
    • Anzahl und Typen von Nutzern
    • Verfügbarer Speicherplatz.
  • Erforderliche Service-Performance, z.B. in Bezug auf Antwortzeiten
  • Service-Skalierbarkeit (zulässige mittel- und langfristige Zunahme der Inanspruchnahme und Auslastung des Service).

Der Abschnitt über Service-Kontinuität im Falle kritischer, disruptiver Ereignisse sollte folgende Angaben enthalten:

  • Ereignistypen, die abgedeckt sind
  • Zeitraum bis zur Einrichtung eines Interims-Betriebsmodus, einschließlich Beschreibung des Interims-Betriebsmodus und seiner Beschränkungen
  • Zeitraum bis zur Wiederherstellung des normalen Servicebetriebs.
Service-Schnittstelle
Beschreibung der Interaktion von Kunden und Usern mit dem Service. Dies kann in Textform oder in Form von Flowcharts erfolgen, die die "Customer Journey", d.h. den Weg des Kunden bei der Nutzung des Service illustrieren.

Falls es bei dem Service eine technische Schnittstelle gibt, müssen etwaige vorgeschriebene technische Standards angegeben werden.

Pflichten der Kunden / User
Dieser Abschnitt sollte etwaige vom Kunden und den Service-Nutzern zu erfüllenden Pflichten enthalten. Dazu gehören zum Beispiel Sicherheitsanwei-sungen, die bei der Nutzung des Service zu beachten sind. Gegebenenfalls sollte von dieser Stelle auf relevante Sicherheits-Richtlinien verwiesen werden.
Kunden-Support / User-Support
Wenn der Service auch Kunden- bzw. User-Support einschließt, sollten mindestens die nachfolgenden Aspekte beschrieben werden:
  • Art des gebotenen Supports (einschließlich Angabe, ob der Support per Remote-Zugriff oder vor Ort erfolgt)
  • User-Typen, die Support erhalten (z.B. welche User-Rollen, mit welcher technischen Kompetenz oder für welche Sprachen)
  • Art der Infrastruktur, für die Support bereitgestellt wird
  • Betriebszeiten.

Weiterhin sollten auch die Regeln für den Umgang mit Service-Unterbrechungen (Incidents) und Service-Aufträgen (Service Requests) definiert werden, einschließlich

  • Verfahren für die Meldung von Incidents und Einreichung von Service Requests
  • Definitionen der Prioritäten von Incidents und Service Requests (darin sollte auch definiert sein, was als schwerwiegender Incident (Major Incident) zu verstehen ist; die Definitionen sollten im Einklang mit denjenigen sein, die in den Prozessen für die Behebung von Incidents und Service Requests verwendet werden)
  • Antwort- und Lösungszeiten (je nach Priorität der Incidents bzw. Service Requests)
  • Eskalationshierarchie
  • Regeln für die Ankündigung geplanter oder ungeplanter Serviceausfälle.
Reporting und Kommunikation
In diesem Abschnitt ist festzulegen, wie die Kommunikation zwischen Kunden und Service-Provider erfolgt, beispielsweise durch Spezifizierung von:
  • Regeln für das Messen der Kundenzufriedenheit (z.B. mittels Durchführung regelmäßiger Umfragen zur Kundenzufriedenheit)
  • Intervallen für Service-Review-Besprechungen mit dem Kunden
  • Regeln für das Einreichen von Beschwerden und Lob (z.B. Angaben, die in einer formellen Beschwerde enthalten sein müssen, Regeln für die Zuweisung von Prioritäten, vereinbarte Reaktionszeiten,
  • Inhalten und Zeitabständen der Service-Berichte, die der Service Provider zu erstellen hat.
Orte, an denen der Service verfügbar ist
Falls der Service an mehreren verschiedenen Standorten angeboten wird, sollten diese Standorte hier angegeben werden.
Service-Varianten und Servicepakete
Bei Services, die in mehreren Varianten angeboten werden, sind hier die Unterschiede zwischen den Varianten aufzuführen.

Bei Services, die in Kombination mit anderen Services angeboten werden, sollten hier die verschiedenen Pakete beschrieben werden.

Preismodell
Bei kostenpflichtigen Services ist hier das Schema anzugeben, nach dem die Preise für die Service-Nutzung berechnet werden.
Abhängigkeit von unterstützenden Services
Ist der Service auf andere (unterstützende) Services angewiesen, so sollten die Abhängigkeiten hier spezifiziert werden.
Beschränkungen des Service-Umfangs
Bei manchen Services kann es hilfreich sein, explizit zu beschreiben, welche Ergebnisse oder Merkmale nicht unterstützt werden, insbesondere wenn das Serviceportfolio eine Reihe ähnlicher Services umfasst.
Sicherheit und Compliance
Dieser Abschnitt sollte einen Überblick über etwaige relevante Sicherheits- und Compliance-Aspekte enthalten und beschreiben, wie diese im Zusammenhang mit dem Service berücksichtigt werden. Zum Beispiel können folgende Fragen beantwortet werden:
  • Welche kritischen Daten werden von dem Service verarbeitet und wie sind diese geschützt?
  • Wie ist gewährleistet, dass nur berechtigte User Zugriff auf den Service haben?
  • Welche gesetzlichen Verpflichtungen oder Unternehmensrichtlinien sind relevant und wie wird Compliance gewährleistet?
Änderungen am Service
Falls der in diesem Dokument definierte Service eine geänderte oder erweiterte Version einer früheren Version ist, sollten die Unterschiede im Vergleich zur Vorgänger-Version beschrieben werden.
Verweise auf weitere relevante Informationen
Dieser Abschnitt kann Verweise auf weitere in diesem Zusammenhang relevante Informationen enthalten, zum Beispiel auf Definitionen zugehöriger Services.
Zusatz-Informationen
Anmerkungen und Zusatzinformationen.

 

Dokument-Kontroll-Informationen

Service-Definitionen sind kontrollierte Dokumente und sind deshalb mit Dokument-Kontroll-Informationen zu versehen, wie im folgenden Beispiel:

Service-Definition: Dokument-Information
Dokument-Name ...
Status ...
Speicherort ...
Verteiler-Liste ...

 

Versions-Historie
Ver­sion Ver­sions­datum Autor­/en Ände­rungen Frei­gabe-Datum Frei­ge­geben durch
... ... ... ... ... ...

 

Status-Werte und Lifecycle

(Diese Informationen beinhaltet das Lifecycle-Diagramm zur Service-Definition, das in der YaSM®-Prozesslandkarte enthalten ist.)

Zu beachten

  • Für jede Service-Definition gibt es in der Regel eine entsprechende Position im Serviceportfolio.
  • Bei Kunden-Services beschreiben die Definitionen Service-Eigenschaften, die unabhängig vom speziellen Kunden sind, der diese Services nutzt. Dies ist insbesondere dann wichtig, wenn mehrere Kunden einen bestimmten Service in Anspruch nehmen können. Service-Definitionen sind üblicherweise Anlagen zu den Kunden-Servicevereinbarungen, die es dem Service-Provider und dem Kunden erlauben, einen verbindlichen Vertrag zu schließen.
  • Bei unterstützenden Services sollten Service-Definitionen die Service-Eigenschaften so beschreiben, dass sie unabhängig davon sind, ob die Services intern oder von externen Dienstleistern erbracht werden. Dies ist insbesondere dann wichtig, wenn mehrere Parteien einen bestimmten unterstützenden Service erbringen. Service-Definitionen sind üblicherweise Anlagen zu den betrieblichen und externen Service-Vereinbarungen, die es dem Service-Provider und einem internen oder externen Dienstleister erlauben, einen verbindlichen Vertrag zu schließen.
  • Manche Organisationen verwenden zum Managen ihrer Service-Definitionen spezielle IT-Anwendungen anstelle eines Sets von Dokumenten.

 

Anmerkungen

Basiert auf: Checkliste Service-Definition zur YaSM-Prozesslandkarte.

Von:  Stefan Kempter Autor: Stefan Kempter, IT Process Maps GbR  und  Andrea Kempter Koautor: Andrea Kempter, IT Process Maps GbR, IT Process Maps.

 

Definition  › Inhalte  › Funktionalität  › Garantierte Servicequalität  › Zu beachten