1.2 Technik, Produkt, Service und Geschäftsergebnis

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 ermöglicht Benutzern oder Kunden, diese Fähigkeiten zu verwenden und ein gewünschtes Ergebnis zu erreichen.

Der eigentliche Wert entsteht nicht durch den Besitz einzelner Systeme, sondern dadurch, dass Menschen und Organisationen mit ihrer Hilfe zuverlässig arbeiten und ihre Ziele erreichen können.

Warum diese Unterscheidung wichtig ist

Im technischen Arbeitsalltag werden die Begriffe System, Produkt, Service, Leistung und Ergebnis häufig vermischt.

Beispielsweise kann der Begriff „E-Mail-System“ je nach Zusammenhang Folgendes bedeuten:

den Mailserver,
die gesamte technische Plattform,
die E-Mail-Anwendung,
das angebotene digitale Produkt,
den E-Mail-Service,
oder den vollständigen Kommunikationsdienst des Unternehmens.

Diese Bedeutungen sind miteinander verbunden, aber nicht identisch.

Für professionelles Service Management muss erkennbar sein:

welche technischen Komponenten vorhanden sind,
welches digitale Produkt daraus entsteht,
welche Services damit angeboten werden,
wer diese Services nutzt,
welche Ergebnisse erwartet werden,
und welchen Wert die Beteiligten daraus erhalten.

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 fünf Betrachtungsebenen

Für die praktische Einordnung kann zwischen fünf Ebenen unterschieden werden.

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 Fähigkeit wird entwickelt und über ihren Lebenszyklus verwaltet?	digitale Kommunikationsplattform
Service	Wie wird diese Fähigkeit Benutzern oder Kunden zugänglich und nutzbar gemacht?	E-Mail- und Kalender-Service
Ergebnis	Was können Benutzer oder Unternehmen dadurch erreichen?	zuverlässig kommunizieren und Termine koordinieren

Diese Ebenen bilden keine starre Hierarchie.

Ein Produkt kann mehrere Services ermöglichen.

Ein Service kann mehrere Produkte, Plattformen oder externe Leistungen verwenden.

ITIL Version 5 betrachtet digitale Produkte und Services deshalb als eng miteinander verbundene Bestandteile eines gemeinsamen Lebenszyklus.

Technische Komponenten

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

Dazu gehören beispielsweise:

physische Server,
virtuelle Maschinen,
Container,
Betriebssysteme,
Netzwerkkomponenten,
Firewalls,
Speicher,
Datenbanken,
Anwendungen,
Schnittstellen,
Zertifikate,
Benutzerkonten,
Identitätsdienste,
Cloud-Ressourcen,
Monitoring-Systeme,
Backup-Systeme,
und technische Dokumentationen.

In einem Konfigurationsmanagement können solche Bestandteile als Configuration Items erfasst werden, sofern ihre Verwaltung für die Bereitstellung oder Steuerung eines Service erforderlich ist.

Praxisbeispiel

Für einen VPN-Zugang werden möglicherweise folgende Komponenten benötigt:

VPN-Gateway,

Firewall,

Internetanschluss,

DNS,

Benutzerverzeichnis,

Multi-Faktor-Authentifizierung,

Clientsoftware,

Zertifikate,

Endgerät,

Monitoring,

und ein externer Identitäts- oder Cloud-Anbieter.

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	Mailserver, 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 oder Administration betrachtet.

Dabei stehen Fragen im Mittelpunkt wie:

Welche Komponenten gehören dazu?
Wie sind sie verbunden?
Welche Abhängigkeiten bestehen?
Wie wird das System überwacht?
Wie wird es gesichert?
Wie kann es wiederhergestellt werden?
Wer darf es administrieren?

Diese Sicht ist für Systemintegratoren besonders wichtig.

Für die Beurteilung eines Service reicht sie allein jedoch nicht aus.

Digitales Produkt

