プロセスマイニングのビジネスケース：財務部門が注目する4つの数字

プロセスマイニングのビジネスケースでは、財務部門が判断するために4つの数値を示します。問題の規模、改善にかかる費用、パイロットの費用、最初の根拠が得られるまでの期間です。このうち3つは、自社のプロセスデータを一度エクスポートするだけで算出できます。見積もりの数値にはその旨を明記し、測定時期も示してください。

「プロセスマイニングを導入する」という申請は、問題、意思決定、根拠を示す日付が明確でないため、評価が難しくなります。却下される案件の多くは、プロセスの実態ではなく、ツールに期待する成果をもとに作られています。このページでは、対象を1つのプロセスに絞り、何を測定し、変更にいくらかかり、いつ結果がわかるのかを示します。

プロセスマイニングのビジネスケースに必要な4つの数値とは？

それぞれの根拠を示せるようにし、申請の妥当性を説明する前に4つすべてを明らかにしてください。

1. **問題の規模：**サイクルタイムの日数、延滞料、売上債権回転日数、FTEの作業時間など、社内ですでに追跡している単位で、現在のプロセスにかかっている費用を示します。自社の処理量と実測時間に基づいて算出してください。
2. **改善費用：**分析ではなく、プロセスを変更するために必要な費用です。方針変更と再研修の実施では、システム変更とは作業規模が異なります。見積もりは、変更の責任者が作成します。
3. **パイロット費用：**ライセンス、データ作業、事実を確認するために必要な社内の作業時間です。
4. **最初の根拠が得られるまでの期間：**結果を確認する予定日と、その際に照合する指標です。

通常、4つのうち3つは同じ情報源から得られます。プロセスデータをエクスポートすると、問題の規模、データ準備にかかる作業、分析に必要な期間がわかります。残る改善費用は、まだ決めていない変更内容によって異なります。そのため、根拠のない数値を作るのではなく、責任者と日付を明確にする必要があります。

ビジネスケースに記載する数値には、測定値か見積もりかを明記してください。財務部門はその違いを確認します。根拠のわからない自信ありげな数値を4つ並べるより、その問いに答えられる案件のほうが退けられにくくなります。

プロセスマイニングのビジネスケースが支持を失うのはなぜですか？

数値が間違っているために案件が失敗することは、ほとんどありません。確認できる根拠がないと、プロセスマイニングのビジネスケースは支持を得られません。

意思決定ではなく、機能の導入を求めている。「受注から入金までの全体を可視化する」だけでは、何に予算を使い、どのように結果を評価するのかが財務部門に伝わりません。「2回目の承認で注文の3分の1に1週間の遅れが生じているかを確認し、11月15日までに結果を報告する」とすれば、明確になります。

**ベンチマークの割合に頼っている。**プロセスマイニングによってサイクルタイムが通常何％短縮されるという主張では、自社のプロセスについては何もわかりません。たとえ目立つ数値でなくても、自社のベースラインのほうが参考になります。

**データ作業の費用が含まれていない。**データの抽出、ケースの特定、タイムスタンプの整理、データ更新の設定には時間がかかります。ライセンス費用しか記載していなければ、パイロット費用を過小評価することになります。費用項目の詳細は、まず費用の内訳を確認してください。

**問題を見えにくくする平均値を使っている。**平均処理時間では、5日間の待ち時間がすべてのケースに均等に分散されるため、数値が小さく見え、改善の効果も小さく見積もられます。時間がどこにかかっているのかを示してください。どのステップで、何件のケースに、どれだけ時間がかかるのかを明らかにします。「四半期に約12,000件の注文があり、その約3分の1が約束した納期に間に合わず、原因は不明です」なら、検証の手がかりになります。「受注管理に重大な非効率がある」だけでは、検証できません。

プロセスマイニングプロジェクトでは、通常どのような成果が得られますか？

どのような根拠が得られるかを把握しておくと、ビジネスケースを作成しやすくなります。イベントデータを使って1つのプロセスを初めて分析すると、通常は次のような問いに答えられます。

• **時間がかかっている箇所：**各アクティビティの待機時間と作業時間を並べて、両者の差を確認できます。
• **プロセスが繰り返される頻度：**文書化されたモデルにないステップを含め、ループや手戻りの回数を確認できます。
• **ケースを引き継ぐ担当者の数：**チームやシステム間の引き継ぎ回数を確認できます。
• **プロセスのばらつき：**異なる経路の数と、最も一般的な経路をたどるケースの割合を確認できます。
• **ルールから外れている箇所：**意図したプロセスと実際のプロセスとの適合性の差を確認できます。
• **自動化の候補となるステップ：**処理量が多く、ルールに基づき、ばらつきが小さく、測定済みのベースラインがあるステップです。
• **各ステップにかかる作業量：**変更案の費用を見積もれるよう、ステップごと、ケースごとの所要時間を確認できます。

