Service Katalog

Service Request oder Service Katalog? Was ist der Unterschied?

Automatisierung ist heute hoch im Kurs. Erst recht innerhalb der IT. Seit sich die IT-Organisation vom reinen Zurufbetrieb hin zu einem kostenbewussten Dienstleister verändert, ist es wichtig, dass Aufträge verursachergerecht abgewickelt, dokumentiert und abgerechnet werden – und entsprechend möglichst rasch abgewickelt werden können. In einem Service Portal wird das Angebot der Standard-Services präsentiert und mittels workflow-gesteuerten Abläufen so abgewickelt, dass fachliche und finanzielle Autorisierungen rollenbasiert eingeholt werden.

Ich werde oft gefragt, ob ein solches Angebot im Service-Portal nicht eigentlich als Service Katalog der IT betrachtet werden kann. Respektive können nicht alle anderen Services ebenfalls in dieses Service Portal aufgenommen werden und als gesamthaftes Service-Angebot der IT-Organisation betrachtet werden? Für den IT-Anwender ist das Service-Portal irgendwie nachvollziehbar: hinter jeder Bestelloption ist ein Versprechen hinterlegt, bis wann mit der Auslieferung zu rechnen ist. Die Leistung ist für jedermann einfach nachvollziehbar. Macht doch irgendwie Sinn, oder?

Was ist ein Service?

Was ist ein Service?

Ist ein IT-Service Request also mit einem IT-Service gleichzusetzen? Ist es berechtigt, die Summe aller IT-Service Requests als Service Katalog zu bezeichnen? So abwegig ist die Frage nicht. Obschon der Prozess Request Fulfilment ein Aktions-Prozess in der Phase Service Operation und der Service Katalog ein Arbeitspaket aus der Phase Service-Design ist, hat es mehr Gemeinsamkeiten als man vielleicht denkt.

So einfach ist es aber nicht. Es ist wichtig, sich die Unterschiede zwischen einem IT-Service und einem Service Request vor Augen zu halten und entsprechend das Service-Angebot des Service Providers zu konzipieren. Ein IT-Service ist kein Service Request und sollte auch klar davon abgegrenzt werden. Egal wie die Bezeichnungen letztlich lauten:

Service Katalog

Service Katalog

  • Gemäss ITIL ist ein Service „eine Möglichkeit, einen Mehrwert für Kunden zu erbringen, indem das Erreichen der von den Kunden angestrebten Ergebnisse erleichtert oder gefördert wird. Dabei müssen die Kunden selbst keine Verantwortung für bestimmte Kosten und Risiken tragen.“
  • Ein Service Request ist eine formale Anfrage eines Anwenders nach etwas, das bereitgestellt werden soll, beispielsweise eine Anfrage nach Informationen oder Beratung, danach ein Passwort zurückzusetzen oder einen Arbeitsplatz für einen neuen Anwender zu installieren. Service Requests werden durch den Request Fulfilment Prozess gemanagt, normalerweise in Verbindung mit dem Service Desk. Service Request können mit einem Request for Change als Teil der Erfüllung der Anfrage verknüpft sein.

Diese eher theoretische Betrachtung hilft in einem ersten Schritt nicht wirklich weiter. Es ist nützlicher, wenn man eine praxisorientierte Sicht zu Recht legt. Ein IT-Service ist keine einzelne Benutzer-Transaktion wie eine Bestellung eines Druckers oder einer Office-Applikation wie beispielsweise Visio. Ein IT-Service ist vielmehr eine Vereinbarung mit dem Businessowner zur Nutzung einer Funktionalität über eine bestimmte Zeit. Es geht um die sicherere und verlässliche Bereitstellung von Business-Applikationen zur Nutzung für die Mitarbeiter zur Unterstützung in ihrer Business-Tätigkeit.

Ein Service Request ist demgegenüber ein auf Benutzer-Ebene ausgelöste Betriebs-Transaktion. Es ist klar auch eine Dienstleistung – aber eher eine Auftragsabwicklung gemäss vordefiniertem Transaktionsumfang.

Service Request Prozess

Service Request Prozess

