メインコンテンツまでスキップ
同じ店舗欠品の事象をデータ洞察の側から捉えます。一言の質問で全店舗の在庫分布を引き出し、Mimir が棒グラフで余剰のある店舗と欠品店舗を示し、在庫移動の判断材料にします。

ケーススタディ：在庫を回せる店舗を見つける

《店舗欠品 → 店舗間在庫移動》は Odin 側から、管理者が在庫移動 Agent をどう構築するかを扱います。Sindri の記事は、業務担当者がチャット画面で移動伝票をどう承認するかを扱います。本記事が扱うのは、その判断の前段です。全店舗の在庫が実際にどう分布し、どの店舗が本当に在庫を回せるのかです。

信義旗艦店の聯名鈦保溫瓶が明日欠品します。在庫を移動するにはまず余裕のある店舗を知る必要があり、その答えは十数店舗の在庫データに散らばっています。小売プロジェクトの POS 店舗セマンティックモデルにそのデータがあり、各店舗・各商品の現在庫、安全在庫、日平均販売数が含まれます。

一言で全店舗の在庫分布を引き出す​

運用担当者は Mimir のホーム画面で POS 店舗セマンティックモデルを選び、次のように入力します。

各店舗の聯名鈦保溫瓶の現在庫と安全在庫はそれぞれいくらですか。安全在庫を上回り、余剰を移動できる店舗はどこですか。各店舗の現在庫を棒グラフで示してください

質問の中で棒グラフを明示することで Mimir はグラフを描きます。指定しなければ既定では文章とデータ表のみが返ります。送信後、7 つのステップが実行されました。利用可能なセマンティックモデルの照会、在庫テーブルの構造と列の把握、照会の検証、各店舗の現在庫と安全在庫の取得、表の整理、対話の命名、そして最後にグラフの描画です。

Mimir の回答。移動可能な店舗と欠品店舗の 2 つの表、および移動の提案

回答は店舗を 2 つのグループに分けました。移動可能な店舗は 11 店です。板橋店は現在庫 80 件に対し安全在庫 24 件で、余剰 56 件と最多です。竹北店は 60 件対 24 件で余剰 36 件と次に多く、屏東店は余剰 15 件です。その他、新莊宏匯店、花蓮店、員林店はそれぞれ約 9 件、台南西門店と台中店は余裕が 2 件しか残っていません。欠品店舗は 1 店のみで、信義旗艦店は現在庫 6 件に対し安全在庫 40 件、不足は 34 件です。

Mimir はさらに提案も直接示しました。板橋（余剰 56）と竹北（余剰 36）から優先的に移動して信義旗艦店の 34 件の不足を補うこと、2 店の余剰は合計 92 件あり余裕は十分だという内容です。これが Odin のケーススタディで実際に発行された 3 枚の移動伝票の根拠です。

グラフで余裕の分布を確認する​

結果カードの View chart をクリックして右側のパネルを開き、Visualization タブに切り替えるとその棒グラフが表示されます。

棒グラフ。各店舗の現在庫を多い順に並べ、青は安全在庫を上回る店舗、オレンジは安全在庫を下回る信義旗艦店

色だけで状況が分かります。青は在庫が安全水準を上回る店舗で、オレンジは 1 本だけ、欠品している信義旗艦店です。棒は長い順に並ぶため、余裕が板橋と竹北の 2 店に集中していることが一目で分かります。それ以降の店舗は余剰があっても 1 桁で、7〜8 店に分けて移動しても物流コストが増えるだけで、得られる数量はわずかです。

パネルの SQL Query タブでは Mimir が生成した照会を確認でき、Data Preview タブでは元のデータ行を確認できます。

チャートとして保存し継続的に追跡する​

欠品期間中の在庫は毎日変わるため、このグラフは一度質問して終わりではありません。パネルの Create View をクリックし、Save current view ダイアログで Visualization を先ほどの棒グラフに設定し、名前を付けて保存します。

Save current view。表示形式を棒グラフに設定し、SQL とともに保存

保存された View には背後の SQL が含まれるため、ダッシュボードに追加して他の欠品追跡指標と並べ、以降はボードを見るだけで済みます。方法は Dashboard を参照してください。

回答をチームの慣習に沿って安定させる​

上の質問が一度で通ったのには前提があります。store_inventory テーブルには store_id と store_name、sku と sku_name の両方があり、不足分をどの 2 列の差で求めるかもデータ自身が決めることではありません。これらの取り決めを Knowledge に書いておけば、Mimir は回答時にそのまま踏襲し、毎回質問の中で説明し直す必要がなくなります。このケースでも回答の冒頭で、保存済みの照会に従い SKU-8801 を対象として SQL を検証してから実行したと説明しています。

このケースが示すこと​

  • 信義旗艦店が 34 件不足していると分かっても、どう補うかは決められません。本当に問うべきは、どの店舗が在庫を回せるかです。今回の答えは、余剰のある店舗は 11 店あるが、板橋と竹北だけで 92 件を占め、残り 9 店を全部合わせても 60 件に届かず、しかも多くは 1 桁だということです。したがって妥当な判断はこの 2 店に絞ることで、7〜8 店に分けて移動しても物流コストが増えるだけです。
  • グラフが必要なら質問の中で棒グラフと明記します。書かなければ Mimir は文章と表しか返さず、View として保存するときに選べる表示形式も、実際に描いたものだけになります。
  • 毎日変わる数値を毎日質問し直す必要はありません。View として保存して Dashboard に置けば、ボードを開くだけで最新の状態が見えます。一度きりの探索だけを Thread に残します。
  • 不足分は安全在庫から現在庫を引いたもの、店舗はコードではなく名前で表示する、といったものはチームの取り決めであり、データが Mimir に教えてくれるわけではありません。Knowledge に書いておけば毎回そのとおりに従うため、質問ごとに説明し直す必要はありません。