-- WEBONDISK OK --

03223 Schnell und pragmatisch zum IT-Servicekatalog – in drei einfachen Schritten und ohne ein großes Projekt

Der klassische IT-Servicekatalog macht wenig Appetit auf das Angebot. Im Gegenteil, häufig schreckt er durch technische Formulierungen ab. Der Kunde bekommt keine Idee davon, wozu die einzelnen Services nützlich sind. Der Servicekatalog ist ein wichtiges Element in der Kundenbeziehung. Das Angebot der IT-Abteilung oder des Providers darf in der Sprache des Kunden beschrieben werden. Dem Leser soll sofort klar werden, welchen Nutzen er mithilfe der einzelnen Services erreichen kann. Der Beitrag beschreibt drei pragmatische Schritte zu einem Servicekatalog:
Schritt 1: Services identifizieren und Servicebaum erstellen
Schritt 2: Eigenschaften eines Dienstes beschreiben und Service Level Agreements erstellen
Schritt3: Servicekatalog und Verrechnung
Arbeitshilfen:
von:
Für den schnellen Hunger
Stellen Sie sich vor, es ist 11:38 an einem Dienstag im Mai. Sie haben Hunger. Ihr Magen knurrt schon so laut, dass Ihre Kollegen es hören. Es muss schnell gehen, das nächste Meeting ist 12:30. Sie laufen über die Straße in den nächsten Supermarkt.
Es ist ein herrlicher, warmer Maitag – sie kommen etwas ins Schwitzen. Zum Glück ist es in der Tiefkühlabteilung kalt. Sie schauen in die Kühltruhen und trauen Ihren Augen nicht – alles weiße Verpackungen. Es steht nur etwas drauf geschrieben: Sparus aurata, Salmo salar oder Sander lucioperca. Und natürlich der Preis.
Sie verstehen nur Bahnhof: „Was soll das? Woher soll ich wissen, was da drin ist? Was soll ich kaufen.”
Sie verlassen das Geschäft und gehen nach nebenan in den Imbiss. Dort verstehen Sie, was angeboten wird, und es gibt sogar ein Bild zu jedem Angebot. Sie entscheiden sich für Currywurst mit Pommes.
IT-Talk
Das ist die Realität in vielen Unternehmen. Die weißen Verpackungen mit den unverständlichen Namen, das ist das Angebot der IT-Abteilung. Unsere Fachbegriffe sind CPU, RAM, Storage, Bandbreite, Transaktion und so weiter.
Der Imbiss nebenan ist im Falle des Unternehmens ein Cloudanbieter wie beispielsweise Salesforce. Der spricht nicht IT mit dem Vertrieb, sondern Vertrieb. Am 10.12.2015 stand auf der Webseite von Salesforce folgender Satz: „Die Sales Cloud nimmt Ihnen Arbeit ab, sodass Sie sich auf das Verkaufen konzentrieren können.” Genau das wollen die Fachbereiche.
Zurück zu den weißen Verpackungen im Supermarkt. Alle Unternehmen, die etwas verkaufen wollen, versuchen ein verführerisches Angebot mit tollen Namen zu erstellen. Das Ziel ist, dass der potenzielle Kunde durch Sprache und Bild animiert wird, dass Produkt zu kaufen. Es sollen positive Erinnerungen und damit Emotionen geweckt werden. Der Kunde darf auf den ersten Blick verstehen, was ihn erwartet.
Worte wecken Assoziationen
Deswegen steht auf der Tiefkühlfischpackung nicht Sparus aurata, Salmo salar oder Sander lucioperca sondern Dorade, atlantischer Lachs oder Zander. Dazu ein paar schöne Bilder, und Sie wissen sofort, was sie bekommen. Sie haben sofort positive oder negative Assoziationen und entscheiden, was sie kaufen wollen.
Speisekarte
Gastronomen gehen einen Schritt weiter und schmücken ihre Speisekarten mit tollen Gerichten wie beispielsweise:
Gebratener Seeteufel auf Wokgemüse mit Paksoi, Tandooriaroma, Wasabi und rosa Ingwer
Lachs-Saltimbocca – Lachsfilet mit Parmaschinken, frischem Salbei & Zitronensoße auf Bandnudeln
IT-Speisekarte
Ihnen läuft das Wasser im Mund zusammen? Gut so – denn das ist das Ziel. Die IT-Speisekarte sieht hingegen meist so aus:
Virtueller Server mittel – 2 vCPU, 4 GB RAM, 100 GB Storage, 100 Mbps, HA Homeshare – 100 GB, tägliche Datensicherung
WLAN – drahtloser Netzwerkzugang, 802.11 g
Mail – 10-GB-Postfach, tägliche Datensicherung, Kalender, mobiler Zugriff
Weckt das irgendwas in Ihnen, wenn Sie das lesen? Ja, sicher, Ihren technischen Sachverstand. Ist es das, was Sie wollen, wenn der Leiter der Buchhaltung oder die Vertriebschefin den IT-Servicekatalog in die Hand nimmt? Welche Gedanken hat der Buchhalter? „Warum kostet der Speicher im Unternehmen so viel, ich habe mir doch zu Hause gerade eine 6-TB-Festplatte für 299 EUR gekauft?”
Service
Oder soll er lieber auf den ersten Blick erkennen, welcher Service welchen Geschäftsprozess unterstützt. Ein Service ist „ein Bündel von Nutzeffekten”. Immer aus Sicht des Konsumenten. Ausgehend von diesen beiden Annahmen, erstellen Sie einen Servicekatalog in drei Schritten:
Schritt 1:
Services identifizieren und Servicebaum modellieren
Schritt 2:
Eigenschaften eines Dienstes beschreiben und Service Level Agreements definieren
Schritt 3:
Servicekatalog aufbauen