ITIL Version 5 rückt die gemeinsame Betrachtung von digitalen Produkten und Services stärker in den Mittelpunkt.

Ein digitales Produkt kann praxisnah als eine zusammenhängende digitale Fähigkeit verstanden werden, die:

geplant,
entwickelt oder beschafft,
bereitgestellt,
betrieben,
unterstützt,
weiterentwickelt,
und schließlich außer Betrieb genommen

werden muss.

Ein digitales Produkt kann unter anderem umfassen:

Software,
Hardware,
Daten,
Schnittstellen,
Automatisierungen,
Sicherheitsfunktionen,
Dokumentation,
Betriebswerkzeuge,
Lieferantenleistungen,
und die zur Verwaltung notwendigen Fähigkeiten.

Beispiele für digitale Produkte:

eine unternehmensweite Kommunikationsplattform,
ein Kundenportal,
eine Warenwirtschaftslösung,
eine digitale Arbeitsplatzplattform,
eine Monitoring-Plattform,
eine Identitäts- und Zugriffsplattform,
oder eine selbst entwickelte Geschäftsanwendung.

Wichtig

Ein Produkt ist nicht zwingend ein einzelnes Programm.

Es kann aus vielen technischen und organisatorischen Bestandteilen bestehen und über längere Zeit weiterentwickelt werden.

Produkt und Service sind keine Gegensätze

In früheren Organisationsmodellen arbeiteten Produktentwicklung und IT-Betrieb häufig weitgehend getrennt.

Dabei entstand vereinfacht folgende Trennung:

Das Produktteam entwickelt eine Lösung.
Das Betriebsteam übernimmt sie anschließend.
Der Support bearbeitet später auftretende Störungen.

Diese Trennung kann zu Problemen führen:

Betriebsanforderungen werden zu spät berücksichtigt.
Monitoring fehlt beim Produktivstart.
Supportmitarbeiter erhalten unzureichende Informationen.
Sicherheitsanforderungen werden nachträglich ergänzt.
Verantwortlichkeiten bleiben unklar.
Fehler werden zwischen Teams weitergereicht.

ITIL Version 5 betrachtet Produkte und Services deshalb als eng verbundene Seiten einer digital unterstützten Lösung.

Ein Produkt muss so gestaltet und betrieben werden, dass damit verlässliche Services erbracht werden können.

Ein Service benötigt wiederum geeignete Produkte und technische Fähigkeiten als Grundlage.

Merke

Ein Produkt stellt Fähigkeiten bereit.

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

Was ist ein Service?

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

Dabei sollen sie nicht sämtliche zugrunde liegenden technischen Details, Kosten und Risiken selbst verwalten müssen.

Ein Benutzer des E-Mail-Service muss beispielsweise nicht:

den Mailserver betreiben,
Zertifikate verlängern,
Datenbanken warten,
Spamfilter konfigurieren,
Backups planen,
Sicherheitsupdates einspielen,
oder externe Provider steuern.

Diese Aufgaben werden durch den Service Provider oder die zuständigen internen Teams übernommen.

Der Benutzer erwartet stattdessen, dass er:

Nachrichten senden und empfangen,
Kontakte nutzen,
Termine verwalten,
und zuverlässig kommunizieren

kann.

Interne und externe Services

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

Auch interne IT-Abteilungen erbringen Services.

Beispiele:

Service	Mögliche Service Consumer
Benutzerverwaltung	Mitarbeiter und Fachabteilungen
zentraler Dateiservice	interne Teams
E-Mail- und Kalender-Service	gesamte Organisation
ERP-Service	Einkauf, Lager, Vertrieb und Buchhaltung
Entwicklungsplattform	Softwareentwicklung
Monitoring-Service	Betriebsteams und Service Owner
Backup- und Restore-Service	Fachabteilungen und Systemverantwortliche

Der Service Provider kann sein:

