ケース属性からアクティビティを追加

概要

ケース属性に格納されたタイムスタンプ値に基づいてイベントログに新しいアクティビティを作成する「ケース属性からアクティビティを追加」エンリッチメントです。この強力な変換エンリッチメントにより、マイルストーン日付、期限のタイムスタンプ、その他の日付ベースのケース属性を、プロセスマップ、バリアント、タイムラインの可視化に表示されるアクティビティへ変換できます。

「期待納期日」「契約開始日」や「保証期限」などの重要なプロセスマイルストーンがケースレベルの属性として保存されている場合に、実際のプロセスアクティビティと併せて分析したい時に不可欠なエンリッチメントです。これらのタイムスタンプをアクティビティに変換することで、計画されたタイムラインと実際のタイムラインのずれを測定し、期限に対する遅延を特定し、時間に基づくプロセスの挙動についてより深い洞察を得ることができます。

エンリッチメントは新しいアクティビティをケース属性で指定された正確なタイムスタンプに配置し、自動的に既存のアクティビティの時系列に組み込みます。これにより、属性に基づくマイルストーンと実際のアクティビティの間の期間を計算し、期待日より前または後に発生したケースを特定し、計画と実際のプロセス実行の関係を可視化できます。

主な用途

  • 期待納期日をアクティビティに変換し、納期遵守のパフォーマンスを測定する
  • 契約開始日やSLA期限をプロセスマップの目に見えるマイルストーンに変換する
  • 計画完了日からアクティビティを作成し、計画対実績のタイムラインを比較する
  • 予約時間やスケジュール日付をアクティビティに変換し、予約遵守の分析を行う
  • 保証期限をプロセスフローに挿入し、保証後サービスアクティビティを特定する
  • チェックイン時間や登録タイムスタンプをプロセスアクティビティに変換し、出席追跡を行う
  • プロジェクトフェーズ期限からマイルストーンアクティビティを作成し、スケジュール遵守を追跡する
  • 約束した顧客納期をアクティビティに変換し、約束履行状況を測定する

設定

日時属性列名: 変換したいタイムスタンプを含むケース属性を選択します。この属性はDateTime型である必要があります。エンリッチメントはこの属性のタイムスタンプ値を新しいアクティビティの発生時間として使用します。該当ケースの属性値がnullの場合、そのケースにはアクティビティは作成されません。

新しいアクティビティ名: 作成される新しいアクティビティの名前を入力します。この名前はプロセスマップ、バリアント分析、アクティビティリストに表示されます。「期待納期日」「SLA期限」「契約開始日」など、アクティビティの内容を明確に示す記述的な名前を選択してください。既存のアクティビティと混同しないように区別可能な名前にしてください。

新しいアクティビティ表示名: レポートやビジュアルで異なる名前として表示したい場合に、ユーザーフレンドリーな表示名をオプションで指定します。指定しない場合は「新しいアクティビティ名」が表示名として使用されます。

期待される順序: プロセスモデル上でこのアクティビティが期待される順序の位置を数値で指定します。この値は適合性検査やバリアント比較において、プロセスフロー上の論理的な位置を理解するために使用されます。たとえば、期限が特定のアクティビティの後に発生すべき場合は、プロセスモデルに基づき適切な順序番号を割り当てます。

例

例1: 納期遵守分析

シナリオ: EC企業が顧客注文の約束納期をケース属性で管理しています。約束納期日をプロセスマップ上のアクティビティとして可視化し、実際の配送が約束日より前か後かを判別し、配送パフォーマンスを測定し問題のある履行パターンを特定したいと考えています。

設定:

  • 日時属性列名: "Promised_Delivery_Date"
  • 新しいアクティビティ名: "Promised Delivery Deadline"
  • 新しいアクティビティ表示名: "Expected Delivery"
  • 期待される順序: 150

出力: 「Promised_Delivery_Date」属性に指定されたタイムスタンプで、それぞれの注文に対して「Promised Delivery Deadline」という新しいアクティビティが作成されます。プロセスマップ上で、このアクティビティは「Package Shipped」や「Delivery Complete」と並んで表示されます。

エンリッチメント前のケースデータ例：

  • ケースID: ORD-5423、Promised_Delivery_Date: 2024-03-15 17:00:00
  • アクティビティ: 注文受付（3月10日）、支払確認（3月10日）、発送（3月12日）、配送完了（3月16日）

