バリューストリームマッピングとは？戦略を業務成果につなげる方法
バリューストリームマッピングで、プロセス全体のアーキテクチャ、実際のプロセスデータ、改善活動をどう結び付けるのか、ProcessMindを例に解説します。
**バリューストリームマッピング（VSM）**では、最初の依頼からプロセスや引き継ぎを経て納品に至るまで、顧客に成果を届ける仕事の流れを端から端まで把握できます。ワークショップを通じて、チームでフローの認識をそろえられます。その後、プロセスデータを使えば、マップが実態をどの程度反映しているか、どこに推定値が含まれるか、待ち時間や手戻りのうち何に注目すべきかを確認できます。
バリューストリームマッピングとは
バリューストリームマッピングは、製品やサービスを顧客に届けるまでの作業、情報、資材の流れを可視化するリーン手法です。バリューストリームマップには通常、顧客、サプライヤー、プロセスの各段階、情報の流れ、待ち時間や在庫に加え、総リードタイムと付加価値を生む作業時間を比較するタイムラインが示されます。
マップは単なるフローチャートではありません。顧客の視点からシステム全体を捉え、価値が生まれる場所、作業が滞る場所、引き継ぎによって手間が増える場所、手戻りやばらつきがキャパシティを消費する場所について、チームの認識をそろえられます。
バリューストリームマッピングは製造業で始まりましたが、サービス、ソフトウェア、医療、金融、調達、カスタマーサポートなど、知識労働を伴うさまざまなプロセスにも利用できます。フローを進む対象は、物理的な製品ではなく、注文、請求書、保険金請求、依頼、判断などの場合もあります。マップの範囲は1つのチームに限らず、複数のチーム、システム、部門にまたがることもあります。
従来のバリューストリームマップが古くなる理由
ワークショップで作成するマップは、関係者を集め、業務に関する知識を記録するのに役立ちます。出発点として有効ですが、すぐに実態と合わなくなることがあります。
- 文書や図は、その時点の状況を記録するものです。プロセス、システム、責任、需要は変化します。
- 実際のケースの経路ではなく、想定されたプロセスが説明されることがあります。
- マップにアクティビティが記載されていても、注文、請求書、製品、顧客、ケースなど、扱う対象とのつながりが示されていないことがあります。
- 問題の発生頻度やパフォーマンスへの影響、傾向の変化がマップからは分からない場合があります。
ワークショップは続けてください。フローについて話し合い、調査すべき点について合意する場として役立ちます。そのうえで、マップをプロセスアーキテクチャや業務上の根拠と結び付け、前提を事実とみなすのではなく、後から見直せるようにします。
ProcessMindでは、バリューストリームを大まかなレベルでモデル化し、各段階をその下位のプロセスと関連付けられます。エンドツーエンドの全体像から、詳細なプロセス要素までたどることができます。また、プロセスを、作成、更新、承認、引き渡しの対象となるオブジェクトや、関連するシステム、チーム、ロール、方針、文書化と結び付けられます。
バリューストリームマッピングの記号一覧
VSMの記号を使うと、チームで共通の視覚的な表現を使えます。以下では、バリューストリームマップでよく使われる要素と、それぞれの要素から分かることを紹介します。
| 記号 | 表すもの | 確認できること |
|---|---|---|
| プロセスボックス | プロセスのステップまたは作業領域 | 作業が行われる場所 |
| 顧客 | 製品やサービスを受け取る人 | 価値が届けられる場所 |
| サプライヤー | 資材、情報、需要の供給元 | フローの開始地点 |
| 在庫または待ち行列 | ステップ間で待機している作業 | リードタイムが積み上がる場所 |
| スーパーマーケット | 管理された在庫ポイント | 下流工程が必要なものを引き取れる場所 |
| かんばん投稿 | 移動や補充を知らせる視覚的な信号 | プル型システムの管理方法 |
| 生産管理 | 計画とスケジュール調整 | 作業の開始と調整の方法 |
| プッシュ矢印 | スケジュールに基づき次のステップへ送られる作業 | 下流からの信号なしに作業が進む場所 |
| プル矢印 | 下流の需要をきっかけに始まる作業 | 需要に応じてフローが進む場所 |
| 手作業による情報の流れ | 人を介して伝達される情報 | 引き継ぎで遅延が生じる可能性のある場所 |
| 電子的な情報の流れ | システムを介して伝達される情報 | システムがフローを支える場所 |
| 作業者 | ステップを実行する人 | キャパシティと責任の所在 |
| データボックス | プロセスのステップに関する指標 | チームが追跡する指標 |
| リードタイムラダー | 処理時間と待ち時間を示すタイムライン | 実作業と経過時間の比較 |
| カイゼンバースト | 改善の機会 | チームが調査したいこと |
| ボトルネックのマーカー | スループットを制限する要因 | フローが制限される可能性のある場所 |
ProcessMindには、BPMNの図形と並んで、専用パレットにVSMの図形が用意されています。エンドツーエンドのマップと詳細なプロセスモデルを同じワークスペースで管理できます。図形と接続の種類について詳しくは、バリューストリームマッピングの文書をご覧ください。
バリューストリーム、オブジェクト、プロセス要素
役立つバリューストリームマップでは、次の3点が明確になっています。
- **どのような成果を届けますか？**たとえば、注文の履行、請求書の支払い、インシデントの解決などです。
- **フローの中を移動したり、途中で変化したりする対象は何ですか？**顧客、注文、製品、出荷、請求書、保険金請求、サービス依頼などが考えられます。
- **どのプロセス要素が成果を生み出しますか？**人やシステムが行うアクティビティ、判断、イベント、引き継ぎが該当します。
1つのバリューストリームに複数の関連オブジェクトが関わることがあります。注文から出荷や請求書が発生する場合もあります。顧客のケースに複数のやり取り、タスク、承認が含まれることもあります。経路を1つだけマッピングすると、こうしたオブジェクト間の関係を見落とす可能性があります。
エンドツーエンドのバリューストリームを全体像として捉え、関係するプロセス要素やオブジェクトと結び付けます。運用上の細部を1つの図にすべて詰め込まずに、顧客に届ける成果から、その背後にある作業までたどれるようになります。
ProcessMindでバリューストリームマップを作成する方法
チームでマップを作成する際は、次の7つのステップに沿って進めます。各ステップで、ワークショップを通じて認識をそろえ、プロセスデータで前提を確認できます。プロセスデータは根拠を補うものであり、ワークショップや業務を理解する人に取って代わるものではありません。
1. 顧客に届ける成果と対象範囲を定める
**ワークショップ：**改善したい製品、サービス、または成果について合意します。顧客からの依頼から納品まで、あるいはインシデントの報告から解決までのように、開始点と終了点を明確にします。
**プロセスデータで確認できること：**イベントデータに関連する開始イベントと終了イベントが記録されていれば、対象範囲内の経過時間を測定し、ケースごとに経路が異なるかを確認できます。選択した境界が、実際の作業記録と合っているかを確かめるのに役立ちます。
2. 現状のアーキテクチャを構築する
**ワークショップ：**主要な段階と、作業を担うプロセスをマッピングします。チームが全体像から詳細へ移れるよう、一貫した階層に整理します。関係者が集まっている間に、プロセスオーナーとRACI上のロールも記録します。
**プロセスデータで確認できること：**イベントデータから、どのアクティビティがどの順番で発生するか、ケースが異なる経路をたどる頻度を把握できます。文書化した段階にさらに詳細が必要な箇所や、実際の経路がワークショップで共有した認識と異なる箇所を特定するのに役立ちます。
3. オブジェクト、システム、根拠を結び付ける
**ワークショップ：**注文、請求書、ケースなど、各段階で扱うオブジェクトを特定します。関係するシステム、方針、作業手順、チームを記録し、該当するプロセス要素と結び付けます。
**プロセスデータで確認できること：**イベント記録を使って、観測されたフローにどのオブジェクトやシステムが現れるか、引き継ぎがどこで行われるか、どのプロセスステップが記録されるかを確認できます。ただし、データに示されるのはソースシステムが記録した内容に限られます。イベントログにないコンテキストは、ワークショップで補います。
4. 実際のパフォーマンスデータでマップを検証する
**ワークショップ：**実際に作業を行う人とマップを確認します。待ち行列、手戻り、引き継ぎがどこで発生するかを尋ね、リードタイム、サイクルタイム、処理量についてチームの推定値を記録します。
**プロセスデータで確認できること：**プロセスマイニングでは、イベントデータから実際のリードタイム、サイクルタイム、待ち時間、スループット、手戻りを算出できます。これらの指標をワークショップでの推定値と比較し、遅延に最も影響するステップやバリアントを確認できます。結果は、データに含まれるイベントやタイムスタンプによって異なります。
5. 将来の状態を設計し、優先順位を付ける
**ワークショップ：**目指すフローと、そこに到達するために必要な変更について合意します。不要な引き継ぎ、責任の所在、需要、キャパシティを検討します。自動化、標準化、方針の変更、システム連携などの機会を挙げ、顧客への影響と測定可能なパフォーマンスに基づいて優先順位を付けます。
**プロセスデータで確認できること：**現状の分析から、優先順位付けの基準となる測定済みのベースラインを得られます。遅延や手戻りのパターンがどれほどの頻度で発生し、どのケースに影響するかを確認できます。将来の状態を決めるのはデータではありません。方向性はチームが定めます。
6. 実施前に変更を検証する
**ワークショップ：**業務を理解する人や、変更を担うチームと提案内容を確認します。想定されるトレードオフや、実施前に検証すべき点について話し合います。
**プロセスデータで確認できること：**ProcessMindのシミュレーションでは、人員配置、到着件数、経路設定、プロセスの変更を、現在のベースラインに照らして試すことができます。結果を参考に、考えられるトレードオフを検討し、将来の状態の計画に役立てます。シミュレーションは計画を支援するものであり、変更を実施したり、結果を保証したりするものではありません。
7. ガバナンスを整え、継続的に改善する
**ワークショップ：**マップのオーナー、確認担当者、見直し時期について合意します。責任者、システム、方針、または作業方法が変わったときは、モデルを更新します。
**プロセスデータで確認できること：**プロセス指標を継続的に確認し、改善後にフローやパフォーマンスが変化したかを検証できます。マップ、根拠、改善バックログを関連付けておくと、チームで同じ全体像を見ながら進捗を確認できます。
現状と将来の状態の比較
現状は、現在の作業の流れを示します。将来の状態は、選定した変更を行った後のフロー案を示します。出発点を理解するための現状と、改善の方向を示す将来の状態の両方が必要です。
実際に作業を行う人とともに、現状のマップを作成します。経路、待ち行列、引き継ぎ、手戻りについて、現場で把握している内容を記録します。プロセスデータがある場合は、ワークショップでの推定値を、観測されたリードタイム、待ち時間、ケースのバリアントと比較します。ワークショップでは待ち行列が発生する理由を確認でき、イベントログでは発生頻度やケースの待ち時間を把握できます。
将来の状態のマップは予測ではなく、設計案です。チームが実施したい変更、対応する担当者、リードタイム、コスト、サービスレベルなど、影響を見込む成果を示します。測定した現状をベースラインとして使います。提案した変更をシミュレーションする場合は、モデルに置いた前提に基づく推定値として扱います。
2つのマップの差分から、改善バックログを作成できます。各変更に担当者と指標を設定し、作業の進行に合わせて結果を確認します。推定値、実測結果、シミュレーション結果は明確に区別してください。
バリューストリームマップで測定する指標
バリューストリームマップでは、付加価値時間と待ち時間などの非付加価値時間を比較することがよくあります。顧客に届ける成果を理解し、フローの遅延箇所を特定するのに役立つ指標を選びます。
| 指標 | 分かること | 確認事項 |
|---|---|---|
| リードタイム | フローの開始から終了までの総経過時間 | 開始イベントと終了イベントを一貫した基準で定義します |
| サイクルタイム | ステップまたはケースの完了にかかる時間 | 実作業時間と経過時間のどちらを指すか明確にします |
| 待ち時間 | アクティビティや段階の間でケースが待機する時間 | 待ち時間と作業時間を区別できるタイムスタンプがあるか確認します |
| 付加価値時間と付加価値率（％VA） | 総経過時間のうち、顧客価値の創出に費やす時間の割合 | 付加価値を生む作業の定義について合意します |
| 初回正解率または初回合格率 | 修正や手戻りなしで作業が完了する頻度 | 初回で成功したとみなす条件を定義します |
| スループットと需要 | 完了する作業量と到着する作業量 | 両方の指標で同じ期間を使います |
| 仕掛品（WIP）と待ち行列の水準 | フロー内にある未完了作業の量 | データに未完了の作業が記録されているか確認します |
| 手戻り率とバリアント率 | 作業が繰り返されたり、異なる経路をたどったりする頻度 | イベントで該当する経路を区別できるか確認します |
| タクトタイム | 顧客需要を満たすために必要な作業ペース | 同じ期間の稼働可能時間と需要を比較します |
プロセスデータで測定できるのは、ソースシステムに記録された内容に限られます。結果の解釈や各指標の意味の確認、イベントログからは分からないコンテキストの特定には、ワークショップを利用します。
バリューストリームマッピングとプロセスマッピングの違い
どちらも図を使って作業を表しますが、答える問いは異なります。
プロセスマッピングでは、プロセス内のステップ、判断、ロールを示します。作業の進め方や責任者を説明するのに役立ちます。プロセス内のアクティビティや判断について、業務上の詳細を記載することもできます。
バリューストリームマッピングでは、注文、保険金請求、ケースなどの対象が、複数のプロセスを経て顧客に成果を届けるまでを端から端まで捉えます。より広いバリューストリーム全体のフロー、待ち時間、引き継ぎ、パフォーマンスを明らかにします。
バリューストリームマップで、業務の一連の流れのうち、どの部分に対応が必要かを判断します。次に、各段階の詳細を確認できるよう、プロセスマップやBPMNモデルにリンクします。もう一方の手法について詳しく知りたい方は、プロセスマッピングとはをご覧ください。
VSMとプロセスマイニングを組み合わせるメリット
ワークショップでは、対象範囲についてチームの認識をそろえ、価値を生むフローのあり方を話し合えます。プロセスマイニングでは、イベントデータを使ってケースがシステム内をどう進むかを確認できます。両者を組み合わせれば、業務を理解する人の知識をイベントログで置き換えることなく、前提を検証できます。
- バリューストリームから始め、エンドツーエンドの改善対象を定めます。
- プロセスマイニングで、記録された経路、遅延、手戻り、ボトルネックを調べます。
- プロセスアーキテクチャで、各段階を詳細なモデル、オーナー、文書化と結び付けます。
- シミュレーションで、実施前にベースラインと照らし合わせながら変更案を検討します。
ワークショップではコンテキストを確認し、チームが将来の状態を設計します。データは、記録されたプロセスで何が起きているかを数値で示します。シミュレーションでは、明示した前提のもとで考えられる結果を検討できます。それぞれの役割を分けて考えることで、業務知識と根拠の両方に基づいて改善を判断できます。
自社のデータでフローを測定すると、プロセスマイニングが現状のマップの検証にどう役立つかを確認できます。VSMモデルと図形を使った手順を詳しく知りたい方は、バリューストリームマッピングの文書をご覧ください。
バリューストリームマッピングでよくある間違い
- **1つの部門だけをマッピングする：**チームやシステムの境界をまたぐ場合も含め、顧客に成果を届けるために必要な段階と引き継ぎを記載します。
- **アクティビティと顧客価値を混同する：**顧客の視点から直接価値を生まなくても、必要なステップはあります。その違いを明確にします。
- **推定値を実測値として扱う：**ワークショップでの推定値を明記し、該当するイベントがある場合はプロセスデータと比較します。
- **典型的な経路だけをマッピングする：**例外やバリアントについて確認し、イベントデータで記録された経路の違いがどの程度の頻度で起きるかを調べます。
- **最上位のマップに詳細を詰め込みすぎる：**バリューストリームでは段階とフローに焦点を当てます。業務ロジックの詳細は、詳細なプロセスモデルにリンクします。
- **現状の把握だけで終える：**将来の状態の設計、担当者、指標について合意し、マップを具体的な行動につなげます。
- **マップのオーナーを決めない：**定期的な見直しの時期を決め、プロセス、システム、責任が変わったときにマップを更新します。
はじめに
製品、サービス、顧客の利用プロセス、需要の種類から1つ選びます。開始点と終了点を明確にし、その範囲を理解する人を集めます。
- **対象と成果を1つずつ選ぶ。**出荷される注文、支払いが完了する請求書、解決されるインシデントなどが例です。
- **実際の作業の流れに沿って段階をマッピングする。**待ち行列や引き継ぎを含め、現場の担当者と前提を確認します。
- **把握している内容と、その根拠を記録する。**ワークショップでの推定値と、プロセスデータから算出した指標を分けて示します。
- **改善の優先事項を少数に絞る。**顧客にとって重要で、調査可能な遅延や制約に焦点を当てます。
- **担当者と見直し日を決める。**プロセスの変化に合わせてマップを見直し、改善目標に関連する指標を追跡します。
ProcessMindでは、バリューストリームをエンタープライズプロセスアーキテクチャや、その下位のプロセスモデルと結び付けられます。分断された図を個別に管理するのではなく、エンドツーエンドの全体像、関連モデル、パフォーマンスの根拠をまとめて管理できます。
継続的に更新できるバリューストリームマップの作成
ProcessMindでバリューストリームをモデル化し、各段階を詳細なプロセスと関連付け、マップをプロセスデータに結び付けられます。共有モデルを使ってフローを話し合い、ワークショップでの前提を検証し、次に調査する箇所をチームで決められます。
次のステップ
ワークショップでフローをマッピングできますが、各ステップ間の待ち時間をすべて測定することはできません。プロセスデータを使って、記録されたプロセスでケースがどれだけの時間待機しているかを確認します。
バリューストリームを可視化 visible
ProcessMindでプロセス、オブジェクト、パフォーマンスデータをつなぎ、バリューストリーム全体を可視化・分析して改善につなげます。
可視化
インサイト
ボトルネック
改善につなげる
