プロセスモデリングとプロセスマイニングを組み合わせるメリット

プロセスモデリングは業務のあるべき姿を記述し、プロセスマイニングはイベントデータから実際の業務の流れを再構成します。2つを組み合わせると、あるべき姿と実態を比較し、見直すべき点を特定して、変更内容を検討できます。適合性チェックを使えば、その比較を明確に示せます。

プロセス管理を支える2つの要素

プロセスモデリングとプロセスマイニングは、同じプロセスについて異なる問いに答えます。モデリングは、現場の知識や設計上の判断をもとに始めます。一方、マイニングは、業務を記録するシステムのイベントログをもとに始めます。

モデリングによって、目指すプロセスをチームで共有できます。マイニングでは、記録されたイベントからケースがたどった経路を確認でき、文書に記載されていない可能性のある違いも把握できます。どちらか一方で十分というわけではありません。モデルだけでは業務がそのとおりに行われているとは証明できず、マイニングしたデータだけではプロセスのあるべき姿は定まりません。

プロセスモデリングで得られること

プロセスモデルを使うと、業務に関する判断を可視化し、確認できるようになります。たとえば、次のようなことに役立ちます。

• 共通の言葉。 引き継ぎや判断、作業手順について意見が分かれたとき、図が具体的な参照先になります。
• 目指す状態。 マイニングで現状は確認できますが、組織がどの経路を目指すかは決められません。モデルにその意図を記録できます。
• 研修・オンボーディング資料。 分かりやすい図があれば、口頭での説明に頼らず、役割や手順を理解しやすくなります。
• 自動化を設計するための土台。 作業の自動化を検討する前に、その作業の内容、使用する情報、完了の条件を定義する必要があります。モデリングを通じて、こうした判断を明確にできます。

プロセスモデリングの手法は、簡単なスケッチから、構造化されたBPMN図までさまざまです。適切な詳細度は、対象者やモデルを使って判断する内容によって異なります。チーム間で正確に共有できる表記法が必要な場合は、BPMN 2.0を使うと、プロセスフローを標準的な方法で表現できます。

プロセスマイニングで得られること

プロセスマイニングでは、通常、ケース識別子、アクティビティ、タイムスタンプを含むイベントデータから、プロセスの実行状況を再構成します。次のようなことを確認できます。

• ケースが実際にたどった経路。 手順を飛ばしたケース、前の工程に戻ったケース、手戻りが発生したケースを含め、記録された順序を確認できます。
• プロセスのバリアント。 すべてのケースが文書化された経路をたどると想定せず、実際にたどった複数の経路を比較できます。
• ボトルネックと待ち時間。 アクティビティ間の所要時間を測定し、ケースがどこで待っているかを確認できます。
• **比較の根拠。**目指すプロセスのモデルがあれば、記録された実行状況との違いを確認できます。

逸脱が誤りかどうかをマイニングだけで判断することはできません。調査のための根拠を示します。データが示す内容を解釈するには、プロセスに関する知識とモデルが役立ちます。

両者の隔たりがコストにつながる理由

文書化されたプロセスと、現場やシステムで実際に行われているプロセスは異なる場合があります。古いモデルをもとに人員配置や変更、自動化を計画すると、想定どおりには発生していない業務に注力してしまうことがあります。その一方で、回避策や手戻りが見えないままになっている可能性もあります。

よくある隔たりには、次のようなものがあります。

• モデルにあるが実行されていない手順。 計画されたレビューが実際には省略されている場合があります。実行状況を確認せずにその手順を前提として設計すると、変更の方向を誤る可能性があります。
• 実際の業務にだけ存在する手順。 回避策が日常的に行われていても、文書化されず、担当者も決まっていないことがあります。
• モデルにない手戻りのループ。 図では一直線の経路でも、イベントデータからケースが前のアクティビティに戻っていると分かることがあります。
• 時間のかかる引き継ぎ。 モデルで担当が変わる箇所を確認でき、マイニングでその時点にケースがどれだけ待つかを測定できます。

モデリングだけでは、文書化されたプロセスが実際の実行状況と一致しているか分かりません。マイニングだけでは、観測された動きが許容できるか判断できません。両者を比較することが重要なのは、この隔たりがあるためです。

両者を組み合わせる方法

改善のサイクルでは、目指すプロセスと実行状況の根拠を結び付けます。請求書の承認プロセスを例に、3つの手順を紹介します。

1. 現状をマイニングする。 イベントデータを使って、請求書がたどる経路、アクティビティ間の待ち時間、修正のために戻るケースを確認します。文書上の経路だけでなく、実際の実行状況を把握できます。
2. 目指す状態をモデル化する。 必要な承認手順、判断箇所、引き継ぎについて合意します。その目標をプロセスモデルに記録し、チームで参照できるようにします。
3. 適合性をチェックする。 モデルと記録されたケースを比較します。承認が省略された請求書、異なる順序で進んだ請求書、想定外の経路をたどった請求書を確認します。それぞれの違いが、実行上の問題なのか、モデルで認めるべき例外なのか、目標状態を見直す必要があるのかを判断します。

分かったことをもとにプロセスまたはモデルを見直し、新たな根拠が得られたら再び比較します。このサイクルは、すべての逸脱をなくすべきだという意味ではありません。どの違いに対応すべきかを、体系的に判断するための方法です。

どの部分に対応すべきかまだ分からない場合は、マイニングから始められます。確認したい目標状態についてすでに合意がある場合は、モデリングから始められます。どちらの場合も、最初のモデルや分析を出発点とし、理解が深まるにつれて更新してください。

