【AIレポート第6弾3章】戦略を変えようとしたとき、会社は動けなかった

経営は、チャネル横断で在庫を見ようとした。

しかし、店舗、EC、卸、倉庫の在庫は、それぞれ違う粒度で管理されていた。
店舗ではSKU単位で見ているが、卸では取引先別の出荷実績が中心だった。
ECでは商品ページ単位の売れ行きが見えていたが、基幹の商品コードとは完全には一致していなかった。
倉庫ではロケーション別に在庫が見えていたが、それがどのチャネルの需要に対応する在庫なのかはすぐには分からなかった。

経営は、品番別の粗利をシーズン中に見ようとした。

しかし、原価、値引き、返品、販売チャネル別の費用が別々に管理されていた。
月次で締めれば見える。
しかし、シーズン中に判断するには遅かった。

経営は、ECで動いている商品を店舗や卸に展開しようとした。
しかし、ECで見ている指標と、店舗・卸で見ている指標が違っていた。
ECはPV、CVR、購入率、カート投入率を見ている。
店舗は売上、客数、客単価、在庫消化を見ている。
卸は取引先別の販売実績と追加発注を見ている。
同じ商品について、部門ごとに違う言語で話していた。

経営は、取引先への提案力を上げようとした。

しかし、提案履歴、商談メモ、先方の担当者情報、取引先別の販売傾向は、営業担当者ごとの管理になっていた。
ベテラン営業は分かっている。
しかし、若手には見えない。
担当者が異動すれば、提案の文脈が途切れる。

経営は、MD判断を週次化しようとした。

しかし、発注数量を決めた根拠が残っていなかった。
なぜ追加したのか。
なぜ止めたのか。
なぜ値引きを待ったのか。
なぜこの店舗に多く配分したのか。
聞けば担当者は説明できる。
しかし、会社として検証できる形にはなっていなかった。
ここで初めて、社長は理解した。
問題は、単に古いシステムではない。

問題は、戦略を実行するための業務とデータと判断がつながっていないことだった。

既存基幹は動いている。しかし、判断には使いにくい。
基幹は、受発注、仕入、在庫、売上、請求を正確に処理するための仕組みだった。
それ自体は重要である。

しかし、今必要なのは、戦略を実行するための仕組みだった。

どの商品を伸ばすのか。
どの在庫を動かすのか。
どのチャネルに寄せるのか。
どの取引先に何を提案するのか。
どのタイミングで値引きするのか。
どの判断を次回に活かすのか。

これらを動かすためには、業務、データ、判断をつなぐ必要があった。

戦略を変えるには、意思決定を変えなければならない。
意思決定を変えるには、業務とデータをつなげなければならない。
そこで初めて、システムが経営テーマになった。

社長は、外部の力を借りることにした。

4章に続く