ITIL 4 - 作成、提供、およびサポート - サービスのバリュー ストリームを作成、提供、およびサポートします。

4. サービスを作成、提供、サポートする価値の流れ

この章では、次の方法について説明します。

• バリュー ストリームを文書化して、組織内でワークフローがどのように流れるかを理解する
• 新しいサービスを作成するためのプロトタイプのバリュー ストリームを理解する
• フィールドサービスをサポートするプロトタイプのバリューストリームを理解する

この章は、実務者が以下を理解するのに役立ちます。

• サービス バリュー システム (SVS) におけるバリュー ストリームの役割
• バリューストリームの分類
• バリューストリームのステップをどのように記述するか
• 一般的な数学モデリング理論を適用してバリュー ストリームを簡素化する方法
• バリューストリームを設計する際に考慮すべきこと

実践者は、バリューストリームはシンプルで簡単に実行できますが、必ずしも作業のプレゼンテーションが単純化されているわけではないことを理解する必要があります。作業の種類が異なればルートも異なるため、さまざまな価値の流れがあり、設計された活動パターンまたは理想的な活動パターンを指す場合もあれば、実際の観察可能な活動パターンを表す場合もあります。個人、ツール、ベンダー、プロセスなどの同じリソースがバリュー ストリームのさまざまな部分に存在する可能性があり、たとえば、運用スペシャリストがユーザー エンゲージメントに参加したり、調査をサポートしたり、復旧サービスの修正を展開したりすることができます。

4.1 ITIL サービスのバリュー ストリーム

ITIL バリュー チェーンには、参加、計画、改善、設計と引き継ぎ、エンゲージメント、提供とサポートの 6 つのプロトタイピング アクティビティが含まれます。バリュー ストリームについて考える便利な方法は、特定のシナリオまたはニーズの種類に対するサービスのバリュー チェーン内のアクティビティを通じた行程を視覚化することです。例えば：

• イベントの種類が異なれば、それぞれの場合に必要な作業を記述するために異なる値ストリームが必要になる場合があります。次に例を示します。
  • エンドユーザーのハードウェアイベント
  • メインイベント
  • サイバーセキュリティインシデント。 
• 顧客のニーズが異なれば、次のような異なる価値の流れが必要になる場合があります。
  • 業務運営の効率を高める新しい製品またはサービス機能の必要性
  • チームメンバーが製品またはサービスにアクセスするためのリクエスト
  • 製品またはサービスの通常の動作を維持するための新しいインフラストラクチャ機能のリクエスト。

4.1.1 ITILサービスバリューストリームの構造

定義: ITIL サービス バリュー チェーン 製品とサービスを効果的に管理するために必要なすべての主要なアクティビティをカバーする、サービス プロバイダー向けの運用モデル。

ITIL サービス バリュー チェーンは、6 つのプロトタイプ バリュー チェーン アクティビティで構成されます。これらの一連のアクティビティは、「ITIL サービス バリュー ストリーム」、またはもっと単純に「バリュー ストリーム」と呼ばれます。バリュー チェーンでは次のことが可能になります。

• 内容に応じて、バリューチェーン活動の 1 つ、一部、またはすべてについて言及します
• 進行中の作業に応じてバリューチェーン活動が重複する

バリュー ストリームは 1 つ以上のステップで構成され、各ステップは特定の目標を達成するための 1 つ以上のアクティビティで構成されます。これらのアクティビティは、直列または並列で行うことができ、他のアクティビティに接続することも、相互に独立させることもできます。アクティビティ自体には 1 つ以上のタスクを含めることができ、それらのタスクは接続することも独立させることもできます。

定義: バリューストリーム 組織が製品やサービスを作成し、消費者に提供するために実行する一連のステップ

バリュー ストリーム モデルを使用すると、サービス組織は作業単位をプロセスに編成できます。プロセスはコンテキストや粒度のレベルに応じて異なります。たとえば、消費者が自発的にサービス リクエストを作成するバリュー ストリームでは、次のようになります。

• バリュー ストリーム レベルでは、この作業単位は満たすべき顧客のニーズとして定義でき、バリュー ストリーム内のサービス ポートフォリオのアクティビティ フローが変化する可能性があります。
• ステップ レベルでは、定義可能な作業単位を要件として見積もる必要があり、バリュー ストリームの実装中にサービス設計パッケージ内のロール定義の設計が変更される可能性があります。

図 4.1 は、バリュー チェーンのアクティビティ、バリュー ストリーム、バリュー ストリーム内のステップ、ステップ内のアクティビティ、およびアクティビティ内のタスクの関係を示しています。

