Create Update Activity

概要

Create Update Activityエンリッチメントは、ケース内の特定のイベント属性値が変化したときに、新しいアクティビティを自動的にプロセスに生成します。この強力な機能により、属性の変化をプロセスフロー上で可視化でき、隠れた状態遷移を明示的なプロセスステップに変換して分析、視覚化、最適化が可能になります。すべてのステータス変更で手動によるイベント記録が不要になり、値の変化を賢く検出して、それを表現するアクティビティを作成します。

このエンリッチメントは、重要な情報が時間とともに変化するが、その変化が明確なアクティビティとして記録されていないプロセスで特に有用です。例えば、受注ステータスが「Pending」から「Approved」、「Shipped」へ変わる場合、それぞれの遷移ポイントで自動的に更新アクティビティを生成できます。これによりプロセスマップ上でのフローが明確になり、状態遷移の正確なタイミング分析や、承認ワークフローのボトルネックや異常の特定が可能になります。エンリッチメントは指定されたアクティビティで選択された属性の変化を監視し、有意な変化が起きた場合のみ新規アクティビティを挿入するため、冗長な更新によるノイズを避けられます。

属性の変化をアクティビティとして可視化することで、属性値の中に隠れていたパターンを分析できます。具体的には、アイテムが特定の状態にとどまる時間を測定したり、どの遷移が最も時間を要するかを特定し、誰がステータス更新を行ったかを追跡し、異なるプロセスバリアント間の状態変化の順序を理解できます。このエンリッチメントはイベント属性とプロセスアクティビティのギャップを埋め、何が起きたかだけでなく、プロセス全体でデータがどのように変遷したかを完全に把握することを可能にします。

よくある用途

  • 受注ステータスが「Pending」から「Processing」「Complete」へ変わったときに「Status Updated」アクティビティを作成
  • チケットの優先度がエスカレーションまたは逆エスカレーションされたときに「Priority Changed」アクティビティを生成
  • ケース処理中に担当者が変更されたときに「Owner Reassigned」アクティビティを追跡
  • クレジットリスク評価が更新されたときに「Risk Level Changed」アクティビティを監視
  • 出荷品が倉庫や配送センター間で移動したときに「Location Updated」アクティビティをキャプチャ
  • 多段階承認プロセスで承認レベルが変わったときに「Approval Stage Advanced」アクティビティを記録
  • 見積交渉中に商品価格が変更されたときに「Price Adjusted」アクティビティを追跡
  • サポートチケットが部署間で移動したときに「Category Reclassified」アクティビティを生成

設定

New Activity Name: 属性値の変化が起きた際に作成されるアクティビティの名前です。「Status Updated」、「Priority Changed」、「Owner Reassigned」など、どのような変化が起きたかを明確に示す説明的な名前を選んでください。このアクティビティ名はプロセスマップやアクティビティリストに表示されます。

Event Attribute: 変化を監視するイベント属性を選択します。この属性の値が変わるたびにエンリッチメントが新規アクティビティを作成します。ステータスフィールド、担当者名、優先度レベル、カテゴリコード、ロケーション識別子など、任意のイベント属性を指定できます。

Update Activity: 変化を検出するための参照点となる特定のアクティビティです。エンリッチメントは複数のアクティビティ(Change Activitiesで指定)を監視しますが、この設定ではどのアクティビティタイプを「更新」アクティビティとして扱うかを指定します。多くの場合、Change Activitiesのリスト内のいずれかと一致させます。

Change Activities: 属性の変化を監視するアクティビティを一つ以上選択します。属性の変化検出にあたって、この名前のアクティビティのイベントのみを検査します。例えば「Create Order」「Modify Order」「Approve Order」を選択した場合、これらのアクティビティ間で属性値が変わったかをチェックします。

Ignore Case: 有効にすると、null(空白)値を意味のある値として扱い、変化検出の対象にします。無効にするとnull値は無視され、nullを含む変化では新規アクティビティは作成されません。null値が「未割当」や「未設定」など意味のある状態を表す場合は有効にして、実際の値間の変化だけを分析したい場合は無効にします。

例1: 注文ステータス追跡