eine interne IT-Abteilung,
ein Managed Service Provider,
ein Cloud-Anbieter,
ein Software-as-a-Service-Anbieter,
ein externer Dienstleister,
oder eine Kombination mehrerer Beteiligter.

Produkte können mehrere Services ermöglichen

Ein digitales Produkt kann verschiedene Services unterstützen.

Beispiel: Eine zentrale Identitätsplattform kann folgende Services ermöglichen:

Benutzeranmeldung,
Single Sign-on,
Multi-Faktor-Authentifizierung,
Passwortzurücksetzung,
Berechtigungsbereitstellung,
Identitätsprüfung,
und Zugriff auf Cloud-Anwendungen.

Umgekehrt kann ein einzelner Service mehrere Produkte benötigen.

Beispiel: Ein digitaler Arbeitsplatzservice kann verwenden:

Identitätsplattform,
Endgeräteverwaltung,
E-Mail-Plattform,
Kollaborationsplattform,
Sicherheitsprodukt,
Softwareverteilung,
Netzwerkzugang,
und Supportwerkzeuge.

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 das Verständnis von Services ist die Unterscheidung zwischen Output und Outcome hilfreich.

Begriff	Bedeutung	Beispiel
Output	ein erzeugtes Ergebnis, Arbeitserzeugnis oder bereitgestellter Bestandteil	VPN-Client wurde installiert
Outcome	die für einen Stakeholder erreichte Wirkung oder Veränderung	Mitarbeiter kann sicher von zu Hause arbeiten

Weitere Beispiele:

Output	Outcome
Benutzerkonto wurde angelegt.	Der neue Mitarbeiter kann seine Arbeit aufnehmen.
Server wurde bereitgestellt.	Die Fachanwendung kann produktiv genutzt werden.
Backup wurde erfolgreich ausgeführt.	Daten können nach einem Ausfall wiederhergestellt werden.
Patch wurde installiert.	Ein bekanntes Sicherheitsrisiko wurde reduziert.
WLAN-Access-Point wurde montiert.	Mitarbeiter erhalten zuverlässigen Netzwerkzugang.
Wissensartikel wurde erstellt.	Supportmitarbeiter können die Störung schneller lösen.

Typischer Fehler

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

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

Technische Fertigstellung ist nicht gleich Serviceerfolg

Eine technische Aufgabe kann formal abgeschlossen sein, obwohl der gewünschte Service noch nicht funktioniert.

Beispiel:

Ein neues Benutzerkonto wurde angelegt.

Technisch wurde Folgendes durchgeführt:

Konto erstellt,
Gruppe zugewiesen,
E-Mail-Adresse angelegt,
Lizenz vergeben.

Der neue Mitarbeiter kann trotzdem nicht arbeiten, wenn:

das Kennwort nicht übermittelt wurde,
MFA nicht eingerichtet werden kann,
eine notwendige Berechtigung fehlt,
das Endgerät noch nicht bereitsteht,
die Anmeldung nicht getestet wurde,
oder die zuständige Führungskraft keine Freigabe erteilt hat.

Der reine Output lautet:

Benutzerkonto erstellt.

Das erwartete Outcome lautet:

Der Mitarbeiter besitzt zum vorgesehenen Zeitpunkt einen funktionierenden und angemessenen Zugriff auf alle für seine Tätigkeit notwendigen Services.

Geschäftsergebnis und Benutzerergebnis

Ein Service kann verschiedene Ergebnisse für unterschiedliche 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 nach einem Ausfall kontrolliert wiederhergestellt werden
Informationssicherheit	Anforderungen an Schutz und Aufbewahrung werden unterstützt
Unternehmensleitung	Betriebsunterbrechungen und Verluste werden begrenzt
Auditor	Wiederherstellbarkeit und Kontrollen sind nachvollziehbar dokumentiert

Nicht jeder Stakeholder bewertet denselben Service nach denselben Kriterien.

