日付の外れ値を検出する

概要

Find Date Outliers計算機は、イベントログ内の属性の日付やタイムスタンプ値が通常の範囲を大きく逸脱しているものを特定し、プロセス分析に影響を与える前にデータ品質の問題を検出するのに役立ちます。この計算機は、イベントログ内のすべての日付およびタイムスタンプ属性を調べ、同じフィールド内の他のデータと比べて異常に早いまたは遅い日付値を持つ個別のケースやイベントを検出します。

手動のデータ検査とは異なり、この計算機はプロセスデータ内のすべての日付フィールドを体系的にチェックし、誤ったアクティビティのタイムスタンプ、形式の乱れたデータインポート、更新されなかったデフォルトのプレースホルダー値など、プロセスマイニング分析を歪める可能性のある問題を強調表示します。

主な用途

レガシーシステムや新しいデータソースからイベントログをインポートした後のデータ品質検証
不完全なデータ入力を示すプレースホルダー日付やデフォルト値の検出
不可能なタイムスタンプを生じさせるシステムクロックエラーやタイムゾーン変換問題の特定
テストデータが誤って本番のイベントログに混入した日付の検出
タイムスタンプデータが想定された業務運用期間内に収まっていることの検証
詳細分析前のすべての属性にわたる日付フィールド全体の品質の迅速な評価

設定

この計算機には設定は不要です。イベントログ内のすべての日付およびタイムスタンプ属性を自動的に調査し、それぞれの属性の通常範囲から大きく外れた値を検出してフラグを立てます。

標準フィールド:

Title: 計算機の出力に対する任意のカスタムタイトル
Description: ドキュメント用の任意の説明文

外れ値の検出方法:

各日付またはタイムスタンプ属性に対して、計算機はその属性の実際のデータから上下限値を計算し、その範囲外の値にフラグを立てます。上下限は統計的手法（四分位範囲）で計算されるため、「外れ値」とみなされる範囲は他のデータ相対のものです。固定の年数カットオフはありません。2018年から2024年までの値を持つ属性は、2010年から2020年までの値を持つ属性とは異なる範囲になります。

注記：

Null値はスキップされます。 データ欠損の日付はこの計算機では外れ値としてフラグされません。（欠損値の追跡には別のデータ品質ツールを使用してください。）
日付やタイムスタンプ属性のみが対象です。 たまたま日付を含むテキストフィールドは処理されません。
変動がほとんどない属性は外れ値を検出しません。 もし属性内のすべての値が密集していれば、「典型範囲外」と言える意味のある外れ値はありません。

例

例1：レガシーシステム移行の検証

シナリオ： 最近、組織は20年前のレガシーERPシステムから最新プラットフォームへ請求書処理データを移行しました。プロセスマイニング分析を行う前に、すべての日付フィールドが妥当な範囲にあるか、特に1900-01-01のようなプレースホルダー日付が変換されていないかを確認したいです。

設定:

Title: 「請求書データ移行検証」
Description: 「レガシーシステムからの日付変換問題の検査」

表示される内容:

この計算機は外れ値の行一覧を返します。レガシーシステムは1900-01-01をデフォルトの「空の」値として使用していたため、それらの行は典型的な請求日範囲から大きく下回るものとしてCase Outliers表に表示されます。さらに、2099-12-31の日付が付いたテストレコードも典型範囲から大きく外れて上方に現れます。

洞察:

出力結果は多くの請求書が実際の日付ではなくレガシープレースホルダー日付を持っていることを示します。また、遠い将来の日付を持つ少数の記録もあり、移行前にクリーニングされなかったテストデータの存在を示唆します。プロセス分析を行う前に、データチームと協力して:

プレースホルダー日付のレコードを修正または削除
遠い将来の日付のテストレコードをフィルタリング

これを行うことで、破損した日付データに基づいて請求処理時間に関する誤った結論を導くのを防げます。

例2：システムクロック問題の検出

シナリオ： 注文履行プロセスの一部で、アクティビティの時系列が不整合であるとの報告を受けています。サーバーのクロック同期エラーやタイムゾーン変換の問題がイベントタイムスタンプに影響を与えている可能性があります。

設定:

Title: 「注文履行タイムスタンプ検証」
Description: 「クロック同期またはタイムゾーン問題の特定」

表示される内容:

Event Outliers表には、アクティビティのタイムスタンプが他のデータから大きく外れているイベントが一覧で表示されます。例えば、20年先の日付が付いた複数のイベントなどです。各行にはケースID、アクティビティ名、問題のあるタイムスタンプが示され、影響を受けたワークフローステップの追跡が可能です。

洞察:

多数のイベントが一律のオフセットで将来日付を持つ場合、それは典型的なシステムクロックエラーや上流システムのタイムゾーン変換バグの兆候です。調査は通常、メンテナンス中に時計がずれた単一のサーバーに辿り着きます。外れ値行を掘り下げることで、どのワークフローステップのタイムスタンプを修正すべきか特定できます。

例3：事前分析のデータ品質チェック

シナリオ： 過去3年にわたる購買から支払いまでのプロセスマイニング分析を実施する準備として、Find Date Outliers計算機をまず実行します。

設定:

Title: 「購買から支払いまでのデータ品質スキャン」
Description: 「事前分析の検証チェック」

表示される内容:

計算機はログ内のすべての日付属性を調査し、外れ値行はありません。Case OutliersおよびEvent Outliers表は両方とも空です。

洞察:

これは最良の結果です。日付データの全属性が密集しており、重大な外れ値がありません。タイムスタンプが時間ベースの指標やプロセスマップの順序付けを歪めることはなく、このまま分析を進めて問題ありません。

出力

計算機は2つのデータテーブルを生成します。各行は単一の外れ値（特定のケースまたはイベント）を表し、属性ごとの要約ではありません。

Case Outliers -- ケースレベルの属性値が外れ値としてフラグされた行が1行ずつ:

Case Id (Text): 外れ値を含むケース
Attribute Name (Text): 外れ値が検出されたケース属性名
Date Value (DateTime): 実際に見つかった外れ値の日付値

Event Outliers -- イベントレベルの属性値が外れ値としてフラグされた行が1行ずつ:

Case Id (Text): イベントが属するケース
Activity Name (Text): イベントのアクティビティ名
Activity Time (DateTime): イベント発生日時
Attribute Name (Text): 外れ値が検出されたイベント属性名
Date Value (DateTime): 実際に見つかった外れ値の日付値

属性ごとの外れ値数を集計したい場合（例：「プレースホルダー日付を持つ請求書は何件か？」）、対象のテーブルをダッシュボードでAttribute Nameでピボットしてください。

ベストプラクティス:

新たなプロセスマイニングプロジェクトの最初のステップとしてこの計算機を実行する
データインポートやシステム移行後に再実行する
プロセスマップ作成やパフォーマンス指標計算の前に外れ値を処理する
継続的に流入するデータに対して定期的に利用し、品質の劣化を早期に検知する

注意: この計算機が検査するのは、既に日付またはタイムスタンプ型のデータの属性のみです。テキストフィールドに見えるだけの日付は解析されません。そうしたフィールドを検査したい場合は、事前に日付属性に変換してください。

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