YaSM und ITIL V3

 

Vergleich: YaSM und die IT Infrastructure Library ITIL® V3 (ITIL 2011)

Teil von: YaSM und andere Service-Management-Frameworks und ‑Standards

 

YaSM® harmoniert besonders gut mit ITIL®, der 'IT Infrastructure Library'® [1]: Mit ITIL vertraute Anwender werden die gemeinsamen Prinzipien der beiden Service-Management-Methoden YaSM und ITIL sofort erkennen.

• Auf dieser Seite erhalten Sie Informationen dazu, wie sich das YaSM Service-Management-Modell zur Version ITIL V3 (ITIL 2011) verhält.
• Auf einer weiteren Seite haben wir für Sie eine detaillierte Gegenüberstellung zwischen YaSM und der neuesten ITIL-Version ITIL 4 erstellt.

 

Abb. 1: ITIL V3 und das YaSM-Modell - Vergleich
ITIL V3 Service-Lifecycle- vs. YaSM Service-Management-Prozesse.

 

Hinweise:

• YaSM ist ein unabhängiges Prozessmodell und wird nicht offiziell von den Herausgebern der ITIL-Publikationen unterstützt.
• Alle ITIL-Prozesse in den folgenden Tabellen sind mit Links zum ITIL®-Wiki von IT Process Maps versehen, wo Sie die detaillierten Beschreibungen der jeweiligen ITIL-Prozesse finden.

 

YaSM und ITIL Service Strategy

ITIL® V3 Service Strategy (Service-Strategie) vs. YaSM Service-Management

ITIL® V3-Prozesse	Rele­vante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
1.1 Strategie-Manage­ment für IT-Services	LP1: Fest­legen der strate­gischen Rich­tung	YaSM enthält einen auf das Wesentliche reduzierten strategischen Prozess, der weitgehend mit ITIL in Einklang ist und in dem die Aktivitäten zur Durchführung strategischer Assessments sowie zur Erstellung und Implemen­tierung der Service­strategie beschrieben sind. ITIL bietet zusätzliche Hilfestellung und Hinter­grund­informationen, beispielsweise zum Thema Analysieren der internen und externen Rahmen­bedingungen und Definieren der Position des Service Providers auf den anvisierten Märkten.
1.2 Service Portfolio Manage­ment	LP1: Fest­legen der strate­gischen Rich­tung SP2: Pflegen des Service­port­folios	Sowohl ITIL als auch YaSM sehen vor, dass alle vom Service Provider erbrachten Kunden- und unter­stützenden Services über das Service­portfolio verwaltet werden sollen. Der YaSM-Prozess zur Pflege des Serviceportfolios ist jedoch etwas enger gefasst als der Service­portfolio-Management-Prozess in ITIL. Der YaSM-Prozess befasst sich in erster Linie mit der Steuerung von Änderungen am Service­portfolio, um dessen Vollstän­digkeit und Konsistenz sicherzustellen, sowie ggf. mit der Erstellung von Service­katalogen. Entscheidungen über die Zusammen­setzung des Service­portfolios (d.h. des Service-Mix, der dem Kunden angeboten wird) gehören bei YaSM in den Zuständig­keitsbereich des strategischen Prozesses.
1.3 Financial Manage­ment für IT-Services	SP12: Managen der Service-Finanzen	Sowohl ITIL als auch YaSM enthalten Prozesse zum Managen der Finanzen, die nicht dazu gedacht sind, alle Aspekte des Finanz-Managements zu beschreiben, sondern die eine Reihe von Service-Management-relevanten Praktiken des Finanz-Managements aufzeigen wollen. ITIL bietet auf einigen Gebieten detailliertere Empfehlungen: So werden beispielsweise gebräuchliche Kostenmodelle und Verrechnungs-Methoden erläutert.
1.4 Demand Manage­ment	-/-	In YaSM ist kein separater Demand-Management-Prozess definiert. Stattdessen wird beschrieben, welchen Beitrag verschiedene YaSM-Prozesse zur Sicherstellung eines ordnungs­gemäßen Managements der Service-Nachfrage leisten. So werden Services im Rahmen des Service-Design-Prozesses für einen bestimmten Bedarf konzipiert und die tatsächliche Nachfrage nach den Services während des Servicebetriebs gemessen und berichtet. Falls erforderlich werden über den Service-Verbesserungs-Prozess Maßnahmen zum Umgang mit Problemen in Zusammenhang mit der Service-Nachfrage angestoßen. Die ITIL-Publikationen bieten zusätzliche Empfehlungen, beispielsweise zum Konzept von Business-Aktivitäts­mustern (Patterns of Business Activity).
1.5 Business Relation­ship Manage­ment	SP3: Pflegen der Kunden­bezie­hungen	Der YaSM-Prozess zum Pflegen der Kunden­beziehungen orientiert sich weitgehend an den ITIL-Empfehlungen. Er wird für die Pflege einer guten Geschäfts­beziehung zwischen dem Service Provider und dem Kunden herangezogen und soll sicherstellen, dass die Kunden­bedürfnisse verstanden werden. Dazu gehören die regelmäßige Kommunikation mit den Kunden, das Messen der Kunden­zufriedenheit und die Bearbeitung von Kunden­beschwerden.

