属性に時間を追加する
概要
属性に時間を追加するエンリッチメントは、データセット内の既存のDateTime属性を指定した時間の長さだけ加算または減算して変更します。新しい計算属性を作成するエンリッチメントとは異なり、このエンリッチメントは既存のタイムスタンプフィールドを直接更新するため、タイムゾーンの調整、データ修正、プロセスデータ全体の体系的な時間シフトに非常に有用です。秒、分、時間、日、週、月、年をすべてのDateTime属性に追加するか、変更する属性を選択的に指定できます。
このエンリッチメントは、体系的な時刻記録の誤りを修正したり、夏時間の変更に対応したり、異なるシステムからのタイムスタンプを整合させたり、プロセス全体をシミュレーションや「もしも」分析のために前後に移動したりするときに特に強力です。フィルター機能によって、特定の地域や期間のケースのみのタイムスタンプを調整するなど、選択的な調整も可能です。元のデータ構造を保ちつつ時間値を変更するため、プロセスモデルのすべての関係性や依存性は維持されます。
主な用途
- タイムゾーンの修正：グローバルな運用からのデータを統合する際に、異なるタイムゾーン間でタイムスタンプを調整
- 夏時間の調整：歴史データのDST移行時に発生する欠落・重複時間の補正
- システムクロック誤差の補正：データ収集時のシステムクロックの誤設定によるタイムスタンプの体系的な誤りを修正
- データ移行時の時間調整：異なる時間記録基準のシステム間でプロセスを移行する際のタイムスタンプ整合
- プロセスシミュレーション：テストや「もしも」シナリオ分析のためにプロセス全体を時間軸上で前後に移動
- バッチ処理の調整：実際の発生時間ではなく処理時間で記録されたバッチ処理イベントのタイムスタンプを修正
- 歴史データの整合：異なる時間参照やエポックを使用していたレガシーシステムのタイムスタンプを同期
設定
フィルター: タイム調整の対象とするケースを制限するためのオプションフィルター。フィルターが設定されていない場合、データセット内のすべてのケースの選択されたDateTime属性が変更されます。特定期間、地域、システムのケースなど、特定のデータサブセットに対して調整を適用するためにフィルターを使用できます。特定の場所のタイムゾーン問題の修正や、特定の収集期間だけに影響した誤りの修正に特に役立ちます。フィルターは標準のmindzieフィルターインターフェースを使用し、複雑な条件や組み合わせに対応します。
属性名: 変更するDateTime属性を選択します。デフォルトでは、選択がない場合はケーステーブルとイベントテーブルのすべてのDateTime属性に適用されます。特定の複数属性を選択して、調整対象のタイムスタンプを絞り込むことも可能です。このリストはデータセット内のすべての利用可能なDateTime属性で動的に更新されます。よく使われる選択肢には「Start_Time」「End_Time」「Created_Date」「Modified_Date」や独自のタイムスタンプフィールドがあります。null値はスキップされ、変更されません。
追加値: 選択したタイムスタンプに加算・減算する数値。正の値は時間を進め、負の値は時間を戻します。この値の解釈は「Timespan Duration」設定に依存します。例えば「Hours」を選択して「2」と入力すると全てのタイムスタンプに2時間加算し、「Minutes」で「-30」とすると30分減算します。この値は整数で入力してください。年や月の追加は大幅なプロセスタイムラインの変化を招くため注意が必要です。
期間の単位: 追加値の単位を指定します。選択肢は以下の通りです：
- 秒 (Seconds)：細かな調整や1分未満のタイミング問題の補正に適する
- 分 (Minutes)：小幅な時間修正やクロック差の調整に便利
- 時間 (Hours)：タイムゾーン調整で最も一般的（例：ESTからUTCへの5時間加算）
- 日 (Days)：プロセス全体の移動や日付レベル誤りの修正に使用
- 週 (Weeks)：週次バッチ処理の調整や週単位スケジュールの誤り修正に
- 月 (Months)：長期的なプロセスシフトや会計期間調整に利用
- 年 (Years)：歴史データの整合や大規模な時間変換に利用
例
例1：ESTからUTCへのタイムゾーン変換
シナリオ: ある企業の米国東海岸の業務はすべてEST（UTC-5）でタイムスタンプを記録しているが、中央データウェアハウスではグローバル整合のためUTCでのデータが必要。米国業務からのすべてのタイムスタンプに5時間を加算する。
設定:
- フィルター：
Region = "US-East" - 属性名：（空白のままで全DateTime属性を調整）
- 追加値：
5 - 期間単位：
Hours
出力例: 元のタイムスタンプ：
- Order_Created: 2024-03-15 09:00:00 (EST)
- Order_Approved: 2024-03-15 09:30:00 (EST)
- Order_Shipped: 2024-03-15 14:00:00 (EST)
エンリッチメント後：
- Order_Created: 2024-03-15 14:00:00 (UTC)
- Order_Approved: 2024-03-15 14:30:00 (UTC)
- Order_Shipped: 2024-03-15 19:00:00 (UTC)
すべてのタイムスタンプはUTCに揃えられ、グローバルなプロセス分析が正確に行え、タイムゾーンの違いによる混乱を回避できます。
インサイト: UTCで統一されたタイムスタンプにより、アナリストは地域差に左右されずに正確にプロセスパフォーマンスを比較でき、世界中の運用を統合したダッシュボード作成が可能になります。
例2：夏時間（DST）修正
シナリオ: 2023年3月の歴史データに、夏時間移行に伴う1時間の欠落があり、ソースシステムで正しく処理されていません。2023年3月12日02:00以降のすべてのタイムスタンプを1時間戻す必要があります。
設定:
- フィルター：
Start_Time >= "2023-03-12 02:00:00" - 属性名：
Start_Time,End_Time,Activity_Timestamp - 追加値：
-1 - 期間単位：
Hours
出力例: 誤って記録されたイベント：
- Activity A: 2023-03-12 03:30:00
- Activity B: 2023-03-12 04:15:00
- Activity C: 2023-03-12 05:00:00
修正後：
- Activity A: 2023-03-12 02:30:00
- Activity B: 2023-03-12 03:15:00
- Activity C: 2023-03-12 04:00:00
DSTによる1時間のギャップが修正され、実際の活動の順序と継続時間が回復しました。
インサイト: DST問題の修正により正確な期間計算が可能となり、偽のボトルネックの発生を防止し、時間ベースのKPIやSLA指標の整合性が維持されます。
例3：システム移行による時間整合
シナリオ: システム移行時に、異なるエポックを使用していた旧システムのタイムスタンプを完全に30日進めて、新システムの時間基準に揃える必要があります。
設定:
- フィルター：
Source_System = "Legacy_ERP" - 属性名：（全属性に適用するため空白）
- 追加値：
30 - 期間単位：
Days
出力例: 旧システムの日時：
- Case_Start: 2024-01-01 08:00:00
- First_Approval: 2024-01-02 10:00:00
- Final_Completion: 2024-01-05 16:00:00
整合後：
- Case_Start: 2024-01-31 08:00:00
- First_Approval: 2024-02-01 10:00:00
- Final_Completion: 2024-02-04 16:00:00
旧システムのすべてのタイムスタンプが新システムの時間基準にしっかりと揃い、両システム間のシームレスなプロセス分析が可能になりました。
インサイト: 適切な時間整合により、移行前後のプロセス比較が正確になり、新システムが期待通りのパフォーマンスを維持していることを検証でき、歴史的なトレンド分析の妥当性も保証されます。
例4：バッチ処理の時間修正
シナリオ: バッチ処理システムが全てのイベントをバッチ実行時刻（深夜）に記録しており、実際の発生時間ではありません。イベントをその順序に基づき時間を引いて分散させる必要があります。
設定:
- フィルター：
Batch_Processed = "True" AND Processing_Sequence >= 6 - 属性名：
Event_Timestamp,Activity_Time - 追加値：
-6 - 期間単位：
Hours
出力例: バッチに記録された時間（すべて深夜）：
- Order_Received: 2024-03-15 00:00:00
- Order_Validated: 2024-03-15 00:00:00
- Order_Approved: 2024-03-15 00:00:00
シーケンス6以上のイベント修正後：
- Order_Received: 2024-03-14 18:00:00
- Order_Validated: 2024-03-14 18:00:00
- Order_Approved: 2024-03-14 18:00:00
イベントは実際の発生日に分散されましたが、完全な分散には複数回のエンリッチメント適用が必要になる場合があります。
インサイト: バッチ処理タイムスタンプの修正により、実際のプロセスパターンが明らかになり、正確な期間やスループット計算が可能となり、人工的なバッチ処理のピークを識別できます。
例5：会計年度調整
シナリオ: 企業が会計年度（4月開始）に合わせるためにカレンダー年のすべてのタイムスタンプを3ヶ月進めて、財務プロセス分析を行う必要があります。
設定:
- フィルター：（なし - すべてのケースに適用）
- 属性名：（全属性に適用するため空白）
- 追加値：
3 - 期間単位：
Months
出力例: カレンダー年のタイムスタンプ：
- Q1_Start: 2024-01-01
- Q1_Transaction: 2024-02-15
- Q1_Close: 2024-03-31
会計年度に整合：
- Q1_Start: 2024-04-01
- Q1_Transaction: 2024-05-15
- Q1_Close: 2024-06-30
すべてのタイムスタンプが会計カレンダーに合わせて調整され、正確な財務期間分析と報告が可能に。
インサイト: 会計年度に揃えることで財務チームは会計期間ごとのプロセスパフォーマンスを正確に分析でき、年度ごとの比較や財務報告要件と指標の整合が容易になります。
出力
属性に時間を追加するエンリッチメントは、既存のDateTime属性をその場で変更し、以下の特徴を持ちます：
その場変更: 新しい属性を作るのではなく、既存のDateTime属性の値を直接変更します。属性名、型、構造は変更されず、時間値のみが修正されます。
属性の範囲: 以下の属性に対して変更可能です：
- ケース属性：ケースレベルのDateTimeフィールド
- イベント属性：イベントレベルのDateTimeフィールド
- 特に選択がない場合はすべてのDateTime属性
- 特定の属性を選択した場合はその属性のみ
値の保持: 以下を維持します：
- 日付および時刻の要素（両方適切に調整）
- 元のタイムスタンプの精度（ミリ秒単位も保持）
- null値（変更せずにそのまま）
- データ型（DateTimeはDateTimeのまま）
フィルター適用: フィルターが適用される場合：
- フィルター条件に合うケースのみタイムスタンプを修正
- 条件に合わないケースは元の値を保持
- 一部は変更されたタイムスタンプ、一部は元のままの混在状態のデータセットとなる
計算の詳細:
- 秒/分/時間/日: 時刻に単純加算
- 週: 日数×7として加算
- 月: 月末日を考慮したスマートな処理（例：1月31日＋1ヶ月 = 2月28日または29日）
- 年: うるう年を自動考慮
重要な注意点:
- このエンリッチメントは（現在の分析セッション内で）データを永久に変更します
- 大幅な時間シフトを行う前にデータセットのバックアップやコピー作成を検討してください
- 月・年の加算は存在しない日付（例：2月30日）を適切な有効日付に調整
- 負の値も完全サポートし、時間を過去に戻すことが可能
他の機能との連携:
- 変更したタイムスタンプは即座にすべての時間ベース計算や可視化に影響
- イベント間の期間計算は変更後のタイムスタンプに基づく
- フィルターやダッシュボードでの日時範囲指定は時間変更後に見直しが必要な可能性あり
- 他のエンリッチメントも変更後の新しいタイムスタンプ値を利用するため透明に連携
このドキュメントはmindzie Studioのプロセスマイニングプラットフォームの一部です。