1. Grundlagen des professionellen Service Managements

1.1 Warum professionelles Service Management notwendig ist

Kurz erklärt

Unternehmen und öffentliche Einrichtungen sind in hohem Maß von digitalen Produkten und Services abhängig.

Ein funktionierender Server allein erzeugt jedoch noch keinen verlässlichen Service. Erst das abgestimmte Zusammenspiel von Technik, Menschen, Arbeitsweisen, Informationen und externen Partnern ermöglicht stabile und nutzbare IT-Services.

Professionelles Service Management hilft dabei, dieses Zusammenspiel planbar, nachvollziehbar und kontinuierlich verbesserbar zu gestalten.

Vom technischen System zum nutzbaren Service

Fachinformatiker für Systemintegration arbeiten täglich mit technischen Komponenten wie:

Für Benutzer und Organisationen ist jedoch normalerweise nicht die einzelne technische Komponente entscheidend.

Sie benötigen einen funktionierenden Service.

Technische Komponenten Unterstützter Service
Domain Controller, DNS, Netzwerk und Benutzerkonto Anmeldung am Arbeitsplatz
Mailplattform, Identitätsdienst, DNS und Internetzugang E-Mail-Kommunikation
Fileserver, Berechtigungen, Netzwerk und Backup zentrale Dateiablage
VPN-Gateway, Firewall, MFA und Benutzerkonto sicherer Fernzugriff
Webserver, Datenbank, Zertifikat und DNS Unternehmensanwendung
Druckserver, Treiber, Netzwerk und Drucker zentraler Druckservice

Ein Service kann aus vielen technischen und organisatorischen Bestandteilen bestehen.

Fällt eine wichtige Abhängigkeit aus, kann der gesamte Service für den Benutzer nicht mehr nutzbar sein.

Merke

Benutzer nehmen normalerweise keinen einzelnen Server oder Netzwerkdienst wahr.

Sie nehmen wahr, ob sie ihre Arbeit ausführen können.

Warum technische Kompetenz allein nicht ausreicht

Technisches Fachwissen ist unverzichtbar.

Es hilft unter anderem dabei:

Im laufenden IT-Betrieb müssen zusätzlich organisatorische und servicebezogene Fragen beantwortet werden:

Diese Fragen können nicht allein durch einen technischen Befehl oder ein Administrationswerkzeug beantwortet werden.

Dafür wird eine abgestimmte Arbeitsweise benötigt.

Was professionelles Service Management leistet

Professionelles Service Management schafft einen gemeinsamen Rahmen für die Planung, Bereitstellung, Unterstützung, Steuerung und Verbesserung von Services.

Es unterstützt insbesondere dabei:

ITIL stellt hierfür ein anpassbares Best-Practice-Framework bereit.

ITIL Version 5 betrachtet digitales Produkt- und Service-Management stärker als zusammenhängende Aufgabe. Dadurch sollen Produkt-, Entwicklungs-, Betriebs-, Support- und Serviceteams besser zusammenarbeiten und Entscheidungen stärker an Outcomes und Wert ausrichten.

ITIL-Grundlage

ITIL ist kein starres Regelwerk.

Die Inhalte müssen an Ziele, Größe, Risiken, Fähigkeiten und Arbeitsweise der jeweiligen Organisation angepasst werden.

Service Management ist mehr als ein Ticketsystem

Ein Ticketsystem kann Service Management unterstützen.

Es kann beispielsweise:

Das Ticketsystem allein sorgt jedoch nicht automatisch für professionelles Service Management.

Zusätzlich muss geklärt sein:

Typischer Fehler

Die Einführung eines Ticketsystems wird mit der Einführung von Service Management gleichgesetzt.

Ein Werkzeug kann eine Arbeitsweise unterstützen, aber keine fehlenden Verantwortlichkeiten, Regeln oder Entscheidungen ersetzen.

Service Management ist keine einzelne Practice

Professionelles Service Management besteht nicht nur aus Incident Management oder Ticketbearbeitung.

Es verbindet verschiedene Management Practices und Arbeitsbereiche, beispielsweise:

Diese Practices können innerhalb eines Vorgangs zusammenwirken.

Beispiel:

  1. Das Monitoring erkennt den Ausfall eines Webdienstes.
  2. Ein Incident wird erfasst.
  3. Betroffene Benutzer werden informiert.
  4. Die technische Analyse stellt eine fehlerhafte Konfiguration fest.
  5. Eine Zwischenlösung stellt den Service wieder her.
  6. Ein Problem Record wird für die weitere Ursachenanalyse angelegt.
  7. Eine dauerhafte Korrektur wird als Change geplant und umgesetzt.
  8. Die Lösung wird im Wissensmanagement dokumentiert.
  9. Monitoring und Arbeitsanweisungen werden verbessert.

Keiner dieser Schritte ersetzt die technische Fehleranalyse.

Die beteiligten Practices helfen jedoch dabei, die technische Arbeit koordiniert, nachvollziehbar und nachhaltig durchzuführen.

Was ohne gemeinsame Arbeitsweise häufig passiert

Fehlt eine abgestimmte Service-Management-Arbeitsweise, können typische Schwierigkeiten entstehen.

Situation Mögliche Folge
Meldungen erfolgen nur telefonisch oder per Zuruf. Vorgänge gehen verloren oder werden nicht nachvollziehbar dokumentiert.
Jeder Mitarbeiter priorisiert nach eigenem Gefühl. Lautstärke oder persönliche Nähe bestimmen die Reihenfolge.
Verantwortlichkeiten sind unklar. Vorgänge werden weitergereicht oder bleiben unbearbeitet.
Änderungen werden nicht dokumentiert. Spätere Störungen lassen sich nur schwer mit früheren Eingriffen verbinden.
Lösungen bleiben im Wissen einzelner Mitarbeiter. Kollegen führen dieselbe Analyse wiederholt durch.
Teams betrachten nur ihre eigene Komponente. Die tatsächliche Serviceauswirkung wird übersehen.
Benutzer erhalten keine Statusinformationen. Unsicherheit und zusätzliche Rückfragen erhöhen den Arbeitsaufwand.
Wiederkehrende Incidents werden nur einzeln behoben. Die zugrunde liegende Ursache bleibt bestehen.
Kennzahlen betrachten nur Ticketmengen. Ergebnisse, Nutzen und Servicequalität bleiben unklar.
Externe Dienstleister werden zu spät eingebunden. Eskalation und Wiederherstellung verzögern sich.

Praxistipp

Wenn mehrere Mitarbeiter denselben Vorgang grundlegend unterschiedlich bearbeiten würden, fehlt möglicherweise eine gemeinsame oder ausreichend dokumentierte Arbeitsweise.

Praxisbeispiel: Der E-Mail-Service ist gestört

Mehrere Benutzer melden, dass sie keine E-Mails senden können.

Eine technische Betrachtung könnte mit folgenden Prüfungen beginnen:

Diese Prüfungen sind notwendig.

Professionelles Service Management ergänzt weitere Fragen.

Servicebezogene Einordnung

Kommunikation

Technische Bearbeitung

Nach der Wiederherstellung

Hinweis

Ein Major Incident ist ein besonders schwerwiegender Incident.

Die Kriterien, Rollen, Kommunikationswege und Eskalationsverfahren werden von der jeweiligen Organisation festgelegt. Major Incident Management wird hier nicht als eigenständige ITIL Practice behandelt.

Merke

Die technische Wiederherstellung ist ein zentraler Teil der Arbeit.

Professionelles Service Management sorgt dafür, dass Auswirkungen, Kommunikation, Verantwortung, Dokumentation und Verbesserung ebenfalls berücksichtigt werden.

Lokale Optimierung kann dem gesamten Service schaden

Ein einzelnes Team kann seine technische Aufgabe korrekt erfüllen und trotzdem den gesamten Service beeinträchtigen.

Beispiel:

Ein Netzwerkadministrator verschärft eine Firewall-Regel.

Die Änderung kann die Sicherheit einer einzelnen Komponente verbessern.

Wurde jedoch nicht geprüft, welche Anwendungen und Services von der bisherigen Verbindung abhängen, können wichtige Geschäftsprozesse ausfallen.

Eine ganzheitliche Betrachtung berücksichtigt deshalb:

Die vier Dimensionen

ITIL verwendet vier Dimensionen, um digitales Produkt- und Service-Management ganzheitlich zu betrachten.

Dimension Typische Inhalte
Organisationen und Menschen Rollen, Fähigkeiten, Kommunikation, Kultur und Verantwortlichkeiten
Informationen und Technologie Daten, Anwendungen, Infrastruktur, Wissen und Werkzeuge
Partner und Lieferanten Hersteller, Provider, Verträge und externe Abhängigkeiten
Wertströme und Prozesse Abläufe, Aktivitäten, Übergaben, Kontrollen und Zusammenarbeit