Referenzen: [Cabinet Office, 2011a] und [IT Process Wiki - ITIL Service Strategy]

 

YaSM und ITIL Service Design

ITIL® V3 Service-Design vs. YaSM Service-Management

ITIL® V3-Prozesse	Rele­vante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
2.1 Design-Koordi­nierung	LP2: Designen neuer / geänd. Services SP6: Managen von Projekten	YaSM beinhaltet einen speziellen Prozess für das Managen von Projekten, dessen Aufgabe u.a. in der Koordinierung aller Service-Entwicklungs­projekte besteht. Dies schließt auch die Koordinierung der Service-Design-Aktivitäten mit ein. Ein wesentlicher Output des YaSM-Service-Design-Prozesses ist das "Service-Implementierungs-Konzept", in dem beschrieben wird, welche Fähigkeiten zur Bereit­stellung eines neuen oder geänderten Services erforderlich sind. Außerdem ist dort die Vorgehens­weise zur Erstellung der notwendigen Service-Infrastruktur und anderer Fähigkeiten skizziert. In ITIL entspricht dies dem "Service Design Package (SDP)". Das SDP soll eine beträchtliche Menge zusätzlicher Informationen enthalten, zum Beispiel verschiedene Richtlinien und Pläne. Bei YaSM sind solche Informationen in anderen Dokumenten enthalten.
2.2 Service Cata­logue Manage­ment	SP2: Pflegen des Service­port­folios	Sowohl ITIL als auch YaSM definieren Servicekataloge als spezifische Sichten auf die im Serviceportfolio enthaltenen Informationen, wobei in der ITIL-Gemeinde die Begriffe Servicekatalog und Serviceportfolio häufig gleich­bedeutend nebeneinander zu verwenden scheinen. Bei YaSM wird aus Gründen der Eindeutigkeit meistens der Begriff Serviceportfolio benutzt. Der YaSM-Prozess "Pflegen des Serviceportfolios" enthält Aktivitäten zur Veröffentlichung von Servicekatalogen sowie zur Sicherstellung, dass diese entsprechend den Aktuali­sierungen des Serviceportfolios stets auf dem neuesten Stand und in sich stimmig sind.
2.3 Service Level Manage­ment	LP2: Designen neuer / geänd. Services LP4: Betreiben der Services LP5: Ver­bessern der Services SP3: Pflegen der Kunden­bezie­hungen	Bei YaSM wird davon ausgegangen, dass mehrere Service-Lifecycle-Prozesse zum Managen der Service Levels zusammenwirken. Daher gibt es bei YaSM keinen eigenen Prozess für das Managen von Service Levels. Die erforderlichen Service Levels - ebenso wie die erforderliche Service­funktionalität - werden auf der Grundlage der Kunden­bedürfnisse im Rahmen der Service-Design-Phase definiert. Überwachung und Reporting der erreichten Service Levels sind beim Servicebetrieb angesiedelt. Im Service-Verbesserungs-Prozess werden Reviews durchgeführt, wobei die erreichten Service Levels mit den zugesagten Levels verglichen und ggf. Korrektur­maßnahmen veranlasst werden. Die Service-Verantwortlichen (Service-Owner) sind letztendlich für die Erbringung der vereinbarten Service Levels verantwortlich. Ihnen kommt hier eine Schlüsselrolle zu. Aufgabe des YaSM-Prozesses "Pflegen der Kunden­beziehungen" ist es, die gewünschten Service-Ergebnisse aus Kundensicht zu bestimmen sowie Service-Vereinbarungen mit den Kunden auszuhandeln und zu unterzeichnen. Bei den meisten Service Providern müssen Vereinbarungen mit den Kunden Service-Level-Ziele (Warranty = Gewährleistung) beinhalten, aber auch die benötigten Service­funktionen (Utility = Nutzen) sowie weitere Aspekte. Aus diesem Grund sprechen wir bei YaSM von "Kunden-Service-Vereinbarungen", "betrieblichen Service-Vereinbarungen" und "externen Service-Vereinbarungen", wohingegen ITIL die Begriffe "Service-Level-Vereinbarungen" (Service Level Agreements, SLAs) "Vereinbarungen auf Betriebsebene" (Operational Service Agreements, OLAs) und "Verträge mit Drittparteien" (Underpinning Contracts, UCs) verwendet. ITIL bietet zusätzliche Empfehlungen, beispielsweise zum Design von SLA-Rahmenwerken. Siehe auch: Service Level Management in YaSM
2.4 Availa­bility Manage­ment	LP2: Designen neuer / geänd. Services LP3: Erstellen neuer / geänd. Services LP4: Betreiben der Services LP5: Ver­bessern der Services	Sowohl bei YaSM als auch bei ITIL ist vorgesehen, dass die Service­verfügbarkeit gemanagt wird, jedoch gibt es in YaSM keinen gesonderten Availability-Management-Prozess. Stattdessen wird die Service­verfügbarkeit als ein Aspekt der Services behandelt, der über die Service-Lifecycle-Prozesse zu verwalten ist: Die Anforderungen an die Verfügbarkeit werden während der Service-Design-Phase definiert, und anhand dieser Anforderungen werden dann die Services erstellt. Das Messen der tatsächlich erreichten Verfügbarkeits-Levels gehört zum Verantwortungs­bereich des Betriebs­prozesses. Für den Fall, dass eine Verbesserung der Service­verfügbarkeit notwendig ist, kann der Service-Verbesserungs-Prozess aktiv werden und mit Hilfe von Service-Verbesserungs­plänen Korrektur­maßnahmen anstoßen. Die ITIL-Bücher bieten zusätzliche Empfehlungen, beispielsweise dahingehend, wie das Design der Services und der zugrunde­liegenden technischen Infrastruktur im Hinblick auf die Service­verfügbarkeit zu gestalten ist. Siehe auch: Availability Management in YaSM
2.5 Capacity Manage­ment	LP2: Designen neuer / geänd. Services LP3: Erstellen neuer / geänd. Services LP4: Betreiben der Services LP5: Ver­bessern der Services	In ITIL heißt es, dass "Capacity Management ein Prozess ist, der sich über den ganzen Service-Lebenszyklus erstreckt". Folglich enthält YaSM auch keinen eigenen Capacity-Management-Prozess, sondern behandelt Servicekapazität und ‑Performance als Aspekte, die über die Service-Lifecycle-Prozesse zu managen sind: Die Anforderungen an Kapazität und Performance werden während der Service-Design-Phase festgelegt, und anhand dieser Anforderungen werden dann die Services erstellt. Das Messen der Kapazitäts- und Performance-Levels gehört zum Betriebsprozess. Für den Fall, dass eine Kapazitäts­anpassung oder eine Verbesserung der Performance notwendig ist, kann der Service-Verbesserungs-Prozess aktiv werden und mit Hilfe von Service-Verbesserungs­plänen Korrektur­maßnahmen anstoßen. Die ITIL-Bücher können bei Bedarf herangezogen werden, falls beispielsweise zusätzliche Empfehlungen zur Kapazitäts­überwachung und ‑analyse oder zur Optimierung der Nutzung von Ressourcen ("Capacity Tuning") gewünscht sind. Siehe auch: Capacity Management in YaSM
2.6 IT Service Conti­nuity Manage­ment (ITSCM)	SP8: Gewähr­leisten von Kontinuität	Beide Prozesse ("ITSCM "in ITIL und "Gewährleisten von Kontinuität" in YaSM) befassen sich in erster Linie mit kritischen, disruptiven Ereignissen, die oft auch als Katastrophenereignisse bezeichnet werden. YaSM empfiehlt, kritische Ereignisse, für die der Service Provider Vorsorge­maßnahmen beschlossen hat, in einem Register gemanagter kritischer Ereignisse zu dokumentieren. Service-Kontinuitäts-Pläne beschreiben, wie die Service­kontinuität bei bestimmten Arten von kritischen Ereignissen sichergestellt werden soll. Die Implemen­tierung der erforderlichen Kontinuitäts­vorkehrungen wird über den Kontinuitäts-Verbesserungsplan gemanagt. In YaSM ist der Prozess zum Lösen von Major Incidents für das Bekämpfen tatsächlich eingetretener disruptiver Ereignisse zuständig. Dieser Prozess sieht die Bildung eines Major-Incident-Teams vor, das die Berechtigung hat, geeignete Service-Kontinuitäts­pläne zu aktivieren. ITIL gibt zusätzliche Empfehlungen, wie Beispiele zu möglichen Risiken und Gefahren sowie Optionen zur Wieder­herstellung von Systemen.
2.7 Information Security Manage­ment	SP7: Gewähr­leisten der Sicher­heit	Der YaSM-Prozess zur Gewährleistung der Sicherheit bezieht sich nicht speziell auf Informations­sicherheit, da es sich bei YaSM ja um ein Konzept handelt, das sich auf alle Arten von Organisationen, die Dienst­leistungen erbringen, anwenden lässt (d.h. nicht nur auf Service Provider im IT-Bereich). ITIL empfiehlt die Einrichtung eines "Management­systems für Informations­sicherheit (Information Security Management System, ISMS)", das ein "Informations­system für Sicherheits­management (Security Management Information System, SMIS)" beinhaltet. YaSM beschreibt und dokumentiert die Verfahren des Security Management im Rahmen seines Prozessmodells sowie über eine Reihe von Sicherheits­richtlinien. Die zu managenden Sicherheits­risiken einschließlich der vorgesehenen Risiko­bewältigungs­maßnahmen sind im Register der Sicherheitsrisiken dokumentiert. Die Implementierung der Sicherheits­vorkehrungen und ‑Maßnahmen wird über den Sicherheits-Verbesserungsplan verwaltet. Die ITIL-Publikationen enthalten zusätzliche Hinweise, wie beispielsweise eine Liste der empfohlenen (unterstützenden) Sicherheits­richtlinien sowie einen Überblick über die Methoden der Risiko­abschätzung und des Risiko­managements.
2.8 Supplier Manage­ment	SP11: Managen v. Liefe­ranten u. Dienst­leistern	Der in YaSM beschriebene Prozess "Managen von Lieferanten und Dienstleistern" orientiert sich an den ITIL-Empfehlungen, jedoch mit folgenden Einschränkungen: Bei YaSM sind die Definition der Anforderungen sowie die Entscheidung darüber, ob ein unter­stützender Service intern oder extern erbracht werden soll, beim Service-Design-Prozess angesiedelt. Ist diese Entscheidung dann getroffen, obliegt es dem Supplier Management, geeignete Lieferanten bzw. Dienstleister auszuwählen und zu etablieren und die externen Services einzurichten. Der Servicebetriebs-Prozess ist für die Überwachung der erreichten Servicequalität sowie für die Erstellung von Service-Qualitäts­berichten zuständig. Dazu gehört auch die Überwachung der extern erbrachten unterstützenden Services. Über den YaSM-Service-Verbesserungs-Prozess wird sichergestellt, dass die externen Services regelmäßig einem Review unterzogen werden. Die Ergebnisse solcher Service Reviews können dann zur Identifizierung und Implementierung von Service­verbesserungen führen, die über einen Service-Verbesserungsplan verwaltet werden. ITIL bietet zusätzliche Empfehlungen, beispielsweise zu Kriterien für die Auswahl neuer Lieferanten bzw. Dienstleister sowie Vorschläge für eine Kategorisierung von Suppliern.

