更新作成アクティビティ

概要

更新作成アクティビティエンリッチメントは、特定の「更新」アクティビティが発生し、監視しているイベント属性の値が前回の値から変化した場合に、新しいアクティビティをプロセスに挿入します。このエンリッチメントは、特定の属性を変更するはずのアクティビティ(「更新」ステップ)があり、そのステップが実際に何かを変更した場合のみ、それをプロセスマップ上で明示したい場合に利用します。

例えば、承認ワークフローにおいて一般的な「ステータス更新」アクティビティが複数のポイントで実行されることがあります。時には注文ステータスを変更し、時にはユーザーが保存をクリックしただけで実際には変更がないこともあります。このエンリッチメントにより、「ステータスが変更された」アクティビティを作成し、「ステータス更新」でOrderStatus属性が実際に変更された時だけ発生させることができ、変更のない実行はこのアクティビティを生成しません。

主な用途

  • 「ステータス更新」ステップが実際に注文ステータスを変更した場合に「ステータスが変更された」アクティビティを挿入する
  • 「チケット編集」ステップが実際に優先度値を変更した場合に「優先度が変更された」アクティビティを挿入する
  • 「ケース再割り当て」ステップが実際に新しいオーナーを選択した場合に「オーナーが再割り当てされた」アクティビティを挿入する

設定

新しいアクティビティ名: 挿入されるアクティビティの名前です。この名前はプロセスマップやアクティビティリストに表示されます。変更内容を説明的に表現した名前を選択してください(例:「ステータスが変更された」「優先度が更新された」)。

イベント属性: 監視対象となるイベント属性の名前です。エンリッチメントは、この属性の現在のイベントでの値と、Change Activitiesリストにある前のイベントでの値を比較します。

更新アクティビティ: 新しいアクティビティの挿入を トリガーする 単一のアクティビティです。この名前のアクティビティのイベントが発生し、かつ監視属性の値が前回の追跡イベントから変化していた場合に新しいアクティビティが作成されます。更新アクティビティはChange Activitiesのエントリの一つでなければなりません。

変更アクティビティ: 属性の値の履歴を追跡する「トラッキングポイント」として考慮されるアクティビティのセットです。エンリッチメントはこれらの名前のアクティビティに該当するイベントをスキャンし、監視属性の最新の値を記憶し、更新アクティビティのイベントが来た時に比較します。

Ignore Case: 比較時にnull(空白)値をどのように扱うかを制御します。有効(デフォルト)の場合、nullは独自の値として扱われ、たとえばnullから"Approved"への変化も変更とみなします。無効の場合、監視属性がnullのイベントはスキップされ、比較に参加しません。

例1: 実際のステータス変更と無変化の保存を区別する

シナリオ: 注文管理プロセスには、ユーザーが注文画面で保存をクリックするたびに実行される一般的な「ステータス更新」アクティビティがあります。ステータスが実際に変更されたときのみ「ステータスが変更された」アクティビティをプロセスマップに表示し、ステータスに変化がない通常の保存はマップに含めたくありません。

設定:

  • 新しいアクティビティ名: Status Changed
  • イベント属性: OrderStatus
  • 更新アクティビティ: Update Status
  • 変更アクティビティ: Create Order, Update Status, Close Order
  • Ignore Case: True

1つのケースでの流れ:

  • Create Order (OrderStatus = "Pending") -- 追跡、既存の追跡イベントがないため新規アクティビティなし
  • Update Status (OrderStatus = "Pending") -- 追跡、値に変化なしで新規アクティビティなし
  • Update Status (OrderStatus = "Approved") -- 追跡、新しい「Status Changed」アクティビティが挿入される(Update Status発生かつ値が"Pending"から"Approved"に変化)
  • Close Order (OrderStatus = "Approved") -- 追跡、Close Orderは更新アクティビティではないため新規アクティビティなし

実際にステータスを変更したUpdate Statusのイベントのみ「Status Changed」アクティビティが生成されます。

例2: 実際に承認する承認ステップ

シナリオ: 調達ワークフローには繰り返し実行される「マネージャーレビュー」アクティビティがあります。マネージャーはコメントだけを加えることもあれば、承認ステージを進めることもあります。承認ステージが変わったレビューのみをマークする「ステージ進捗」アクティビティを作りたい。

設定:

  • 新しいアクティビティ名: Stage Advanced
  • イベント属性: ApprovalStage
  • 更新アクティビティ: Manager Review
  • 変更アクティビティ: Submit, Manager Review, Director Review, Final Approval
  • Ignore Case: True

直近のSubmit / Manager Review / Director Review / Final ApprovalイベントのApprovalStageの値と異なるManager Reviewイベントが来た場合のみ「Stage Advanced」アクティビティが挿入されます。ステージを変えない(コメントのみの保存)Manager Reviewは生成しません。

出力

更新作成アクティビティエンリッチメントは属性値の変化を表す新しいイベント行をイベントログに生成します。これらの新規アクティビティは既存のプロセスフローにシームレスに統合され、すべてのプロセス分析ツールに表示されます。

アクティビティのプロパティ:

  • アクティビティ名: 「新しいアクティビティ名」設定と一致
  • タイムスタンプ: 属性の変更があったイベントから継承
  • ケースID: 元イベントと同じ(同一ケースにアクティビティを追加)
  • イベント属性: 元イベントのすべての属性が新しいアクティビティにコピーされる
  • アクティビティタイプ: プロセスマップやアクティビティリストに表示される標準アクティビティ

生成ロジック:

  • 新規アクティビティは以下の3条件すべてが成立したイベントに対してのみ挿入される
    1. イベントのActivityが設定された更新アクティビティに一致すること
    2. 同一ケース内に変更アクティビティリストのいずれかのActivityを持つ過去イベントがあること(比較対象となる過去の値が存在)
    3. 現イベントで監視属性の値が過去の追跡イベントの値と異なること
  • ケース内の最初の追跡イベントは比較対象がないため新規アクティビティは生成しない
  • Change ActivitiesリストにないActivityのイベントは完全に無視される
  • Ignore Case無効時は監視属性がnullのイベントはスキップされ、比較に参加しない

統合ポイント:

  • 新規アクティビティは属性変更の流れを示すプロセスマップに表示される
  • 特定の変更パターンを持つケースのフィルタリングに利用可能
  • 続くエンリッチメントでの期間計算などに利用できる
  • 異なる変更シーケンスを識別するバリアント分析で可視化される
  • アクティビティ頻度統計やパフォーマンス指標に含まれる
  • 元のイベント属性をすべて含む形でイベントログのエクスポートに現れる

プロセスマップの可視化: 新規アクティビティはプロセスマップに追加のノードを作成し、属性変更の経路を示します。これにより、それまで見えなかった状態遷移が通常のプロセスアクティビティと並んで分析可能になります。

パフォーマンス考慮:

  • 変更検出のために選択したアクティビティのすべてのイベントを処理する
  • 大規模データセットでは、変更が予想されるアクティビティにChange Activitiesを絞ることを検討
  • 新規アクティビティが増えることでプロセスマップの複雑度が増す可能性あり
  • 必要に応じてフィルタを活用し特定タイプの変更に分析を絞ることが可能

参照

  • アクティビティの削除: 不要なアクティビティをプロセスログから除外
  • 繰り返しアクティビティの削除: 連続した同一アクティビティの統合
  • 代表ケース属性: 特定アクティビティから属性値をケースレベルに抽出
  • 2つのアクティビティ間の期間: 元アクティビティと更新アクティビティ間の時間計測

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