1 Services identifizieren

Business Services
Geht es um den Servicekatalog, sprechen wir von geschäftsfokussierten IT-Diensten – den sogenannten Business Services. Denn nur diese haben eine Relevanz für das Geschäft.
Reibungslose Kommunikation
Der erste Schritt ist es, die Prozesswelt des Nutzers zu verstehen. Womit schafft die Fachabteilung einen Wert für das Unternehmen? Welche Arbeitsabläufe sind kritisch? Es ist ein wichtiger Schritt, Prozesse, Arbeitsschritte und Sprache der Fachabteilungen zu verstehen. Damit wird die Grundlage für eine reibungslose Kommunikation zwischen den IT-Experten und den Anwendern gelegt.
Kernprozesse dokumentieren
Es ist nicht in jedem Unternehmen der Fall, dass die Kernprozesse dokumentiert und regelmäßig aktualisiert werden. Daher ist es in der Regel notwendig, die benötigten Informationen zu beschaffen und zu dokumentieren. Beginnen Sie mit dem wichtigsten Prozess Ihres Unternehmens und leiten Sie für diesen sinnvolle Services ab.
OBASHI Methode
Das Vorgehen startet oben – vom Geschäftsprozess bis zur Infrastruktur. Durch diese Fokussierung erreichen Sie schnell nutzbringende Ergebnisse. Sie können verifizieren, ob dadurch ein Nutzen für die Fachabteilung und die IT-Abteilung entsteht. Bedienen Sie sich dabei des OBASHI-Modells. OBASHI ist eine Methode zur strukturierten Dokumentation der Abhängigkeiten zwischen Menschen, Geschäftsprozessen und der IT [1].
Ownership und Business Process
Das Wort OBASHI ist ein Akronym. Die Buchstaben stehen für die einzelnen Schichten der Visualisierung, die Sie im Folgenden kennenlernen werden. Für die Identifikation der Services sind das O = Ownership und das B = Business Process notwendig. Unter Ownership verstehen wir hauptsächlich die Prozesseigner, -verantwortlichen oder -manager und die Menschen, die in den Prozessen arbeiten.
Nutzer einbinden
Vereinbaren Sie mit denen einen Termin – dauert in erster Lesung selten mehr als eine Stunde. Lassen Sie sich den Prozess erklären und visualisieren Sie ihn am Flipchart. Sollte es eine Prozessdokumentation geben, dann überprüfen Sie mit den Kollegen, ob diese aktuell ist.
In der Regel sind das auch für die Fachabteilung wertvolle Termine. Nicht selten gibt es unterschiedliche Auffassungen, wie ein Prozess läuft. So bekommen alle Seiten Klarheit.
Application
Im nächsten Schritt identifizieren Sie gemeinsam, welche Prozessteile IT-unterstützt sind und in welchen Applikationen diese ablaufen. Das A von OBASHI steht für Application.
In diesem Schritt entsteht dann ein Bild wie in Abbildung 1 – ein kleiner Ausschnitt aus einem Business- und IT-Diagramm für den Vertriebsprozess.
Abb. 1: Die ersten drei Schichten eines OBASHI-Business- und -IT-Diagramms
Applikationsverantwortliche einbinden
Jetzt ist der richtige Zeitpunkt, um die Applikationsverantwortlichen oder -administratoren mit einzubeziehen. Diese liefern Details über die Unterstützung der Geschäftsprozesse, Schnittstellen, Datenaustausch, Abhängigkeiten, Dienste und Applikationen, die die Nutzer nicht kennen. Damit entsteht ein vollständiges Bild. Sie wissen, welche Geschäftsprozessschritte in welchen Applikationen ablaufen.
Detaillierungsgrad festlegen
Sie dürfen jetzt auf der Basis der Darstellung am Flipchart oder im OBASHI-Diagramm entscheiden, auf welcher Flughöhe Sie Ihre Prozesse ansiedeln. Also in welchem Detaillierungsgrad. Der Prozessschritt „Angebot erstellen” unterteilt sich sicher noch in einige Arbeitsschritte.
Prüfen Sie, ob das aus Sicht Ihres Kunden einen Mehrwert bietet. Was erreichen Sie dadurch, was Sie ohne die Detaillierung nicht könnten? Nur dann ist es sinnvoll, kleinteilige Services zu definieren. Ansonsten abstrahieren Sie bitte sinnvoll.
Ergebnis
Das Ergebnis dieser sehr kommunikativen Arbeit:
Sie kennen die Prozesse dieser Fachabteilung.
Sie kennen den Kunden und wissen u. a., mit wem Sie zukünftige Changes abstimmen und mit wem Sie den SLA vereinbaren.
Sie kennen die Nutzer und damit die Servicekonsumenten.
Und Sie haben Ihre ersten geschäftsfokussierten IT-Dienste gefunden. Dies sind die Prozessschritte, die direkt von den Applikationen abhängig sind. Schauen Sie bitte die erweiterte Darstellung in Abbildung 2 an:
Abb. 2: Erweiterter Ausschnitt aus einem OBASHI-Business- und -IT-Diagramm in den ersten drei Schichten
Sprechende Servicenamen
Ihre Services sind „Angebot erstellen”, „Auftragsbestätigung erstellen”, „Preisanfrage”, „Lieferschein erstellen” und „Rechnung stellen”. Warum es so wichtig ist, dass der Service auch so heißt, wie er heißt, erfahren Sie gleich.
Hinweis
Zuvor noch ein Hinweis: Manchmal gibt es die Situation, dass man nicht mit den Fachbereichen sprechen darf oder möchte. Dann starten Sie bitte mit dem A. Führen Sie zusammen mit den Applikationsverantwortlichen ein „Reverse-Engineering” durch. Schließen Sie von den Applikationen auf die Prozesse. Meist haben die Applikationsverantwortlichen das Wissen dazu. Sie verbauen sich damit aber die Möglichkeit, mehr Vertrauen und mehr Nähe zur Fachabteilung aufzubauen.

