LP4: Betreiben der Services

 

Prozessname: Betreiben der Services - Teil von: Service-Lifecycle-Prozesse

Vorhergehender Prozess: Erstellen neuer oder geänderter Services

Nächster Prozess: Verbessern der Services

 

Prozess-Beschreibung

Der Service-Operation-Prozess in YaSM (Abb. 1) stellt sicher, dass die Services effektiv und effizient sowie in Übereinstimmung mit den vertraglichen Zusagen erbracht werden. Dies beinhaltet die Bearbeitung von Serviceaufträgen, die Lösung von Incidents und Problemen sowie die Erledigung routinemäßiger Betriebsaufgaben durch den Prozess.

 

Abb. 1: 'Betreiben der Services'
Der YaSM Service-Operation-Prozess ('LP4').

Die erreichte Servicequalität wird regelmäßig gemessen. Die entsprechenden Service-Qualitätsberichte stellen einen wichtigen Input für den Serviceverbesserungs-Prozess dar.

Abbildung 1 verdeutlicht auch, wie drei bestimmte Teilprozesse des Servicebetriebs (Überwachen der Services, Lösen von Incidents und Service Requests, Lösen von Problemen) zusammenwirken, um existierende oder potenzielle Incidents sowie deren zugrundeliegenden Ursachen (Problems) aufzufinden und zu lösen.

 

Kompatibilität: Der YaSM Servicebetriebs-Prozess ist kompatibel mit ISO 20000, dem internationalen Service-Management-Standard (vgl. ISO/IEC 20000-1:2018, Abschnitte 8.3, 8.4, 8.7 und 9) und eignet sich zur Umsetzung mehrerer ITIL 4-Praktiken, wie 'Monitoring and Event Management', 'ITIL 4 Incident Management' und 'ITIL 4 Problem Management'.

Sub-Prozesse

Der Service-Operation-Prozess in YaSM beinhaltet die folgenden Sub-Prozesse:

LP4.1: Unterstützen des Service-Betriebs

Prozessziel: Bereitstellen von Unterstützung für den Service-Betrieb, z.B. durch Sicherstellen der notwendigen Ressourcen für den Service-Betrieb sowie durch Konfigurieren und Verwalten der unterstützenden Systeme, die für den Betrieb der Services erforderlich sind.

LP4.2: Bereitstellen von Leitlinien für den Service-Betrieb

Prozessziel: Bereitstellen von Instruktionen für die vom Betriebspersonal auszuführenden Tätigkeiten. Dies schließt z.B. die Erstellung von detaillierten Richtlinien für regelmäßige Wartungsaufgaben mit ein.

LP4.3: Überwachen der Services

Prozessziel: Sicherstellen, dass die Service-Komponenten und die Service-Auslastung laufend überwacht werden, und zeitnahes Reagieren, falls Unregelmäßigkeiten festgestellt werden.

LP4.4: Erstellen von Service-Qualitätsberichten

Prozessziel: Regelmäßiges Messen der erreichten Service-Qualität und Identifizieren von Bereichen, in denen die Service-Qualität verbessert werden muss.

LP4.5: Durchführen laufender Betriebsaufgaben

Prozessziel: Durchführen der routinemäßigen betrieblichen Aufgaben, die erforderlich sind, um die vereinbarte Service-Qualität dauerhaft zu liefern.

LP4.6: Lösen von Incidents und Service Requests

Prozessziel: Bearbeiten von Service Incidents (Meldungen vermuteter oder tatsächlicher Service-Unterbrechungen) oder Service Requests (Serviceaufträgen). Im Falle von Incidents ist das primäre Ziel des Prozesses, den Service für den Anwender so schnell wie möglich wieder herzustellen. In manchen Fällen wird dazu ein Workaround eingesetzt, falls die zugrundliegende Ursache nicht unmittelbar identifiziert und/ oder behoben werden kann.

LP4.7: Lösen von Problemen

Prozessziel: Die Verwaltung aller Probleme über ihren gesamten Lebenszyklus, wobei ein Problem die einem oder mehreren (potentiellen) Incidents zugrundeliegende Ursache ist. Das primäre Ziel dieses Prozesses ist, dem Auftreten von Service Incidents vorzubeugen und die Auswirkungen von Incidents, die nicht verhindert werden können, minimal zu halten.

Prozess-Outputs

Die folgenden Dokumente und Records werden vom Servicebetriebs-Prozess erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.

Änderungs-Vorschläge zu Informationen zur Selbsthilfe

Ein Vorschlag zur Aktualisierung der Informationen für Anwender zur Selbsthilfe. Diese werden z.B. auf den Support-Seiten des Service-Providers im Intranet zur Verfügung gestellt.

Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen

