WEBVTT
Kind: captions
Language: de

00:00:00.640 --> 00:00:02.380
Hallo!
Ich bin Stefan Kempter,

00:00:02.380 --> 00:00:05.980
und in diesem kurzen Video stelle ich Ihnen
die YaSM®-Prozesslandkarte vor:

00:00:05.980 --> 00:00:09.200
Ein Satz von
Prozessdiagrammen und Dokumentvorlagen

00:00:09.200 --> 00:00:13.260
für Organisationen,
die beim Thema YaSM ernst machen wollen.

00:00:13.760 --> 00:00:16.640
Die Diagramme und Templates
sind das ideale Tool,

00:00:16.640 --> 00:00:17.620
wenn es darum geht,

00:00:17.620 --> 00:00:20.780
Service-Management Best Practice
richtig zu verstehen,

00:00:21.160 --> 00:00:23.700
und sie sparen Ihnen eine Menge
Zeit und Arbeit

00:00:23.700 --> 00:00:25.380
beim Designen und Dokumentieren

00:00:25.400 --> 00:00:28.660
der Service-Management-Prozesse
in Ihrer Organisation.

00:00:29.780 --> 00:00:33.410
Die YaSM®-Prozesslandkarte gibt es zurzeit
• in Deutsch und Englisch

00:00:33.410 --> 00:00:36.430
für zwei Plattformen:
• Visio® und ARIS™.

00:00:36.980 --> 00:00:41.280
Das heißt, Sie können das Prozessmodell
in Form von Visio-Diagrammen erhalten

00:00:41.290 --> 00:00:43.710
oder auch als komplettes
ARIS-Prozessmodell.

00:00:44.240 --> 00:00:46.500
Die Inhalte sind immer genau gleich.

00:00:47.280 --> 00:00:49.040
Da Microsoft Visio
sehr populär ist,

00:00:49.040 --> 00:00:52.400
zeige ich Ihnen heute die
YaSM®-Prozesslandkarte in Visio.

00:00:53.200 --> 00:00:55.640
Zunächst allerdings
habe ich hier einige Folien,

00:00:55.649 --> 00:00:59.469
mit denen ich Ihnen das Grundprinzip
hinter unserem Produkt erläutern möchte.

00:00:59.800 --> 00:01:01.920
Das Prinzip ist eigentlich ganz einfach:

00:01:01.920 --> 00:01:04.260
Wir haben eine Sammlung
von Prozess-Diagrammen,

00:01:04.260 --> 00:01:07.540
und diese sind schön hierarchisch
in mehreren Detail-Ebenen

00:01:07.540 --> 00:01:09.760
in Form einer Pyramide angeordnet.

00:01:10.300 --> 00:01:13.140
An der Spitze der Pyramide
befindet sich ein Diagramm

00:01:13.140 --> 00:01:15.960
mit der kompletten Übersicht
über die YaSM-Prozesse.

00:01:16.280 --> 00:01:19.420
Das ist der Haupt-Einstiegspunkt
in das Prozessmodell

00:01:19.420 --> 00:01:20.880
- und von hier können wir dann

00:01:20.880 --> 00:01:24.520
einfach per Hyperlink zu den
weiteren Detailebenen hinabsteigen.

00:01:25.160 --> 00:01:28.100
Auf der zweiten Ebene
finden wir dann 17 Diagramme

00:01:28.100 --> 00:01:30.520
- eines für jeden
"YaSM-Hauptprozess",

00:01:30.520 --> 00:01:33.580
wie z.B. ein Diagramm
für das "Service Design".

00:01:34.180 --> 00:01:36.400
Von der Hauptprozess-Ebene
können wir weiter

00:01:36.400 --> 00:01:39.560
zu den Ebenen 3 und 4
mit den "Sub-Prozessen" gehen,

00:01:39.560 --> 00:01:40.360
wo wir schließlich

00:01:40.369 --> 00:01:43.909
"Swimlane-Diagramme" mit einzelnen
Aktivitäten zu sehen bekommen.

00:01:44.360 --> 00:01:46.640
Hier erklären wir also sehr detailliert,

00:01:46.640 --> 00:01:49.460
wer was und
in welcher Reihenfolge zu tun hat.

00:01:49.840 --> 00:01:51.000
Alles in allem gibt es

