4

Service, Service-Request und IMAC

Leicht werden die Begriffe Service Request und Service durcheinander gebracht. Kennst Du den Unterschied, bietest Du Deinen Kunden bessere Services und produzierst kostengünstiger. In dieser Folge nehmen wir die drei Begriffe auseinander. Du wirst sie nie mehr verwechseln.

Ich darf es immer wieder beobachten: Starte ich mit einem Kunden in die Definition von Services, sind in 70% der Fälle die ersten Services immer die gleichen. Und: sie sind keine Services.

Damit Dir das nicht auch passiert, möchte ich heute mit Dir sprechen.

Service oder Service-Request?

Was ist ein Service?

Ein Service ist ein Bündel von Nutzeffekten.

Was bedeutet das? Ich verdeutliche Dir die Definition an einem Beispiel aus der nicht-IT-Welt:

Ich bin letzte Woche am Knie operiert worden. Da habe ich eine ganze Reihe Services in Anspruch genommen:

• OP-Vorbereitung – Nutzeffekt: Es wurde sichergestellt, dass nichts gegen die Durchführung der OP spricht.
• Narkose – Nutzeffekt: Ich habe nichts von der Operation selbst gespürt
• Operation – Nutzeffekt: Ich kann inzwischen wieder ohne Unterarmstützen laufen
• Aufwachen – Nutzeffekt: Mit Hilfe von Pfefferminztee und einen gewissen Ablauf wurde mein Kreislauf wieder in Schwung gebracht. Ich konnte bald wieder nach Hause gehen.

Alles in allem ein gut organisierter Ablauf, mit einem absolut überragenden Nutzen für mich. Und dieser Ablauf wurde allein an dem Tag acht Mal wiederholt.

Und genau einen solchen Nutzen darfst Du mit Deinen Services Deinen Kunden bieten. Wenn Du mehr dazu wissen möchtest, warum es für Dich von Vorteil ist, geschäftsfokussierte IT-Services anzubieten, lies bitte folgende Beiträge:

• 5 Vorteile geschäftsfokussierter IT-Dienste, die Dein Chef und Deine Kunden lieben werden
• Wie Du geschäftsfokussierte IT-Dienste definierst und welche 4 Grundsätze Dir dabei helfen

Was würdest Du mir antworten, wenn ich nach Deinen Services frage? Von Kunden bekomme ich mindestens eine der folgenden Antworten:

• Notebook bestellen
• Rechner installieren
• SAP
• eMail
• Software XY installieren
• Projektlaufwerk einrichten

[easy-tweet tweet="Ein Service ist ein Bündel von Nutzeffekten!" user="the_bsm_guy" hashtags="itsm,itil,siam"]

Was meinst Du? Sind das Services, unter der Definition, dass ein Service einen Nutzen für den Kunden haben soll?

Ja? Ganz klare Antwort: nein!

Hier geht es bunt durcheinander. SAP und eMail könnten durchaus Services in einer ersten Stufe eines Servicekatalogs angeboten werden. Die anderen sind auf keinen Fall Services. Sie haben keinen Nutzeffekt.

Installierst Du einem Kunden den Adobe Photoshop, hat er keinen Nutzen davon. Den Nutzen hat er erst, wenn er die Lizenz für die Software erwirbt.

Ein Projektlaufwerk hat einen Nutzeffekt, das bloße einrichten selbst nicht. Es ist ein Arbeitsschritt im Fullfilment-Prozess bei der Bestellung des Service „Projektlaufwerk“.

Drei Töpfe

In der Aufzählung geht es durcheinander. Ich denke in drei verschiedenen Töpfen:

1. Service
2. Service Request
3. IMAC – Install, Move, Add, Change

Bitte erinnere Dich an die Definition eines Service: Ein Service ist ein Bündel von Nutzeffekten. Durch die Nutzung eines Service entsteht im Prozess des Kunden ein Nutzen. Nimm den Service „Rechnung erstellen“. Das Ergebnis des Service ist eine gedruckte Rechnung, die der Kunde verschicken kann.

Der Output des Prozesses ist eine Rechnung, die die Liquidität des Unternehmens sichert. Der Prozess würde ohne den Service nicht den Output liefern können.

Wir diskutieren hier bitte nicht darüber, dass die Rechnung auch per Hand geschrieben werden könnte.

Was ist nun ein Service Request?

Die Definition in FitSM lautet: „Anwender-Anfrage nach Informationen, Beratung, Zugriff auf einen Service oder zur Einleitung eines vorautorisierten Change.“

Anders ausgedrückt: Ein berechtigter Nutzer kann vordefinierte Aktionen innerhalb eines Service auslösen.

Klingt auch nicht einfach, oder?

Lass uns konkret werden:

Kein Service Request ohne Service

Service „Rechnung erstellen“: Zu diesem Service kannst Du Service Requests definieren. Du überlegst Dir, welche Anfragen können Nutzer während der Nutzung des Services haben. Lass uns mal überlegen:

• Pflichtangaben auf Rechnungsvorlage ändern (Firmenanschrift, Vertretungsberechtigte und so weiter)
• Bankverbindung auf Rechnungsvorlage ändern
• Rechnungsvorlage anpassen

Du merkst, es ist gar nicht so einfach. Auch hier wieder die Aufforderung an Dich: Sprich mit Deinem Kunden darüber.

Hast Du das getan und ihr habt eine Liste möglicher Service Requests, dann darfst Du schauen, welche davon häufig auftreten. Diese solltest Du standardisieren, wenn möglich automatisieren und im Servicekatalog bereitstellen.

