# 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: - Wert wird von den beteiligten Stakeholdern wahrgenommen. - Verschiedene Stakeholder können denselben Service unterschiedlich bewerten. - Der wahrgenommene Wert kann sich im Laufe der Zeit verändern. 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: - Dateien zentral verfügbar werden, - mobiles Arbeiten möglich wird, - der Austausch großer Dateien vereinfacht wird, - lokale Speichersysteme entfallen, - Sicherungs- und Wiederherstellungsfunktionen verbessert werden. Für ein anderes Unternehmen kann derselbe Service ungeeignet sein, wenn: - gesetzliche Vorgaben nicht erfüllt werden, - die erforderliche Datenhoheit fehlt, - die Internetanbindung nicht ausreichend ist, - notwendige Schnittstellen fehlen, - die laufenden Kosten zu hoch sind. > 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: - Service Provider - Kunde - Benutzer - Sponsor - Lieferanten - Entwicklungsteams - Supportteams - Fachabteilungen - Management - Sicherheits- und Datenschutzverantwortliche - externe Partner **Beispiel: Einführung eines Ticketsystems** Der Service Provider kann: - die Plattform bereitstellen, - Benutzerkonten einrichten, - Rollen und Berechtigungen konfigurieren, - Schnittstellen implementieren, - Verfügbarkeit und Support gewährleisten. Die Kundenorganisation muss unter anderem: - Anforderungen formulieren, - Verantwortlichkeiten festlegen, - Kategorien und Prioritäten definieren, - Mitarbeiter schulen, - Daten pflegen, - Rückmeldungen geben, - das System in die eigenen Arbeitsabläufe integrieren. 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: - Störungen früher erkennen, - Ausfallzeiten verkürzen, - Kapazitätsengpässe rechtzeitig feststellen, - Ursachen schneller eingrenzen, - vereinbarte Service Levels einhalten. 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: - eine gewünschte Leistung ermöglicht, - eine bestehende Einschränkung beseitigt, - einen Arbeitsablauf verbessert, - eine Aufgabe automatisiert, - eine benötigte Funktion bereitstellt, - die Produktivität erhöht. 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: - Verfügbarkeit - Kapazität - Performance - Kontinuität - Informationssicherheit 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: - ausreichend Teilnehmer unterstützt werden, - Bild und Ton stabil übertragen werden, - der Service zu den benötigten Zeiten verfügbar ist, - die Verbindung angemessen geschützt wird, - Ausfälle innerhalb akzeptabler Zeiten behoben werden, - Datenschutz- und Compliance-Anforderungen erfüllt werden. --- **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** - Daten werden gesichert. - ältere Versionen können aufbewahrt werden. - Dateien und Systeme können wiederhergestellt werden. **Warranty** - Sicherungen werden im vereinbarten Intervall ausgeführt. - Sicherungsdaten werden vor unbefugtem Zugriff geschützt. - ausreichende Speicherkapazität steht zur Verfügung. - Wiederherstellungen sind innerhalb der benötigten Zeit möglich. - Sicherungskopien bleiben auch bei Ausfall eines Standorts verfügbar. > 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: - Anschaffungs- und Lizenzkosten - laufende Nutzungsgebühren - Betriebs- und Wartungskosten - Kosten für Hardware und Infrastruktur - Energie- und Raumkosten - Kosten für Personal - Schulungsaufwand - Migrationskosten - Integrationsaufwand - Kosten für Support - Kosten für Sicherheitsmaßnahmen - Kosten für Ausfallzeiten - Kosten für Anbieterwechsel oder Vertragsbeendigung - Aufwand für Compliance, Datenschutz und Dokumentation ITIL unterscheidet aus Sicht des Servicekonsumenten zwei grundlegende Wirkungen: - Kosten, die durch die Nutzung eines Services entstehen - Kosten, die der Servicekonsument durch die Nutzung des Services vermeiden oder reduzieren kann **Beispiel: Managed Backup** Durch den Service entstehen unter anderem: - monatliche Gebühren, - Einrichtungsaufwand, - Kosten für Datenübertragung, - Aufwand für regelmäßige Wiederherstellungstests. Gleichzeitig können andere Kosten reduziert oder vermieden werden: - eigene Backup-Infrastruktur, - Beschaffung zusätzlicher Speichersysteme, - manuelle Sicherungsarbeiten, - eigenes Spezialpersonal, - Folgekosten unzureichend gesicherter Daten. > 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: - Ausfälle - Sicherheitsvorfälle - Datenverlust - fehlerhafte Änderungen - unzureichende Kapazität - fehlende Kompetenzen - Abhängigkeit von Lieferanten - nicht erfüllte gesetzliche Anforderungen - falsche oder unvollständige Daten - unklare Verantwortlichkeiten - fehlende Wiederherstellbarkeit - Anbieterbindung - unkontrollierte Kostensteigerungen Auch bei Risiken müssen zwei Wirkungen unterschieden werden: - Risiken, die durch die Nutzung des Services entstehen - Risiken, die durch den Service reduziert oder übernommen werden **Beispiel: Cloudbasierter E-Mail-Service** Möglicherweise reduzierte Risiken: - Ausfall eigener Mailserver - veraltete lokale Software - fehlende eigene Betriebskapazität - unzureichende Skalierbarkeit - fehlende geografische Redundanz Möglicherweise neu entstehende oder verbleibende Risiken: - Abhängigkeit vom Anbieter - Abhängigkeit von der Internetverbindung - Fehlkonfiguration von Berechtigungen - Datenschutz- und Compliance-Risiken - eingeschränkte Migrationsmöglichkeiten - großflächige Störung beim Provider > 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: - einfache Bedienbarkeit - verständliche Kommunikation - Erreichbarkeit des Supports - angemessene Reaktionszeiten - transparente Statusinformationen - zuverlässige Zusagen - barrierearme Nutzung - nachvollziehbare Änderungen - respektvoller Umgang - verständliche Dokumentation **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: - Energieverbrauch - Ressourceneinsatz - Lebensdauer von Hardware - Reparierbarkeit - Wiederverwendung - fachgerechte Entsorgung - soziale Auswirkungen - langfristige Finanzierbarkeit - organisatorische Belastbarkeit - Abhängigkeit von knappen Ressourcen **Beispiel** Eine technisch leistungsfähige Lösung kann kurzfristig einen hohen Nutzen erzeugen. Wenn sie jedoch: - unverhältnismäßig viel Energie verbraucht, - nur schwer gewartet werden kann, - Personal dauerhaft überlastet, - hohe und unkontrollierbare Folgekosten erzeugt, - regulatorische Anforderungen gefährdet, 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** - Welche Ergebnisse sollen erreicht werden? - Für wen soll Wert entstehen? - Welche Kosten werden erwartet? - Welche Risiken sollen reduziert werden? - Welche neuen Risiken können entstehen? - Welche Utility wird benötigt? - Welche Warranty ist erforderlich? - Wie soll der Erfolg gemessen werden? **Nach der Einführung** - Wurden die gewünschten Outcomes erreicht? - Wird der Service tatsächlich verwendet? - Sind die geplanten Verbesserungen eingetreten? - Entsprechen die tatsächlichen Kosten der Planung? - Haben sich Risiken wie erwartet verändert? - Wie bewerten Benutzer und Kunden ihre Erfahrung? - Sind unerwünschte Nebenwirkungen entstanden? - Besteht Verbesserungsbedarf? > 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** - Beschäftigte können außerhalb des Standorts arbeiten. - Geschäftsprozesse bleiben auch bei Standortausfällen verfügbar. - Reisekosten und Wegezeiten werden reduziert. - externe Fachkräfte können sicher eingebunden werden. **Utility** - VPN-Zugang - Mehrfaktor-Authentifizierung - Zugriff auf Dateien und Anwendungen - Videokonferenzen - zentral verwaltete Endgeräte **Warranty** - ausreichende Verfügbarkeit - angemessene Performance - genügend gleichzeitige Verbindungen - sichere Authentifizierung - Wiederherstellbarkeit - Support zu den benötigten Zeiten **Zusätzliche Kosten** - Lizenzen - Endgeräte - Support - Schulung - Sicherheitslösungen - Internet- und Verbindungskosten **Möglicherweise vermiedene Kosten** - zusätzliche Büroflächen - Dienstreisen - lokale Infrastruktur an mehreren Standorten - Produktivitätsverluste bei Standortausfällen **Möglicherweise reduzierte Risiken** - vollständige Abhängigkeit von einem Bürostandort - unkontrollierte private Fernzugriffslösungen - Nutzung unverwalteter Endgeräte **Möglicherweise neu entstehende Risiken** - gestohlene Endgeräte - Phishing und kompromittierte Zugangsdaten - Fehlkonfigurationen - unzureichende private Netzwerkverbindungen - Datenschutzprobleme - soziale Isolation oder Überlastung **Mögliche Messgrößen** - Erfolgsquote von Anmeldungen - Verfügbarkeit des End-to-End-Services - Anzahl sicherheitsrelevanter Vorfälle - Zeit bis zur Bereitstellung eines Arbeitsplatzes - Zufriedenheit der Benutzer - Supportaufwand - tatsächlich vermiedene Kosten - Erreichung der fachlichen Arbeitsziele --- **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** - [ ] Der Servicekonsument ist eindeutig bestimmt. - [ ] Kunden, Benutzer und Sponsoren werden unterschieden. - [ ] Die gewünschten Outcomes sind beschrieben. - [ ] Die erforderliche Utility ist festgelegt. - [ ] Die erforderliche Warranty ist festgelegt. - [ ] technische und fachliche Anforderungen sind verbunden. - [ ] zusätzliche Kosten sind erfasst. - [ ] vermeidbare oder reduzierte Kosten sind erfasst. - [ ] neu entstehende Risiken sind erfasst. - [ ] reduzierte oder übernommene Risiken sind erfasst. - [ ] Verantwortlichkeiten sind vereinbart. - [ ] Abhängigkeiten und Lieferanten sind berücksichtigt. - [ ] Benutzererfahrung und Zugänglichkeit werden bewertet. - [ ] Nachhaltigkeitsaspekte werden berücksichtigt. - [ ] Kennzahlen besitzen einen Bezug zu den gewünschten Outcomes. - [ ] Annahmen werden nach der Einführung überprüft. - [ ] Kunden- und Benutzerfeedback wird ausgewertet. - [ ] Verbesserungen werden dokumentiert und priorisiert. --- **17. Versionshinweis: ITIL 4 und ITIL (Version 5)** Die grundlegende Wertorientierung bleibt auch in ITIL (Version 5) erhalten. Dazu gehören insbesondere: - gemeinsame Wertschöpfung, - Ausrichtung auf Outcomes, - Betrachtung von Kosten und Risiken, - Zusammenarbeit zwischen Providern, Konsumenten und Stakeholdern, - ganzheitliches Management digitaler Produkte und Services, - kontinuierliche Verbesserung. 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** - [PeopleCert – ITIL Foundation (Version 5)](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-5-foundation-version-50-4154) - [PeopleCert – ITIL Foundation Version 5: Neuerungen](https://www.peoplecert.org/news-and-announcements/itil-version-5-foundation-whats-new-guide) - [PeopleCert – ITIL Qualification Scheme](https://www.peoplecert.org/Frameworks-Professionals/ITIL-framework) - [PeopleCert – ITIL 4 Foundation](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565) - [PeopleCert – ITIL 4 Practitioner: Service Level Management](https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-practitioner-service-level-management-3867)