Deshalb müssen Anforderungen, Erwartungen 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, 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äftlicher Nutzen	Zusammenarbeit und Geschäftsprozesse werden unterstützt

Diese Darstellung hilft, technische Aufgaben mit den Ergebnissen für Benutzer und Unternehmen zu verbinden.

Sie ist jedoch keine starre ITIL-Prozesskette.

Produkte, Services, Stakeholder und Ergebnisse beeinflussen sich gegenseitig.

Was bedeutet Wert?

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

Wert kann sich beispielsweise zeigen durch:

Zeitersparnis,
geringeres Risiko,
höhere Verfügbarkeit,
bessere Benutzererfahrung,
geringere Kosten,
schnellere Kommunikation,
bessere Entscheidungsgrundlagen,
höhere Sicherheit,
Erfüllung rechtlicher Anforderungen,
oder Unterstützung eines Geschäftsprozesses.

Wert ist nicht für jeden Stakeholder identisch.

Beispiel:

Eine strengere Multi-Faktor-Authentifizierung kann:

für die Informationssicherheit einen deutlichen Schutzgewinn darstellen,
für Benutzer zunächst zusätzlichen Aufwand erzeugen,
für das Unternehmen Risiken reduzieren,
und für den Service Desk mehr Supportanfragen verursachen.

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

Merke

Wert ist nicht nur eine technische Eigenschaft.

Er wird von den beteiligten Stakeholdern anhand ihrer Ziele, Erfahrungen, Kosten und Risiken wahrgenommen.

Wert wird gemeinsam ermöglicht

Der Service Provider stellt nicht allein und automatisch Wert her.

Auch Service Consumer und weitere Stakeholder tragen dazu bei.

Beispiel: Sicherer Fernzugriff

Der Service Provider muss unter anderem:

VPN-Infrastruktur bereitstellen,
Zugänge verwalten,
Sicherheit gewährleisten,
Störungen bearbeiten,
und den Service überwachen.

Der Benutzer muss unter anderem:

Zugangsdaten schützen,
MFA korrekt verwenden,
Sicherheitsvorgaben einhalten,
ein geeignetes Endgerät verwenden,
und Störungen mit verwertbaren Informationen melden.

Die Führungskraft oder Fachabteilung muss möglicherweise:

den Zugriff genehmigen,
benötigte Berechtigungen benennen,
und Änderungen rechtzeitig mitteilen.

Der Wert entsteht erst durch das Zusammenwirken dieser Beteiligten.

Verfügbarkeit allein reicht nicht aus

Ein Service kann technisch erreichbar und trotzdem praktisch unbrauchbar sein.

Beispiele:

Die Anwendung lädt, reagiert aber zu langsam.
Der Benutzer kann sich anmelden, besitzt aber keine notwendigen Berechtigungen.
Das VPN ist erreichbar, unterstützt aber die benötigte Fachanwendung nicht.
Das Backup läuft erfolgreich, wurde aber nie wiederhergestellt getestet.
Der Druckservice ist verfügbar, aber der Benutzer kann keinen geeigneten Drucker auswählen.
Das Portal funktioniert technisch, ist aber für Benutzer nicht verständlich.

Bei der Beurteilung eines Service müssen daher neben technischer Verfügbarkeit auch weitere Aspekte berücksichtigt werden, beispielsweise:

Leistung,
Kapazität,
Sicherheit,
Zuverlässigkeit,
Benutzerfreundlichkeit,
Support,
Wiederherstellbarkeit,
und Eignung für den vorgesehenen Zweck.

Beispiel: Zentraler Dateiservice

Ein Unternehmen betreibt einen zentralen Dateiservice.

Technische Komponenten

Fileserver,
Storage,
Netzwerk,
DNS,
Active Directory,
Berechtigungen,
Backup,
Monitoring.

Digitales Produkt

Eine verwaltete Plattform zur Speicherung und gemeinsamen Nutzung von Unternehmensdateien.

Service

