VeriSM und YaSM

 

Vergleich: YaSM und VeriSM™

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

 

YaSM und VeriSM richten sich beide nach bewährten Service-Management "Best Practices", wie sie in ISO 20000, ITIL^®, CMMI-SVC^®, COBIT^® und ähnlichen Frameworks beschrieben werden. Aber sie sind nicht dasselbe:

Während VeriSM™ [1] eine Vorgehensweise für das Managen von Services darstellt, ist YaSM^® ein gut strukturiertes, detailliertes Prozessmodell mit einsatzfertigen Templates für das Service-Management.

 

Abb. 1: VeriSM und YaSM Service-Management
Prozess-Diagramme und Dokument-Templates für VeriSM-Projekte.

Was ist der Unterschied zwischen VeriSM und YaSM?

VeriSM hilft Service-Providern, die Herausforderungen und grundsätzlichen Herangehensweisen im Service-Management zu verstehen. Es zeigt Organisationen, wie sie unterschiedliche Management-Methoden einsetzen können, um ihren Kunden die richtigen Services zur richtigen Zeit anzubieten.

In diesem Sinne bietet VeriSM eine übersichtsartige Beschreibung, wie Services definiert, produziert und erbracht werden, ohne genaue Vorgaben für detaillierte Aktivitäten zu machen.

In der Praxis aber müssen sich Organisationen von einem bestimmten Punkt an mit den Details befassen und ihre Service-Management-Prozesse definieren.

Dies kann eine aufwändige und schwierige Aufgabe sein, die durch das YaSM-Modell einfacher wird:

YaSM beschreibt einen kompletten Satz von Service-Management-Prozessen, einschließlich deren Aktivitäten, Verantwortlichkeiten, Inputs und Outputs, und es stellt einsatzfertige Prozess- und Dokument-Templates zur Verfügung.

Diese Service-Management-Templates gibt es für populäre Anwendungen wie

• Visio^®, Word^®, Excel^®,
• für BIC / BIC Process Design®,
• die ARIS Process Platform™
• sowie im BPMN-XML-Format.

Alle Templates sind vollständig editierbar, damit Organisationen maßgeschneiderte Prozesse entwickeln können, ohne bei null anzufangen.

Hinweis: YaSM wird nicht offiziell von den Herausgebern von VeriSM unterstützt, und YaSM sollte nicht als "VeriSM-Prozessmodell" verstanden werden.

Gibt es Prozesse in VeriSM?

VeriSM beschreibt eine Methode für das Managen von Services, mit der Organisationen auf flexible Weise unterschiedliche Management-Praktiken einsetzen können. Es hat nicht das Ziel, Frameworks wie ITIL^® zu ersetzen.

Deshalb finden sich in VeriSM keine detaillierten Spezifikationen von Prozessen und auch keine Liste von Prozessen, die Organisationen implementieren sollten.

Dennoch erkennt VeriSM an, dass die meisten geschäftlichen Aktivitäten mit sich wiederholenden Aufgaben einhergehen, und dass das Definieren und Dokumentieren von Prozessen einige Vorteile bietet:

• Zum Beispiel erlauben dokumentierte Prozesse einer Organisation, das bevorzugte Vorgehen für bestimmte Aufgaben zu definieren.
• Wiederholbare Prozesse bedeuten höhere Produktivität und weniger Zeitverluste, da nicht immer wieder Vorgehensweisen für gleiche Aufgaben entwickelt werden müssen.
• Schließlich ist es mit definierten Prozessen auch möglich, Kennzahlen zu deren Bewertung zu verwenden, um Potentiale für Verbesserungen zu identifizieren.

Prozesse haben in VeriSM also in jedem Fall ihre Berechtigung.

Es gibt zwar in VeriSM keine explizite Auflistung von Prozessen, aber durchaus Hinweise zwischen den Zeilen:

