WEBVTT
Kind: captions
Language: de

00:00:00.760 --> 00:00:03.740
Wer sich mit den gängigen Service-
Management-Frameworks beschäftigt,

00:00:03.740 --> 00:00:05.200
lernt oft als erstes,

00:00:05.380 --> 00:00:08.220
dass man den Kunden-Support
nicht dem Zufall überlassen darf.

00:00:08.840 --> 00:00:11.999
Stattdessen wird ein einheitlicher
und professioneller Umgang

00:00:11.999 --> 00:00:14.899
mit Incidents und
Serviceaufträgen verlangt.

00:00:15.380 --> 00:00:17.280
Der Grund dafür
ist ganz einfach:

00:00:17.520 --> 00:00:19.940
Schlechter Kunden-Service
vertreibt die Kunden,

00:00:19.940 --> 00:00:21.440
und das soll nicht passieren

00:00:21.860 --> 00:00:23.980
- weil es viel einfacher
und billiger ist,

00:00:23.980 --> 00:00:25.580
bestehende Kunden
zu behalten,

00:00:25.580 --> 00:00:27.060
als neue zu gewinnen.

00:00:27.800 --> 00:00:29.060
Und so ist es
nur logisch,

00:00:29.060 --> 00:00:31.840
dass in allen Service-Management-
Frameworks und -Standards

00:00:32.060 --> 00:00:34.480
viel über Support-Prozesse
geschrieben wird!

00:00:34.960 --> 00:00:36.760
Und heute möchte ich
Ihnen näher erläutern,

00:00:36.760 --> 00:00:38.060
was genau es braucht,

00:00:38.280 --> 00:00:41.520
um beim Thema Kunden-Support
gut aufgestellt zu sein.

00:00:42.880 --> 00:00:45.140
Die bekannten
Service-Management-Frameworks

00:00:45.140 --> 00:00:47.160
wie ITIL® und CMMI-SVC®

00:00:47.320 --> 00:00:49.740
enthalten viele bewährte
Empfehlungen dazu,

00:00:49.800 --> 00:00:51.839
wie man den Kunden-Support
organisiert

00:00:51.839 --> 00:00:53.459
und Incidents managt.

00:00:53.820 --> 00:00:56.620
Und ISO 20000 enthält
explizit die Forderung

00:00:56.620 --> 00:00:57.740
nach Prozessen für das

00:00:57.740 --> 00:01:00.600
Managen von Incidents
und Service Requests.

00:01:01.240 --> 00:01:03.320
Tatsächlich ist der
Incident-Management-Prozess

00:01:03.320 --> 00:01:05.700
wohl der bekannteste Teil
dieser Frameworks,

00:01:05.880 --> 00:01:07.640
und es wird so viel
über ihn geredet,

00:01:07.640 --> 00:01:08.920
dass man leicht übersieht,

00:01:08.940 --> 00:01:11.740
dass auch noch ein paar andere
Prozesse eine Rolle spielen,

00:01:11.860 --> 00:01:14.460
wenn wir den Kunden-Support
richtig hinbekommen wollen.

00:01:15.280 --> 00:01:17.780
Diese Prozesse schauen wir uns
gleich näher an,

00:01:17.790 --> 00:01:19.040
aber zuerst sollten wir uns

00:01:19.040 --> 00:01:22.080
über die Ziele von gutem
Kunden-Support klarwerden.

00:01:22.780 --> 00:01:24.460
Natürlich müssen wir
dafür sorgen,

00:01:24.460 --> 00:01:26.300
dass sich die Kunden
gut behandelt fühlen.

00:01:26.660 --> 00:01:28.060
Wir dürfen sie nicht verärgern,

00:01:28.060 --> 00:01:30.160
indem wir unsere
Kontaktdaten verstecken

00:01:30.460 --> 00:01:32.260
- stattdessen sollte es
einfach sein,

00:01:32.260 --> 00:01:33.620
sich an uns zu wenden.

00:01:33.980 --> 00:01:36.940
Wenn es eine Störung gibt,
sollten wir sie zügig lösen,

00:01:37.090 --> 00:01:38.890
und die Kunden
auf dem Laufenden halten,

00:01:38.890 --> 00:01:41.000
solange wir an der
Lösung arbeiten.

00:01:41.760 --> 00:01:42.860
Aber sich einfach