Benutzer können entsprechend ihrer Berechtigungen:

Dateien speichern,
öffnen,
bearbeiten,
austauschen,
und bei Bedarf wiederherstellen lassen.

Erwartete Ergebnisse

Teams können gemeinsam an Dokumenten arbeiten.
Unternehmensdaten werden zentral verwaltet.
Zugriffe sind kontrollierbar.
Daten können nach Fehlern wiederhergestellt werden.
Informationen bleiben auch bei einem Gerätewechsel verfügbar.

Möglicher Wert

weniger Datenverlust,
bessere Zusammenarbeit,
zentrale Zugriffskontrolle,
nachvollziehbare Sicherung,
und geringerer Verwaltungsaufwand.

Beispiel: Störung des Dateiservice

Ein Benutzer meldet:

„Das Netzlaufwerk ist verschwunden.“

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

Die serviceorientierte Analyse prüft zusätzlich:

Betrifft die Störung nur einen Benutzer?
Sind mehrere Standorte betroffen?
Funktioniert die Anmeldung?
Ist nur ein Netzlaufwerk oder der gesamte Dateiservice betroffen?
Welcher Geschäftsprozess ist beeinträchtigt?
Gibt es eine alternative Zugriffsmöglichkeit?
Wurde eine Gruppenrichtlinie geändert?
Gab es einen Change am Netzwerk oder Verzeichnisdienst?
Welche Priorität ergibt sich aus Auswirkung und Dringlichkeit?
Wer muss informiert werden?

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 erforderlich sein:

Ebene	Beispiel
Komponentenüberwachung	CPU, RAM, Datenträger und Netzwerkinterface
Systemüberwachung	Datenbankverbindung und Dienststatus
Anwendungsüberwachung	Anmeldung und wichtige Transaktionen
Serviceüberwachung	vollständiger Benutzerweg funktioniert
Ergebnisorientierte Messung	Benutzer können ihre Aufgabe innerhalb der erwarteten Zeit ausführen

Praxistipp

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

Ein einfacher 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:

Zu welchem Produkt gehört die Komponente?
Welche Services verwenden sie?
Welche Benutzer sind abhängig?
Welche anderen Systeme greifen darauf zu?
Welche Ergebnisse können beeinträchtigt werden?
Welche Überwachung bestätigt die erfolgreiche Änderung?
Wie kann der vorherige Zustand wiederhergestellt werden?
Wer muss informiert werden?

Beispiel:

Eine Änderung an DNS kann Auswirkungen besitzen auf:

Benutzeranmeldung,
E-Mail,
Webanwendungen,
Zertifikatsprüfung,
Active Directory,
VPN,
Monitoring,
und externe Schnittstellen.

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.

Beispiel:

Störung	Technische Betrachtung	Servicebezogene Betrachtung
einzelner Testserver ausgefallen	kompletter Serverausfall	möglicherweise geringe Auswirkung
DNS-Fehler auf zentralem Resolver	einzelner Dienst gestört	möglicherweise viele Services betroffen
Drucker der Geschäftsleitung defekt	einzelnes Gerät ausgefallen	Auswirkung abhängig von Alternativen und Geschäftsbedarf
Datenbank langsam	System 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 technische Dokumentation sollte nicht nur Komponenten beschreiben.

Sie sollte nach Möglichkeit auch folgende Fragen beantworten:

Zu welchem Produkt gehört die Komponente?
Welche Services unterstützt sie?
Wer ist verantwortlich?
Welche Benutzer oder Kunden sind abhängig?
Welche anderen Komponenten werden benötigt?
Welche Überwachung existiert?
Welche Wiederherstellungsverfahren gelten?
Welche Lieferanten oder Verträge sind beteiligt?
Welche Änderungen wurden zuletzt durchgeführt?

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 unter anderem:

Nutzung,
Support,
Sicherheit,
Überwachung,
Berechtigungen,
Wiederherstellung,
und organisatorische Verantwortung.

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

