Meridian：部門ファイルから、担当者のいるアクションへ。

Meridian は4つの工場と4つの倉庫を、部門ごとのワークブックで回しています。シフト別の生産実績、購買の管理表、在庫の棚卸し、標準原価表です。部門ごとに自分たちの数字を持っていたため、週次会議は数字をもとに動くのではなく、数字の突き合わせから始まっていました。

誰にもファイルを手放すようには求めませんでした。SAS はファイルをそのまま読み込み、プロジェクトは5つのステージで構成されます。各ステージはプログラムのフォルダーで、すべてのプログラムの横にフローがあります。

19のファイルは、23の生テーブル、12のクレンジング済みテーブル、判断にそのまま使える23のゴールドテーブルになりました。40のクレンジングルールが28,098行を修正しました。テキストで入力された金額、3種類の形式が混在する日付、何通りもの書き方があるシフトコードなどです。ルールはそれぞれ、データ品質ログに1行ずつ記録します。

すべてのプログラムにフローがあるため、SAS Lineage はどのテーブルについても、それを作ったプログラムまでさかのぼり、それを読むレポートまでたどる経路を描けます。

計画担当者の問いはシンプルです。どの倉庫のどの製品が、今後4週間で発注点を下回るのか。Model Studio は同じ特徴量（発注点に対する在庫、輸送中の在庫、直近の出荷、サプライヤーの遅延、季節）で7つの候補モデルを学習し、後半の週はテスト用に学習から除外しました。

学習から除外した週で最もランキング性能が高かった Forest を、チャンピオンとして Model Manager に登録しました。勾配ブースティングはチャレンジャーとして毎週コードで再学習されるため、チャンピオンの性能が落ちれば数字に表れます。

スコアはまだアクションではありません。デシジョン Meridian_next_best_action はチャンピオンモデルを実行し、続いて2つのルールセットを通します。「アクションの選択」（6ルール）は、在庫ポジションに再発注が必要か、発注書の納期督促が必要か、製品に利益率の見直しが必要か、ラインの確認が必要かを決めます。「優先度・担当・レビュー」（14ルール）は、影響額に応じて優先度を設定し、担当者を選び、期限を決め、いつ2人目が確認するかを判断します。

デシジョンは SAS Micro Analytic Service に公開されるため、Web リクエストを送れるものなら何でも、何をすべきかを問い合わせられます。

スケジュールされたジョブが毎週月曜06:00に動きます。Lantern で人が判断し解決した内容を読み戻し、今週の候補アクションを作り、それぞれを公開済みのデシジョンに通し、メッセージを下書きし、先週の結果を測定して、結果を Lantern に送ります。

バッチジョブもほかのすべてと同じ公開済みのデシジョンを呼び出すため、レポート上のアクションと画面上のアクションが食い違うことはありません。デシジョンサービスに接続できない場合、ジョブは停止し、空のリストを公開する代わりに先週のアクションを残します。

Lantern は各アクションに担当者を1人割り当て、SAS がなぜそれを挙げたのかを示します。発動したルール、在庫ポジションについてのチャンピオンの確率、そして優先度・担当者・期限を選んだルールセットです。担当者は仕事をし（サプライヤーに電話する、ラインを確認する、注文を出す）、行ったことを記録して解決します。

見える内容は役割で決まります。購買担当者には発注書が、シフトリーダーには自分のラインが表示され、データベースが行単位でそれを強制します。

ジョブは毎週、解決済みのアクションをその後の結果と照らし合わせます。在庫は切れたか、発注書は期日どおりに届いたか、不良率は下がったか。結果は Lantern に送られ、アクションの横に表示されます。

モデルも同じ方法で評価します。チャンピオン、チャレンジャー、そして在庫水準だけで単純に順位付けする方法を、学習から除外した同じ1,100行でスコアリングします。そのうち138行が4週間以内に欠品しました。