Referenzen: [Cabinet Office, 2011b] und [IT Process Wiki - ITIL Service Design]

 

YaSM und ITIL Service Transition

ITIL® V3 Service Transition (Service-Überführung) vs. YaSM Service-Management

ITIL® V3-Prozesse	Rele­vante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
3.1 Transi­tion Planning und Support	SP6: Managen von Projekten	Der YaSM-Prozess "Managen von Projekten" ist für die Planung und Koordinierung von wichtigen Service-Management-Initiativen, wie zum Beispiel die Erstellung neuer oder erheblich geänderter Services zuständig. Dazu gehört auch die Planung und Koordinierung der Service-Überführungsphase. Bei ITIL ist der Ansatz etwas anders: Der Prozess "Transition Planning und Support" ist dazu gedacht, die Gesamtplanung von Service-Überführungs­projekten zu unterstützen, wobei ein Teil der Detailplanung über zwei weitere ITIL-Prozesse, nämlich das Change Management und das Release und Deployment Management, erfolgt.
3.2 Change Manage­ment	SP5: Bewerten u. Koor­dinieren v. Changes	Der in YaSM beschriebene Change-Bewertungs-Prozess orientiert sich an den ITIL-Empfehlungen, jedoch mit folgenden Einschränkungen: In YaSM sind Requests for Change (RFCs) nicht als separater Datenobjekttyp definiert, sondern als Ausgangszustand eines Change Records, der alle Informationen zur Bewertung eines vorgeschlagenen Changes enthält. Im Verlauf seines Lebenszyklus wird der Change Record mit weiteren Informationen ergänzt. YaSM unterscheidet nicht zwischen Changes und Change-Vorschlägen (Change Proposals). ITIL schlägt vor, dass einige Changes zu verschiedenen Zeitpunkten während ihres Lebenszyklus evaluiert werden, zum Beispiel vor der Build- und Test-Phase oder vor dem Ausrollen. YaSM verfolgt hierbei einen einfacheren Ansatz: Alle vorgeschlagenen Changes werden bei Eingang eines Request for Change bewertet und nach der Implementierung einem Review unterzogen. Den Change-Verantwortlichen (Change-Ownern) sowie den Projekt-, Test- und Deployment-Managern obliegt es sicher­zustellen, dass die Regeln der Organisation in Bezug auf Planung, Test und Implementierung von Changes befolgt werden und dass der Change auch den erwarteten Nutzen bringt. Der YaSM-Prozess "Bewerten von Changes" dient zur Bewertung der mit einem vorgeschlagenen Change einhergehenden Risiken, aber nicht in erster Linie zur Planung der Changes. Die Planungsaktivitäten sind bei Initiativen größeren Umfangs in der Regel beim YaSM-Projektmanagement-Prozess angesiedelt. Während laut ITIL der Change-Manager eine Liste der voraussichtlichen Serviceunterbrechungen (Projected Service Outages, PSO) erstellen soll, wird bei YaSM davon ausgegangen, dass das Betriebspersonal eher in der Lage ist, einen "Kalender der geplanten Serviceunterbrechungen" zu pflegen. In diesem Kalender werden Unterbrechungen aus den verschiedensten Gründen berücksichtigt, wie zum Beispiel aufgrund von Change Deployments, betriebliche Aktivitäten, Sicherheitstests usw.
3.3 Service Asset und Configu­ration Manage­ment	SP4: Verwalten v. Konfig.-Informa­tionen	Der in YaSM beschriebene Konfigurations­management-Prozess orientiert sich an den ITIL-Empfehlungen, jedoch mit folgenden Einschränkungen: Der YaSM-Prozess zum Verwalten von Konfigurations­informationen bietet den Rahmen für das Kontrollieren der Konfigurations­elemente (Configuration Items, CIs) und der zugehörigen Konfigurations­informationen. Insbesondere obliegt es dem Configuration-Manager zu bestimmen, welche CI-Typen der Kontrolle unterliegen sollen und wer berechtigt sein soll, diese CIs sowie die entsprechenden CMS-Inhalte zu ändern. Die Änderungen am CMS als solche erfolgen meistens durch andere Service-Management-Prozesse. Der Configuration-Manager verfolgt und überprüft die Änderungen und auditiert die Informationen im CMS regelmäßig. Was die Aufzeichnung und Bereitstellung von Lebenszyklus-Daten zu den CIs ("Status Accounting") anbelangt, ist im YaSM-Konfigurations­management-Prozess für jeden CI-Typ ein geeigneter Satz erlaubter Statuswerte definiert, wobei das Aufzeichnen der Statusänderungen im Rahmen anderer Service-Management-Prozesse erfolgt.
3.4 Release und Deploy­ment Manage­ment	LP3: Erstellen neuer / geänd. Services SP6: Managen von Projekten	Der YaSM-Prozess "Managen von Projekten" ist für die Planung und Koordinierung von bedeutenden Service-Management-Initiativen zuständig, wie beispielsweise das Erstellen neuer oder geänderter Services. Dazu gehört auch die Planung und Steuerung der Erstellungs-, Test und Deployment-Aktivitäten für neue Services und deren zugrunde liegende Infrastruktur. Über den Service-Erstellungs-Prozess wird sichergestellt, dass alle benötigten Service­komponenten vor dem Ausrollen getestet werden und dass im CMS enthaltene Konfigurations­informationen soweit erforderlich aktualisiert werden. Neue Services dürfen erst dann aktiviert werden, wenn die Bereitschaft der Organisation zum Betrieb des Services bestätigt wurde. ITIL bietet zusätzliche Empfehlungen, beispielsweise zum Design von Release Packages und zu Deployment-Optionen für die IT-Infrastruktur.
3.5 Service-Validie­rung und ‑Test	LP3: Erstellen neuer / geänd. Services	YaSM enthält keinen separaten Test-Prozess, sondern der Service-Erstellungs-Prozess umfasst auch diejenigen Aktivitäten, die für Tests der Infrastruktur und anderer für einen neuen oder geänderten Service erforderlichen Fähigkeiten notwendig sind (siehe auch Anmerkungen zum ITIL-Prozess: Release und Deployment Management). Für den Fall, dass bei den Tests Fehler bei den Servicekomponenten festgestellt werden, werden über den Service-Build-Prozess auch Korrektur­maßnahmen angestoßen. Die ITIL-Bücher enthalten zusätzliche Informationen, so zum Beispiel eine Erläuterung gebräuchlicher Teststrategien und Testtypen.
3.6 Change-Evalu­ierung	SP5: Bewerten u. Koor­dinieren v. Changes	Laut ITIL sollen bestimmte Arten von (signifikanten) Changes einem formellen Change-Evaluierungs-Prozess unterworfen werden. Bei YaSM gibt es keinen eigenen Change-Evaluierungs-Prozess, sondern YaSM behandelt Change-Evaluierungen als Teil des Change-Bewertungs-Prozesses.
3.7 Know­ledge Manage­ment	-/-	Das YaSM-Modell beinhaltet keinen speziellen Knowledge-Management-Prozess. YaSM geht davon aus, dass mehrere Service-Management-Prozesse am Management von Wissen beteiligt sind und dass die Prinzipien des Knowledge Managements auch in mehreren Service-Management-Prozessen verwendet werden. Beispielsweise verwaltet der Incident-Behebungs-Prozess Wissen darüber, wie bestimmte Arten von Service Incidents zu handhaben sind.

