Service-Wertsystem und Service-Wertschöpfungskette

Ein Service-Wertsystem (SVS) beschreibt, wie die Komponenten und Aktivitäten einer Organisation zusammenwirken, um Wertschöpfung zu ermöglichen. ITIL 4 verwendet diesen Namen; ITIL Version 5 nennt es ITIL-Wertsystem. Version 5 wurde im Januar 2026 eingeführt, sein Foundation-Lehrplan trägt das Datum Februar 2026.

Inputs und Output

Nachfrage ist das Bedürfnis oder der Wunsch von Konsumenten nach Produkten und Services. Beschäftigte, die sicheren Fernzugriff wünschen, äußern Nachfrage. Eine Chance ist eine Möglichkeit, zusätzlichen Wert zu schaffen oder die Organisation zu verbessern, etwa eine ungenutzte Cloud-Funktion, die Kosten senken könnte. Die Organisation entscheidet, welche Chancen sie verfolgt.

Der Output des Systems ist Wert: die Vorteile, der Nutzen und die Bedeutung, die Stakeholder wahrnehmen. Eine fertige App zur Ausgabenabrechnung ist ein Produkt der Arbeit. Dass Führungskräfte Abrechnungen in zwei Minuten statt in zwei Tagen genehmigen, ist ein Ergebnis, das die App nützlich macht. Die Fertigstellung der Software allein belegt noch nicht, dass Menschen davon profitieren.

Wert entsteht durch gemeinsame Wertschöpfung. Der Provider trägt Technologie und Support bei; Konsumenten bringen Wissen, Entscheidungen und die Nutzung ein. Eine klare Störungsmeldung mit einem Screenshot kann einem Mitarbeiter helfen, den Service früher wiederherzustellen.

Fünf Komponenten wirken zusammen

Version 5 verwendet für die entsprechenden Komponenten die Begriffe Wertschöpfungskette und Management Practices. Diese Komponenten wirken zusammen, während eine Aktivität stattfindet. Sie sind keine fünf Phasen, die nacheinander abgeschlossen werden.

Die sieben Grundprinzipien bleiben bestehen: Wertorientierung; dort beginnen, wo man steht; iterative Weiterentwicklung mit Feedback; Zusammenarbeit und Transparenz fördern; ganzheitlich denken und arbeiten; auf Einfachheit und Praktikabilität achten; optimieren und automatisieren. Sie prägen Entscheidungen im gesamten System. „Dort beginnen, wo man steht“ bedeutet zum Beispiel, einen bestehenden Prozess zur Kennwortzurücksetzung zu prüfen, bevor man ihn ersetzt.

Verfolge eine Verbesserung bei der Kennwortzurücksetzung

Eine Bank mit 40 Filialen erhält Meldungen über 20 Minuten Wartezeit am Telefon für die Kennwortzurücksetzung. Das ist Nachfrage. Ihre Identitätsplattform hat eine ungenutzte Funktion zur Kennwortzurücksetzung per Selbstbedienung: eine Chance.

Die Governance prüft die Idee anhand der Sicherheitsrichtlinie. Aktivitäten der Wertschöpfungskette erfassen die Bedürfnisse der Beschäftigten, entwerfen und erstellen den Ablauf zur Kennwortzurücksetzung und nehmen ihn in Betrieb. Die Practices Service Desk, Informationssicherheitsmanagement und Change Enablement stellen Menschen, Wissen und Werkzeuge bereit. Die kontinuierliche Verbesserung prüft später, ob die Wartezeit gesunken ist. Dass Beschäftigte innerhalb weniger Minuten weiterarbeiten können, ist der Wert, den sie erleben.

Das ganze System betrachten

Ein Silo entsteht, wenn Teams isoliert arbeiten und wenig Informationen austauschen. Getrennte Teamziele können doppelte Arbeit oder bei Übergaben verlorene Informationen verdecken. Eine gemeinsame Sicht auf den Weg zum Wert hilft Teams bei der Koordination, und das System lässt bei veränderter Nachfrage unterschiedliche Wege zu.

Die vier Dimensionen sind Perspektiven, um das ganze System zu untersuchen: Organisationen und Menschen, Informationen und Technologie, Partner und Lieferanten sowie Wertströme und Prozesse. Sie unterscheiden sich von seinen fünf Komponenten. Das SVS kann eine ganze Organisation oder einen Teil davon beschreiben, unabhängig von Branche und Größe.

Governance lenkt und überwacht eine Organisation. Sie sorgt dafür, dass die Arbeit auf Zweck, Strategie und Richtlinien der Organisation ausgerichtet bleibt. Ein Leitungsorgan ist die Person oder Gruppe mit der höchsten Rechenschaftspflicht für Leistung und die Einhaltung von Vorgaben: ein Vorstand, ein Kuratorium oder der Inhaber einer kleinen Firma. Ein Ausschuss kann eine Entscheidung vorbereiten, aber das Leitungsorgan bleibt rechenschaftspflichtig.

Bewerten, Lenken und Überwachen

Um eine Maßnahme zuzuordnen, frag dich, was die Entscheidung bewirkt. Eine mögliche Richtung zu beurteilen, ist Bewerten; Richtung und Verantwortung festzulegen, ist Lenken; die Leistung daran zu überprüfen, ist Überwachen. Der Name des Dokuments allein reicht nicht aus: Ein Bericht kann eine Entscheidung beim Bewerten oder beim Überwachen unterstützen.

Richtung in tägliche Entscheidungen umsetzen

Eine Richtlinie hält Erwartungen und Absichten formell fest, die Entscheidungen und Aktivitäten leiten. Zum Beispiel: „Personenbezogene Daten von Kunden müssen in zugelassenen Rechenzentren innerhalb der Region des Kunden gespeichert werden.“ Das Management wählt und konfiguriert dann Rechenzentren, die die Richtlinie erfüllen. Die Richtlinie gibt eine gemeinsame Regel vor, ohne jede technische Handlung festzulegen.

Governance und Management haben unterschiedliche Aufgaben. Governance gibt die Richtung vor, genehmigt Richtlinien und überwacht Ergebnisse. Das Management plant, organisiert und erledigt die Arbeit innerhalb dieser Vorgaben und berichtet anschließend darüber.

Angenommen, ein Vorstand gibt vor, dass ein Onlineshop 99,9 % Verfügbarkeit erreichen muss. Das IT-Management entscheidet, wie der Shop gestaltet, gewartet und unterstützt wird. Es misst die Verfügbarkeit und berichtet die Ergebnisse an den Vorstand. Der Vorstand überwacht diese Ergebnisse anhand seiner Vorgabe; er muss nicht jede Servereinstellung auswählen.

Kontrollen können schnelleres Arbeiten ermöglichen