00:01:51.000 --> 00:01:55.260
im YaSM-Prozessmodell
ungefähr 120 Prozessdiagramme.

00:01:56.220 --> 00:01:58.300
Und jetzt gehen wir hinüber
nach Visio,

00:01:58.310 --> 00:02:00.380
um uns anzuschauen,
wie wir das Ganze

00:02:00.380 --> 00:02:03.000
in Form von Visio-Diagrammen
umgesetzt haben.

00:02:03.640 --> 00:02:06.579
Was wir hier zunächst sehen
ist das "Top-Level-Diagramm"

00:02:06.579 --> 00:02:09.660
mit einer kompletten Übersicht
über die YaSM-Prozesse.

00:02:10.260 --> 00:02:12.700
Oben sind die
"Service-Lifecycle-Prozesse"

00:02:12.700 --> 00:02:15.080
• für das Erarbeiten
der Service-Strategie,

00:02:15.080 --> 00:02:16.380
• für das Designen,

00:02:16.390 --> 00:02:17.270
• Implementieren

00:02:17.270 --> 00:02:18.750
• und Betreiben der Services

00:02:18.750 --> 00:02:21.540
• und für die
kontinuierliche Service-Verbesserung.

00:02:22.240 --> 00:02:24.840
Unterhalb des Service-Lifecycles
befinden sich

00:02:24.840 --> 00:02:27.560
die "unterstützenden YaSM-Prozesse",
zum Beispiel

00:02:27.560 --> 00:02:29.840
• zum Bewerten und Koordinieren
von Changes

00:02:29.840 --> 00:02:32.000
• oder zum
Managen von Projekten.

00:02:32.920 --> 00:02:34.640
Wenn wir jetzt
genauer wissen möchten,

00:02:34.640 --> 00:02:36.680
was sich im
"Service-Betrieb" abspielt,

00:02:36.680 --> 00:02:38.680
dann nehmen wir von hier
einen Link

00:02:38.680 --> 00:02:41.220
und gehen hinunter
zur nächsten Detail-Ebene.

00:02:41.740 --> 00:02:46.360
Dort finden wir ein Übersichts-Diagramm mit
mehr Details über den Service-Betrieb.

00:02:47.280 --> 00:02:48.400
Wir zoomen gleich hinein,

00:02:48.410 --> 00:02:50.230
aber zunächst möchte ich
hier erläutern,

00:02:50.230 --> 00:02:53.000
dass wir auf der linken Seite
in diesen Diagrammen immer

00:02:53.010 --> 00:02:54.590
die "Inputs"
zu sehen bekommen:

00:02:54.960 --> 00:02:57.600
Links sehen wir also
die anderen YaSM-Prozesse

00:02:57.600 --> 00:03:01.600
und die Inputs, die diese Prozesse
in den Service-Betrieb hineinschicken.

00:03:02.360 --> 00:03:03.080
Rechts haben wir

00:03:03.090 --> 00:03:05.730
die "Outputs" vom Service-Betrieb
und wo sie hingehen,

00:03:05.920 --> 00:03:09.440
und in der Mitte sind die Prozesse
vom Service-Betrieb zu sehen,

00:03:09.440 --> 00:03:11.749
wie z.B. die bekannten Prozesse

00:03:11.749 --> 00:03:14.929
• zum Bearbeiten von
Incidents und Serviceaufträgen,

00:03:14.929 --> 00:03:16.989
• und die zum
Behandeln von Problemen.

00:03:17.760 --> 00:03:20.800
Wir verwenden in diesen Diagrammen
zwei Arten von Shapes:

00:03:21.120 --> 00:03:23.360
• Die grünen Shapes
stellen Prozesse dar,

00:03:23.360 --> 00:03:28.020
• und die orangefarbenen Shapes sind
"Daten- bzw. Informationsobjekte".

00:03:28.780 --> 00:03:30.659
Mit den Informationsobjekten

00:03:30.659 --> 00:03:33.559
stellen wir die Informationsflüsse
zwischen den Prozessen dar

00:03:33.560 --> 00:03:36.660
- und das ist ein wichtiges Prinzip
in unseren Diagrammen:

00:03:36.660 --> 00:03:38.360
Denn wir wollen Ihnen
nicht nur zeigen,

