LP2: Designen 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 123: | Zeile 123: | ||
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm"> | <div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm"> | ||
<dt itemprop="name" id="Service-Definition">Service-Definition</dt> | <dt itemprop="name" id="Service-Definition">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 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. Siehe auch: <a href="https://yasm.com/wiki/de/index.php/Service-Definition_-_Checkliste" title="Checkliste Service-Definition">Checkliste / Dokumentvorlage 'Service-Definition'</a>. <a href="#ydo" title="YaSM-Datenobjekt">[*]</a></dd></div> | ||
<div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm"> | <div itemprop="hasDefinedTerm" itemscope itemtype="https://schema.org/DefinedTerm"> | ||
<dt itemprop="name" id="Service-Implementierungs-Konzept">Service-Implementierungs-Konzept</dt> | <dt itemprop="name" id="Service-Implementierungs-Konzept">Service-Implementierungs-Konzept</dt> | ||
| Zeile 134: | Zeile 134: | ||
<p><i><u>Anmerkungen:</u></i> | <p><i><u>Anmerkungen:</u></i> | ||
</p><p><span id="ydo"><strong>[*]</strong> <i>"YaSM-Datenobjekte"</i> sind Dokumente und Records, für die YaSM | </p><p><span id="ydo"><strong>[*]</strong> <i>"YaSM-Datenobjekte"</i> sind Dokumente und Records, für die YaSM | ||
detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe <a href="https://yasm.com/wiki/de/index.php/Service-Management-Checklisten" title=" | detaillierte Empfehlungen bereithält: Für jedes YaSM-Objekt gibt es eine Checkliste (siehe <a href="https://yasm.com/wiki/de/index.php/Service-Definition_-_Checkliste" title="Beispiel: YaSM-Checkliste Service-Definition">Dokumentvorlage 'Service-Definition'</a> sowie <a href="https://yasm.com/wiki/de/index.php/Service-Management-Checklisten#yasm-checkliste-beispiel" title="Beispiele: YaSM-Checklisten und Dokument-Vorlagen">weitere Beispiele</a>), 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 <a href="https://yasm.com/wiki/de/img/yasm-projekt/Yasm-objekt-lifecycle-diagramm.jpg" title="Beispiel: YaSM Objekt-Lifecycle-Diagramm (.JPG)">Beispiel</a>).</span> | ||
</p><p><i>"Andere Objekte"</i> sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.</html> | </p><p><i>"Andere Objekte"</i> sind eher informelle Daten oder Informationen. Es gibt aus diesem Grund keine zugehörigen Lifecycle-Diagramme oder Checklisten.</html> | ||
==Rollen und Verantwortlichkeiten== | ==Rollen und Verantwortlichkeiten== | ||
<span id="verantwortlich">Prozess-Owner: Der '''Service-Design-Manager''' ist verantwortlich für die detaillierte Spezifikation der Anforderungen an neue bzw. zu ändernde Services, sowie für die Bestimmung eines geeigneten Vorgehens zu deren Implementierung.</span> | |||
<p> </p> | <p> </p> | ||
{| class="wikitable" style="background: white | {| class="wikitable" style="background: white; font-size: 95%" | ||
|+ | |+style="background:#465674; color:#ffffff; font-size: 110%"|Verantwortlichkeits-Matrix 'LP2: Designen neuer oder geänderter Services' | ||
|- style="vertical-align:top" | |- style="vertical-align:top" | ||
! colspan="2"| YaSM-Rolle / Sub-Prozess | ! colspan="2"| YaSM-Rolle / Sub-Prozess | ||
| Zeile 219: | Zeile 218: | ||
<html><div itemid="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/yasm-service-design-prozess.jpg" itemscope itemtype="https://schema.org/ImageObject"> | <html><div itemid="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/yasm-service-design-prozess.jpg" itemscope itemtype="https://schema.org/ImageObject"> | ||
<a href="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/yasm-service-design-prozess.jpg" title="Service-Design: Prozess-Ziel" itemprop="contentUrl"> | <a href="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/yasm-service-design-prozess.jpg" title="Service-Design: Prozess-Ziel" itemprop="contentUrl"> | ||
<img style="display: block; float: left; margin- | <img style="display: block; float: left; margin-bottom: 10px; margin-right: 10px" srcset="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/400px/yasm-service-design-prozess.jpg 400w, https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/yasm-service-design-prozess.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/yasm-service-design-prozess.jpg" decoding="async" width="400" height="209" class="thumbimage" title="Service-Design: Prozess-Ziele" alt="Ziel des Service-Design-Prozesses in YaSM ist das Definieren der erwarteten Ergebnisse und der erforderlichen Eigenschaften eines neuen oder geänderten Service, Bestimmen der Infrastruktur und anderer Voraussetzungen, die für das Erbringen des Service notwendig sind, sowie Entwickeln des Vorgehens zu dessen Implementierung." /> | ||
<meta itemprop="caption" content="Prozess-Ziel: YaSM Service-Design - Designen neuer oder geänderter Services (LP2)" /> | <meta itemprop="caption" content="Prozess-Ziel: YaSM Service-Design - Designen neuer oder geänderter Services (LP2)" /> | ||
<meta itemprop="width" content="1200" /> | <meta itemprop="width" content="1200" /> | ||
<meta itemprop="height" content="627" /> | <meta itemprop="height" content="627" /> | ||
<meta itemprop="dateCreated" content="2021-09-21" /> | <meta itemprop="dateCreated" content="2021-09-21" /> | ||
<meta itemprop="datePublished" content="2021-09-22" /></ | <meta itemprop="datePublished" content="2021-09-22" /> | ||
< | <span itemprop="thumbnail" itemscope itemtype="https://schema.org/ImageObject"> | ||
<p style="margin-top: 0; word-wrap:normal;">Basiert auf: Der Service-Design-Prozess aus der <a href="https://yasm.com/de/produkte/yasm-prozesslandkarte" title="YaSM-Prozesslandkarte">YaSM Prozesslandkarte</a>.</p> | <meta itemprop="url" content="https://yasm.com/wiki/de/img/yasm-prozess/ziel-definition/400px/yasm-service-design-prozess.jpg" /> | ||
<meta itemprop="width" content="400" /> | |||
<p>Von:  Stefan Kempter <a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/de/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="Von: Stefan Kempter | Profil auf LinkedIn" alt="Autor: Stefan Kempter, IT Process Maps GbR" /></a>  und  Andrea Kempter <a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/de/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="Von: Andrea Kempter | Profil auf LinkedIn" alt="Koautor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.<br style="clear:both;"/ | <meta itemprop="height" content="209" /> | ||
</span></a></div> | |||
<p style="margin-top: 0; word-wrap:normal;">Basiert auf: Der Service-Design-Prozess aus der <a href="https://yasm.com/de/produkte/yasm-prozesslandkarte" title="YaSM-Prozesslandkarte">YaSM-Prozesslandkarte</a>.</p> | |||
<p>Von:  Stefan Kempter <a href="https://www.linkedin.com/in/stefankempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/de/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="Von: Stefan Kempter | Profil auf LinkedIn" alt="Autor: Stefan Kempter, IT Process Maps GbR" /></a>  und  Andrea Kempter <a href="https://www.linkedin.com/in/andreakempter"><img style="margin:0px 0px 0px 0px;" src="/wiki/de/img/yasm-wiki/bookmarking/linkedin.jpg" width="16" height="16" title="Von: Andrea Kempter | Profil auf LinkedIn" alt="Koautor: Andrea Kempter, IT Process Maps GbR" /></a>, IT Process Maps.<br style="clear:both;"/><p></html> | |||
==Themenverwandte Artikel== | ==Themenverwandte Artikel== | ||
<html><a href="https://yasm.com/wiki/de/index.php/Service_Design"><img src="https://yasm.com/wiki/de/img/yasm-service-management/service-design.jpg" title="YaSM und Service-Design" alt="Der Service-Design-Prozess in YaSM enthält die Aktivitäten zum Designen neuer bzw. geänderter Services." | <html><a href="https://yasm.com/wiki/de/index.php/Service_Design"><img style="display: block; float: left; margin-bottom: 10px; margin-right: 10px" srcset="https://yasm.com/wiki/de/img/yasm-service-management/400px/service-design.jpg 400w, https://yasm.com/wiki/de/img/yasm-service-management/480px/service-design.jpg 480w, https://yasm.com/wiki/de/img/yasm-service-management/service-design.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/de/img/yasm-service-management/service-design.jpg" title="YaSM und Service-Design" alt="Der Service-Design-Prozess in YaSM enthält die Aktivitäten zum Designen neuer bzw. geänderter Services." decoding="async" width="400" height="225" class="thumbimage" /></a> | ||
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/de/index.php/Service_Design">YaSM und Service Design</a></p> | |||
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/de/index.php/Service_Design">YaSM und Service Design</a></p> | |||
<p><small>von: Stefan Kempter</small></p> | <p><small>von: Stefan Kempter</small></p> | ||
<p>Alle bekannten Service-Management-Frameworks und -Standards behandeln Fragen des Service-Designs.</p> | <p>Alle bekannten Service-Management-Frameworks und -Standards behandeln Fragen des Service-Designs.</p> | ||
<p>In ITIL<sup><small>®</small></sup> 4 wird Service Design als Practice bezeichnet. Außerdem findet sich Service Design in der aktuellen ITIL-Version auch als Schlüssel-Aktivität in der Service Value Chain (Service-Wertschöpfungskette) wieder: <a href="https://yasm.com/wiki/de/index.php/Service_Design">[...]</a></p | <p>In ITIL<sup><small>®</small></sup> 4 wird Service Design als Practice bezeichnet. Außerdem findet sich Service Design in der aktuellen ITIL-Version auch als Schlüssel-Aktivität in der Service Value Chain (Service-Wertschöpfungskette) wieder: <a href="https://yasm.com/wiki/de/index.php/Service_Design">[...]</a></p> | ||
<p style="clear:both;"> </p> | <p style="clear:both;"> </p> | ||
<a href="https://yasm.com/wiki/de/index.php/Capacity_Management"><img src="https://yasm.com/wiki/de/img/yasm-service-management/capacity-management.jpg" alt="ITIL®, verfügt über Kapazitätsmanagement als Teil von Service Design. Brauchen wir wirklich einen Capacity Management Prozess?" | <a href="https://yasm.com/wiki/de/index.php/Capacity_Management"><img style="display: block; float: left; margin-bottom: 10px; margin-right: 10px" srcset="https://yasm.com/wiki/de/img/yasm-service-management/400px/capacity-management.jpg 400w, https://yasm.com/wiki/de/img/yasm-service-management/480px/capacity-management.jpg 480w, https://yasm.com/wiki/de/img/yasm-service-management/capacity-management.jpg 1200w" sizes="100vw" src="https://yasm.com/wiki/de/img/yasm-service-management/capacity-management.jpg" alt="ITIL®, verfügt über Kapazitätsmanagement als Teil von Service Design. Brauchen wir wirklich einen Capacity Management Prozess?" decoding="async" width="400" height="225" class="thumbimage" /></a> | ||
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/de/index.php/Capacity_Management">Wo ist das Capacity Manage­ment?</a></p> | |||
<p style="margin-top: 0; word-wrap:normal;"><a href="https://yasm.com/wiki/de/index.php/Capacity_Management">Wo ist das Capacity | |||
<p><small>von: Stefan Kempter</small></p> | <p><small>von: Stefan Kempter</small></p> | ||
<p>Es würde niemand ernstlich bestreiten, dass Service-Kapazität und -Performance gemanagt werden müssen. Aber braucht man dazu einen Capacity-Management-Prozess? <a href="https://yasm.com/wiki/de/index.php/Capacity_Management">[...]</a></p | <p>Es würde niemand ernstlich bestreiten, dass Service-Kapazität und -Performance gemanagt werden müssen. Aber braucht man dazu einen Capacity-Management-Prozess? <a href="https://yasm.com/wiki/de/index.php/Capacity_Management">[...]</a></p><p> | ||
<br style="clear:both;"/> | |||
<p> </p> | <p> </p> | ||
<p><small> | <p><small> | ||
Version vom 29. Januar 2024, 11:47 Uhr
Prozessname: Designen neuer oder geänderter Services - Teil von: Service-Lifecycle-Prozesse
Vorhergehender Prozess: Festlegen der strategischen Richtung
Nächster Prozess: Erstellen neuer oder geänderter Services
Prozess-Beschreibung
Der Service-Design-Prozess in YaSM (Abb. 1) hat das Ziel, die erforderlichen Service-Eigenschaften zu definieren und die Infrastruktur sowie andere Voraussetzungen zu bestimmen, die für das Erbringen des Service notwendig sind. Zudem entwickelt der Prozess die Vorgehensweise zur Implementierung neuer oder geänderter Services.
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.
Kompatibilität: Der YaSM Design-Prozess ist kompatibel mit ISO 20000, dem internationalen Service-Management-Standard (vgl. ISO/IEC 20000-1:2018, Abschnitte 5, 8 und 9) und eignet sich zur Umsetzung der Practice 'ITIL 4 Service Design'.
Sub-Prozesse
YaSM's Service-Design-Prozess beinhaltet die folgenden Sub-Prozesse:
- LP2.1: Definieren der erforderlichen Service-Eigenschaften
- Prozessziel: Definieren des erwarteten Service-Ergebnisses und der erforderlichen Eigenschaften eines neuen oder geänderten Service. Dies schließt die Definition der Eigenschaften aller unterstützenden Services mit ein, die eingerichtet oder geändert werden müssen, um den neuen Service zu erbringen.
- LP2.2: Designen erforderlicher Service- und SMS-Komponenten
- Prozessziel: Spezifizieren der erforderlichen Infrastruktur und anderer Voraussetzungen, die geschaffen werden müssen, bevor ein neuer oder geänderter Service erbracht werden kann.
- LP2.3: Beschreiben des Vorgehens zur Implementierung
- Prozessziel: Beschreiben, wie die Infrastruktur und andere Voraussetzungen für die Erbringung eines neuen oder geänderten Service geschaffen werden.
- LP2.4: Vorbereiten der Service-Implementierung
- Prozessziel: Durchführen einer finalen Begutachtung der Service-Design-Dokumente, und Entscheiden, ob der Service zur Implementierung bereit ist. Dies schließt die Einreichung eines oder mehrerer RFCs beim Change-Bewertungs-Prozess mit ein.
Prozess-Outputs
Die folgenden Dokumente und Records werden vom Service-Design-Prozess 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 zur Bewertung der Compliance-Auswirkungen
- Eine Anforderung zur Bewertung, welche Compliance-Anforderungen für einen neuen oder geänderten Service relevant sind, typischerweise erteilt während des Service-Designs.
- Anforderung zum Hinzufügen von Services zum Serviceportfolio
- Eine Anforderung aus einem Service-Management-Prozess zum Hinzufügen neuer (Versionen von) Services zum Serviceportfolio. Eine solche Anforderung wird an den Serviceportfolio-Manager gerichtet, wenn neue oder signifikant geänderte Services erstellt werden.
- Anforderung zur Bewertung von Kontinuitäts-Risiken
- Eine Anforderung zur Bewertung von Risiken im Zusammenhang mit kritischen Ereignissen; diese wird typischerweise während des Service-Designs erteilt, falls evtl. neue oder geänderte Kontinuitäts-Vorkehrungen für einen neuen oder verbesserten Service benötigt werden.
- 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.
- Anforderungs-Spezifikation
- Ein Anforderungs-Spezifikations-Dokument enthält eine vollständige Beschreibung des Verhaltens einer Anwendung, eines Systems oder einer anderen Infrastruktur-Komponente, die zu entwickeln oder zu beschaffen ist. Anforderungs-Spezifikationen enthalten typischerweise funktionale und nicht-funktionale Anforderungen, wie z.B. Performance-Anforderungen oder Rahmenbedingungen für das Design. Inhalte und Detailtiefe hängen von der Art des spezifizierten Systems und der Zielsetzung der Spezifikation ab. [*]
- 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. [*]
- 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.
- Preis-Schema
- Ein Preis-Schema stellt die Basis für die Berechnung des Preises dar, den ein Kunde für die Nutzung eines Service zu bezahlen hat. Preis-Schemata werden vom Finanz-Manager gepflegt und können einfach oder komplexer sein, insbesondere wenn der zu bezahlende Betrag von der tatsächlichen Nutzung des Service oder der Service-Qualität abhängt. Eine Beschreibung des maßgeblichen Preis-Schemas ist auch in den Service-Vereinbarungen enthalten.
- 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. Siehe auch: Checkliste / Dokumentvorlage 'Service-Definition'. [*]
- Service-Implementierungs-Konzept
- Das Service-Implementierungs-Konzept baut auf den in den Service-Definitionen enthaltenen Spezifikationen auf. Es beschreibt aus technischer und organisatorischer Sicht, welche Voraussetzungen erforderlich sind, um einen neuen oder geänderten Service anbieten zu können, und skizziert den Ansatz zur Schaffung der notwendigen Service-Infrastruktur und sonstigen Voraussetzungen. Das Service-Implementierungs-Konzept ist eine wichtige Grundlage für die Projektplanung und die Service-Implementierung. [*]
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 Dokumentvorlage 'Service-Definition' sowie weitere Beispiele), 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.
Rollen und Verantwortlichkeiten
Prozess-Owner: Der Service-Design-Manager ist verantwortlich für die detaillierte Spezifikation der Anforderungen an neue bzw. zu ändernde Services, sowie für die Bestimmung eines geeigneten Vorgehens zu deren Implementierung.
| YaSM-Rolle / Sub-Prozess | Compli.-Mgr. | Finanz-Mgr. | Proz.-Owner | Sicherh.-Mgr. | Serv.-Kontin.-Mgr. | Serv.-Design-Mgr. | Serv.-Owner | Serv.-portf. Mgr. | Suppl.-Mgr. | Techn.- Fachexp. | |
|---|---|---|---|---|---|---|---|---|---|---|---|
| LP2.1 | Definieren der erforderlichen Service-Eigenschaften | R | R | - | R | R | AR | R | R | R | - |
| LP2.2 | Designen erforderlicher Service- und SMS-Komponenten | R | - | R | R | R | AR | R | - | - | R |
| LP2.3 | Beschreiben des Vorgehens zur Implementierung | - | - | - | - | - | AR | R | - | - | R |
| LP2.4 | Vorbereiten der Service-Implementierung | - | - | - | - | - | AR | R | - | - | R |
Anmerkungen
Basiert auf: Der Service-Design-Prozess aus der YaSM-Prozesslandkarte.
Von: Stefan Kempter 
und Andrea Kempter , IT Process Maps.
Themenverwandte Artikel
von: Stefan Kempter
Alle bekannten Service-Management-Frameworks und -Standards behandeln Fragen des Service-Designs.
In ITIL® 4 wird Service Design als Practice bezeichnet. Außerdem findet sich Service Design in der aktuellen ITIL-Version auch als Schlüssel-Aktivität in der Service Value Chain (Service-Wertschöpfungskette) wieder: [...]
Wo ist das Capacity Management?
von: Stefan Kempter
Es würde niemand ernstlich bestreiten, dass Service-Kapazität und -Performance gemanagt werden müssen. Aber braucht man dazu einen Capacity-Management-Prozess? [...]
Prozess-Beschreibung › Sub-Prozesse › Prozess-Outputs › Kennzahlen › Rollen