Klare Risikoschranken ermöglichen Teams, routinemäßige Entscheidungen sicher zu treffen. Eine Richtlinie kann erlauben, risikoarme Standard-Changes vorab zu genehmigen, während Changes mit höherem Risiko gesondert bewertet werden. Teams wissen dann, wann sie handeln können und wann sie eine Change-Autorität einbeziehen müssen.

Eine Change-Autorität entscheidet im Rahmen des Managements über einzelne Changes. Sie ist nicht allein deshalb das Leitungsorgan, weil sie Arbeit genehmigt. Eine zusätzliche Genehmigung durch einen Ausschuss für jeden Change kann die Bereitstellung von Wert verlangsamen, ohne die Kontrolle zu verbessern. Prüfe anhand des Grundprinzips „Auf Einfachheit und Praktikabilität achten“, ob jede Kontrolle einen sinnvollen Zweck erfüllt.

Dieselbe Logik auf KI anwenden

KI-Governance schafft Aufsicht, Richtlinien und Rechenschaftspflichten für eine sichere, rechtmäßige und transparente KI-Nutzung, die die Ziele der Organisation unterstützt. Ein Leitungsorgan bewertet einen vorgeschlagenen KI-Service und seine Risiken, legt fest, wer rechenschaftspflichtig ist und welche Richtlinien gelten, und überwacht Leistung und die Einhaltung von Vorgaben. Das Management implementiert und betreibt den Service innerhalb dieser Schranken.

Auch Governance braucht kontinuierliche Verbesserung. Das Leitungsorgan prüft, ob seine Kontrollen weiterhin nützlich sind, wenn sich Organisation, Technologie und Risiken ändern. Eine Richtlinie, die einst gute Entscheidungen unterstützte, muss möglicherweise überarbeitet werden, wenn sie beginnt, Arbeit zu verzögern, ohne einem aktuellen Risiko zu begegnen.

Die Service-Wertschöpfungskette ist ein Betriebsmodell für die Erstellung, Bereitstellung und kontinuierliche Verbesserung von Services. Ein Betriebsmodell beschreibt, wie eine Organisation gemeinsam mit anderen Wert schafft und sich selbst betreibt. ITIL 4 nennt sechs miteinander verbundene Aktivitäten. Jede wandelt Inputs in Outputs um, und diese Outputs können zu Inputs für andere Aktivitäten werden.

Was jede Aktivität beiträgt

Arbeit anhand ihres Zwecks zuordnen

Zu entscheiden, im nächsten Jahr die Finanzierung von Cloud-E-Mail bereitzustellen, ist Planen. Die Beschwerde eines Anwenders entgegenzunehmen oder die Geschäftsanforderungen für das nächste Jahr zu besprechen, ist Einbinden, der wichtigste Kontakt zu Konsumenten und anderen externen Beteiligten. Sinkende Zufriedenheit zu analysieren und eine Verbesserung zu vereinbaren, ist Verbessern.

Für einen Online-Buchungsservice definiert Design und Überführung Qualitäts- und Anwenderanforderungen und organisiert die Überführung in den Produktivbetrieb. Beschaffen/Erstellen erstellt und testet Software oder beschafft Komponenten von einem Lieferanten. Den Service täglich zu betreiben und ihn nach einem Ausfall wiederherzustellen, ist Bereitstellen und Unterstützen.

Für eine sinnvolle Zuordnung kommt es darauf an, was die Arbeit bewirkt. Der Kauf von 200 Laptops macht Komponenten verfügbar und gehört daher zu Beschaffen/Erstellen. Feedback der Beschäftigten zu diesen Laptops einzuholen, dient dem Einbinden. Dieselben Personen können bei beiden Aktivitäten mitwirken.

Outputs verbinden die Aktivitäten

Eine durch Einbinden erfasste Anfrage kann zum Input für Design und Überführung werden. Eine durch Beschaffen/Erstellen gelieferte Komponente kann durch Design und Überführung in den Produktivbetrieb gelangen. Leistungsinformationen aus Bereitstellen und Unterstützen können Verbessern zeigen, wo Ergebnisse schwach sind, und Planen bei der Priorisierung helfen.

Diese Verbindungen geben keine feste Reihenfolge vor. Eine kleine Anfrage kann nur die Aktivitäten nutzen, die sie braucht. Bei einem neuen Service kann Design und Überführung erneut durchlaufen werden, nachdem Feedback eine fehlende Anforderung aufgedeckt hat. Verbessern kann an einem bestehenden Service arbeiten, während Beschaffen/Erstellen eine neue Komponente entwickelt.

Aktivitäten reichen über Practices oder Teams hinaus

Jede Aktivität greift auf mehrere Practices zurück, und eine Practice kann mehrere Aktivitäten unterstützen. Service Level Management hilft Einbinden, Kundenziele zu vereinbaren, Bereitstellen und Unterstützen, Ergebnisse zu beurteilen, und Verbessern, verfehlte Ziele zu erkennen. Bereitstellen und Unterstützen kann daher nicht mit dem Service Desk gleichgesetzt werden.

Wer die sechs Aktivitäten als feste Projektabfolge liest, übersieht diese Flexibilität. Das Modell stellt verbundene Arten von Arbeit bereit; ein Wertstrom wählt daraus einen Weg für die jeweilige Nachfrage.

Ein Wertstrom ist eine Reihe von Schritten, um Produkte und Services für Konsumenten zu erstellen und bereitzustellen. Er ist ein praktischer Weg durch die Aktivitäten der Wertschöpfungskette. Jeder Schritt beruht außerdem auf Practices, die Kompetenzen, Informationen, Werkzeuge und Prozesse bereitstellen.

Drei Ebenen unterscheiden

Ein Prozess läuft häufig innerhalb einer Practice ab und trägt zu einem Teil eines Wertstroms bei. Eine Liste von Abteilungen sagt dir, wer beteiligt ist, erklärt aber nicht, was zwischen dem Auslöser und dem nützlichen Ergebnis geschieht.

Eine Wertstromdarstellung erstellen

1. Benenne den Auslöser: die Nachfrage oder Chance, die die Arbeit in Gang setzt.
2. Liste die tatsächlichen Schritte auf, bis der Konsument Wert erhält.
3. Ordne jeden Schritt der Aktivität der Wertschöpfungskette zu, die er ausführt.
4. Ergänze die wichtigsten Practices, die er braucht.
5. Überprüfe das Ende mit dem Konsumenten und lass die Ergebnisse in die Verbesserung einfließen.

Eine Wiederherstellung verfolgen

Ein Anwender meldet einen Fehler in der Vertriebs-App. Der Service Desk erfasst und beurteilt ihn: Einbinden, unterstützt durch Service Desk und Incident Management. Der Support setzt einen bekannten Workaround ein, damit der Verkauf weitergehen kann: Bereitstellen und Unterstützen, mithilfe von Incident Management und Wissen über den Workaround.