00:01:42.860 --> 00:01:45.320
auf die perfekte Kundenbetreuung
zu konzentrieren,

00:01:45.320 --> 00:01:46.320
ist nicht genug.

00:01:46.570 --> 00:01:47.750
Es kommt auch darauf an,

00:01:47.750 --> 00:01:50.370
die Kosten für den Support
im Blick zu behalten.

00:01:51.100 --> 00:01:53.660
Dafür gibt es einige
mögliche Ansätze.

00:01:54.280 --> 00:01:55.840
Wenn wir es
zum Beispiel schaffen,

00:01:55.840 --> 00:01:58.340
die Anzahl der Störungen
bzw. Incidents

00:01:58.340 --> 00:02:00.000
von vorne herein
niedrig zu halten,

00:02:00.240 --> 00:02:01.360
müssen wir auch
weniger Zeit

00:02:01.360 --> 00:02:03.300
für deren Bearbeitung
aufwenden.

00:02:03.920 --> 00:02:06.120
Es sollten auch Mechanismen
vorhanden sein,

00:02:06.120 --> 00:02:08.860
um mögliche Probleme
frühzeitig zu entdecken,

00:02:09.120 --> 00:02:11.120
so dass wir uns um
Incidents kümmern können,

00:02:11.120 --> 00:02:13.320
noch bevor
viele User betroffen sind.

00:02:13.800 --> 00:02:15.540
Und wenn wir
attraktive Angebote

00:02:15.550 --> 00:02:17.430
zur Selbsthilfe
bereitstellen können,

00:02:17.430 --> 00:02:18.830
lässt sich viel Geld sparen,

00:02:19.000 --> 00:02:21.180
da dann für die Lösung
bestimmter Incidents

00:02:21.180 --> 00:02:23.600
keine Support-Mitarbeiter
benötigt werden.

00:02:24.320 --> 00:02:25.520
Was wir also wollen,

00:02:25.520 --> 00:02:28.980
ist eine gute Kundenerfahrung
ohne ausufernde Kosten,

00:02:29.180 --> 00:02:31.500
und jetzt möchte ich Ihnen
etwas mehr im Detail zeigen,

00:02:31.500 --> 00:02:34.500
welche Empfehlungen Sie
dazu in YaSM finden.

00:02:35.420 --> 00:02:37.420
Als erstes ist es wichtig
zu verstehen,

00:02:37.420 --> 00:02:38.900
dass wir nicht erst
dann anfangen,

00:02:38.900 --> 00:02:40.740
über Kunden-Support
nachzudenken,

00:02:40.740 --> 00:02:42.460
wenn ein Service
in Betrieb ist.

00:02:42.900 --> 00:02:44.200
Solche Überlegungen müssen

00:02:44.200 --> 00:02:46.760
weit vor der Implementierung
des Service beginnen,

00:02:46.760 --> 00:02:49.420
nämlich in der Phase
des Service-Designs.

00:02:50.120 --> 00:02:51.540
Es ist ja leicht einzusehen,

00:02:51.540 --> 00:02:54.200
dass schlecht designte Services
oder Infrastrukturen

00:02:54.200 --> 00:02:56.000
zu vielen Störungen
führen können,

00:02:56.180 --> 00:02:58.560
die dann mit viel Aufwand
behoben werden müssen.

00:02:58.860 --> 00:03:00.180
Also macht es viel Sinn,

00:03:00.180 --> 00:03:02.380
beim Service Design
darüber nachzudenken,

00:03:02.380 --> 00:03:04.580
wie Incidents
vermieden werden können.

00:03:05.260 --> 00:03:06.660
Mögliche Lösungen sind hier

00:03:06.660 --> 00:03:09.640
die Vermeidung sogenannter
"Single Points of Failure",

00:03:09.780 --> 00:03:12.140
damit Incidents gar nicht
erst auftreten,

00:03:12.640 --> 00:03:13.880
oder das Einrichten

00:03:13.890 --> 00:03:16.190
von Wiederherstellungs-
und Reparatur-Mechanismen,

00:03:16.340 --> 00:03:19.040
damit Incidents schneller
gelöst werden können.

00:03:19.780 --> 00:03:21.000
Wir können also festhalten,

00:03:21.000 --> 00:03:23.080
dass Services
und ihre Infrastruktur

