ITIL 4 – Créer, fournir et prendre en charge – Créer, fournir et prendre en charge le flux de valeur des services

4. Flux de valeur qui créent, fournissent et soutiennent les services

Ce chapitre fournit des informations sur la manière de :

• Documenter une chaîne de valeur pour comprendre comment le flux de travail circule dans l'organisation
• Comprendre la chaîne de valeur du prototype pour créer un nouveau service
• Comprendre la chaîne de valeur du prototype prenant en charge un service sur le terrain

Ce chapitre aidera les praticiens à comprendre :

• Le rôle de la chaîne de valeur dans le système de valeur du service (SVS)
• Classification des flux de valeur
• Comment décrire les étapes d'une chaîne de valeur
• Comment appliquer la théorie commune de la modélisation mathématique pour simplifier les flux de valeur
• Éléments à prendre en compte lors de la conception d'une chaîne de valeur

Les praticiens doivent comprendre que les flux de valeur sont simples et faciles à réaliser, mais pas nécessairement des présentations de travail simplifiées. Différents types de travail suivent des itinéraires différents et il existe donc de nombreux flux de valeur différents. Ils peuvent faire référence à des modèles d'activité conçus ou idéaux, ou exprimer des modèles d'activité réels et observables. Les mêmes ressources, telles que des individus, des outils, des fournisseurs ou des processus, peuvent être présentes dans différentes parties de la chaîne de valeur ; par exemple, un spécialiste des opérations peut participer à l'engagement des utilisateurs, prendre en charge les enquêtes et déployer des correctifs pour les services de récupération.

4.1 Flux de valeur des services ITIL

La chaîne de valeur ITIL comprend six activités de prototypage : participation, planification, amélioration, conception et transfert, engagement, et livraison et support. Une façon utile de réfléchir à une chaîne de valeur consiste à visualiser le parcours à travers les activités de la chaîne de valeur d'un service pour un scénario ou un type de besoin spécifique. Par exemple:

• Différents types d'événements peuvent nécessiter différentes chaînes de valeur pour décrire le travail requis dans chaque cas, par exemple :
  • Événements matériels de l'utilisateur final
  • événement principal
  • Incident de cybersécurité. 
• Différents types de besoins des clients peuvent nécessiter différentes flux de valeur, tels que :
  • Le besoin d'une nouvelle fonctionnalité de produit ou de service qui augmente l'efficacité des opérations commerciales
  • Une demande pour qu’un membre de l’équipe accède à un produit ou un service
  • Une demande de nouvelles capacités d’infrastructure pour préserver le fonctionnement normal d’un produit ou d’un service.

4.1.1 Structure de la chaîne de valeur des services ITIL

Définition : Chaîne de valeur des services ITIL Un modèle opérationnel pour les prestataires de services qui couvre toutes les activités clés nécessaires pour gérer efficacement les produits et services.

La chaîne de valeur des services ITIL se compose de 6 activités prototypes de chaîne de valeur. Ces séries d'activités sont appelées : flux de valeur des services ITIL, ou plus simplement : flux de valeur. Une chaîne de valeur peut :

• Mentionner une, certaines ou toutes les activités de la chaîne de valeur, selon le contenu
• Activités de chaîne de valeur en double, dépendantes des travaux en cours

Une chaîne de valeur se compose d'une ou plusieurs étapes, et chaque étape consiste en une ou plusieurs activités pour atteindre un objectif spécifique. Ces activités peuvent être en série ou parallèles, et elles peuvent être connectées à d’autres activités ou indépendantes les unes des autres. Une activité elle-même peut contenir une ou plusieurs tâches, qui peuvent également être connectées ou indépendantes.

Définition : flux de valeur La série d'étapes suivies par une organisation pour créer et fournir des produits et services aux consommateurs

Avec un modèle de flux de valeur, les organisations de services peuvent organiser les unités de travail en processus, qui peuvent varier en fonction du contexte et du niveau de granularité. Par exemple, dans une chaîne de valeur où les consommateurs créent spontanément des demandes de service :

• Au niveau de la chaîne de valeur, cette unité de travail peut être définie comme un besoin client à satisfaire, ce qui peut modifier le flux d'activités dans le portefeuille de services au sein de la chaîne de valeur.
• Au niveau des étapes, des unités de travail définissables doivent être estimées en tant qu'exigences, ce qui peut modifier la conception des définitions de rôles dans le package de conception de services lors de la mise en œuvre de la chaîne de valeur.

La figure 4.1 montre la relation entre les activités de la chaîne de valeur, les flux de valeur, les étapes au sein de la chaîne de valeur, les activités au sein des étapes et les tâches au sein des activités.

Les flux de valeur sont initiés par des exigences ; par exemple :

• Événements générés par les outils de surveillance
• Demandes soumises par les utilisateurs.

Figure 4.1 Hiérarchie des activités de la chaîne de valeur

Une chaîne de valeur se termine par la création ou la restauration de la valeur d'un produit ou d'un service fonctionnel. La chaîne de valeur nécessite les informations de contenu suivantes :

• Entrée d'une ou plusieurs parties prenantes (organisations externes qui effectuent des étapes ou des actions), telles que les noms de serveurs ou les données GPS envoyées via l'appareil mobile de l'utilisateur ;
• Autres flux de valeur​, par exemple : une chaîne de valeur doit utiliser des informations d'identification ou d'autres informations pour l'intégration de nouveaux employés, qui proviennent de la chaîne de valeur qui embauche (ou signe) le nouvel employé.

Les flux de valeur utilisent les ressources des prestataires de services et des consommateurs de services pour générer les résultats requis et fonctionnent au sein des systèmes de gestion, des systèmes de gouvernance, des facteurs externes, des contraintes et des principes.

La chaîne de valeur produira des résultats qui seront utilisés pour créer les résultats souhaités. Ce résultat peut inclure des informations et des commentaires partagés avec les parties prenantes et aider à l'exécution d'activités de gestion ou d'activités de gouvernance. Dans certains cas, ces résultats peuvent également servir de déclencheurs pour d’autres flux de valeur au sein ou à l’extérieur de l’organisation.

4.1.2 Flux de valeur et organisation

ITIL 4 n'assimile pas les organisations aux entités corporatives. Une organisation peut être une personne (comme un programmeur ou un consultant indépendant), une équipe (comme une équipe de développement ou de support en tant qu'unité commerciale), une entreprise ou même un écosystème d'entreprises travaillant ensemble.

Les flux de valeur concernent fondamentalement les organisations. Par conséquent, des flux de valeur peuvent exister à chaque niveau de granularité, et il peut s’agir d’une seule personne, d’une équipe, d’une unité commerciale, etc. Cependant, il est important de se rappeler que la chaîne de valeur est définie par le contexte du système en cours de construction et que son objectif est de créer de la valeur pour l'organisation, ses clients et les autres parties prenantes. Une grande entreprise peut comprendre plusieurs organisations différentes qui disposent d'un certain degré d'autonomie en matière de gestion, et chacune d'entre elles peut être considérée comme une chaîne de valeur et une chaîne de valeur du système de valeur de service (SVS) avec sa propre valeur. Cependant, il est peu probable qu'il soit autosuffisant. Un système de valeur de service (SVS) doit être établi au niveau de l'équipe.

Les objectifs et attentes généraux d'un produit ou d'un service doivent être décrits du début à la fin, c'est-à-dire du besoin à la valeur, plutôt que de simplement décrire l'utilisation de chaque équipe dans un ensemble d'activités différent ou non coordonné. Par conséquent, les flux de valeur représenteront le travail de différentes équipes, auront un impact sur différentes parties prenantes, utiliseront différents processus, outils et personnes, et parfois même différents fournisseurs.

La chaîne de valeur des services ITIL doit être visualisée et indiquer clairement les points de contact où les utilisateurs interagissent avec les produits, les services ou les professionnels de la gestion des services informatiques. Un avantage clé des techniques de flux de valeur ITIL est la capacité non seulement à identifier l'implication de plusieurs parties prenantes, mais également à identifier les points de défaillance potentiels et à lier clairement la valeur aux exigences.

Information clé La principale différence entre les flux de valeur et les processus réside dans leur orientation et la manière dont ils sont utilisés. Les activités interdépendantes qui transforment de nombreux intrants en extrants peuvent être considérées comme des processus. La chaîne de valeur se concentre sur le flux d'activités depuis un besoin ou une opportunité jusqu'à la réalisation de la valeur client. Des taxonomies de processus, des outils ou des techniques de gestion de processus peuvent être utilisés pour les flux de valeur. Par conséquent, de nombreux processus ne constituent pas des flux de valeur.

