LP3: Erstellen neuer oder geänderter Services

 

Prozessname: Erstellen neuer oder geänderter Services - Teil von: Service-Lifecycle-Prozesse

Vorhergehender Prozess: Designen neuer oder geänderter Services

Nächster Prozess: Betreiben der Services

 

Prozess-Beschreibung

Über den Service-Erstellungs-Prozess (Abb. 1) in YaSM werden - sobald das Service-Design die Vorgehensweise zur Implementierung neuer oder geänderter Services definiert hat - die benötigte Infrastruktur, die unterstützenden Services, die Dokumentation sowie weitere Service-Komponenten aufgebaut, getestet und ausgerollt.

Abb. 1: 'Erstellen neuer geänderter Services':
YaSM Service-Erstellungs-Prozess LP3 ('Service-Implementierung').

Wenn infolge der Einführung eines neuen Services bestimmte Kompetenzen oder Ressourcen ausgebaut werden müssen, kann ggf. auf weitere Prozesse zurückgegriffen werden. Es kann beispielsweise erforderlich sein

• Service-Management-Prozesse zu verändern,
• Sicherheitsmechanismen und -vorkehrungen anzupassen,
• Service-Kontinuitätsvorkehrungen zu aktualisieren
• und neues Wissen bzw. Kompetenzen aufzubauen.

Während über die Service-Design- und Service-Erstellungsprozesse die eigentlichen Design- und Erstellungsaktivitäten erfolgen, besteht die Aufgabe des Projektmanagement-Prozesses typischerweise in der Gesamtplanung und -koordinierung des Service-Entwicklungsprojektes.

 

Kompatibilität: Der YaSM Service-Erstellungs-Prozess ist kompatibel mit ISO 20000, dem internationalen Service-Management-Standard (vgl. ISO/IEC 20000-1:2018, Abschnitte 8.5 und 8.7) und eignet sich zur Umsetzung mehrerer ITIL 4-Praktiken, wie 'ITIL 4 Release Management' und 'ITIL 4 Service Validation and Testing'.

Sub-Prozesse

YaSM's Service-Erstellungs-Prozess beinhaltet die folgenden Sub-Prozesse:

LP3.1: Koordinieren der Entwicklungs- und Beschaffungs-Aktivitäten

Prozessziel: Initiieren und Koordinieren der Aktivitäten für die Entwicklung oder Beschaffung der Infrastruktur-Komponenten und anderer Voraussetzungen, die für einen neuen oder geänderten Service benötigt werden.

LP3.2: Entwickeln von Anwendungen und Systemen

Prozessziel: Entwickeln und Konfigurieren von Anwendungen und Systemen, die die erforderliche Funktionalität für die Services bereitstellen. Dieser Prozess umfasst sowohl die Erstellung von selbst entwickelten Anwendungen und Systemen als auch die Anpassung und Konfiguration von Produkten, die von externen Herstellern beschafft werden.

LP3.3: Entgegennehmen der Service-Komponenten

Prozessziel: In Empfang nehmen der erforderlichen Service-Komponenten, um diese einer initialen Bewertung zu unterziehen. Dieser Prozess stellt sicher, dass nur solche Komponenten, die strikte Qualitätskriterien erfüllen, in die Hauptphase des Service-Tests Eingang finden.

LP3.4: Erstellung oder Aktualisierung der Betriebs-Dokumentation

Prozessziel: Bereitstellen von Leitlinien für den Betrieb des neuen Service, indem z.B. Service-Betriebshandbücher und Standard Operating Procedures erstellt oder aktualisiert werden.

LP3.5: Testen der Service-Komponenten

Prozessziel: Testen aller Service-Komponenten sowie der Werkzeuge und Mechanismen zu deren Ausrollen. Dieser Prozess stellt sicher, dass nur solche Komponenten, die strikte Qualitätskriterien erfüllen, in die produktive Umgebung ausgerollt werden.

LP3.6: Ausrollen der Service-Komponenten

Prozessziel: Ausrollen der Service-Komponenten in die Live-Umgebung. Dieser Prozess ist auch für die Konfiguration betriebsunterstützender Systeme und die Schulung von End-Anwendern und Betriebspersonal verantwortlich.

LP3.7: Vorbereiten der Service-Aktivierung

Prozessziel: Überprüfen, ob die gesamte Infrastruktur und andere Voraussetzungen vorhanden sind, bevor die Aktivierung der neuen Services freigegeben wird.

Prozess-Outputs

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

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 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.

Anforderung zur Aktualisierung der Service-Management-Prozesse

Eine Anforderung zur Aktualisierung der Prozesse des Service-Providers; diese wird typischerweise während einer Service-Implementierung erteilt, falls neue oder geänderte Prozesse für einen neuen Service benötigt werden.