シナリオ: eコマースのフルフィルメントプロセスで、複数のアクティビティ(Create Order, Payment Received, Ship Order)が注文ステータスを変更しますが、ステータス遷移は明確なアクティビティとして記録されていません。ステータスの進行をプロセスマップで可視化するために、「Status Changed」アクティビティを作成したいです。

設定:

  • New Activity Name: Status Changed
  • Event Attribute: OrderStatus
  • Update Activity: Create Order
  • Change Activities: Create Order, Payment Received, Ship Order
  • Ignore Case: False

結果: OrderStatus属性が指定したアクティビティ間で変化するたびに「Status Changed」アクティビティを作成します。例:

  • ケース開始「Create Order」(OrderStatus = "Pending")
  • 「Payment Received」(OrderStatus = "Paid") - 「Status Changed」アクティビティ作成
  • 「Ship Order」(OrderStatus = "Shipped") - 「Status Changed」アクティビティ作成

プロセスマップに「Status Changed」アクティビティが表示され、ステータス遷移の正確なタイミングが示されるため、各ステータスの滞留時間を測定できます。

インサイト: 実際のステータス変更シーケンスを明示し、遷移遅延を特定し、SLA遵守状況をステータスごとに測定し、特定のステータス進行パターンでフィルタリング可能です。

例2: サポートチケット優先度のエスカレーション

シナリオ: 顧客サポートプロセスで、チケットの優先度がエスカレーションまたは逆エスカレーションされます。優先度属性の変更をすべて追跡し、エスカレーションパターンや対応時間を把握したいです。

設定:

  • New Activity Name: Priority Changed
  • Event Attribute: TicketPriority
  • Update Activity: Create Ticket
  • Change Activities: Create Ticket, Assign Agent, Escalate, Update Ticket, Resolve Ticket
  • Ignore Case: True

結果: 優先度が変更されるたびに「Priority Changed」アクティビティを作成します。例えば、チケットが「Low」から「Medium」、さらに「High」にエスカレートし最終的に解決された場合:

  • LowからMediumへエスカレーション時に「Priority Changed」
  • MediumからHighへエスカレーション時に「Priority Changed」

追加された各アクティビティには元のイベントのすべての属性、新しい優先度値、変更時刻が含まれます。

インサイト: チケットがエスカレーションされる頻度、エスカレーション間の時間、頻繁に優先度変更が必要な顧客や問題タイプを明らかにし、初期優先度設定の最適化に役立ちます。

例3: 出荷ロケーション追跡

シナリオ: 物流プロセスで、出荷品の倉庫間移動は記録されていますが、ロケーションの変化は明確なアクティビティとして追跡されていません。ShipmentLocation属性は移動に伴って変わるため、これらの変化をプロセスフローで可視化したいです。

設定:

  • New Activity Name: Location Updated
  • Event Attribute: ShipmentLocation
  • Update Activity: Receive Shipment
  • Change Activities: Receive Shipment, Transfer Item, Load for Delivery, Deliver
  • Ignore Case: False

結果: ロケーション変更のたびに「Location Updated」アクティビティを作成します:

  • 「Warehouse A」に到着(Receive Shipment) - 初期ロケーション設定
  • 「Warehouse B」へ転送(Transfer Item) - 「Location Updated」作成
  • 「Warehouse B」で積込(Load for Delivery) - 変化なし、アクティビティなし
  • 「Customer Site」へ配送(Deliver) - 「Location Updated」作成

プロセスマップに出荷の移動経路が示され、分配ネットワークの流れが視覚的に把握できます。

インサイト: 出荷ルートを可視化し、転送のボトルネックを特定し、各ロケーションでの滞留時間を測定し、非効率的なルーティングを明らかにします。

例4: 承認ワークフローステージの追跡

シナリオ: 調達承認プロセスで、ApprovalStage属性は「Pending」から「Manager Approved」、「Director Approved」、「Final Approved」へと変遷します。各承認段階の遷移にアクティビティを作成したいです。