まず1つのプロセスで分析を始め、イベントデータから何が分かるかを確認しましょう。

適合性チェック：モデルと実績をつなぐ方法

適合性チェックでは、目指すプロセスモデルと記録された実行状況を比較します。アクティビティが省略されたケース、順序が異なるケース、モデル上の経路が観測されなかったケースを確認できます。

違いが見つかった場合は調査が必要ですが、それだけで不具合があるとは限りません。プロセス上認められた例外かもしれませんし、モデルが不完全な場合や、関連するアクティビティがイベントデータに記録されていない場合もあります。まず対象範囲が明確なプロセスとモデルを用意し、業務を理解している人と結果を確認してください。

ProcessMindで適合性チェックがどのように行われるかをご覧ください。ケースごとに異なる経路を確認するには、プロセスバリアントをご覧ください。

従来の方法：メリットと注意点

プロセスモデルとマイニング結果を別々のツールで管理する方法は、モデリングや分析のワークフローが確立しているチームに適している場合があります。それぞれのツールを目的に応じて使い分け、ニーズに合った表記法や分析環境を選べます。

その一方で、両者をつなぐ作業が必要になります。モデルのエクスポート、分析結果の準備、アクティビティ名の統一、バージョンの手作業での照合などが発生する場合があります。比較に手間がかかりすぎると、プロジェクトで一度行ったきりになり、繰り返されないこともあります。その結果、モデルと根拠の内容に再びずれが生じます。

モデルとデータを確実にそろえる方法、明確な担当体制、実際に行われるレビュー手順があれば、別々のツールでも運用できます。重要なのは、プロセスの変化に合わせてチームが比較を繰り返せるかどうかです。

実務で役立つプロセスモデリングの手引き

役立つプロセスモデリングの手引きは、モデルを使ってどのような判断を行うかを明確にするところから始まります。図を描く前に、プロセスの範囲、モデルを使う人、必要な詳細度について合意してください。

1. 範囲を明確にする。 開始点と終了点が定まったプロセスを1つ選びます。受注から入金までのように範囲が広い場合は、役立つモデルを作る前に、より小さなプロセスに分ける必要があります。
2. 詳細度を決める。 図の詳細度は1つの階層にそろえます。大まかな工程とシステム上の細かな操作を混在させると、理解しにくくなることがあります。
3. なじみのある名称を使う。 アクティビティやロールには、チームで使っている言葉を使います。分かりやすいラベルがあれば、モデルを確認しやすくなり、イベントデータとの比較も容易になります。
4. まず主要な経路を示し、次に例外を加える。 あまり一般的でない経路を加える前に、通常の流れを分かりやすく示します。判断や責任に影響する例外を含めてください。
5. 担当者を決め、モデルのバージョンを管理する。 レビューの担当者を決め、変更履歴を残します。担当者や履歴がなければ、モデルが最新かどうか判断しにくくなります。
6. 定期的に見直す。 プロセスが変わったときや、合意したレビュー時期にモデルを確認します。誰も更新しない図は、いずれチームから信頼されなくなります。

表記法は、作業の一部にすぎません。記号や規則については、BPMN 2.0の解説をご覧ください。ProcessMindでプロセスを文書化する場合は、BPMNモデリングの概要をご覧ください。プロセスマッピングの手法を幅広く知りたい方は、プロセスマッピングについての記事をご覧ください。

改善のサイクルを継続的な取り組みにする

プロセスの変化に合わせてサイクルを繰り返すことで、改善に役立てられます。各回の担当者と、答えるべき具体的な問いを決めてください。たとえば、長い待ち時間の原因を調べる、変更によってケースの経路が変わったか確認する、モデルが今も目標状態を反映しているか見直す、といった問いが考えられます。

レビューは実行しやすい形にしましょう。

• 対象を絞って変更する。 プロセス全体を一度に再設計するのではなく、具体的な課題を1つ選びます。
• 根拠を確認する。 プロセスマイニングで記録された実行状況を確認し、必要に応じてプロセスシミュレーションで想定されるシナリオを検討します。
• モデルを更新する。 目標状態が変わった場合は、参照先として役立つようモデルを修正します。
• 例外を見直す。 逸脱が認められた経路なのか、データの問題なのか、対応が必要な課題なのかを判断します。

体系的な改善サイクルについては、データに基づくプロセス改善ガイドをご覧ください。

ProcessMindの役割

ProcessMindでは、プロセスモデリングとプロセスマイニングを1つのプラットフォームで利用できます。目指す状態を文書化し、記録された実行状況を分析して、別々のツール間で手作業による引き継ぎをせずに両者を比較できます。シナリオを検討するためのプロセスシミュレーションも利用できます。

モデルと分析を同じ場所にまとめることで、比較を繰り返しやすくなります。ただし、どの逸脱が重要かを判断したり、プロセスを変更したりする機能ではありません。根拠を解釈し、次の対応を決めるのはチームです。

まずプロセスマイニングについて知りたい方は、プロセスマイニングとは何かをご覧ください。ProcessMindで両者がどのようにつながるかは、BPMNモデリングとプロセスマイニングをご覧ください。

1つのプロセスで改善のサイクルを回す

プロセスを1つ選び、現状をマイニングして目指す状態をモデル化したうえで、業務をよく知る人と違いを確認してください。最初の分析はトライアルで実施できます。