週次の出荷レポートに赤い数値が出ると、理由を急いで説明したくなります。しかし先に確かめるべきなのは、今週と前週が同じ定義で、同じ程度にそろったデータを測っているかです。
Agentには入力確認と計算、例外表の作成を任せられます。指標の定義、調査基準、担当者の決定はチームの仕事です。
比較の契約を一枚に固定する
架空の出荷チームが、利用を許可された注文CSVと出荷イベントCSVを使うとします。実際の導入事例や実施済み試験ではありません。期限超過は「約束した出荷期限を過ぎ、週次締切までに出荷イベントがない注文」。分母は期限が対象週に入る全注文で、未出荷も含めます。キャンセルの除外はチームの明文化した条件に従います。
同じタイムゾーンで、月曜0時から翌月曜0時未満の連続した7日間を比較します。締切、抽出時刻、データ収録範囲、注文ID、約束期限、実出荷時刻を記録します。ダウンロード日は業務日ではありません。出荷データが欠けていれば、イベントがないことだけで遅延とは判定できません。
三つの入力を別の経路に分ける
| 架空の例 | 根拠 | 判定 |
|---|---|---|
| A：データ到着遅れ | 出荷イベントが日曜までしかない | データ欠損。全週の率は出さない |
| B：定義変更 | 返金の帰属が注文週から返金発生週へ変わった | 比較不可。同一定義で再計算 |
| C：業務偏差 | 両期間の入力と定義がそろう | 計算後、チームの基準と照合 |
Aでは不足期間と対象注文IDを示し、欠損値はnullのままにします。0にはしません。前回の完全なレポートは日付を残し、今回の結果として表示しないこと。部分集計を出すなら、その範囲と分母を明示します。
Bでは返金イベント自体が正しくても比較が崩れます。出荷遅延指標とは別に扱い、指標責任者が帰属ルールを決めてから両期間を再計算します。Agentが都合のよい定義を選んではいけません。
Cの架空データを、今週200件中20件、前週200件中8件とします。10%対4%、6ポイント増、12件増です。チームが事前に「5ポイント以上かつ10件以上増えたら調査」と決めていたなら、両条件を満たします。これは例示ルールであり、業界標準でもモデルの既定値でもありません。
原因の物語ではなく例外記録を作る
例外ID、種類、指標、ファイルと行ID、定義版、両期間の値、基準、未確認事項、提供された担当役割、再確認条件、状態を一行にまとめます。担当が指定されていなければ未割当と記録します。
「遅延が12件増えた」は観測です。「配送会社の障害が原因」は注文単位の根拠が必要な仮説です。地域別と端末別の別々の集計を結び付けて因果にしないこと。必要な交差集計を次の確認として提案します。
要約には確認済み偏差、欠損、必要な判断を先に置きます。根拠行と計算は参照可能にします。業務異常がない週にもデータ不足は残り得ます。
手動確認から再利用へ
Budaの運用業務では、定義、許可された入力コピー、日付付きレポート、例外表をDriveに残せます。読む版は指示で指定します。フォルダー名だけではアクセス権を定義できません。
匿名化した過去の一週を手動で確認し、分類、計算、未決事項だけを出させます。通知送信や正式記録の変更は行いません。方法を確認してからSkillにします。Buda AIのMarketplaceで適切なSkillを検索・インストールでき、事前に内容と権限を確認します。自動化は検証した手順を予定実行するためのもので、すべての接続先が設定済みという意味ではありません。
並列成果物の統合とは異なり、ここでは各週の比較の成立条件を扱います。遅延データ到着後はv1を保ち、入力差分と再確認項目を明記したv2を出します。
よくある判断
基準を誰が決める？
業務責任者です。理由、ポイント差、最低件数を事前に記録します。未定なら観測値を示して確認を求め、モデル案を承認済み扱いにしません。
後からデータが届いたら？
新しい入力を別版で保存し、影響する指標と完全性を再確認します。不足が埋まったことと業務異常が見つかったことを別に記録します。
件数が少ない場合は？
分子と分母を必ず示します。5件中1件は20%ですが、まず1件です。チームが決めた最低件数と個別記録を確認します。
入力の一部欠損、定義変更、基準超過の三つを人工的に作り、分岐が正しいか試すとよいでしょう。これは試験案であり結果報告ではありません。