繰り返し活動の削除

概要

繰り返し活動の削除エンリッチメントは、連続して重複する活動を1回に統合し、各活動が何回繰り返されたかという重要な情報を保持しながらプロセスを簡素化します。この強力なデータクリーンアップツールは、システムの動作、ユーザーの操作、またはプロセス設計により同じ活動が連続して実行される場合のプロセス分析に不可欠です。

ケース内で活動が連続して繰り返されると、真のプロセスフローが見えにくくなり、有意義なパターンの特定が困難になります。このエンリッチメントは、繰り返される活動をまとめることでノイズを除去し、活動が何回発生したかを追跡するカウント属性を作成します。また、繰り返された活動からイベントレベルの属性値を連結して保持することも可能で、統合の過程で重要な情報が失われません。

このエンリッチメントは2つの動作モードを提供します。厳密な連続繰り返し（活動が直接連続している必要がある）と柔軟な繰り返し（間に他の活動があっても全ての該当活動をまとめる）です。この柔軟性により、特定のプロセス分析ニーズにあわせて調整可能です。

よくある使用例

自動リトライロジックによるスタッターパターンの除去によるプロセスフローの簡素化
ユーザーがボタンを繰り返しクリックしたりページをリフレッシュしたりするイベントログのクリーンアップ
連続して発生するポーリングや状態確認活動の統合
高頻度モニタリング活動の分析時のプロセス複雑性の軽減
プロセス発見のために繰り返しのノイズを排除
次のステップに進む前に活動が何回繰り返されたかの追跡
監査証跡のために繰り返された活動の属性値を連結して保持

設定

Activity Name: 繰り返し発生を統合したい活動を選択します。このエンリッチメントは、この活動が複数回続けて発生する場所を特定し、一つのイベントにまとめます。リトライ試行、状態チェック、ユーザー操作など、プロセス内で繰り返される傾向のある活動を選んでください。

Count Column Name: 繰り返し回数を格納する新しい属性の名前を指定します。この属性には連続して統合された回数が自動的に設定されます。デフォルトの命名パターンは "[Activity Name]_Count" ですが、組織の命名規則に合わせてカスタマイズ可能です。例えば「Payment Retry」を繰り返し削除する場合は "Payment_Retry_Attempts" とすることもできます。

Concatenate Attributes (Optional): 繰り返された活動の中から保持したい、1つ以上のイベントレベルの文字列属性を選択します。複数のインスタンスが統合されると、これらの属性値はカンマ区切りで連結されます。これはエラーメッセージ、タイムスタンプ、ユーザーIDなど、それぞれの繰り返しで異なる文脈情報を含んでいる場合に特に有用です。計算済みでなく、非表示でない文字列型イベント属性のみ選択可能です。

Must Follow Directly: エンリッチメントが繰り返し活動をどのように認識するかを制御します：

有効（デフォルト）: 間に他の活動がない、直接連続した繰り返しのみを削除します。例：「A, B, B, B, C」では3回連続のBを1回にまとめます。最も一般的かつ保守的な方法です。
無効: ケース全体から該当活動の全インスタンスを削除し、最初の1回だけを保持します。例：「A, B, C, B, D, B」では最初のBだけを残し他を削除します。このモードはプロセスフローを根本的に変えるため慎重に使用してください。

例

例1：決済処理のリトライロジック

シナリオ： ネットワーク障害や一時的なカード認証問題で支払いが失敗した場合、eコマースプラットフォームが最大5回まで自動リトライを行います。これらのリトライがプロセスマップに乱雑さをもたらし、実際の顧客の流れが見えにくくなっています。

設定:

Activity Name: "Process Payment"
Count Column Name: "Payment_Retry_Count"
Concatenate Attributes: "Error_Message", "Gateway_Response"
Must Follow Directly: 有効

出力: 連続する決済処理試行が1つの "Process Payment" 活動に統合され、以下のコンテキストが付加されます：

新属性 "Payment_Retry_Count" に 1（リトライなし）、2（1回リトライ）、5（4回リトライ）等の値を保持
イベント属性 "Error_Message" にエラーメッセージをカンマ区切りで連結（例："Network timeout, Network timeout, Card declined"）
イベント属性 "Gateway_Response" にレスポンスコードが連結（例："503, 503, 402"）

ケース変換例：

変換前：Process Payment (失敗) -> Process Payment (失敗) -> Process Payment (失敗) -> Process Payment (成功)
変換後：Process Payment (成功) に Payment_Retry_Count = 4 が付加される

洞察： 何回リトライしたかを分析することで決済成功率を正確に把握可能。リトライ回数が多いケースは特定ゲートウェイの統合不具合やピーク時の問題を示している可能性があります。

例2：カスタマーサービスのステータス確認

シナリオ： カスタマーサービスのチケットシステムは、顧客回答を待つ間5分ごとにステータスを自動チェックします。これにより長時間のケースで数百のイベントが発生し、プロセス分析が困難になります。

設定:

Activity Name: "Check Ticket Status"
Count Column Name: "Status_Check_Count"
Concatenate Attributes: (未選択)
Must Follow Directly: 有効

出力: 連続するステータス確認は1つのイベントにまとめられます。例えば「顧客へのメール送信」と「顧客回答受領」の間に50回のステータス確認があっても、今は1つの "Check Ticket Status" として Status_Check_Count=50 と表示。