バリュー ストリームは要件によって開始されます。例:

• 監視ツールによって生成されるイベント
• ユーザーが送信したリクエスト。

図 4.1 バリュー ストリームのアクティビティ階層

価値の流れは、機能的な製品やサービスの価値を創造または復元することで終了します。値ストリームには次のコンテンツ情報が必要です。

• ユーザーのモバイルデバイスを介して送信されたサーバー名や GPS データなど、1 つ以上の関係者 (ステップまたはアクションを実行する外部組織) からの入力。
• 他のバリュー ストリーム、例: 1 つのバリュー ストリームでは、新入社員のオンボーディングに ID 情報またはその他の情報を使用する必要があります。これらの情報は、新入社員を雇用 (または契約) するバリュー ストリームから取得されます。

バリュー ストリームは、サービス プロバイダー、サービス利用者のリソースを使用して必要な出力を生成し、管理システム、ガバナンス システム、外部要因、制約、原則の範囲内で機能します。

値ストリームは、望ましい結果を作成するために使用される出力を生成します。この出力には、利害関係者と共有される情報やフィードバックが含まれ、管理活動やガバナンス活動の実行に役立ちます。場合によっては、これらの出力は、組織内外の他の価値の流れのトリガーとして機能することもあります。

4.1.2 バリューストリームと組織

ITIL 4 では、組織と企業体を同一視しません。組織には、個人 (自営業のプログラマーやコンサルタントなど)、チーム (ビジネス ユニットとしての開発チームやサポート チームなど)、企業、または連携するビジネスのエコシステムが含まれます。

バリューストリームは基本的に組織に関するものです。したがって、バリュー ストリームは粒度の各レベルで存在する可能性があり、それらは 1 人の個人、チーム、ビジネス ユニットなどである可能性があります。ただし、バリュー ストリームは構築されるシステムのコンテキストによって定義され、その目的は組織、その顧客、その他の利害関係者に価値を生み出すことであることを覚えておくことが重要です。大企業には、管理においてある程度の自律性を持つ複数の異なる組織が含まれる場合があり、それぞれの組織は、独自の価値を持つサービス バリュー システム (SVS) バリュー チェーンおよびバリュー ストリームとみなすことができます。ただし、それが自給自足できる可能性は低く、サービス バリュー システム (SVS) をチーム レベルで確立する必要があります。

製品やサービスの全体的な目標と期待は、異なるアクティビティや調整されていない一連のアクティビティでの各チームの使用を単に説明するのではなく、最初から最後まで、つまりニーズから価値まで説明する必要があります。したがって、バリューストリームはさまざまなチームの作業を表し、さまざまな利害関係者に影響を与え、さまざまなプロセス、ツール、人材、さらにはさまざまなサプライヤーを使用することになります。

ITIL サービスのバリュー ストリームを視覚化し、ユーザーが製品、サービス、または IT サービス管理専門家と対話するタッチ ポイントを明確に示す必要があります。ITIL バリュー ストリーム手法の主な利点は、複数の利害関係者の関与を特定するだけでなく、潜在的な障害点を確認し、価値を要件に明確に結び付けることができることです。

重要な情報 バリュー ストリームとプロセスの主な違いは、その焦点とその使用方法です。多くの入力を出力に変換する相互に関連するアクティビティは、プロセスと考えることができます。 バリュー ストリームは、ニーズまたは機会から顧客価値の実現までの活動の流れに焦点を当てます。プロセス分類、プロセス管理ツール、または手法をバリュー ストリームに使用できます。したがって、多くのプロセスはバリューストリームではありません。

バリュー ストリームの各ステップは、プロセスまたはバリュー ストリームとして再定義できます。後者は、複数のビジネスが関与する大企業やエコシステムによく見られます。

例 鉄道で旅行する乗客は、選択した国とルートに応じて複数のサービス プロバイダーとやり取りする場合があります。これらのサービスプロバイダーの中には、人々を輸送する鉄道会社もあります。その他のサービス プロバイダーには、駅管理、発券、セキュリティ、配車、列車のナビゲーションなどがあります。鉄道旅行は、シームレスで快適なユーザー旅行を生み出すために、多くの組織が協力し協力する複雑なエコシステムです。各組織は、複数のバリュー ストリームを含む独自の SVS を管理する必要があります。同時に、これらの組織は鉄道旅行を可能にし、サポートするバリューストリームコラボレーションにも貢献します。バリュー ストリームの特定のステップは、参加組織のバリュー ストリームによって実際に実現されます。