00:03:38.360 --> 00:03:40.040
welche Prozesse es
in YaSM gibt,

00:03:40.040 --> 00:03:42.519
sondern auch,
wie die Prozesse zusammenspielen.

00:03:43.160 --> 00:03:44.480
Hier z.B. sehen wir,

00:03:44.480 --> 00:03:46.120
dass das "Incident Management"

00:03:46.120 --> 00:03:47.500
alle "Incident Records"

00:03:47.500 --> 00:03:51.040
ans "Problem Management" schickt,
wo sie weiter analysiert werden.

00:03:51.540 --> 00:03:54.560
Falls der Problem Manager daraufhin
ein Problem entdeckt

00:03:54.560 --> 00:03:58.580
und einen Workaround für wiederholt
auftretende Incidents bereitstellen kann,

00:03:58.580 --> 00:04:02.140
dann wird ein "Problem Record"
mit einer Beschreibung des Workarounds

00:04:02.140 --> 00:04:04.540
ans Incident Management
zurückgeschickt

00:04:04.540 --> 00:04:08.080
- wo der Workaround bei der Lösung
künftiger Incidents hilft.

00:04:08.680 --> 00:04:10.860
Auf diese Weise
zeigen wir Ihnen also,

00:04:10.860 --> 00:04:13.520
wie Incident und Problem Management
zusammenspielen

00:04:13.520 --> 00:04:15.780
- und wie es in YaSM funktioniert.

00:04:16.740 --> 00:04:18.879
Man kann darüber hinaus
auf solche Shapes,

00:04:18.879 --> 00:04:21.079
wie z.B. das Prozess-Shape
hier klicken,

00:04:21.080 --> 00:04:23.479
und dann sieht man
- hier auf der rechten Seite -

00:04:23.479 --> 00:04:24.919
in einem "Shape-Daten-Fenster",

00:04:24.919 --> 00:04:27.459
dass für solche Shapes
Felder definiert sind:

00:04:27.980 --> 00:04:29.820
Der Prozess hat z.B. nicht nur

00:04:29.820 --> 00:04:31.000
• ein Namens-Feld,

00:04:31.000 --> 00:04:34.180
• sondern direkt darunter
auch eine kurze Beschreibung.

00:04:35.120 --> 00:04:37.620
Dasselbe funktioniert auch
für die Datenobjekte.

00:04:37.860 --> 00:04:39.860
Wenn ich auf
den Incident Record klicke,

00:04:39.860 --> 00:04:42.160
dann können Sie
im Shape-Daten-Fenster sehen,

00:04:42.160 --> 00:04:44.160
• dass das Objekt
einen Namen hat

00:04:44.160 --> 00:04:46.600
• und ebenfalls
eine kurze Beschreibung.

00:04:47.580 --> 00:04:49.560
Die Kurz-Beschreibung ist
schon mal ganz schön,

00:04:49.560 --> 00:04:51.719
aber man kann natürlich
eine Menge mehr

00:04:51.719 --> 00:04:53.799
über einen
Incident Record sagen.

00:04:54.280 --> 00:04:56.819
Deshalb sind solche Datenobjekte
in vielen Fällen

00:04:56.819 --> 00:04:58.999
mit sogenannten
"Checklisten" verknüpft.

00:04:59.320 --> 00:05:01.280
Checklisten sind
Word™-Dokumente,

00:05:01.280 --> 00:05:04.060
und man kann sie von hier aus
mit einem Link öffnen.

00:05:04.660 --> 00:05:07.340
Wenn ich auf den Link klicke,
sehen wir auch gleich

00:05:07.340 --> 00:05:09.660
die Checkliste
für den Incident Record:

00:05:10.400 --> 00:05:12.999
Die erläutert den Incident Record
im Detail

00:05:12.999 --> 00:05:14.999
und zeigt eine Struktur der Daten,

00:05:15.000 --> 00:05:18.960
die wir typischer Weise
in einem solchen Record erwarten würden.

00:05:20.020 --> 00:05:23.780
In der YaSM®-Prozesslandkarte
gibt es ca. 100 solcher Checklisten,

00:05:24.020 --> 00:05:27.120
z.B. auch eine für
die "Service-Definition".

00:05:27.580 --> 00:05:30.820
Und da es sich um Word-Dokumente
handelt, die Sie ändern können,

