正しいタイムゾーン

概要

正しいタイムゾーンのエンリッチメントは、プロセスマイニングデータセット内のすべてのタイムスタンプをUTC(協定世界時)から指定されたローカルタイムゾーンに自動的に調整します。このエンリッチメントは、複数の地理的地域にまたがるプロセスを分析する場合や、ソースシステムがUTC形式でタイムスタンプを保存しており、正確な分析のためにローカルの営業時間に変換する必要がある場合に不可欠です。

このエンリッチメントは、データセット全体を対象に包括的な変換を実行し、ケース属性およびイベント属性のすべての日付/時刻値を正しいローカルタイムゾーンに変換します。これにより、勤務時間計算、シフト分析、日次・週次のパターンなどの時間ベースの分析が、プロセスが実際に行われているローカルタイムゾーンのビジネス実態を正確に反映します。

よくある利用例

  • グローバルなERPシステムからのUTCタイムスタンプをローカルの営業時間に変換し、正確な勤務時間分析を行う
  • 複数のソースシステムで異なるタイムゾーンの規則を用いるタイムスタンプを、単一の一貫したローカル時間に整合させる
  • 作業時刻を反映したシフトベースの分析の準備
  • プロセスが稼働するタイムゾーンで時間を変換し、正確な営業時間メトリクスを算出
  • 特定の地域タイムゾーンでのタイムスタンプが求められるコンプライアンスレポートのサポート
  • 本社のタイムゾーンにタイムスタンプを標準化し、多地域間のプロセス比較を容易にする
  • システムの時間ではなく、ビジネスユーザーがローカル時間でイベントを見るためにタイムスタンプの表示を正す

設定

このエンリッチメントは、データセットレベルで指定されたタイムゾーン設定を自動的に使用して動作します。エンリッチメント自体に追加設定は必要ありません。

データセットのタイムゾーン: 変換対象となるタイムゾーンは、mindzieStudioでデータセットのインポートまたは設定時に構成されます。エンリッチメントはこの設定を読み取り、すべてのタイムスタンプに一貫して適用します。一般的なタイムゾーンには以下が含まれます:

  • 東部標準時(Eastern Standard Time)
  • 太平洋標準時(Pacific Standard Time)
  • 中央ヨーロッパ時間(Central European Time)
  • グリニッジ標準時(Greenwich Mean Time)
  • オーストラリア東部標準時(Australia Eastern Standard Time)
  • その他、Windows標準のタイムゾーン識別子全般

自動検出: エンリッチメントはデータセット内のすべての日付/時刻列(ケース属性およびイベント属性の両方)を自動的に識別し、UTCから指定されたローカルタイムゾーンへ変換します。日時の時間部分が存在するタイムスタンプのみ変換対象です(日付のみは変換しません)。

すでにローカルの場合はスキップ: データセットがすでにローカル時間に変換済み(IsLocalTimeフラグがある場合)であれば、重複変換を避けるためにこのエンリッチメントは処理をスキップします。

例1:グローバル製造プロセス分析

シナリオ: 多国籍製造企業がドイツ、中国、メキシコに工場を持ち、すべてのタイムスタンプをUTCで保存するSAPシステムに報告しています。ヨーロッパの本社は中央ヨーロッパ時間で生産プロセスを分析し、ビジネス報告に合わせたいと考えています。

設定:

  • データセットのタイムゾーン: Central European Standard Time
  • 追加のエンリッチメント設定は不要

出力: 元のUTCタイムスタンプがCET/CESTに変換されます:

  • UTCイベント: 2024-03-15 14:30:00 → CET: 2024-03-15 15:30:00(冬時間)
  • UTCイベント: 2024-07-15 14:30:00 → CEST: 2024-07-15 16:30:00(夏時間)

注文日時、納品日時、支払日時などのケース属性のタイムスタンプおよびイベントのタイムスタンプはすべて自動的に調整され、8:00〜17:00 CETの勤務時間分析や残業検出が正確に行えます。

知見: 変換後、メキシコ工場の22:00 UTCと表示されていた夜間作業が、実際には現地の午後3時(通常勤務時間)であったことが判明し、誤ったコンプライアンス警告が解消されました。

例2:医療予約スケジューリング

シナリオ: 米国内の3つの異なるタイムゾーンにまたがる病院ネットワーク。中央スケジューリングシステムはすべての予約時間をUTCで管理していますが、現地スタッフは業務計画のために地域のローカル時間で予約を確認したい。

設定:

  • データセットのタイムゾーン: Eastern Standard Time(東海岸分析用)
  • 追加のエンリッチメント設定は不要

出力: 患者の予約関連タイムスタンプがUTCからEST/EDTへ変換されます:

  • 登録日時: 2024-02-20 18:00:00 UTC → 2024-02-20 13:00:00 EST
  • 予約日時: 2024-02-20 19:30:00 UTC → 2024-02-20 14:30:00 EST
  • 退院日時: 2024-02-20 21:45:00 UTC → 2024-02-20 16:45:00 EST

