Einführung: YaSM-Prozesslandkarte

     

Video auf YouTube ansehen | Transkript lesen.

 

Prozess- und Dokument-Templates für Enterprise Service-Management- und ITSM-Vorhaben: Eine kurze Einführung in die Struktur und Inhalte des YaSM-Prozessmodells.

Für Service-Provider, die YaSM und Service-Management Best-Practice praktisch einführen möchten, gibt es die "YaSM®-Prozesslandkarte": Ein detailliertes YaSM-Referenzmodell mit sofort einsetzbaren Prozessdiagrammen und Dokument-Vorlagen. Das Modell wird zur Implementierung von ESM- und ITSM-Prozessen eingesetzt.

Ressourcen und weitere Informationen

Weitere Videos
Themenverwandte Seiten

Video-Transkript

Hallo! Ich bin Stefan Kempter, und in diesem kurzen Video stelle ich Ihnen die YaSM®-Prozesslandkarte vor: Ein Satz von Prozessdiagrammen und Dokumentvorlagen für Organisationen, die beim Thema YaSM ernst machen wollen.

Die Diagramme und Templates sind das ideale Tool, wenn es darum geht, Service-Management Best-Practice richtig zu verstehen. Sie sparen Ihnen eine Menge Zeit und Arbeit beim Designen und Dokumentieren der Service-Management-Prozesse in Ihrer Organisation.

Die YaSM®-Prozesslandkarte gibt es in Deutsch und Englisch für Visio® und ARIS™

Sie können das YaSM-Prozessmodell in Form von Visio-Diagrammen erhalten oder auch als komplettes ARIS-Prozessmodell. Die Inhalte sind immer genau gleich.

Da Microsoft Visio sehr populär ist, zeige ich Ihnen heute die YaSM®-Prozesslandkarte in Visio.

Zunächst allerdings habe ich hier einige Folien, mit denen ich Ihnen das Grundprinzip hinter unserem Produkt erläutern möchte. Dies ist ganz einfach:

Wie ist das Service-Management-Prozessmodell aufgebaut?

Die YaSM®-Prozesslandkarte ist eine Sammlung von Prozess-Diagrammen, und diese sind hierarchisch in mehreren Detail-Ebenen in Form einer Pyramide angeordnet:

  • An der Spitze der Pyramide befindet sich ein Diagramm ("Top-Level-Diagramm") mit der kompletten Übersicht über die YaSM-Prozesse. Das ist der Haupt-Einstiegspunkt in das Prozessmodell: Von hier können wir einfach per Hyperlink zu den weiteren Detailebenen hinabsteigen.
  • Auf der zweiten Ebene finden wir dann 17 Diagramme - eines für jeden YaSM-Hauptprozess, wie z.B. ein Diagramm für das "Service Design".
  • Von der Hauptprozess-Ebene können wir weiter zu den Ebenen 3 und 4 mit den Sub-Prozessen gehen, wo wir schließlich Swimlane-Diagramme mit einzelnen Aktivitäten zu sehen bekommen. Hier erklären wir also sehr detailliert, wer was und in welcher Reihenfolge zu tun hat.

Alles in allem enthält das YaSM-Prozessmodell ungefähr 120 Prozessdiagramme.

Und jetzt gehen wir hinüber nach Visio, um uns anzuschauen, wie wir das Ganze in Form von Visio-Diagrammen umgesetzt haben.

Top-Level-Diagramm: Service-Lifecycle- und unterstützende Service-Management-Prozesse

Was wir hier zunächst sehen ist das "Top-Level-Diagramm" mit einer kompletten Übersicht über die YaSM-Prozesse.

Oben befinden sich die Service-Lifecycle-Prozesse

  • für das Erarbeiten der Service-Strategie,
  • für das Designen,
  • Implementieren
  • und Betreiben der Services
  • sowie für die kontinuierliche Service-Verbesserung.

Unterhalb des Service-Lifecycles befinden sich die unterstützenden Service-Management-Prozesse, zum Beispiel

  • zum Bewerten und Koordinieren von Changes
  • oder zum Managen von Projekten.

Übersichts-Diagramme für jeden YaSM-Hauptprozess

Wenn wir jetzt genauer wissen möchten, was sich im Service-Betrieb abspielt, dann nehmen wir von hier einen Link und gehen hinunter zur nächsten Detail-Ebene. Dort finden wir ein Übersichts-Diagramm mit mehr Details über den Service-Betrieb.

Wir zoomen gleich hinein, aber zunächst möchte ich hier erläutern, dass wir

  • auf der linken Seite in diesen Diagrammen immer die "Inputs" zu sehen bekommen: Links sehen wir also die anderen YaSM-Prozesse und die Inputs, die diese Prozesse in den Service-Betrieb hineinschicken.
  • Rechts haben wir die "Outputs" vom Service-Betrieb und wo sie hingehen,
  • und in der Mitte sind die Prozesse vom Service-Betrieb zu sehen, wie z.B. die bekannten Prozesse zum Bearbeiten von Incidents und Serviceaufträgen, und die zum Behandeln von Problemen.

