分散していた在庫情報を統合し、補充判断を早期化

在庫情報ではなく、補充・移動の判断をそろえる

在庫統合の企画では、最初に『どこに何個あるかを見えるようにする』と置きがちだ。しかし経営上の問いは、今日の販売機会を守るためにどこへ配分するか、将来需要に対して何を発注するか、どの顧客へいつまでの受渡しを約束するかである。表示できても、その後の判断と実行が電話・表計算・担当者の勘に戻るなら、意思決定速度も資本効率も変わらない。

対象読者が最初に合意すべき結論

商品部は欠品を、財務は在庫金額を、店舗は作業量を、オンライン販売は表示在庫を、情報システムは同期遅延を見ている。それぞれの指標は正しいが、別々に最適化すると衝突する。欠品を恐れて店舗が発注を上乗せすれば滞留が増え、在庫削減を優先して供給余力を削れば約束後欠品が増える。共通の意思決定単位と、衝突を解く優先順位が必要になる。

したがってプロジェクトの最重要目標は『在庫を統合する』ではなく、『特定の判断を、定めた期限内に、説明可能な根拠で行い、結果から学習する』と置く。たとえば倉庫から店舗への補充なら、締切、対象品、補充単位、サービス水準、現場の修正権限までを含めて一つの業務サービスとして扱う。

リアルタイム化を目的にしてはいけない理由

更新を秒単位にしても、売場からバックヤードへ移動中の商品、検品前の入荷、返品保留、オンライン販売向け確保を同じ『在庫』へ足せば答えは誤る。必要なのは最大速度ではなく、判断期限に対して十分な鮮度と、意味が一致した数量である。店頭引渡しの引当は短い遅延が問題になる一方、週次の長期補充計画は将来供給と需要の確度が重要になる。

鮮度を一律に上げると、接続先・監視・障害復旧の費用が増え、重要なイベントと参考情報の区別がつきにくくなる。意思決定ごとに『何分遅れると誤判断になるか』『欠落時は停止するか推定するか』を定め、その要件から連携方式を逆算すべきである。

経営会議で衝突する二つの正解

財務責任者が在庫金額を減らしたいと主張し、販売責任者が欠品を避けるため在庫を積みたいと主張する。どちらも自部門の数字だけを見れば正しい。問題は、同じ一個の在庫が、粗利機会、顧客への約束、保管費用、値下げリスク、資金拘束という複数の価値を同時に持つことにある。統合基盤は勝者を決めるのではなく、どの条件ならどちらを優先するかを明示する必要がある。

そのため、全社一律の在庫削減率や充足率ではなく、品目の代替性、需要の不確実性、補充所要期間、粗利、陳腐化、顧客影響から在庫を一個増やす価値を評価する。高いサービス水準を維持しながら資本を軽くする余地は、平均値ではなくこの境界に現れる。

「在庫あり」を一つの数字で表さない

同一商品・同一拠点であっても、会計上存在する数量と、今すぐ販売できる数量と、特定チャネルへ約束できる数量は一致しない。この差を例外扱いすると、統合後も二重販売や補充過多が続く。差はノイズではなく、業務状態そのものである。

三つの真実を分離する

第一は現物の真実で、実際に拠点に存在し、位置や品質を確認できる数量である。第二は記録の真実で、基幹、倉庫、店舗、オンライン販売など各システムが保有する残高である。第三は約束の真実で、確定引当、仮引当、チャネル割当、保留、将来入荷の確度を加味し、顧客や店舗へ提示できる数量である。三つを混ぜず、差異を明示する。

GS1の商品の移動履歴を表す国際標準が、対象物に何が・いつ・どこで・なぜ・どのように起きたかをイベントとして表すのは、現在値だけでは経緯を説明できないためである。製品採用の有無にかかわらず、販売、入荷、移動、検品、棚卸、引当、取消を原因付きで残せば、残高を再計算し、差異がどの工程で発生したかを追える。

未来在庫は数量ではなく、条件付きの約束である