Referenzen: [Cabinet Office, 2011c] und [IT Process Wiki - ITIL Service Transition]

 

YaSM und ITIL Service Operation

ITIL® V3 Service Operation (Servicebetrieb) vs. YaSM Service-Management

ITIL® V3-Prozesse	Rele­vante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
4.1 Event Manage­ment	LP4: Betreiben der Services	In YaSM ist kein spezieller Event-Management-Prozess definiert, sondern der Prozess "Betreiben der Services" deckt die Aktivitäten zur Konfigurierung der Event-Monitoring-Systeme sowie zum Event-Monitoring und zur Entscheidung über angemessene Reaktionen ab. Darüber hinaus ist in YaSM vorgesehen, dass der Incident-Behebungs-Prozess angestoßen werden kann, wenn bestimmte Arten von Events festgestellt werden, welche ein menschliches Eingreifen erforderlich machen. Die ITIL-Publikationen enthalten zusätzliche Empfehlungen, zum Beispiel in Bezug auf Event-Filterungs- und Korrelationsregeln.
4.2 Incident Manage­ment	LP4.6: Lösen v. Incidents u. Service Requests	Der in YaSM beschriebene Prozess zum Lösen von Incidents und Service Requests orientiert sich an den ITIL-Empfehlungen, jedoch mit den folgenden Einschränkungen: Während ITIL empfiehlt, zwei separate Prozesse für das Managen von Incidents und Service Requests zu implementieren, geht YaSM davon aus, dass sich diese Prozesse von der Art her sehr ähneln. Daher gibt es in YaSM nur einen einzigen Prozess für die Bearbeitung sowohl von Incidents als auch von Serviceaufträgen. Laut ITIL geht es beim Incident Management um die schnellst­mögliche Wieder­herstellung der Services, während das Problem Management sich mit Diagnose und Lösung der Ursachen befasst, die den Incidents zugrunde liegen. Den einzelnen Organisationen wird jedoch ein gewisser Grad an Freiheit bei der genauen Festlegung der Regeln eingeräumt, wann das Problem Management und nicht mehr das Incident Management zuständig ist. Bei YaSM ist hierbei ein einfacher Ansatz gewählt worden: Im Rahmen des Incident-Behebungs-Prozesses werden alle notwendigen Maßnahmen zur Lösung eines Incidents ergriffen, evtl. unter Zuhilfenahme eines Workarounds und Hinzuziehung von Fachleuten des 2nd und 3rd Level Supports. Der Problemlösungs-Prozess wird erst nach Abschluss des Incidents aufgerufen, zum Beispiel in Fällen, in denen die zugrunde liegende Ursache eines Incidents nicht behoben werden konnte oder unklar ist.
4.3 Request Fulfill­ment	LP4.6: Lösen v. Incidents u. Service Requests	Der in YaSM beschriebene Prozess zum Lösen von Incidents und Service Requests orientiert sich an den ITIL-Empfehlungen, jedoch mit den folgenden Einschränkungen: Während ITIL die Implementierung von zwei verschiedenen Prozessen für das Managen von Incidents und Service Requests empfiehlt, geht YaSM davon aus, dass sich diese Prozesse von der Art her sehr ähneln. Daher gibt es in YaSM nur einen einzigen Prozess für die Bearbeitung sowohl von Incidents als auch von Serviceaufträgen.
4.4 Problem Manage­ment	LP4.7: Lösen v. Proble­men	Der in YaSM beschriebene Prozess zum Lösen von Problemen orientiert sich an den ITIL-Empfehlungen, jedoch mit den folgenden Einschränkungen: Da es sich laut ITIL bei Known Errors (bekannten Fehlern) um "Problems mit bekannten zugrunde liegenden Ursachen und einem Workaround" handelt, empfiehlt YaSM, Informationen über zugrunde liegende Ursachen und in Frage kommende Workarounds als Teil der Problem Records zu führen. ITIL plädiert dafür, Known Errors über eine "Known-Error-Datenbank (KEDB)" zu verwalten. Für den Fall, dass die Lösung eines Problems einen Change notwendig macht, beschreibt der YaSM-Prozess "Lösen von Problemen" den Change und bereitet einen Business Case (Kosten-Nutzen-Rechnung) vor; der Change wird dann in der Regel über einen Service- bzw. Prozess-Verbesserungs­plan unter der Federführung des Service- bzw. Prozess­verantwortlichen implementiert. ITIL bietet zusätzliche Hinter­grund­informationen, insbesondere in Bezug auf Methoden der Problemanalyse.
4.5 Access Manage­ment	LP4: Betreiben der Services SP7: Gewähr­leisten der Sicher­heit	YaSM enthält keinen speziellen Access-Management-Prozess, sondern der Servicebetriebs-Prozess deckt die Aktivitäten zur Konfigurierung der Zugriffs­kontrollsysteme sowie zum Nachverfolgen von Zugriffen auf die Services ab. Der Security-Manager legt die Regeln für die Gewährung von Zugriff auf die Services in einer geeigneten Sicherheits­richtlinie fest und führt regelmäßig ein Review der gewährten Zugriffsrechte durch. Individuelle Anträge auf Zugriff auf einen Service werden in Form von Service Requests abgewickelt. Die ITIL-Publikationen enthalten zusätzliche Informationen, beispielsweise darüber, wie User-Profile zur Gewährung von Zugriffsrechten verwendet werden können.