Zum Beispiel empfiehlt VeriSM, dass Organisationen sich wiederholende Vorkommnisse untersuchen und potenzielle Probleme proaktiv identifizieren. Die Umsetzung dieser Empfehlung in der Praxis bedeutet in der Regel, dass ein Problem-Management-Prozess zu definieren und zu dokumentieren ist. Ein anderes Beispiel ist die Forderung, dass Änderungen ("Changes") kontrolliert werden müssen - was einen Change-Management-Prozess verlangt.

VeriSM-Phasen und entsprechende YaSM-Prozesse

VeriSM beschreibt vier Service-Phasen ("VeriSM stages") auf oberster Ebene: Definieren, Produzieren, Bereitstellen und Reagieren ("Define, Produce, Provide, Respond").

Diese Phasen entsprechen im Wesentlichen dem Service-Lifecycle, der dem YaSM-Modell zugrunde liegt. Deshalb sind die VeriSM-Phasen ein Bereich, in dem VeriSM und YaSM besonders gut zueinander passen.

Die folgende Tabelle zeigt eine Übersicht über die VeriSM-Phasen und die relevanten YaSM Service-Management-Prozesse.

Im Weiteren wird ausführlich dargestellt, wie die YaSM-Prozesse, Dokumente und Templates mit den einzelnen VeriSM-Phasen zusammenhängen, und in welcher Form YaSM detaillierte Empfehlungen für Organisationen bereitstellt, die sich an VeriSM orientieren möchten.

VeriSM™-Phasen und entsprechende Service-Management-Prozesse
VeriSM™-Phase [1]	Relevante Service-Management-Prozesse in YaSM
1 Definieren (Define)	LP1: Festlegen der strategischen Richtung LP2: Designen neuer oder geänderter Services
2 Produzieren (Produce)	LP3: Erstellen neuer oder geänderter Services SP5: Bewerten und Koordinieren von Changes SP11: Managen von Lieferanten und Dienstleistern
3 Bereitstellen (Provide)	LP4: Betreiben der Services LP5: Verbessern der Services SP3: Pflegen der Kunden­beziehungen SP7: Gewährleisten der Sicherheit SP8: Gewährleisten von Kontinuität
4 Reagieren (Respond)	LP4.6: Lösen von Incidents und Service Requests LP4.7: Lösen von Problemen

(Die in dieser Tabelle genannten VeriSM-Phasen basieren auf [IFDC, 2017])

 

VeriSM-Phase 1: Definieren (Define)

Die Definitions-Phase in VeriSM beginnt, wenn ein Kunde einen neuen oder geänderten Service benötigt. Dies löst Aktivitäten zum genauen Spezifizieren der Anforderungen und zum Designen einer geeigneten Service-Lösung aus. Die Definitions-Phase endet mit der Erstellung eines "Service-Blueprints"; hierbei handelt es sich um Konzept mit allen erforderlichen Vorgaben für die anschließende Produktions-Phase.

Die Definitions-Phase im YaSM-Prozessmodell

Im YaSM-Prozessmodell werden neue Services eingeführt bzw. bestehende Services angepasst,

• wenn sich während eines strategischen Assessments abzeichnet, dass ein Service neu eingeführt oder angepasst werden muss,
• oder wenn Kunden Bedarf für einen neuen bzw. geänderten Service anmelden.

Größere Initiativen zur Entwicklung neuer Services werden aus dem strategischen Prozess heraus angestoßen. Weniger umfangreiche ("nicht-strategische") Service-Anpassungen können z.B. vom Customer Relationship Management ausgehen.

Sobald ein genehmigter Business Case vorliegt, werden in einem ersten Schritt grobe Anforderungen ermittelt, z.B. als erster Entwurf der Service-Definition. Diese Informationen gehen als Input in den Service-Design-Prozess, wo der neue Service und das Vorgehen zur Implementierung im Detail spezifiziert werden. Verschiedene andere YaSM-Prozesse sind am Service-Design beteiligt, damit alle relevanten Aspekte des neuen Service berücksichtigt werden, wie z.B. Funktionalität, Verfügbarkeit, Kapazität, Kontinuität, Sicherheit, Compliance, Infrastruktur, unterstützende Services usw.

