まずお金の話から。
20,000平方メートルの倉庫が1日8,000件の注文を出荷している。昨年オーナーはWMSに約$90,000、OMSにさらに$30,000を投じた。ある朝、オペレーション責任者にこう聞く。「今週は儲かったのか？」答えは「まあまあです。先週よりは良いです」。「どれくらい良い？どの部分が稼いだ？お金はどこから漏れた？」誰も答えられない。WMSはある。OMSもある。すべての数字はシステムの中に眠っている。それなのにオーナーは、金曜の夜に継ぎはぎで作るExcelの週報で今も経営を回し、数字は相変わらず合わない。
倉庫BIダッシュボードがまさにそのためのものだ：毎朝8つの数字、それぞれに出所が明確。これだけ。
私は「デジタル変革ビジョン」とかやらない。二つの計算をする。一つ目：ダッシュボードのない倉庫では、オーナーは月に少なくとも3回、カンで決めざるを得ない——採用するか、値下げするか、この荷主の注文を受けるか。誤った判断は一回あたり少なくとも数万の損失。二つ目：BIの年間コストは、防げる判断ミスの損失より安いか？二つを計算すれば、ダッシュボードを作るべきかは自ずと答えが出る。
倉庫BIダッシュボードの8つの数字——一つ欠けても経営はぼやける
オーナーのダッシュボードに載せる数字はきっかり8つ。それ以外はノイズ。8つともどの倉庫でも測定可能で、定義が厳密だから誰も文句を言えない。
| # | KPI | 一文定義 | 健全な範囲 |
|---|---|---|---|
| 1 | 在庫精度 | 帳簿と実物が一致したSKU ÷ カウントしたSKU | ≥99.5% |
| 2 | 納期遵守率 | カットオフ前に出荷した注文 ÷ 全注文 | ≥98% |
| 3 | 労働生産性 (UPH) | 出荷ユニット数 ÷ 現場労働時間（ピック/パック/検品） | 業種により異なる |
| 4 | 注文あたり履行コスト | 当月の総履行コスト ÷ 出荷注文数 | 前年比で低下傾向 |
| 5 | ロケーション稼働率 | 使用中ロケーション ÷ 利用可能ロケーション | 75%–85% |
| 6 | 返品率 | 返品注文 ÷ 出荷注文 | ECは<8% |
| 7 | 残業比率 | 残業時間 ÷ 総労働時間 | <10% |
| 8 | デッドストック金額 | 90日間動きのない在庫の原価金額 | 前年比で低下傾向 |
なぜこの8つか。在庫精度は土台——帳簿と実物が合わなければ、他の数字は全部フィクションだ。在庫精度97%で、月$50,000超の原因不明差異が出ていた倉庫を見たことがある。他のKPIは美しかったが、意味はなかった。納期遵守率はペナルティに直結する：1日の遅れは緊急輸送、マーケットプレイスの罰金、顧客離れを意味する。UPHと残業比率はペアだ——残業が増えているのにUPHが下がっているなら、労働力の構成が壊れている。来月の給与明細がそれを示す。注文あたりコストはオーナーの最終損益で、他の7つはその分解だ。ロケーション稼働率とデッドストックもペアだ——稼働率90%なら、スペースを借り増すのではなく、デッドストックを処分すべきだ。
直感に反する話をしよう：多くのオーナーはBIダッシュボードが「見えない」を解決すると思っている。実際は「議論できない」を解決するのだ。 営業は出荷が遅いと倉庫を責め、倉庫はカットオフ後に注文を落としてくると営業を責めた。双方が自分のExcelを持ち寄った。ダッシュボードが稼働した後、納期遵守率が落ちた日に、ダッシュボードは注文の41%がカットオフ後に届いたことを示した。議論終了。数字はそこにあった。
各数字の出所：ダッシュボードを着飾ったスプレッドシートにするな
データソースが勝負のすべてだ。私が見た中で一番笑えた「BIダッシュボード」：美しいインターフェースに2週間かけて開発し、毎週月曜に誰かがWMSのデータをExcelに書き出して手入力していた。それはダッシュボードじゃない。仮装した週報だ。
8つの数字の本当の出所はここだ：
| KPI | 主なソース | 「帳簿」が実際に指すテーブル |
|---|---|---|
| 在庫精度 | WMS（循環棚卸＋在庫台帳） | 差異＝システム数量−カウント数量、SKU別 |
| 納期遵守率 | OMS（注文＋約束カットオフ）またはWMS（出荷タイムスタンプ） | WMS内部のタイムスタンプではなく、OMSの約束カットオフを使う |
| 労働生産性 (UPH) | WMS（タスク完了タイムスタンプ）＋勤怠システム（現場時間） | 分母は現場時間。監督者は除外する |
| 注文あたりコスト | 財務（給与/消耗品/運送会社請求書）＋WMS（注文量） | 分子は実際に使ったお金、予算ではない |
| ロケーション稼働率 | WMS（ロケーションマスタ＋占有状態） | 「利用可能」は破損・予約済みロケーションを除く |
| 返品率 | OMS（返品注文）またはWMS（返品受入） | 定義を一つに決める。両側で一致させること |
| 残業比率 | 勤怠システム（打刻/シフト記録） | 監督者の報告ではなく、時計を信じる |
| デッドストック金額 | WMS（在庫＋ロット別入荷日）＋財務（単位原価） | 90日間無動×移動平均原価 |
9割の倉庫がはまる罠：同じ数字でもシステムごとに定義が違う。 OMS時計の納期遵守率は約束カットオフ基準、WMS時計ではスキャン完了時刻基準。この2–3ポイントの差が、1ヶ月の責任のなすりつけ合いを生む。ダッシュボードプロジェクトの最初の仕事は開発じゃない——定義だ：数字ごとに一文、ソースを特定のシステムとテーブルに固定し、財務・オペレーション・ITの三者が承認する。
ソースは「毎朝」が可能かどうかも決める。在庫精度は循環棚卸由来——せいぜい週次だ。だから日次ダッシュボードに無理やり押し込むな。6つの数字は日次更新、2つは週次更新。ダッシュボードは指標が多いほど良いのではなく、更新頻度が定義に合っているほど良い。
自社構築 vs BIツール購入：小数点まで数字を回してみよう
オーナーが必ず聞く質問だ。二つのルートのコスト構造はまったく違う。だから並べて示す。
シナリオ：倉庫1拠点、1日8,000注文、KPIは8つ——日次6つ、週次2つ。
| コスト項目 | 自社構築（初期開発/外注） | BIツール購入（年間サブスク） |
|---|---|---|
| 初年度支出 | $11k–$21k（開発＋連携） | $4k–$11k/年（ライセンス＋導入） |
| 2年目以降 | $1.5k–$3k/年（保守） | $4k–$11k/年（更新） |
| ソース連携 | WMS/OMS/勤怠/財務を一つずつ接続——人手が重い | 多くのツールはETLかステージングDBが必要。導入は別料金 |
| 定義変更コスト | SQL 1行 | レポート＋ETLの作り直し、追加料金もあり |
| 3年間の総所有コスト | 約$15k–$27k | 約$13k–$33k |
| 最大のリスク | 開発者が辞めたら誰も保守しない | ソースシステムを変えたら全レポートが壊れる |
計算結果はこうだ：1日10,000注文未満の単一倉庫でKPIが8つなら、自社構築が勝つ。 SQLが書けるデータ担当が一人いれば2週間で立ち上がり、3年で確実に安くなる。購入が正解な例外は二つ：第一に、複数倉庫・複数事業部——権限管理、ドリルダウン、モバイルアプリはBIツールの値段に見合う。第二に、データ担当がおらず、社内最大の「データエンジニア」がオーナー本人——なら作るな。ツールを買って人件費を節約しろ。
多くの人が見落とすトレードオフ：ダッシュボードプロジェクトの最大コストは開発費じゃない。定義の議論で燃える時間だ。 BIツールを買って半年も稼働させられなかった倉庫を見た——技術の問題じゃない。注文あたりコストの分子をめぐって財務とオペレーションが3ヶ月争った：運送会社コストは配賦するのか、返品は数えるのか、監督者の給与は入れるのか。ツール選定会議が5回。定義会議が11回。作るにせよ買うにせよ、定義がツールより先だ。順番を逆にしたら金を燃やしているだけだ。
稼働チェックリスト：4週間。「半年デジタルプロジェクト」じゃない
ダッシュボードプロジェクトは「変革プログラム」になった瞬間に死ぬ。4週間のリズムを示す。これより長いなら、方向が間違っている可能性が高い。
1週目：定義。数字ごとに一文、ソースをテーブルに固定し、財務・オペレーション・ITが承認。承認なしに、その後の作業は全部無駄だ。
2週目：ソース接続。6つの日次数字を3 a.m.のスケジュールジョブで流す。リアルタイムを追うな——日次で運用判断には十分だし、リアルタイムダッシュボードに使う金は90%が無駄だ。
3週目：インターフェース。1ページ、8つの数字、信号機。ドリルダウンなし、多次元分析なし、予測なし——成功の基準は、オーナーが8 a.m.にスマホを開いて8つの数字を見ることだ。
4週目：2週間回して、定義を直す。すべての不一致は定義の問題で、技術の問題じゃない。直して、出す。
最終計算：動く倉庫BIダッシュボードは初年度、作るなら$11k–$21k（買うなら$4k–$11k）かかり、月に少なくとも2–3回のカンでの判断を防ぐ。 1回の誤判断が$4kなら、年間36回——節約は投資の10倍だ。この計算は合っている。
Lao Zhou（物流コストアナリスト）著
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