00:03:23.080 --> 00:03:26.880
für Stabilität und hohe Verfügbarkeit
ausgelegt sein sollten,

00:03:27.140 --> 00:03:30.340
sodass wir nicht zu viel Aufwand
für den Support treiben müssen.

00:03:31.000 --> 00:03:34.480
Aber natürlich können auch
die besten Services einmal ausfallen,

00:03:34.690 --> 00:03:36.680
und somit brauchen wir
auf jeden Fall auch

00:03:36.680 --> 00:03:39.180
vernünftige Support-Prozesse
im Service-Betrieb,

00:03:39.180 --> 00:03:41.900
um Störungen und Incidents
zu behandeln.

00:03:42.700 --> 00:03:44.860
Zuallererst gehört dazu
ein Prozess

00:03:44.860 --> 00:03:47.500
zum Managen von Incidents
und Service-Aufträgen,

00:03:47.780 --> 00:03:50.440
der die Anfragen von den
Kunden entgegennimmt.

00:03:51.420 --> 00:03:54.440
Dieser Prozess enthält
typischerweise Aktivitäten für

00:03:54.640 --> 00:03:56.420
• die Behebung von Incidents

00:03:56.820 --> 00:03:59.240
• das Bearbeiten von
Service-Aufträgen

00:03:59.360 --> 00:04:01.600
• und die fortlaufende
Information der Kunden

00:04:01.600 --> 00:04:03.180
über den Stand der Dinge.

00:04:04.220 --> 00:04:06.480
Diese Aktivitäten
bedeuten in der Regel,

00:04:06.480 --> 00:04:09.460
dass Support-Mitarbeiter
im Help Desk beteiligt sind

00:04:09.660 --> 00:04:10.740
- was teuer ist.

00:04:11.120 --> 00:04:12.700
Deshalb stellen wir
auch sicher,

00:04:12.700 --> 00:04:15.600
dass es attraktive Angebote
zur Selbsthilfe gibt,

00:04:15.800 --> 00:04:18.600
wie z.B. in Form
einer Support-Website.

00:04:19.260 --> 00:04:21.240
Ganz klar, wenn sich
Kunden selbst helfen,

00:04:21.240 --> 00:04:24.180
bedeutet das weniger Arbeit
für die Support-Mitarbeiter

00:04:24.180 --> 00:04:25.780
und weniger Unkosten.

00:04:26.540 --> 00:04:28.160
Weiterhin ist es auch
sehr wichtig,

00:04:28.380 --> 00:04:30.300
während des Bearbeitens
von Incidents

00:04:30.300 --> 00:04:31.600
Erfahrungen zu sammeln

00:04:31.780 --> 00:04:34.100
und eine Support Knowledge
Base aufzubauen

00:04:34.500 --> 00:04:37.240
- denn wenn sich Anleitungen
zum Beheben bestimmter Incidents

00:04:37.240 --> 00:04:38.300
leicht finden lassen,

00:04:38.300 --> 00:04:41.000
können diese Incidents
sehr schnell behoben werden.

00:04:41.680 --> 00:04:44.440
So, nun ist der Prozess zum
Managen von Incidents

00:04:44.440 --> 00:04:45.880
nicht gerade unwichtig,

00:04:46.100 --> 00:04:48.800
aber wir sollten nicht nur untätig
herumsitzen und warten,

00:04:48.800 --> 00:04:50.520
bis Incidents passieren.

00:04:51.220 --> 00:04:54.600
Stattdessen sollten wir ein Auge auf
die Service-Infrastruktur haben

00:04:54.610 --> 00:04:56.550
und Abweichungen vom
Normalzustand

00:04:56.550 --> 00:04:58.290
so früh wie möglich erkennen.

00:04:59.000 --> 00:05:00.820
Wenn Auffälligkeiten
entdeckt werden,

00:05:00.820 --> 00:05:03.020
sollten geeignete Reaktionen
erfolgen

00:05:03.240 --> 00:05:05.260
- wann immer möglich
automatisiert.

00:05:05.840 --> 00:05:08.980
Die Absicht ist dabei,
etwaige Probleme abzufangen,

00:05:08.980 --> 00:05:11.200
bevor die Kunden
etwas davon merken.

00:05:11.940 --> 00:05:13.620
Falls in bestimmten Situationen

00:05:13.620 --> 00:05:15.700
menschliches Eingreifen
unumgänglich ist,