2 Auf die richtigen Worte kommt es an

Erinnern Sie sich bitte an die Speisekarte des Fischrestaurants: Gebratener Seeteufel auf Wokgemüse mit Paksoi, Tandooriaroma, Wasabi und rosa Ingwer – lecker! Und das gleiche Gefühl wollen Sie mit Ihrem Service erreichen.
In der Sprache des Business
Der Leiter der Buchhaltung weiß sofort, was der Service „Rechnung stellen” für einen Nutzen bringt. Er hat die direkte Verbindung zur Arbeit seiner Abteilung. Er wird nicht mehr gezwungen, in IT zu denken. Er darf in seiner Fachwelt bleiben. Damit passieren für die IT-Abteilung sehr interessante Dinge:
Ein Benutzer kann beim Helpdesk anrufen und sagen, dass er Probleme beim Erstellen einer Rechnung hat. Da der Service in der CMDB mit den entsprechenden CIs und dadurch idealerweise auch mit dem Monitoring verknüpft ist, weiß der Bearbeiter sofort, worum es geht, und kann schon eine erste Diagnose stellen. Er kann das Ticket gezielter weiterleiten, ohne mit dem Nutzer technisch zu werden.
Genau andersrum funktioniert es im Change Management: Wird eine Änderung an einem CI geplant, können die betroffenen Geschäftsprozesse und damit Nutzer identifiziert werden. Eine gezielte Abstimmung und Kommunikation ist möglich.
Die Frage nach der Verfügbarkeit des Service wird objektiver beantwortet. Während heute meist die Standardantwort „immer” zu vernehmen ist, fällt sie bei geschäftsfokussierten IT-Diensten differenzierter aus. Sie fragen: „Wie lange können wir darauf verzichten, Rechnungen zu stellen?” Antwort: „Das geht schon mal eine Woche, aber am Monatsende müssen alle Rechnung innerhalb von drei Tagen raus!” – Zwischen drei Tagen und immer liegt viel Geld, das für eine übertriebene Hochverfügbarkeit gespart werden kann.
Das Reporting vereinfacht sich. Sie dürfen natürlich dann nicht mehr einzelne Applikationen oder gar Server berichten. Sie dürfen die Verfügbarkeit des Service „Rechnung stellen” ausweisen. Wie Sie den Service erbringen, ist Ihre Sache – Hauptsache das SLA ist kontinuierlich erfüllt und der Kunde zufrieden. Gleichzeitig können Sie prozessorientierte Messwerte vereinbaren und auswerten.
Die Abrechnung wird einfacher und für den Kunden überprüfbar. Aus Sicht eines Buchhalters ist es völlig sinnlos, eine Rechnung zu überprüfen, die verbrauchte CPU-Zeit, RAM und Bandbreite ausweist. Wie soll er das nachvollziehen? Warum rechnen Sie nicht zukünftig einen Preis pro erstellte Rechnung ab? Das ist für den Buchhalter leicht zu überprüfen, und Ihnen gibt es Freiheiten bei der Kalkulation des Preises.
Für den Erfolg des Servicekatalogs ist es entscheidend, dass Sie ihn in der Sprache Ihrer Kunden verfassen. Präsentieren Sie Ihr Angebot so, dass der Kunde auf den ersten Blick sieht, wozu die Dienste nützlich sind. Das erleichtert die Kommunikation und schafft Vertrauen.