Referenzen: [Cabinet Office, 2011d] und [IT Process Wiki - ITIL Service Operation]

 

YaSM und ITIL Continual Service Improvement

ITIL® V3 Continual Service Improvement (Kontinuierliche Serviceverbesserung) vs. YaSM Service-Management

ITIL® V3-Prozesse	Rele­vante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
5.1 Verbesse­rungs-Prozess in sieben Schritten	LP5: Ver­bessern der Services	Der in den ITIL-Büchern vorgestellte "Verbesserungs­prozess in sieben Schritten" stellt im Grunde genommen die Beschreibung einer Methodik dar, die allgemein auf die Identifizierung von Mängeln bei den Services und Prozessen und auf die Implementierung von Verbesserungen anwendbar ist. Die Prinzipien, die dort empfohlen werden, sind in einer Reihe von YaSM-Prozessen verankert. Ein Beispiel ist der Prozess "Verbessern der Services".

Referenzen: [Cabinet Office, 2011e] und [IT Process Wiki - ITIL CSI - Kontinuierliche Serviceverbesserung]

 

Wo YaSM über ITIL hinausgeht

YaSM ist zwar in vieler Hinsicht im Vergleich zu ITIL verschlankt, jedoch gibt es auch eine Reihe von YaSM-Prozessen, die über die ITIL-Empfehlungen hinausgehen. Diese Prozesse wurden hauptsächlich eingeführt, um YaSM mit anderen Service-Management-Standards und ‑Rahmenwerken wie z.B. ISO 20000, COBIT® [3], USMBOK™ [4] und CMMI-SVC® [5] in Einklang zu bringen.