Keine Dimension sollte dauerhaft isoliert betrachtet werden.

Beispiel:

Eine technisch leistungsfähige Anwendung kann trotzdem scheitern, wenn:

Merke

Ein Serviceproblem ist nicht automatisch ausschließlich ein Technikproblem.

Gemeinsame Sprache statt Missverständnisse

Unterschiedliche Teams verwenden häufig unterschiedliche Begriffe.

Beispiele:

Werden diese Begriffe nicht einheitlich verwendet, können Missverständnisse entstehen.

Ein Benutzer meldet beispielsweise ein „Problem“.

Im allgemeinen Sprachgebrauch ist das verständlich.

Im Service-Management-Kontext muss jedoch zunächst geprüft werden, ob es sich um:

handelt.

Eine gemeinsame Sprache erleichtert:

Wichtig

Benutzer müssen nicht zwingend die offiziellen ITIL-Begriffe kennen.

Die korrekte fachliche Einordnung ist Aufgabe der zuständigen Service- und Supportorganisation.

Verantwortung muss über einzelne Komponenten hinausgehen

In technischen Umgebungen werden Verantwortlichkeiten häufig nach Komponenten verteilt.

Beispiele:

Ein Service kann von allen diesen Bereichen gleichzeitig abhängen.

Folgende Situation ist möglich:

Netzwerk funktioniert.
Server funktioniert.
Datenbank funktioniert.
Anwendung läuft laut Monitoring.
Der Benutzer kann trotzdem nicht arbeiten.

Service Management ergänzt die technische Komponentenverantwortung um eine Ende-zu-Ende-Sicht:

Wert entsteht nicht allein durch Bereitstellung

Ein Service erzeugt nicht automatisch Wert, nur weil er technisch bereitgestellt wurde.

Eine VPN-Lösung kann:

sein.

Wenn Benutzer jedoch:

wird das erwartete Outcome möglicherweise nicht erreicht.

ITIL Version 5 betrachtet Wertschöpfung als Zusammenarbeit zwischen Service Provider, Service Consumer und weiteren Stakeholdern.

Bei der Bewertung können unter anderem berücksichtigt werden:

Merke

Ein technisch verfügbarer Service ist nicht automatisch ein brauchbarer oder wertvoller Service.

Service Management bedeutet nicht maximale Bürokratie

ITIL schreibt Organisationen nicht vor, jeden Ablauf möglichst umfangreich zu dokumentieren.

Eine Arbeitsweise muss zum jeweiligen Kontext passen.

Ein kleines Unternehmen benötigt möglicherweise:

Eine große oder stark regulierte Organisation benötigt möglicherweise:

Grundsatz

So viel Struktur wie nötig, aber nicht mehr Komplexität als sinnvoll.

Eine übermäßig komplizierte Arbeitsweise kann:

Eine zu schwache Arbeitsweise kann dagegen:

Was professionelles Service Management nicht bedeutet

Professionelles Service Management bedeutet nicht:

Es bedeutet vielmehr:

Bedeutung für Fachinformatiker für Systemintegration

Fachinformatiker für Systemintegration sind häufig an mehreren Stellen eines Service beteiligt.

Zu ihren Aufgaben können gehören:

Service Management hilft dabei, diese technischen Tätigkeiten in einen größeren Zusammenhang einzuordnen.

Technische Tätigkeit Zusätzliche Service-Management-Frage
Dienst neu starten Wurde die Wiederherstellung geprüft und ist eine weitere Ursachenanalyse notwendig?
Firewall-Regel ändern Wer ist betroffen, welches Risiko besteht und wie sieht der Rückfallplan aus?
Benutzerkonto entsperren Handelt es sich um einen Incident oder einen Service Request?
Server patchen Wie werden Test, Freigabe, Wartungsfenster und Kommunikation organisiert?
Monitoring-Alarm bearbeiten Ist das Event relevant und muss ein Incident erfasst werden?
neue Hardware einbauen Müssen Asset- und Konfigurationsinformationen aktualisiert werden?
Fehler dauerhaft beheben Müssen Problem Management und Change Management einbezogen werden?
Lösung dokumentieren Wer benötigt dieses Wissen und wie wird es auffindbar gemacht?
Backup kontrollieren Wurde nur der Sicherungslauf oder auch die Wiederherstellbarkeit geprüft?

Wie ein serviceorientierter Systemintegrator denkt

Ein serviceorientierter Systemintegrator fragt nicht nur:

Welche Komponente ist defekt?

Er fragt zusätzlich:

Diese Denkweise verhindert nicht jede Störung.

Sie hilft jedoch dabei, Störungen kontrollierter, nachvollziehbarer und nachhaltiger zu behandeln.

Erste Orientierung in einer neuen Organisation

Wenn du in einer neuen IT-Abteilung beginnst, solltest du frühzeitig herausfinden:

Praxistipp

Lerne nicht nur die technische Infrastruktur kennen.

Lerne auch, welche Services davon abhängen und wer bei Störungen oder Änderungen beteiligt werden muss.

Anzeichen für unzureichendes Service Management

Folgende Beobachtungen können darauf hinweisen, dass Arbeitsweisen verbessert werden sollten:

Ein einzelnes Anzeichen beweist noch kein grundsätzliches Organisationsproblem.

Wiederholen sich mehrere dieser Muster, sollte die zugrunde liegende Arbeitsweise untersucht werden.

Entscheidungshilfe: Wird mehr Struktur benötigt?

Prüfe folgende Fragen:

Werden mehrere Fragen mit Ja beantwortet, besteht wahrscheinlich Verbesserungsbedarf.

Die Lösung ist jedoch nicht automatisch ein möglichst umfangreicher Prozess.

Zuerst sollte festgestellt werden:

  1. Welches konkrete Problem besteht?
  2. Welche Auswirkungen verursacht es?
  3. Welche bestehende Arbeitsweise funktioniert bereits?
  4. Welche kleinste sinnvolle Verbesserung ist möglich?
  5. Wie lässt sich ihre Wirkung überprüfen?

Checkliste für den Arbeitsalltag

Wenn du eine technische Aufgabe erhältst, prüfe zusätzlich:

Schnellzusammenfassung

Technik

stellt Komponenten und Funktionen bereit.

Service Management

verbindet Technik mit Menschen, Arbeitsweisen, Informationen, Partnern und den Zielen der Organisation.

Professionelle IT-Arbeit

entsteht, wenn technische Kompetenz und serviceorientierte Arbeitsweise zusammenwirken.

Vom technischen Baustein zum geschäftlichen Ergebnis

Technische Komponenten
↓
digitales Produkt
↓
nutzbarer Service
↓
Outcome für Benutzer und Organisation
↓
wahrgenommener Wert

Technische Komponenten bilden die Grundlage.

Der eigentliche Nutzen entsteht jedoch erst, wenn daraus ein funktionierender Service entsteht, der ein benötigtes Outcome unterstützt.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zur gemeinsamen Wertschöpfung, zu den vier Dimensionen, zur Integration von Produkten und Services sowie zur Ausrichtung auf Outcomes, Kosten, Risiken, Erfahrung und Nachhaltigkeit wurden anhand der genannten offiziellen ITIL- und PeopleCert-Quellen geprüft.

Die Praxisbeispiele, Checklisten, Entscheidungshilfen und betrieblichen Hinweise sind zusätzliche, herstellerneutrale Praxisempfehlungen dieses Nachschlagewerks.

Sie stellen keine wörtlichen ITIL-Definitionen und keine vorgeschriebenen ITIL-Prozesse dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

1.2 Technik, Produkt, Service und Geschäftsergebnis

Kurz erklärt

Technische Komponenten sind die Bausteine einer IT-Lösung.

Ein digitales Produkt bündelt technische und organisatorische Fähigkeiten.

Ein Service macht diese Fähigkeiten für Benutzer oder Kunden nutzbar.

Entscheidend ist am Ende nicht nur, ob einzelne Systeme funktionieren, sondern ob Benutzer und Organisationen mit ihrer Hilfe das gewünschte Ergebnis erreichen.

Warum diese Unterscheidung wichtig ist

Im IT-Arbeitsalltag werden Begriffe wie System, Produkt, Service, Leistung und Ergebnis häufig miteinander vermischt.

Der Begriff „E-Mail-System“ kann beispielsweise Folgendes bezeichnen:

Diese Bedeutungen hängen zusammen, sind aber nicht identisch.

Für professionelles Produkt- und Service-Management muss erkennbar sein:

Merke

Ein technisch funktionierendes System ist eine notwendige Grundlage.

Entscheidend ist jedoch, ob der damit unterstützte Service für die Benutzer zuverlässig nutzbar ist und das erwartete Ergebnis ermöglicht.

Die Betrachtungsebenen

Für die praktische Einordnung unterscheiden wir folgende Ebenen:

Ebene Zentrale Frage Beispiel
Technische Komponente Aus welchen einzelnen Bausteinen besteht die Lösung? Server, Switch, Datenbank, Zertifikat
Technisches System Wie arbeiten mehrere Komponenten zusammen? E-Mail-Plattform
Digitales Produkt Welche gebündelte digitale Fähigkeit wird verwaltet und weiterentwickelt? Kommunikations- und Kollaborationsplattform
Service Wie wird diese Fähigkeit für Benutzer oder Kunden nutzbar gemacht? E-Mail- und Kalender-Service
Output Was wurde technisch erstellt oder bereitgestellt? Benutzerpostfach wurde angelegt
Outcome Welche Wirkung oder welches Ergebnis wurde erreicht? Mitarbeiter kann kommunizieren
Wert Welchen Nutzen nehmen die beteiligten Stakeholder wahr? zuverlässige Zusammenarbeit und Zeitersparnis

Diese Ebenen bilden keine starre lineare Kette.

Ein digitales Produkt kann mehrere Services ermöglichen.

Ein Service kann wiederum mehrere Produkte, Plattformen, Systeme und externe Leistungen verwenden.

Technische Komponenten

Technische Komponenten sind einzelne Bausteine, aus denen Systeme, Produkte und Services aufgebaut werden.

Dazu gehören beispielsweise:

In einem Konfigurationsmanagement können relevante Bestandteile als Configuration Items erfasst werden.

Ob ein Bestandteil als Configuration Item verwaltet wird, hängt davon ab, ob seine Informationen für die Bereitstellung, Steuerung, Unterstützung oder Wiederherstellung eines Service benötigt werden.

Praxisbeispiel

Für einen VPN-Service können unter anderem folgende Komponenten notwendig sein:

Jede einzelne Komponente kann technisch funktionieren.

Trotzdem kann der gesamte VPN-Service unbrauchbar sein, wenn die Komponenten nicht korrekt zusammenarbeiten.

Technisches System

Ein technisches System entsteht durch das koordinierte Zusammenwirken mehrerer Komponenten.

Beispiele:

Technisches System Mögliche Komponenten
Verzeichnisdienst Domain Controller, DNS, Datenbank, Replikation und Zeitquelle
E-Mail-System Mailplattform, Identitätsdienst, DNS, Zertifikate und Spamfilter
Webplattform Webserver, Datenbank, Load Balancer, DNS und Speicher
Virtualisierungsplattform Hosts, Hypervisor, Netzwerk, Storage und Managementsystem
Backup-System Backupserver, Agenten, Speicherziele, Zugangsdaten und Zeitpläne

Ein technisches System wird häufig aus Sicht der Architektur und Administration betrachtet.

Dabei stehen Fragen im Mittelpunkt wie:

Diese Sicht ist für Fachinformatiker für Systemintegration unverzichtbar.

Für die vollständige Bewertung eines Service reicht sie allein jedoch nicht aus.

Was ist ein digitales Produkt?

Ein digitales Produkt bündelt Fähigkeiten, mit denen für Benutzer, Kunden oder die eigene Organisation nutzbare Ergebnisse ermöglicht werden.

Ein digitales Produkt kann unter anderem bestehen aus:

Beispiele für digitale Produkte:

Ein digitales Produkt wird über seinen gesamten Lebenszyklus betrachtet.

Dazu gehören unter anderem:

Wichtig

Ein digitales Produkt ist nicht zwingend nur eine einzelne Anwendung.

Es kann aus vielen technischen und organisatorischen Bestandteilen bestehen.

Produkt und Service gehören zusammen

ITIL Version 5 betrachtet digitale Produkte und Services als eng miteinander verbundene Bestandteile einer digital unterstützten Lösung.

Ein Produkt stellt Fähigkeiten bereit.

Ein Service ermöglicht es Benutzern oder Kunden, diese Fähigkeiten sinnvoll zu verwenden.

Beispiel:

Betrachtung Kommunikationsplattform
Produkt technisch und organisatorisch verwaltete Kommunikations- und Kollaborationsplattform
Services E-Mail, Kalender, Kontakte, Chat, Videokonferenzen und Dateifreigabe

Produkt und Service sind dabei keine voneinander unabhängigen Welten.

Probleme entstehen häufig, wenn Produktentwicklung, Betrieb und Support getrennt arbeiten und wichtige Anforderungen zu spät berücksichtigen.

Mögliche Folgen sind:

Merke

Ein Produkt stellt Fähigkeiten bereit.

Ein Service macht diese Fähigkeiten für bestimmte Stakeholder nutzbar.

Was ist ein Service?

Ein Service unterstützt Benutzer, Kunden oder andere Stakeholder dabei, gewünschte Ergebnisse zu erreichen.

Die Benutzer müssen dabei nicht alle zugrunde liegenden technischen und organisatorischen Einzelheiten selbst verwalten.

Ein Benutzer eines E-Mail-Service muss beispielsweise nicht selbst:

Der Benutzer erwartet stattdessen, dass er:

kann.

Der Service Provider übernimmt oder koordiniert die dafür notwendigen Fähigkeiten, Ressourcen, Arbeitsweisen und Beziehungen.

Interne und externe Services

Ein Service muss nicht an einen extern zahlenden Kunden verkauft werden.

Auch interne IT-Abteilungen erbringen Services.

Service Mögliche Service Consumer
Benutzerverwaltung Mitarbeiter und Fachabteilungen
zentraler Dateiservice interne Teams und Projekte
E-Mail- und Kalender-Service gesamte Organisation
ERP-Service Einkauf, Lager, Vertrieb und Buchhaltung
Entwicklungsplattform Softwareentwicklung
Monitoring-Service Betriebsteams und Service-Verantwortliche
Backup- und Restore-Service Fachabteilungen und Systemverantwortliche
Netzwerkzugang Mitarbeiter, Gäste und technische Systeme

Der Service Provider kann sein:

Ein Produkt kann mehrere Services ermöglichen

Eine zentrale Identitätsplattform kann beispielsweise folgende Services unterstützen:

Ein einzelner Service kann umgekehrt mehrere Produkte benötigen.

Ein digitaler Arbeitsplatzservice kann beispielsweise verwenden:

Praxistipp

Frage bei einer Störung nicht nur:

„Welches System ist ausgefallen?“

Frage zusätzlich:

„Welche Services verwenden dieses System und welche Benutzer sind dadurch betroffen?“

Output und Outcome unterscheiden

Für die Bewertung einer Aufgabe ist die Unterscheidung zwischen Output und Outcome wichtig.

Begriff Praktische Bedeutung
Output etwas wurde erstellt, verändert oder bereitgestellt
Outcome für einen Stakeholder wurde eine Wirkung oder ein nutzbares Ergebnis erreicht

Beispiele:

Output Outcome
VPN-Client wurde installiert. Mitarbeiter kann sicher von außerhalb arbeiten.
Benutzerkonto wurde angelegt. Neuer Mitarbeiter kann seine Arbeit aufnehmen.
Server wurde bereitgestellt. Fachanwendung kann produktiv verwendet werden.
Backup wurde erfolgreich ausgeführt. Daten können nach einem Ausfall wiederhergestellt werden.
Patch wurde installiert. Ein bekanntes Sicherheitsrisiko wurde reduziert.
Access Point wurde montiert. Benutzer erhalten zuverlässigen WLAN-Zugang.
Wissensartikel wurde erstellt. Supportmitarbeiter können eine Störung schneller lösen.

Typischer Fehler

Die technische Durchführung wird mit dem erfolgreichen Ergebnis gleichgesetzt.

Eine installierte Anwendung ist beispielsweise noch kein erfolgreicher Service, wenn der Benutzer sie nicht starten, verwenden oder für seine Aufgabe einsetzen kann.

Technische Fertigstellung ist nicht gleich Serviceerfolg

Ein neues Benutzerkonto wurde technisch angelegt.

Folgende Schritte wurden durchgeführt:

Der neue Mitarbeiter kann trotzdem nicht arbeiten, wenn:

Der technische Output lautet:

Benutzerkonto wurde erstellt.

Das erwartete Outcome lautet:

Der Mitarbeiter besitzt zum vorgesehenen Zeitpunkt einen funktionierenden und angemessenen Zugriff auf die für seine Tätigkeit benötigten Services.

Geschäftsergebnis und Benutzerergebnis

Ein Service kann unterschiedliche Ergebnisse für verschiedene Stakeholder ermöglichen.

Beispiel: Backup- und Restore-Service

Stakeholder Erwartetes Ergebnis
Benutzer versehentlich gelöschte Datei kann wiederhergestellt werden
Fachabteilung geschäftskritische Daten bleiben verfügbar
IT-Betrieb Systeme können kontrolliert wiederhergestellt werden
Informationssicherheit Schutz- und Aufbewahrungsanforderungen werden unterstützt
Unternehmensleitung Betriebsunterbrechungen und Verluste werden begrenzt
Auditor Kontrollen und Wiederherstellbarkeit sind nachvollziehbar dokumentiert