Chaque étape de la chaîne de valeur peut être redéfinie comme un processus ou une chaîne de valeur. Ce dernier cas est typique des grandes entreprises et des écosystèmes impliquant plusieurs entreprises.

Exemple Les passagers voyageant en train peuvent interagir avec plusieurs prestataires de services, en fonction du pays et de l'itinéraire choisi. Certains de ces prestataires de services sont des compagnies ferroviaires qui transportent des personnes. Les autres prestataires de services incluent la gestion des gares, la billetterie, la sécurité, la répartition et la navigation ferroviaire. Le voyage ferroviaire est un écosystème complexe dans lequel de nombreuses organisations collaborent et collaborent pour créer un parcours utilisateur fluide et confortable. Chaque organisation doit gérer son propre SVS, qui contient plusieurs flux de valeur. Dans le même temps, ces organisations contribuent à une collaboration sur la chaîne de valeur qui permet et soutient le voyage en train. Certaines étapes de la chaîne de valeur sont effectivement réalisées par les chaînes de valeur des organisations participantes.

Les flux de valeur de haut niveau pour l'ajout de nouvelles fonctionnalités aux services informatiques peuvent impliquer des fournisseurs tiers, des équipes de développement de logiciels internes, des équipes d'ingénierie de fiabilité des sites, d'autres équipes informatiques et des équipes d'utilisateurs. Les étapes réalisées par un fournisseur externe sont susceptibles d'être gérées comme la propre chaîne de valeur du fournisseur. Les étapes effectuées au sein d'une organisation sont formalisées sous forme de gestion de processus des actions ou activités impliquées dans ces processus.

La mise en cascade d'une flux de valeur vers des flux de valeur ou des processus de niveau inférieur permet aux organisations de :

• Se concentrer sur la valeur des flux de valeur de niveau supérieur, en intégrant les flux de valeur et les processus des parties participantes
• Améliorer de manière itérative, en s'appuyant sur les commentaires d'autres organisations ou équipes dans la chaîne de valeur 
• Collaborez et augmentez la visibilité sur les flux de travail au sein des organisations et des équipes
• Pensez et travaillez de manière holistique en comprenant comment l’organisation ou l’écosystème au sens large fonctionne et en profite, ainsi que ce que font les parties impliquées.

4.1.3 Considérations relatives à la chaîne de valeur

4.1.3.1 Choisir la bonne perspective

Les flux de valeur peuvent être documentés sous deux angles. D'une part, il peut être conçu pour refléter les souhaits du prestataire de services, d'autre part, il enregistre l'exécution des travaux de recherche. Une fois documentée, la conception peut être comparée au comportement observé.

Les différences entre la conception et le comportement observé peuvent déclencher des améliorations. Ceux-ci peuvent inclure :

• Mettre à jour la documentation sur la chaîne de valeur pour refléter les modèles de travail réels
• Optimisez les flux de travail en réduisant le temps de changement. Transformez la demande en valeur et automatisez le travail reproductible.

4.1.3.2 Point de départ et point d'arrivée

Une chaîne de valeur commence toujours par une exigence et se termine par la création ou la réalisation de valeur pour une ou plusieurs parties prenantes. Par conséquent, il est conseillé de conserver une voix externe lors de la documentation des flux de valeur, par exemple en :

• Jalons et échéanciers qui reflètent le plan d’affaires
• Capacité à utiliser un langage pertinent pour le public
• Créez des résultats et de la valeur du point de vue du client ou de l'utilisateur.

4.1.3.3 Flexibilité

Les flux de valeur réutilisent les activités de la chaîne de valeur en fonction du contexte et de l'environnement dans lesquels le travail est effectué. Les flux de valeur peuvent être personnalisés de manière flexible en fonction des besoins de l’organisation. Par exemple : les organisations peuvent ajouter une étape pendant le travail, similaire à une approche en cascade, ou créer des boucles itératives entre les activités de la chaîne de valeur.

4.1.3.4 Granularité

La chaîne de valeur peut refléter dans une certaine mesure la granularité du travail. Par exemple, une chaîne de valeur utilisant des activités logicielles agiles peut présenter plusieurs itérations de travail, reflétant la nature exploratoire de l'approche. Alternativement, une chaîne de valeur peut incarner une perspective de niveau supérieur qui permet de représenter le travail comme une étape. Quelle que soit la manière dont le travail est représenté, il est essentiel que la granularité reste cohérente tout au long de la chaîne de valeur.

4.1.3.5 Étapes d'identification

Quelles étapes doivent être utilisées pour la chaîne de valeur, quelles activités ces étapes doivent-elles inclure et les points suivants doivent être pris en compte lors de la prise de décision :

• Niveau de détail de la chaîne de valeur. Les organisations doivent décider si les détails de toutes les opérations doivent être affichés ou simplement un aperçu du travail.
• L'impact des transferts entre individus ou équipes sur la chaîne de valeur. Il est souvent préférable de présenter les activités réalisées par différentes équipes sous forme d’étapes distinctes. Cela permet de comprendre quelles tâches dans la file d'attente connaissent des retards.
• Activités multiples dans une chaîne de valeur qui ont un impact sur la chaîne de valeur.

Comprend plusieurs activités de la chaîne de valeur

Si une étape comprend à la fois des activités d’action et de planification, il est plus logique de la diviser en deux étapes distinctes. Par exemple : l'étape « Déterminer les besoins du client » peut être divisée en :