00:05:15.740 --> 00:05:17.460
wird ein Incident Record
erstellt

00:05:17.710 --> 00:05:20.490
und an den Incident-Management-
Prozess geschickt.

00:05:21.460 --> 00:05:22.460
Also, wir versuchen,

00:05:22.460 --> 00:05:24.980
mögliche Fehlersituationen
früh zu erkennen,

00:05:25.420 --> 00:05:27.620
und wenn Incidents
einmal aufgetreten sind,

00:05:27.620 --> 00:05:30.120
senden wir sie zu
einem weiteren Prozess,

00:05:30.120 --> 00:05:32.720
der sich um die dahinterliegenden
Probleme kümmert.

00:05:33.300 --> 00:05:34.340
In diesem Prozess

00:05:34.340 --> 00:05:36.940
analysieren wir die Incidents
in unserer Datenbank,

00:05:36.940 --> 00:05:38.380
um Muster zu erkennen,

00:05:38.700 --> 00:05:40.820
wie z.B. das
häufige Auftreten

00:05:40.830 --> 00:05:43.610
von Papierstaus bei einem
bestimmten Drucker-Typ,

00:05:43.790 --> 00:05:46.450
die zu vielen gleichgelagerten
Incidents führen.

00:05:47.260 --> 00:05:48.660
Wenn das Problem
erkannt ist,

00:05:48.660 --> 00:05:51.020
können wir es hoffentlich
lösen, z.B.

00:05:51.020 --> 00:05:52.480
indem wir die
betroffenen Drucker

00:05:52.480 --> 00:05:54.280
durch ein anderes
Modell ersetzen.

00:05:54.660 --> 00:05:56.140
Und das sollte dann bewirken,

00:05:56.140 --> 00:05:58.940
dass in Zukunft
weniger Incidents auftreten.

00:05:59.640 --> 00:06:00.920
Der Zweck der Übung ist,

00:06:00.920 --> 00:06:03.010
dass sich Incidents
nicht endlos wiederholen,

00:06:03.180 --> 00:06:04.980
und dass Templates
oder Anleitungen

00:06:04.980 --> 00:06:07.400
für eine schnelle Lösung
bereitgestellt werden,

00:06:07.400 --> 00:06:10.040
falls sich die Incidents
nicht vermeiden lassen.

00:06:10.440 --> 00:06:12.780
Vom Problem-Management-
Prozess bekommen wir deshalb

00:06:12.780 --> 00:06:15.750
vor allem Workarounds
und permanente Lösungen,

00:06:15.919 --> 00:06:17.210
so dass wir weniger Zeit

00:06:17.210 --> 00:06:20.090
für das Beheben von Incidents
aufwenden müssen.

00:06:22.060 --> 00:06:23.240
Dies war jetzt erstmal

00:06:23.240 --> 00:06:24.920
eine Übersicht
über die Empfehlungen,

00:06:24.920 --> 00:06:25.960
die wir in YaSM

00:06:25.960 --> 00:06:28.599
und anderen Service-
Management-Frameworks finden.

00:06:29.320 --> 00:06:31.440
Vielleicht sieht das alles
recht kompliziert aus,

00:06:31.760 --> 00:06:34.740
aber wenn Sie solche Prozesse
bei sich einführen möchten,

00:06:34.900 --> 00:06:39.380
dann bietet YaSM detaillierte Anleitungen
in Form von Prozess-Templates,

00:06:39.640 --> 00:06:41.360
und bevor wir für heute
zum Schluss kommen,

00:06:41.360 --> 00:06:43.740
möchte ich Ihnen noch
ein paar Beispiele zeigen.

00:06:45.440 --> 00:06:49.540
Die YaSM-Prozess-Templates gibt es
zum Beispiel als Visio®-Diagramme.

00:06:50.020 --> 00:06:51.900
Wir starten mit dem
Top-Level-Diagramm,

00:06:51.900 --> 00:06:55.160
das eine Übersicht über alle
YaSM-Prozesse darstellt,

00:06:55.400 --> 00:06:57.420
und da die Prozesse,
die ich Ihnen zeigen möchte,

00:06:57.420 --> 00:06:59.280
im Service-Betrieb
angesiedelt sind,

00:06:59.280 --> 00:07:00.520
klicken wir auf den Link,