得られる情報は、プロセスとデータによって異なります。ケースID、アクティビティ、タイムスタンプを含むログがあれば、最初の4項目を確認できます。それ以外には、より詳細なデータが必要で、比較対象となるモデルが必要な場合もあります。プロセスマイニングによるプロセスデータの分析方法をご覧ください。データをまだ利用できない場合は、インテリジェンスへの道筋で、事前に整えておく必要があるものを説明しています。

明確にしておきたいことがあります。ツールが答えを出すわけではありません。ツールが示すのは根拠であり、その根拠をビジネスケースにまとめるのは利用者です。変更の価値、ステップ自体が必要かどうか、チームがどれだけのキャパシティを実際に取り戻せるかは、いずれもツールの一覧からはわかりません。これらは事業上の判断であり、測定結果があれば判断しやすくなります。プロセスマイニングの効果は、その判断に基づいて実施する変更の範囲に応じたものです。

ログがプロセスの一部しか対象としていない場合や、期間の一部しかカバーしていない場合は、数値を示す際に明記してください。対象範囲と対象外の内容が読者にわかるようにすれば、一部の測定結果も根拠として役立ちます。

自社の測定値から効果をどのように算出しますか？

問題の規模を示すだけでは、変化につながるメリットは伝わりません。プロセスマイニングの価値は、データによってどの意思決定が変わるかにあります。組織として下す必要のある判断に結び付けて、投資の根拠をまとめましょう。初めてのケースでは、次の2つのモデルで大半をカバーできます。

現金または運転資本：

短縮日数 × 対象ケース数 × ケース1日あたりの価値 × 資本コスト

キャパシティ：

期間あたりの削減時間 × 時給の総コスト

次の3点を明確に区別しましょう。

• **業務で使っている単位で示します。**サイクルタイムの日数、回避できた延滞料金、短縮したDSO、または削減できた時間などでメリットを表します。「効率化」だけでは検証できません。
• **現金とキャパシティを分けて考えます。**キャパシティを確保しても、それだけで現金が生まれるわけではありません。同じチームでより多くの業務を処理することで価値が生まれるのか、人員配置の判断によるものなのかを示し、その判断を誰が行うのかも明記します。
• **最も確信の持てない前提を明らかにします。**見積もりのうち、根拠が最も弱い部分と、その検証方法を示します。

実測したベースラインがあれば、その後の計算の根拠を説明しやすくなります。時間の数値を自社のイベントデータから算出していれば、残る前提は削減幅だけです。これはレビュー担当者が検討できる数値です。ベースラインも削減幅も仮定に基づくメリットは、会議での検討に耐えにくくなります。削減率の根拠を示せない場合は、検証した範囲と、そのうち計算に用いた値を明記してください。

これらの数値をProcessMindのROI計算ツールに入力できます。年間のケース数、平均処理時間、諸経費を含む時給、想定する削減幅、インシデント数と平均コストに加え、ライセンスプランの条件を入力すると、年間メリットの合計、純利益、投資収益率、投資回収期間が算出されます。

これは汎用モデルであり、入力値がどのように組み合わさるかを示す点に価値があります。初期値を自社の業務量、所要時間、コストに置き換えて初めて、自社のケースになります。また、この計算ツールでは導入作業やデータ準備の工数はコストに含まれないため、別途加算してください。自社の状況に合わせられないモデルでは、まだ投資の根拠として不十分です。

4つの数値で示すビジネスケースの具体例

以下の数値は説明用です。数値そのものではなく、算出方法を参考にしてください。

**状況：**あるプロセスで、四半期あたり12,000件の注文を処理しています。サイクルタイムの中央値は18日、90パーセンタイル値は41日です。注文の約3分の1は、ある承認ステップで5日を超えて滞留しています。このステップで実際に作業する時間は約4分です。

