アクティビティループの削除

概要

Remove Activity Loopsフィルターは、ケース内の重複するアクティビティの発生を排除することで、プロセストレースを簡素化します。このフィルターは、分析を複雑にする繰り返しのアクティビティを取り除くことでイベントデータをクリーンアップします。連続する重複のみを削除する（連続して繰り返されるアクティビティ）か、ケース全体で重複をすべて削除し、各一意のアクティビティの最初の発生のみを保持するかを選択できます。

このフィルターは、システムのログ記録の動作、データ品質の問題、あるいは明確にしたい実際のプロセスループの影響でアクティビティが複数回記録されるプロセスを分析する際に特に有用です。

よくある用途

プロセス可視化: プロセスフローの理解や分析を難しくするアクティビティループを除去してプロセスマップを簡素化。
データ品質向上: システムエラーや統合問題による重複したアクティビティ記録をクリーンアップ。
バリアント分析: ループに基づくバリアントを排除して、コアのプロセス経路に注目し、プロセスバリアント数を減少。
パフォーマンス測定: 処理時間を不必要に膨らませる重複アクティビティを削除して、より正確な継続時間の指標を取得。
コンプライアンス分析: 標準プロセスへの準拠を確認するため、繰り返しのない本質的なアクティビティ順序を特定。
プロセスマイニング準備: プロセス発見や適合性チェックのためのよりクリーンなデータセットを用意。

設定

重複除去方法：重複アクティビティの特定と削除方法を選択します。

直接追跡重複除去: 連続する重複アクティビティのみを削除します。同一アクティビティが連続して複数回現れる場合、最初の発生のみが保持されます。非連続の重複は保持されます。例として、「A, B, B, C, D, D, D」は「A, B, C, D」になります。
全体重複除去: ケース全体で重複アクティビティをすべて削除し、各一意のアクティビティの最初の発生のみを保持します。例えば、「A, C, B, C, D」は「A, C, B, D」になります（2回目の「C」が連続でなくても削除されます）。

例

例1：連続するシステムログの簡素化

シナリオ：大量注文を処理する際に注文履行システムが「Check Inventory」アクティビティを連続して複数回ログに記録し、プロセス分析にノイズを生じさせています。連続した重複だけを簡素化し、全体のプロセスフローは保持したい場合。

設定:

重複除去方法：直接追跡重複除去

結果：連続する重複アクティビティを含むケースが簡素化されます。例えば、「Create Order, Check Inventory, Check Inventory, Check Inventory, Pick Items, Pack Order」の場合、「Create Order, Check Inventory, Pick Items, Pack Order」になります。非連続の重複は変わりません。

考察：ログのアーティファクトをきれいにしつつ、本物のプロセスループは保持したい場合に理想的です。「Check Inventory」が後半で再度出現した場合（連続でない場合）は、別のプロセスステップとして保持されます。

例2：真のプロセス経路の特定

シナリオ：カスタマーサービスプロセスで複数のレビューアクティビティがあり、ケースが同じアクティビティを何度も繰り返すことがあります。繰り返し回数を考慮せずに、各ケースで行われた一意のアクティビティを特定したい場合。

設定:

重複除去方法：全体重複除去

結果：すべてのケースが一意のアクティビティ列に減少されます。「Open Ticket, Assign Agent, Review, Escalate, Review, Resolve」のケースは「Open Ticket, Assign Agent, Review, Escalate, Resolve」になります。重複するアクティビティはすべて削除され、最初の発生のみが保持されます。

考察：アクティビティが何度実行されたかは問わず、実施された内容だけを理解するのに役立ちます。基本的なプロセスステップが特定でき、最短経路の把握に貢献します。

例3：データ入力エラーのクリーンアップ

シナリオ：承認プロセスにおいて、手動入力のミスやシステムリフレッシュの問題で同じ承認アクティビティが連続して2回記録されることがあります。

設定:

重複除去方法：直接追跡重複除去

結果：連続する重複承認は削除され、別のアクティビティ後に再承認されたケースはそのまま保持されます。例えば「Submit, Approve, Approve」は「Submit, Approve」になり、「Submit, Approve, Modify, Approve」は変更されません。

考察：プロセスを歪めずにデータ品質問題を修正します。正当な複数回承認（他のアクティビティで区切られている場合）は保持され、明らかなミスのみが削除されます。

例4：分析のためのバリアント削減

シナリオ：活動ループにより多くのバリアントが生じ、コアのプロセスパターンを特定しにくくなっています。バリアント数を減らすため、何回行われたかではなく、どのアクティビティが出現したかに注目したい場合。

設定:

重複除去方法：全体重複除去

結果：ユニークなアクティビティ列でバリアントが統合されます。ループの回数だけで異なる複数のバリアントが単一のバリアントに凝縮され、数百から数十程度に大幅に減少します。

考察：一意のアクティビティによる簡素化はコアのプロセスパターンの特定を助け、プロセス発見をより意味のあるものにします。ループの挙動は除外したケースで別途分析可能です。

出力

このフィルターは、同じケースを含む変更済みのデータセットを返しますが、イベントシーケンスは選択された重複除去方法に従ってフィルターされます。各ケースは元のケースレベルの属性とメタデータを維持します。

直接追跡重複除去：連続する重複イベントを削除したケースを返します。アクティビティ名が直前イベントと同じでない限りイベントは保持されます。
全体重複除去：各一意のアクティビティの最初の発生のみを保持したケースを返します。ケース内の位置に関わらず、その後の同一アクティビティ名のイベントはすべて削除されます。

削除されたすべてのイベントは結果から除外され、残存するイベントは元のタイムスタンプと属性を保持します。

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