Service Requests sind in aller Regel Bestandteil eines übergeordneten IT-Services. Ein IT-Service ist demzufolge Voraussetzung zur Beauftragung von bestimmten Service Requests. So ist beispielsweise ein IT-Service „Elektronischer Arbeitsplatz“ die Basis, respektive die Voraussetzung zur Möglichkeit, bestimmte arbeitsplatzerweitertende Bestellungen, respektive Service Request in Auftrag zu geben. Ein Service Request zur Aufschaltung einer Rolle in einer bestimmten Business-Applikation setzt den IT-Service zur Nutzung dieser Business-Applikation voraus.

Ein IT-Service berechtigt also zu einem oder mehreren Service Requests. Respektive basiert ein Service Request auf einem oder mehreren IT-Services. Eine Unterscheidung zwischen IT-Service und Service Requests ist daher sehr wichtig. Wie die Präsentation eines IT-Service-Katalogs und des Service-Requests technisch umgesetzt wird, bleibt bestimmt noch eine Herausforderung. Für die Kommunikation mit dem Business und den Benutzern ist eine klare Unterscheidung sehr zu empfehlen.


 

5 Comments
  • Eine mögliche Lösung.....

    22. April 2014 at 17:36

    ..am Beispiel des Core Service „Messaging“
    Dessen Capabilities:
    1. Empfangen und senden von emails
    2. Planen und verwalten von Meetings
    Das Ganze hat einen SLA zum Kunden (Service based SLA). So weit so gut. Was es aber jetzt auch noch gibt sind Child Services des Service Messaging (deren Qualitäten auch im SLA von Messaging beschrieben werden können inkl. Reaktionszeit und Realisierungszeit), die exclusiv nicht zu konsumieren sind, sondern nur in Kombination mit Messaging.
    1. Mailbox vergrößern
    2. Zusätzliche Zugriffsrechte (e.g. Sekretärin)
    3. Mailbox Data Restore
    Die letzten 3 sind quasi Teil eines „User Service Catalogue“ und können per RQF requestiert und dann realisiert werden (manuell oder automatisiert).
    Vorteile:
    Diese für einen User requestierbaren Services sind teil eines „managed“ Service Catalogue mit klaren Qualitäten (KPI´s & Metrics) und Verantwortlichkeiten (Service Owner). Alles da, alles drin.

  • Martin Andenmatten

    22. April 2014 at 18:00

    Ja, das ist ein gutes Beispiel. Der Service „Messaging“ ist also der Hauptservice, welcher die gelisteten Optionen als Service Requests berechtigt.

    Der Zusammenhang zwischen Services und Service Requests ist wichtig und hat letztlich auch kostenrelevante Konsequenzen. Die Grundlagen dazu sind wohl im SLA geregelt.

    Genauso wichtig ist aber auch die klare Abgrenzung zwischen Service und „abrufbare“ Optionen via Service Portal. Letztere sind in aller Regel operative Transaktionen, welche mit der Auslieferung abgeschlossen sind.

  • Peter Bergmann

    23. April 2014 at 05:56

    Eine interessante Fragestellung Herr Kollege, die sich lohnt, etwas Zeit und Gedanken zu investieren…

    In der Tat: derzeit scheinen sich viele Beraterkollegen auf das zu stürzen, was gemeinhin als Service Katalog angesehen wird. Neben dem CMS/der CMDB ist der Katalog schon auch eines der wichtigsten Instrumente in der Serviceorientierung. Selten gut, meistens nach Gusto der IT-Organisation verfasst.

    Ein Blick zu Service Providern mit langer Geschäftserfahrung zeigt uns: das Leistungsangebot ist in Form von Fahrplänen, Dienstleistungsaushängen usw. klar ablesbar. Als Service Konsument informiere ich mich bspw. über das Angebot der Bahn, wenn ich von A nach B zu einer bestimmten Zeit und mit gewissen Komfortansprüchen will.

    Oder aber am Fenster des Friseurs steht „Waschen, Schneiden, Föhnen für 15 € (ohne Wartezeit)“. Als Kunde und Konsument zugleich greif doch zu. Würde ich jetzt (mal rein theoretisch) meine zunehmend grauen Haare einfärben lassen wollen, dann hätte ich eine Nachfrage dazu. Der Friseur kann sagen „Machen wir nicht“ oder „Das kostet 37,50€“ oder, oder, oder. In jedem Fall weiß er, ob er als Dienender (Service Geber) diese Nachfrage bedienen kann (will) oder nicht.

    Genauso sehe ich den Service Katalog. Zu einem „SAP-Verbucher Service“ kann ich bestimmte Berechtigungen, bspw. als Stellvertreter für einen bislang nicht zugänglichen Rechnungs-/Kundenkreis anfordern. Oder aber nach 2 Wochen Urlaub fällt mir bei Passwort nicht mehr ein, oder ich habe schlicht ein Verständnisproblem, weil ich einen Report in der geforderten Art und Weise so noch nie erstellt habe.

    Für mich sind „Farbe färben“ oder „Support beim Erstellen eines Reports“ Geschäftsvorfälle, in der jeweiligen Zeile zum Service im Angebotskatalog. In jeder Schnittmenge von „Service Definition“ und „Geschäftsvorfall“ findet sich ein Ereignis (Event) welches nach fest vorgegebener SOP (Standard Operating Procedure) abgearbeitet wird. Dreh- und Angelpunkt ist der Service Desk, da dieser u.a. im Request Fulfilment die Bearbeitungen steuert, lenkt oder leitet bzw. die Abarbeitung von Tasks eines Workflows überwacht.

    Alles in allem wird so der Service Katalog für den Konsumenten erlebbar:
    – Er kann seine relevanten Services nebst KPIs als berechtigter Service Konsument einsehen
    – Er kann für seine Service (anfordernd, verändernd, abbestellend) Requests aufgeben, sofern es möglich ist
    – Der Service Provider kann für (zusätzliche) Services/Service Requests Einnahmen generieren

    Nach meiner Einschätzung kann es kein Service Request Management ohne ein Angebot/einen Katalog geben. Beides hängt ursächlich und direkt miteinander zusammen. Wir Beratende müssen das klar und deutlich voneinander treffen und vor allem in den Projekten mit den Kunden daran arbeiten, dass ein verständlicher Service Katalog als wichtiges Arbeitsinstrument im Service Management unabdingbar ist. Für den Service Konsumenten/Kunden ebenso wie für den Service Provider mit seinen Suppliern (sofern vorhanden)

  • Martin Andenmatten

    24. April 2014 at 04:19

    Vielen Dank Herr Bergmann,

    wichtig ist aber schon auch, dass die Service Requests grundsätzlich vordefiniert und als Angebot klar ersichtlich sin. Wenn ich „Haare färben“ nicht als Standard-Angebot habe, muss ich einen Weg finden, über diese Anfrage zu entscheiden. Entweder weise ich höflich aber bestimmt ab. Oder aber, ich überlege mir, ob das ein Angebot ist, dass mehere Kunden interessieren könnte und ich versuche so einen Standard-Service nach entsprechender Abklärung, Aneignung und Qualitätskontrolle aufzunehmen.

    Wenn der Service Desk sich so in Szene bringen kann, kann er sich aus dem ungeliebten HelpDesk-Dasein emanzipieren und als erweiternder Kundenservice-Desk präsentieren.

  • Peter Bergmann

    24. April 2014 at 19:55

    So, genauso Herr Kollege habe ich gemeint.

    Die Geschäftsvorfälle zu einem Service (auch Service Requests) sind, müssen vordefiniert sein. Beim Eintreten eines Vorfalls wird gehandelt.

    Sollte die Anfrage nicht vorbereitet sein und somit gar nicht gestellt werden können, dann kann diese auch nicht bedient werden. Unabhängig von einer späteren Aufnahme in das Portfolio.

    Wenn also mein Friseur noch nie Haare gefärbt hat, wäre er gut beraten, meinen Wunsch abschlägig zu bescheiden. Würde er sich versuchen wollen, das graue Haar zu überdecken und sich dabei vertun, hätte er es womöglich mit gut 15-jähriger Fitnesstrainingerfahrung zu tun.

Post a Comment