設定:

  • New Activity Name: Approval Stage Advanced
  • Event Attribute: ApprovalStage
  • Update Activity: Submit for Approval
  • Change Activities: Submit for Approval, Manager Review, Director Review, Final Approval
  • Ignore Case: False

結果: 各段階の遷移時に「Approval Stage Advanced」アクティビティを作成します:

元のアクティビティ ApprovalStage変更前 ApprovalStage変更後 新規アクティビティ作成
Submit for Approval null Pending いいえ(初期値)
Manager Review Pending Manager Approved はい
Director Review Manager Approved Director Approved はい
Final Approval Director Approved Final Approved はい

インサイト: 承認の進行を明確に示し、承認間の時間を測定し、承認が停滞するポイントを特定、多段階承認の効率分析を可能にします。

例5: インシデント管理におけるケース担当者変更

シナリオ: ITインシデント管理プロセスで、ワークロードやエスカレーションに応じてケースが担当者間で再割り当てされます。AssignedTo属性は変化しますが、この再割り当ては明確なアクティビティとしては追跡されていません。再割り当てのパターンを把握したいです。

設定:

  • New Activity Name: Case Reassigned
  • Event Attribute: AssignedTo
  • Update Activity: Create Incident
  • Change Activities: Create Incident, Assign, Reassign, Escalate, Resolve
  • Ignore Case: True

結果: AssignedToが変更されるたびに「Case Reassigned」アクティビティを作成します:

  • Create Incident(AssignedTo = "Auto-Assignment Queue") - 初期割当
  • Assign(AssignedTo = "John Smith") - 「Case Reassigned」作成
  • Reassign(AssignedTo = "Sarah Jones") - 「Case Reassigned」作成
  • Escalate(AssignedTo = "Senior Team") - 「Case Reassigned」作成

担当者のすべての変更を追跡し、誰がいつケースを扱ったかを可視化します。

インサイト: ケースの再割り当て頻度を明確にし、頻繁な再割り当てが必要な過負荷エージェントを特定し、担当交代の遅延を測定し、初期割当戦略の最適化を支援します。

出力

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

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

  • Activity Name: 「New Activity Name」設定に一致します
  • Timestamp: 属性変化が起きたイベントのタイムスタンプを継承します
  • Case ID: 元のイベントと同じ(同一ケースに追加)
  • Event Attributes: 元のイベントのすべての属性をコピー
  • Activity Type: プロセスマップおよびアクティビティリストに表示される標準アクティビティ

作成ロジック:

  • 監視対象属性値が変化した場合のみ新規アクティビティを作成
  • 最初のアクティビティ発生時は初期値を設定し(更新アクティビティは作成しない)
  • 以降は前回値と比較
  • 値が異なれば新しいアクティビティを同じタイムスタンプで挿入
  • 「Ignore Case」が無効の場合、null値を含む変化は無視
  • 「Change Activities」に一致するイベントのみ監視

統合ポイント:

  • プロセスマップに属性変化のフローとして新規アクティビティが表示
  • 特定の変更パターンを含むケースのフィルタに利用可能
  • 期間計算など後続エンリッチメントで活用可能
  • バリアント分析で異なる変更シーケンスを特定可能
  • アクティビティ頻度統計、パフォーマンス指標に含まれる
  • イベントログのエクスポートに、元の属性すべてとともに出力される

プロセスマップの視覚化: 新規アクティビティによりプロセスマップに追加ノードが生成され、これまで隠れていた状態遷移が明示的に表示され、通常のプロセスアクティビティとともに分析可能になります。

パフォーマンス考慮事項:

  • 監視対象のすべてのイベントを処理して変化を検出
  • 大規模データセットでは変更が予想されるアクティビティに限定することを検討
  • 新規アクティビティの追加によりイベント数が増加し、プロセスマップの複雑さに影響することあり
  • 必要に応じて特定の変更タイプにフォーカスするフィルターを活用

関連

  • Remove Activities: プロセスログから不要なアクティビティを削除
  • Remove Repeated Activities: 連続する同一アクティビティを統合
  • Representative Case Attribute: 特定アクティビティから属性値をケースレベルに抽出
  • Duration Between Two Activities: 元アクティビティと更新アクティビティ間の時間測定

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