Ein grüner Hoststatus bestätigt nicht automatisch:

erfolgreiche Anmeldung,
korrekte Berechtigungen,
ausreichende Leistung,
fehlerfreie Transaktionen,
oder positive Benutzererfahrung.

Denkfehler 3: Installation bedeutet Abschluss

Eine Softwareinstallation ist ein Output.

Der Vorgang ist erst erfolgreich, wenn:

die Anwendung funktioniert,
der Benutzer zugreifen kann,
der vorgesehene Zweck erfüllt wird,
und das Ergebnis überprüft wurde.

Denkfehler 4: Produkt und Service sind dasselbe

Produkte und Services sind eng miteinander verbunden, erfüllen aber unterschiedliche Betrachtungszwecke.

Das Produkt bündelt und entwickelt Fähigkeiten.

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

Denkfehler 5: Wert ist nur finanzieller Gewinn

Wert kann auch entstehen durch:

Risikoreduzierung,
Sicherheit,
Zuverlässigkeit,
schnellere Arbeit,
bessere Erfahrung,
oder die Erfüllung verbindlicher Anforderungen.

Wie ein Systemintegrator die Zusammenhänge ermittelt

Bei einem unbekannten System kannst du schrittweise vorgehen.

Vorgehensweise

technische Komponenten erfassen

Verbindungen und Abhängigkeiten bestimmen

übergeordnetes Produkt oder System identifizieren

unterstützte Services ermitteln

Benutzer und weitere Stakeholder bestimmen

erwartete Ergebnisse erfassen

kritische Geschäftsprozesse zuordnen

Verantwortlichkeiten klären

Monitoring und Wiederherstellung prüfen

Informationen dokumentieren

Fragen für eine neue Umgebung

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

Wie heißt der Service?
Welches Ergebnis soll er ermöglichen?
Wer verwendet ihn?
Wer ist für ihn verantwortlich?
Welche Produkte und Systeme unterstützen ihn?
Welche technischen Komponenten sind kritisch?
Welche externen Anbieter sind beteiligt?
Welche Servicezeiten gelten?
Welche Leistungsanforderungen bestehen?
Welche Sicherheitsanforderungen gelten?
Welche Abhängigkeiten bestehen?
Wie wird der Service überwacht?
Wie wird er wiederhergestellt?
Wo befindet sich die Dokumentation?
Welche bekannten Fehler und Zwischenlösungen existieren?

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
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 für einen Stakeholder
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:

Benutzeranmeldung,
E-Mail,
VPN,
Dateiservice,
Backup,
oder Unternehmensanwendung.

Anschließend werden die dazugehörigen:

Komponenten,
Produkte,
Services,
Stakeholder,
Ergebnisse,
Risiken,
und Abhängigkeiten

angezeigt.

Verwandte Seiten

1.1 Warum professionelles Service Management notwendig ist
1.3 Typische Folgen unstrukturierter IT-Arbeit
1.4 Serviceorientierung im Arbeitsalltag
2.1 Was ist ein digitales Produkt?
2.2 Was ist ein Service?
2.3 Wert und gemeinsame Wertschöpfung
2.4 Output und Outcome
2.5 Kosten und Risiken
Service Configuration Management
IT Asset Management
Monitoring and Event Management
Change Management
Fehleranalyse und Troubleshooting

Quellen und Versionsstand

Offizielle Grundlagen

PeopleCert: ITIL Foundation – Version 5
ITIL: ITIL Foundation – Version 5
ITIL: ITIL Foundation Version 5 – What’s New?
PeopleCert: The New ITIL Product and Service Lifecycle Model
PeopleCert: ITIL Product – Version 5
PeopleCert: ITIL Service – Version 5
PeopleCert: ITIL FAQ – Frequently Asked Questions about ITIL

Einordnung

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

Die verwendeten Beispiele, Checklisten 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