• Définir les exigences avec les clients (les contributions de pratiques telles que le centre de services et la gestion des relations peuvent être utilisées pour cartographier les activités habilitantes de la chaîne de valeur)
• Évaluer les besoins des clients (les contributions de pratiques telles que l'analyse commerciale, la gestion des risques, etc. peuvent être utilisées, mappées aux activités planifiées dans la chaîne de valeur).

De même, l'étape « Implémenter le correctif via le site Web du fournisseur » peut être divisée en :

• Téléchargez le correctif depuis le site Web (vous pouvez utiliser le contenu de pratiques telles que le développement et la gestion de logiciels, la gestion des fournisseurs, etc., cartographiées pour acquérir/créer des activités dans la chaîne de valeur)
• Déployez ce correctif (les contributions de pratiques telles que la gestion du changement, la gestion du déploiement, etc. peuvent être utilisées, mappées aux activités de conception et de transformation dans la chaîne de valeur).

Si plusieurs étapes sont réalisées par le même groupe de personnes ou le même ensemble de ressources, il est préférable de les décrire comme des étapes distinctes dans les activités de la chaîne de valeur afin que le résultat des étapes combinées puisse être mieux décrit. Cela permet également d'éviter l'impact des files d'attente entre chaque étape sur votre travail.

4.1.3.6 Séquence des étapes

Même si une chaîne de valeur commence généralement par un engagement, d’autres activités peuvent également servir de premières étapes. Par exemple, si un ingénieur découvre un incident grâce à un outil de surveillance (exigence), la première étape peut consister à lancer une enquête (livraison et support), auquel cas il est peu probable qu'il contacte directement le client concerné (action).

4.1.3.7 Cartographie de la chaîne de valeur des services

Les étapes de la chaîne de valeur peuvent être décrites en cartographiant les activités de la chaîne de valeur. En fait, les activités de la chaîne de valeur sont également décrites en cartographiant les activités ou tâches de base. Par exemple:

• L'étape d'évaluation des besoins du client peut être mappée à l'activité de planification dans la chaîne de valeur, mais elle peut également être mappée à une activité ou une tâche dans la chaîne de valeur appelée « affiner les exigences avec le client » qui est l'activité motrice de la chaîne de valeur. .
• L'étape de téléchargement d'un correctif depuis le site Web du fournisseur peut être mappée à l'activité Get/Build dans la chaîne de valeur, mais il existe également une activité ou une tâche appelée « Mettre à jour la solution de contournement » qui peut être mappée à l'activité d'amélioration dans la chaîne de valeur.

4.1.3.8 Mise en correspondance avec la pratique

En fonction du niveau de granularité, les étapes, les activités ou les tâches d'une chaîne de valeur peuvent être mappées à des processus ou des procédures en pratique. Par exemple, les étapes de développement et de déploiement du code peuvent être mappées aux activités et tâches suivantes :

• Programme pour effectuer des tests automatisés
• Le processus d’exécution de tests manuels

4.1.4 Flux de valeur du service de conception

Les praticiens sont encouragés à utiliser les méthodes suivantes ou à essayer d’autres méthodes pour garantir que les besoins organisationnels sont satisfaits.

1. Définir les cas d'utilisation ou les scénarios de la chaîne de valeur à travers les éléments suivants :

• Exigences (de préférence en termes non techniques)
• Des déclencheurs qui créent de la demande
• La chaîne de valeur crée des résultats
• Valeur dans le contexte d’une chaîne de valeur (car la valeur peut être créée ou restaurée).

2. Enregistrez les étapes requises dans toute la chaîne de valeur du service, de la demande à la valeur.

3. Commencez la cartographie de la chaîne de valeur des services à partir de l'étape 2.

4. Si nécessaire, divisez les étapes en activités ou en tâches.

5. Identifier les pratiques pertinentes ou les ressources connexes pour faciliter la réussite de chaque étape, activité ou tâche, notamment :

• Équipe d’exploitation ou de gestion ou individu
• Outils et techniques
• Informations et données (par exemple, enregistrements, formulaires)
• Tout partenaire ou fournisseur qui peut obtenir des résultats grâce à ses propres ressources.

Les cinq étapes ci-dessus doivent être réalisées de manière collaborative : par exemple, une série de réunions ou d'ateliers pourraient être organisés. La première tâche de la préparation de la documentation consiste à établir une compréhension large et fondamentale et à constituer une base de référence afin de répondre aux besoins et de créer de la valeur de manière ciblée.

Une fois que vous avez établi une base de référence, vous pouvez expérimenter ou optimiser davantage votre flux de valeur en :

• Créez des simulations simples pour tester les flux de travail
• Éliminer le travail qui ne contribue pas à des résultats, à des résultats ou à des avantages significatifs
• changer de poste à gauche
• Retarder les travaux pouvant entraîner des écarts de qualité, de coût ou de délai
• Introduire des mécanismes de rétroaction et des mécanismes de mise à niveau pour garantir une amélioration continue de la qualité des résultats et des avantages de la chaîne de valeur.
• Identifiez les opportunités d'amélioration de l'automatisation à partir des étapes, des activités ou des tâches pour accélérer les flux de travail
• Identifier et gérer les goulots d'étranglement ou les contraintes, qui peuvent nécessiter une refonte de la chaîne de valeur autour des contraintes
• Introduisez des déclencheurs d’examen et améliorez les flux de valeur si nécessaire. (Les avis peuvent être aléatoires, par exemple lors des commentaires des consommateurs, ou sur une base régulière.)

4.1.5 Étapes de description de la chaîne de valeur

Lorsque vous décrivez les étapes de la chaîne de valeur, vous devez identifier et documenter les éléments suivants :

• Le nom de l'étape  définit ce qu'est l'étape. Décidez si vous souhaitez utiliser un langage non technique pour décrire l'étape. Évitez les acronymes et le jargon afin que les évaluateurs de flux de valeur puissent facilement comprendre quels sont leurs objectifs ; par exemple :
  • Une meilleure étape de la chaîne de valeur serait la phrase « Enregistrer un incident utilisateur » plutôt que « Enregistrer un ticket d'incident à l'aide de INC_template ».
  • L'expression « enregistrer les exigences du client » est une meilleure expression que « remplir le formulaire TK421 avec les commentaires du client ».
• Entrez un déclencheur.  Un déclencheur provoque le démarrage d'une étape.
• Informations  décrit les informations requises pour l'étape. Les ressources doivent être obtenues auprès de parties prenantes externes ou d’autres organisations avant d’effectuer des activités de chaîne de valeur.
• Contributions à la pratique  Les outils, techniques, individus et autres ressources qui contribuent à la réussite des étapes de pratique par l'organisation.
• Quelles activités ou tâches  doivent être exécutées clairement en fonction des conditions de déclenchement et des exigences de résultats ? Quelles activités peuvent être parallélisées ? Quelles activités nécessitent des prérequis ? Combien de temps faut-il pour réaliser chaque activité ou tâche ?
• Quels principes doivent être suivis pour limiter  cette étape ? Ces principes sont définis par des prestataires ou des parties prenantes externes. Plus important encore, les organisations doivent explorer les contraintes de ressources auxquelles elles peuvent être confrontées.
• La raison pour laquelle l'  étape de sortie existe. Les étapes doivent atteindre des résultats et créer de la valeur pour les prestataires de services, les utilisateurs ou d’autres parties prenantes.
• Délai de livraison estimé ou cible  Le temps qu'il faut pour terminer une étape, y compris : le temps passé à attendre dans les files d'attente.

Le modèle suivant peut être utilisé comme référence initiale pour la description de la chaîne de valeur. Le premier modèle (Tableau 4.1) fournit un résumé de la chaîne de valeur, et le deuxième modèle (Tableau 4.2) fournit une structure par étapes décrivant la chaîne de valeur. Les praticiens sont encouragés à utiliser les modèles qu’ils jugent appropriés.

Tableau 4.1 Modèle de description du flux de valeur du service

nom de la chaîne de valeur

tout le monde

Description de la chaîne de valeur et de ses cas d'utilisation

besoin

déclenchement

résultat

valeur créée

Délai de livraison estimé ou délai de livraison cible

Tableau 4.2 Modèle de description des étapes de la chaîne de valeur

nom de la chaîne de valeur
numéro d'étape
nom de l'étape
activités de la chaîne de valeur	Activer, planifier, améliorer, concevoir et transformer, acquérir/construire, livrer et soutenir
entrer	Déclencheurs et messages
sortir	Déclencheurs et messages
résultat attendu
Estimation du délai de livraison ou objectif de délai de livraison
pratique de soutien
Nom de pratique	Décrire comment les pratiques contribuent à cette étape
Rôles et responsabilités
Un responsable
R exécuté
C consulté
on m'a dit

Remarque : les contributions pratiques doivent être décrites de manière globale, en évitant l'utilisation de jargon technique (dans la mesure du possible).

4.1.6 Cartographie de la chaîne de valeur

价值流映射起源于精益制造技术。这是一种从需求机会到价值实现的可视化工作流，其工作流可有计划地持续改进。在精益中，核心思想是最大化客户价值，同时将浪费最小化。简而言之，精益涉及以更少的资源为服务消费者创造更多价值。精益组织了解服务对消费者的价值，并将其关键流程集中在增加价值上。

我们的目标是通过不产生任何浪费的完美价值创造过程为服务消费者提供完美价值。为实现这个目标，精益思想通过将横跨技术、资产和部门的水平价值流，将管理的重点从优化单独的技术、资产和垂直部门转变为对消费者的产品和服务的流程进行优化。

价值流映射用于深入了解组织的工作流程，并在ITIL中发挥重要作用。它可用于识别价值流中的增值活动和非增值活动，同时可以发现优化和自动化的改进机会。价值流映射包括评估（例如：记录工作流程从需求机会到价值实现的真实状态）和计划（例如：规划对工作流程进行改进的变更）。

在许多组织中，关注单个流程会导致仅在较小的控制范围内优化流程中的步骤，例如：针对单个团队或部门，因而忽略了此局部优化对整个价值流的影响。局部优化会对价值流造成深入的瓶颈，并有可能使价值流的整体性能变差，而不是更好。

与传统业务系统相比，消除整个价值流中的浪费，而不是孤立在某些点，可以创建人力、空间、资金和时间所需更少、成本更低、缺陷更少的流程。

价值流图是优化整个价值链（不仅仅是局部优化）的绝佳工具。这种全局的观点与整体思考和工作的指导原则完全吻合。价值流映射通过以下方式帮助组织：

• 流程可视化不仅在单个流程级别（例如：生产中的装配、焊接等），可以使从机会到价值的整体流程更清晰
• 使每个价值流中的资源浪费更加明显
• 提供用于讨论价值流和流程的统一语言
• 使有关流程的决策变得清晰化，以便可以进行讨论（以防止在较低级别上做出随意的决策）
• 将精益的概念和技术联系在一起（以防止孤立地使用其中的一两个）
• 形成实施或改进点计划的基础。（通过帮助组织设计端到端工作流的操作方式，价值流图成为实施的蓝图。）
• 展示了信息流和物料流之间的联系。

价值流映射最初是在制造背景中开发的，但是，如ITIL中所述，它同样适用于服务的创建和交付。在服务价值体系中涉及服务价值流的任何方面都应包含在价值流图中。

在IT和服务管理中可以找到许多不同的价值流，它们因机会或需求的来源、所需的结果以及相关的价值的差异而有所不同。例如，在服务价值流映射中分别定义了，用于尽快恢复服务的流程活动，按照商定可用性级别交付服务的流程活动，以及处理服务变更的流程活动。

价值流映射的结果可用于多种情况，例如：编写业务案例、定义优先级、优化组织内的服务价值流和实践、查明现有实践中的瓶颈、和获得对影响组织问题的共识。但是，价值流图的最重要的作用是确定需要实现哪些改进点动作才能实现未来期望的结果。

有关更多信息，请参见ITIL®4：指导，计划和改进。

4.1.7 分析价值流时的关键指标

可以为任何工作流程和活动定义以下几个重要的指标。这些在表4.3中概述，并在图4.2中显示。

表格 4.3 工作流程指标

术语	描述
节点周期	完成离散工作单元，将输入转换为输出所需的时间。例如，花费五分钟填写一个新的事件表格，则周期就是五分钟。
等待时间	工作开始之前，离散工作单元在队列中等待的时间。例如，事故单在开始工作之前平均等待四个小时，则等待时间为四个小时。
交货时间	节点周期和等待时间的总和。交货时间表示完成离散工作单元（从其进入流程队列到流程结束）所需的总时间。
流程队列	等待流程处理的离散工作单元的数量。
在制品（WIP）	正在操作但尚未完成的离散工作单元的数量
吞吐量	工作进入或退出系统的速率

图 4.2处理时序

这些术语源自利特尔定律，有关更多信息，请参见运营管理或排队理论文献。利特尔定律可以简单地表示为：

进行中的工作= 吞吐量×交货时间    或   进行中的工作= 吞吐量×（周期时间+等待时间）

这种数学表示形式适用于简单的系统。但是，在复杂的环境中，同时发生多个活动、步骤或任务的情况下，应用此模型可能会更加困难。

系统的简单性取决于价值流、活动或任务的粒度。例如，新服务的价值流可能被简单地表示，并且处于高阶层次，如图4.3所示。

图4.3 价值流的简单表示

图4.4表示相同的价值流，它具有更高的准确性，并且在更精细的级别上具有明显更高的复杂性。显然，将前置时间，队列时间和等待时间进行建模更加困难。

图 4.4价值流的复杂表示

无论环境如何复杂，在设计价值流、步骤或行动时，利特尔定律都提出以下注意事项：

• 在执行各种步骤/操作/任务时，建议尽量减少各类资源间传递工作的次数，尤其是如果这些资源是独立的。传递就会产生队列，队列就会产生等待时间，从而增加了交货时间。减少潜在传递的数量通常是通过提高自动化程度，提高人员技能以增加他们可以完成任务的程度，或重组团队（通常称为分解竖井）来实现。
• 吞吐量通常不受服务提供者的控制，尤其是在外部事件和触发器的背景中。但是，使用统计建模功能（例如：泊松分布，高斯分布和帕累托分布）可以帮助评估活动模式。例如，超场无法预测在工作日的每个小时内购物者的确切人数，但是它可以使用统计模型来创建估计值。
• 在简单的系统中，等待时间可以表示为节点周期的函数。一个新的工作单元是周期时间乘以系统中已有的工作单位。例如，如果完成一个工作单元需要10分钟，当前正在执行一个单元，而正在等待三个单元，则：
  • 队列中进入系统的下一个工作单位将花费10分钟/单位×（1 + 3）单位= 40分钟
  • 下一个工作单元的交货时间将是40分钟等待时间+ 10分钟节点周期= 50分钟
• 根据粒度级别和工作性质，节点周期可以假定认为是固定的和可预测的。
• 为了创建更可预测的节点周期，可能有必要限制在制品数量。该技术是看板方法的一部分，在可预测吞吐量（工作量）的环境中效果很好。例如，一个团队可能一次将其在制品限制为三个请求，因此，如果在制品超过此限制，则延迟处理任何其他请求。

ITIL 故事: ITIL 服务价值

亨利:艾克苏汽车租赁采用服务价值流来绘制整个组织的工作流程。价值流展示了组织如何利用信息、工具、流程和其他结构化的工作方式来创建产品和服务。它们有助于我们通过任何给定场景或利益相关者的价值链活动形象化过程；例如，当我们为用户创建新功能或为客户服务台更新脚本时

索尔马兹: 我们利用ITIL的服务价值流帮助我们的员工、合作伙伴和供应商了解如何为客户创造价值。我们定期审查我们的价值流，以确定改进运营的方法。

雷尼: 我们将利用从试点中吸取的经验教训，通过价值流的使用，规范我们如何应对常见问题。我们已经确定了两个需要优先考虑的场景：新功能的开发，以及当客户体验到服务降级时我们向他们提供的支持级别。在我们的待办事项中还有许多其他场景；例如，自行车归还时服务缓慢。

4.2 价值流模型用于创建、交付和支持

本节探讨了几乎在所有组织中都可以找到的两种常见的价值流模型：

• 新服务的开发  组织经常发现有必要创建、修改或淘汰服务。这种价值流反映了创建新服务所需的常见工作模式，因此通常需要在整个组织中付出大量的努力和协调。
• 恢复现有服务  在现代，复杂的IT组织中，可以预料到故障，必须对其进行快速管理。此价值流与检测和解决故障时的典型活动有关，以及如何将这些活动用于改进服务。

这些价值流模型应适合每个组织的需求，因为背景、复杂性、粒度级别、步骤数、每个步骤的输入和输出，都将有所不同。

尽管这些模型使用第4.1节中的模板，但存在许多替代方法（例如：示例目标交货时间和示例角色）。这些阐明了如何使用表格，不应将其解释为规范性指导或标准的活动计算。

当以下各节内容涉及到实践贡献中的资源时，它们包括服务管理的四个维度的任何或全部：

• 组织和人员  技能，管理权限，资金，人员配备等
• 信息和技术  工具，数据库，数据对象，信息对象等
• 合作伙伴和供应商  为组织等提供产品和服务的供应商。
• 价值流和流程  流程，过程，模板等

4.2.1 开发新服务

这种价值流原型研究组织在创建新服务或修改现有服务时的常规活动。它与服务的性质无关，可以用来描述用于创建服务的价值流，这些服务可以提供给组织内部的客户，也可以提供给组织外部的客户。

4.2.1.1 设计考虑

设计此值流时，典型的注意事项包括：

• 确定如何管理工作。使用顺序瀑布阶段应对较大的增量，或以快速反馈的方式在短时间内更改规格（例如敏捷方法）应对较小的增量，或者两者混合？根据工作的管理方式，可能有必要创建单独的价值流，并在每个价值流中描述不同的项目管理方法。
• 建立正确的监督级别，以保持对业务成果而不是仅关注输出物。
• 建立正确的层级管理机构，以确保各个组织单位与组织的合作伙伴、供应商、客户、用户和其他主要利益相关者之间的活动得到有效协调。
• 融入所有必需的实践活动，用以创建新服务，实现端到端贯通，实现整体愿景的工作成果。
• 确保组织对客户的预期目标和期望有清晰的了解，并从头到尾跟踪每个目标和期望，以确保服务支持所需的结果。在将客户需求转换为服务成果（功能性或非功能性）时，组织应避免引入冲突或不一致。
• 了解客户从需求到价值的过程，并从客户的角度定义需求，而不是仅仅依靠内部视角或团队成员的先前经验。

4.2.1.2 从需求到价值的旅程

此价值流通过六个关键步骤描述了从需求出发的过程（如图4.5所示）：

1. 确认并记录服务要求（契动）
2. 决定是否投资新服务（计划）
3. 设计和架构新服务以满足客户要求（设计和转换）
4. 构建，配置或购买服务组件（获取/构建）
5. 部署服务组件以准备启动（设计和转换）
6. 为客户和用户发布新服务（交付和支持）。

图 4.5 开发新的服务

4.2.1.3 需求和价值

此价值流是由创建新服务的需求触发的。它可能来自：

• 服务消费者：赞助商、客户或用户。服务消费者可以在服务提供者外部，也可以是同一组织的成员，取决于具体环境。
• 服务消费者以外的外部利益干系人，例如供应商或监管机构。
• 提供者服务职能部门（例如：销售或市场营销）的一名工作人员，已经感觉到新的机会。SVS外部的机会可以转化为共同创造价值的需求。
• 该组织的治理主体的成员。

依据环境和工具，可以有多种方式识别需求。通常，需求是高级经理或其授权代表的要求。请注意，此值流的后续步骤将请求者视为发起价值流的个人或角色。它并不视为在服务请求管理中的角色。

在此阶段，重要的一点是，需求必须阐明服务的期望结果和期望值。一种有用的技术是使常用的Agile软件开发模板描述重要事情和用户故事，从而分解了以下需求：

作为<角色>，我想要<结果>，以便<价值>。

例如：

• 作为业务开发经理，我想跟踪我的销售流水线，以便专注于完成新交易。
• 作为基础架构工程师，我希望能够对报警通知进行分组，以便可以关联警报并消除重复项。

步骤1：确认并记录服务需求

对新产品或服务特性的任何请求均始于确认并记录需求。通常，业务案例方法用于收集和评估需求。重要的是要记住，目标是收集足够的信息以提交业务案例。

成功完成此步骤要求服务组织与请求者和其他利益相关者（例如，市场用户和样本用户）共同驱动，使用调查和民意测验来完成业务案例模板，获得包含有关需求、收益（定量和定性两者）、成本、风险的高阶信息。各种技术和服务管理团队，在综合考量开发、发布、运营和支持的成本的情况下，完成高阶估算并补充信息。

通常对此步骤有贡献的实践包括：

• 业务分析 根据业务案例，提供记录客户需求所需的技能、工具和其他资源，以进行深度适合的可行性评估。
• 组合管理 提供有关当前，退休和将来（计划的）服务的信息。
• 关系管理 提供技能、信息和其他资源，以管理请求者的期望，并与服务提供者建立融洽关系。
• 服务配置管理 提供有关当前运行的服务和服务组件的信息，以便在描述需求时提供内容。
• 服务级别管理 提供有关当前服务级别的信息，以在描述需求时提供内容。

步骤2：决定是否投资新服务

当请求细化并记录在业务案例中后，可能有必要澄清初始成本、收益和风险评估，以便服务组织可以计划工作。这将需要与各个内部团队进行更详细的讨论，并可能需要与客户和其他外部利益相关者进行持续的对话。完成后，管理团队可以评估业务案例，然后由管理团队决定是否授予批准。

通常对此步骤有贡献的实践包括：

• 业务分析 提供与各种专家团队合作所需的技能、工具和其他资源，针对业务案例中记录的客户需求，收集补充信息并进行可行性分析。
• 基础设施和平台管理 提供有关设计和开发新服务的基础结构组件的补充评估，以及对于正运行的应用程序影响分析的补充评估。还根据需要，为业务案例评估做出贡献。
• 组合管理 提供必要的资源，以允许服务所有者完成可行性评估，并决定是否对新服务的投资授权
• 问题管理 提供有关当前错误和解决方法的信息，这些错误和解决方法可能会影响新功能。
• 项目管理 提供管理和技术资源以完成业务案例评估。概述可用于完成表4.2中的价值流步骤模板。
• 风险管理 提供有关新功能可能在正面或负面带来企业风险的信息。
• 服务配置管理 提供有关当前运行服务和配置项的信息。
• 服务设计 提供有关设计新服务以满足功用、功效、品牌或其他指标的内部标准和政策的补充评估，并在必要时，为业务案例评估做出贡献。
• 服务台 提供有关新服务影响当前客户和用户支持渠道的补充评估，并在必要时，对业务案例评估做出贡献。
• 服务财务管理 提供工具和策略来计算新功能可能达到的ROI。
• 服务级别管理 提供有关当前服务级别以及新功能可能带来变更的信息。
• 软件开发和管理 提供有关设计和开发新服务的软件组件的补充评估，以及对运行的应用程序活动影响的补充评估。根据需要，为业务案例评估做出贡献。

步骤3：设计和架构师新服务以满足客户需求

注意：此示例假定管理团队已授权研发新功能所需的投资。在决定修改现有服务后，有必要审查并修改设计以适应新功能。例如：

• 将帐户审查系统与支付系统集成
• 增加业务、服务和技术的容量

在此阶段，还需要将请求的功能和更新的服务设计转换到软件和基础架构设计规范。根据软件和基础架构组件的开发方法，这可能会创建关于重要事情和用户故事的初始待办项。

通常对此步骤有贡献的实践包括：

• 架构管理  提供架构要求和约束。
• 可用性管理  提供了用以描述服务潜在需求，以及为满足该需求所需的技术、服务和业务能力所需的技能、工具和其他资源（并将这些需求记录在服务设计包中）。
• 业务分析  提供协调工作所需的技能、工具和其他资源，并确保输出被一致地记录在服务设计包中。
• 容量和性能管理  提供所需的技能，工具和其他资源，用以描述服务潜在需求，以及在满足预期性能水平所需的技术、服务和业务容量（并将这些内容记录在服务设计包中）。
• 信息安全管理  提供设计管控所需的技能、工具和其他资源，这些管控不仅可以确保信息的机密性、完整性和可用性，而且还可以确保对客户/用户的身份验证和不可抵赖性与组织的策略保持一致（并将这些管控内容记录在服务设计包中）。
• 基础设施和平台管理  提供创建和完善基础架构组件高阶设计所需的技能、工具和其他资源，以满足服务设计包中规定的功用和功效的标准要求。
• 项目管理  提供所需的技能、工具和其他资源，以确保项目启动、并具备足够的资源按照既定计划完成任务实现目标。
• 服务配置管理  提供有关当前运行的服务和配置项的信息。
• 服务连续性管理  提供设计管控所需的技能、工具和其他资源，这些管控将确保在发生灾难的情况下，可将新服务的可用性和性能都维持在可接受的水平（并将这些内容记录在服务设计包中） 。
• 服务设计  提供所需的技能、工具和其他资源，确保在设计新服务时考虑客户体验和用户体验（并将这些内容作为基准记录在服务设计包中）。
• 服务级别管理  提供所需的技能、工具和其他资源，以根据清晰的业务目标设置服务级别（并将这些内容记录在服务设计包中）。
• 软件开发和管理  提供所需的技能、工具和其他资源，以根据服务设计包中的规范，创建和提炼重要事情和用户故事列表。
• 供应商管理  协助与合作伙伴和供应商进行互动，并选择新供应商采购服务组件。

步骤4：构建、配置或购买服务组件

将设计包作为基准之后，就可以开始获取或构建服务组件的工作。服务组件通常是技术性的（例如：软件、服务器、存储或网络）。但是，根据服务的性质，可能还需要管理一些非技术服务组件（例如：新的团队结构、新的角色、关键的技能和胜任力、知识资料、培训文档和供应商合同）。

因此，至关重要的是从产品和服务的技术和非技术两方面，进行确认和配置，其中可能包括：

• 应用之间的技术集成
• 修改现有的后端和客户端应用程序
• 处理能力和基础设施的扩容
• 客户代理机构的培训文档的更新和沟通，以及帮助客户提供简单的脚本文档
• 推广新服务的发布说明文档的更新和交流
• 即将实现的产品和服务的变更的市场营销，而无需承诺特定功能
• 更新服务设计包，并在服务组件的获取或构建时，实现议定的变更。

通常对此步骤有贡献的实践包括：

• 基础设施和平台管理  提供所需的工程技能、工具和其他资源，确保更新基础架构，并将新系统和其他基础架构组件集成到现有服务中。
• 组合管理  提供所需的技能、工具和其他资源，在创建服务组件时，与服务组合保持更新和沟通。
• 项目管理  提供活动、问题和风险跟踪的跨团队协调，以及定期将状态更新到项目委员会。
• 发布管理  提供所需的技能，工具和其他资源，创建和沟通发布计划，并随着开发和部署活动而进行更新和维护。
• 风险管理  提供有关新的或修改的服务组件需要遵守的风险和策略信息。
• 服务配置管理  提供有关当前运行的服务和配置项的信息，以及在创建服务组件、更新服务配置项记录时，所需的技能、工具和其他资源。
• 服务验证和测试  提供所需的技术技能、工具和其他资源，用以记录测试用例、执行自动和手动测试，以及提供测试活动的反馈和报告。
• 软件开发和管理  提供所需的工程技能，工具和其他资源，用以创建新应用程序功能并将新系统和其他软件组件集成到现有服务。
• 供应商管理  协助与合作伙伴和供应商进行互动，并选择新的供应商来采购服务组件。

步骤5：部署服务组件以准备启动

服务组件完成构建后，便可以开始修改实时产品和服务的工作。鉴于服务组件的复杂性，组织可能需要使用不同的方法来修改实时产品和服务，例如：

• 软件组件经由CI / CD 流水线，即时打上特性标志并部署到生产环境中，该标志可防止用户意外访问新功能或有更改的功能。
• 服务器，存储或网络配置等基础结构组件需在上线之前完成开发和部署。
• 在获取/构建的同时编制内部文档，并且在发布之前完成分发。
• 综合考虑稳定的软件功能以及发布计划来编制营销文档。

在这个阶段，还可以考虑两项更重要的工作：

• 规划服务发布 完成大多数开发和配置工作后，就可以给发布计划定版。根据背景和需求，将另一个以发布计划为输出的步骤（例如，回到“计划价值链”活动），添加到价值流中可能更有效率。
• 创建客户宣传品 包括传单，电子邮件，海报，广告等，以构建新功能的认知，并宣传其优势。

通常有助于此步骤的做法包括：

• 变更支持 提供了提交，评估和批准变更请求，以及安排对各种服务组件的变更所需的技能，工具和其他资源。
• 部署管理 提供将各种服务组件（技术和非技术）部署到实际环境中所需的技能，工具和其他资源。
• 事件管理 同意提供前期支持（ELS）的期限，服务渠道和方法。
• 知识管理 提供更新支持用脚本所需的技能，工具和其他资源。
• 问题管理 记录新特性中存在的所有已知缺陷（技术债务）及解决方法。
• 项目管理 提供在活动、问题、 风险跟踪以及给项目委员会的定期状态更新等方面的跨团队协作机制。
• 发布管理 提供了发布（上线）计划定版所需的技能，工具和其他资源，并与组织中的其他组（例如，销售和营销部门）合作，将这些计划传达给用户和客户。
• 服务配置管理 提供有关当前运行的服务和配置项的信息，以及在构建服务组件时更新服务配置记录所需的技能，工具和其他资源。
• 服务台 确保在新特性，已知缺陷和解决方法方面对所有面向客户的支持角色进行了充分的培训。
• 供应商管理 在与合作伙伴及供应商的交互，以及选择提供服务组件的新供应商方面提供帮助。

步骤6：为客户和用户提供发布新服务

部署完所有服务组件后，组织即可将其提供给最终用户使用。本步骤实现在上一步中规划的发布。

服务组件的发布可能不仅限于技术过程。可能有必要细致协调技术与非技术工作，例如销售及市场营销。本步骤中，服务组件成为日常业务的一部分之前，会有一小段时间在ELS的支持下运转。ELS可以采用多种形式，并取决于组织及其客户的需求，可能的形式例如：

• 专门的ELS团队 这些团队来自整个价值流。团队专注于服务设计包中定义的关键指标，通常具有跳过正常的事件管理和变更管理实践以快速部署修复程序的自治权。该团队还与组织中的产品负责人紧密合作，以将优先任务添加到各个团队的待办事项列表中。
• 超级用户 超级用户通常来自客户和用户社区，活跃在社区论坛，社交媒体或其他渠道上，是产品推进者和拥护者。推进者接受了对新产品或更新产品的高水平培训及综述，以使他们能够为其他团队或用户提供支持；例如，业务用户或一线/服务台。
• 驻场，面对面支持人员 ELS也可以由IT人员在客户所在地或现场实施。通常称此类工作人员为内勤人员。

通常有助于此步骤的做法包括：

• 事件管理 提供ELS所需的技能，工具和资源，以更新支持脚本和知识文章，并实现从ELS阶段到日常业务支持阶段的过渡。
• 基础设施和平台管理 提供IT运营资源来运行相关的基础设施组件。
• 问题管理 记录新服务中存在的所有已知缺陷（技术债务）和解决方法。
• 项目管理 提供活动，问题和风险跟踪的跨团队协调，并为项目委员会提供定期状态更新报告。
• 关系管理 提供了在客户和用户联系组织，提出问题、需求或信息请求时，管理他们的期望所需要的技能，信息和其他资源。
• 发布管理 提供执行发布（上线）计划所需的技能，工具和其他资源，以确保成功完成发布。
• 服务配置管理 提供有关当前运行的服务和配置项的信息。
• 服务台 提供在发布新服务时捕获客户和用户需要（例如问题、需求或信息请求）所需的技能，工具和资源。
• 软件开发和管理 提供IT应用程序管理资源来运行相关软件组件。
• 供应商管理 为与合作伙伴和供应商的互动，以及选择新的供应商来采购服务组件等事宜提供协助。

服务组件发布后，客户和用户可以通过服务关系与他们进行互动，从而产生所需的结果并共同创造价值

发布组件后，可以扩展此值流以包括其他活动，例如：

• 与请求者互动，以识别新服务中的任何差距，或价值流活动中未发现的任何结果，成本和风险。
• 找出改进服务、价值流，以及积累实践的机会。

4.2.2 恢复现有服务

此价值流模型检查组织为支持现有服务而进行的典型活动。此场景与服务的性质无关，可用于描述各类为组织内外部消费者提供支持服务的价值流。

4.2.2.1 设计考虑因素

设计此值流时，典型的注意事项包括：

• 识别利益干系人，以及价值的创造或恢复对他们意味着什么，例如：
  • 对于用户而言，这意味着可以恢复使用产品和服务的能力
  • 对于组织的合规性人员而言，这可能意味着维护问题内容以及为恢复价值而采取的步骤的正确记录
  • 对于服务所有者，这可能意味着要对活动进行足够的文档化，以支撑趋势报告，问题调查和改进点机会识别。
• 采用由内而外的方法来了解事件的影响，并将这些评估与各种利益干系人的价值描述联系起来。
• 首先定义价值流的范围，然后定义一个涵盖范围内所有活动的单体价值流，以建立关于如何支持创建或恢复价值的端到端的、整体的构想。
• 强调合作伙伴和供应商执行的活动，这些活动可能会给成功创造或恢复价值引入风险或依赖关系。
• 了解应集成哪些（或如何集成）系统，并在多个活动中心之间共享数据。

4.2.2.2 需求和价值

此价值流由无法使用现有产品或服务的用户触发。8由于服务消费者无法从次优产品或服务中获取最大价值，生产力的损失导致产出价值下降。

当监视工具发出预警，提醒组织出现了或对用户产生影响的故障时，需求也可能源自服务提供者。在这种情况下，价值流可能会绕过步骤1或交换步骤1和2的顺序。换句话说，如果需要，服务提供者可以：

• 无须用户提醒，直接解决问题
• 尽早与用户联系，以通知他们正在发生的事件
• 事件解决后与用户联系。
• 恢复价值的需求推动了这一价值流。

4.2.2.3 从需求到价值的旅程

此价值流描述了七个关键步骤（如图4.6所示）：

图4.6实时服务的还原

• 确认并登记用户查询（参与）
• 调查查询，将其重新分类为事件，然后尝试修复它（交付和支持）
• 从专家团队处获取修复程序（获取/构建）
• 部署修复程序（设计和过渡）
• 验证事件是否已解决（交付和支持）
• 征集用户反馈（参与）
• 识别整体系统改进机会（改进）

该价值流在步骤2分支。如果成功解决此问题的初始尝试成功，那么价值就在无须后续活动的情况下恢复了。从步骤2到价值的虚线代表这种情况。

在步骤5之后，价值得到恢复，价值流就可以结束了，还可以进一步开展如步骤6和7所述的活动，请求并处理客户反馈。例如，组织通常要求从随机的客户样本中获取反馈。

步骤1：确认并登记用户查询

价值流中的第一步是与客户或用户进行互动，以识别和确认需求，并记录有关查询的详细信息。在此阶段，用户联系只是查询，9因为尚未对其进行分类并识别为事件。

通常有助于此步骤的做法包括：

• 服务目录管理 提供优化登记查询所需的信息，技能，工具和其他资源。
• 服务台 提供所需的技能，工具和其他资源，以允许客户或用户联系服务支持，并使客户支持专员能够与联系人产生共情，管理与客户或用户的沟通方式，获取及传递有关预期解决时间的信息

步骤2：调查查询，将其重新分类为事件，然后尝试将其修复

记录查询时，训练有素的支持专员或等效自动化程序（例如聊天机器人）可以将查询识别为事件并将其重新分类，从而启动脚本或标准过程以对记录进行相应分类。由于组织的过程和工具的不同，也可能会创建一个链接到初始查询的新事件记录

登记用户发起的事件后，通常会尝试快速识别其性质并应用已知的解决方案。

支持专员通常遵循允许他们尝试一个或多个修复程序的活动的脚本或工作流。如果这些修复程序之一将服务恢复到正常状态，则价值恢复，价值流就可以结束。如果所有这些修复程序均不起作用，则可以将问题上报至专家角色，以开展进一步调查。

通常有助于此步骤的做法包括：

• 事件管理 提供了登记事件所需的技能，工具和其他资源，以及有关可能需要多长时间解决的信息。
• 知识管理 提供查找技术信息和权变措施所需的技能，工具和其他资源，这些信息可以帮助调查，诊断和解决事件。
• 监控和事态管理 提供对监视工具和日志的访问，以帮助调查和诊断事件。
• 服务配置管理 通过提供相关配置项的信息来协助事件的调查和诊断。
• 服务台 提供使支持专员能够与客户或用户产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
• 服务级别管理 提供可用于评估事件影响和规划服务恢复的信息。

调查和诊断通常是一项高度技术性的活动。但是，还应注意非技术因素（例如环境或经济因素），以下是可能的示例：

• 网络中断的原因，是风暴影响了本地电缆或卫星连接。
• 流媒体服务中止服务的原因，是客户或用户的信用卡被银行拒付。

步骤3：从专家团队处获取修复程序

在此步骤中，由于最初尝试恢复服务失败，因此该事件将上报专家团队，或要求参考专家团队意见。在不同的情况下，专家团队的介入可能会以不同方式发生，其中一些方式可能涉及控制权的移交。例如：

• 支持专员可以在供应商网站上查找补丁。但是，事件的控制权不会因此移交给供应商。
• 支持专员向供应商发起事件。对用户事件的控制权并不移交，而是创建由供应商管理的并行事件工单。
• 支持专员将事件上报给内部工程团队。事件的控制权将随之移交给工程团队。
• 支持专员要求外包的工程团队提供修复程序。这可能会或可能不会涉及将事件的控制权交给工程团队。

该修复程序也可以是容易获得的东西，例如公开可用的补丁或升级。在某些情况下，修复程序可能要操作物理设备，例如更换有故障的硬盘驱动器。通常，在处理自定义应用程序或硬件时，必须先构建修复程序，然后才能进行部署。

通常有助于此步骤的做法包括：

• 事件管理 提供了更新事件记录所需的技能，工具和其他资源，其中包含构建和测试此修复程序所必需的活动的详细信息。
• 基础设施和平台管理 根据事件的性质，提供构建或配置故障基础设施或平台的修复程序所需的技能，工具和其他资源。
• 知识管理 提供所需的技能，工具和其他资源，以查找可以帮助调查和诊断事件的技术信息，并使用有关修复的信息更新现有的知识记录。
• 服务配置管理 提供创建修复程序时更新服务配置记录所需的技能，工具和其他资源。
• 服务台 提供使支持专员能够与客户或用户产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
• 服务财务管理 根据修复程序的性质，可能需要为解决事件所需的资源或服务组件向合作伙伴或供应商付款。
• 服务验证和测试 提供技能，工具和其他资源，以测试修复程序并确认它可以解决此事件，且符合所有相关的政策和标准。
• 软件开发和管理 根据事件的性质，提供构建或配置故障软件的修复程序所需的技能，工具和其他资源。
• 供应商管理 根据事件的性质，提供同协助构建修复程序的关键供应商进行交互所需的技能，工具和其他资源。

步骤4：部署修复程序

获得了修复程序，并通过测试及验证后，可以将其部署到用户或生产环境。部署可以采用多种形式。例如：

• 使用CI / CD 流水线在整个生产环境中分发修复程序
• 将硬件组件（例如新硬盘）交付给数据中心，随后在该中心进行配置
• 将硬件组件（例如新笔记本电脑）交付给最终用户办公室，由本地IT支持人员进行配置
• 远程登录用户的PC以从网络驱动器安装补丁。

通常有助于此步骤的做法包括：

• 部署管理 提供将修复程序部署到用户或生产环境所需的技能，工具和其他资源。
• 事件管理 提供了更新事件记录所需的技能，工具和其他资源，以及部署修复程序所需活动的详细信息。
• 基础设施和平台管理 根据事件的性质，提供配置和打包要部署的修复程序所需的技能，工具和其他资源。
• 知识管理 提供了使用有关修复程序的信息更新现有知识记录所需的技能，工具和其他资源。
• 服务配置管理 提供了在部署修复程序时更新服务配置记录所需的技能，工具和其他资源。
• 服务台 提供使支持代理能够使用共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
• 服务财务管理 根据部署的性质，可能需要向合作伙伴或供应商付款。
• 软件开发和管理 根据修复程序的性质，提供配置和打包用于部署的修复程序所需的技能，工具和其他资源。
• 供应商管理 根据事件的性质，提供与能够协助配置和打包待部署的修复程序的关键供应商进行交互所需的技能，工具和其他资源。

步骤5：验证事件是否已解决

部署修复程序后，下一步是验证事件是否已解决。此步骤与价值流中先前的步骤1和2十分相似，因为它涉及支持专员与用户开展沟通和共情。

如ITIL Foundation中所述，价值是对事物的利益，有用性或重要性的感知。在此模型中，用户和组织对价值的感知是不同的。例如：

• 用户可能将一系列现象视为价值流失，包括恢复服务所花费的时间，相关的生产力损失，生产力损失造成的挫败感，等待服务恢复时可能出现的任何其他问题或复杂情况， IT支持期间的服务体验和服务的可靠性等。而有效地消除价值流失被认为是有价值的。
• IT支持专员可能依据与用户及专家团队合作的经验，与各个小组进行交互所花费的时间以及更新相关记录等来计算价值。
• 专家团队可能会依据与IT支持专员或用户合作的经验，创建和部署修复程序以及更新相关记录的复杂性来计算价值。

而且，即使事件在技术层面上解决了，用户也可能需要其他帮助。例如：

• 有人告知服务已恢复
• 重新赋予服务的访问权和使用权
• 解决由于该事件引起的任何未决或额外问题。

因此，建议您与用户进行核对，以确保价值值已经令人满意地恢复了。这有助于增加IT支持与用户之间的共情，增进双方长期信任。

当受影响的产品或服务以最佳水平运行时，可以认为该事件已解决。换句话说，价值流失已得到纠正。

为了区分事件的解决和结束，许多IT支持工具通过以下方式将状态分配给事件记录：

• 解决事件意味着已解决了潜在的技术问题。
• 结束事件意味着修复程序和相关的价值恢复已经得到用户确认。
• 解决或关闭事件的过程是事件管理实践的基础设计的一部分，随后被价值流引用。在本节中，通常是指解决事件。

通常有助于此步骤的做法包括：

• 事件管理 提供根据用户交互详情更新（解决或关闭）事件记录所需的技能，工具和其他资源。
• 知识管理 提供根据修复程序和价值恢复相关信息来更新现有知识记录所需的技能，工具和其他资源。
• 服务配置管理 提供解决事件后更新服务配置记录所需的技能，工具和其他资源。其概述可用于填写表4.2中提供的价值流步骤模板。
• 服务台 提供使支持专员能够产生共情并管理与客户或用户的沟通渠道所需的技能，工具和其他资源。
• 服务级别管理 提供信息以评估恢复/已达到的服务水平，以及恢复的及时性。

步骤6：征集用户反馈

解决事件后，许多组织征求用户反馈，以便确定服务、与用户通信的方式、解决事件的过程或关键做法等的改进机会。通常，将其与价值流中涉及的其他角色（例如，IT支持专员和技术专家）的反馈相补充会很有用。

无论是提供反馈还是收集反馈，重要的是要通过探索如何做得更好来保持积极的态度，而不是专注于出了问题的地方。在讨论事件的历史及其影响时，通常很难区分情绪和自我。可能还需要识别并过滤掉可能会影响反馈的环境，个人或专业因素，例如：

• 担心生病的孩子的父母在分享反馈意见时可能会过分消极。
• 担心即将裁员的IT支持专员可能不会专注于日常工作。
• 刚刚大赚一笔的业务开发经理可能更友善，并且对IT支持问题较为宽容。

用户与IT支持人员之间越来越多的共情和信任可以帮助改进进行沟通并减少偏差的影响。反馈可以通过多种方式收集，但最终应存储在集中的位置，以帮助分析和管理报告。

通常有助于此步骤的做法包括：

• 持续改进 提供收集用户反馈所需的技能，工具和其他资源。
• 基础设施和平台管理 根据事件的性质和解决事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
• 服务台 提供使支持专员能够产生共情并管理与各利益干系人的沟通渠道所需的技能，工具和其他资源。
• 软件开发和管理 根据事件的性质和解决该事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。
• 供应商管理 根据事件的性质和解决事件所需的步骤，提供可用于识别改进机会的相关反馈所需的技能，工具和其他资源。

步骤7:识别整体系统改进机会

收集到所有相关利益干系人的反馈后，可以将其单独或与其他信息进行分析，例如有关服务，服务提供者，服务消费者组织，外部约束等的历史数据。可以依此识别整体系统的改进机会。例如：

• 服务提供者组织，或更一般而言，是SVS及其组件
• 价值流以及相关的步骤，动作和任务
• 与用户，合作伙伴，供应商和其他利益干系人的关系
• 定义与感知价值的方式。

识别的任何改进都应记录在服务提供商的持续改进登记册中，从而为服务提供商组织和提供者的SVS都能创造价值。写入登记册后，改进机会将优先于SVS中的其他工作。

通常有助于此步骤的做法包括：

• 持续改进 提供识别改进SVS及其组件的机会所需的技能，工具和其他资源；识别改进收集和分析反馈方式的机会；识别改进服务的方式，并将其记录在持续改进登记册中。
• 部署管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 事件管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 基础设施和平台管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 知识管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 监控和事态管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 问题管理 提供技能，工具和其他资源，以调查并减轻事件的可能原因。
• 风险管理 提供技能，工具和其他资源，以管理由于事件或修复而引发的新风险或现有风险的变化。
• 服务配置管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 服务台 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 服务财务管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 服务验证和测试 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 服务级别管理 提供登记并评估服务改进提案所需的信息，工具和技能。
• 软件开发和管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。
• 供应商管理 提供所需的技能，工具和其他资源，以识别改进实践的机会并将其记录在持续改进登记册中。

ITIL 故事: 用于创建、交付和支持的模型价值流

雷尼:有多种识别，创建和记录价值流的技术

索尔马兹: 最初，我们使用物理看板板通过便签纸记录了我们的价值流。随着试点工作的进展和增长，我们创建了一个电子看板，以便我们可以在两个项目地点之间共享它，并调整我们的价值流。

雷尼: 由于这是一项新提案，因此我们的价值流包含许多未知数。我们决定采用最小可行产品方法，使我们能够增量地开展服务适配，在自行车租赁过程的每个阶段测试客户的需求，了解如何根据指标衡量绩效并评估结果

弗朗西斯:在说明价值流时，我们结合了来自试点客户的反馈，并利用了艾克苏服务组合中的现有价值流。在创建用于实现新功能的价值流时，我们使用了ITIL模板。我们将不断调整我们的价值流，使它们与客户不断变化的需求保持一致

雷尼:在可视化价值流之后，我们能够识别我们需要投入新服务的额外资源。例如，我们发现迫切需要能够快速轻松地取回废弃或损坏的自行车，以帮助服务顺利运行。

4.3 使用价值流来定义最小可行实践

前文描述的价值流设计和文档编制技术有助于服务提供商了解工作性质和从需求到价值的流动，以及组织资源和实践为实现这种流动所做的贡献。

同样的技术也可以用于定义从对组织或利益干系人并允许学习和持续改进的实践中所需的最小贡献集。

例如，如果假定第4.2节中讨论的两个价值流模型是服务提供者组织中的唯一价值流，则可以使用表4.4的模板合并实践贡献。

表格 4.4 最小可行实践贡献

实践名称
贡献	目的（价值流步骤）

因此，例如，服务配置管理可以根据需要合并贡献，如表4.5所示。

表格 4.5 服务配置管理的最小可行实践贡献示例

服务配置管理实践
贡献	目的（进入价值流1或2）*
提供有关当前操作服务和配置项的信息，以及在构建服务组件时更新服务配置记录的技能、工具和其他资源	构建，配置或购买服务组件（价值流1中的步骤4）
提供有关当前运行的服务和相关配置项的信息	决定是否投资新服务（价值流1中的步骤2）
提供有关当前运行的服务和配置项的信息，以及在构建服务组件时更新服务配置记录的技能，工具和其他资源	部署服务组件以准备启动（价值流1中的步骤5）
提供技能，工具和其他资源，以在部署修复程序时更新服务配置记录	部署修复程序（值流2中的步骤4）
提供有关当前运行的服务和相关配置项的信息	设计和架构师提供新服务以满足客户需求（价值流1中的步骤3）
提供识别改进实践机会并将其记录在持续改进登记册中所需的技能，工具和其他资源	识别整体系统改进机会（价值流2中的步骤7）
通过提供有关配置项的信息来协助调查和诊断事件	调查查询，将其重新分类为事件，然后尝试将其修复（值流2中的步骤2）
提供有关当前运行的服务和相关配置项的信息	了解并记录服务要求
提供有关当前实时服务和服务组件的信息，以在描述需求时提供背景	确认并记录服务需求（价值流1中的步骤1）
提供解决事件后更新服务配置记录的技能，工具和其他资源	验证事件是否已解决（值流2中的步骤5）

* 价值流1（开发新服务）在第4.2.1节中；价值流2（恢复现有服务）在第4.2.2节中

因此，如果在特定功能或技能集的缺失方面面临挑战，那么符合逻辑的响应是调查哪个价值流步骤需要哪些贡献，可能走向如下两种后续之一：

• 放弃构建功能或技能集的要求
• 记录新的价值流，或修改现有的价值流，以确认对新功能的需求。

在上面的示例中，如果高级经理质疑服务配置管理实践所有者为何不支持对IT领域进行定期审核以识别未记录的配置项，则可能导致以下结果之一：

• 相互同意不需要该功能。
• 标识新的或迄今未记录的价值流，其中定期审核配置项。

采用最小可行实践方法将帮助组织避免对组织不需要的技能，工具，流程和其他资源进行投资。有助于：

• 降低业务的总拥有成本（TCO）
• 增加服务配置管理的投资回报。

ITIL 故事: 使用价值流来定义最小可行方法

Rainey :  Il serait utile de définir l'ensemble minimum de contributions requises pour les 34 pratiques ITIL qui bénéficieraient à l'organisation ou aux parties prenantes. Par exemple, notre service d'assistance actuel est conçu pour fournir une assistance routière ; cependant, cela ne s'étend pas aux sentiers de montagne que nos clients pourraient souhaiter explorer. Pour une première flotte de vélos de ville, nous pouvons conserver notre approche actuelle, mais si nous élargissons notre portefeuille de services pour inclure la location de vélos de montagne, nous devrons également étendre nos capacités d'assistance.

4.4 Résumé

Une chaîne de valeur est une articulation d'un parcours dans une chaîne de valeur de service, exprimant la manière dont le travail circule dans une organisation à mesure qu'elle crée, améliore ou prend en charge des produits et services qui co-créent de la valeur avec les consommateurs de services. Les flux de valeur et les processus sont l'une des dimensions de la gestion des services qui décrivent les étapes, actions et tâches nécessaires pour co-créer de la valeur à partir des exigences.

Une chaîne de valeur est étroitement liée à son contexte, reflétant l'étendue du contrôle et de l'impact de l'organisation, ainsi que le type de scénario ou de besoin. La granularité de la chaîne de valeur représente la nécessité de communiquer le flux de travail. Les flux de valeur peuvent être linéaires ou itératifs. Le choix du modèle reflète un désir quant à la manière dont le travail doit se dérouler et peut également refléter la manière dont le travail se déroule dans l'ensemble de l'organisation.

Dans certains cas, les flux de valeur peuvent également être répercutés sur plusieurs organisations. Par exemple, une étape dans une chaîne de valeur interorganisationnelle peut représenter la totalité de la chaîne de valeur d’une des organisations participantes.

Au sein d'une chaîne de valeur, d'une étape, d'une action ou d'une tâche, une organisation peut identifier les contributions (personnes, outils, informations, processus, etc.) que les pratiques de l'organisation doivent apporter. Ces informations peuvent être utilisées pour optimiser le système de valeur du service et ses composants.