エンリッチメント後：

  • アクティビティ: 注文受付（3月10日）、支払確認（3月10日）、発送（3月12日）、Promised Delivery Deadline（3月15日 17:00）、配送完了（3月16日）

洞察: 「Promised Delivery Deadline」から「Delivery Complete」までの期間を計算することで遅延配送を特定できます。分析結果では、約23%の配送が約束期限を過ぎており、その多くは西海岸倉庫からの注文であることが分かります。この結果は問題の物流センターに対する改善施策の立案に役立ちます。

例2: ITサポートのSLA監視

シナリオ: ITサポート部門ではチケット優先度に応じたサービスレベル合意（SLA）があります。チケットごとに計算されたSLA期限がケース属性として管理されており、これをアクティビティとして挿入し、SLA遵守状況を監視、期限超過直前のチケットを特定したいと考えています。

設定:

  • 日時属性列名: "SLA_Deadline"
  • 新しいアクティビティ名: "SLA Response Deadline"
  • 新しいアクティビティ表示名: "SLA Deadline"
  • 期待される順序: 50

出力: 各チケットに対して、SLA_Deadline属性のタイムスタンプで「SLA Response Deadline」アクティビティが作成されます。この期限アクティビティは実際のサポートアクティビティの時系列に含まれます。

ケースデータ例：

  • チケットID: TKT-8821、優先度: 高、SLA_Deadline: 2024-06-20 14:30:00
  • アクティビティ: チケット作成（6月20日 10:00）、自動割当（6月20日 10:05）、SLA Response Deadline（6月20日 14:30）、初回対応（6月20日 15:15）、チケット解決（6月21日 09:00）

洞察: 「初回対応」が「SLA Response Deadline」以降に発生しているケースを抽出することでSLA違反が簡単に特定できます。分析では18%の高優先度チケットがSLA違反を起こしており、多くは人員不足のピーク時間帯（12時～14時）に集中していることが明らかになりました。これによりピーク時間帯の増員要請に説得力が増します。

例3: 契約マイルストーン追跡

シナリオ: プロフェッショナルサービス企業が長期顧客契約の複数マイルストーン（日付）をケース属性で管理しています（契約開始日、初回納品期限、第2納品期限、契約終了日）。これらマイルストーン日をアクティビティとして可視化し、計画された契約スケジュールと実際の作業を比較したいと考えています。

設定（異なるマイルストーンごとに4回実行）：

設定1:

  • 日時属性列名: "Contract_Start_Date"
  • 新しいアクティビティ名: "Contract Start Milestone"
  • 期待される順序: 10

設定2:

  • 日時属性列名: "Deliverable_1_Due_Date"
  • 新しいアクティビティ名: "Deliverable 1 Deadline"
  • 期待される順序: 50

設定3:

  • 日時属性列名: "Deliverable_2_Due_Date"
  • 新しいアクティビティ名: "Deliverable 2 Deadline"
  • 期待される順序: 100

設定4:

  • 日時属性列名: "Contract_End_Date"
  • 新しいアクティビティ名: "Contract End Milestone"
  • 期待される順序: 200

出力: 保存された期限に基づき4つのマイルストーンアクティビティがそれぞれの契約に対して作成されます。これらは「要件収集」「設計レビュー」「Deliverable 1 提出」などの実際の作業アクティビティとともにタイムラインに表示されます。

契約C-445のケースデータ例：

  • エンリッチメント前: 要件収集（1月5日）、設計レビュー（1月20日）、Deliverable 1 提出（2月10日）、テスト完了（2月25日）、Deliverable 2 提出（3月8日）
  • エンリッチメント後: Contract Start Milestone（1月1日）、要件収集（1月5日）、設計レビュー（1月20日）、Deliverable 1 Deadline（2月5日）、Deliverable 1 提出（2月10日）、テスト完了（2月25日）、Deliverable 2 Deadline（3月1日）、Deliverable 2 提出（3月8日）、Contract End Milestone（3月15日）

洞察: 実際作業と契約期限との整合性が可視化され、Deliverable 1 は5日遅れ、Deliverable 2 は7日早期提出であったため、全体としては契約期限内完了となっています。この分析により、どの種類の納品物が継続的に遅延しやすいかが特定でき、見積もり精度向上に役立ちます。

例4: 医療予約遵守分析

シナリオ: 医療クリニックで患者予約時間をケース属性として保存しています。予約された時間をアクティビティとして作成し、患者が診察を受けるまでの待ち時間を測定し、予約遅延のパターンを把握したいと考えています。