Die wichtigsten Outputs aus dem Service-Design-Prozess in YaSM sind:

• Die Service-Definition, die die erforderlichen Eigenschaften des neuen oder geänderten spezifiziert,
• das Service-Implementierungs-Konzept: Dies beschreibt, welche Komponenten und Voraussetzungen für den neuen oder geänderten Service erforderlich sind und wie diese geschaffen werden.

Zusammengenommen entsprechen die Service-Definition und das Service-Implementierungs-Konzept in YaSM dem in VeriSM empfohlenen Service Blueprint.

YaSM-Prozesse für die Definitions-Phase

Insbesondere sind zwei YaSM-Prozesse für das Starten von Service-Entwicklungsvorhaben und das Definieren neuer oder geänderter Prozesse zuständig:

• LP1: Festlegen der strategischen Richtung
• LP2: Designen neuer oder geänderter Services

Darüber hinaus unterstützen einige weitere YaSM-Prozesse die Service-Definition, wie z.B.

• SP3: Pflegen der Kundenbeziehungen
• SP7: Gewährleisten der Sicherheit
• SP8: Gewährleisten von Kontinuität
• SP9: Sicherstellen von Compliance

YaSM-Dokumente und -Templates für die Definitions-Phase in VeriSM

Das YaSM-Modell stellt eine Reihe von Templates bzw. Vorlagen für die Dokumente und Records bereit, die in der Definitions-Phase in VeriSM eine Rolle spielen, wie z.B.

• Service-Portfolio
• Service-Definition
• Service-Implementierungs-Konzept
• Register der Sicherheits-Risiken
• Register gemanagter kritischer Ereignisse
• Compliance-Register

VeriSM-Phase 2: Produzieren (Produce)

In der Produktionsphase werden die Service-Komponenten erstellt, getestet und implementiert, gemäß der Vorgaben im Service Blueprint. Die Kontrolle von Changes ist dabei ein wichtiger Aspekt, um die Risiken zu minimieren und unnötige Service-Unterbrechungen zu vermeiden.

Die Produktions-Phase im YaSM-Prozessmodell

Nachdem im Rahmen des Service-Designs das Vorgehen zur Implementierung festgelegt wurde, übernimmt in YaSM der Service-Erstellungsprozess. Dort werden alle notwendigen Voraussetzungen wie z.B. technische Infrastruktur, unterstützende Services, Dokumentation usw. erzeugt, getestet und implementiert.

Welche Aktivitäten genau durchzuführen sind, hängt von der Art der erforderlichen Service-Komponenten ab. Oft sind Anwendungen und Systeme zu beschaffen, zu entwickeln oder zu konfigurieren. Falls unterstützende Services von externen Parteien bereitgestellt werden, müssen die entsprechenden Dienstleister ausgewählt und Verträge abgeschlossen werden.

Alle Service-Komponenten und Implementierungs-Mechanismen müssen, unabhängig von ihrer Art, gründlich gegen das Service-Design getestet werden. Nach erfolgreichem Abschluss der Tests können die Komponenten in die Live-Umgebung ausgerollt werden und der Service ist bereit zur Aktivierung.

Der Change-Management-Prozess unterstützt diese Aktivitäten, um sicherzustellen, dass Changes auf kontrollierte Art und Weise und ohne unbeabsichtigte negative Auswirkungen umgesetzt werden.

Die wichtigsten Outputs aus dem Service-Design-Prozess in YaSM sind:

• Test-Dokumentation
• aktualisierte Konfigurations-Informationen
• das aktualisierte Service-Portfolio mit aktuellen Service-Definitionen
• aktualisierte Prozesse und Richtlinien
• Betriebliche Dokumente, wie z.B. Betriebshandbücher, Incident- und Service-Request-Modelle, Wiederherstellungspläne etc.

YaSM-Prozesse für die Produktions-Phase

