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 technische Komponenten erfassen Verbindungen und Abhängigkeiten bestimmen übergeordnetes System oder Produkt identifizieren unterstützte Services ermitteln Benutzer und weitere Stakeholder bestimmen erwartete Outputs und Outcomes erfassen kritische Geschäftsprozesse zuordnen Verantwortlichkeiten klären Monitoring und Wiederherstellung prüfen 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