入荷予定を現在庫と同じ確度で足すと、遅延時に連鎖的な欠品が起きる。将来供給には予定日、供給元、確度、代替可否を持たせ、将来需要・既存引当と合わせて将来の約束可能在庫を計算する。クラウドサービス提供者の公式資料も、現在庫だけでなく予定供給と予定需要から日付別の約束可能量を算出する考え方を示している。

さらに、同じ物理在庫を全チャネルが取り合う場合、チャネル・地域・顧客群ごとの割当方針が必要になる。割当は商品を物理的に隔離することと同義ではない。共通プールのうち誰がどこまで消費できるかという経営ルールであり、優先顧客を守る代わりに他チャネルの販売機会を制限する場合もある。

欠品と過剰在庫を同じ原因から考える

欠品が起きると現場は安全側へ発注を上乗せし、差異が怖いほど余裕を積む。その結果、需要の弱い拠点へ在庫が滞留し、値下げや廃棄が増える。さらに帳簿在庫の信頼が下がり、担当者が独自の表を持ち始める。この循環を断つには、モデル精度より先に差異の発生源と補償行動を可視化する。

誤差は上流から下流へ増幅する

単位換算の誤り、商品コード未対応、時刻の逆転、取消漏れ、移動中在庫の二重計上は、統合基盤で一度正規化されると『正しい共通値』に見える。補充判断ルールはその値を使って発注や移動を作るため、元の小さな誤差が複数拠点へ増幅する。データ品質は情報システムの内部指標ではなく、発注・売上・運転資本へ至る先行重要指標である。

とりわけ残高を上書きする連携では、いつから差が生じたか分からず、原因分析が棚卸時まで遅れる。発生時刻と受信時刻を分け、イベントIDで重複を防ぎ、遅着や順序逆転を許容して再計算する。障害後に『最新全件データへ戻す』だけでなく、最後の整合点から追いつけることが運用品質を決める。

現場の上書きは、誤差ではなく制約情報である

担当者が推奨補充量を減らす理由には、棚が狭い、入荷作業が集中する、近隣イベントが中止になった、代替品を売り切りたいなど、システムが持たない情報がある。上書き率を下げるだけでは、現場が判断を黙って迂回する。変更量と理由、結果を記録し、制約マスターやルールの改善へ戻すべきである。

一方、理由のない恒常的な上乗せは、信頼不足や評価制度の歪みを示す。『欠品すると叱られるが、余らせても見えにくい』なら過剰在庫は合理的な現場行動になる。制度、権限、重要指標を直さずに計算ルールだけ導入しても、継続改善の流れは成立しない。

一件の補充判断から設計上の穴を探す

抽象的なデータの持ち方から始めるより、ある商品をある拠点へ補充する一件を、販売から次回発注まで追う方が設計は具体化する。そこで、代表的な業務シナリオを追う。

通常系：販売から補充まで

店舗で販売が成立すると、販売イベントが商品・拠点・数量・時刻・取引IDとともに発生する。共通基盤は重複を排除して販売可能数を減らし、既存引当、入荷予定、発注ロット、売場容量、次回便、需要見通しを用いて推奨補充量を計算する。推奨には『欠品予想時刻』『採用した制約』『前回からの変化』を添える。

担当者が承認または修正すると、発注・移動指示へ変換される。入荷、検品、棚入れが完了した時点で初めて販売可能へ加える。販売結果と欠品、値下げ、修正理由を次回確認へ戻す。重要なのは、一つのシステム間の連携方式ではなく、判断の前後で状態と責任がつながっていることである。

例外系：移動予定が遅れ、オンライン注文が重なる

別拠点からの移動予定を入荷予定として将来の約束可能在庫へ含めた後、輸送遅延が発生し、同じ商品へオンライン注文が入るとする。設計上の分岐は、確度が基準値を下回った時点で新規約束を止めるか、別拠点へ再配分するか、受渡し日を変更して顧客へ選択を求めるかである。いずれも在庫、注文、決済、通知の補償処理が必要になる。

この分岐を現場の電話判断へ残すと、同じ状況でも顧客対応が変わり、取消後の在庫戻しが漏れる。例外表には、検知条件、意思決定者、期限、代替案、顧客への説明、会計・在庫の戻し、再発防止データを持たせる。例外を通常系と同じ精度で設計することが、約束精度を支える。