Der folgende YaSM-Prozess ist für die Erstellungs-, Test- und Implementierungs-Aktivitäten für neue oder geänderte Services zuständig:

• LP3: Erstellen neuer oder geänderter Services

Darüber hinaus unterstützen einige weitere YaSM-Prozesse die Service-Erstellung, wie z.B.

• SP1: Einrichten und Pflegen des Service-Management-Systems
• SP2: Pflegen des Serviceportfolios
• SP5: Bewerten und Koordinieren von Changes
• SP11: Managen von Lieferanten und Dienstleistern

YaSM-Dokumente und -Templates für die Produktions-Phase in VeriSM

Das YaSM-Modell stellt eine Reihe von Templates bzw. Vorlagen für die Dokumente und Records bereit, die in der Produktions-Phase in VeriSM eine Rolle spielen, wie z.B.

• Service-Definition
• Service-Implementierungs-Konzept
• Service-Portfolio
• Service-Vereinbarung
• Testskript
• Testprotokoll
• Change Record
• Change-Modell
• Change-Planung
• Service-Betriebshandbuch

VeriSM-Phase 3: Bereitstellen (Provide)

In der Bereitstellungs-Phase betreibt der Service-Provider den Service und stellt sicher, dass der Service stets die vereinbarte Leistungsfähigkeit und Funktionalität liefert. In dieser Phase sind auch die Aktivitäten zu Marketing und Vertrieb der angebotenen Services enthalten.

Die Bereitstellungs-Phase im YaSM-Prozessmodell

Die Bereitstellungs-Phase ist im YaSM-Prozessmodell hauptsächlich mit dem Service-Betriebsprozess verbunden, der sicherstellt, dass die Services wirksam und effizient geliefert werden, wie vertraglich vereinbart. Insbesondere werden in diesem Prozess die routinemäßigen betrieblichen Aufgaben durchgeführt. Außerdem werden Service-Qualitätsberichte erstellt, um zu überprüfen, ob die Services die Anforderungen erfüllen.

Des Weiteren sieht YaSM den Service-Verbesserungs-Prozess vor, um Informationen zur Service-Qualität zu sammeln, Potentiale für Verbesserungen zu ermitteln und ggf. korrigierende Maßnahmen zu ergreifen.

Sicherheitsbelange und Anforderungen bezüglich Service-Kontinuität werden in den YaSM-Prozessen für Service-Sicherheit und Kontinuität adressiert.

Marketing-Aktivitäten finden vor allem im YaSM-Prozess für das Managen der Kundenbeziehungen statt, der für die Akquise neuer Kunden und das Pflegen bestehender Kundenbeziehungen zuständig ist.

Die wichtigsten Outputs aus den Bereitstellungs-Prozessen in YaSM sind:

• Service-Qualitätsberichte
• Identifizierte Bereiche, in denen Korrekturmaßnahmen erforderlich sind
• aktualisierte Service-Definitionen und betriebliche Dokumente
• aktualisierte Konfigurations-Informationen

YaSM-Prozesse für die Bereitstellungs-Phase

Die folgenden YaSM-Prozesse sind zuständig für das Betreiben und eventuelle Verbessern der Services:

• LP4: Betreiben der Services
• LP5: Verbessern der Services

Darüber hinaus unterstützen einige weitere YaSM-Prozesse die Service-Bereitstellung, wie z.B.

• SP3: Pflegen der Kundenbeziehungen
• SP7: Gewährleisten der Sicherheit
• SP8: Gewährleisten von Kontinuität

YaSM-Dokumente und -Templates für die Bereitstellungs-Phase in VeriSM

Das YaSM-Modell stellt eine Reihe von Templates bzw. Vorlagen für die Dokumente und Records bereit, die in der Bereitstellungs-Phase in VeriSM eine Rolle spielen, wie z.B.

• Service-Betriebshandbuch
• Service-Definition
• Service-Portfolio
• Service-Qualitätsbericht
• Service-Vereinbarung
• Service-Verbesserungsplan
• Kunden-Portfolio
• Register der Sicherheits-Risiken
• Register gemanagter kritischer Ereignisse