Nicht jeder Stakeholder bewertet denselben Service nach denselben Kriterien.

Deshalb müssen Anforderungen, Erwartungen, Kosten und Risiken aus mehreren Perspektiven betrachtet werden.

Vom technischen Baustein zum Ergebnis

Ein vereinfachtes Beispiel für einen E-Mail-Service:

Ebene Beispiel
Komponenten DNS, Identitätsdienst, Mailplattform, Zertifikate und Netzwerk
System technische Kommunikationsplattform
Produkt digitale Kommunikations- und Kollaborationslösung
Service E-Mail-, Kalender- und Kontaktservice
Output Postfach und Clientzugang wurden bereitgestellt
Outcome Mitarbeiter können zuverlässig kommunizieren
Geschäftsergebnis Zusammenarbeit und Geschäftsprozesse werden unterstützt
Wert zuverlässige Kommunikation bei angemessenen Kosten und Risiken

Diese Darstellung ist keine starre ITIL-Prozesskette.

Sie dient als praktische Orientierung, um technische Arbeit mit den erwarteten Ergebnissen zu verbinden.

Was bedeutet Wert?

Wert entsteht, wenn ein Produkt oder Service für einen Stakeholder einen erkennbaren Nutzen besitzt.

Wert kann sich beispielsweise zeigen durch:

Wert ist nicht für jeden Stakeholder identisch.

Beispiel:

Eine strengere Multi-Faktor-Authentifizierung kann:

Eine gute Lösung berücksichtigt diese unterschiedlichen Perspektiven.

Merke

Wert ist nicht nur eine technische Eigenschaft.

Er wird von Stakeholdern anhand ihrer Ergebnisse, Kosten, Risiken, Erfahrungen und Erwartungen wahrgenommen.

Wert wird gemeinsam ermöglicht

Der Service Provider erzeugt Wert nicht vollständig allein.

Auch Service Consumer und weitere Stakeholder tragen zur erfolgreichen Nutzung bei.

Beispiel: sicherer Fernzugriff

Der Service Provider muss unter anderem:

Der Benutzer muss unter anderem:

Die Fachabteilung oder Führungskraft muss möglicherweise:

Das gewünschte Ergebnis entsteht erst durch das Zusammenwirken der Beteiligten.

Verfügbarkeit allein reicht nicht aus

Ein Service kann technisch erreichbar und trotzdem praktisch unbrauchbar sein.

Beispiele:

Bei der Beurteilung eines Service können deshalb unter anderem folgende Eigenschaften wichtig sein:

Praxisbeispiel: zentraler Dateiservice

Ein Unternehmen betreibt einen zentralen Dateiservice.

Technische Komponenten

Digitales Produkt

Eine verwaltete Plattform zur Speicherung und gemeinsamen Nutzung von Unternehmensdateien.

Service

Benutzer können entsprechend ihrer Berechtigungen:

Erwartete Outcomes

Möglicher Wert

Praxisbeispiel: Störung des Dateiservice

Ein Benutzer meldet:

„Das Netzlaufwerk ist verschwunden.“

Eine rein komponentenorientierte Analyse könnte sofort mit dem Fileserver beginnen.

Die serviceorientierte Analyse prüft zusätzlich:

Dadurch wird verhindert, dass eine einzelne technische Vermutung zu früh als Ursache angenommen wird.

Bedeutung für das Monitoring

Monitoring sollte nicht ausschließlich einzelne Komponenten überwachen.

Ein Server kann erreichbar sein, obwohl der Service für Benutzer nicht funktioniert.

Deshalb können unterschiedliche Überwachungsebenen notwendig sein:

Ebene Beispiel
Komponentenüberwachung CPU, Arbeitsspeicher, Datenträger und Netzwerkinterface
Systemüberwachung Datenbankverbindung und Dienststatus
Anwendungsüberwachung Anmeldung und wichtige Transaktionen
Serviceüberwachung vollständiger Benutzerweg funktioniert
Ergebnisorientierte Messung Benutzer kann die vorgesehene Aufgabe erfolgreich ausführen

Praxistipp

Überwache bei kritischen Services möglichst auch eine Funktion, die der tatsächlichen Benutzernutzung nahekommt.

Ein erfolgreicher Ping bestätigt nur die Erreichbarkeit eines Hosts, nicht die Nutzbarkeit des gesamten Service.

Bedeutung für Änderungen

Vor einer technischen Änderung muss nicht nur die betroffene Komponente betrachtet werden.

Zusätzlich sollte geprüft werden:

Beispiel:

Eine Änderung an DNS kann Auswirkungen besitzen auf:

Die technische Änderung kann klein erscheinen, während die mögliche Serviceauswirkung sehr groß ist.

Bedeutung für die Priorisierung

Die Priorität einer Störung sollte nicht nur anhand der ausgefallenen Komponente bewertet werden.

Störung Technische Betrachtung Servicebezogene Betrachtung
einzelner Testserver ausgefallen vollständiger Serverausfall möglicherweise geringe geschäftliche Auswirkung
zentraler DNS-Dienst gestört einzelner technischer Dienst möglicherweise viele Services betroffen
einzelner Arbeitsplatzdrucker defekt einzelnes Gerät ausgefallen Auswirkung hängt von Alternativen und Bedarf ab
zentrale Datenbank reagiert langsam System ist noch erreichbar möglicherweise erhebliche Beeinträchtigung eines Geschäftsprozesses

Merke

Die technische Größe eines Fehlers bestimmt nicht automatisch seine geschäftliche Priorität.

Bedeutung für die Dokumentation

Eine gute Dokumentation sollte nicht nur Komponenten beschreiben.

Sie sollte nach Möglichkeit auch folgende Fragen beantworten:

Dadurch wird aus einer reinen Inventarliste eine nutzbare Wissensgrundlage für Betrieb, Support und Wiederherstellung.

Typische Denkfehler

Denkfehler 1: Der Server ist der Service

Ein Server ist normalerweise nur eine Komponente oder Plattform.

Der Service umfasst zusätzlich beispielsweise:

Denkfehler 2: Wenn das Monitoring grün ist, funktioniert der Service

Ein grüner Hoststatus bestätigt nicht automatisch:

Denkfehler 3: Installation bedeutet Abschluss

Eine Softwareinstallation ist zunächst ein Output.

Der gewünschte Zustand ist erst erreicht, wenn:

Denkfehler 4: Produkt und Service sind dasselbe

Produkte und Services sind eng miteinander verbunden, besitzen aber unterschiedliche Betrachtungsschwerpunkte.

Das Produkt bündelt und entwickelt Fähigkeiten.

Der Service macht diese Fähigkeiten für bestimmte Stakeholder nutzbar.

Denkfehler 5: Wert bedeutet nur finanziellen Gewinn

Wert kann auch entstehen durch:

Wie ein Systemintegrator die Zusammenhänge ermittelt

Vorgehensweise

  1. technische Komponenten erfassen
  2. Verbindungen und Abhängigkeiten bestimmen
  3. übergeordnetes System oder Produkt identifizieren
  4. unterstützte Services ermitteln
  5. Benutzer und weitere Stakeholder bestimmen
  6. erwartete Outputs und Outcomes erfassen
  7. kritische Geschäftsprozesse zuordnen
  8. Verantwortlichkeiten klären
  9. Monitoring und Wiederherstellung prüfen
  10. Informationen nachvollziehbar dokumentieren

Fragen für eine neue Umgebung

Wenn du einen neuen Service kennenlernst, solltest du mindestens folgende Fragen stellen:

Checkliste für technische Aufgaben

Bevor du eine technische Maßnahme durchführst:

Schnellzusammenfassung

Begriff Kurzbeschreibung
Komponente einzelner technischer oder organisatorischer Baustein
System zusammenwirkende Gruppe von Komponenten
Digitales Produkt gebündelte digitale Fähigkeit, die über ihren Lebenszyklus verwaltet wird
Service nutzbarer Zugang zu Fähigkeiten, der gewünschte Ergebnisse unterstützt
Output erzeugtes Arbeitsergebnis oder bereitgestellter Bestandteil
Outcome erreichte Wirkung oder Veränderung für einen Stakeholder
Geschäftsergebnis Outcome, das ein Ziel oder einen Prozess der Organisation unterstützt
Wert wahrgenommener Nutzen unter Berücksichtigung von Ergebnissen, Kosten, Risiken und Erfahrung

Grafik vorgesehen

Zusammenhang zwischen Technik, Produkt, Service und Ergebnis

Technische Komponenten
↓
Systeme und Plattformen
↓
digitales Produkt und unterstützende Fähigkeiten
↓
nutzbare Services
↓
Ergebnisse für Benutzer und Organisation
↓
wahrgenommener Wert