Anforderung zur Entwicklung von Anwendungen oder Systemen

Eine Anforderung zur Entwicklung oder Anpassung einer Anwendung oder eines Systems; diese wird typischerweise während einer Service-Implementierung erteilt, falls neue oder geänderte Anwendungen oder Systeme für einen neuen Service benötigt werden.

Anforderung zum Einrichten eines externen Service

Eine Anforderung zum Einrichten eines externen unterstützenden Service; diese wird typischerweise während einer Service-Implementierung erteilt, falls neue oder geänderte externe unterstützende Services für einen neuen Service benötigt werden.

Anforderung zur Änderung des Konfigurations-Modells

Eine Anforderung aus einem Service-Management-Prozess zur Änderung des Konfigurations-Modells. Eine solche Anforderung wird an den Configuration-Manager gestellt, wenn neue CIs oder CI-Attribute im CMS dokumentiert werden müssen, aber die CMS-Struktur die Aufnahme der neuen Daten nicht ermöglicht.

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.

Bestätigung der Service-Betriebsbereitschaft

Die Bestätigung der Service-Betriebsbereitschaft dokumentiert die Ergebnisse eines Betriebsbereitschafts-Assessments. Ein Service wird auf Betriebsbereitschaft geprüft, bevor er in Betrieb gehen kann. Dabei werden Kriterien verwendet, die sich insbesondere auf die Fähigkeit des Service-Providers beziehen, den Service betreiben zu können. Wenn bestätigt ist, dass die Kriterien zur Betriebsbereitschaft erfüllt sind, kann der Service im Serviceportfolio auf 'aktiv' gesetzt werden. [*]

Bestätigung des erfolgreichen Ausrollens

Eine Bestätigung, dass das Ausrollen von Service-Komponenten erfolgreich abgeschlossen wurde; diese wird typischerweise während einer Service-Implementierung erteilt, falls neue oder geänderte Anwendungen oder Systeme für einen neuen Service ausgerollt werden müssen.

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

Entwicklungs-QS-Dokumentation

Eine Dokumentation von Tests und QS-Maßnahmen, die während Entwicklung oder Konfiguration von Anwendungen, Systemen und anderen Infrastruktur-Komponenten durchgeführt wurden. Die QS-Dokumentation weist nach, dass die vorgeschriebenen QS-Maßnahmen auf Komponenten-Ebene durchgeführt wurden, bevor eine Infrastruktur-Komponente zu den Service-Tests zugelassen wird.

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.

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

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

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

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

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-Erstellungs-Prozess.

Rollen und Verantwortlichkeiten

Prozess-Owner: Service-Implementierungs-Manager

• Der Service-Implementierungs-Manager ist verantwortlich für die Koordination der Implementierung neuer oder signifikant geänderter Services. Insbesondere stellt der Service-Implementierungs-Manager sicher, dass die gesamte Service-Infrastruktur und andere erforderliche Voraussetzungen ordnungsgemäß getestet und ausgerollt werden.

 

Verantwortlichkeits-Matrix: "LP3: Erstellen neuer oder geänderter Services"

YaSM-Rolle / Sub-Prozess		Anwend./ System-Entw.	Kunde	Oper.	Serv.-Implmnt.-Mgr.	Serv.-Owner	Techn.- Fachexp.	Test-Mgr.
LP3.1	Koordinieren der Entwicklungs- und Beschaffungs-Aktivitäten	-	-	-	AR	-	-	-
LP3.2	Entwickeln von Anwendungen und Systemen	AR	-	-	-	-	-	-
LP3.3	Entgegennehmen der Service-Komponenten	-	-	-	A	-	-	R
LP3.4	Erstellen oder Aktualisieren der Betriebs-Dokumentation	-	-	-	AR	R	R	-
LP3.5	Testen der Service-Komponenten	-	R	R	A	-	-	R
LP3.6	Ausrollen der Service-Komponenten	-	-	R	AR	-	-	-
LP3.7	Vorbereiten der Service-Aktivierung	-	-	-	AR	-	-	-

 

Anmerkungen

Basiert auf: Der Service-Erstellungsprozess aus der YaSM Prozesslandkarte.

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

Themenverwandte Artikel

YaSM und Service Transition

von: Stefan Kempter

Service Transition ist im Service-Management ein prominentes Thema, seit mit ITIL V3 der Service-Lifecycle eingeführt wurde. In ITIL^® 4 wurde das Konzept des Service-Lifecycles wieder aufgegeben, doch die meisten bekannten ITIL-Prozesse aus der Service-Transition-Phase sind in der aktuellen ITIL-Version als sogenannte "Practices" wiederzufinden: [...]

 

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