Zweites Beispiel. Nehmen wir den beliebten Service Projektverzeichnis. Mögliche Service Requests sind:

• Projektverzeichnis einrichten
• Speicherplatz Projektverzeichnis vergrößern
• Berechtigung für Projektverzeichnis hinzufügen
• Berechtigung für Projektverzeichnis entfernen
• Projektverzeichnis archivieren

Dir fallen bestimmt noch mehr ein.

Ganz wichtig: Ein Service Request steht nicht allein. Ein Service Request gehört immer zu einem oder mehreren IT-Services.

Ein Service Request ist selbst kein Service. Um einen Service Request anzufordern, brauche ich mindestens eine aktive Subscription für den Service. Wenn Du den Service Request „Bankverbindung auf Rechnungsvorlage ändern“ nimmst, dann ist Dir offensichtlich, dass es bei einigen Service Request noch die explizite Berechtigung für den Abruf geben muss.

Kurz zusammengefasst: Der Kunde realisiert mit Hilfe Deines Service einen Nutzen. Zu jedem Service gibt es Service Request, die der Kunde abrufen kann, um etwas im Zusammenhang mit der Servicenutzung zu beauftragen.

Und was ist jetzt IMAC?

Unter IMAC werden die Aktivitäten des Clientmanagements zusammengefasst:

• Install
• Move
• Add
• Change

Vorsichtig, jetzt werde ich fundamentalistisch: Der Client oder Arbeitsplatz an sich hat keinen Nutzen und ist damit kein Service. Ohne Service kein Service Request. Ich brauche eine eigene Kategorie für die Tätigkeiten rund um den Arbeitsplatz.

Lassen wir die Spitzfindigkeiten.

Was gehört jetzt dazu:

Install:

• Installation der Hardware
• Installation der Software
• Konfiguration für den Nutzer
• Aufbau am Arbeitsplatz

Move:

• Umzug des Arbeitsplatzes an einen anderen Standort
• Wechsel des Arbeitsplatzsystems
• Wechsel des Anwenders am Arbeitsplatzsystem

Add:

• Installation zusätzlicher Hardware
• Installation zusätzlicher Software

Change:

• Änderung der bestehenden Hardwarekonfiguration
• Aktualisierung der Software
• Einstellungen an installierter Software

 

Häufig werden dann noch zwei Leistungspakete definiert:

Remove:

• Hardware deinstallieren
• Festplatte sichern und vernichten
• Abbau, Vorbereitung zur Einlagerung und Entsorgung

Dispose

• Umweltgerechte Entsorgung
• Hardware Refresh

Eine ganze Gruppe von Service Requests, die Du unter den für Deine Organisation passenden Begriffen anbieten kannst.

Keine Angst, ich habe es gemerkt: Ich spreche jetzt von Service Requests. Auch wenn es keinen Service dafür gibt, sind das schöne Beispiel für Service Requests.

Und der Kunde?

Was findet sich jetzt im Servicekatalog wieder? Die Services natürlich.

Blöde Antwort – ich darf die Frage besser stellen: Was findet sich jetzt im Kundenfrontend wieder? Im Self Service Portal, IT-Shop oder wie auch immer das bei Dir heißt.

Alle Services und Service Requests, die ein Kunde über diese Schnittstelle anfordern würde und soll, solltest Du bereitstellen.

Zwei Kriterien sind zu prüfen:

1. Wird eine nennenswerte Anzahl von Kunden den Service Request jemals über das Kundenfrontend bestellen?

   Denke bitte an den Service Request „Bankverbindung auf Rechnungsvorlage ändern“. Das ist definitiv ein valider Request. Wird er so häufig abgefragt werden, dass es Dir Aufwand erspart ihn im Self Service anzubieten und noch zu automatisieren?
   Nein?
   Dann solltest Du den Platz im Portal auch nicht damit verschwenden. Es macht das Angebot für den Kunden nur unübersichtlich.

2. Ist es gewollt, dass der Kunde den Service Request direkt über das Frontend anfordert?

   Der Service Request „Postfach vergrößern“ ist ein valider Service Request, den sicher viele Nutzer gern anfordern würden. Politisch ist eine hohe Hürde zur Vergrößerung des Postfaches gewünscht? Dann würde ich den Service Request auch nicht ins Portal aufnehmen.

Beantwortest Du eine Frage mit nein, dann stelle den Service Request nicht für den Self Service bereit.

Wenn wir gerade das Thema Self Service streifen. Dazu habe ich zwei informative Gespräche mit Stefan Krause geführt:

• User Self Service – Selbstbedienung oder Saftladen?
• User Self Services für Fortgeschrittene

Zum Schluss noch eine wichtige Anregung: Du hast Deine Service Request definiert und bietest eine  Teil davon im Self Service Portal an. Denke bitte darüber nach, wie Du diese automatisieren kannst.

Du sparst so viel Zeit der Nutzer und Deiner Kollegen. Dafür lohnt sich der Aufwand für die Automatisierung auf jeden Fall. Es muss niemand manuell die Größe eines Shares ändern. Das können Tools oder einfache Skripte schnell und zuverlässig.

Es ist ein wirklich leicht erreichter Gewinn, die Service Requests zu automatisieren. Das beginnt nicht erst bei der technischen Realisierung. Schon ein eventueller Genehmigungsprozess sollte so weit wie sinnvoll automatisiert werden. Ohne, dass unnötige Eingriffe eines Menschen notwendig sind.