Die folgende Tabelle gibt einen Überblick über die zusätzlichen Prozesse und erläutert ihren Zweck innerhalb des YaSM-Modells:

 

YaSM-Prozessen, die über die ITIL®-Empfehlungen hinausgehen

YaSM-Prozesse, die nicht in ITIL® spezifiziert sind	Anmerkungen
SP1: Einrichten u. Pflegen d. Service-Mgmt.-Systems	ITIL legt den Schwerpunkt auf das Managen von Services über ihren gesamten Lebenszyklus hinweg, sagt jedoch nicht explizit, wie die Service-Management-Prozesse überhaupt entstehen. Im ISO 20000-Standard sind Anforderungen an Service Provider im Hinblick auf Planung, Einrichtung, Implementierung, Betrieb, Überwachung, Review, Pflege und Verbesserung eines "Service-Management-Systems (SMS)" spezifiziert, in dem die Service-Management-Prozesse eine wesentliche Komponente darstellen. Dies bedeutet, dass es eine gewisse Lücke zwischen ITIL und ISO 20000 gibt, die YaSM dadurch schließt, dass ein eigener Prozess für das Einrichten und Pflegen des Service-Management-Systems eingeführt wurde.
SP6: Managen von Projekten	Gemäß ITIL befassen sich eine Reihe von Prozessen mit der Durchführung von Koordinierungsaktivitäten, insbesondere Design-Koordinierung, Transition Planning und Support, Change Management sowie Release und Deployment Management. Das Problem bei diesem Ansatz ist, dass es mehrere Koordinierungsprozesse gibt, die jeweils bestimmte Teile eines Service-Entwicklungsprojekts koordinieren. In YaSM gibt es stattdessen eine zentrale Instanz, die die Aufgabe hat, alle Aspekte der Service-Entwicklungs-Projekte von Anfang bis Ende zu planen und zu koordinieren. Der YaSM-Prozess "Managen von Projekten" ist auch vielseitiger, da er nicht nur bei der Einführung neuer Services, sondern auch für das Managen anderer umfangreicherer Initiativen verwendet werden kann (zum Beispiel für eine größere Anpassung an der technischen Infrastruktur des Service Providers).
SP9: Sicher­stellen v. Compliance	Compliance wird für viele Organisationen immer wichtiger. Aus diesem Grund enthält YaSM einen eigenen Prozess zum Sicherstellen von Compliance mit Gesetzen, Bestimmungen, Industrie­standards usw., in dem die wichtigsten Compliance-Management-Aktivitäten und die Schnittstellen zu den anderen YaSM-Prozessen aufgezeigt sind. Über diesen Prozess wird auch eine bessere Ausrichtung von YaSM auf COBIT und USMBOK erreicht, die beide Abschnitte über die Sicherstellung von Compliance enthalten.
SP10: Managen von Personal-Ressourcen	Kompetenzen und Kompetenzentwicklung sind Bestandteil von mehreren ITIL-Prozessen, aber es wird dort keine klar definierte Verantwortlichkeit für die wichtige Aufgabe des Managens von Personal-Ressourcen genannt. Aus diesem Grund enthält YaSM einen Prozess "Managen von Personal-Ressourcen". Dieser YaSM-Prozess beschreibt nicht alle mit dem Personal-Management in Verbindung stehenden Aspekte, sondern legt den Schwerpunkt eher auf die Entwicklung der Kompetenzen, die der Service Provider für die Erbringung seiner Services benötigt. Durch diesen Prozess wird auch die Übereinstimmung von YaSM mit ISO 20000 und CMMI-SVC verbessert, welche beide eine angemessene Verwaltung der Personal-Ressourcen fordern.

 