IT サービスに新しい機能を追加するための高レベルのバリュー ストリームには、サードパーティ ベンダー、社内ソフトウェア開発チーム、サイト信頼性エンジニアリング チーム、その他の IT チーム、およびユーザー チームが関与する場合があります。外部サプライヤーによって実行されるステップは、サプライヤー独自のバリュー ストリームとして管理される可能性があります。組織内で実行されるステップは、これらのプロセスに含まれるアクションまたはアクティビティのプロセス管理として形式化されます。

バリュー ストリームを下位レベルのバリュー ストリームまたはプロセスにカスケードすると、組織は次のことが可能になります。

• 参加当事者のバリューストリームとプロセスを統合し、より高いレベルのバリューストリームの価値に焦点を当てる
• バリューストリーム内の他の組織やチームからのフィードバックに依存して、反復的に改善します。 
• 組織やチーム全体で協力し、ワークフローの可視性を高める
• より広範な組織やエコシステムがどのように運営され、利益を得るのか、関係者が何をしているのかを理解することで、総合的に考えて取り組みます。

4.1.3 バリューストリームの考慮事項

4.1.3.1 適切なパースペクティブを選択する

バリュー ストリームは 2 つの観点のいずれかから文書化できます。サービスプロバイダーの要望を反映するように設計できる一方で、研究のために作業のパフォーマンスを記録します。文書化すると、設計を観察された動作と比較できます。

設計と観察された動作の違いが改善のきっかけとなる可能性があります。これらには次のものが含まれる場合があります。

• 実際の作業パターンを反映するためにバリュー ストリームのドキュメントを更新する
• 切り替え時間を短縮してワークフローを最適化します。需要を価値に変え、反復可能な作業を自動化します。

4.1.3.2 開始点と終了点

価値の流れは常に要件で始まり、1 人以上の利害関係者にとっての価値の創造または実現で終わります。したがって、バリューストリームを文書化するときは、たとえば次のようにして、アウトサイドインの意見を維持することをお勧めします。

• 事業計画を反映したマイルストーンとタイムライン
• 聴衆に関係のある言葉を使用する能力
• 顧客またはユーザーの観点から成果と価値を構築します。

4.1.3.3 柔軟性

バリュー ストリームは、作業が実行されるコンテキストと環境に応じて、バリュー チェーン内のアクティビティを再利用します。バリューストリームは組織のニーズに応じて柔軟にカスタマイズできます。例: 組織は、ウォーターフォール アプローチと同様に、作業中にステージを追加したり、バリュー チェーンのアクティビティ間に反復ループを作成したりできます。

4.1.3.4 粒度

バリュー ストリームは、作業の粒度をある程度反映できます。たとえば、アジャイル ソフトウェア アクティビティを使用するバリュー ストリームでは、アプローチの探索的な性質を反映して、作業が複数回反復されることがあります。あるいは、バリュー ストリームは、作業をステップとして表すことを可能にする、より高いレベルのパースペクティブを具体化することもできます。作業がどのように表現されるかに関係なく、バリュー ストリーム全体にわたって粒度が一貫していることが重要です。

4.1.3.5 識別手順

バリュー ストリームにどのステップを使用する必要があるか、これらのステップにどのようなアクティビティを含める必要があるか、意思決定を行う際には次の点を考慮する必要があります。

• バリューストリームの詳細レベル。組織は、すべての操作の詳細を表示するか、作業の概要のみを表示するかを決定する必要があります。
• 個人またはチーム間の引き継ぎがバリュー ストリームに及ぼす影響。多くの場合、異なるチームが実行するアクティビティを個別のステップとして示すことが最善です。これは、キュー内のどのジョブに遅延が発生しているかを把握するのに役立ちます。
• バリュー ストリームに影響を与えるバリュー チェーン内の複数のアクティビティ。

複数のバリューチェーン活動を含む

ステップにアクションと計画アクティビティの両方が含まれる場合は、それを 2 つの別々のステップに分割する方が合理的です。たとえば、「顧客のニーズを決定する」ステップは次のように分割できます。

• 顧客との要件の定義 (サービス デスクや関係管理などの実践からの貢献を、バリュー チェーンでの活動の実現にマッピングするために使用できます)
• 顧客のニーズを評価します (ビジネス分析、リスク管理などの実践からの貢献を利用して、バリュー チェーンの計画された活動にマッピングできます)。

同様に、「ベンダー Web サイト経由でパッチを実装する」ステップは次のように分割できます。

• Web サイトからパッチをダウンロードします (バリュー チェーンでの活動の取得/構築にマ​​ッピングされた、ソフトウェア開発と管理、サプライヤー管理などの実践からのコンテンツを使用できます)
• このパッチを展開します (変更管理、展開管理などの実践からの貢献を使用して、バリュー チェーンの設計および変革アクティビティにマッピングできます)。