Entwickler untersuchen die Ursache und schreiben und testen eine dauerhafte Fehlerbehebung: Beschaffen/Erstellen, unter Rückgriff auf Problem Management und Softwareentwicklung. Die Fehlerbehebung zu beurteilen, zu genehmigen und in Betrieb zu nehmen, trägt zu Design und Überführung bei und nutzt Change Enablement und Deployment Management.

Das Team informiert den Anwender und prüft, ob die App funktioniert: Einbinden, gefolgt von der Bestätigung für Bereitstellen und Unterstützen. Die Entwicklung ähnlicher Incidents zu überprüfen, ist Verbessern. Der Wert für den Konsumenten besteht darin, wieder verkaufen zu können. Die Wiederherstellung kann diesen Wert liefern, bevor die dauerhafte Fehlerbehebung abgeschlossen ist.

Wege können Aktivitäten wiederholen

Eine mobile Funktion zur Genehmigung von Ausgabenabrechnungen folgt einem anderen Weg: Einbinden erfasst den Bedarf; Planen legt Priorität und Budget fest; Design und Überführung definiert Anforderungen; Beschaffen/Erstellen erstellt die Funktion; Design und Überführung nimmt sie in Betrieb; Bereitstellen und Unterstützen stellt sie zur Verfügung; Einbinden sammelt Feedback; Verbessern plant Änderungen. Dass Einbinden oder Design und Überführung wiederholt wird, ist normal. Der Weg folgt den Erfordernissen der Arbeit.

Kernwertströme und unterstützende Wertströme

In Version 5 liefert ein Kernwertstrom externen Konsumenten auf die im Betriebsmodell vorgesehene Weise Wert, etwa durch die Erfüllung von Kundenbestellungen. Ein unterstützender Wertstrom dient internen Konsumenten und unterstützt Kernwertströme, etwa bei der Einarbeitung von Mitarbeitern oder der Einbindung von Lieferanten. Beide nutzen dieselben Aktivitäten. „Unterstützend“ beschreibt, wem der Wertstrom dient und was er unterstützt; es bedeutet nicht, dass die Arbeit keinen Wert hat.

Die Darstellung macht die Dimension Wertströme und Prozesse sichtbar. Sie wendet „Ganzheitlich denken und arbeiten“ an, indem sie den ganzen Weg zeigt, einschließlich der Übergaben zwischen Teams, die möglicherweise jeweils nur einen Teil sehen.

Die Wertstromanalyse untersucht und zeigt, wie Arbeit fließt, damit Teams erkennen, wie Wert entsteht und wo Verbesserungen möglich sind. Wertstrommanagement ist die fortlaufende Steuerung und Verbesserung dieses Ablaufs.

Verzögerungen sichtbar machen

Eine Ist-Wertstromdarstellung erfasst, wie die Arbeit tatsächlich abläuft. Nimm Schritte, beteiligte Personen, weitergegebene Informationen und Artefakte, Bearbeitung und Wartezeiten auf. Eine Soll-Wertstromdarstellung zeigt den verbesserten Ablauf, den das Team erreichen möchte. Wer nur das offizielle Verfahren erfasst, übersieht möglicherweise Warteschlangen und wiederholte Dateneingaben, die die Wartezeit eines Konsumenten erklären.

Die Durchlaufzeit ist die verstrichene Zeit vom Auslöser bis zum bereitgestellten Wert. Die Bearbeitungszeit ist die Zeit, in der an dem Vorgang gearbeitet wird. Für einen sequenziellen Wertstrom, in dem sich Bearbeitungs- und Wartezeiten nicht überschneiden, gilt:

Verwende im Zähler und Nenner dieselbe Zeiteinheit.

Eine Laptopanfrage durchrechnen

Die Bearbeitungszeit beträgt 4 h. Die Wartezeit beträgt 48 h, woraus sich 52 h Durchlaufzeit ergeben. Die Flusseffizienz beträgt etwa 7,7 %, weil nur in 4 der 52 verstrichenen Stunden an dem Vorgang gearbeitet wird.

Wird der Standard-Laptop vorab genehmigt, sinkt die Wartezeit auf die Genehmigung von 16 h auf 1 h. Die Bearbeitungszeit bleibt bei 4 h; die Wartezeit beträgt nun 33 h. Die Durchlaufzeit beträgt jetzt 37 h und die Flusseffizienz etwa 10,8 %. Die verbleibende Wartezeit von 24 h auf das Einrichtungsteam bietet sich als Nächstes zur Untersuchung an.

Wird die Konfigurationsaufgabe von 2 h halbiert, spart das von den ursprünglichen 52 h nur 1 h ein: etwa 1,9 %. Die Verkürzung der Wartezeit auf die Genehmigung sparte 15 h. Prüfe nach einer Änderung den gesamten Wertstrom; wenn Arbeit schneller in eine andere Warteschlange gelangt, kann die gesamte Durchlaufzeit unverändert bleiben.

Die Verbesserung an die Art der Arbeit anpassen

Komplexitätsdenken hilft bei der Wahl einer Arbeitsweise.

• Geordnete Arbeit ist vorhersehbar. Für Standard-Laptopanfragen können vereinbarte Schritte und Automatisierung genutzt werden.
• Bei komplexer Arbeit werden Ursache und Wirkung erst im Nachhinein klar. Die Entwicklung eines neuartigen digitalen Produkts verlangt kleine Experimente und schnelles Feedback.
• Chaotische Situationen müssen zuerst stabilisiert werden. Stelle bei einem großen Ausfall mit unbekannter Ursache ausreichend Kontrolle für eine anschließende sinnvolle Analyse her.

Wer unsichere Arbeit wie ein vollständig bekanntes Verfahren behandelt, kann eine schlechte Lösung festschreiben. Wer jede Routineanfrage als Experiment behandelt, verschwendet Aufwand. Wähle einen Ansatz, der zur Situation passt, und passe ihn dann anhand der beobachteten Ergebnisse an.

Das Wertstrommanagement nutzt die Darstellung und Kennzahlen, um die Practices hinter dem Ablauf zu verbessern, unnötige Genehmigungen und wiederholte Eingaben zu beseitigen und den Weg bei veränderter Nachfrage erneut zu beurteilen. Für jede vorgeschlagene Änderung kann das Modell zur kontinuierlichen Verbesserung genutzt werden, um eine Baseline festzulegen, zu handeln und Ergebnisse zu prüfen.