Die Informationsflüsse im YaSM-Prozessmodell

Wir verwenden in diesen Diagrammen zwei Arten von Shapes: Die grünen Shapes repräsentieren Prozesse, und die orangefarbenen Shapes sind Daten- bzw. Informationsobjekte.

Mit den Informationsobjekten stellen wir die Informationsflüsse zwischen den Prozessen dar - und das ist ein wichtiges Prinzip in unseren Diagrammen: Denn wir wollen Ihnen nicht nur zeigen, welche Prozesse es in YaSM gibt, sondern auch, wie die Prozesse zusammenspielen.

Hier z.B. sehen wir, dass das "Incident Management" alle "Incident Records" ans "Problem Management" schickt, wo sie weiter analysiert werden. Falls der Problem Manager daraufhin ein Problem entdeckt und einen "Workaround" für wiederholt auftretende Incidents bereitstellen kann, dann wird ein "Problem Record" mit einer Beschreibung des Workarounds ans Incident Management zurückgeschickt - wo der Workaround bei der Lösung künftiger Incidents hilft.

Auf diese Weise zeigen wir Ihnen also, wie Incident und Problem Management zusammenspielen - und wie es in YaSM funktioniert.

Man kann darüber hinaus auf solche Shapes, wie z.B. das Prozess-Shape hier klicken, und dann sieht man - auf der rechten Seite - in einem "Shape-Daten-Fenster", dass für solche Shapes Felder definiert sind: Der Prozess hat z.B. nicht nur ein Namens-Feld, sondern direkt darunter auch eine kurze Beschreibung.

Dasselbe funktioniert auch für die Datenobjekte: Wenn ich auf den Incident Record klicke, dann können Sie im Shape-Daten-Fenster sehen, dass das Objekt einen Namen hat und ebenfalls eine kurze Beschreibung.

Diese Kurz-Beschreibung ist schon einmal ganz schön, aber man kann natürlich eine Menge mehr über einen Incident Record sagen! Deshalb sind solche Datenobjekte in vielen Fällen mit sogenannten Checklisten verknüpft.

Checklisten und Dokument-Vorlagen

Die YaSM-Checklisten sind Word™-Dokumente, und man kann sie von hier aus mit einem Link öffnen.

Wenn ich auf den Link klicke, sehen wir auch gleich die Checkliste für den Incident Record: Diese erläutert den Incident Record im Detail und zeigt eine Struktur der Daten, die wir typischer Weise in einem solchen Record erwarten würden.

In der YaSM®-Prozesslandkarte gibt es ca. 100 solcher Checklisten, z.B. auch eine für die "Service-Definition". Da es sich um Word™-Dokumente handelt, die Sie ändern können, können Sie die Checkliste für die Service-Definition als Vorlage oder Ausgangsbasis verwenden, wenn Sie solche Dokumente in Ihrer Organisation erstellen müssen.

Damit schließen wir die Checkliste wieder ... und zurück in Visio schauen wir uns jetzt noch an, was hinter dem zweiten Link des Datenobjekt-Shapes steckt.

Objekt-Lifecycle-Diagramme

Der zweite Link öffnet das Objekt-Lifecycle-Diagramm für den Incident Record, in dem wir sehen, wo - in welchen YaSM-Prozessen - solche Records

  • erstellt,
  • bearbeitet,
  • gelesen
  • und archiviert werden.

Die Lifecycle-Diagramme bieten Ihnen also die vollständige Übersicht auf einen Blick, indem sie darstellen, wie die Dokumente und Records zwischen den YaSM-Prozessen fließen.

Details zum Incident-Management-Prozess

So, und jetzt gehen wir weiter in die Prozess-Details, z.B. weiter hinein in den Prozess für die "Bearbeitung von Incidents und Service Requests".

Wieder klicken wir auf den Link, und es öffnet sich ein Diagramm, in dem dargestellt wird, wie wir in YaSM mit "Incidents" und "Service Requests" umgehen. Wie schon zuvor sind links die Inputs, rechts die Outputs, und in der Mitte haben wir nun eine Übersicht über die Sub-Prozesse vom Incident Management.

Der erste Sub-Prozess stellt sicher, dass alle Incidents und Serviceaufträge erfasst werden, und die anderen kümmern sich darum, dass Incidents und Serviceaufträge bearbeitet werden.

