在庫適正化プロジェクト「よそうはうそよ」
この話はVoicyでもしてるので、よければ音声でもどうぞ。
ECでも最近、欠品もちょくちょく出るようになってきて、ご迷惑おかけしています。会社にとっては欠品ってダメージ大きいんですよね。本来は売れたであろう、稼げたであろう分をロスしているのも勿論だけど、その時に買えなかったことで、もしかしたら別の会社の商品に流れてしまうこともあるだろうし、リピートで購入してた方が、欠品を機会に購入をやめてしまうこともあるでしょうしね。
一方で、在庫過多の状態も、これはこれで大変です。倉庫のスペースは圧迫するし、そもそもそ在庫が増えてるということは、その分キャッシュが減ってますから。将来のキャッシュが在庫という形になっているわけで。キャッシュは腐らないけど、在庫はその時々で価値が変動しちゃいますしね。
今の会社全体の在庫管理は、かなり属人的というか、ベテランの経験と勘に頼りつつ、若手も含めて何人かで、日々日々の在庫を見て、生産計画を立てて、ってことをやっています。僕は属人的な業務が悪いとは全然思ってないんですが、在庫や生産管理は、人が背負うには、ちょっと重すぎるんじゃないかと思ってて、ここはいずれシステム化、AI活用などをもっと取り入れて軽減していかないと、早晩やっていけなくなるんじゃないかなと思っていました。
で、このシーズン、EC本店をリニューアルしたりで、EC売上も伸びて、商品の欠品も出てくるような状況の中、まずはECの在庫管理から始めて、最終的には会社全体の在庫や、それに紐づく生産計画までも最適化していけるといいな、ということで新しいプロジェクトがスタートしました。
よそうはうそよプロジェクト
プロジェクトタイトルは「よそうはうそよ」。
これは木村石鹸ではおなじみMGやTOC研修をやってもらったり、個別でも色んな分野、領域で伴走支援をお願いしているたくらみ屋の森本さんの言葉です。今回のプロジェクトも、勿論、森本さんに伴奏してもらってます。
「よそう」を反対から読むと「うそよ」になる。つまり、「よそう」に頼る判断とか意思決定は「うそよ」。うまくいかなくなる確率が高い。TOCでは、そんな風に考えて、なるべく「よそう」を減らして、判断できるようにしようという考え方があるそうです。
在庫管理においても、如何に「よそう」を減らせるか。判断をシンプルにできるようにするか。そこがポイントです。
会計恒等式（IN／OUT／残）の整理から始まったが
「よそうはうそよプロジェクト」の最初は、会計恒等式に基づいて「在庫」のデータを整理する、というところから始まりました。
前期繰越残／IN数／OUT数／次期繰越残
在庫で考えると、例えば昨日最終時点の在庫が10個ある。（前期繰越残）
今日在庫を5個増やした。(IN数）
今日10個売れた。（OUT数）
今日最終残ったのは5個。（次期繰越残）
この「次期繰越残」5個が次の日の「前期繰越残」5個になる。
こういうシンプルな構造がある。これをまず、実際のデータできちんと把握する。「IN数」「OUT数」「残数」を整理します。
こんなの簡単じゃないか、当たり前すぎるだろ、って思う人も多いと思います。簡単そうに思えるじゃないですか。意外と、これをきちんと定義して整理するって難しいんですよね。
正しい在庫が分からないと奪い合いが起きる。
これはこのプロジェクトのメンバーの一人、担当Ｙの名言です。どの在庫データが正しい、何をみたら適切な判断ができるのか、その辺が曖昧だと、各担当は自身の販売先や状況を鑑みて、自分の手元にリスクヘッジのために在庫を確保したりしだす。つまり「隠れ在庫」ができてくる。すると、ますます、在庫管理がカオスみたいな状態になる。
まず、正しい在庫が何かを決める。その数値をもとに判断する。これが重要なわけです。
どのシステム、どの場所の、どの数値を使うか？
例えば、僕らの場合だと、「在庫」にまつわる数字が管理されているシステムやツールが、けっこう多岐にわたります。
現状、ECサイトは、本店以外に、楽天店、ヤフー店舗、キナリノ店舗、Qoo10店舗、Amazon店舗の5店舗があります。
これらの受注データは、ネクストエンジン（通称：NE）という一括受注管理ソフトを使って、受注処理をしています。
このNE上では、倉庫と連動して日々各商品ごとの在庫数が見れるようになっていて、そこには「引き当て数」「フリー在庫」の数が各商品ごとに一覧で表示されています。「引き当て数」は、現状販売されていて、出荷までのプロセス途中にある数です。フリー在庫は、この「引き当て数」を差し引いて、前日最終倉庫と同期をとった正味の在庫数から、「引き当て数」を差分した数になります。
実際の在庫は、僕らは大阪の某大手物流会社の倉庫（E倉庫）に置いてて、ECの受注に貸しては、E倉庫から出荷されます。NEで受注処理を行ったデータが、E倉庫に行って、E倉庫から出荷。当日分の出荷が完了したら、E倉庫にある各商品の残数が、NE側に戻され、NEの在庫数が更新される。
E倉庫にも、今時点での在庫数と、出荷数（OUT）があります。そして勿論、うちの工場からはこのE倉庫に随時、商品の納品を行っているのでIN数もあります。ほら、ちょっとややこしくなってきたでしょ。
ややこしいのは、Amazonに関しては、Amazonの倉庫に在庫があって、Amazonの注文データはAmazonの倉庫から出荷されています。ただ、Amazonの倉庫への商品の納品自体は、E倉庫から出荷されているわけです。AmazonにはAmazonの「在庫数」「OUT数」「IN数」があるわけです。その「IN数」は、E倉庫の「OUT数」でもあります。
さらに言うと、在庫数の調整は、担当が毎朝NEの在庫状況をだーっと見て、「引き当て数」と「フリー在庫」の関係から、ちょっとヤバそうだなとか、この商品は、このままだとあと何日で欠品するなとか、そういう判断をして、各商品ごとの発注を、うちの製造拠点である伊賀工場（IGA）にかけるんです。この商品を〇個、この商品を〇個、と、かなりアナログなやり方で。この辺は、全然システム化されていなくて特定のチャットグループでやりとりしてます。
IGAはその依頼に基づいてIGA側にある商品在庫から、E倉庫に商品を出荷します。IGAにも各商品ごとに在庫があります。僕らはECだけではなく、卸販売も行っているので、卸先への出荷はIGAから行うのです。
各卸先からの注文は、一旦会社の方に入って、会社からIGAに出荷指示がいく。IGAは会社からの卸関係の出荷指示と、EC担当からのE倉庫への納品依頼を処理しながら、各商品の在庫の適正数をかなり勘に頼って、製造計画を立てています。
ただ、そういう日々日々の出荷指示とは別に、ECなら、たとえば大きなセールがある時は、事前に何月何日からこういうセールがある、各商品の販売予定数はこれぐらいになるとか、あるいは各営業からも、全国何百店舗とあるようなチェーンストアで取り扱いが決まったりすると、一気に何千、何万個の納品が求められるので、その辺も個別に事前に相談があるわけです。
そういう各方面から来る情報を全部集約して、IGAでは製造計画と、IGAでの各商品の在庫数量の確保を行っています。この変は、一応システムはあるんですが、ほぼ人が数値を見ながら判断してやってます。（こういうのは多分早晩AIがやることになるんじゃないかと思ってますが）
なので商品の在庫としてはIGAにも現状の「在庫数」があるし、出荷数があるし、製造したらIN数もある、ということです。
単純なIN/OUT/残と思ったら、実際の在庫はIGA、E倉庫、Amazon倉庫に分散しているし、在庫管理のシステムはNEやE倉庫が提供するシステムや、あるいはIGAの在庫を管理するスプレッドシートやらと、これも分散している。さらに言うと、OUTとか残をどの時点のどこのデータにするかによっても数がかわりますね。ECなんかは注文はずっと入ってくるので、NEのデータはリアルタイムで変わる。E倉庫は、〇時までの注文データなら当日中に出荷を行う、みたいなルールがあるので、ある時点で、その日のE倉庫にある在庫数、OUT数はどこかの時点で確定します。IN数は、IGAからE倉庫に納品して、その後、検品されて受け入れ確定の後に在庫数に反映されますが、この数と、NEと同期したNE上でのE倉庫の在庫数とはタイムラグが出てくることになります。
はい。質問です。どのシステムのどの数値で、IN/OUT/残を整理すると、わかりやすく、シンプルに管理できるようになるでしょうか？
頭の良い人ならすぐわかるのかもしれませんが、僕らは森本さんと担当者２人で、うんうんかなり悩んで、あーだこーだと数値を実際に整理してみたりして試してみたんですよね。結果、最終的にはかなりシンプルに数値を追いかけられるようになりました。とりあえず、E倉庫のデータを使うことにしたんですね。それが一番シンプルだから。答えに辿り着いたら、そりゃそうだ、ってなるんですが、でも、ひとまずはきちんと整理する、プロジェクトメンバーが環境や状況を理解する、認識を合わせる。この辺はとても大事なことだと思うので、この整理はすごく良かったなと思っています。
今までECの担当は、NEの「引き当て数」「フリー在庫」を見て判断していたわけですが、これからはE倉庫側のデータを使おうということになったわけです。
データの整理をする
以下は、ある1品目のE倉庫でのデータを日毎データに整形したものです。
この商品は2023/08/04に1774個在庫が計上され、そこからスタートしてます。その日にOUTで965出てますが、これはE倉庫からAmazonに移動した分です。E倉庫の残り在庫が809個。
8月7日からのOUT数は、E倉庫から出荷された数。つまりほぼ販売数です。8月7日に127個のOUTがあり、次の日からは19、26、39と、落ち着いた数が続きますが、8/17にまた120とまとまった数があがっています。
8/7は月曜日なので、先週の金曜日に最終出荷終わった後から、翌月曜日の午前中までの注文をまとめて、その日の午後に出荷しています。なので、他の平日より数が多くなっているわけです。8/17は、お盆明けですね。お盆中も受注は受け付けていましたが、出荷はしてなかったので、まとめて出荷になっています。
とりあえずこんな感じで、ECで販売する全品目についてのIN/OUT/残を日別で整理していきました。
データをグラフ化する
この日別の在庫推移のデータをグラフ化したものがこれ。
グラフ化すると、見えてくるものが全然違う印象があります。
この表だと一目瞭然ですが、赤の日々のOUT数に対して、黄色の残数があきらかに過剰な期間があります。ただ、ほぼIN（入庫）がないので、ずーっと減っていって、グラフの後半ぐらいでは適正になってきています。青のINの山が増えてきていて、在庫減っては入庫、減っては入庫を繰り返して欠品しないようにしている感じでしょうか。
僕はこのグラフを各商品ごとで見て、かなり新鮮だったし、驚きがあったんですね。今まで単にデータだった在庫数が、何かしらの判断するための情報に変わった瞬間というか。今更ながらにグラフって凄いなと思いました。
データを見える化する5段階
たくらみ屋森本さんに教えてもらったのが、データ（数値）を見える化する五段階という考え方でした。
①ソート
②合計
③平均
④グラフ
⓹3次元グラフ(時間の考えが入ったもの)
最初のデータの整理は、時系列にデータを並べて、整理しているので一段階目でしょうか。それを四段階目のグラフにしてみた。
元々見ていたネクストエンジンのデータは、毎日のその時点での数値です。これは単にデータに過ぎない。このデータだけ見ていても、何かの判断を下すのは極めて難しく、このデータを情報として活用するためには、担当者の経験や勘、頭の中で動くロジックなどが必要だったわけです。
そこに時間の概念が入って、日々のデータを俯瞰的に見られるようにした。すると、IN/OUT/残の推移がなんとなく見えるようになってきて、ある日がOUTが多くなるなとか、全体的にOUTの数ってだいたい20～50ぐらいの間で推移しているんだな、みたいことが分かった。
そして、それをグラフ化してみると、明らかに残数とOUT数のバランスがおかしいところがあることが分かる。セール対策としてかなり在庫に厚みをもたせたけど、そこまで売れなくて、かなり在庫数は余った状態になり、それが数か月かけて徐々に減っていき、適正化していった。そんな流れが読み取れるわけです。
上記グラフは、また別商品のグラフです。この商品は赤（OUT）の山が時折大きくあり、在庫が逼迫するシーンが何度かあります。
この商品の在庫を、大きく三段階に分け、赤（危険）／薄緑（やや危険）／青（安全）という区分で色分けして表示したものが以下のグラフです。
この形で見ると、さらに分かりやすくなります。在庫数が青のラインより上にあれば安全。赤のゾーンだと危険ということになります。後半以降は、黄緑、赤ゾーンに入ってる時間が長くなっています。
ダイナミックバッファマネジメント（ＤＢＭ）
今回僕らが在庫管理に取り入れようとしているのが、ダイナミックバッファマネジメント（ＤＢＭ）という手法です。
これは簡単に言うと、在庫数＝バッファを、ダイナミックに変動させていく、という管理手法です。
まず、各商品ごとに目標在庫（バッファ）を決めます。目標在庫数は、例えば、そのアイテムの過去1ヶ月の1日平均販売数×20日分みたいな設定で、とりあえず決めておく。
Ａは１００個、Ｂは３００個、Ｃは５００個となったとします。
各在庫を赤、黄、青でざっくり３等分します。この辺は最初はあんまり細かいこと考えず、とりあえずやってみる。
Ａなら1～33個まで赤／34～64個までを黄色／65～100個までは青
Bなら1～100個まで赤／101～200個まで黄色／201～300個までは青
Cなら1～166個まで赤／167～333個まで黄色／334～500個までは青
キャンペーンなどの特需のタイミングは別途考慮するとして、次回発注タイミングには、目標在庫に届くだけの数を発注します。
その時に、その時点での在庫数が赤、黄、青のどのゾーンに属していたかを記録していきます。そして例えば、こんなルールを決めておくわけです。
赤の連続回数：3回と仮に決める
3日続けて赤ゾーンの在庫だったら、目標在庫数を引き上げる
青の連続回数：5回と仮に決める
5日続けて青ゾーンの在庫だったら、目標在庫数を引き下げる
目標在庫数の増減：増減ともに30％で始めてみる
上記のようなグラフで見て見ると、黒の折れ線グラフ、後半はレッドゾーンに入ってますね。ここで発注する時は、目標在庫数バッファを引き上げを検討します。逆に、前半～中盤ぐらいまでは、赤ゾーンにはほとんど入ってないので、発注タイミングでバッファ数の引き下げを検討する。
こんな感じで、その時点での過去の実績から、動的にバッファを変えていくわけです。キャンペーン時や、テレビなどで取り上げれて爆発的な注文がありあそう、みたいな時は勿論、そこはある程度「よそう」に頼って在庫の積み増しなどが必要にはなってきます。ただ、日々日々の運用においては、まず、直観的に在庫が間に合ってるかどうかを把握して、発注するなら過去の数日間のデータから、目標バッファを上げ下げをしていくわけです。
というところまでが、今、プロジェクトで進んだところです。
実際は、全アイテムでＤＢＭを動かすのはまだ難しいので、まずは１アイテムだけをピックアップして、ＤＢＭで調整していくことを始めていきます。
それでうまくいきそうであれば、もう少しシステムを自動化するなりなんなりして、ECにおいては全アイテムをDBMで動かすところに持っていけたらなと思っています。
ただ、それでも実はプロジェクトの本丸というか最終ゴールの、まだ半分にも行ってないようなレベルです。最終ゴールは、会社全体の在庫をＤＢＭで管理するということです。それは、各品目の製造計画にも関係することなので、これはかなり規模が大きいです。
でも、いきなりそこを目指しても、難しいので、まずは出来るところから、出来る範囲からやっていこうというのが現状です。この辺、まず出来るところから、完璧じゃなくてもいいのでやってみよう、ってのは、TOCの考え方の一つで、僕はすごく良いなと思っています。完璧を求めると、手が止まるし、進まなくなるんで。多少ミスや間違いがあっても、まずは進めてみる。すごく大事なことだなぁと思います。