Das Management digitaler Produkte und Services steuert Produkte und Services, die von digitaler Technologie abhängen, von der Idee bis zur Außerbetriebnahme. Ein digitales Produkt besteht hauptsächlich aus Software, Daten und digitaler Infrastruktur, etwa eine Mobile-Banking-App. Ein digitaler Service gibt Konsumenten Zugang zu den Möglichkeiten von Produkten, etwa zu Online-Zahlungen.

Der Lebenszyklus von Version 5

Der ITIL-Produkt- und Servicelebenszyklus nennt acht Aktivitäten: Entdecken, Entwerfen, Beschaffen, Erstellen, Überführen, Betreiben, Bereitstellen und Unterstützen. Die ersten vier erstellen und ändern hauptsächlich Produkte; die letzten vier betreiben hauptsächlich Produkte und stellen damit Services bereit. Überführen bringt neue oder geänderte Produkte in den Produktivbetrieb.

Aus Sicht der Organisation bilden diese Aktivitäten die Wertschöpfungskette von Version 5. Ein Wertstrom kombiniert sie mit Management Practices für eine bestimmte Art von Nachfrage. Der Lebenszyklus beschreibt die Arbeit, die während der Lebensdauer eines Produkts nötig ist; ein Wertstrom beschreibt einen bestimmten Weg durch diese Arbeit.

Das Wertsystem bleibt das übergeordnete System mit seinen fünf Komponenten. Der Lebenszyklus ersetzt weder Governance noch Grundprinzipien, Practices oder kontinuierliche Verbesserung.

Aktivitäten gemeinsam einsetzen

Der Lebenszyklus ist keine einzelne lineare Abfolge. Entdecken kann weitergehen, während Entwickler ein Release erstellen. Feedback aus dem Support kann direkt zum Entwerfen führen. Bei einem Produkt, das alle zwei Wochen veröffentlicht wird, können Entwerfen, Erstellen und Überführen erneut stattfinden, während der bestehende Service weiterläuft und Anwender versorgt.

Eine Stadtverwaltung führt eine App ein, mit der defekte Straßenlaternen gemeldet werden können. Der Support bemerkt, dass Meldungen ohne Ortsangabe eingehen. Entdecken untersucht den Grund, Entwerfen ergänzt eine automatische Kartenmarkierung und Erstellen und Überführen implementieren und führen sie ein. Betreiben und Bereitstellen halten die bestehende App während dieser Arbeit verfügbar. Das Produkt ist gleichzeitig an mehreren Aktivitäten beteiligt.

Version 5 und ITIL 4 in Beziehung setzen

Die folgende Übersicht vergleicht die Arbeit grob; die Aktivitäten entsprechen einander nicht genau.

Die Versionen gruppieren Arbeit unterschiedlich. Deshalb müssen die Aktivitäten eines konkreten Wertstroms anhand ihres jeweiligen Zwecks betrachtet werden. Betreiben hält die Technologie in gutem Zustand; Bereitstellen stellt den Service zur Verfügung und kümmert sich um alltägliche Anwenderbedürfnisse. Sie tragen durch unterschiedliche Arbeit zum selben Ergebnis bei.

Ergebnisse der Aktivitäten messen

Nützliche Beispiele für Kennzahlen sind der überprüfte Bedarf der Konsumenten hinter Roadmap-Einträgen für Entdecken, die Bestehensquote automatisierter Tests für Erstellen und ohne Incidents ausgerollte Changes für Überführen. Betreiben kann die Verfügbarkeit verfolgen, Bereitstellen die Erfüllungszeit von Anfragen und die Anwenderzufriedenheit und Unterstützen die Wiederherstellungszeit.

Diese Kennzahlen helfen, Schwachstellen in einem Wertstrom zu finden. Eine hohe Bestehensquote bei Tests während des Erstellens kann mit einer langsamen Erfüllung von Anfragen einhergehen: Der Erfolg einer Aktivität zeigt nicht, ob der Konsument rechtzeitig einen nützlichen Service erhält.

Um ein nützliches digitales Produkt zu erstellen, muss man ein Bedürfnis verstehen, eine Lösung gestalten, Ressourcen beschaffen und die Lösung funktionsfähig machen. Version 5 nennt diese Arbeit Entdecken, Entwerfen, Beschaffen und Erstellen. Feedback kann Arbeit zwischen diesen Aktivitäten hin und her führen, bevor ein vollständiges Produkt existiert.

Ein Bedürfnis entdecken, das erfüllt werden sollte

Entdecken untersucht die Bedürfnisse der Konsumenten, Chancen durch Technologie und auf dem Markt sowie die Strategie der Organisation. Es hilft bei der Entscheidung, welche Produkte und Services angeboten oder geändert werden sollen, und hält die Roadmap auf diese Bedürfnisse und Chancen ausgerichtet. Eine Roadmap gibt die Richtung für die geplante Produktentwicklung vor; sie muss überarbeitet werden, wenn sich die Erkenntnisse ändern.

Eine Untersuchung für eine Klinik zeigt, dass Patienten Termine online buchen möchten. Die Klinik nimmt die Online-Buchung in ihre Roadmap auf. Die nützliche Entdeckung ist das Bedürfnis der Patienten und der Service, den es unterstützen könnte, nicht allein die Möglichkeit, eine neue Anwendung zu erstellen.

Die gesamte Lösung entwerfen

Entwerfen setzt Bedürfnisse in Spezifikationen und Prototypen um. Eine Produktspezifikation beschreibt die benötigten Funktionen, Qualitätsniveaus und Einschränkungen. Ein Prototyp ist eine frühe vereinfachte Version, mit der eine Idee mit Anwendern getestet wird, bevor das vollständige Produkt erstellt wird.

Die Spezifikation der Klinik verlangt, dass Patienten einen Termin auf höchstens drei Bildschirmseiten buchen, verschieben oder absagen, das System außerhalb der Bürozeiten nutzen und 24 Stunden vor einem Besuch Erinnerungen erhalten können. Jede Anforderung beschreibt ein Verhalten oder eine Qualität, anhand deren die fertige Lösung überprüft werden kann.

Zehn Patienten probieren einen anklickbaren Prototyp aus. Vier finden die Schaltfläche zum Absagen nicht. Das Team ändert den Entwurf, bevor es die vollständige Software schreibt. Ein Prototyp dient dem Lernen; er kann verworfen werden, nachdem er seine Frage beantwortet hat. Wer ihn als nahezu fertige Software behandelt, kann ein Team dazu bringen, einen schwachen Entwurf beizubehalten, nur weil bereits etwas existiert.

Entwerfen umfasst auch, wie das Produkt betrieben und unterstützt wird. Monitoring, Sicherungen und Hilfe für Anwender brauchen einen Platz in der Lösung. Werden diese Anforderungen erst nach der Einführung erkannt, können kostspieligere Änderungen nötig sein. Damit wird „Ganzheitlich denken und arbeiten“ auf den gesamten Lebenszyklus des Produkts angewendet.