複数のステップが同じグループの人々または同じリソースのセットによって実行される場合、結合されたステップの出力を最も適切に説明できるように、それらをバリュー チェーン アクティビティの個別のステップとして説明するのが最善です。これは、各ステップ間のキューで待機することによる作業への影響を回避するのにも役立ちます。

4.1.3.6 一連のステップ

通常、バリュー ストリームはエンゲージメントから始まりますが、他のアクティビティも最初のステップとして機能します。たとえば、エンジニアが監視ツールを通じてインシデントを発見した場合 (要件)、最初のステップとして調査 (提供とサポート) を開始することが考えられますが、この場合、影響を受ける顧客に直接連絡すること (アクション) は考えられません。

4.1.3.7 サービスバリューチェーンへのマッピング

バリュー ストリームの各ステップは、バリュー チェーンのアクティビティにマッピングすることで記述できますが、実際には、バリュー チェーンのアクティビティも、基本的なアクティビティやタスクをマッピングすることによって記述されます。例えば：

• 顧客のニーズを評価するステップは、バリュー チェーンの計画アクティビティにマッピングできますが、バリュー チェーンの推進アクティビティである「顧客との要件の絞り込み」と呼ばれるバリュー チェーンのアクティビティまたはタスクにマッピングすることもできます。 。
• サプライヤーの Web サイトからパッチをダウンロードするステップは、バリュー チェーンの Get/Build アクティビティにマッピングできますが、バリュー チェーンの改善アクティビティにマッピングできる「Update Workaround」と呼ばれるアクティビティまたはタスクもあります。

4.1.3.8 実践へのマッピング

粒度のレベルに応じて、バリュー ストリーム内のステップ、アクティビティ、またはタスクを実際のプロセスまたは手順にマッピングできます。たとえば、コードの開発とデプロイのステップは、次のアクティビティとタスクにマッピングできます。

• 自動テストを実行するプログラム
• 手動テストを実行するプロセス

4.1.4 サービスのバリューストリームの設計

実践者は、組織のニーズが確実に満たされるように、次の方法を使用するか、他の方法を試すことをお勧めします。

1. 以下を通じてバリュー ストリームのユース ケースまたはシナリオを定義します。

• 要件 (できれば非技術的な用語で)
• 需要を生み出すきっかけ
• バリューストリームが結果を生み出す
• 値ストリームのコンテキスト内の値 (値は作成または復元できるため)。

2. 需要から価値までのサービス バリュー チェーン全体で必要なステップを記録します。

3. ステップ 2 からサービス バリュー チェーンへのマッピングを開始します。

4. 必要に応じて、ステップをアクティビティまたはタスクに分割します。

5. 各ステップ、アクティビティ、またはタスクの正常な完了を促進するために、次のような関連する実践または関連リソースを特定します。

• 運営または管理チームまたは個人
• ツールとテクニック
• 情報とデータ (例: 記録、フォーム)
• 独自のリソースを通じて成果や結果を達成できるパートナーまたはサプライヤー。

上記の 5 つのステップは、協力して完了する必要があります。たとえば、一連の会議やワークショップを組織することができます。ドキュメントを準備する最初のタスクは、ニーズに応え、目標を絞った方法で価値を生み出すための、広範かつ基本的な理解を確立し、ベースラインを形成することです。

ベースラインを確立したら、次の方法でバリュー ストリームをさらに実験または最適化できます。

• ワークフローをテストするための簡単なモックを作成する
• 意味のある成果、成果、利益に貢献しない作業を排除する
• 左シフト勤務
• 品質、コスト、または時間の逸脱を引き起こす可能性のある作業の遅延
• フィードバック メカニズムとアップグレード メカニズムを導入して、成果物の品質とバリュー ストリームのメリットを継続的に改善します。
• ステップ、アクティビティ、またはタスクから自動化改善の機会を特定し、ワークフローを加速します
• ボトルネックや制約を特定して管理します。制約を中心としたバリュー ストリームの再設計が必要になる場合があります。
• 必要に応じてレビュートリガーを導入し、バリューストリームを改善します。(レビューは、消費者からのフィードバック中など、ランダムに行うことも、定期的に行うこともできます。)

4.1.5 バリューストリームを記述する手順

バリュー ストリームのステップを説明するときは、次の点を特定して文書化する必要があります。