**1. 問題の規模：**待ち時間の影響を受ける注文は、四半期あたり約4,000件です。このステップでの平均待ち時間が6日なら、四半期あたりのサイクルタイムは合計24,000注文日分に相当します。同じ期間に、このステップで実際に必要な作業時間は約270時間です。どちらの数値をケースに含めるかは、遅延によってコスト、サービスレベル、またはその両方に影響が出るかによって異なります。いずれの数値も、使用前に自社のデータと照合してください。単位にも注意が必要です。注文日数は金額ではないため、金額に換算する場合は、その換算方法も前提として明記し、検証してください。

**2. 改善策のコスト：**考えられる変更の1つは、承認ステップの対象を注文の33％から8％に減らせるよう基準を引き上げ、承認者が不在の場合は代理担当者を割り当てることです。低コストの改善策として扱う前に、方針、統制、導入コストを担当者に確認してください。

**3. パイロットのコスト：**対象を1つのプロセスと定めた期間に絞ります。ライセンス、データ準備を行う分析担当者の工数、プロセスオーナーの工数を含めてください。データ準備の工数を確認できていない場合は、見積もりとして明記します。ライセンス費用しか記載されていないプロセスマイニングの費用対効果分析では、必要な作業を過小評価することになります。

**4. 最初の証拠を得るまでの期間：**対象セグメントのサイクルタイムを確認する日を決めます。待ち時間に変化がなくても、次の判断に役立つベースラインが得られます。

**結論を変える可能性がある要素：**承認ステップが統制上の不備を検出するために設けられている場合、基準を変更すると統制が弱まる可能性があります。そのリスクをケースに含め、変更を提案する前に統制の責任者を交えて検討してください。

4つの数値と財務部門からの質問を、1ページにまとめます。

表の各項目は、実測した数値か、担当者を明示した見積もりに基づいている必要があります。プロセスマイニングのROI計算も同様です。自社のデータと提案する変更によって裏付けられるまでは、見積もりを削減額として提示しないでください。

まず変更を検討する価値のあるステップを見つける方法については、プロセスマイニングで自動化の機会を見つける方法をご覧ください。

最初のビジネスケースをパイロットにする理由

最初のビジネスケースの対象は、プラットフォームではなくパイロットです。4つの数値も、1つのプロセス、1つの判断、そして大規模な投資を決める前に結果を確認できる期間を想定しています。プロセスマイニングの価値を検証する取り組みとして、つまり小規模な展開ではなく、測定のための取り組みとして進めてください。

小さく試し、判断基準は現実的に設定しましょう。ビジネスケースは、迷わず実行できるほど明確であるべきです。そうでなければ、対象を広げすぎている可能性があります。まずデータで状況を確かめ、必要なところから範囲を広げてください。数席分の費用と数週間の分析担当者の工数で実施できるパイロットなら、プラットフォーム全体の導入より低い基準で判断できます。さらに、プラットフォーム導入だけでは得られない、自社のベースラインも把握できます。

小さく始めることは、ソフトウェアの選択にも関わります。エンタープライズ規模での導入を前提とするツールでは、検討を始める時点で大きなビジネスケースが必要になります。ProcessMindはシート単位の料金体系で、トライアル後も無料プランを利用できます。また、クレジットカード不要の14日間無料トライアルがあるため、最初の分析にエンタープライズ契約は必要ありません。各プランの料金を見る。

プロセスマイニングのパイロットを始める前に、次の4点を決めておきましょう。

• **1つのプロセス：**1つの問いで範囲を決められるよう、対象を絞ります。
• **1つの判断：**調査結果をどの判断に役立てるのかを決めます。
• **終了基準：**継続と中止を判断する条件を、事前に合意します。
• **レビュー日：**証拠を評価し、次の対応を決める日を設定します。

パイロットの結果が次の取り組みを支持する場合は、その知見を次のプロセスの検討に役立てます。そうでない場合も、ベースラインと方針を見直す明確な理由が得られます。いずれの場合も、開始前に考えられる3つの結果をケースに記載してください。証拠が変更案を支持する、別の変更案を支持する、または中止を支持する、の3つです。結論が1つに決まっているケースは、測定の取り組みとはいえません。

数値をそろえられない場合はどうするか

その場合、投資の妥当性をまだ確認できていない可能性があります。それを伝えることは失敗ではなく、調査で得られた結果です。主な理由は3つあります。業務量が少なく、改善の効果が限られる。データを分析に使える形で入手できない。あるいは、その判断を待っている人がいない、という理由です。

データがあり、プロセスの規模が小さい場合は、手作業でベースラインを測定します。データを使える状態にできない場合は、ライセンスを申請するのではなく、データ整備に必要な作業を見積もります。再検討する前に何を変える必要があるかも明記してください。