Ressourcen beschaffen

Beschaffen besorgt oder weist die Ressourcen zu, die die Lösung braucht. Dazu gehören Cloud-Kapazität, Lizenzen, Geräte, Daten und Menschen mit geeigneten Kompetenzen. Ressourcen können von Lieferanten oder aus der Organisation selbst stammen. Auch die Wiederverwendung einer vorhandenen Komponente oder die Zuweisung einer internen Fachkraft gehört zur Beschaffung.

Die Klinik schließt für Erinnerungen einen Vertrag mit einem SMS-Anbieter. Außerdem stellt sie interne Mitarbeiter zur Unterstützung des Buchungssystems bereit. Kaufen ist eine Möglichkeit, Ressourcen zu beschaffen; es umfasst nicht die ganze Bedeutung der Aktivität.

Die funktionierende Lösung erstellen und prüfen

Erstellen entwickelt, integriert und testet Komponenten, um aus dem Entwurf eine funktionierende Lösung zu machen. Ein Test prüft, ob eine Komponente oder ein Produkt die Anforderungen erfüllt und sich wie erwartet verhält. Beim Test der Erinnerungsfunktion wird auch der festgelegte Zeitpunkt geprüft und nicht nur, ob eine Nachricht gesendet werden kann.

Bei der kontinuierlichen Integration führen Entwickler Änderungen häufig in einer gemeinsamen Codebasis zusammen; automatisierte Builds und Tests prüfen diese Änderungen. Das liefert früh Feedback zu Integrationsfehlern und Mängeln, die die Tests erkennen können. Bestandene Tests belegen nicht, dass jeder Mangel gefunden wurde; das Ergebnis hängt davon ab, was getestet wurde.

Die Klinik kann ihren Entwurf nach einem Prototyptest überarbeiten, nach einem Test während der Erstellung eine andere Ressource beschaffen oder ein neues Bedürfnis entdecken, während das Produkt erstellt wird.

Ein funktionierendes digitales Produkt muss in den Produktivbetrieb gelangen, in gutem Zustand bleiben und einen nützlichen Service bereitstellen. Anwender brauchen außerdem Hilfe, wenn der Service ausfällt. Version 5 teilt diese Arbeit in Überführen, Betreiben, Bereitstellen und Unterstützen auf.

In den Produktivbetrieb überführen

Überführen führt neue oder geänderte Produkte und Services ein und umfasst Release, Deployment sowie die Einbindung und Ausgliederung von Lieferanten. Deployment überführt Komponenten in eine Umgebung. Ein Release macht eine Version oder eine Gruppe von Komponenten zur Nutzung verfügbar. Software kann in der Produktivumgebung installiert werden, während eine Funktion abgeschaltet ist; Deployment und Release müssen daher nicht gleichzeitig stattfinden.

Continuous Delivery hält getestete Änderungen für das Deployment bereit, wobei eine Person über den Zeitpunkt entscheidet. Continuous Deployment überführt jede Änderung, die automatisierte Tests besteht, ohne manuelle Entscheidung in die Produktivumgebung. Keiner der beiden Begriffe bedeutet, dass Anwender bei jeder Überführung von Komponenten zwangsläufig eine neue Funktion erhalten.

Zuverlässige Technologie betreiben

Betreiben betreibt, wartet und überwacht Produkte entsprechend der vereinbarten Leistung und Zuverlässigkeit. Zuverlässigkeit ist die Fähigkeit, geforderte Funktionen über einen Zeitraum wie erwartet zu erfüllen. Beobachtbarkeit bedeutet, den internen Zustand eines Systems anhand von Ausgaben wie Protokollen, Kennzahlen und Ablaufspuren zu verstehen. Site Reliability Engineering (SRE) wendet Softwareentwicklung auf den Betrieb an, einschließlich Automatisierung und messbarer Zuverlässigkeitsziele.

Ein Ereignis ist eine Zustandsänderung, die für das Management eines Services oder Konfigurationselements von Bedeutung ist. Der Abschluss einer Sicherung ist ein Ereignis; ebenso das Erreichen einer Festplattenauslastung von 90 %. Viele Ereignisse müssen nur erfasst werden. Andere warnen davor, dass ein Eingreifen einen Incident verhindern könnte.

Bei einem Buchungsservice, der während eines ganzen Monats mit 30 Tagen zu 99,9 % verfügbar ist, beträgt die Gesamtzeit 43.200 Minuten. Die erlaubte Ausfallzeit beträgt 0,1 % davon: 43,2 Minuten. Bei 43 Minuten Ausfallzeit beträgt die Verfügbarkeit etwa 99,90 % und erfüllt das Ziel gerade noch. Vergleiche ungerundete Werte, bevor du entscheidest, ob ein knappes Ergebnis ein Ziel erfüllt.

Reguläre Serviceaktionen bereitstellen

Bereitstellen stellt Services im Alltag zur Verfügung, bindet Anwender ein und meldet sie ab, erfüllt Anfragen und sammelt Feedback. Eine Serviceanfrage bittet um eine vereinbarte reguläre Serviceaktion, etwa Zugang zu einem freigegebenen Ordner oder einen neuen Laptop. Der berechtigte Anwender oder sein Vertreter stellt die Anfrage.

Unterstützen, wenn ein Service ausfällt

Unterstützen stellt den normalen Betrieb wieder her und verringert künftige Ausfälle durch die Lösung von Incidents, die Wiederherstellung nach Katastrophen und das Management von Problemen. Ein Incident ist eine ungeplante Unterbrechung oder Qualitätsminderung. Eine Katastrophe verursacht schwere Verluste oder Schäden, etwa ein Brand, der ein Rechenzentrum zerstört.

Ein Problem ist eine tatsächliche oder mögliche Ursache von Incidents. Ein Fehler ist ein Mangel oder eine Schwachstelle, die Incidents verursachen kann. Ein bekannter Fehler ist ein analysiertes Problem, das noch nicht gelöst wurde.

Angenommen, 30 Personen können nach einem fehlerhaften Treiberupdate nicht drucken. Ihre Serviceausfälle sind Incidents. Das fehlerhafte Update ist das Problem; sobald es analysiert, aber noch nicht behoben ist, ist das Problem ein bekannter Fehler. Das Zurücksetzen des Treibers kann das Drucken wieder ermöglichen, während die dauerhafte Fehlerbehebung noch aussteht. Die Wiederherstellung bedeutet daher nicht, dass die Ursache beseitigt wurde.

„Ich brauche Zugang zum Vertriebsordner“ ist eine Anfrage. „Der Vertriebsordner lässt sich nicht öffnen“ meldet einen Incident. Ermittle, ob der Anwender eine reguläre Aktion oder die Wiederherstellung einer ausgefallenen Funktion wünscht.