同じ欠品予測でも、三つの経営判断がある

欠品が予想された時、追加発注、別拠点からの移動、顧客への約束制限は同じ問題への異なる回答です。追加発注は将来供給を増やすが滞留リスクを負い、移動は即効性があるが輸送・作業コストと供給元の機会損失を生み、約束制限は在庫を守るが短期売上を失う。基盤は一つの推奨値ではなく、選択肢ごとの損失と前提を示すべきです。

どの選択を採ったか、誰が承認したか、その後の欠品・値下げ・顧客影響がどうなったかを残す。この判断履歴がなければ、モデル精度は改善しても経営の意思決定能力は蓄積しません。

在庫・約束・補充の決定権を分ける

統合基盤が計算できても、誰がどの判断を変更できるかが曖昧なら、例外は止まる。データ責任者、業務責任者、ルール責任者を分け、判断の種類ごとに権限と説明責任を置く。

三つの決定を同じ画面で混ぜない

記録の訂正は、現物確認や取引記録に基づき残高を直す決定である。約束の変更は、顧客・チャネルへ提示する販売可能な状態を変える決定である。補充の変更は、将来の供給と資本配分を変える決定である。同じ担当者が操作する場合でも、目的、承認、監査を分けなければ、欠品回避のために帳簿を直接書き換えるなど不適切な近道が生まれる。

ルール変更には版と発効日を持たせ、過去判断を当時の条件で説明できるようにする。商品分類や季節、供給不安時の臨時ルールには失効日を設定する。例外権限が恒久化すると、共通基盤の外側に新たな属人運用が生まれる。

自動化は品目群ではなく損失構造で分ける

需要が安定し、供給制約が明確で、データ一致率が高い領域は自動実行へ進めやすい。新商品、季節品、希少品、供給途絶中の商品は、少量でも誤判断の損失が大きい。販売頻度だけでなく、誤発注、欠品、廃棄、顧客影響の上限から自動化可否を決める。

人手承認を残す場合も、全件確認ではなく影響額、データ信頼度、需要変化、制約違反で例外を絞る。人が見る件数を減らしつつ、重要な判断に注意を配分することが目的であり、機械が決めた比率を競うことではない。

連携方式は、全件・差分・併用から選ぶ

すべての企業にイベント駆動の全面刷新が必要なわけではない。既存システム、判断期限、復旧要件、データ量に応じて方式を選び、理想論で接続先を増やさない。選択の基準は、現在値の表示速度ではなく、誤判断時に原因を説明し復元できるかである。

三つの連携方式を比較する

定期全件型は導入が比較的容易で、日次・時間単位の集計には向くが、差異の原因や順序を追いにくい。イベント型は履歴と再計算に強いが、イベントID、順序、再送、データ形式の版、監視の設計負荷が高い。併用型はイベントで差分を反映し、定期全件データで照合・復旧するため、現実的な移行策になりやすい。

選択はシステム単位ではなく判断単位で行う。オンライン販売の仮引当は短時間の一貫性が必要でも、サプライヤーの予定情報は日次更新で十分な場合がある。全項目を同じ方式へ押し込まず、重要イベントの厳密性と参考データを利用できる状態を分ける。

共通サービスに閉じ込めるべき判断ルール

販売可能、約束可能、チャネル割当、補充推薦を各画面へ実装すると、ルールが分岐し、変更時に一致しなくなる。入力時刻、使用したルール版、算出結果、理由を返す共通判断サービスへ寄せる。一方で、現場固有の表示・承認・代替提案は利用側へ残し、中央集権化し過ぎない。

障害時の代替運転も設計対象である。最後に確認済みの値へ安全係数を掛けて販売を継続するのか、高リスク商品だけ停止するのか、店舗判断へ切り替えるのか。停止・機能制限の条件を平時に決め、訓練していなければ、最も忙しい時に最も危険な手作業が発生する。

自動化は、信頼できる範囲から広げる

画面を作ってから自動化する一本道ではなく、対象判断ごとにデータ・業務・統制の確認段階を通す。確認段階を満たさない領域は並行稼働を続けるか対象外とし、全社展開の日程を優先してリスクを隠さない。