• ステップ名は、 そのステップが何であるかを定義します。ステップの説明に非専門用語を使用するかどうかを決定します。バリュー ストリームの評価者が目標を簡単に理解できるように、頭字語や専門用語は避けてください。たとえば、次のとおりです。
  • バリュー ストリームのステップとしては、「INC_template を使用してインシデント チケットを記録する」よりも「ユーザー インシデントを登録する」というフレーズの方が適しています。
  • 「顧客の要件を記録する」という表現は、「顧客の入力を TK421 フォームに記入する」よりも適切な表現です。
• トリガーを入力します。 トリガーによりステップが開始されます。
• 情報は、 ステップに必要な情報を説明します。バリュー ストリーム活動を実行する前に、外部の利害関係者または他の組織からリソースを取得する必要があります。
• 実践への貢献 組織が実践ステップを正常に完了するのに貢献するツール、技術、個人、およびその他のリソース。
• トリガー条件と出力結果の要件に基づいて明確に実行する必要があるアクティビティやタスクは 何ですか? どのアクティビティを並列化できますか? どのアクティビティに前提条件が必要ですか? 各アクティビティやタスクの実行にはどのくらい時間がかかりますか?
• このステップを制限するには どのような原則に従う必要がありますか? これらの原則は、サービスプロバイダーまたは外部関係者によって定義されます。最も重要なことは、組織は直面する可能性のあるリソースの制約を検討する必要があるということです。
• 出力 ステップが存在する理由。ステップでは、成果を達成し、サービスプロバイダー、ユーザー、またはその他の関係者に価値を生み出す必要があります。
• 推定または目標配信時間 ステップを完了するまでにかかる時間の長さ。これには次のものが含まれます。キューで待機する時間。

次のテンプレートは、バリュー ストリームの説明の最初の参照として使用できます。最初のテンプレート (表 4.1) はバリュー ストリームの概要を提供し、2 番目のテンプレート (表 4.2) はバリュー ストリームを説明するステップ構造を提供します。実践者には、適切と思われるテンプレートを使用することが推奨されます。

表4.1 サービスバリューフロー記述テンプレート

値ストリーム名

みんな

バリューストリームとそのユースケースの説明

必要

引き金

結果

生み出される価値

配達予定時間または目標配達時間

表 4.2 バリュー ストリーム ステップの説明テンプレート

値ストリーム名
ステップ番号
ステップ名
バリューチェーン活動	アクティブ化、計画、改善、設計と変革、取得/構築、提供、サポート
入力	トリガーとメッセージ
出力	トリガーとメッセージ
期待される結果
納期の見積もりまたは納期の目標
サポート練習
練習名	実践がこのステップにどのように貢献するかを説明する
役割と責任
責任者
Rが実行されました
Cさんが相談した
私が言われた

注: 実践への貢献は、(可能な場合は) 専門用語の使用を避け、全体的な方法で説明する必要があります。

4.1.6 バリューストリームマッピング

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

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

价值流映射用于深入了解组织的工作流程，并在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: 組織や利害関係者に利益をもたらす 34 の ITIL 実践に必要な最小限の貢献を定義することは有益でしょう。たとえば、現在のサポート サービスはロードサービスを提供するように設計されていますが、お客様が探索を希望する登山道には適用されません。最初のシティバイクのフリートについては、現在のアプローチを維持できますが、マウンテンバイクのレンタルを含めてサービスポートフォリオを拡大する場合は、サポート機能も拡張する必要があります。

4.4 概要

バリュー ストリームは、サービスのバリュー チェーンにおける行程を表現したもので、サービスの消費者と価値を共創する製品やサービスを作成、強化、またはサポートするときに、組織内で仕事がどのように流れるかを表します。価値のストリームとプロセスは、要件から価値を共同創造するために必要なステップ、アクション、タスクを記述するサービス管理の側面の 1 つです。

バリュー ストリームはそのコンテキストと密接に関連しており、組織の管理範囲や影響、シナリオやニーズの種類を反映しています。バリュー ストリームの粒度は、ワークフローを伝達する必要性を表します。値のストリームは線形または反復的になります。モデルの選択は、仕事がどのように流れるかという希望を反映しており、組織全体での仕事の流れも反映する場合があります。

場合によっては、バリュー ストリームが複数の組織にまたがってカスケードされることもあります。たとえば、組織間のバリュー ストリームのステップは、参加している組織の 1 つのバリュー ストリーム全体である可能性があります。

組織は、バリュー ストリーム、ステップ、アクション、またはタスク内で、組織の実践が提供する必要がある貢献 (人材、ツール、情報、プロセスなど) を特定できます。この情報は、サービス価値システムとそのコンポーネントを最適化するために使用できます。