00:07:00.520 --> 00:07:03.240
der uns zum Diagramm
für den Service-Betrieb führt.

00:07:04.420 --> 00:07:06.320
Wenn wir das
ein bisschen vergrößern,

00:07:06.320 --> 00:07:09.600
können wir einige der zuvor
bereits erwähnten Prozesse sehen,

00:07:10.290 --> 00:07:12.490
zum Beispiel für das
Überwachen der Services,

00:07:12.580 --> 00:07:15.479
für das Lösen von Incidents
und Service-Aufträgen

00:07:15.640 --> 00:07:17.860
und für das Lösen von Problemen.

00:07:18.960 --> 00:07:20.680
Von hier gehen wir
weiter hinein,

00:07:20.680 --> 00:07:21.720
um uns die Einzelheiten

00:07:21.720 --> 00:07:24.300
beim Lösen von Incidents
näher anzuschauen.

00:07:25.460 --> 00:07:29.060
Der erste Schritt ist die Erfassung
aller relevanten Informationen

00:07:29.060 --> 00:07:31.300
zu den Incidents und
Service Requests.

00:07:31.840 --> 00:07:33.160
Diese Details werden in

00:07:33.160 --> 00:07:36.360
Incident Records oder
Service Request Records gespeichert,

00:07:36.360 --> 00:07:38.170
die dann an die nächsten
Sub-Prozesse

00:07:38.170 --> 00:07:40.230
zur Bearbeitung der
Service-Aufträge

00:07:40.230 --> 00:07:43.870
bzw. Lösung von Incidents
weitergereicht werden.

00:07:44.660 --> 00:07:46.140
Für jeden solchen Sub-Prozess

00:07:46.140 --> 00:07:48.540
gibt es jetzt eine weitere
Detaillierungs-Ebene,

00:07:48.540 --> 00:07:51.640
die die auszuführenden
Aktivitäten beschreibt.

00:07:52.740 --> 00:07:54.860
Wenn wir etwas hineinzoomen,
sehen wir,

00:07:54.860 --> 00:07:56.880
dass die Mitarbeiter im
1st Level Support

00:07:56.880 --> 00:07:59.220
zunächst eine Erstanalyse
durchführen

00:07:59.389 --> 00:08:00.449
und die Knowledge Base

00:08:00.449 --> 00:08:04.149
nach bekannten Problemen und
Lösungs-Möglichkeiten durchsuchen.

00:08:04.980 --> 00:08:07.260
Nach ein paar weiteren Schritten
muss entschieden werden,

00:08:07.260 --> 00:08:10.740
ob eine Lösung der Störung im
1st Level Support erfolgen kann

00:08:11.080 --> 00:08:12.120
oder ob der Incident

00:08:12.120 --> 00:08:14.820
an den 2nd Level Support
übergeben werden muss,

00:08:15.440 --> 00:08:16.480
... und so weiter ...

00:08:16.900 --> 00:08:20.220
bis wir am Ende des Prozesses
den Incident entweder gelöst

00:08:20.420 --> 00:08:24.060
oder eben an den 2nd Level
Support weitergeleitet haben.

00:08:25.400 --> 00:08:28.380
Wenn wir uns in die obere Hälfte
des Diagramms bewegen,

00:08:28.380 --> 00:08:31.120
können wir auch herausfinden,
was als nächstes passiert.

00:08:31.780 --> 00:08:34.620
Incidents, die in diesem Prozess
gelöst werden konnten,

00:08:34.620 --> 00:08:36.860
sind jetzt z.B. bereit
zum Schließen,

00:08:37.280 --> 00:08:38.620
und wenn wir auf
den Link klicken,

00:08:38.620 --> 00:08:40.840
bringt uns das zu einem
anderen Diagramm,

00:08:40.840 --> 00:08:42.320
das die empfohlenen Schritte

00:08:42.330 --> 00:08:45.410
zum formalen Schließen
von Incidents beschreibt.

00:08:45.840 --> 00:08:49.220
Dazu gehören das Kontrollieren
der Lösungsdokumentation

00:08:49.380 --> 00:08:50.820
und das erneute Prüfen

00:08:50.820 --> 00:08:54.700
der Klassifizierung des Incidents
oder Service-Auftrags.

00:08:57.080 --> 00:08:58.800
Mit diesen Anleitungen
sollte es