Eine Practice ist eine Gesamtheit organisatorischer Ressourcen, die zur Ausführung von Arbeit oder zum Erreichen eines Ziels bestimmt sind. Version 5 nennt sie Management Practice. Eine Practice umfasst alle vier Dimensionen, darunter Menschen und Kompetenzen, Informationen und Technologie, Partner und Lieferanten sowie Wertströme und Prozesse.

Eine Practice reicht über einen Prozess oder eine Abteilung hinaus. Incident Management kann Prozesse zur Erfassung und Diagnose, eine Wissensdatenbank, Monitoring-Werkzeuge und Menschen aus einem Service Desk, einem Netzwerkteam und einem Lieferanten umfassen. Diese Ressourcen schaffen gemeinsam die Fähigkeit, den Service wiederherzustellen.

Zwei Arten, die 34 Practices zu gruppieren

Version 5 behält die 34 Practice-Namen bei. Deployment Management, Infrastruktur- und Plattformmanagement sowie Softwareentwicklung und -management wechseln aus der technischen Gruppe in das Produkt- und Service-Management. Informationssicherheitsmanagement und Servicefinanzmanagement wechseln ebenfalls in diese Gruppe, und zwar aus dem allgemeinen Management.

Allgemeine Management Practices in Version 5

Die 12 Practices sind Architekturmanagement; kontinuierliche Verbesserung; Wissensmanagement; Messung und Berichterstattung; organisatorisches Veränderungsmanagement; Portfoliomanagement; Projektmanagement; Beziehungsmanagement; Risikomanagement; Strategiemanagement; Lieferantenmanagement sowie Personal- und Talentmanagement.

Diese Fähigkeiten unterstützen das Management der Organisation. Zum Beispiel liefert Messung und Berichterstattung zuverlässige Informationen für Verbesserungsentscheidungen. Kontinuierliche Verbesserung hilft, Practices und Services auf veränderte Bedürfnisse auszurichten.

Produkt- und Service-Management-Practices in Version 5

Die 22 Practices sind Verfügbarkeitsmanagement; Geschäftsanalyse; Kapazitäts- und Leistungsmanagement; Change Enablement; Deployment Management; Incident Management; Informationssicherheitsmanagement; Infrastruktur- und Plattformmanagement; IT-Asset-Management; Monitoring und Event Management; Problem Management; Release Management; Servicekatalogmanagement; Servicekonfigurationsmanagement; Servicekontinuitätsmanagement; Service Design; Service Desk; Servicefinanzmanagement; Service Level Management; Service Request Management; Servicevalidierung und -tests sowie Softwareentwicklung und -management.

Fähigkeiten mit einem Wertstrom verbinden

Eine Laptopanfrage greift auf Service Request Management zurück, um die vereinbarte Aktion zu bearbeiten, auf IT-Asset-Management, um das Gerät zu verfolgen, auf Deployment Management, um Software zu installieren, und auf den Service Desk, um den Anwender zu kontaktieren. Eine Aktivität der Wertschöpfungskette kann all diese Practices brauchen. Der Service Desk kann außerdem zu mehreren Aktivitäten beitragen, indem er Nachfrage entgegennimmt, Anwender informiert und Feedback sammelt.

Mache nicht standardmäßig aus jeder Practice ein eigenes Team. Organisationen übernehmen und passen an, was sie brauchen, bündeln Ressourcen, wo es nützlich ist, und bauen Fähigkeiten schrittweise auf. Eine kleine Organisation kann sich für mehrere Practices auf dieselben Personen stützen und dabei den jeweiligen Zweck klarhalten.

Practice-Leitfäden als Ausgangspunkt nutzen

Offizielle Practice-Leitfäden beschreiben die Practices. Die Leitfäden von ITIL 4 behandeln Zweck, zentrale Begriffe, Umfang, Erfolgsfaktoren und die vier Dimensionen, einschließlich der beitragenden Prozesse und Wertströme. Sie bieten eine gemeinsame Sprache und einen Ausgangspunkt zur Anpassung. Wer „Dort beginnen, wo man steht“ und „Auf Einfachheit und Praktikabilität achten“ folgt, passt diese Empfehlungen an die tatsächliche Arbeit der Organisation an.

Wenn Anwender einen Provider kontaktieren, können mehrere Practices beitragen. Ihr Zweck hilft, Kontakt, reguläre Anfragen, Wiederherstellung, Untersuchung und Vereinbarungen zur Servicequalität zu unterscheiden.

Kontakt, Wiederherstellung und Ursachen

Der Service Desk kann Telefon, Chat, ein Portal, E-Mail oder persönlichen Kontakt vor Ort nutzen. Er ist die Kontaktstelle, während Incident Management die Fähigkeit zur Wiederherstellung bereitstellt. Andere technische Teams und Lieferanten können einen großen Teil dieser Wiederherstellung übernehmen.

Incident Management kann den Service durch einen Workaround wiederherstellen, bevor die Ursache bekannt ist. Problem Management kann nach der Wiederherstellung weiterarbeiten oder eine Schwachstelle untersuchen, bevor ein Incident auftritt. Wiederholte Incidents sind nützliche Belege, aber eine Wiederholung ist keine Voraussetzung dafür, dass ein Problem existiert.

Eine vordefinierte Kennwortzurücksetzung über ein Portal ist eine Serviceanfrage. Wenn ein Anwender unerwartet nicht auf einen funktionierenden Service zugreifen kann, kann das ein Incident sein. Achte auf den Bedarf und die vereinbarte Serviceaktion, nicht nur auf das Wort „Kennwort“.

Qualität vereinbaren und Beziehungen pflegen

Service Level Management legt klare, an den Geschäftsanforderungen orientierte Serviceziele fest und beurteilt, überwacht und steuert die Bereitstellung anhand dieser Ziele. Ein Service Level Agreement (SLA) dokumentiert die erforderlichen Services und das erwartete Service Level, die Provider und Kunde vereinbart haben. Ein Reaktionszeitziel ist nützlich, wenn es widerspiegelt, was die Arbeit des Kunden braucht.

Beziehungsmanagement entwickelt Beziehungen zu Stakeholdern auf strategischer und taktischer Ebene. Es hilft, Bedürfnisse und geschäftliche Auswirkungen über einen einzelnen Kontakt zu einer Störung hinaus zu verstehen. Ein Gespräch mit einem Abteilungsleiter über die Folgen eines schlechten Services kann künftige Prioritäten beeinflussen.

Monitoring und Event Management beobachtet Services und Komponenten und erfasst und berichtet ausgewählte bedeutsame Zustandsänderungen. Ein Schwellenwertalarm liefert Informationen, die eine Untersuchung oder Maßnahme auslösen können; die Practice ersetzt nicht die Arbeit zur Wiederherstellung eines ausgefallenen Services.