知見: 変換により、多くの予約がUTCの夕方に見えたが、実際は標準営業時間内(9:00〜17:00 EST)に行われていることが判明し、適切な人員配置とリソース割り当てに役立ちました。

例3:金融取引プロセス

シナリオ: 投資会社がグローバルに取引処理を行い、すべてのトランザクションをUTCでログに記録。規制遵守およびパフォーマンス分析のため、NYSE取引時間に合わせてニューヨーク時間(EST/EDT)に変換する必要があります。

設定:

  • データセットのタイムゾーン: Eastern Standard Time
  • 追加のエンリッチメント設定は不要

出力: 取引実行のタイムスタンプがNYSE取引時間に調整されます:

  • 取引開始: 2024-03-10 13:30:00 UTC → 2024-03-10 09:30:00 EDT(市場開始)
  • 取引完了: 2024-03-10 13:31:15 UTC → 2024-03-10 09:31:15 EDT
  • 決済確認: 2024-03-10 20:00:00 UTC → 2024-03-10 16:00:00 EDT(市場終了)

知見: タイムゾーン修正により、平常市場時間中の取引と時間外取引が正確に区別され、手数料計算やコンプライアンスレポートに役立ちました。

例4:Eコマース注文処理

シナリオ: 世界中のフルフィルメントセンターを持つオンライン小売業者が、注文処理時間を本社の営業時間に合わせるために太平洋時間で分析を行いたい。

設定:

  • データセットのタイムゾーン: Pacific Standard Time
  • 追加のエンリッチメント設定は不要

出力: 注文のライフサイクルタイムスタンプがUTCからPST/PDTに変換されます:

  • 注文受付: 2024-08-15 05:00:00 UTC → 2024-08-14 22:00:00 PDT(前日)
  • 支払い処理: 2024-08-15 05:15:00 UTC → 2024-08-14 22:15:00 PDT
  • 倉庫ピッキング: 2024-08-15 15:00:00 UTC → 2024-08-15 08:00:00 PDT
  • 出荷: 2024-08-15 23:00:00 UTC → 2024-08-15 16:00:00 PDT

知見: タイムゾーン変換により、UTCの午前5時に注文されたように見えた注文が実際は前夜の午後10時であることがわかり、夜間の注文増加理由が説明でき、朝の倉庫スタッフ配置の最適化に貢献しました。

例5:ITサービスデスク運用

シナリオ: グローバルITサービスプロバイダが複数地域のインシデント解決時間を分析。ITSMシステムはすべてのイベントをUTCで記録しますが、SLA遵守はローカルの営業時間で測定する必要があります。

設定:

  • データセットのタイムゾーン: GMT Standard Time(英国業務分析用)
  • 追加のエンリッチメント設定は不要

出力: インシデントタイムスタンプがUTCからGMT/BSTに変換されます:

  • インシデント作成: 2024-06-20 08:00:00 UTC → 2024-06-20 09:00:00 BST
  • 初回対応: 2024-06-20 08:45:00 UTC → 2024-06-20 09:45:00 BST
  • エスカレーション: 2024-06-20 11:00:00 UTC → 2024-06-20 12:00:00 BST
  • 解決: 2024-06-20 15:30:00 UTC → 2024-06-20 16:30:00 BST

知見: ローカル時間に変換することで、多くのインシデントが英国の営業時間内(9:00〜17:00 BST)に発生していることが明らかになり、現行シフト体制の妥当性が確かめられ、サポート需要のピーク時間帯が把握できました。

出力

正しいタイムゾーンのエンリッチメントは、データセット内の既存のすべての日付/時刻属性を変更し、新たな列は作成しません。変換の対象は以下の通りです。

ケース属性:

  • ケーステーブルのすべての日付/時刻フィールドがUTCから指定されたローカルタイムゾーンに変換されます
  • 例:ケース開始時刻、ケース終了時刻、注文日、納期、完了日など
  • 時間成分のあるタイムスタンプのみ変換され、日付のみは変更されません

イベント属性:

  • イベントテーブルのすべての日付/時刻フィールドがローカル時間に変換されます
  • プロセスマイニングで主に使用するTimestampフィールドも調整されます
  • 追加のタイムスタンプフィールド(開始時刻、終了時刻、スケジュール時刻など)も変換の対象です

データの整合性:

  • イベントの相対順序は変わりません
  • タイムスタンプ間の継続時間計算は正確に保たれます
  • 重複変換を防ぐために内部でIsLocalTimeフラグが設定されます

連携上の注意点:

  • 変換後は、すべての時間ベースのエンリッチメントや計算処理がローカルタイムで動作します
  • 時間範囲に基づくフィルターはローカル時間で動作します
  • エクスポート機能は変換済みのローカルタイムスタンプを出力します
  • 夏時間(DST)の自動適用も行われます

関連


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