設定:

  • 日時属性列名: "Scheduled_Appointment_Time"
  • 新しいアクティビティ名: "Scheduled Appointment"
  • 新しいアクティビティ表示名: "Appointment Time"
  • 期待される順序: 20

出力: 患者が予約された正確な時間に「Scheduled Appointment」アクティビティが作成され、実際の「Patient Called to Exam Room」との比較が可能になります。

ケースデータ例：

  • 患者訪問 PV-9923、Scheduled_Appointment_Time: 2024-09-12 10:00:00
  • アクティビティ: 患者受付（9:45）、Scheduled Appointment（10:00）、診察室呼出（10:23）、医師入室（10:30）、訪問完了（10:52）

洞察: 「Scheduled Appointment」から「Patient Called to Exam Room」までの期間を計算し、平均18分の遅延があることが分かりました。午前の予約（8～10時）は比較的時間通りで、午後に進むにつれ遅れが拡大する傾向があり、スケジュール調整の必要性を示唆しています。

例5: 製造業の生産計画

シナリオ: 製造業者が生産案件ごとに計画開始日をケース属性で管理しています。この計画開始日時をアクティビティとして挿入し、計画と実際の生産スケジュールを比較し、遅延案件を特定したいと考えています。

設定:

  • 日時属性列名: "Planned_Production_Start"
  • 新しいアクティビティ名: "Planned Start Date"
  • 新しいアクティビティ表示名: "Scheduled Start"
  • 期待される順序: 15

出力: 各生産案件に対して「Planned_Production_Start」属性のタイムスタンプで「Planned Start Date」アクティビティが作成されます。

ケースデータ例：

  • ジョブID: JOB-3391、Planned_Production_Start: 2024-11-05 06:00:00
  • アクティビティ: 資材依頼（11月1日）、資材受領（11月3日）、Planned Start Date（11月5日 6:00）、生産準備（11月6日 8:00）、生産開始（11月6日 9:30）、品質チェック（11月7日）、生産完了（11月7日）

洞察: 「Planned Start Date」と「生産開始」の間の遅延を計測し、34%の案件が24時間以上遅れて開始していることが判明。遅延原因の60%は資材遅延、25%は設備の可用性問題であることが特定され、資材計画や設備保全の改善に役立てられます。

出力

「ケース属性からアクティビティを追加」エンリッチメントは、イベントログに新しいイベント行を作成します。

新しいアクティビティレコード: 指定された日時属性に非null値がある各ケースについて、新しいイベント行が作成され、以下を含みます：

  • アクティビティ名: 「新しいアクティビティ名」設定で指定した名前
  • タイムスタンプ: 選択したケース属性のDateTime値
  • ケース関連付け: 元の属性と同じケースに紐付け
  • 期待順序: 適合性検査やバリアント分析のために指定した順序値

データタイプ: 新アクティビティは標準的なイベントログのアクティビティとして扱われ、以下の分析で使用されます：

  • プロセスマップおよびバリアント（時系列で表示）
  • アクティビティ頻度表および統計
  • タイムラインの可視化
  • 期間計算（期間エンリッチメントの開始または終了点として）
  • 適合性検査（期待順序値を利用）

Null処理: 指定した日時属性がnullまたは空のケースには新アクティビティは作成されません。したがって、元のケース総数に対して新しいアクティビティ数は少なくなる可能性があります。

時系列統合: 新しいアクティビティはタイムスタンプに基づき自動的に正しい時系列に配置され、遅いアクティビティの前、早いアクティビティの後に表示されます。これにより正確な期間計算とプロセスフローの可視化が保証されます。

複数回のエンリッチメント: 異なる元属性を指定して複数回実行可能で、データセット内の複数の期限日属性から複数のマイルストーンアクティビティを作成できます（契約マイルストーントラッキング例参照）。

他のエンリッチメントとの連携: 新しく作成したアクティビティは以下で使用可能です：

  • マイルストーンと実際のアクティビティ間の時間計算用の期間エンリッチメント
  • 適合性検査用にマイルストーンの順序を検証する適合性エンリッチメント
  • マイルストーン関連パターンでケースをセグメント化するためのアクティビティフィルター
  • 計画と実績の差異解析用の計算機

関連項目

関連アクティビティエンリッチメント:

関連属性エンリッチメント:

関連トピック:

  • プロセスディスカバリー - マイルストーンアクティビティ追加後のアクティビティフロー理解
  • タイムライン分析 - 計画と実際のアクティビティの時間的関係の可視化

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