Eine Verlangsamung der Gehaltsabrechnung verfolgen

Am Zahltag meldet das Monitoring, dass die Reaktionszeit der Gehaltsabrechnung ihren Schwellenwert überschritten hat. Der Service Desk erhält Anrufe von Anwendern. Incident Management ergänzt Serverkapazität, um die normale Geschwindigkeit wiederherzustellen. Problem Management identifiziert später einen fehlerhaften Datenbankindex als Ursache.

Service Level Management berichtet dem Kunden über die Verfehlung des Reaktionszeitziels. Beziehungsmanagement bespricht die geschäftlichen Auswirkungen mit dem Finanzleiter. Jeder Beitrag hat einen anderen Zweck, auch wenn dieselbe Führungskraft an mehreren Gesprächen teilnimmt.

Wenn Anwender nach der Ergänzung von Kapazität wieder arbeiten können, kann der Incident enden, während das Problem offen bleibt. Diese Unterscheidung sichtbar zu halten verhindert, dass eine erfolgreiche Wiederherstellung ungelöste Ursachen verdeckt, die sich auf den nächsten Zahltag auswirken könnten.

Eine neue Servicefunktion braucht mehr als eine Installation. Risiken müssen bewertet werden, Anwender brauchen zum richtigen Zeitpunkt Zugang und die Organisation braucht zuverlässige Informationen über Komponenten, Kosten und Lieferanten. Diese Beiträge stammen aus unterschiedlichen Practices.

Erfolgreiche Changes einführen

Change Enablement zielt darauf ab, erfolgreiche Produkt- und Service-Changes durch Risikobewertung, Genehmigung und Verwaltung des Change-Kalenders zu maximieren. Ein Change fügt etwas hinzu, ändert oder entfernt etwas, das Services direkt oder indirekt beeinflussen könnte. Das ursprüngliche ITIL 4 Foundation-Buch nannte diese Practice Change Control.

Das Ziel sind erfolgreiche Changes, nicht die größtmögliche Anzahl von Genehmigungssitzungen. Risikoarme Standard-Changes können vorab genehmigt werden. Die zuständige Autorität und die Bewertung passen zum Risiko und Kontext des Changes.

Eine Funktion kann ausgerollt werden, während sie abgeschaltet ist. Ein späteres Release macht sie Anwendern verfügbar. Diese Unterscheidung erklärt, warum „erfolgreich installiert“ nicht immer „Anwender können es nutzen“ bedeutet.

Komponenten und ihren Wert kennen

Servicekonfigurationsmanagement stellt genaue, zuverlässige Informationen über Services und die sie unterstützenden Konfigurationselemente bereit, wo und wann sie gebraucht werden. Ein Konfigurationselement (CI) ist eine Komponente, die verwaltet werden muss, um einen IT-Service bereitzustellen. Konfigurationsinformationen umfassen Einstellungen und Beziehungen, etwa welche Anwendung von welcher Datenbank abhängt.

IT-Asset-Management plant und verwaltet den vollständigen Lebenszyklus finanziell wertvoller IT-Komponenten. Es unterstützt die Wertschöpfung, die Kontrolle von Kosten und Risiken, Kauf, Wiederverwendung, Außerbetriebnahme sowie die Erfüllung regulatorischer oder vertraglicher Anforderungen. Ein IT-Asset kann ein Laptop oder eine Softwarelizenz sein.

Ein Laptop kann sowohl ein Asset als auch ein CI sein. Die Asset-Sicht fragt nach Wert und Lebenszyklus; die Konfigurationssicht fragt, wie er zur Servicebereitstellung eingerichtet und verbunden ist. Einen Datensatz genau zu führen, macht die andere Sicht nicht überflüssig.

Informationen und Lieferantenleistung schützen

Informationssicherheitsmanagement schützt die Informationen, die für die Geschäftstätigkeit gebraucht werden. Vertraulichkeit beschränkt den Zugang auf berechtigte Personen; Integrität hält Informationen richtig und vollständig; Verfügbarkeit hält sie bei Bedarf nutzbar.

Lieferantenmanagement steuert Lieferanten und ihre Leistung, damit sie die reibungslose Bereitstellung hochwertiger Produkte und Services unterstützen. Kontinuierliche Verbesserung richtet Produkte, Services, Practices und andere Managementelemente durch fortlaufende Verbesserung auf veränderte Geschäftsanforderungen aus.

Einen Fernzugriffsclient ausrollen

Für 1.500 Beschäftigte bewertet Change Enablement das Risiko und plant den Rollout zeitlich ein. Deployment Management installiert den Client auf Testgeräten und dann auf den Laptops der Beschäftigten. Release Management ermöglicht die Nutzung in mehreren Wellen.

Servicekonfigurationsmanagement erfasst Geräteversionen und Beziehungen. IT-Asset-Management verfolgt Lizenzen. Informationssicherheitsmanagement prüft Verschlüsselungseinstellungen und Lieferantenmanagement hält den Anbieter zur Erfüllung seines Supportvertrags an. Kontinuierliche Verbesserung kann die Ergebnisse des Rollouts nutzen, um den nächsten Change zu verbessern. Der Wertstrom gelingt durch diese kombinierten Fähigkeiten; keine einzelne Practice liefert jeden Beitrag.

Kontinuierliche Verbesserung ist wiederkehrende Arbeit auf jeder Ebene, damit die Leistung weiterhin die Erwartungen der Stakeholder erfüllt. Sie ist eine Komponente des Wertsystems, eine Aktivität der Wertschöpfungskette von ITIL 4 namens Verbessern und eine Practice. Alle tragen gemeinsam Verantwortung dafür, Verbesserungen zu erkennen und zu unterstützen.

Das Modell zur kontinuierlichen Verbesserung bietet sieben verbundene Schritte. Es kann einen Change in einem kleinen Team, einen einzelnen Wertstrom oder eine organisationsweite Transformation leiten. Ein großer Change braucht gewöhnlich mehrere kleinere Iterationen.

Was bei jedem Schritt zu tun ist

Version 5 behält sieben Schritte bei, nennt Schritt 6 aber „Sind wir auf dem richtigen Weg?“ und Schritt 7 „Wie halten wir die Verbesserungen relevant?“ Die Formulierung betont den laufenden Fortschritt und die anhaltende Nützlichkeit.

Eine Verbesserung des Service Desks verfolgen

Vision: Beschäftigte sollen ohne lange Unterbrechungen arbeiten können. Aktueller Zustand: Der Service Desk löst 1.392 von 2.400 monatlichen Kontakten beim ersten Kontakt. Die Anzahl der Lösungen geteilt durch die Anzahl der Kontakte ergibt eine Baseline von 58 %.