3 Servicebaum erstellen

Um einige der beschrieben Vorteile zu realisieren, reicht es nicht aus, die Menschen, Prozesse und Applikationen zu kennen. Es erfordert auch Informationen über die Server, das Betriebssystem und den Rest der Infrastruktur. Für die Analyse der Ursache einer Störung oder der Auswirkung einer Veränderung ist das entscheidend.
OBASHI hilft strukturieren
Sie dürfen den Servicebaum nach unten vervollständigen. Im nächsten Schritt ermitteln Sie die verbleibenden drei Schichten des OBASHI-Modells (s. Abbildung 3).
Abb. 3: Die komplette Sicht auf zwei Services im OBASHI-Modell
System
S steht für das Betriebssystem (System), und das ist gleichzeitig die Schicht, die in der Praxis meist überflüssig ist. Welches Betriebssystem auf einem Server installiert ist, steht als Attribut in Ihrer CMDB.
Hardware und Infrastruktur
H repräsentiert die physische und virtuelle Hardware und I den „Rest” der Infrastruktur wie Netzwerk und Storage. Damit bekommen Sie ein komplettes Bild, welche Komponenten für die Erbringung eines Service notwendig sind.
Fokussieren
Konzentrieren Sie sich bitte auch hier auf Ihren Service und nehmen Sie in das Modell nur die Objekte auf, die dafür notwendig sind. Lassen Sie weg, was nicht dazu gehört – das kommt bestimmt später.
Die Fokussierung garantiert nützliche Ergebnisse in einem begrenzten Zeitraum. Alles andere läuft auf ein Asset-Management-Projekt hinaus und ist nicht zielführend. Vor allem dauert es viel zu lange.
Modellieren und Diskutieren ...
Modellieren Sie den ersten Service komplett bis zu Ende. Danach nehmen Sie die Zeichnung und diskutieren mit den gleichen Gruppen das Ergebnis. Es wird an einigen Stellen Änderungen geben. Die meisten werden die Zusammenhänge nämlich auch das erste Mal grafisch aufgearbeitet sehen. Das können Menschen besser verarbeiten. Diese Änderungen pflegen Sie ein und haben den ersten definierten Service.
... im Zyklus
Die Abbildung 4 zeigt den Bearbeitungszyklus im Prozess der Erstellung eines Service. Die beiden Eingangstore sind das initiale Projekt (Scope) und kontinuierlich das Change Management. Je nach Umfang und Komplexität dauert der gesamte Vorgang ein bis zwei Tage.
Abb. 4: Bearbeitungszyklus eines geschäftsfokussierten IT-Dienstes
Detailierungstiefe anpassen
Es kommt vor, dass Sie hier schon feststellen, dass Sie sich für die falsche Flughöhe entschieden haben, der Service also zu grob oder zu granular geschnitten ist. Dann ändern Sie das. Dank der fokussierten Vorgehensweise ist die Verschwendung ziemlich gering. Meist erkennen Sie dies nach der Modellierung von drei oder vier Services. Auch dann ist die dafür aufgewendete Zeit verschmerzbar und auch nicht umsonst. Die ermittelten Zusammenhänge sind weiterhin gültig, nur der Service wird anders geschnitten.
Visualisierung entscheidend
Die Darstellung und Dokumentation muss nicht als OBASHI-B&IT-Diagramm erfolgen. Sie können jede sinnvolle Visualisierungsform nehmen. Vielleicht bietet Ihre CMDB oder Ihre Architekturmanagementsoftware eine Möglichkeit, sowas zu strukturieren und zu visualisieren. Die Visualisierung ist entscheidend. Die Abbildung 5 zeigt die Sicht auf die Services in der Business-Service-Management-Lösung SM-VIEW.
Abb. 5: Darstellung eines Servicebaums in der Software SM-VIEW

4 Eigenschaften eines Dienstes beschreiben