00:08:58.800 --> 00:09:01.120
keine allzu große
Herausforderung für Sie sein,

00:09:01.120 --> 00:09:04.380
solche Prozesse in Ihrer Organisation
einzuführen.

00:09:05.040 --> 00:09:06.440
Was uns selbst betrifft,

00:09:06.580 --> 00:09:09.040
wir bieten auch Support
für unsere Produkte an

00:09:09.040 --> 00:09:09.820
und bemühen uns,

00:09:09.820 --> 00:09:11.840
mit gutem Beispiel voranzugehen,

00:09:12.120 --> 00:09:15.440
und selbstverständlich folgen wir
unseren eigenen Empfehlungen.

00:09:16.160 --> 00:09:17.840
Für unsere Kunden
bedeutet das,

00:09:18.020 --> 00:09:22.201
dass sie alle relevanten Informationen
im YaSM-Support-Portal finden:

00:09:23.840 --> 00:09:25.420
Wie in vielen Portalen dieser Art,

00:09:25.420 --> 00:09:28.460
können die Besucher in einem
Community-Forum stöbern

00:09:28.620 --> 00:09:30.560
oder einen neuen Post starten.

00:09:31.200 --> 00:09:32.460
Sie können die
Knowledge Base

00:09:32.470 --> 00:09:34.710
mit Anleitungen zur
Selbsthilfe durchsuchen

00:09:34.960 --> 00:09:38.420
- oder einfach ein paar Suchbegriffe
hier in das Suchfeld eingeben,

00:09:38.420 --> 00:09:39.740
um das gesamte Portal

00:09:39.750 --> 00:09:42.270
nach relevanten Inhalten
zu durchforsten.

00:09:43.300 --> 00:09:45.900
Wer nicht die richtigen
Informationen im Portal findet,

00:09:45.900 --> 00:09:47.700
kann auch ein
Support-Ticket anlegen.

00:09:48.280 --> 00:09:50.260
Während die Tickets
bearbeitet werden,

00:09:50.260 --> 00:09:51.940
können die User
den aktuellen Stand

00:09:51.940 --> 00:09:53.780
im Support-Portal verfolgen.

00:09:54.440 --> 00:09:55.460
Und schließlich,

00:09:55.460 --> 00:09:57.220
wenn jemand direkt
mit uns sprechen möchte,

00:09:57.380 --> 00:09:59.600
zeigen wir unsere
Kontaktinformationen

00:09:59.610 --> 00:10:02.670
für alle sichtbar hier oben
auf jeder Seite an.

00:10:04.880 --> 00:10:06.540
Und das war's für heute!

00:10:06.900 --> 00:10:08.480
Ich hoffe, ich konnte
deutlich machen,

00:10:08.480 --> 00:10:09.780
dass wir in jedem Fall

00:10:09.780 --> 00:10:12.200
sehr guten Kunden-Support
anzubieten können,

00:10:12.200 --> 00:10:14.600
ohne dass die Kosten
aus dem Ruder laufen,

00:10:14.940 --> 00:10:17.480
und dass wir in YaSM
Prozess-Templates anbieten,

00:10:17.500 --> 00:10:21.060
mit denen Sie relativ einfach
professionelle Support-Prozesse

00:10:21.060 --> 00:10:23.500
in Ihrer Organisation
einführen können.

00:10:24.160 --> 00:10:25.460
Vielen Dank fürs Zusehen!

00:10:25.470 --> 00:10:26.250
Und wie immer:

00:10:26.250 --> 00:10:27.330
Wenn Sie Fragen haben,

00:10:27.330 --> 00:10:30.740
beantworten wir diese gerne
in der YaSM-Community.

00:10:31.140 --> 00:10:32.300
[ Besuchen Sie uns auf
yasm.com ]

00:10:32.300 --> 00:10:33.680
[ Frei zugängliches
YaSM-Wiki: ... ]

00:10:33.680 --> 00:10:35.680
[ ... Eine vollständige Einführung
in das YaSM-Framework. ]

00:10:35.680 --> 00:10:36.920
[ Weitere Videos
und Informationen ... ]

00:10:36.920 --> 00:10:38.980
[ ... über YaSM
und die YaSM®-Prozesslandkarte  ]

00:10:38.980 --> 00:10:40.980
[ Diskutieren Sie mit uns
in der YaSM-Support-Community! ]