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.
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 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.
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.
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.
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).
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.
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.
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.
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 Kundenbeziehungen" 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.
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.
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.
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 Vorsorgemaßnahmen beschlossen hat, in einem Register gemanagter kritischer Ereignisse zu dokumentieren.
Service-Kontinuitäts-Pläne beschreiben, wie die Servicekontinuität bei bestimmten Arten von kritischen Ereignissen 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 disruptiver Ereignisse 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.
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 "Managementsystems 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 einschließlich der vorgesehenen Risikobewältigungsmaßnahmen sind im Register der Sicherheitsrisiken dokumentiert. Die Implementierung der Sicherheitsvorkehrungen 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.
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 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 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.
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.
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-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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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-Verbesserungsplan unter der Federführung des Service- bzw. Prozessverantwortlichen implementiert.
ITIL bietet zusätzliche Hintergrundinformationen, insbesondere in Bezug auf Methoden der Problemanalyse.
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.
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".
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
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.
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).
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.
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 V3 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.
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? [...]
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. [...]
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 Operation]. -- S. Kempter: IT Process Wiki, "ITIL Service Operation (Servicebetrieb)". - IT Process Maps; Lindau (Bodensee), Deutschland.
[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.
und Stefan Kempter 