Eine Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen zur Service-Provider-Organisation; diese wird z.B. bei einer Service-Implementierung erteilt, wenn neue oder geänderte Kompetenzen und/ oder zusätzliche Personalressourcen für einen neuen Service benötigt werden.

Anwender-Handbuch

Eine Dokumentation für Endanwender, die beschreibt, wie eine Anwendung oder ein System zu bedienen ist.

Beschaffungs-Anforderung

Eine Anforderung zur Beschaffung von Gütern von einem externen Lieferanten. Beschaffungs-Anforderungen werden typischerweise an den Supplier-Manager gerichtet, wenn z.B. Anwendungen, Systeme oder andere Infrastruktur-Komponenten für die Erstellung eines neuen Service notwendig sind, oder wenn Standard-Infrastruktur-Komponenten oder Verbrauchsgüter für den Service-Betrieb benötigt werden.

Beschwerde-Record

Ein Record, der alle Einzelheiten einer Beschwerde von Kundenseite enthält, einschließlich der durchgeführten Aktivitäten zur Behandlung der Beschwerde. [*]

Budget-Anforderung

Eine Budget-Anforderung wird typischerweise erstellt, um finanzielle Mittel für das Erstellen, Verbessern oder Betreiben eines Service oder Prozesses zu erhalten. Eine genehmigte Budget-Anforderung bedeutet, dass die finanziellen Ressourcen vom Finanz-Manager zugeteilt wurden. [*]

Change Record

In einem Change Record sind alle Einzelheiten eines Changes enthalten; er dokumentiert somit den Lebenszyklus eines einzelnen Changes. Zu Beginn beschreibt ein Change Record einen Change-Antrag (Request for Change, RFC), der vor der Implementierung des Changes zu bewerten und freizugeben ist. Weitere Informationen werden im Verlauf des Changes hinzugefügt. [*]

CI Record

Konfigurations-Information wird für alle Konfigurations-Elemente (Configuration Items, CIs) in CI Records gepflegt, die unter der Kontrolle des Konfigurations-Managers stehen. In diesem Zusammenhang gibt es unterschiedliche Typen von CIs: Anwendungen, Systeme und andere Infrastruktur-Komponenten werden als CIs behandelt, aber oft auch Services, Richtlinien, Projektdokumente, Mitarbeiter, Lieferanten usw. Konfigurations-Informationen sind im Konfigurations-Management-System (Configuration Management System, CMS) verzeichnet. [*]

Fragebogen zur Kundenumfrage

Eine Kundenumfrage setzt typischerweise Fragebögen ein, mit denen Einblick in die generelle Zufriedenheit der Kunden und zu speziellen (Aspekten von) Services aus Kundensicht gewonnen werden sollen. In vielen Fällen werden Antworten auf einer Skala gegeben, wie z.B. '1: Sehr unzufrieden', ... , '10: Sehr zufrieden'. [*]

Geplante Service-Unterbrechungen

Im Dokument bzw. in der Datenbank der geplanten Serviceunterbrechungen sind erwartete bzw. geplante Abweichungen von der normalen Service-Verfügbarkeit aufgeführt, wie z.B. Unterbrechungen auf Grund von Wartungsarbeiten oder Implementierungen von Changes. [*]

Incident- bzw. Request-Status-Information

Eine Nachricht mit Informationen zum aktuellen Stand der Bearbeitung eines Incidents oder Serviceauftrags an einen Anwender, der zuvor einen Incident oder Serviceauftrag gemeldet hat. Statusinformationen werden Anwendern typischerweise an verschiedenen Punkten im Lebenszyklus eines Incidents bzw. Serviceauftrags gesendet. Falls die Lösungszeit den vereinbarten Zeitrahmen überschreitet oder zu überschreiten droht, sind Status-Benachrichtigungen besonders wichtig, um den Anwender auf dem Laufenden zu halten.

Incident Record

Ein Datensatz mit allen Angaben zu einem Service Incident, in dem der Verlauf des Incidents von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Service Incident ist definiert als ungeplante Unterbrechung oder Qualitätsminderung eines Service. Auch ein Ereignis, das in der Zukunft einen Service beeinträchtigen könnte, wird als Incident behandelt (z.B. der Ausfall einer Festplatte in einem Satz gespiegelter Festplatten). Siehe auch: Checkliste 'Incident Record'. [*]

Incident-Modell

Incident-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Incident-Typ. Incident-Modelle dienen dem Zweck, wiederkehrende Incidents effektiv und effizient zu bearbeiten. [*]

Informationen zum Change-Status

Aktuelle Status-Informationen zur Implementierung eines Changes. Diese Informationen werden dem Change-Manager von den verschiedenen Prozessen zur Verfügung gestellt, die freigegebene Changes implementieren. Der Change-Manager wird so in die Lage versetzt, die Change Records und die Change-Planung aktuell zu halten.