ITIL-Funktionen und YaSM

Neben den Prozessen ist in ITIL auch eine Reihe von "Funktionen" beschrieben. So wird das Incident Management beispielsweise als Prozess und das Facilities Management als Funktion eingeführt.

Laut Definition ist eine Funktion eine organisatorische Einheit, häufig charakterisiert durch ein bestimmtes Wissens- oder Erfahrungsgebiet. Beispiele wären die Personalabteilung oder ein Team von Fachleuten, das einen bestimmten Teil der technischen Infrastruktur betreibt.

Im Gegensatz dazu stellen Prozesse eine Gruppe von Aktivitäten dar, die dazu dienen, ein klar definiertes Ergebnis zu erzielen, wie zum Beispiel der Incident-Behebungs-Prozess. In einem Prozess können mehrere Funktionen eine Rolle spielen (das Team von technischen Fachleuten hat vielleicht Aktivitäten innerhalb des Incident-Behebungs-Prozesses durchzuführen).

Die Tatsache, dass in der Realität Funktionen und Prozesse oft identische Bezeichnungen haben, kann leicht zu erheblicher Verwirrung führen. Zum Beispiel führt das Personalmanagement-Team (eine "Funktion") eine Reihe personal­bezogener Aktivitäten durch, die in ihrer Gesamtheit dann als Personalmanagement-Prozess bezeichnet werden.

Um solche Unklarheiten zu vermeiden, besteht YaSM aus einer Reihe von Prozessen, ohne dass auf Funktionen oder organisatorische Strukturen Bezug genommen wird.