VeriSM-Phase 4: Reagieren (Respond)

In der Reaktions-Phase behandelt der Service-Provider Vorkommnisse ("Incidents"), die von Kunden gemeldet werden, sowie Service Requests und sonstige Anfragen.

Die Reaktions-Phase im YaSM-Prozessmodell

Das YaSM-Prozessmodell umfasst einen speziellen Prozess für das Beheben von Service-Unterbrechungen ('Service Incidents') und das Bearbeiten von Service-Aufträgen ('Service Requests'). Dieser beinhaltet die erforderlichen Schritte zum Erfassen von Informationen über die berichteten Vorfälle, sowie zu deren Klassifizierung, Lösung und Schließung. Der Prozess stellt auch sicher, dass die Kunden stets über den Status offener Fälle auf dem Laufenden gehalten werden.

Relevante Erkenntnisse, die während der Bearbeitung von Vorfällen und Anfragen gewonnen worden sind, werden zu einer Knowledge Base hinzugefügt, oft in Form von Incident- und Service-Request-Modellen.

Die Untersuchung von sich wiederholenden Vorfällen ("Problemen") und die proaktive Identifikation potentieller Service-Beeinträchtigungen liegt in der Verantwortung des Problem-Management-Prozesses.

Die wichtigsten Outputs aus diesen Prozessen in YaSM sind:

• Aufzeichnungen (Records) über gemeldete Incidents und Service Requests
• Modelle (Templates) für die Bearbeitung von Incidents und Service Requests
• Aufzeichnungen (Records) über identifizierte Probleme

YaSM-Prozesse für die Reaktions-Phase

Die folgenden YaSM-Prozesse sind zuständig für das Bearbeiten von Kunden-Anfragen, Vorfällen, Aufträgen etc.:

• LP4.6: Lösen von Incidents und Service Requests
• LP4.7: Lösen von Problemen

YaSM-Dokumente und -Templates für die Reaktions-Phase in VeriSM

Das YaSM-Modell stellt eine Reihe von Templates und Checklisten für die Dokumente und Records bereit, die in der VeriSM Reaktions-Phase eine Rolle spielen, wie z.B.

• Incident Record (vgl. auch: Checkliste 'Incident Record' hier im Wiki)
• Incident-Modell
• Service Request Record
• Service-Request-Modell
• Problem Record

Andere VeriSM-Elemente und YaSM

Das VeriSM-Management-Mesh

Das "Management Mesh" in VeriSM (in etwa: "Management-Gitter" oder "Management-Geflecht") umfasst Ressourcen, Umgebung, Management-Methoden und Technologien, die in der Organisation eingesetzt werden.

Das Management Mesh bietet Flexibilität, damit Organisationen je nach Erfordernis aus einer Reihe von Management-Praktiken, Technologien usw. die für sie geeigneten auswählen können.

Das YaSM-Modell unterstützt Organisationen dabei, die etablierten Service-Management "Best Practices" in ihr Management Mesh zu integrieren. Dazu stellt YaSM schlüssige, klar strukturierte Prozesse und Templates bereit, die auf bewährten Standards wie ITIL^®, ISO 20000, CMMI-SVC^® und COBIT^® beruhen.

Service-Management-Prinzipien

VeriSM empfiehlt, dass Organisationen ihre Service-Management-Grundsätze bzw. -Prinzipien formulieren, so dass diese als "Leitplanken" (Guardrails) für ihre Service-Teams fungieren.

Eine gute Ausgangsbasis für das Aufstellen solcher Prinzipien sind die bewährten Service-Management-Frameworks wie ITIL^®, CMMI-SVC^® und COBIT^®, und auch die Anforderungen aus ISO 20000, dem internationalen Standard für Service-Management.