Infos für Anwender zur Selbsthilfe

Informationen für Anwender zur Selbsthilfe. Diese werden z.B. auf den Support-Seiten des Service-Providers im Intranet zur Verfügung gestellt.

Proaktive Anwender-Information

Eine Meldung über bestehende oder potentielle Service-Unterbrechungen an die Anwender oder Kunden, damit die Anwender sich auf die zeitweilige Unterbrechung des Service einstellen können.

Problem Record

Ein Datensatz mit allen Angaben zu einem Problem, in dem der Verlauf des Problems von der Ersterfassung bis zur Schließung dokumentiert ist. Ein Problem ist definiert als die zugrundeliegende Ursache eines oder mehrerer (potentieller) Incidents, auch wenn die Ursache bei der Erstellung eines Problem Records oft noch nicht bekannt ist. In vielen Fällen wird eine Umgehungslösung (Workaround) für ein Problem bereitgestellt, solange eine vollständige Lösung noch nicht verfügbar ist. Siehe auch: Checkliste 'Problem Record'. [*]

Protokoll der Service-Zugriffe

Das Protokoll der Service-Zugriffe (Service Access Log) enthält Datensätze, die von den Zugriffs-Kontrollsystemen gesammelt werden, wenn Benutzer Zugang zu bestimmten Services anfordern. Diese Daten werden z.B. vom Sicherheits-Manager als Grundlage für die Verbesserung von Sicherheits-Mechanismen und -Vorkehrungen genutzt.

Protokoll der System-Ereignisse

Das Protokoll der System-Ereignisse (System Event Log) enthält Datensätze, die von den Überwachungs-Systemen erzeugt werden, die kontinuierlich den Zustand der technischen Infrastruktur prüfen. Ereignis-Records (Event Records) werden z.B. genutzt, um aktuelle Service-Unterbrechungen zu detektieren, die unmittelbares Handeln erfordern. Mit Ereignis-Records werden auch Situationen identifiziert, die präventive Maßnahmen erfordern, um die Service-Qualität aufrecht zu halten (z.B. drohende Kapazitäts-Engpässe).

Service Request Record

Ein Record, der alle Details eines Service Requests (Serviceauftrags) aufzeichnet. Service Requests sind formale Anfragen eines Kunden bzw. Anwenders im Rahmen bestehender Service-Vereinbarungen - z.B. nach Informationen, Beratung, Zurücksetzen eines Passworts, oder Installation einer Workstation für einen neuen Anwender. [*]

Service-Betriebshandbuch

Ein Service-Betriebshandbuch spezifiziert die Aktivitäten, die für den Betrieb eines Service und der darunter liegenden Infrastruktur erforderlich sind. Die Informationen im Service-Betriebshandbuch sollen die im Tagesgeschäft anfallenden Aufgaben auf eine für das Betriebspersonal nützliche Weise beschreiben. Einige Anweisungen für den Betrieb bestimmter Anwendungen, Systeme oder Infrastruktur-Komponenten können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. [*]

Service-Qualitäts-Bericht

Ein Service-Qualitätsbericht stellt dar, inwieweit der Service-Provider in der Lage ist, die zugesagte Service-Qualität zu liefern. Insbesondere vergleicht der Bericht die erreichten Service-Levels mit den vereinbarten Zielwerten, wie in den Servicedefinitionen festgelegt. Service-Qualitätsberichte stellen auch etwaige Verletzungen vertraglicher Verpflichtungen und außergewöhnliche Ereignisse heraus. Siehe auch: Checkliste 'Service-Qualitäts-Bericht'. [*]

Service-Request-Modell

Service-Request-Modelle enthalten die vordefinierten Schritte zum Umgang mit einem bestimmten Typ von Serviceauftrag. Request-Modelle dienen dem Zweck, häufig wiederkehrende Serviceaufträge effektiv und effizient zu bearbeiten. [*]

Statistik zur Service-Inanspruchnahme

Statistische Daten zur Inanspruchnahme der Services durch Kunden bzw. Benutzer, als Basis für die Erstellung von Kunden-Rechnungen.

Support-Anfrage

Eine Anforderung zur Unterstützung bei der Behebung eines Incidents oder Problems. Eine solche Anforderung wird üblicherweise vom Incident- oder Problem-Manager gestellt, wenn weitere technische Expertise für die Behebung von Incidents oder Problems erforderlich ist.

Technisches Handbuch

Ein Dokument, das die Verfahren zu Betrieb und Wartung eines Systems oder anderer Infrastruktur-Komponente beschreibt. Technische Handbücher werden oft von externen Produktlieferanten oder internen Entwicklungsteams bereitgestellt.

