紙製品メーカー様は、2023年12月から継続してご支援しています。これまでは在庫差異の原因特定と、受注30万行の集計自動化を進めてきました。
今回やったのは、棚卸しの当日そのものです。
ご相談の背景
在庫を管理する表は、すでにありました。ただ、棚卸しの当日には使えなかったのです。
売れ筋の分析、発注の判断、季節ごとの傾向。必要だと思って足していった機能が、そのまま重さになっていました。棚卸しは時間との戦いです。画面が固まる表は、当日は開かれません。
倉庫の実在庫と、システム上の理論在庫。この2つを限られた作業時間で突き合わせて、合わないところを潰す。当日に必要なのは、それだけでした。
実施したこと
1. 照合だけに特化した表を、別に立てた
分析用の表に手を入れるのではなく、棚卸し用の表を新しく作りました。やることを1つに絞ると、載せる列も自然に決まります。
外部倉庫の在庫、ECカートの在庫、受注済みで未出荷のぶん。この3つを貼るだけで理論在庫が出て、実数と比較できる形にしています。
2. 出力データを、加工せずに貼れる形にした
各システムから落としたデータを、Excelで整えてから貼る。この工程が残っていると、当日に必ず詰まります。
出てきたCSVをそのまま貼れば集計されるところまで、表の側で吸収しました。整える手間は、表を作るときに一度だけ払えば済みます。
3. 品番を相互参照して、片方にしかないものを拾った
2つのシステムを突き合わせると、どちらか一方にしか登録されていない品番が必ず出ます。ここは黙って落ちると、あとから「その商品はどこに行ったのか」という話になります。
相互参照して、片側にしかない品番も一覧に上がるようにしました。
4. 倉庫が返してくるのは、品番ではなくJANだった
自社は品番で管理していても、外部の倉庫は品番では引けません。カウント結果はJANコードで返ってきます。
ここを想定せずに表を作ると、当日その場で突合できず、手作業が発生します。JANの紐付けを組み込み、倉庫から返ってきたデータをそのまま照合できる形にしました。
連携先が何で返してくるかは、表を作る前に確認する。これは以降の案件でも必ずやるようにしています。
5. 当日の手が止まらない工夫を入れた
- 実数の入力欄｜数えた数字をその場で打ち込める
- 差異の大きい順にソート｜上から潰せば、影響の大きいものから片付く
- チェックボックス｜確認済みが一目で分かる
棚卸しは、全部を完璧に合わせる作業ではありません。限られた時間で、影響の大きいところから潰す作業です。表の設計もそれに合わせています。
6. 在庫の判定を、3区分に整理し直した
あわせて、在庫分析の側も作り直しています。基幹システム・ECカート・受注データを統合し、SKUごとの在庫指数から自動で区分するようにしました。
- 補充｜指数0.3未満。今の売れ方に対して在庫が薄い
- 監視｜1年以上2年未満。すぐ動かす必要はないが、放置もできない
- 要削減｜2年以上、または直近12ヶ月の売上が0
参照するのは過去12ヶ月の売上です。しきい値は後からいくらでも変えられる前提で、まず走らせています。完璧な基準を決めてから始めようとすると、いつまでも始まりません。
7. 数字だけで切らないよう、別の軸を併置した
ここが一番議論したところです。
売れていないから削る、という判断を数字だけでやると、買う人が少なくても確実にいる商品を落とします。定番と季節商品でも考え方が変わります。
そこで、在庫指数と並べてお気に入り登録の数も判断材料に置きました。要削減と出ていても、お気に入りが多い商品は一度立ち止まる。機械的な判定と、人の判断を分けるための線です。
いまの状態
- 棚卸し用の照合表は完成し、当日の運用に投入済み。更新のサポートも当日に入っています
- 在庫分析の側は1ヶ月の試験運用中。月1回の見直しサイクルで回しながら、しきい値を調整していきます
- SKUを増やす計画があるため、判定を人の勘に依存させない形にしておく必要がありました
棚卸しの表は、軽さがすべてです
在庫の表に機能を足していくと、いつのまにか「見るための表」になります。それ自体は悪くありません。ただ、棚卸しの当日に必要なのは、見る表ではなく潰す表です。
1つの表で両方をやろうとすると、たいていどちらも中途半端になります。分析用と照合用は、割ってしまったほうが速い。
IT CONSULTING