00:05:30.820 --> 00:05:33.300
können Sie die Checkliste
für die Service-Definition

00:05:33.309 --> 00:05:36.209
als Vorlage oder
Ausgangsbasis verwenden,

00:05:36.209 --> 00:05:39.729
wenn Sie solche Dokumente
in Ihrer Organisation erstellen müssen.

00:05:41.600 --> 00:05:43.899
Damit schließen wir
die Checkliste wieder ...

00:05:43.899 --> 00:05:46.659
und zurück in Visio
schauen wir uns jetzt noch an,

00:05:46.660 --> 00:05:50.080
was hinter dem zweiten Link
des Datenobjekt-Shapes steckt.

00:05:50.800 --> 00:05:51.780
Dieser Link öffnet

00:05:51.789 --> 00:05:54.549
das "Lifecycle-Diagramm"
für den Incident Record,

00:05:54.549 --> 00:05:55.500
in dem wir sehen,

00:05:55.509 --> 00:05:58.369
wo - in welchen YaSM-Prozessen -
solche Records

00:05:58.369 --> 00:05:59.340
• erstellt,

00:05:59.340 --> 00:06:00.460
• bearbeitet,

00:06:00.460 --> 00:06:01.480
• gelesen

00:06:01.480 --> 00:06:02.880
• und archiviert werden.

00:06:03.780 --> 00:06:05.479
Diese Diagramme bieten Ihnen also

00:06:05.479 --> 00:06:08.079
die vollständige Übersicht
auf einen Blick,

00:06:08.080 --> 00:06:09.320
indem sie darstellen,

00:06:09.320 --> 00:06:13.140
wie die Dokumente und Records
zwischen den YaSM-Prozessen fließen.

00:06:14.420 --> 00:06:16.679
So, und jetzt,
nach diesen Ausführungen,

00:06:16.679 --> 00:06:18.519
gehen wir weiter in die Details,

00:06:18.520 --> 00:06:20.179
z.B. weiter hinein

00:06:20.179 --> 00:06:24.159
in den Prozess für die Bearbeitung
von Incidents und Service Requests.

00:06:25.240 --> 00:06:26.660
Wieder klicken wir auf den Link,

00:06:26.660 --> 00:06:29.420
und es öffnet sich ein Diagramm,
in dem dargestellt wird,

00:06:29.420 --> 00:06:33.320
wie wir in YaSM mit Incidents
und Service Requests umgehen.

00:06:34.340 --> 00:06:35.259
Wie schon zuvor sind

00:06:35.259 --> 00:06:36.399
• links die Inputs,

00:06:36.400 --> 00:06:37.620
• rechts die Outputs,

00:06:37.620 --> 00:06:39.180
• und in der Mitte haben wir nun

00:06:39.189 --> 00:06:42.969
eine Übersicht über die Sub-Prozesse
vom Incident Management.

00:06:43.680 --> 00:06:45.600
Der erste Sub-Prozess
stellt sicher,

00:06:45.610 --> 00:06:48.850
dass alle Incidents und
Serviceaufträge erfasst werden,

00:06:49.220 --> 00:06:50.960
und die anderen
kümmern sich darum,

00:06:50.960 --> 00:06:53.880
dass Incidents und Serviceaufträge
bearbeitet werden.

00:06:54.880 --> 00:06:56.860
Was die Incidents betrifft,
so gibt es

00:06:56.860 --> 00:07:00.120
einen Prozess speziell zur
"Behebung von Major Incidents"

00:07:00.120 --> 00:07:04.240
und einen weiteren zur
"Behebung der Incidents im 1st-Level-Support".

00:07:04.740 --> 00:07:07.719
Und wenn der 1st-Level-Support
nichts ausrichten kann,

00:07:07.719 --> 00:07:09.119
dann gehen die Incidents

00:07:09.120 --> 00:07:12.219
weiter zu den Spezialisten
im 2nd-Level-Support.

00:07:12.880 --> 00:07:15.780
Und schließlich werden
alle Incidents und Service Requests

00:07:15.789 --> 00:07:18.529
hier unten formal geschlossen,
wenn sie gelöst sind.

00:07:19.349 --> 00:07:22.889
Dieses Diagramm zeigt uns also
schon einmal die gröberen Schritte,

