プロセスマイニングの課題と、プロジェクトを着実に進める方法

**兆候：**分析からケースが抜け落ちる、アクティビティの順序が不自然に見える、同じステップが複数の名前で表示される。

**原因：**システム間でケース識別子が一致していない可能性があります。タイムスタンプのタイムゾーンや詳細度が異なる場合もあります。アクティビティ名にばらつきがあったり、イベントの欠落によってケースが未完了に見えたりすることもあります。責任者が不明確、プライバシー要件がある、またはソースの項目を利用できないために、データへのアクセスが遅れる場合もあります。

**予防策：**1つのプロセスから始めます。安定したケース識別子、意味の分かるアクティビティ名、分析に使えるタイムスタンプ、業務を代表する十分な数の完了ケースがあることを確認してください。早い段階でデータの責任者にアクセス方法とプライバシー要件を確認します。データの欠落を記録し、答えるべき問いに影響するかを判断してください。

特定のシステムから自動的に整ったデータが得られると決めつけないでください。データソースにかかわらず、手元の抽出データを検証します。完了ケースがそろった対象を絞ったデータセットは、項目が欠けた広範なデータより、通常は分析に役立ちます。

イベントログによくある不備を順に確認するには、ログに4つの代表的な不備がないか確認するをご覧ください。

**兆候：**ダッシュボードはあるものの、何を改善するか合意できない。または、何か変わったか分からないまま分析を繰り返している。

**原因：**チームが下すべき判断ではなく、ツールやデータセットを起点にプロジェクトを始めています。ベースラインがなければ、介入の前後でプロセスを比較できません。また、プロセスが変化するにつれて、1回限りの分析は役立ちにくくなります。

**予防策：**問いを業務上の具体的な表現で記述します。たとえば、特定のプロセスのどのステップで遅延が発生しているか、どのバリアントで手戻りが最も多いかを確認します。問題を反映するKPIを選び、ベースラインを記録して、次回の確認時期を決めてください。プロセスマイニングは、保管して終わるレポートではなく、繰り返し行う改善サイクルとして捉えます。

**兆候：**関係者は結果に関心を示すものの、次の対応を誰も決めない。プロセスオーナーが不在だったり、最初の報告後に協力が得られなくなったりする。

**原因：**業務を理解している人が関与していない、または対応する権限や時間を持つ人がいない可能性があります。プロジェクトが事業上の優先事項と結び付いていないと、現在の問題を解決する手段ではなく、余分な作業に感じられることがあります。

**予防策：**分析を始める前に、プロセスオーナーと経営層のスポンサーを決めます。業務を実行・管理する人にも参加してもらいましょう。分析で支援する判断を合意し、現実的な目標を設定して、レビューの日程を決めます。

**兆候：**プロセスの問いに答えるより、接続の準備やツールの習得に時間をかけている。変更のたびに専門家の支援が必要になる。

**原因：**ツールがデータ形式、チームのスキル、またはプロジェクトの範囲に合っていない可能性があります。設定が複雑だと最初の分析が遅れ、ライセンスと利用目的が合わなければ参加できる人が限られることもあります。

**予防策：**広範囲に展開する前に、1つのデータ出力を使ってワークフローを試します。利用可能なデータにツールが対応していること、分析担当者が操作できることを確認してください。ツールで測定、モデル化、シミュレーションできる範囲を明確にします。プロセスの変更をツールが実行することは期待しないでください。

**考えられる原因：**データへのアクセス、責任者、または準備要件が未解決です。

**対応策：**データの責任者、必要な項目、アクセス方法を確認します。少量のデータを出力して試します。

**考えられる原因：**対象範囲が1つの判断に結び付いていません。

**対応策：**最初に立てた問いに立ち返ります。最初の分析が終わるまで、追加のプロセスは保留します。

**考えられる原因：**イベントが欠落している、アクティビティ名にばらつきがある、またはプロセスの範囲が不明確です。

**対応策：**プロセスの専門家とサンプルケースを確認し、イベントの定義を修正します。

**考えられる原因：**ベースラインや合意済みのKPIがありません。

**対応策：**現在のKPIを記録し、いつ、どのように再測定するかを決めます。

**考えられる原因：**判断や次のステップを担う人がいません。

**対応策：**担当者を決め、対応内容に合意し、レビュー日を設定します。

**考えられる原因：**実際に業務を行う人を交えずにプロジェクトが設計されています。

**対応策：**プロセスの検証と問いの選定に、実務担当者を加えます。

**考えられる原因：**ワークフローが複雑すぎる、または知識が1人に集中しています。

**対応策：**手順を文書化し、分析を維持する担当者が必要なスキルを身に付けられるようにします。

**兆候：**各ステップを分析対象に含めるべきかチーム内で意見が分かれる、またはモデルが複雑すぎて判断に役立たない。

**原因：**実際のプロセスには、バリアント、例外、引き継ぎがあります。焦点を絞った問いを立てる前にすべてを細かく図にすると、複雑さが増します。また、モデルをすべてのケースを網羅する完全な説明として扱うと、誤解を招くことがあります。

**予防策：**プロセスの範囲を定め、問いに関係する重要な節目に焦点を当てます。プロセスマイニングでケースごとの違いを把握し、問題に関係するバリアントを調べてください。イベントデータが示す内容を、実務担当者に確認してもらいます。

**兆候：**同じアクティビティに異なる名前を使っている、またはケースの完了条件について意見が一致しない。

**原因：**部門、システム、文書の間でプロセスの定義にずれが生じています。そのため比較が難しくなり、遅延の原因が見えにくくなることがあります。

**予防策：**結果を比較する前に、ケースの定義と主要なアクティビティの意味を合意します。分析を見直して繰り返せるよう、前提条件とデータ変換を記録してください。

**兆候：**プロセスマップはあるものの、分析と一貫して併用する方法がありません。

**原因：**文書化とイベントデータを別々に扱っています。図には想定されるプロセスが示される一方、イベントログには実際に起きたことが記録されています。

**予防策：**モデルを参照しながら、実際に観測されたプロセスと比較します。すべてのばらつきをなくそうとするのではなく、業務上の問いに関係する逸脱を調べてください。

**兆候：**調査結果に基づく変更に反対が出る、または分析が役立つのか疑問視される。

**原因：**プロジェクトが現在の事業上の優先事項と結び付いていない可能性があります。分析の方法を理解していない、または問いの設定に関与していないために、調査結果が信頼されない場合もあります。

**予防策：**分析の目的、範囲、限界を説明します。早い段階からプロセスオーナーや現場のチームに参加してもらい、具体的な業務目標と結び付けます。結論だけでなく、根拠となるデータと前提条件も共有してください。

**兆候：**特定の分析担当者が不在になると作業が滞る、または他のチームが分析を維持できない。

**原因：**データ、定義、分析手順に関する知識が共有されていません。

**予防策：**プロセス、データの定義、判断内容を文書化します。調査結果を利用する人を育成し、変更の依頼や結果のレビューを行う明確な方法を整えます。プロセスエクセレンスセンターはチーム間の取り組みを調整できますが、プロセスオーナーの役割に代わるものではありません。

**兆候：**パイロットが終わっても、継続、見直し、中止の判断が計画されていない。

**原因：**繰り返し実施できる方法を検証するのではなく、パイロット自体を最終成果として扱っています。

**予防策：**パイロットの前に、次のステップに進む根拠となる証拠を定めます。スポンサーとプロセスオーナーを交えて結果を確認してください。データ、手法、責任体制がより広い範囲を支えられる場合にのみ、対象を広げます。