SP8: Gewährleisten von Kontinuität

 

Prozessname: Gewährleisten von Kontinuität - Teil von: Unterstützende Prozesse

Vorhergehender Prozess: Gewährleisten der Sicherheit

Nächster Prozess: Sicherstellen von Compliance

 

Prozess-Beschreibung

Der Service-Kontinuitäts-Prozess in YaSM (Abb. 1) dient zur Sicherstellung der Service-Kontinuität ('Service Continuity') im Fall von kritischen, disruptiven Ereignissen, wie z.B. Überschwemmungen, Feuer, Stromausfall usw.

Die Vorbereitung auf solche Ereignisse beginnt mit der Erstellung eines Registers der gemanagten kritischen Ereignisse. In diesem Register sind die Arten von disruptiven Ereignissen aufgelistet, für die der Service-Provider beschlossen hat, Vorbereitungsmaßnahmen zu treffen. Das Register spezifiziert außerdem, was zur Vorbereitung auf diese Ereignisse im Einzelnen unternommen werden muss; insbesondere verweist es auf die entsprechenden Service-Kontinuitäts-Pläne.

Abb. 1: 'Gewährleisten von Kontinuität':
YaSM Service-Kontinuitäts-Prozess SP8 (Service-Continuity-Management).

Der Kontinuitäts-Manager verfügt über eine Reihe von Möglichkeiten, Service-Kontinuität sicherzustellen. Die wichtigste hierbei ist, dass diese Rolle bereits in die Service-Design- und Service-Erstellungs-Prozesse einbezogen ist, um zu gewährleisten, dass Kontinuitätsaspekte bei der Erstellung oder Aktualisierung von Services berücksichtigt werden. Sobald im Verlauf der Design-Phase eines Services feststeht, welche Kontinuitätsvorkehrungen und -mechanismen für einen neuen Service erforderlich sind, können diese eingerichtet werden, und zwar

• über den Prozess "Erstellen von Services" durch Hinzufügen geeigneter Kontinuitätsmerkmale zur Service-Infrastruktur, die errichtet werden soll
• sowie über den Prozess "Gewährleisten von Kontinuität" durch Aktualisierung der Kontinuitätsvorkehrungen und -mechanismen, die in der Verantwortung des Service-Kontinuitäts-Managers betrieben werden.

Sofern Service-Kontinuitätsaspekte eine Rolle spielen, ist der Service-Kontinuitäts-Manager auch in die Service- oder Prozess-Verbesserungsinitiativen mit einbezogen.

Sollen neue Arten von kritischen Ereignissen berücksichtigt werden oder sind die Kontinuitätsvorkehrungen aus anderen Gründen zu verbessern, kann der Prozess "Gewährleisten von Kontinuität" selbstständig Kontinuitätsverbesserungs-Initiativen anstoßen. Solche Initiativen werden über den Kontinuitätsverbesserungs-Plan verwaltet.

 

Kompatibilität: Der YaSM-Prozess zur Service-Kontinuität ist kompatibel mit ISO 20000, dem internationalen Service-Management-Standard (vgl. ISO/IEC 20000-1:2018, Abschnitt 7) und eignet sich zur Umsetzung der Practice 'ITIL 4 Service Continuity Management'.

Sub-Prozesse

YaSM's Service-Kontinuitäts-Prozess beinhaltet die folgenden Sub-Prozesse:

SP8.1: Bewerten von Risiken aus kritischen Ereignissen

Prozessziel: Bestimmen der disruptiven Ereignisse, die vom Service-Provider gemanagt werden müssen, und Definieren geeigneter Kontinuitäts-Vorkehrungen und -Mechanismen.

SP8.2: Definieren von Kontinuitäts-Verbesserungen

Prozessziel: Definieren der Ziele von Initiativen zur Verbesserung der Service-Kontinuität und des Vorgehens zu deren Implementierung. Dies beinhaltet auch die Erstellung von Kosten-/ Nutzen-Analysen für die Initiativen.