Die Grafik sollte zusätzlich verdeutlichen, dass Rückmeldungen aus Nutzung, Betrieb und Support wieder in die Weiterentwicklung des Produkts und der Services einfließen.

Eine spätere interaktive Version kann einen beispielhaften Service auswählen lassen, etwa:

Anschließend werden die dazugehörigen:

angezeigt.

Verwandte Seiten

Quellen und Versionsstand

Offizielle Grundlagen

Einordnung

Die Aussagen zur integrierten Betrachtung digitaler Produkte und Services, zum gemeinsamen Produkt- und Service-Lebenszyklus sowie zur Ausrichtung auf Outcomes und Wert wurden anhand der genannten offiziellen ITIL- und PeopleCert-Veröffentlichungen geprüft.

Die Beispiele, Checklisten, Betrachtungsebenen und technischen Zuordnungen sind zusätzliche herstellerneutrale Praxisempfehlungen dieses Nachschlagewerks.

Sie stellen keine wörtlichen offiziellen ITIL-Definitionen dar.

Behandelter Framework-Stand: ITIL Version 5
Zusätzlich berücksichtigt: ITIL 4
Fachlicher Stand: August 2026

1.3 Wert, Nutzen, Kosten und Risiken

Kurz erklärt

Ein IT-Service ist nicht bereits deshalb wertvoll, weil er technisch funktioniert. Wert entsteht erst, wenn der Service einen Servicekonsumenten dabei unterstützt, gewünschte Ergebnisse zu erreichen und dabei ein angemessenes Verhältnis zwischen Nutzen, Kosten und Risiken bietet.

Der Wert eines Services wird daher nicht allein durch den Service Provider bestimmt. Er entsteht durch das Zusammenwirken von Provider, Kunde, Benutzer und weiteren beteiligten Stakeholdern.

Entscheidend ist nicht, welche Technik bereitgestellt wurde, sondern welchen wahrgenommenen Nutzen sie für die Beteiligten erzeugt.

1. Wert im Service Management

ITIL beschreibt Wert als den wahrgenommenen Nutzen, die Nützlichkeit und die Bedeutung von etwas.

Dabei sind drei Punkte besonders wichtig:

Ein technisch identischer Service kann daher für zwei Organisationen einen völlig unterschiedlichen Wert besitzen.

Beispiel

Ein Cloudspeicher mit 2 TB Speicherplatz kann für ein kleines Unternehmen sehr wertvoll sein, wenn dadurch:

Für ein anderes Unternehmen kann derselbe Service ungeeignet sein, wenn:

Wert ist keine rein technische Eigenschaft eines Services, sondern hängt vom jeweiligen Kontext und von der Wahrnehmung der Stakeholder ab.

2. Wertschöpfung statt einseitiger Wertlieferung

In einem klassischen Liefermodell könnte der Eindruck entstehen, dass ein Anbieter einen fertigen Wert produziert und anschließend an den Kunden übergibt.

Im Service Management entsteht Wert jedoch normalerweise erst durch die gemeinsame Nutzung und Ausgestaltung des Services. ITIL spricht deshalb von Wertschöpfung durch Zusammenarbeit beziehungsweise Value Co-Creation.

Daran können beteiligt sein:

Beispiel: Einführung eines Ticketsystems

Der Service Provider kann:

Die Kundenorganisation muss unter anderem:

Erst durch das Zusammenwirken beider Seiten kann das gewünschte Ergebnis entstehen.

Ein Service Provider kann die Voraussetzungen für Wert schaffen. Ob tatsächlich Wert entsteht, hängt auch davon ab, wie der Service ausgewählt, eingerichtet, genutzt und weiterentwickelt wird.

3. Ergebnisse statt bloßer Ausgaben

Für die Bewertung eines Services müssen Outputs und Outcomes unterschieden werden.

Begriff Bedeutung Beispiel
Output unmittelbares Arbeitsergebnis einer Aktivität ein eingerichteter VPN-Zugang
Outcome durch einen oder mehrere Outputs ermöglichtes Ergebnis Beschäftigte können sicher von außerhalb arbeiten
Wert wahrgenommener Nutzen und Bedeutung des Ergebnisses produktives und flexibles Arbeiten bei vertretbarem Risiko

Ein Output kann technisch vollständig erbracht worden sein, ohne dass das gewünschte Outcome erreicht wird.

Beispiel

Ein Monitoring-System wurde installiert und erfasst alle Server. Das ist zunächst ein Output.

Das gewünschte Outcome könnte sein:

Werden zwar Messwerte gesammelt, aber keine sinnvollen Warnungen erzeugt und keine Reaktionen festgelegt, ist der technische Output vorhanden, das angestrebte Outcome jedoch nicht erreicht.

4. Nutzen beziehungsweise Utility

Die Utility beschreibt, ob ein Service für einen bestimmten Zweck geeignet ist und die benötigte Funktionalität bereitstellt.

Sie beantwortet vereinfacht die Frage:

Tut der Service das, was benötigt wird?

Utility kann entstehen, wenn ein Service:

Utility wird häufig als „fit for purpose“ bezeichnet: für den vorgesehenen Zweck geeignet.

Beispiele

Service mögliche Utility
E-Mail-Service Nachrichten senden und empfangen
Backup-Service wiederherstellbare Kopien von Daten erzeugen
VPN-Service sicheren Fernzugriff ermöglichen
Ticketsystem Anfragen und Störungen strukturiert erfassen
Identitätsdienst Benutzer authentifizieren und Zugriffe steuern
Monitoring Zustände erfassen und relevante Abweichungen melden

Eine hohe Utility allein reicht nicht aus. Ein Service kann alle benötigten Funktionen besitzen und trotzdem unbrauchbar sein, wenn er beispielsweise zu häufig ausfällt oder nicht ausreichend geschützt ist.

5. Zusicherung beziehungsweise Warranty

Die Warranty beschreibt, unter welchen Bedingungen und mit welcher zugesicherten Qualität ein Service genutzt werden kann.

Sie beantwortet vereinfacht die Frage:

Funktioniert der Service zuverlässig genug und unter den benötigten Bedingungen?

Warranty kann sich insbesondere auf folgende Eigenschaften beziehen:

Warranty wird häufig als „fit for use“ bezeichnet: für die tatsächliche Nutzung geeignet.

Beispiel

Ein Videokonferenzdienst besitzt die benötigten Funktionen. Er bietet damit grundsätzlich Utility.

Für eine Organisation ist er jedoch nur dann tatsächlich nutzbar, wenn beispielsweise:

6. Utility und Warranty gehören zusammen

Utility Warranty
Was leistet der Service? Wie zuverlässig und unter welchen Bedingungen leistet er es?
für den Zweck geeignet für die Nutzung geeignet
benötigte Funktionen benötigtes Qualitätsniveau
unterstützt gewünschte Ergebnisse stellt die erforderlichen Nutzungsbedingungen sicher

Beispiel: Backup-Service

Utility

Warranty

Utility ohne ausreichende Warranty bedeutet: Der Service kann grundsätzlich das Richtige, ist aber nicht zuverlässig genug. Warranty ohne passende Utility bedeutet: Der Service funktioniert zuverlässig, löst jedoch nicht das benötigte Problem.

7. Kosten aus Sicht des Servicekonsumenten

Kosten sind nicht nur der Kaufpreis oder die monatliche Rechnung. Bei der Bewertung eines Services müssen alle relevanten Aufwände betrachtet werden.

Mögliche Kosten sind:

ITIL unterscheidet aus Sicht des Servicekonsumenten zwei grundlegende Wirkungen:

Beispiel: Managed Backup

Durch den Service entstehen unter anderem:

Gleichzeitig können andere Kosten reduziert oder vermieden werden:

Für eine sachgerechte Bewertung müssen zusätzliche Kosten und vermiedene Kosten gemeinsam betrachtet werden.

8. Risiken aus Sicht des Servicekonsumenten

Ein Risiko ist ein mögliches Ereignis, das Schaden verursachen, die Zielerreichung beeinträchtigen oder Unsicherheit erzeugen kann.

Bei Services können Risiken beispielsweise entstehen durch:

Auch bei Risiken müssen zwei Wirkungen unterschieden werden:

Beispiel: Cloudbasierter E-Mail-Service

Möglicherweise reduzierte Risiken:

Möglicherweise neu entstehende oder verbleibende Risiken:

Die Auslagerung eines Services beseitigt nicht automatisch die Verantwortung der Kundenorganisation. Risiken können übertragen, geteilt, reduziert oder akzeptiert werden, müssen aber weiterhin gesteuert werden.

9. Erfahrung und wahrgenommene Servicequalität

Die technische Leistung eines Services ist nicht der einzige Faktor für seinen Wert. Auch die Erfahrung der beteiligten Personen beeinflusst, wie der Service wahrgenommen wird.

Dazu gehören beispielsweise:

Beispiel

Zwei Provider können technisch eine Verfügbarkeit von 99,9 Prozent erreichen. Der eine informiert bei Störungen frühzeitig, nennt regelmäßig den Bearbeitungsstand und dokumentiert anschließend die Ursache. Der andere reagiert verspätet und kommuniziert widersprüchlich.

Obwohl die gemessene Verfügbarkeit gleich ist, kann der wahrgenommene Wert deutlich unterschiedlich sein.

Technische Kennzahlen müssen durch die Perspektive von Kunden und Benutzern ergänzt werden.

10. Nachhaltigkeit als Teil langfristiger Wertbetrachtung

In der aktuellen ITIL-Weiterentwicklung wird Nachhaltigkeit ausdrücklich in die Betrachtung von Wert, Outcomes, Kosten, Risiken und Erfahrung einbezogen.

Nachhaltigkeit kann verschiedene Perspektiven umfassen:

Beispiel

Eine technisch leistungsfähige Lösung kann kurzfristig einen hohen Nutzen erzeugen. Wenn sie jedoch:

kann ihr langfristiger Wert gering sein.

11. Unterschiedliche Stakeholder bewerten Wert unterschiedlich

Stakeholder mögliche Wertkriterien
Benutzer einfache und störungsarme Nutzung
Kunde Unterstützung der Geschäftsziele
Sponsor vertretbare Finanzierung und messbarer Nutzen
Service Provider zuverlässige und wirtschaftliche Leistungserbringung
Management Zielerreichung, Steuerbarkeit und Risikokontrolle
Informationssicherheit Vertraulichkeit, Integrität und Verfügbarkeit
Datenschutz rechtmäßige und zweckgebundene Verarbeitung
Fachabteilung passende Funktionen und kurze Bearbeitungszeiten
Support diagnostizierbare und wartbare Lösung
Lieferant klarer Leistungsumfang und erfüllbare Vereinbarungen

Konflikte sind möglich.

Beispiel

Eine besonders strenge Authentifizierung kann die Sicherheit erhöhen, gleichzeitig aber die Benutzung erschweren. Die Aufgabe des Service Managements besteht nicht darin, nur eine Perspektive zu maximieren, sondern gemeinsam eine angemessene Lösung zu finden.

12. Wertannahme und tatsächlich erreichter Wert

Vor Einführung eines Services existiert zunächst eine Annahme darüber, welchen Wert er erzeugen soll.

Diese Annahme muss später anhand tatsächlicher Ergebnisse überprüft werden.

Vor der Einführung

Nach der Einführung

Ein erfolgreich abgeschlossenes Einführungsprojekt beweist noch nicht, dass der Service dauerhaft Wert erzeugt.

13. Wertorientierte Kennzahlen

Kennzahlen sollten nicht nur technische Aktivität messen, sondern einen Bezug zu den gewünschten Ergebnissen besitzen.

schwache oder unvollständige Kennzahl stärker wertorientierte Ergänzung
Anzahl bearbeiteter Tickets Wiederherstellungszeit und Benutzerzufriedenheit
Anzahl durchgeführter Changes Anteil erfolgreicher Changes und Auswirkungen auf den Service
Serververfügbarkeit Verfügbarkeit des vollständigen Geschäftsservices
Anzahl erstellter Benutzerkonten Zeit bis zur vollständigen Arbeitsfähigkeit neuer Beschäftigter
Anzahl erzeugter Backups erfolgreiche und getestete Wiederherstellungen
Anzahl geschlossener Incidents nachhaltig behobene Störungen und Wiederholungsrate
Anzahl automatisierter Schritte eingesparte Bearbeitungszeit und reduzierte Fehlerquote

Kennzahlen dürfen nicht isoliert betrachtet werden. Eine verkürzte Ticketbearbeitungszeit wäre beispielsweise kein positiver Wertbeitrag, wenn Tickets lediglich vorschnell geschlossen werden und Benutzer anschließend neue Tickets eröffnen müssen.

14. Praxisbeispiel: neuer Remote-Work-Service

Eine Organisation führt einen Service für mobiles Arbeiten ein.

Erwartete Outcomes

Utility

Warranty

Zusätzliche Kosten

Möglicherweise vermiedene Kosten

Möglicherweise reduzierte Risiken

Möglicherweise neu entstehende Risiken

Mögliche Messgrößen

15. Typische Fehlinterpretationen

Aussage fachliche Einordnung
„Der Server läuft, also liefert der Service Wert.“ Ein laufender Server bestätigt weder die Funktion des vollständigen Services noch das gewünschte Outcome.
„Der Kunde hat bezahlt, also ist der Service wertvoll.“ Preis und wahrgenommener Wert sind nicht identisch.
„Alle vereinbarten Funktionen sind vorhanden.“ Utility kann vorhanden sein, während Warranty oder Benutzererfahrung unzureichend sind.
„Der Provider übernimmt den Betrieb, daher bestehen keine Risiken mehr.“ Risiken können reduziert oder übertragen werden, verschwinden aber nicht automatisch.
„Die Einführung wurde termingerecht abgeschlossen.“ Projekterfolg beweist noch keinen dauerhaften Servicewert.
„Die SLA-Werte wurden eingehalten.“ Einhaltung einzelner Messwerte beweist nicht, dass die geschäftlichen Outcomes erreicht wurden.
„Viele bearbeitete Tickets zeigen einen guten Support.“ Eine hohe Ticketzahl kann auch auf schlechte Servicequalität oder wiederkehrende Fehler hinweisen.
„Automatisierung erzeugt immer Wert.“ Automatisierung kann ungeeignete Abläufe beschleunigen und Fehler vervielfachen.
„Wert ist vollständig objektiv messbar.“ Messdaten sind wichtig, der Wert enthält jedoch auch wahrnehmungs- und kontextabhängige Aspekte.

16. Checkliste zur Bewertung eines Services

17. Versionshinweis: ITIL 4 und ITIL (Version 5)

Die grundlegende Wertorientierung bleibt auch in ITIL (Version 5) erhalten. Dazu gehören insbesondere:

ITIL (Version 5) hebt zusätzlich die Erfahrung der Stakeholder, Nachhaltigkeit und den gemeinsamen Lebenszyklus digitaler Produkte und Services deutlicher hervor.

Die in ITIL 4 verwendeten Konzepte Utility und Warranty bleiben für die praktische Bewertung von Serviceanforderungen relevant. Bei aktuellen Unterlagen muss jedoch immer geprüft werden, auf welche ITIL-Version und welchen offiziellen Lehrplan sie sich beziehen.

Merksatz

Wert entsteht, wenn ein Service gewünschte Ergebnisse ermöglicht, einen wahrgenommenen Nutzen bietet und Kosten sowie Risiken für die beteiligten Stakeholder in einem angemessenen Verhältnis stehen. Utility beschreibt, ob der Service das Richtige leistet; Warranty beschreibt, ob er unter den benötigten Bedingungen zuverlässig genutzt werden kann.

Quellen und weiterführende Dokumentation

1.4 Servicebeziehungen, Rollen und Serviceangebote

Kurz erklärt

Ein Service entsteht nicht isoliert innerhalb einer IT-Abteilung. Er wird in einer Beziehung zwischen einem Service Provider und einem Service Consumer bereitgestellt, genutzt und fortlaufend weiterentwickelt.

Damit diese Beziehung funktioniert, muss eindeutig geklärt sein:

Eine Servicebeziehung besteht nicht nur aus der technischen Bereitstellung. Sie umfasst auch Zusammenarbeit, Vereinbarungen, Nutzung, Kommunikation und gemeinsame Verantwortung für die Wertschöpfung.

1. Service Provider

Ein Service Provider ist eine Organisation, die Services bereitstellt.

Der Provider kann:

Typische Aufgaben eines Service Providers sind:

Beispiele

Service Provider bereitgestellter Service
interne IT-Abteilung Arbeitsplatz- und Supportservice
externer Cloudanbieter Rechen-, Speicher- oder Plattformservice
Managed Service Provider Betrieb und Überwachung der IT-Infrastruktur
Telekommunikationsunternehmen Internet- und Standortverbindungen
internes Personalteam digital unterstützter Personalservice
Softwareanbieter cloudbasierte Fachanwendung
Rechenzentrum Hosting, Stromversorgung, Kühlung und Konnektivität

Der Begriff „Provider“ bezeichnet eine Rolle innerhalb einer bestimmten Servicebeziehung. Dieselbe Organisation kann gegenüber ihren Benutzern Provider und gegenüber einem Cloudanbieter Consumer sein.

2. Service Consumer

Ein Service Consumer ist eine Organisation, die Services eines Service Providers nutzt.

Der Begriff bezeichnet nicht nur einzelne Benutzer. Er umfasst die konsumierende Organisation und die unterschiedlichen Rollen, die an Auswahl, Finanzierung, Anforderungen und Nutzung eines Services beteiligt sind.

