Skip to main content

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:

  • einen Mailserver,
  • eine technische Plattform,
  • eine E-Mail-Anwendung,
  • ein digitales Kommunikationsprodukt,
  • einen E-Mail-Service,
  • oder den gesamten Kommunikationsdienst des Unternehmens.

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

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

  • welche technischen Komponenten vorhanden sind,
  • wie diese Komponenten zusammenarbeiten,
  • welches digitale Produkt daraus entsteht,
  • welche Services damit ermöglicht werden,
  • wer diese Services verwendet,
  • welche Ergebnisse erwartet werden,
  • und welchen Wert die beteiligten Stakeholder wahrnehmen.

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:

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

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:

  • VPN-Gateway,
  • Firewall,
  • Internetanschluss,
  • DNS,
  • Benutzerverzeichnis,
  • Multi-Faktor-Authentifizierung,
  • Clientsoftware,
  • Zertifikate,
  • Endgerät,
  • Monitoring,
  • und ein externer Identitätsanbieter.

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:

  • Welche Komponenten gehören zum System?
  • Wie sind sie miteinander verbunden?
  • Welche Abhängigkeiten bestehen?
  • Wie wird das System überwacht?
  • Wie wird es gesichert?
  • Wie kann es wiederhergestellt werden?
  • Wer darf es administrieren?
  • Welche anderen Systeme greifen darauf zu?

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:

  • Software,
  • Hardware,
  • Daten,
  • Schnittstellen,
  • Automatisierungen,
  • Sicherheitsfunktionen,
  • Dokumentation,
  • Betriebswerkzeugen,
  • Lieferantenleistungen,
  • Supportleistungen,
  • und organisatorischen Fähigkeiten.

Beispiele für digitale Produkte:

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

Ein digitales Produkt wird über seinen gesamten Lebenszyklus betrachtet.

Dazu gehören unter anderem:

  • Bedarf und Zielsetzung verstehen,
  • Anforderungen untersuchen,
  • Lösung gestalten,
  • Komponenten beschaffen oder entwickeln,
  • testen,
  • bereitstellen,
  • betreiben,
  • unterstützen,
  • verbessern,
  • und später kontrolliert außer Betrieb nehmen.

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:

  • Monitoring fehlt beim Produktivstart.
  • Supportmitarbeiter erhalten keine ausreichende Dokumentation.
  • Betriebsanforderungen werden erst nach der Einführung erkannt.
  • Sicherheitsanforderungen werden nachträglich ergänzt.
  • Verantwortlichkeiten bleiben unklar.
  • Fehler werden zwischen Teams weitergereicht.
  • Benutzererfahrungen fließen nicht in die Weiterentwicklung ein.

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:

  • Mailserver betreiben,
  • Zertifikate verlängern,
  • Datenbanken warten,
  • Spamfilter konfigurieren,
  • Backups planen,
  • Sicherheitsupdates installieren,
  • Speicher erweitern,
  • oder externe Provider koordinieren.

Der Benutzer erwartet stattdessen, dass er:

  • Nachrichten senden und empfangen,
  • Kontakte verwenden,
  • Termine verwalten,
  • Informationen austauschen,
  • und zuverlässig kommunizieren

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:

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

Ein Produkt kann mehrere Services ermöglichen

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

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

Ein einzelner Service kann umgekehrt mehrere Produkte benötigen.

Ein digitaler Arbeitsplatzservice kann beispielsweise verwenden:

  • eine Identitätsplattform,
  • eine Endgeräteverwaltung,
  • eine E-Mail-Plattform,
  • eine Kollaborationsplattform,
  • Sicherheitsprodukte,
  • 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 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:

  • Konto erstellt,
  • Gruppen zugewiesen,
  • E-Mail-Adresse angelegt,
  • Lizenz vergeben,
  • Benutzerprofil vorbereitet.