Gewünschter Zustand: innerhalb von sechs Monaten 70 % erreichen. Beim Volumen der Baseline würde das bedeuten, 1.680 Kontakte beim ersten Kontakt zu lösen. Das Ziel ist der Anteil, sodass sich die erforderliche Anzahl ändert, wenn sich das Volumen ändert.

Plan: eine Wissensdatenbank für die 20 häufigsten Lösungen in monatlichen Iterationen aufbauen. Handeln: die Artikel veröffentlichen und Mitarbeiter in ihrer Nutzung schulen.

Prüfen: Nach sechs Monaten werden 1.620 von 2.500 Kontakten beim ersten Kontakt gelöst. Das Ergebnis beträgt 64,8 %: über 58 %, unter 70 %. Der Service Desk hat sich verbessert, aber das Ziel nicht erreicht. Beim neuen Volumen wären für 70 % insgesamt 1.750 Lösungen beim ersten Kontakt nötig.

Fortfahren: die Ergebnisse teilen, die Artikel aktuell halten und die verbleibende Lücke untersuchen. Feedback kann das Team zu Schritt 4 zurückführen, um den Plan zu ändern, oder zu Schritt 3, wenn das Ziel überarbeitet werden muss. Ein verfehltes Ziel liefert Informationen für die nächste Entscheidung.

Den Ausgangspunkt sichtbar halten

Wer die Baseline überspringt, verzichtet auf den Vergleich, der zur Beurteilung einer Veränderung nötig ist. Ein Ergebnis von 64,8 % zeigt hier Fortschritt, weil das Team vor dem Handeln 58 % gemessen hat. Auch mit „ein neues Werkzeug kaufen“ zu beginnen, greift vor: Dabei wird eine Lösung gewählt, bevor Ergebnis und Ziel vereinbart sind.

Die Grundprinzipien unterstützen die Schritte. „Wertorientierung“ leitet die Vision; „Dort beginnen, wo man steht“ leitet die Baseline; „Iterative Weiterentwicklung mit Feedback“ leitet Planung, Handeln und Prüfung. „Zusammenarbeit und Transparenz fördern“ bezieht Betroffene ein und macht den Fortschritt durchgehend sichtbar.

Eine Kennzahl ist ein Mess- oder Rechenwert, der für Management und Verbesserung überwacht oder berichtet wird. Eine Leistungskennzahl (KPI) ist eine wichtige Kennzahl, mit der der Fortschritt auf ein Ziel hin beurteilt wird. Ein kritischer Erfolgsfaktor (CSF) beschreibt etwas, das gegeben sein muss, um die angestrebten Ergebnisse zu erreichen.

Das Ziel mit Belegen verbinden

Beginne mit dem Ziel, identifiziere die zu seiner Erreichung nötigen CSFs und wähle dann für jeden zwei oder drei zuverlässige KPIs. Erfasse vor dem Handeln eine Baseline, lege für jede KPI Ziel und Termin fest und berichte die Ergebnisse an die Personen, die über das weitere Vorgehen entscheiden.

Für den CSF „Anwender können häufige Probleme lösen, ohne auf einen Mitarbeiter zu warten“ gehören der Anteil häufiger Anliegen, die über Self-Service gelöst werden, und der Anteil der über Self-Service abgeschlossenen Kennwortzurücksetzungen zu den nützlichen KPIs. Die Erstlösungsquote misst nicht dasselbe: Ein Mitarbeiter kann einen Kontakt lösen, daher zeigt sie nicht, ob Anwender selbstständig eine Lösung finden.

Eine Kennzahl wird durch ihre Verbindung zum Ziel zu einer KPI. Nicht jede verfügbare Anzahl verdient die gleiche Aufmerksamkeit. Messung und Berichterstattung, eine allgemeine Management Practice, liefert zuverlässige Daten zur Unterstützung dieser Entscheidungen.

Den richtigen Nenner wählen

Die beim ersten Kontakt gelösten Fälle des Service Desks stiegen von 1.392 auf 1.620, also um 228. Die Kontakte nahmen jedoch ebenfalls zu, von 2.400 auf 2.500. Die Anteile betragen:

Die Veränderung beträgt 6,8 Prozentpunkte. Die gemeinsame Angabe von Anzahl und Prozentwert trennt das Arbeitsaufkommen vom Anteil der erfolgreich beim ersten Kontakt bearbeiteten Fälle. Um beim neuen Volumen 70 % zu erreichen, sind 1.750 Lösungen nötig.

Verwende einen Prozentwert, wenn das Ziel einen Anteil betrifft. Anzahlen, Zeitdauern und Kosten sind ebenfalls sinnvolle Formen von KPIs, wenn das Ziel sie betrifft. Ein Ziel, eine Wartezeit zu verkürzen, braucht zum Beispiel ein Zeitmaß.

Ergebnisse und unbeabsichtigte Auswirkungen messen

Die „Anzahl veröffentlichter Wissensartikel“ misst einen Output. Der Anteil der beim ersten Kontakt gelösten Kontakte und die Anwenderzufriedenheit liegen näher an dem Ergebnis, das Menschen schätzen. 200 Artikel zu veröffentlichen, die niemand nutzt, würde eine Produktionsvorgabe erfüllen, ohne Anwendern zu helfen.

Kombiniere Ergebnis- oder Wertkennzahlen mit Kennzahlen für Geschwindigkeit und Kosten. Ein einzelnes Ziel kann Verhalten fördern, das die Zahl verbessert und gleichzeitig dem Service schadet. Werden Mitarbeiter nur anhand der Erstlösungsquote beurteilt, schließen sie Kontakte möglicherweise zu früh ab. Den Anteil der innerhalb von sieben Tagen wieder geöffneten Incidents zu verfolgen, hilft, diesen Effekt sichtbar zu machen.

Ideen und Verantwortlichkeiten sichtbar halten

Ein Register für kontinuierliche Verbesserung (CIR) ist ein strukturiertes Dokument oder eine Datenbank, die Verbesserungsideen bis zu ihrem Abschluss oder ihrer Ablehnung verfolgt. Einträge enthalten eine Beschreibung, einen Verantwortlichen, Priorität, erwarteten Nutzen und Status. Ein gemeinsames Register vermeidet doppelte Arbeit und hilft, mögliche Vorteile zu vergleichen, wenn entschieden wird, was zuerst getan wird.

Governance überwacht die Leistung anhand der Strategie. Führungskräfte sind für Verbesserungen an Practices und Wertströmen verantwortlich. Jedes Teammitglied kann eine Idee im Register einbringen. Die Zuweisung eines Verantwortlichen hält die Zuständigkeit klar und lässt gleichzeitig Ideen aus der gesamten Organisation zu.