IT-Service-Canvas
Mit der Identifikation der Services und der Modellierung des Servicebaums sind Sie den ersten Schritt gegangen – herzlichen Glückwunsch! Im nächsten beschreiben Sie den Service in verschiedenen Dimensionen.
Als Werkzeug bietet sich dazu das IT-Service-Canvas (vgl. Abbildung 6) an. Es enthält alle Punkte, über die es sich lohnt nachzudenken, wenn Sie eine profitable Service-Erbringung für zufriedene Kunden anstreben. Eine Vorlage für das IT-Service-Canvas haben wir Ihnen als Arbeitshilfe beigefügt.[ 03223_a.pdf]
Sie können sich zu einem kostenlosen Kurs für das Canvas anmelden. In zwölf E-Mails erläutert der Autor die Anwendung jedes einzelnen Felds in einer weitergehenden Beschreibung und Anleitung [2].
Abb. 6: IT-Service-Canvas
Kosten und Preis
Dadurch, dass Sie sich im ersten Schritte auf geschäftsfokussierten IT-Dienst konzentrieren, haben Sie die Punkte „Geschäftsprozess” und „Nutzer” schon erledigt. Der Servicebaum spiegelt Ihre „Architektur” wider und ist damit auch abgeschlossen. Mithilfe des Servicebaums können sie strukturiert die Servicegestehungskosten ermitteln und auf dieser Basis dann den Verrechnungspreis festlegen.
In diesem Schritt konzentrieren Sie sich bitte auf die Punkte „Nutzen” und „Service Level”.
Nutzen eines Service
Was ist der Nutzen eines Service aus Sicht des Endkunden bzw. Nutzers? Das ist die entscheidende Frage. Denn warum soll der Kunde den Service bezahlen? Diese Fragen stellen Sie sich bitte, auch und vor allem, wenn Sie als interne IT-Abteilung auftreten. Externe Provider wie Salesforce beantworten diese auf jeden Fall.
Den ersten Schritt haben Sie getan. Sie haben einen geschäftsfokussierten IT-Dienst definiert. Nehmen Sie bitte für die weitere Arbeit den Service „Angebot erstellen” als Beispiel. Er wird im Folgenden näher beschrieben.
Was ist der Nutzen
Welchen Nutzen hat der Service für den Nutzer?
Angebote erstellen!
O. k. Das ist sicher der primäre Nutzen. Gibt es noch weiteren Nutzen?
Problemlöser
Beantworten Sie diese Frage bitte zusammen mit Ihren Nutzern. Was soll der Service „Angebot erstellen” für Probleme lösen? Wenn es, wie in den meisten Fällen, ein existenter Service ist, welche Probleme löst er, was machen die Menschen mit dem Service?
So finden Sie weiteren primären und sekundären Nutzen. Die Tabelle 1 zeigt die primären und sekundären Nutzen für den Service „Angebot erstellen”.
Tabelle 1: Nutzenbeschreibung für den Service „Angebot erstellen”
Nutzen
Beschreibung
Erstellen von definitiven Angeboten
Der Servicekonsument kann Angebote erstellen und diese als definitives Angebot speichern.
Hinzufügen von Artikeln aus dem Artikelstamm
Der Servicekonsument kann ein Angebot basierende auf den im Artikelstamm verfügbaren Artikeln erstellen und diese dem Angebot in beliebiger Anzahl hinzufügen. Dabei erhält er Informationen über das Produkt, den Einkaufspreis (EK) und den empfohlenen Verkaufspreis (VK).
Hinzufügen von freien Artikeln
Der Servicekonsument kann eigene Artikel erstellen und so Artikel hinzufügen, die zum Zeitpunkt des Serviceabrufs nicht im Artikelstamm enthalten sind.
Anhängen von Lieferantenangeboten
Der Servicekonsument kann dem Angebot eine beliebige Zahl von Lieferantenangeboten in einem unterstützten Dateiformat hinzufügen.
Preisanfrage
Der Servicekonsument kann ein Angebot dem Einkauf zur Anfrage des aktuellen Preises und/oder der Anlage des freien Artikels im Artikelstamm übermitteln.
Rückmeldung von Fehlern bei der Preisanfrage
Jeglicher Fehler bei einer Preisanfrage wird dem Servicekonsumenten per E-Mail zurückgemeldet.
Angebotsprüfung
Alle Angebote werden vor dem Setzen des Status „definitiv” auf formale und inhaltliche Richtigkeit überprüft. Der Servicekonsument erhält eine Information über diese Prüfung direkt beim Ausführen der Angebotsprüfung. Ein Angebot kann nur definitiv gesetzt werden, wenn es alle Prüfungen besteht.
Aufbewahrung verschiedener Angebotsversionen
Der Servicekonsument kann verschiedene Versionen des Angebots erstellen. Die vorhergehenden Angebote werden ohne Zeitbeschränkung aufbewahrt.
Individueller Zuschnitt
Natürlich ist der Nutzen sehr spezifisch auf Ihren Kunden, seine Prozesse und Applikationen zugeschnitten. Genau das ist Ihr Vorteil als interner Provider. Das können nur Sie und nicht Salesforce. Das Beispiel ist einem konkreten Projekt entnommen.
Jetzt überlegen Sie zusammen mit den Applikationsverantwortlichen, ob es nennenswerte funktionale Parameter gibt, die der Kunde kennen sollte. Tabelle 2 zeigt die drei Parameter, die in diesem Beispiel relevant sind.
Tabelle 2: Funktionale Parameter des Service „Angebot erstellen”
Attribut
Service Level
Datentyp
Bronze
Silber
Gold
Maßeinheit
Servicespezifische funktionale Parameter
Zeichen für die Beschreibung eines Angebots
1.000
1.000
1.000
Zeichen
Maximale Zeit, die eine Preisanfrage dauert
24
24
12
Stunden
Unterstützte Dateiformate für Lieferantenangebote
*.doc, *.docx, *.xls, *.xlsx, *.pdf, *.sar
Dateiformat
Wenn sinnvoll und möglich, beginnen Sie schon bei der Nutzenbeschreibung und den funktionalen Parametern, in den einzelnen Service Levels, zu unterscheiden. Das hilft Ihnen, bei der Verrechnung je nach Nutzungsgrad zu differenzieren und verschiedene Preise zu bilden. Bitte nur, wenn dies von den Kunden nicht als künstliches Diversifizieren des Service wahrgenommen wird. Der größte Teil des Nutzens sollte in der untersten SLA-Kategorie verfügbar sein.
Eigenschaften eines Business Service
Das sind die wichtigsten Eigenschaften eines geschäftsfokussierten Service (Business Service). Folgende Parameter sind nützlich, und Sie sollten diese zusätzlich beschreiben:
Service-Erbringungspunkt: Wo kann der Nutzer den Service abrufen, auf seinem Arbeitsplatz-PC, auf einem Terminalserver, auf dem Tablet?
Service-Erbringungsbereitschaftszeiten: In welchem Zeitraum steht der Service dem Nutzer zur Verfügung?
Supportzeiten: In welchem Zeitraum kann der Nutzer den Service Desk anrufen, und es meldet sich ein Mensch am anderen Ende?
Supportsprachen: In welchen Sprachen kann der Nutzer mit dem Service Desk kommunizieren?
Auf diese Art und Weise beschreiben Sie einen Dienst so, dass der Kunde und Nutzer (auch Konsument genannt) genau weiß, was ihn erwartet. Genau das ist das Ziel. Einer der Hauptgründe für unzufriedene Benutzer und Kunden sind nicht erfüllte Erwartungen. Der Kunde erwartet eine Leistung, die Sie gar nicht leisten wollen oder können.
Wichtig
Daher ist es sehr wichtig, dass Sie einen Service so genau wie möglich aus Sicht des Kunden beschreiben. Mit der Servicebeschreibung steuern Sie die Erwartung und beugen Unzufriedenheit vor. Es ist dabei extrem wichtig, dass Sie sich auf die Sprache und die Prozesse Ihres Kunden konzentrieren.
Beigefügt finden Sie als Beispiel für den Service „Angebot erstellen” eine komplett ausgefüllte Servicebeschreibung im Excel-Format (Servicebeschreibung und Attribute basieren auf [3]). Dieser entnehmen Sie bitte die Werte der einzelnen Parameter. Im zweiten Tabellenblatt können Sie Ihre eigenen Dienste entwickeln und ausarbeiten.[ 03223_b.xlsx]