最小単位は一つの判断・一つの責任チーム

対象を商品群、補充元、補充先、締切、現行担当へ限定し、現行判断と新しい推奨を並行して比較する。差分を需要、供給、在庫差異、マスター、制約、担当者判断に分類する。推奨が当たった件数だけでなく、外れた時の損失上限と復旧時間を確認する。

次の段階へ進む条件は、在庫一致率、イベント遅延、未解決差異、説明可能率、現場処理時間、約束後欠品などを組み合わせる。平均値だけでなく、最悪拠点や高影響商品を見る。平均が良くても、重大な例外を説明できなければ自動化しない。

三つの実装分岐

データ精度が低い場合は、自動補充より棚卸差異・スキャン・取消連携の改善を優先する。精度は高いが現場制約が未整理なら、推薦と理由表示に留め、修正理由を集める。精度と制約が安定し、損失上限が管理できる領域だけ自動実行へ移す。この分岐を明示すると、未成熟な領域を無理に同じ段階計画へ乗せずに済む。

展開後もルール・マスター・作業能力は変化する。季節、改装、物流網変更、新チャネル追加で前提が崩れるため、精度低下を検知して自動化を一段戻す仕組みが必要である。整備段階は一方向に上がるものではなく、条件に応じて運転モードを切り替える能力で測る。

重要指標をデータから経営成果までつなぐ

在庫回転や欠品率だけでは、改善・悪化の原因を特定できない。データ健全性、判断品質、実行品質、顧客・財務成果を階層化し、同じ会議で確認する。重要指標は報告のためではなく、次にどの制約を直すかを決める診断装置である。

一つの数値を上げると、別の損失が増える

在庫回転を上げるために在庫を削れば、欠品と緊急移動が増える可能性がある。充足率を上げるために余裕を積めば、値下げ・廃棄・保管負荷が増える。推奨採用率を高めても、現場が理由なく従っているだけかもしれない。対になる守るべき条件を置き、品目特性・拠点特性別に見る。

先行重要指標にはイベント到着遅延、未対応コード、差異未解決時間、ルール説明可能率、現場修正理由充足率を置く。結果重要指標には約束後欠品、緊急移動、廃棄・値下げ、在庫回転、粗利、運転資本を置く。先行が悪化して結果が維持されている時は、現場の追加作業で隠している可能性がある。

見直し条件を先に決める

導入仮説は『共通在庫と補充判断で欠品と過剰を同時に改善できる』である。見直し条件は、データ品質が改善しても判断が変わらない、推奨採用後に緊急移動や欠品が増える、現場工数が削減分を上回る、特定拠点に損失が偏る、といった状態である。成果だけを探さず、仮説を止める信号を合意する。

また、実地在庫を更新する作業が守られない、入出荷の記録点が存在しない、責任者が差異を処理できない場合、統合基盤だけでは改善しない。先に現場プロセスを直す、対象を狭める、または投資を停止する判断も、成熟したガバナンスの一部である。

結論：速く見て、正しく動ける在庫基盤へ

在庫統合はデータ基盤プロジェクトに見えるが、実体は顧客への約束、供給能力、運転資本をめぐる意思決定改革である。現物・記録・約束を分け、イベントから現在値を再構成し、補充・引当・移動の判断と結果を閉じることで初めて、欠品と過剰在庫を同じ原因から結果までの流れとして扱える。

経営会議で残すべき三つの問い

第一に、どの意思決定を何分・何時間早めたいのか。第二に、その判断に使う在庫の意味と確度を、部門をまたいで同じ言葉で説明できるか。第三に、誤判断が起きた時に止め、戻し、学習できるか。この三つに答えられない段階で全社リアルタイム化へ進むべきではない。

逆に、一つの判断で状態辞書、イベント、権限、例外、重要指標を通して設計できれば、対象商品や拠点を広げても原則は再利用できる。DXwheelが担うべき価値も、製品をつなぐことだけではなく、異なる部門の判断を同じ運用モデルへ翻訳し、限定範囲で検証可能にすることにある。