Zu den Aufgaben eines Service Consumers können gehören:

Beispiel

Ein Unternehmen nutzt einen externen E-Mail-Service.

Der Provider stellt unter anderem bereit:

Die Kundenorganisation muss unter anderem:

Der Provider trägt nicht automatisch die alleinige Verantwortung für alle Ergebnisse. Auch der Consumer muss die vereinbarten Beiträge leisten.

3. Customer, User und Sponsor

Innerhalb des Service Consumers unterscheidet ITIL drei wichtige Rollen:

Rolle Bedeutung zentrale Fragestellung
Customer definiert die Anforderungen an einen Service und übernimmt Verantwortung für die Outcomes des Servicekonsums Was benötigen wir und welche Ergebnisse sollen erreicht werden?
User verwendet den Service Kann ich den Service wirksam, sicher und verständlich nutzen?
Sponsor genehmigt beziehungsweise autorisiert das Budget für den Servicekonsum Ist die Finanzierung gerechtfertigt und tragfähig?

Diese Rollen müssen nicht von verschiedenen Personen ausgeübt werden. Eine Person kann mehrere Rollen übernehmen. In größeren Organisationen sind die Rollen jedoch häufig getrennt.

Beispiel: neues Ticketsystem

Sponsor

Customer

User

Ein Service kann die Erwartungen des Sponsors erfüllen und trotzdem für Benutzer ungeeignet sein. Deshalb müssen alle drei Perspektiven berücksichtigt werden.

4. Rollen sind kontextabhängig

ITIL-Rollen sind keine festen Berufsbezeichnungen. Sie beschreiben die Funktion einer Person oder Organisation in einer bestimmten Beziehung.

Beispiel: Software-as-a-Service

Ein Unternehmen verwendet eine cloudbasierte Personalverwaltungssoftware.

Beteiligter Rolle in diesem Zusammenhang
SaaS-Anbieter Service Provider gegenüber dem Unternehmen
Personalabteilung Customer und teilweise User
Geschäftsführung Sponsor
Beschäftigte User einzelner Funktionen
interne IT-Abteilung unterstützt die Nutzung und koordiniert die Integration
Cloud-Infrastruktur-Anbieter Provider gegenüber dem SaaS-Anbieter
SaaS-Anbieter Consumer gegenüber dem Cloud-Infrastruktur-Anbieter

Daraus folgt:

5. Produkte und Services unterscheiden

Ein Produkt ist eine Konfiguration von Ressourcen einer Organisation, die dazu entwickelt wurde, einem Consumer Wert anzubieten.

Zu solchen Ressourcen können gehören:

Ein Produkt kann die Grundlage für einen oder mehrere Services bilden.

Beispiel

Ein Provider betreibt eine Plattform für Zusammenarbeit.

Das Produkt kann unter anderem umfassen:

Auf dieser Grundlage können verschiedene Services angeboten werden:

Das Produkt ist die organisierte Ressourcenkonfiguration des Providers. Der Service ermöglicht dem Consumer daraus gewünschte Outcomes.

6. Service und Serviceangebot unterscheiden

Ein Service ermöglicht die gemeinsame Wertschöpfung, indem er gewünschte Outcomes unterstützt, ohne dass der Consumer bestimmte Kosten und Risiken vollständig selbst verwalten muss.

Ein Serviceangebot beschreibt dagegen eine konkrete Zusammenstellung von Leistungen, die sich an die Bedürfnisse einer bestimmten Consumer-Gruppe richtet.

Ein Serviceangebot kann enthalten:

  1. Waren
  2. Zugriff auf Ressourcen
  3. Service Actions

Diese Bestandteile können einzeln oder kombiniert auftreten.

7. Waren als Bestandteil eines Serviceangebots

Waren sind materielle oder übertragbare Bestandteile, deren Eigentum auf den Consumer übergehen kann.

Beispiele:

Typische Eigenschaften:

Beispiel

Ein Workplace-Service enthält:

Notebook, Dockingstation und Monitor können Waren sein. Einrichtung und Support sind dagegen Service Actions.

8. Zugriff auf Ressourcen

Ein Serviceangebot kann dem Consumer Zugriff auf Ressourcen ermöglichen, ohne dass deren Eigentum übertragen wird.

Beispiele:

Typische Eigenschaften:

Beispiel

Bei einem Cloudspeicher erhält der Consumer normalerweise nicht das Eigentum an bestimmten physischen Festplatten. Er erhält Zugriff auf eine vereinbarte Speicherkapazität und die dazugehörigen Funktionen.

9. Service Actions

Service Actions sind Tätigkeiten, die der Provider zur Unterstützung des Consumers ausführt.

Beispiele:

Service Actions können:

ausgeführt werden.

Beispiel

Ein Backup-Service kann enthalten:

10. Beispiel für ein vollständiges Serviceangebot

Service: verwalteter digitaler Arbeitsplatz

Bestandteil konkrete Leistung
Ware Notebook, Netzteil und gegebenenfalls Zubehör
Zugriff auf Ressourcen E-Mail, Dateispeicher, Fachanwendungen, VPN und Kollaborationsplattform
Service Actions Einrichtung, Softwareverteilung, Support, Wartung und Austausch
Utility Beschäftigte können ihre betrieblichen Aufgaben digital ausführen
Warranty vereinbarte Verfügbarkeit, Performance, Sicherheit, Kapazität und Kontinuität
Consumer-Beitrag sorgfältige Nutzung, Einhaltung der Sicherheitsregeln und Meldung von Problemen
erwartetes Outcome Beschäftigte sind innerhalb der vorgesehenen Zeit vollständig arbeitsfähig

Verschiedene Consumer-Gruppen können unterschiedliche Serviceangebote erhalten:

Ein Serviceangebot muss so konkret sein, dass Consumer verstehen, was enthalten ist, unter welchen Bedingungen es genutzt werden kann und welche eigenen Beiträge erforderlich sind.

11. Servicebeziehung

Eine Servicebeziehung ist die Zusammenarbeit zwischen einem Service Provider und einem Service Consumer.

Sie umfasst drei miteinander verbundene Bestandteile:

Bestandteil Bedeutung
Service Provision Tätigkeiten und Ressourcen des Providers zur Bereitstellung des Services
Service Consumption Tätigkeiten und Ressourcen des Consumers zur Nutzung des Services
Service Relationship Management gemeinsame Aktivitäten zur Pflege und Weiterentwicklung der Beziehung

12. Service Provision

Zur Service Provision können gehören:

Beispiel: VPN-Service

Der Provider:

13. Service Consumption

Zur Service Consumption können gehören:

Beispiel: VPN-Service

Der Consumer:

Auch die Nutzung eines Services benötigt Ressourcen, Kompetenzen, Verantwortlichkeiten und kontrollierte Abläufe.

14. Service Relationship Management

Service Relationship Management umfasst die gemeinsamen Aktivitäten von Provider und Consumer, mit denen die Servicebeziehung aufgebaut, gepflegt und verbessert wird.

Dazu gehören beispielsweise:

Typische Fragen eines Service Reviews

Eine Servicebeziehung muss aktiv gepflegt werden. Ein unterschriebener Vertrag ersetzt keine laufende Zusammenarbeit.

15. Interne und externe Servicebeziehungen

Servicebeziehungen können intern oder extern bestehen.

Merkmal interner Provider externer Provider
organisatorische Zugehörigkeit Teil derselben Organisation rechtlich selbstständige Organisation
Grundlage interne Vereinbarungen, Richtlinien und Service Levels Vertrag, Leistungsbeschreibung und Service Levels
Finanzierung interne Kostenstelle, Budget oder Leistungsverrechnung Rechnung, Abonnement oder nutzungsabhängige Zahlung
Steuerung interne Governance Vertrags- und Lieferantenmanagement
Eskalation interne Führungs- und Fachstrukturen vertragliche und organisatorische Eskalationswege
Verantwortung innerhalb der Organisation verteilt zwischen den Organisationen vereinbart

Auch interne Services benötigen:

„Intern“ bedeutet nicht automatisch kostenlos, unkritisch oder frei von Vereinbarungen.

16. Lieferanten und Partner

Ein Provider muss nicht alle Ressourcen und Tätigkeiten selbst bereitstellen. Häufig wirken weitere Organisationen mit.

Beispiele:

Der Consumer erlebt möglicherweise einen einzigen Service, obwohl im Hintergrund mehrere Provider und Lieferanten beteiligt sind.

Beispiel

Ein Software-as-a-Service-Angebot kann abhängig sein von:

Der direkte Provider bleibt gegenüber seinem Consumer für die vereinbarte Servicebeziehung verantwortlich, auch wenn Teile der Leistung von Lieferanten stammen.

Zu prüfen sind deshalb:

17. Beiträge des Providers und des Consumers