00:07:22.889 --> 00:07:26.989
die zum Bearbeiten von Incidents und
Service Requests erforderlich sind,

00:07:27.320 --> 00:07:31.060
und von hier können wir jetzt noch
einmal weiter nach unten gehen:

00:07:31.069 --> 00:07:35.389
Zur untersten Detailebene, die in der
YaSM®-Prozesslandkarte enthalten ist.

00:07:36.380 --> 00:07:39.040
Hier sehen die Diagramme
jetzt ein bisschen anders aus,

00:07:39.240 --> 00:07:42.740
weil wir im unteren Teil eine Swimlane
mit "Aktivitäten" haben.

00:07:43.600 --> 00:07:47.320
Zunächst schauen wir uns allerdings
kurz den oberen Teil des Diagramms an:

00:07:47.600 --> 00:07:48.360
• Dort sind links

00:07:48.369 --> 00:07:51.189
die ganzen Inputs zu sehen,
die der Prozess benötigt,

00:07:51.189 --> 00:07:52.719
und wo die Inputs herkommen.

00:07:53.300 --> 00:07:56.220
• Rechts sind die ganzen Outputs
- und wo sie hingehen.

00:07:57.220 --> 00:07:59.080
Im unteren Teil des Diagramms
sehen wir

00:07:59.080 --> 00:08:00.820
eine Swimlane mit Aktivitäten.

00:08:01.440 --> 00:08:05.020
Swimlanes werden verwendet,
um "Verantwortlichkeiten" zuzuweisen:

00:08:05.260 --> 00:08:07.920
Die gelben Shapes in den Swimlanes
sind "YaSM-Rollen",

00:08:07.920 --> 00:08:11.840
die anzeigen, wer die Aktivitäten in
der Swimlane durchzuführen hat.

00:08:12.580 --> 00:08:14.740
Wahrscheinlich ist es nun
fast selbsterklärend,

00:08:14.740 --> 00:08:16.400
was dieses Diagramm hier sagt:

00:08:16.660 --> 00:08:18.520
Der 1st-Level-Support soll zunächst

00:08:18.529 --> 00:08:20.349
• eine Erstanalyse durchführen,

00:08:20.349 --> 00:08:22.260
• die Knowledge Base durchsuchen

00:08:22.260 --> 00:08:24.120
• und den Incident, wenn möglich,

00:08:24.120 --> 00:08:27.340
bestehenden anderen Incidents
oder Problems zuordnen.

00:08:28.120 --> 00:08:31.280
Nach diesen Anfangs-Aktivitäten
ist eine Entscheidung fällig:

00:08:31.560 --> 00:08:32.460
• Wir müssen uns entscheiden,

00:08:32.460 --> 00:08:36.100
ob wir den Incident im 1st-Level-Support
lösen können oder nicht.

00:08:36.680 --> 00:08:39.180
Diese Entscheidung
hat ein paar mögliche Ausgänge:

00:08:39.460 --> 00:08:43.720
• Erstens könnte es sein, dass wir im
1st-Level-Support nichts erreichen können:

00:08:43.960 --> 00:08:47.320
Dann wird der Incident an den
2nd-Level-Support übergeben.

00:08:47.860 --> 00:08:51.180
• Oder wir können tatsächlich
die Ursache des Incidents beheben

00:08:51.360 --> 00:08:52.660
- das wäre ideal!

00:08:53.300 --> 00:08:54.259
• Wenn das nicht geht,

00:08:54.259 --> 00:08:56.739
dann haben wir vielleicht
einen Workaround verfügbar

00:08:56.740 --> 00:08:59.360
• oder eine Idee
für einen neuen Workaround.

00:09:00.180 --> 00:09:03.180
In diesem Falle wird der
neue Workaround angewendet

00:09:03.180 --> 00:09:04.460
• und so weiter ...

00:09:04.720 --> 00:09:08.120
• ... bis der Prozess hier schließlich
auf der rechten Seite endet.

00:09:08.520 --> 00:09:11.580
In diesem Fall gibt es
zwei Endpunkte für den Prozess:

00:09:11.940 --> 00:09:14.360
Entweder wir haben
den Incident gelöst

00:09:14.360 --> 00:09:18.520
- durch Behebung der Ursache oder
durch Anwendung eines Workarounds.