Testprotokoll

Ein Testprotokoll stellt einen detaillierten Bericht zu Testaktivitäten bereit. Ein solches Protokoll wird z.B. während der Tests neuer oder geänderter Service-Komponenten erstellt, oder während der Tests von Sicherheits- oder Service-Kontinuitäts-Mechanismen. [*]

Testskript

Ein Testskript bzw. Testdrehbuch spezifiziert einen Satz von Testfällen einschließlich der erwarteten Ergebnisse. Die Art der Testfälle hängt davon ab, was zu testen ist. [*]

Vorschlag zur Verbesserung der Kontinuitäts-Vorkehrungen

Ein Vorschlag zur Verbesserung der Service-Sicherheit. Solche Vorschläge können an jeder Stelle innerhalb der Organisation entstehen.

Vorschlag zur Prozess-Änderung

Ein Vorschlag zur Änderung eines oder mehrerer Service-Management-Prozesse. Vorschläge für Prozess-Änderungen oder -Verbesserungen können an jeder Stelle innerhalb der Organisation entstehen.

Vorschlag zur Service-Änderung

Ein Vorschlag zur Änderung eines Service, z.B. zur Verbesserung der Qualität oder Wirtschaftlichkeit des Services. Solche Vorschläge können an jeder Stelle innerhalb oder außerhalb der Service-Provider-Organisation entstehen.

Wiederherstellungs-Plan

Wiederherstellungspläne (Recovery-Pläne) enthalten genaue Anweisungen zu den Maßnahmen, mit denen bestimmte Services und/ oder Systeme nach einem Ausfall wieder hergestellt werden können, was in vielen Fällen auch die Wiederherstellung von Daten zu einem definierten, konsistenten Stand mit einschließt. [*]

 

---

Anmerkungen:

[*] "YaSM-Datenobjekte" sind Dokumente und Records, für die YaSM detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe Dokumentvorlage 'Service-Qualitäts-Bericht' sowie weitere Beispiele), die die typischen Inhalte beschreibt, und ein Lifecycle-Diagramm, das darstellt, wie sich der Zustand des Objekts ändert, während es von verschiedenen YaSM-Prozessen erstellt, geändert, gelesen und archiviert wird (siehe Beispiel).

"Andere Objekte" sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.

Prozess-Kennzahlen

Prozesskennzahlen werden benötigt, wenn gemessen werden soll, ob die Service-Management-Prozesse "zufriedenstellend" laufen.

Vorschläge zu geeigneten Prozess-Kennzahlen entnehmen Sie der Liste von Kennzahlen zum Service-Operations-Prozess.

Rollen und Verantwortlichkeiten

Prozess-Owner: Ein Betriebs-Manager (Operations-Manager) trägt die gesamtheitliche Verantwortung für den Betrieb eines Service. Diese Rolle stellt unter anderem sicher, dass alle operativen Routine-Aufgaben zeitgerecht und zuverlässig ausgeführt werden.

 

Verantwortlichkeits-Matrix 'LP4: Betreiben der Services'

YaSM-Rolle / Sub-Prozess		Betriebs-Mgr.	Oper.	Serv.-Owner	Techn.- Fach­exp.
LP4.1	Unterstützen des Service-Betriebs	AR	R	R	R
LP4.2	Bereitstellen von Leit­linien für den Service-Betrieb	AR	-	R	R
LP4.3	Überwachen der Services	A	R	-	-
LP4.4	Erstellen von Service-Qualitäts­berichten	A	R	R	-
LP4.5	Durchführen laufender Betriebs­aufgaben	A	R	-	-
LP4.6	Lösen von Incidents und Service Requests	siehe RACI-Matrix "LP4.6: Lösen von Incidents und Service Requests"
LP4.7	Lösen von Problemen	siehe RACI-Matrix "LP4.7: Lösen von Problemen"

 

Anmerkungen

Service Operation (Servicebetrieb): Prozess-Ziele

Basiert auf: Der Service-Operation-Prozess aus der YaSM-Prozesslandkarte.

Von:  Stefan Kempter   und  Andrea Kempter , IT Process Maps.

Themenverwandte Artikel

Der Servicebetrieb: Service Operation in YaSM und den ITSM-Frameworks.

Service Operation in YaSM

Da sich die heute gebräuchlichen Leitlinien für den Servicebetrieb über lange Zeit etabliert haben und allgemein anerkannt sind, basiert der YaSM Service-Operation-Prozess auf den Empfehlungen von ITIL^® und anderen Service-Management-Frameworks.

Was ist das Besondere an Service Operation in YaSM?
[ ... Weiterlesen ]

 

Prozess-Beschreibung  › Sub-Prozesse  › Prozess-Outputs  › Kennzahlen  › Rollen