Für gemeinsame Wertschöpfung müssen die Beiträge beider Seiten bekannt sein.

Provider-Beitrag Consumer-Beitrag
geeignete Servicefunktionen klare Anforderungen
qualifiziertes Personal geeignete Ansprechpartner
technische Infrastruktur notwendige Endgeräte und lokale Voraussetzungen
Support und Dokumentation korrekte Nutzung und Mitarbeit
Sicherheitsmaßnahmen Einhaltung von Sicherheitsregeln
Monitoring und Berichte Rückmeldung über Erfahrung und Ergebnisse
Behandlung von Störungen vollständige und rechtzeitige Fehlermeldungen
geplante Verbesserungen Beteiligung an Tests und Abnahmen
transparente Kommunikation Mitteilung veränderter Anforderungen
vereinbarte Servicequalität Einhaltung eigener Verpflichtungen

Beispiel

Bei einer Datenmigration kann der Provider:

Der Consumer muss möglicherweise:

Fehlt einer dieser Beiträge, kann das gewünschte Outcome trotz technisch korrekter Provider-Leistung ausbleiben.

18. Vereinbarungen in Servicebeziehungen

Eine Vereinbarung kann formell oder informell sein. Sie muss jedoch für die beteiligten Parteien ausreichend eindeutig sein.

Mögliche Inhalte sind:

Mögliche Vereinbarungsformen:

Eine Vereinbarung ist nur wirksam, wenn die Beteiligten sie verstehen, praktisch erfüllen können und regelmäßig überprüfen.

19. Abgrenzung wichtiger Begriffe

Begriff Bedeutung
Produkt konfigurierte Ressourcen eines Providers zur Ermöglichung von Wertangeboten
Service Mittel zur gemeinsamen Wertschöpfung durch Unterstützung gewünschter Outcomes
Serviceangebot konkrete Beschreibung einer oder mehrerer Leistungen für eine Consumer-Gruppe
Service Provider Organisation, die Services bereitstellt
Service Consumer Organisation, die Services konsumiert
Customer definiert Anforderungen und verantwortet Outcomes des Servicekonsums
User verwendet den Service
Sponsor autorisiert das Budget für den Servicekonsum
Service Provision Bereitstellungstätigkeiten und Ressourcen des Providers
Service Consumption Nutzungstätigkeiten und Ressourcen des Consumers
Service Relationship Management gemeinsame Pflege und Weiterentwicklung der Beziehung
Output unmittelbares Arbeitsergebnis
Outcome durch Outputs ermöglichtes Ergebnis
Value wahrgenommener Nutzen und Bedeutung
Utility Eignung für den benötigten Zweck
Warranty Zusicherung der Eignung für die tatsächliche Nutzung

20. Praxisbeispiel: Managed Backup Service

Service Provider

Ein externes IT-Unternehmen betreibt den Backup-Service.

Service Consumer

Ein mittelständisches Unternehmen verwendet den Service zur Sicherung seiner Systeme.

Sponsor

Die Geschäftsführung genehmigt das Budget.

Customer

Die IT-Leitung definiert:

User

Administratoren verwenden:

Indirekte Benutzer sind alle Beschäftigten, deren Daten und Anwendungen durch den Service geschützt werden.

Serviceangebot

Provider-Beiträge

Consumer-Beiträge

Erwartete Outcomes

Erst getestete und fachlich bestätigte Wiederherstellungen zeigen, ob die Servicebeziehung das erwartete Outcome tatsächlich unterstützt.

21. Praxisbeispiel: interner Onboarding-Service

Ein neuer Beschäftigter soll am ersten Arbeitstag vollständig arbeitsfähig sein.

Beteiligte Provider

Consumer-Rollen

Rolle mögliches Beispiel
Sponsor Leitung der einstellenden Organisationseinheit
Customer verantwortliche Führungskraft
User neuer Beschäftigter

Benötigte Leistungen

Mögliches Outcome

Der neue Beschäftigte kann die vorgesehenen Aufgaben sicher und ohne unnötige Verzögerung ausführen.

Einzelne technische Outputs reichen dafür nicht aus. Ein eingerichtetes Notebook erzeugt noch keinen vollständigen Wert, wenn:

22. Typische Konflikte in Servicebeziehungen

Konflikt mögliche Ursache
Anforderungen werden nicht erfüllt Anforderungen waren unklar, widersprüchlich oder nicht abgestimmt
Benutzer lehnen den Service ab Benutzerperspektive wurde nicht ausreichend berücksichtigt
Sponsor zweifelt am Nutzen Outcomes und Wirtschaftlichkeit wurden nicht belegt
Provider erwartet mehr Mitwirkung Consumer-Beiträge wurden nicht vereinbart
Consumer erwartet nicht enthaltene Leistungen Serviceangebot und Ausschlüsse sind unklar
Service Levels werden erfüllt, trotzdem besteht Unzufriedenheit Kennzahlen bilden die tatsächliche Erfahrung oder Outcomes nicht ab
Änderungen führen zu Problemen Kommunikation, Tests oder Verantwortlichkeiten fehlen
Störungen eskalieren zu spät Eskalationswege sind unbekannt oder ungeeignet
Lieferant verursacht wiederholt Ausfälle unterstützende Verträge passen nicht zu den Consumer-Anforderungen
Kosten steigen unerwartet Nutzung, Abrechnung und Kapazitätsentwicklung werden nicht ausreichend überwacht

Konflikte sollten nicht nur als Kommunikationsproblem behandelt werden. Sie können auf strukturelle Mängel hinweisen, beispielsweise:

23. Typische Fehlinterpretationen

Aussage fachliche Einordnung
„Der Benutzer ist automatisch der Kunde.“ User und Customer sind unterschiedliche Rollen, auch wenn eine Person beide Rollen besitzen kann.
„Wer bezahlt, definiert automatisch alle Anforderungen.“ Der Sponsor autorisiert das Budget; die Anforderungen werden durch die Customer-Rolle bestimmt.
„Der Provider erzeugt den Wert allein.“ Wert entsteht durch das Zusammenwirken von Provider, Consumer und weiteren Stakeholdern.
„Ein Produkt und ein Service sind dasselbe.“ Ein Produkt ist eine Ressourcenkonfiguration; ein Service unterstützt die gemeinsame Wertschöpfung.
„Ein Serviceangebot ist nur eine Preisliste.“ Es beschreibt konkrete Leistungen, Zielgruppen, Bedingungen und Bestandteile des Angebots.
„Bei einem Cloudservice besitzt der Consumer die Infrastruktur.“ Normalerweise erhält er Zugriff auf Ressourcen, ohne deren Eigentum zu übernehmen.
„Ein externer Provider übernimmt alle Risiken.“ Risiken und Verantwortlichkeiten werden verteilt, aber nicht automatisch vollständig übertragen.
„Interne Services benötigen keine Vereinbarungen.“ Auch interne Servicebeziehungen benötigen klare Erwartungen und Verantwortlichkeiten.
„Ein Vertrag reicht zur Steuerung der Beziehung aus.“ Die Beziehung muss fortlaufend kommuniziert, überprüft und verbessert werden.
„Der direkte Provider ist für Fehler seiner Lieferanten nicht zuständig.“ Gegenüber dem Consumer gelten weiterhin die vereinbarten Verantwortlichkeiten des direkten Providers.
„Ein Service ist erfolgreich, wenn er bereitgestellt wurde.“ Entscheidend sind Nutzung, Outcomes, Erfahrung und tatsächlich erzeugter Wert.

24. Checkliste für eine klare Servicebeziehung

25. Versionshinweis: ITIL 4 und ITIL (Version 5)

Die grundlegenden Rollen und Beziehungen bleiben auch in ITIL (Version 5) wichtig. Dazu gehören insbesondere:

ITIL (Version 5) verwendet für die finanzierende Consumer-Rolle teilweise die präzisere Bezeichnung Consumer Sponsor, um sie deutlicher von anderen Sponsorrollen abzugrenzen.

Zusätzlich betrachtet ITIL (Version 5) die Perspektiven und Erfahrungen von Benutzern, Kunden, Consumer Sponsors und Provider-Rollen stärker entlang einer durchgängigen Product and Service Lifecycle Journey.

Für Prüfungen und Zertifizierungen muss immer die Terminologie der jeweils zugrunde liegenden ITIL-Version und des offiziellen Lehrplans verwendet werden.

Merksatz

Ein Service Provider stellt nicht einfach Technik bereit. Provider und Consumer bilden eine Servicebeziehung, in der Customer, User und Sponsor unterschiedliche Perspektiven vertreten. Ein klares Serviceangebot beschreibt, welche Waren, Ressourcenzugriffe und Service Actions enthalten sind und welche Beiträge beide Seiten leisten müssen, damit die gewünschten Outcomes und gemeinsamer Wert entstehen.

Quellen und weiterführende Dokumentation