Der neue Mitarbeiter kann trotzdem nicht arbeiten, wenn:

  • das Anfangskennwort nicht sicher übermittelt wurde,
  • die Multi-Faktor-Authentifizierung nicht eingerichtet werden kann,
  • notwendige Berechtigungen fehlen,
  • das Endgerät nicht bereitsteht,
  • die Anmeldung nicht getestet wurde,
  • oder erforderliche Freigaben fehlen.

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:

  • 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 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 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:

  • VPN-Infrastruktur bereitstellen,
  • Zugänge verwalten,
  • Sicherheitsmaßnahmen umsetzen,
  • Störungen bearbeiten,
  • den Service überwachen,
  • und Dokumentation bereitstellen.

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 Fachabteilung oder Führungskraft muss möglicherweise:

  • den Zugriff genehmigen,
  • benötigte Berechtigungen benennen,
  • Änderungen rechtzeitig mitteilen,
  • und organisatorische Voraussetzungen schaffen.

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:

  • 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 eine wichtige Fachanwendung nicht.
  • Das Backup läuft erfolgreich, wurde aber nie durch eine Wiederherstellung geprüft.
  • Der Druckservice ist erreichbar, aber der Benutzer kann keinen passenden Drucker auswählen.
  • Das Portal ist technisch verfügbar, aber für Benutzer nicht verständlich.
  • Ein Dienst antwortet, verarbeitet jedoch keine Transaktionen korrekt.

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

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

Praxisbeispiel: 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 Outcomes

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

Möglicher Wert

  • geringeres Risiko von Datenverlust,
  • bessere Zusammenarbeit,
  • zentrale Zugriffskontrolle,
  • nachvollziehbare Sicherung,
  • und geringerer Verwaltungsaufwand.

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:

  • Betrifft die Störung nur einen Benutzer?
  • Sind mehrere Standorte betroffen?
  • Funktioniert die Benutzeranmeldung?
  • Ist nur ein Laufwerk 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 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:

  • Zu welchem Produkt gehört die Komponente?
  • Welche Services verwenden sie?
  • Welche Benutzer sind abhängig?
  • Welche anderen Systeme greifen darauf zu?
  • Welche Outcomes können beeinträchtigt werden?
  • Welche Überwachung bestätigt die erfolgreiche Änderung?
  • Wie kann der vorherige Zustand wiederhergestellt werden?
  • Wer muss informiert werden?
  • Welche Dokumentationen müssen aktualisiert 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.

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:

  • 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?
  • Welche bekannten Fehler und Workarounds bestehen?

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:

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

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

Ein grüner Hoststatus bestätigt nicht automatisch:

  • eine erfolgreiche Anmeldung,
  • korrekte Berechtigungen,
  • ausreichende Leistung,
  • fehlerfreie Transaktionen,
  • oder eine brauchbare Benutzererfahrung.

Denkfehler 3: Installation bedeutet Abschluss

Eine Softwareinstallation ist zunächst ein Output.

Der gewünschte Zustand ist erst erreicht, wenn:

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

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:

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

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:

  • 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 Workarounds existieren?

Checkliste für technische Aufgaben

Bevor du eine technische Maßnahme durchführst:

  • Welche Komponente wird verändert?
  • Zu welchem System oder Produkt gehört sie?
  • Welche Services verwenden sie?
  • Welche Benutzer oder Geschäftsbereiche sind betroffen?
  • Welches Ergebnis soll die Maßnahme erreichen?
  • Welche Abhängigkeiten bestehen?
  • Welche Risiken entstehen?
  • Wird eine Freigabe benötigt?
  • Gibt es einen Rückfallplan?
  • Wie wird der Erfolg technisch geprüft?
  • Wie wird die Nutzbarkeit des Service geprüft?
  • Wer muss informiert werden?
  • Welche Dokumentationen müssen aktualisiert werden?

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:

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

Anschließend werden die dazugehörigen:

  • Komponenten,
  • Systeme,
  • 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
  • PeopleCert: ITIL Foundation Version 5 – What’s New?
  • ITIL: 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 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

Back to top