LP3: Erstellen neuer oder geänderter Services: Unterschied zwischen den Versionen
Aus YaSM Service-Management-Wiki
Andrea (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
Andrea (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
| Zeile 128: | Zeile 128: | ||
==Prozess-Outputs== | ==Prozess-Outputs== | ||
<html><!-- define schema.org/ | <html><!-- define schema.org/DefinedTermSet --> | ||
<div itemid="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services# | <div itemid="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services#prozess-inputs-outputs" itemscope="itemscope" itemtype="https://schema.org/DefinedTermSet"> | ||
<link itemprop="additionalType" href="http://www.productontology.org/id/Input/output" /> | |||
<meta itemprop="name" content="YaSM-Prozess LP3: Dokumente und Records" /> | <meta itemprop="name" content="YaSM-Prozess LP3: Dokumente und Records" /> | ||
<meta itemprop="alternateName" content="Service-Erstellung Prozess-Outputs" /> | <meta itemprop="alternateName" content="Service-Erstellung Prozess-Outputs" /> | ||
| Zeile 136: | Zeile 137: | ||
<p> </p> | <p> </p> | ||
<dl style="color:#636363"><dt>Aktualisierungs-Daten für den Projektplan</dt> | <dl> | ||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Aktualisierungs-Daten für den Projektplan</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | |||
<dd | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Anforderung zum Hinzufügen von Kompetenzen und Personalressourcen</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | |||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Anforderung-zur-Aktualisierung-der-Service-Management-Prozesse">Anforderung zur Aktualisierung der Service-Management-Prozesse</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | ||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Anforderung-zur-Entwicklung-von-Anwendungen-oder-Systemen">Anforderung zur Entwicklung von Anwendungen oder Systemen</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | |||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Anforderung-zum-Einrichten-eines-externen-Service">Anforderung zum Einrichten eines externen Service</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | |||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Anforderung zur Änderung des Konfigurations-Modells</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | ||
<dd>Eine Dokumentation für Endanwender, die beschreibt, wie eine Anwendung oder ein System zu bedienen ist.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Anwender-Handbuch">Anwender-Handbuch</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">Eine Dokumentation für Endanwender, die beschreibt, wie eine Anwendung oder ein System zu bedienen ist.</dd></div> | |||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Beschaffungs-Anforderung</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | ||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt id="Bestaetigung-der-Service-Betriebsbereitschaft">Bestätigung der Service-Betriebsbereitschaft</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | ||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Bestaetigung-des-erfolgreichen-Ausrollens">Bestätigung des erfolgreichen Ausrollens</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | ||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt>CI Record</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Entwicklungs-QS-Dokumentation">Entwicklungs-QS-Dokumentation</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | |||
<dd | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt>Incident-Modell</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name">Informationen zum Change-Status</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | |||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt>Problem Record</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt>Service-Betriebshandbuch</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt>Service-Definition</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt>Service-Request-Modell</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | ||
<dd>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.</dd></ | <div style="color:#636363" itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt itemprop="name" id="Technisches-Handbuch">Technisches Handbuch</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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.</dd></div> | ||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt id="Testprotokoll">Testprotokoll</dt> | ||
< | <dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | ||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></ | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
< | <dt id="Testskript">Testskript</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
<dd>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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></dl> | <div itemprop="hasDefinedTerm" itemscope itemtype="http://schema.org/DefinedTerm"> | ||
</div><!-- end of schema.org/ | <dt>Wiederherstellungs-Plan</dt> | ||
<dd itemprop="description" style="margin-bottom: 1em;">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. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | |||
</dl> | |||
</div><!-- end of schema.org/DefinedTermSet --><p> | |||
<p> </p> | <p> </p> | ||
| Zeile 383: | Zeile 387: | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services#LP3.6"> | <link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services#LP3.6"> | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services#LP3.7"> | <link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services#LP3.7"> | ||
<link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services# | <link itemprop="hasPart" href="https://yasm.com/wiki/de/index.php/LP3:_Erstellen_neuer_oder_ge%C3%A4nderter_Services#prozess-inputs-outputs"> | ||
<link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess/Erstellen-neuer-oder-geaenderter-services-yasm-lp3.jpg" /> | <link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess/Erstellen-neuer-oder-geaenderter-services-yasm-lp3.jpg" /> | ||
<link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess-definition/was-ist-service-erstellungs-prozess.jpg" /> | <link itemprop="image" href="https://yasm.com/wiki/de/img/yasm-prozess-definition/was-ist-service-erstellungs-prozess.jpg" /> | ||
Version vom 25. Januar 2021, 15:46 Uhr
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').
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.
| 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
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