SP8.3: Starten von Kontinuitäts-Verbesserungs-Initiativen

Prozessziel: Starten von Initiativen zur Sicherstellung bzw. Verbesserung der Service-Kontinuität. Dies beinhaltet auch das Einholen der Genehmigung durch Beantragung eines Budgets und Einreichen eines Requests for Change.

SP8.4: Implementieren von Kontinuitäts-Vorkehrungen

Prozessziel: Implementieren, Testen und Ausrollen von neuen oder verbesserten Kontinuitäts-Vorkehrungen und -Mechanismen.

SP8.5: Betreiben der Kontinuitäts-Vorkehrungen

Prozessziel: Durchführen geeigneter Schulungen zur Vorbereitung der Mitarbeiter und Kunden des Service-Providers auf kritische Ereignisse. Sicherstellen, dass die Kontinuitäts-Vorkehrungen und -Mechanismen regelmäßig gewartet und getestet werden.

SP8.6: Überprüfen der Kontinuitäts-Vorkehrungen

Prozessziel: Die Kontinuitäts-Vorkehrungen und -Mechanismen regelmäßigen Reviews zu unterwerfen, um Verbesserungspotentiale zu identifizieren, die mit Kontinuitäts-Verbesserungs-Initiativen adressiert werden sollen.

Prozess-Outputs

Die folgenden Dokumente und Records werden vom Prozess zur Gewährleistung der Service-Kontinuität ('Service-Continuity-Management') erzeugt. YaSM-Datenobjekte [*] sind mit einem Sternsymbol markiert, und andere Objekte werden in grau dargestellt.

Anforderung zur Bewertung der Compliance-Auswirkungen

Ist-Daten zu Projekt-Fortschritt und Ressourcen-Verbrauch, die von unterschiedlichen Service-Management-Prozessen an den Projektmanager übermittelt werden. Diese Daten sind ein Input für das Projekt-Controlling.

Aktualisierungs-Daten für den Projektplan

Ist-Daten zu Projekt-Fortschritt und Ressourcen-Verbrauch, die von unterschiedlichen Service-Management-Prozessen an den Projektmanager übermittelt werden. Diese Daten sind ein Input für das Projekt-Controlling.

Anforderung zur Bewertung von Sicherheits-Risiken

Eine Anforderung zur Bewertung von Sicherheits-Risiken; diese wird typischerweise während des Service-Designs erteilt, falls evtl. neue oder geänderte Sicherheits-Regelungen und -Mechanismen für einen neuen oder verbesserten Service benötigt werden.

Bericht zum Kontinuitäts-Review

Ein Bericht zum Kontinuitäts-Review zeichnet die Details und Ergebnisse eines Kontinuitäts-Reviews auf. Dieser Bericht ist eine wichtige Grundlage für die Definition von Initiativen zur Verbesserung der Service-Kontinuität. [*]

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.

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. [*]

Index der Informationen für kritische Ereignisse

Ein Katalog mit allen Informationen, die im Zusammenhang mit der Bewältigung von kritischen, disruptiven Ereignissen relevant sind. Dieser Index wird vom Service-Kontinuitäts-Manager gepflegt und an alle Mitarbeiter verteilt, die für das Bekämpfen von kritischen Ereignissen verantwortlich sind. [*]

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.

Kontinuitäts-Betriebshandbuch

Das Kontinuitäts-Betriebshandbuch spezifiziert die in der Verantwortung des Service-Kontinuitäts-Managers liegenden Aktivitäten, die für den Betrieb der Kontinuitäts-Vorkehrungen und -Mechanismen erforderlich sind. Einige Anweisungen für den Betrieb bestimmter Sicherheits-Systeme können in separaten technischen Handbüchern oder Standardarbeitsanweisungen ('Standard Operating Procedures, SOP') dokumentiert werden. [*]

Kontinuitäts-Verbesserungs-Plan

