日付の異常値検出
概要
Find Date Outliers 計算機は、イベントログ内の通常の範囲外にある日付およびタイムスタンプの値を特定し、プロセス分析に影響を及ぼす前にデータ品質の問題を検出するのに役立ちます。この専門のデータ品質計算機は、イベントログ全体のすべての日付およびタイムスタンプ属性を自動的にスキャンし、昔すぎる日付、未来すぎる日付、またはゼロ値など、明らかに無効な値を検出します。
手動によるデータ検査とは異なり、この計算機はプロセスデータ内のすべての日付フィールドを体系的に調査し、不正なアクティビティのタイムスタンプ、誤ったデータインポート、または更新されていないデフォルトのプレースホルダー値のような、プロセスマイニング分析を歪める可能性のある問題を強調表示します。
主な用途
- レガシーシステムや新しいデータソースからイベントログをインポートした後のデータ品質検証
- 未入力を示すプレースホルダー日付やデフォルト値の検出
- システムクロックの誤りやタイムゾーン変換の問題による不可能なタイムスタンプの特定
- 本番イベントログに誤って混入したテストデータの日付の検出
- タイムスタンプが予想される業務期間内にあるかの検証
- 詳細分析の前にすべての属性の日付フィールドの全体的な品質の迅速な評価
設定
この計算機は設定が不要です。イベントログ内のすべての日付およびタイムスタンプ属性を自動的に調べ、非現実的または問題のある日付と見なされる基準に基づき異常値を識別します。
標準フィールド:
- Title: 計算機出力の任意のカスタムタイトル
- Description: ドキュメント目的の任意説明文
検出ルール:
計算機は以下の条件で日付の異常値を識別します：
- 1990年以前の日付: 1990年1月1日より前の値はデータエラーまたはプレースホルダーと考えられます
- 2040年以降の日付: 2040年1月1日を超える値は現行の業務には非現実的です
- ゼロまたはヌルの日付: 欠損、ヌル、またはゼロのタイムスタンプ値は未完了のデータを示します
- 無効な日付フォーマット: 正しく解析できない不正な日付値
事例
事例 1: レガシーシステム移行の検証
シナリオ: 組織は20年前のレガシーERPシステムから最新プラットフォームに請求処理データを移行しました。プロセスマイニング分析の実施前に、すべての日付フィールドが正しく変換され、データセットにプレースホルダーやデフォルト日付が残っていないことを確認したい。
設定:
- Title: "請求データ移行の検証"
- Description: "レガシーシステムからの変換問題のチェック"
出力:
計算機は属性別に問題のある日付値をグループ化したテーブルを生成します。各行は異常値が検出された特定の属性を示します：
| 属性名 | 異常値数 | 例示異常値 | 問題の種類 |
|---|---|---|---|
| Invoice_Date | 847 | 1900-01-01 | 1990年以前 |
| Payment_Due_Date | 847 | 1900-01-01 | 1990年以前 |
| Last_Modified_Date | 23 | 2099-12-31 | 2040年以降 |
| Approval_Timestamp | 156 | NULL | ゼロ/ヌル |
インサイト:
この出力は移行に関連する重大なデータ品質問題を明らかにしました。1900年1月1日の日付を持つ847件の請求は、適切に変換されなかったレガシーシステム由来のプレースホルダー値であり、この日付は古いシステムでのデフォルトの「空」値として一般的に使われていました。Last_Modified_Dateに2099年の日付がある23件は誤って本番に混入したテストレコードと推察されます。Approval_Timestampが156件もヌルであることは、重要なプロセスタイミング情報が欠落している未完了レコードを示しています。
分析を行う前に次のことを実施するべきです：
- データチームと協力して847件のプレースホルダー日付を持つレコードを修正または削除
- 2099年の日付の23件のテストレコードを除外
- なぜ156件の請求が承認タイムスタンプを欠くのか調査
この検証により、汚染された日付データに基づく請求処理時間や承認パターンに関する誤った結論を回避できました。
事例 2: システムクロックの問題検出
シナリオ: 注文履行プロセスで一部のタイムスタンプが整合性を欠いているという報告があり、処理イベントの順序がおかしい可能性があります。サーバーのクロック同期問題やタイムゾーン変換のバグが疑われています。
設定:
- Title: "注文履行のタイムスタンプ検証"
- Description: "クロック同期またはタイムゾーン問題の特定"
出力:
活動タイムスタンプフィールドで異常値が示されました：
| 属性名 | 異常値数 | 例示異常値 | 問題の種類 |
|---|---|---|---|
| Activity_Timestamp | 1,247 | 2043-08-15 14:23:00 | 2040年以降 |
| Event_Start_Time | 1,247 | 2043-08-15 14:23:00 | 2040年以降 |
インサイト:
すべての1,247件のイベントタイムスタンプは2043年8月と、ちょうど20年先の日付になっています。これは、アプリケーションサーバーのいずれかのシステムクロック誤設定、または時間単位の変換ミスで数十年先の日時を付加したために起きる典型的な問題です。Activity_TimestampとEvent_Start_Time両方で同一数の異常値と同値があることから、複数のフィールドで同じイベントが捕捉されていることが確認されます。
調査により、倉庫管理システムのサーバーがメンテナンス後に誤った時計設定となり、そのサーバーを通じて処理された6時間分のすべてのイベントに20年先の日付が付与されたことが判明。これら1,247件のイベントはピッキング、梱包、出荷など重要な注文処理であり、正しいタイムスタンプに修正する必要があります。
この計算機がなければ、タイムスタンプの誤りによりプロセスマップのイベント順序が完全に崩れ、影響期間の注文履行パフォーマンスを正確に分析できませんでした。
事例 3: 分析前のデータ品質チェック
シナリオ: 過去3年間の購買から支払いまでのプロセスを包括的にプロセスマイニング分析する予定です。詳細分析の前のベストプラクティスとして、Find Date Outliers 計算機を実行し、データセットがクリーンかどうかを確認します。
設定:
- Title: "購買-to-支払い データ品質スキャン"
- Description: "分析前の検証チェック"
出力:
計算機はすべての属性で有効な日付範囲を持ち、異常値が検出されなかったことを示す表を返します。
結果: いかなる日付属性にも異常値なし
インサイト:
これは最良の結果であり、日付データの健全性が証明されました。イベントログ全体のすべてのタイムスタンプおよび日付フィールドを検査し、1990年以前、2040年以降、またはヌル・ゼロ値のいずれも発見されませんでした。これにより以下の点が保証されます：
- すべてのタイムスタンプは活動発生時刻を正確に反映している
- プレースホルダー日付が時間ベースの指標を歪めることはない
- テストデータが誤って本番データに混入していない
- データ収集期間中のシステムクロックは正しく同期されていた
これによりプロセスマップの時間的順序、期間の計算精度、時間ベースの洞察の信頼性を信頼して進めることができます。前もってのこの検証が、破損した日付データによる困惑する結果のトラブルシューティングに費やす膨大な時間を節約します。
事例 4: 未完成のデータ入力の特定
シナリオ: 顧客サービスのチケッティングシステムでサポート担当者が一部の日付を手動入力していますが、多数のチケットにタイムスタンプ情報の欠落や不完全さがあり、ケース解決時間分析に影響があると疑っています。
設定:
- Title: "サポートチケット日付の完全性チェック"
- Description: "日付情報が欠落しているチケットの特定"
出力:
| 属性名 | 異常値数 | 例示異常値 | 問題の種類 |
|---|---|---|---|
| First_Response_Date | 3,456 | NULL | ゼロ/ヌル |
| Resolution_Date | 892 | NULL | ゼロ/ヌル |
| Escalation_Date | 12,034 | NULL | ゼロ/ヌル |
| Follow_Up_Date | 8,721 | 1970-01-01 | 1990年以前 |
インサイト:
分析は重大なデータ入力ギャップを明らかにしました。多くのヌル値は担当者が重要な日付を一貫して記録していないことを示しています：
- 3,456件のFirst_Response_Dateなしチケット： これらのケースは応答時間SLA分析に含められません
- 892件のResolution_Dateなしチケット： 解決時間を計算できません
- 12,034件のEscalation_Dateなしチケット： これは問題ありません。ほとんどのチケットはエスカレーションされないため、ヌル値は期待されます
- 8,721件のFollow_Up_Dateに1970-01-01がある： Unixエポック日付(1970年1月1日)はフィールドが適切に設定されなかった古典的なデフォルト値です
最も懸念すべきはFirst_Response_Dateが欠落している3,456件のチケットで、これはチケット総数の15％に相当し、顧客サービスの応答性を測る指標に直接的な影響があります。次の対策を推奨します：
- First_Response_Dateを必須フィールドにするようチケッティングシステムを更新
- 完全な日付入力の重要性について担当者に教育を実施
- 可能な限り手動入力ではなく自動タイムスタンプ取得を検討
- 解決していない892件のチケットを完了ケース分析から除外
この検証によって、欠損データを除外していたためにケース解決指標が過小評価されていたことが明確になり、経営陣に対して実際より楽観的なサポートチームのパフォーマンス評価が報告されていた問題を認識できました。
出力
計算機は異常値を含むすべての日付およびタイムスタンプ属性のデータテーブルを生成します。このテーブルはデータ品質問題の迅速な特定と優先順位付けに役立ちます：
Attribute Name (テキスト): 日付異常値を含むケースまたはイベントの属性フィールド名。問題がどのフィールドにあるかを正確に把握できます。
Outlier Count (数値): この属性で問題の日付値を持つケースまたはイベントの数。数が多いほど深刻なデータ品質問題であり、早急な対応が必要です。
Example Outlier Value (日時): 属性で検出された異常な日付値の一例。問題の性質を理解する手助け（例： "1900-01-01" はプレースホルダー、"2050-01-15" はクロックエラーを示唆）。
Issue Type (カテゴリ): 検出された異常値の種類 - 「1990年以前」、「2040年以降」、または「ゼロ/ヌル」 - プレースホルダー日付、未来の日付、欠損値のいずれかを示します。
インタラクティブ分析:
出力テーブルは完全にインタラクティブで以下が可能です：
- 任意の行をクリックして、その異常値を含む特定のケースに掘り下げる
- Outlier Countでソートして優先的に修正する属性を決定
- 特定の問題タイプに絞ってフィルタリング
- 異常値リストをエクスポートしてデータ品質チームと共有
ベストプラクティス:
- 新規プロセスマイニングプロジェクトの最初のステップとしてこの計算機を実行する
- いかなるデータインポートやシステム移行後にも再度実行する
- プロセスマップ作成やパフォーマンス指標計算の前に異常値を処理する
- 継続的なデータフィードに対して定期的にこの計算機を使用し、品質低下を早期に検出する
注意: 計算機は日付またはタイムスタンプのデータ型を持つ属性のみを調査します。日付を含むテキストフィールドは分析されません。異常値が見つからない場合は「No date outliers detected」と表示され、データ品質が非常に良好であることを示します。
本ドキュメントは mindzie Studio プロセスマイニングプラットフォームの一部です。