5 Service Level Agreements definieren

Das gleiche Ziel verfolgen Sie mit der Beschreibung der Eigenschaften, die in der Regel als SLA angesehen werden. Die bisher aufgestellte Servicebeschreibung ist Teil Ihres SLA. Dazu kommen noch messbare Werte. Diese sind in Tabelle 3 dargestellt.
Tabelle 3: SLA-Parameter des Service „Angebot erstellen”
Attribut
Service Level
Datentyp
Bronze
Silber
Gold
Maßeinheit
Service-Erfüllungszielwert
Verhältnis von Spezifikation, gemäß erbrachtem Service „Angebot erstellen” pro berechtigtem Servicekonsumenten
95
97
98
%
Service-Beeinträchtigungsdauer
4:00
02:30
01:00
hh:mm
Service-Erbringungsdauer
Maximal zulässige Dauer für die vollständige und abschließende Erbringung eines Service „Angebot erstellen” explizit an den abrufenden Servicekonsumenten
01:00
hh:mm
Service-Erbringungseinheit
Basisportion der Service-Erbringung an einen abrufenden Servicekonsumenten
Ein definiertes Angebot, das im System gespeichert ist und gedruckt oder als PDF gespeichert werden kann
 
Keine Angabe zur Verfügbarkeit
Sie finden hier bewusst keine Angabe zur Verfügbarkeit. Das hat zwei Gründe:
1.
Verfügbarkeit kann nie kontinuierlich gemessen werden. Messen Sie beispielsweise die Verfügbarkeit einer Webseite alle fünf Minuten und sie ist jedes Mal erreichbar, dann haben Sie eine Verfügbarkeit von 100 %. Jedoch sieht die Erfahrung der Nutzer anders aus, denn die stellen regelmäßig fest, dass die Webseite nicht verfügbar ist. Sie haben bei den Messungen einfach Glück gehabt.
2.
Kann der Service an verschiedenen Service-Erbringungspunkten abgerufen werden, dann sind Sie meist nicht in der Lage, an allen zu messen. Können die Nutzer per Smartphone zugreifen, können diese ein anderes Erlebnis haben als die Nutzer, die an ihrem Arbeitsplatz tätig sind.
Dieser nicht möglichen Objektivität trägt der Erfüllungszielwert Rechnung. Er wählt das Verhältnis von Abrufversuchen zu erfolgreichen Serviceabrufen und zwar pro Konsument. Ein subjektiver und schwer zu ermittelnder Wert. Es lohnt sich aber für Sie, darüber nachzudenken, wie sie ihn ermitteln können.
Relevante Messwerte
Zusätzlich dürfen Sie über geschäftsprozessrelevante Messwerte nachdenken. Dazu nehmen wir ein anderes Beispiel: „Webshop” – ein einfaches Beispiel, um die Idee zu verdeutlichen.
Die Frage ist: Welche Messwerte sind für die Business-Verantwortlichen relevant und stellen einen Wert dar? Folgende könnten das für einen Webshop sein:
Dauer der Suchanfrage nach einem Artikel
Zeit, die benötigt wird, um die Startseite vollständig zu laden
Zeit, die benötigt wird, um eine Produktseite zu laden
Gesamtdauer eines Einkaufsvorgangs: Artikel suchen, in den Warenkorb legen, zum Check-out gehen, anmelden, bezahlen und Bestellung abschließen
Für einen Onlineshop extrem wichtige Messwerte. Denn Nichtverfügbarkeit beginnt für den Kunden schon dann, wenn die Webseite langsamer reagiert als sonst. Der Kunde wechselt dann schnell zu einem anderen Shop und ist somit für das Unternehmen verloren.