Was die Incidents betrifft, so gibt es

  • einen Prozess speziell zur Behebung von Major Incidents
  • und einen weiteren zur Behebung der Incidents im 1st-Level-Support.
  • Wenn der 1st-Level-Support nichts ausrichten kann, dann gehen die Incidents weiter zu den Spezialisten im 2nd-Level-Support.
  • Schließlich werden alle Incidents und Service Requests (hier unten) formal geschlossen, wenn sie gelöst sind.

Dieses Diagramm zeigt uns also schon einmal die gröberen Schritte, die zum Bearbeiten von Incidents und Service Requests erforderlich sind, und von hier können wir jetzt noch einmal weiter nach unten gehen: Zur untersten Detailebene, die in der YaSM®-Prozesslandkarte enthalten ist.

Flowchart-Diagramme und Darstellung der Aktivitäten

Auf der untersten Detailebene sehen die Diagramme jetzt ein bisschen anders aus:

  • Im oberen Teil des Diagramms sind links die ganzen Inputs zu sehen, die der Prozess benötigt, und wo die Inputs herkommen. Rechts sind die ganzen Outputs dargestellt - und wo sie hingehen.
  • Im unteren Teil des Diagramms sehen wir eine Swimlane mit Aktivitäten.

Swimlanes werden verwendet, um Verantwortlichkeiten zuzuweisen: Die gelben Shapes in den Swimlanes sind "YaSM-Rollen", die anzeigen, wer die Aktivitäten in der Swimlane durchzuführen hat.

Wahrscheinlich ist es nun fast selbsterklärend, was dieses Diagramm hier aussagt:

  • Der 1st-Level-Support soll zunächst eine Erstanalyse durchführen,
  • die Knowledge Base durchsuchen
  • und den Incident - wenn möglich - bestehenden anderen Incidents oder Problems zuordnen.

Nach diesen Anfangs-Aktivitäten ist eine Entscheidung fällig: Wir müssen uns entscheiden, ob wir den Incident im 1st-Level-Support lösen können oder nicht. Diese Entscheidung hat einige mögliche Ausgänge:

  • Erstens könnte es sein, dass wir im 1st-Level-Support nichts erreichen können: Dann wird der Incident an den 2nd-Level-Support übergeben.
  • Oder wir können tatsächlich die Ursache des Incidents beheben - das wäre ideal!
  • Wenn das nicht geht, dann haben wir vielleicht einen Workaround verfügbar ...
  • ... oder eine Idee für einen neuen Workaround. In diesem Falle wird der neue Workaround angewendet
  • ... und so weiter ...
  • ... bis der Prozess hier schließlich auf der rechten Seite endet.

In diesem Fall gibt es zwei Endpunkte für den Prozess:

  • Entweder wir haben den Incident gelöst - durch Behebung der Ursache oder durch Anwendung eines Workarounds.
  • Etwas weiter oben sehen wir den zweiten Endpunkt: Wenn wir den Incident nicht beheben konnten, dann haben wir ihn an den 2nd-Level-Support übergeben.

Und wenn wir jetzt wissen möchten: Wie geht’s hier weiter? Was passiert im 2nd-Level-Support? Dann gehen wir wieder in den oberen Bereich dieses Diagramms:

  • Dort finden wir den Incident Record, wie er an den 2nd-Level-Support-Prozess übergeben wird,
  • und mit dem Link hier können wir dann direkt in den nachfolgenden Prozess springen und sehen, wie es im 2nd-Level-Support weitergeht.

Überblick: Die Bestandteile der YaSM®-Prozesslandkarte

Und das ist, was ich Ihnen heute in dieser kurzen Einführung zeigen wollte. Um es kurz zu machen, haben wir uns auf die wichtigsten Komponenten in der YaSM®-Prozesslandkarte beschränkt:

  • Die YaSM-Prozessdiagramme
  • und die Dokumentvorlagen.

Außerdem gibt es in unserem Produkt auch

  • eine RACI-Matrix,
  • das YaSM-Datenmodell,
  • ein Excel®-Repository,
  • und (als optionale Komponente) die "YaSM - ISO 20000 Bridge": Ein Satz von Diagrammen speziell für Organisationen, die sich nach ISO 20000 zertifizieren lassen möchten.

Weiter in die Details gehen wir hier jetzt aber nicht, denn zu diesen Komponenten haben wir weitere Videos vorbereitet.

Support

Wenn Sie eine Lizenz erwerben, dann gibt es dazu auch Support: Darin enthalten sind

  • Updates,
  • Antworten auf Fragen zu YaSM
  • und technischer Support.

Dieser Service ist während des ersten Jahres kostenfrei.

So viel für heute. Wenn Sie mehr über die YaSM®-Prozesslandkarte erfahren möchten oder Fragen an uns haben, wenden Sie sich einfach direkt an uns! Vielen Dank für's Zusehen - und bis dann!

 

Home      YaSM-Videos      Einführung in die YaSM-Prozesslandkarte