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
Sobald das Service-Design die Vorgehensweise zur Implementierung neuer oder geänderter Services definiert hat, werden über den YaSM-Prozess zum Erstellen der Services ("LP3: Erstellen neuer oder geänderter Services") die benötigte Infrastruktur, die unterstützenden Services, die Dokumentation sowie weitere Service-Komponenten aufgebaut, getestet und ausgerollt.
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-Entwicklungsprojekts.
Sub-Prozesse
"Erstellen neuer oder geänderter Services" 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 von "Erstellen neuer oder geänderter Services" 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 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.
| 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 | - | - | - |
[ Infobox ]
| Link zu dieser Seite: | https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services |
| Sprachversionen: | Deutsch | English |
| Image: | YaSM LP3: Erstellen neuer oder geänderter Services (.JPG) |
| Autoren: | Stefan Kempter  und
Andrea Kempter - IT Process Maps. |
Definition › Prozess-Beschreibung › Sub-Prozesse › Prozess-Outputs