Einträge im Kontinuitäts-Verbesserungs-Plan (Continuity Improvement Plan) dienen dem Service-Kontinuitäts-Manager zur Erfassung und dem Management von Kontinuitäts-Verbesserungs-Initiativen über ihren gesamten Lebenszyklus. Initiativen im Kontinuitäts-Verbesserungs-Plan können die Ausfallsicherheit von Services erhöhen oder Mechanismen einrichten, mit denen die Services im Falle kritischer Ereignisse wieder hergestellt werden können. [*]

Leitfaden für kritische Ereignisse

Der Leitfaden für kritische Ereignisse enthält detaillierte Anweisungen, wann und wie das Verfahren zur Bewältigung kritischer, disruptiver Ereignisse eingeleitet wird. Insbesondere legt die Richtlinie die ersten Schritte fest, die der 1st Level Support nach Bekanntwerden eines (vermuteten) kritischen Ereignisses zu ergreifen hat. [*]

Register gemanagter kritischer Ereignisse

Das Register der gemanagten kritischen Ereignisse ist ein vom Service-Kontinuitäts-Manager genutztes Tool, das eine Übersicht über die kritischen Ereignisse bietet, gegen die der Service-Provider sich auf irgendeine Weise zu schützen beschlossen hat, ausgehend von der Betrachtung potenzieller Schäden und Eintrittswahrscheinlichkeiten. Das Register der gemanagten kritischen Ereignisse spezifiziert auch, wie die identifizierten Ereignisse behandelt werden; insbesondere nennt es die relevanten Service-Kontinuitäts-Pläne. [*]

Service-Kontinuitäts-Plan

Ein Service-Kontinuitäts-Plan beschreibt, wie Service-Kontinuität bei einer bestimmten Art von kritischem Ereignis erreicht wird. Der Plan spezifiziert die erforderlichen vorbereitenden Maßnahmen und beschreibt, wie im Ereignisfall effektiv reagiert werden kann. Service-Kontinuitäts-Pläne enthalten gewöhnlich Verweise auf spezielle Wiederherstellungs-Pläne (Recovery-Pläne) mit genauen Anleitungen zur Wiederherstellung von Anwendungen, Systemen und anderen Infrastruktur-Komponenten. [*]

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 Kontinuitäts-Verbesserung

Ein Vorschlag zur Verbesserung der Service-Kontinuität. 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-Kontinuitäts-Prozess.

Rollen und Verantwortlichkeiten

Prozess-Owner: Service-Kontinuitäts-Manager

• Der Service-Kontinuitäts-Manager ist verantwortlich für das Managen solcher Risiken, die gravierende Auswirkungen auf die vom Service-Provider erbrachten Services haben können. Insbesondere stellt diese Rolle sicher, dass der Service-Provider bei kritischen, disruptiven Ereignissen die vereinbarten Minimalanforderungen bereitstellen kann.

 

Verantwortlichkeits-Matrix: "SP8: Gewährleisten von Kontinuität"

YaSM-Rolle / Sub-Prozess		Compli.-Mgr.	Oper.	Proz.-Owner	Secur. mgr.	Serv.-Kontin.-Mgr.	Serv.-Owner	Techn.- Fach­exp.
SP8.1	Bewerten von Risiken aus kritischen Ereignissen	-	-	R	-	AR	R	-
SP8.2	Definieren von Kontinuitäts-Verbesserungen	R	-	-	R	AR	-	-
SP8.3	Starten von Kontinuitäts-Verbesserungs-Initiativen	-	-	-	-	AR	-	-
SP8.4	Implementieren von Kontinuitäts-Vorkehrungen	-	R	-	-	AR	-	R
SP8.5	Betreiben der Kontinuitäts-Vorkehrungen	-	R	-	-	AR	-	-
SP8.6	Überprüfen der Kontinuitäts-Vorkehrungen	-	-	-	-	AR	-	-

 

Anmerkungen

Basiert auf: Der Prozess für Service-Kontinuität aus der YaSM-Prozesslandkarte.

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

 

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