Da sich das YaSM-Modell an diesen Frameworks und Standards orientiert, bietet es eine solide Basis für Organisationen, die ihr Service-Management auf tragfähigen Grundsätzen aufbauen möchten.

Governance

VeriSM beschreibt Governance ("Führung") als ein System, mit dessen Hilfe Organisationen gesteuert und kontrolliert werden. Zu den wichtigsten Gesichtspunkten angemessener Führung ("Good Governance") gehören Transparenz, Verantwortung, Reaktionsfähigkeit, Wirksamkeit und Effizienz.

Die Basis von Good Governance sind zweckmäßige Richtlinien und klar definierte Prozesse, für die das YaSM-Prozessmodell einsatzfertige Templates bereithält.

Manche Organisationen wählen den Weg einer Zertifizierung gemäß ISO 20000, um ihre Governance dauerhaft zu verbessern.

Dies wird durch die YaSM - ISO 20000 Bridge unterstützt, die die Service-Management-Prozesse mit dem ISO 20000 Standard verknüpft und somit eine Lösung für jede einzelne Anforderung beschreibt.

Progressive Management-Praktiken

VeriSM erkennt an, dass zahlreiche Organisationen neben "traditionellen" Leitlinien zum Service-Management mittlerweile auch "progressive" Praktiken verwenden, um besser zu arbeiten und flexibler zu werden. Diese Praktiken haben oft ihren Ursprung in anderen Bereichen wie z.B. der Produktionstechnik und Software-Entwicklung, und umfassen Methoden wie z.B. DevOps, Agile, Kanban, Lean usw.

In der Regel bieten die progressiven Management-Methoden keine detaillierten Empfehlungen wie z.B. genaue Spezifikationen von durchzuführenden Aktivitäten. Sie beschreiben vielmehr

• Prinzipien,
• Management-Techniken,
• Vorgehensweisen,
• Werte,
• und sogar Philosophien.

DevOps führt zum Beispiel das Konzept von funktionsübergreifenden Teams ein, die einen Service über den ganzen Lebenszyklus hinweg managen. Außerdem legt es den Schwerpunkt auf automatisiertes und häufiges Deployment, unterstützt durch Technologien wie Virtualisierung und Containerization. DevOps ist damit weniger eine Alternative zu den bewährten Service-Management-Empfehlungen, sondern eine Quelle für das Gestalten besserer, schlankerer Prozesse.

Da es keine feststehende Liste "progressiver" Management-Praktiken gibt und nachdem für jede Organisation individuelle Anforderungen gelten, ist das YaSM-Prozessmodell nicht speziell an diesen Praktiken ausgerichtet. Das YaSM-Modell beschreibt jedoch schlanke, schlüssige Prozesse und stellt entsprechende Templates bereit. Organisationen sind somit flexibel, wenn es darum geht, unterschiedliche Ansätze wie DevOps und Agile in ihre Service-Management-Abläufe einzubauen.

Themenverwandte Artikel

Was ist VeriSM™ - 'Value-driven, Evolving, Responsive, Integrated, Service Management'

Was ist VeriSM™ - 'Value-driven, Evolving, Responsive, Integrated, Service Management'?

Eine kurze Einführung in den VeriSM Service-Management-Ansatz: [ ... Weiterlesen ]

 

Referenzen

[1] IFDC (International Foundation for Digital Competences) (2017). VeriSM™ - A Service Management Approach for the Digital Age. Zaltbommel, Niederlande: Van Haren Publishing.

Anmerkungen

[1] VeriSM™ ist eine eingetragene Marke von IFDC.
[2] ISO/IEC 20000® ist eine eingetragene Marke von ISO.
[3] ITIL® ist eine eingetragene Marke von AXELOS Limited.
[4] CMMI® und Capability Maturity Model® sind eingetragene Marken der Carnegie Mellon University.
[5] COBIT® ist eine eingetragene Marke von ISACA.

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

 

Vergleich: VeriSM und YaSM  › Gibt es VeriSM-Prozesse?  › VeriSM-Phasen und entsprechende Prozesse