6 Verrechnung

... in der Sprache des Kunden
Die Service-Erbringungseinheit ist auch ein ganz interessantes Attribut insbesondere dann, wenn es um Verrechnung geht. Auch die Verrechnung darf in der Sprache des Kunden erfolgen. Anstatt verbrauchte Rechenzeit und RAM zusammen mit ein paar GB Storage abzurechnen, können Sie ohne Weiteres auch jedes erstellte Angebot fakturieren.
Damit machen Sie Ihrem Kunden die Rechnungsprüfung ganz einfach. Sie erleichtern sich das Leben beim Kalkulieren der Servicegestehungskosten. Und Sie vermeiden den Einsatz von Softwareprodukten, die die technischen Verbrauchswerte ermitteln.
Preismodell
Der Service-Erbringspreis kann verschieden gestaltet werden (vgl. Tabelle 4).
Tabelle 4: Preismodell für den Service „Angebot erstellen”
Attribut
Service Level
Datentyp
Bronze
Silber
Gold
Maßeinheit
Service-Erbringungspreis
Pflicht: Service-Zugangspreis pro berechtigtem Servicekonsumenten und Kalendermonat
35,00
50,00
100,00
Verbraucherpreis 1: flatratebasiert
Festpreis pro berechtigtem Servicekonsumenten und Kalendermonat für jegliche Service-Menge
250,00
500,00
1.050,00
Verbraucherpreis 2:
einheitsbasiert
Festpreis pro konsumierter Service-Erbringungseinheit
7,50
15.00
25.00
Beispiele für Preismodelle
Da kann es helfen, wenn Sie sich die gängigen Preismodelle anderer Servicedienstleister anschauen:
Mobilfunk: Flatrate, volumen- oder einheitenbasiert
Pizza: pro Pizza (Grundpreis) plus Extra-Zutaten (nach Verbrauch)
Friseur: pro Haarschnitt und möglicher Zusatzleistungen
Flug: Grundpreis (Flug, Gebühren) + Extras (Sitzplatz, Getränke, Gepäck)
Orientieren Sie sich einfach daran und versuchen Sie dies bitte ernsthaft auf Ihre Services zu übertragen.

7 Servicekatalog erstellen