洞察： 自動ポーリングによるノイズを排除し、実際の顧客のやりとりを分析可能に。ステータスチェック回数はチケットが顧客の回答を待つ時間を示し、解決時間や顧客満足度と関連付けられます。

例3：製造品質検査の再検査

シナリオ： 医薬品製造で品質検査が不合格となると、バッチは最大3回まで再検査され、問題がなければ次工程へ進みます。再検査回数を追跡しつつ、分析のためにプロセスフローを分かりやすく保ちたい。

設定:

Activity Name: "Quality Inspection"
Count Column Name: "Inspection_Attempts"
Concatenate Attributes: "Inspector_ID", "Test_Results", "Failure_Reason"
Must Follow Directly: 有効

出力: 複数の連続する品質検査が完全な監査情報とともに統合されます：

Inspection_Attempts: 検査回数（1〜4回）
Inspector_ID は複数鑑定者のIDを "INSP_001, INSP_001, INSP_002" のように連結
Test_Results は "FAIL, FAIL, PASS" のように進行が分かる連結
Failure_Reason は "pH out of range, pH out of range, " のように不合格理由を連結表示

洞察： 初回合格率（Inspection_Attempts=1）と手直し率（Inspection_Attempts>1）を比較しながら、誰が検査し何故失敗したかを完全にトレース可能。

例4：ITサポートチケットの再割り当て

シナリオ： ITヘルプデスクでは解決前にサポート担当者間で複数回チケットが再割り当てされます。各再割り当てが "Reassign Ticket" 活動として記録されるため、実際の解決プロセスが分析しづらい。

設定:

Activity Name: "Reassign Ticket"
Count Column Name: "Reassignment_Count"
Concatenate Attributes: "Assigned_To", "Reassignment_Reason"
Must Follow Directly: 有効

出力: 複数回の連続再割り当てが統合されます：

Reassignment_Count: 再割り当て総数（チケットの往復回数を示す）
Assigned_To は "Agent_A, Agent_B, Agent_C, Agent_D" のように割り当てパスを連結
Reassignment_Reason は "Wrong department, Requires senior agent, Requires system admin" のように理由を連結

洞察： 再割り当て回数の多いケースは初期ルーティングの問題や責任者の不明瞭さを示し、連結された担当者名から典型的なエスカレーションパターンが分かり、割り当てルールの最適化に役立ちます。

例5：文書承認ワークフローの修正

シナリオ： 文書管理システムではレビュアーが文書を何度も差し戻し、修正依頼を繰り返します。組織は修正サイクルを追跡しつつ、承認全体のプロセスマップはシンプルに保ちたい。

設定:

Activity Name: "Request Revisions"
Count Column Name: "Revision_Cycles"
Concatenate Attributes: "Reviewer_Comments"
Must Follow Directly: 有効

出力: 連続する修正依頼が統合されます：

Revision_Cycles: 文書差し戻し回数（品質指標）
Reviewer_Comments は "Fix formatting, Update references, Correct calculations" のように連結され、レビューフィードバックの全歴史を保持

洞察： 多回数修正が必要な文書は要求仕様の不明確さや初回品質チェックの不足を示す可能性があり、連結されたコメントがレビュー過程の完全な監査記録となり、プロセスマップも見やすく保たれます。

出力

繰り返し活動の削除エンリッチメントは、イベントログを主に2つの方法で変更します：

イベント削減: 選択した活動の連続発生を1つのイベントにまとめます。最初の発生は保持し、その後の繰り返しは隠されて表示イベント数を減らします。この統合はケース単位で行われるため、ケースごとに削除されるイベント数は繰り返しのパターンにより異なります。

新しいカウント属性: "Count Column Name" で指定した名前の新しいイベントレベル整数属性が作成されます。この属性には統合されたイベントでまとめられた回数が設定され、繰り返しがなければ1となります。例えば4なら、活動が連続して4回発生していることを意味します。

連結された属性値: 連結を選択した属性の値はすべての繰り返しイベントから取り出され、時系列順にカンマ区切りで連結され、統合イベントに保存されます。エラーメッセージやユーザーID、タイムスタンプなど繰り返しごとに異なる重要情報を保持します。

プロセスビューへの影響: このエンリッチメント適用後、プロセスマップやバリアントは連続した同一活動のループを除いた簡素なフローを示します。例えば「A -> B -> B -> B -> C」のループは「A -> B -> C」となり、コアとなるプロセス構造の把握が容易になります。ただし、カウント属性をフィルターや計算で使うことで繰り返しパターンの分析は可能です。

カウント属性のユースケース: 新しいカウント属性は以下に利用できます：

フィルター：「Payment_Retry_Count > 3 のケースのみ表示」など、問題のある支払い処理を抽出
計算機：ケース全体で平均や合計を計算しリトライ率を測定
パフォーマンス分析：カウントの多寡と処理時間の相関を調査
品質指標：カウント=1 のイベント数で初回成功率を追跡
可視化：リトライ回数の分布を示すヒストグラム作成

データ整合性: エンリッチメントはタイムスタンプ情報（最初の発生のタイムスタンプを使用）を保持し、重要な属性値の連結を可能にすることで完全なデータ整合性を維持します。データの恒久的な削除はなく、繰り返しイベントは非表示扱いとなり、必要に応じてエンリッチメント解除で再表示できます。

このドキュメントは mindzie Studio プロセスマイニングプラットフォームの一部です。