Rollen stellen im YaSM-Modell die einzigen organisatorischen Informationen dar: Beispielsweise kommt die Rolle des 1st-Level-Support im Incident-Behebungs-Prozess vor, weil der 1st-Level-Support im Rahmen dieses Prozesses eine Reihe von Aktivitäten durchführen muss. Ungeachtet dessen gehören die Mitarbeiter des 1st-Level-Supports in der Regel zu einer organisatorischen Einheit oder Funktion, z.B. zu einem vom Support-Manager geleiteten Support-Team.

Video: Vergleich von ITIL V3 und YaSM

Video starten: YaSM und ITIL V3

In diesem Video erläutert Stefan Kempter anhand einiger Beispiele die Gemeinsamkeiten und Unterschiede zwischen YaSM und ITIL® V3.

Er zeigt Ihnen, wie das schlanke YaSM-Framework alle wesentlichen Anforderungen im Dienstleistungs-Management erfüllt.

Video ansehen:

• YaSM und ITIL V3 (9:43 Min.)

 

Themenverwandte Artikel

YaSM - eine Alternative zu ITIL® oder ITIL 4?

YaSM - eine Alternative zu ITIL®

Fast sieht es so aus, also ob mancher gerne vermeiden würde, sich mit ITIL zu befassen, und nach Alternativen sucht - aber sollten wir wirklich auf ITIL verzichten?
[ ... Weiterlesen ]

 

Ist YaSM 'ITIL Lite' oder 'Lean ITIL'?

Ist YaSM 'ITIL Lite' oder 'Lean ITIL'?

YaSM ist auf jeden Fall schlanker als ITIL (die Motivation für die Entwicklung von YaSM war ja gerade, dass viele unserer Kunden nach etwas Einfacherem gesucht haben). Trotzdem ist es nicht in unserem Sinne, dass YaSM mit einer leichten Version von ITIL bzw. ITIL 4 oder 'ITIL Lite' gleichgesetzt wird, da solche Ansätze oft zu kurz geraten.
[ ... Weiterlesen ]

 

Literatur

• [Cabinet Office, 2011a]. -- The Cabinet Office: ITIL® Service Strategy (2011 Edition). - The Stationery Office; London, UK, July 2011.
• [Cabinet Office, 2011b]. -- The Cabinet Office: ITIL® Service Design (2011 Edition). - The Stationery Office; London, UK, July 2011.
• [Cabinet Office, 2011c]. -- The Cabinet Office: ITIL® Service Transition (2011 Edition). - The Stationery Office; London, UK, July 2011.
• [Cabinet Office, 2011d]. -- The Cabinet Office: ITIL® Service Operation (2011 Edition). - The Stationery Office; London, UK, July 2011.
• [Cabinet Office, 2011e]. -- The Cabinet Office: ITIL® Continual Service Improvement (2011 Edition). - The Stationery Office; London, UK, July 2011.

Externe Links

• [IT Process Wiki]. -- S. Kempter & Kempter, A.: "IT Process Wiki. -- Das Wiki zur IT Infrastructure Library ITIL® (ITIL 2011, ITIL V3 & V2), ISO 20000 und IT Service Management (ITSM). - IT Process Maps; Lindau (Bodensee), Deutschland.
• [IT Process Wiki - ITIL Service Strategy]. -- S. Kempter: IT Process Wiki, "ITIL Service Strategy (Servicestrategie)". - IT Process Maps; Lindau (Bodensee), Deutschland.
• [IT Process Wiki - ITIL Service Design]. -- S. Kempter: IT Process Wiki, "ITIL Service Design". - IT Process Maps; Lindau (Bodensee), Deutschland.
• [IT Process Wiki - ITIL Service Transition]. -- S. Kempter: IT Process Wiki, "ITIL Service Transition (Serviceüberführung)". - IT Process Maps; Lindau (Bodensee), Deutschland.
• [IT Process Wiki - ITIL Service Operation]. -- S. Kempter: IT Process Wiki, "ITIL Service Operation (Servicebetrieb)". - IT Process Maps; Lindau (Bodensee), Deutschland.
• [IT Process Wiki - ITIL CSI]. -- S. Kempter: IT Process Wiki, "ITIL CSI - Continual Service Improvement (Kontinuierliche Serviceverbesserung)". - IT Process Maps; Lindau (Bodensee), Deutschland.

Anmerkungen

[1] ITIL® ist eine eingetragene Marke von AXELOS Limited. - IT Infrastructure Library® ist eine eingetragene Marke von AXELOS Limited. Die offizielle ITIL-Site: axelos.com/certifications/itil-service-management
[2] In ISO 20000 werden die Service-Management-Prozesse - und weitere Elemente wie z.B. die Service-Management-Richtlinien und -Pläne - als "Service Management System (SMS)" bezeichnet.
[3] COBIT® ist eine eingetragene Marke von ISACA (Information Systems Audit and Control Association).
[4] USMBOK™ ist eine eingetragene Marke von Virtual Knowledge Solutions International Incorporated (VKSII).
[5] CMMI® und Capability Maturity Model® sind eingetragene Marken der Carnegie Mellon University.

Basiert auf: Die YaSM-Prozesslandkarte - Dokument: "YaSM und die IT Infrastructure Library ITIL® V3 (ITIL 2011)".

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

 

Service Strategy  › Service Design  › Service Transition  › Service Operation  › Video: ITIL vs. YaSM