Alles beisammen!?
Sie haben jetzt alles beisammen:
Service, der einen Bezug zur Welt des Kunden hat
Servicebeschreibung, mit der Sie die Erwartung des Kunden steuern
Leistungsparameter (SLA), der zeigt, in welchen Grenzen Sie bereit sind zu liefern
Preismodell, mit dem Sie die Kosten plus Ihren Gewinn verrechnen können
Das alles in eine Excel-Liste oder einen Webshop gepackt, und schon ist der Servicekatalog fertig. – Oder nicht?
Versetzen Sie sich bitte wieder in die Lage Ihres Kunden. Sie haben aufgrund der Methodik nun ungefähr 165 geschäftsfokussierte Dienste – mal einige hundert mehr, mal einige weniger. Soll sich der Kunde jetzt daraus das zusammensuchen, was er benötigt? – Ist das ein gutes Einkaufserlebnis? – Nein! Was ist die Alternative?
Rollenmodell und Servicekatalog
Überlegen Sie bitte, welche Anker die Welt Ihres Kunden hat: Er hat Prozesse, er hat Abteilungen und er hat in der Regel ein explizites oder implizites Rollenmodell. Mitarbeiterrollen und die zugehörigen Stellenbeschreibungen sind der Schlüssel für einen sinnvollen Servicekatalog.
In der Buchhaltung sieht das wie in Abbildung 7 dargestellt aus.
Abb. 7: Rollen in der Buchhaltung
Rollen und ihre Prozesse
Sie sehen hier die Ownership-Ebene aus dem OBASHI-Modell. Ergänzt um die Business-Process-Schicht, ergibt sich das Bild (vgl. Abbildung 8), das Sie benötigen: die Zuordnung von Rollen zu den einzelnen Prozessen und damit Business Services in Ihrem Unternehmen.
Abb. 8: Rollen und ihre Prozesse bzw. Services
Im Servicekatalog können Sie nun den „Arbeitsplatz Lohnbuchhalter” und den „Arbeitsplatz Finanzbuchhalter” anbieten. Diese enthalten alle für die Arbeit notwendigen Dienste.
Einfache Auswahl
Aus Sicht Ihres Kunden ist das eine einfache Auswahl – eine einfache Entscheidung, die er zu treffen hat. Gleiches gilt für die Abrechnung – wenn Sie pro Arbeitsplatz abrechnen, dann kann der Leiter der Buchhaltung die Rechnung durch simples Nachzählen überprüfen.
Optionen
Die Services dürfen gern auch eine Option enthalten, dass PC, Mobiltelefon und One-Time-Password-Token gleich mitgeliefert werden. Möglicherweise braucht es das, denn es kann sein, das ein Mitarbeiter in mehreren Rollen tätig ist.
Es wird so sein, dass Mitarbeiter auch einzelne Dienste einer anderen Rolle benötigen. Dafür haben Sie die Dienste ja. Sie sollten die einzelnen Dienste nur nicht in den Vordergrund Ihres Servicekatalogs packen. Der Mensch ist ab einer gewissen Auswahl nicht mehr in der Lage zu entscheiden.

8 Fazit

Für Ihren Erfolg als interner Provider ist es entscheidend, dass Sie sich in die Welt Ihrer Kunden begeben. Das ist ihr Vorteil gegenüber externen Anbietern. Diese haben nicht das individuelle Prozesswissen aus Ihrem Unternehmen.
Damit haben Sie die Möglichkeit, die Art und Weise zu verändern, wie Services produziert, orchestriert, verkauft und gewartet werden. Die gezeigte Methodik zieht sich durch den gesamten Lebenszyklus eines Service.
An allen Stellen der IT darf ein Umdenken stattfinden. Die Technik ist Mittel zum Zweck. Im Fokus stehen der Kunde, seine Prozesse und die Menschen, die in den Prozessen arbeiten – in letzter Konsequenz die Endkunden Ihres Unternehmens.
Die Services begleiten Sie jeden Tag – egal ob im Incident oder Change Management. Es geht immer um den Service „Angebot erstellen”. Auch wenn ein neues Release der Customer-Relationship-Management-Software ausgerollt wird – es geht um Angebote. Genauso in der Configuration Management Database oder bei der Verrechnung.

Quellen

1
Informationen und kostenloser OBASHI-Kurs unter: different-thinking.de/obashi-kurs/
3
Huppertz, Paul G.: Webinar 06 „Die Service-Spezifizierung – Service-Qualität & Service-Preis, 2015-04-14, V03.01.02, de.slideshare.net/PaulGHz/webinar-06-die-servicespezifizierung-servicequalitt-servicepreis-20150414-v010000
 

Weiterlesen und „IT-Servicemanagement digital“ 4 Wochen gratis testen:

  • IT-Servicemanagement nach ISO 20000, IT Governance und IT Compliance
  • Zugriff auf über 220 Fachbeiträge und 160 Arbeitshilfen
  • Onlinezugriff – überall verfügbar


Sie haben schon ein Abonnement oder testen bereits? Hier anmelden

Ihre Anfrage wird bearbeitet.
AuthError LoginModal