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 der IT Infrastructure Library ITIL^® [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.

 

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 IT Process 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	Relevante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
1.1 Strategie-Management für IT-Services	LP1: Festlegen der strategischen Richtung	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 Implementierung der Servicestrategie beschrieben sind. ITIL bietet zusätzliche Hilfestellung und Hintergrundinformationen, beispielsweise zum Thema Analysieren der internen und externen Rahmenbedingungen und Definieren der Position des Service Providers auf den anvisierten Märkten.
1.2 Service Portfolio Management	LP1: Festlegen der strategischen Richtung SP2: Pflegen des Serviceportfolios	Sowohl ITIL als auch YaSM sehen vor, dass alle vom Service Provider erbrachten Kunden- und unterstützenden Services über das Serviceportfolio verwaltet werden sollen. Der YaSM-Prozess zur Pflege des Serviceportfolios ist jedoch etwas enger gefasst als der Serviceportfolio-Management-Prozess in ITIL. Der YaSM-Prozess befasst sich in erster Linie mit der Steuerung von Änderungen am Serviceportfolio, um dessen Vollständigkeit und Konsistenz sicherzustellen, sowie ggf. mit der Erstellung von Servicekatalogen. Entscheidungen über die Zusammensetzung des Serviceportfolios (d.h. des Service-Mix, der dem Kunden angeboten wird) gehören bei YaSM in den Zuständigkeitsbereich des strategischen Prozesses.
1.3 Financial Management 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 Management	-/-	In YaSM ist kein separater Demand-Management-Prozess definiert. Stattdessen wird beschrieben, welchen Beitrag verschiedene YaSM-Prozesse zur Sicherstellung eines ordnungsgemäß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ätsmustern (Patterns of Business Activity).
1.5 Business Relationship Management	SP3: Pflegen der Kundenbeziehungen	Der YaSM-Prozess zum Pflegen der Kundenbeziehungen orientiert sich weitgehend an den ITIL-Empfehlungen. Er wird für die Pflege einer guten Geschäftsbeziehung zwischen dem Service Provider und dem Kunden herangezogen und soll sicherstellen, dass die Kundenbedürfnisse verstanden werden. Dazu gehören die regelmäßige Kommunikation mit den Kunden, das Messen der Kundenzufriedenheit und die Bearbeitung von Kundenbeschwerden.

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	Relevante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
2.1 Design-Koordinierung	LP2: Designen neuer oder geänderter 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-Entwicklungsprojekte 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 Bereitstellung eines neuen oder geänderten Services erforderlich sind. Außerdem ist dort die Vorgehensweise 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 Catalogue Management	SP2: Pflegen des Serviceportfolios	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 gleichbedeutend 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 Aktualisierungen des Serviceportfolios stets auf dem neuesten Stand und in sich stimmig sind.
2.3 Service Level Management	LP2: Designen neuer oder geänderter Services LP4: Betreiben der Services LP5: Verbessern der Services SP3: Pflegen der Kundenbeziehungen	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 Servicefunktionalität - werden auf der Grundlage der Kundenbedü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. Korrekturmaß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 Servicefunktionen (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.
2.4 Availability Management	LP2: Designen neuer oder geänderter Services LP3: Erstellen neuer oder geänderter Services LP4: Betreiben der Services LP5: Verbessern der Services	Sowohl bei YaSM als auch bei ITIL ist vorgesehen, dass die Serviceverfügbarkeit gemanagt wird, jedoch gibt es in YaSM keinen gesonderten Availability-Management-Prozess. Stattdessen wird die Serviceverfü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 Verantwortungsbereich des Betriebsprozesses. Für den Fall, dass eine Verbesserung der Serviceverfügbarkeit notwendig ist, kann der Service-Verbesserungs-Prozess aktiv werden und mit Hilfe von Service-Verbesserungsplänen Korrekturmaßnahmen anstoßen. Die ITIL-Bücher bieten zusätzliche Empfehlungen, beispielsweise dahingehend, wie das Design der Services und der zugrundeliegenden technischen Infrastruktur im Hinblick auf die Serviceverfügbarkeit zu gestalten ist.
2.5 Capacity Management	LP2: Designen neuer oder geänderter Services LP3: Erstellen neuer oder geänderter Services LP4: Betreiben der Services LP5: Verbessern 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ätsanpassung oder eine Verbesserung der Performance notwendig ist, kann der Service-Verbesserungs-Prozess aktiv werden und mit Hilfe von Service-Verbesserungsplänen Korrekturmaß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.
2.6 IT Service Continuity Management (ITSCM)	SP8: Vorbereiten auf Katastrophen-Ereignisse	Beide Prozesse ("ITSCM "in ITIL und "Vorbereiten auf Katastrophen-Ereignisse" in YaSM) befassen sich in erster Linie mit Ereignissen, die als ausreichend wichtig eingestuft werden, um als "Katastrophe" zu gelten. YaSM empfiehlt, Katastrophen, für die der Service Provider Vorsorgemaßnahmen beschlossen hat, in einem Register gemanagter Katastrophen-Ereignisse zu dokumentieren. Service-Kontinuitäts-Pläne beschreiben, wie die Servicekontinuität bei bestimmten Arten von Katastrophen sichergestellt werden soll. Die Implementierung der erforderlichen Kontinuitätsvorkehrungen 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 Katastrophenfälle zuständig. Dieser Prozess sieht die Bildung eines Major-Incident-Teams vor, das die Berechtigung hat, geeignete Service-Kontinuitätspläne zu aktivieren. ITIL gibt zusätzliche Empfehlungen, wie Beispiele zu möglichen Risiken und Gefahren sowie Optionen zur Wiederherstellung von Systemen.
2.7 Information Security Management	SP7: Gewährleisten der Sicherheit	Der YaSM-Prozess zur Gewährleistung der Sicherheit bezieht sich nicht speziell auf Informationssicherheit, da es sich bei YaSM ja um ein Konzept handelt, das sich auf alle Arten von Organisationen, die Dienstleistungen erbringen, anwenden lässt (d.h. nicht nur auf Service Provider im IT-Bereich). ITIL empfiehlt die Einrichtung eines "Management-systems für Informationssicherheit (Information Security Management System, ISMS)", das ein "Informationssystem für Sicherheitsmanagement (Security Management Information System, SMIS)" beinhaltet. YaSM beschreibt und dokumentiert die Verfahren des Security Management im Rahmen seines Prozessmodells sowie über eine Reihe von Sicherheitsrichtlinien. Die zu managenden Sicherheitsrisiken ein-schließlich der vorgesehenen Risikobewältigungsmaß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) Sicherheitsrichtlinien sowie einen Überblick über die Methoden der Risikoabschätzung und des Risikomanagements.
2.8 Supplier Management	SP11: Managen von Lieferanten und Dienstleistern	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 unterstü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ätsberichten zuständig. Dazu gehört auch die Überwachung der extern erbrachten unter-stü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 Serviceverbesserungen 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	Relevante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
3.1 Transition 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ührungsprojekten 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 Management	SP5: Bewerten und Koordinieren von 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 sicherzustellen, 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-Projekt-management-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 Configuration Management	SP4: Verwalten von Konfigurations-Informationen	Der in YaSM beschriebene Konfigurationsmanagement-Prozess orientiert sich an den ITIL-Empfehlungen, jedoch mit folgenden Einschränkungen: Der YaSM-Prozess zum Verwalten von Konfigurationsinformationen bietet den Rahmen für das Kontrollieren der Konfigurationselemente (Configuration Items, CIs) und der zugehörigen Konfigurationsinformationen. 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-Konfigurationsmanagement-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 Deployment Management	LP3: Erstellen neuer oder geänderter 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 sicher-gestellt, dass alle benötigten Servicekomponenten vor dem Ausrollen getestet werden und dass im CMS enthaltene Konfigurationsinformationen 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-Validierung und -Test	LP3: Erstellen neuer oder geänderter 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 Korrekturmaß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-Evaluierung	SP5: Bewerten und Koordinieren von 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 Knowledge Management	-/-	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	Relevante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
4.1 Event Management	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 Management	LP4.6: Lösen von Incidents und 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 schnellstmögliche Wiederherstellung 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 Fulfillment	LP4.6: Lösen von Incidents und 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 Management	LP4.7: Lösen von Problemen	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 zugrundeliegenden Ursachen und einem Workaround" handelt, empfiehlt YaSM, Informationen über zugrundeliegende 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-Verbesserungsplan unter der Federführung des Service- bzw. Prozessverantwortlichen implementiert. ITIL bietet zusätzliche Hintergrundinformationen, insbesondere in Bezug auf Methoden der Problemanalyse.
4.5 Access Management	LP4: Betreiben der Services SP7: Gewährleisten der Sicherheit	YaSM enthält keinen speziellen Access-Management-Prozess, sondern der Servicebetriebs-Prozess deckt die Aktivitäten zur Konfigurierung der Zugriffskontrollsysteme 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 Sicherheitsrichtlinie 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	Relevante YaSM-Prozesse	Vergleich: YaSM und ITIL V3 (ITIL 2011)
5.1 Verbesserungs-Prozess in sieben Schritten	LP5: Verbessern der Services	Der in den ITIL-Büchern vorgestellte "Verbesserungsprozess 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 und Pflegen des Service-Management-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: Sicherstellen von 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, Industriestandards 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 personalbezogener 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® und YaSM

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® (9:43 Min.)

Themenverwandte Artikel

YaSM - eine Alternative zu ITIL®?

von: Stefan Kempter

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

 

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

von: Stefan Kempter

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 oder 'ITIL Lite' gleichgesetzt wird, da solche Ansätze oft zu kurz geraten. [...]

 

Initiative von AXELOS: ITIL® auch für Nicht-IT-Dienstleister

von: Stefan Kempter

AXELOS will den Einsatz von ITIL® in Non-IT-Bereichen fördern: Nicht nur IT-Service-Provider, sondern Dienstleister aller Branchen sollen von ITIL profitieren. [...]

 

 

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/best-practice-solutions/itil
[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