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 Service

 

Prozess-Beschreibung

Abbildung 1: "Betreiben der Services". - YaSM Service-Lifecycle-Prozess LP4.

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

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

Die Abbildung oben 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.

 

Sub-Prozesse

"Betreiben der Services" 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-Infrastruktur laufend überwacht wird, und Bestimmen von geeigneten Maßnahmen, 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 von "Betreiben der Services" 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).

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.

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.

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 Beispiel), 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: Betriebs-Manager (Operations-Manager)

• 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.- Fachexp.
LP4.1	Unterstützen des Service-Betriebs	AR	R	R	R
LP4.2	Bereitstellen von Leitlinien für den Service-Betrieb	AR	-	R	R
LP4.3	Überwachen der Services	A	R	-	-
LP4.4	Erstellen von Service-Qualitätsberichten	A	R	R	-
LP4.5	Durchführen laufender Betriebsaufgaben	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"

 

[ Infobox ]

Link zu dieser Seite:	https://yasm.com/wiki/de/index.php/L4:_Betreiben_der_Services
Sprachversionen:	Deutsch | English
Image:	YaSM LP4: Betreiben der Services (.JPG)
Autoren:	Stefan Kempter     und   Andrea Kempter     -   IT Process Maps.

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