00:09:19.200 --> 00:09:21.720
Etwas weiter oben sehen wir
den zweiten Endpunkt:

00:09:21.960 --> 00:09:24.080
Wenn wir den Incident
nicht beheben konnten,

00:09:24.080 --> 00:09:27.180
dann haben wir ihn an den
2nd-Level-Support übergeben.

00:09:28.120 --> 00:09:29.600
Und wenn wir jetzt wissen möchten:

00:09:29.610 --> 00:09:30.430
Wie geht’s hier weiter?

00:09:30.430 --> 00:09:32.640
Was passiert im 2nd-Level-Support?

00:09:32.640 --> 00:09:36.080
Dann gehen wir wieder in den
oberen Bereich dieses Diagramms:

00:09:36.580 --> 00:09:38.579
Dort finden wir den Incident Record,

00:09:38.579 --> 00:09:41.479
wie er an den 2nd-Level-Support-Prozess
übergeben wird,

00:09:41.740 --> 00:09:42.839
und mit dem Link hier

00:09:42.839 --> 00:09:45.719
können wir dann direkt in den
nachfolgenden Prozess springen

00:09:46.120 --> 00:09:49.100
und sehen, wie es im
2nd-Level-Support weitergeht.

00:09:52.460 --> 00:09:53.340
Und das ist,

00:09:53.350 --> 00:09:56.270
was ich Ihnen heute in dieser
kurzen Einführung zeigen wollte.

00:09:56.800 --> 00:09:58.560
Um es kurz zu machen,
haben wir uns auf

00:09:58.560 --> 00:10:02.160
die wichtigsten Komponenten in der
YaSM®-Prozesslandkarte beschränkt:

00:10:02.520 --> 00:10:03.580
• Die YaSM-Prozessdiagramme

00:10:03.580 --> 00:10:05.280
• und die Dokumentvorlagen.

00:10:06.100 --> 00:10:08.360
Außerdem gibt es
in unserem Produkt auch

00:10:08.360 --> 00:10:09.700
• eine RACI-Matrix,

00:10:09.700 --> 00:10:11.080
• ein Datenmodell,

00:10:11.080 --> 00:10:12.680
• ein Excel®-Repository,

00:10:12.820 --> 00:10:15.520
und die "YaSM - ISO 20000 Bridge"
[als optionale Komponente]:

00:10:15.520 --> 00:10:18.480
Ein Satz von Diagrammen
speziell für Organisationen,

00:10:18.480 --> 00:10:21.860
die sich nach ISO 20000
zertifizieren lassen möchten.

00:10:22.440 --> 00:10:25.060
Weiter in die Details
gehen wir hier aber nicht,

00:10:25.060 --> 00:10:28.920
denn zu diesen Komponenten
haben wir weitere Videos vorbereitet.

00:10:30.060 --> 00:10:33.740
Wenn Sie eine Lizenz erwerben,
dann gibt es dazu auch Support:

00:10:33.740 --> 00:10:35.160
Darin enthalten sind

00:10:35.170 --> 00:10:36.160
• Updates,

00:10:36.160 --> 00:10:38.000
• Antworten auf Fragen zu YaSM

00:10:38.000 --> 00:10:39.920
• und technischer Support.

00:10:40.180 --> 00:10:43.120
Dieser Service ist während
des ersten Jahres kostenfrei.

00:10:44.420 --> 00:10:45.700
So viel für heute.

00:10:45.700 --> 00:10:48.740
Wenn Sie mehr über die
YaSM®-Prozesslandkarte erfahren möchten

00:10:48.740 --> 00:10:50.160
oder Fragen an uns haben,

00:10:50.160 --> 00:10:52.640
dann gehen Sie einfach auf
yasm.com

00:10:53.340 --> 00:10:55.860
Vielen Dank fürs Zusehen
- und bis dann!

00:10:56.960 --> 00:10:59.680
[ Besuchen Sie
yasm.com ]

00:10:59.680 --> 00:11:03.440
[ Weitere Videos und Informationen zu YaSM
und zur YaSM®-Prozesslandkarte ]

00:11:03.440 --> 00:11:06.080
[ Bitte wenden Sie sich an uns,
wenn Sie Fragen haben! ]

