FBA倉庫の在庫が、あと2週間で尽きる。本社倉庫には在庫がある。
ならすぐ送ればいい、という話のはずでした。ところが送る個数が決まりません。いま何が発注済みで、いつ入ってくるのかが分からないと、何個移動すべきかも、そもそも移動が必要なのかも判断できません。結局、発注を担当しているAさんに聞くまで動けませんでした。
在庫管理の悩みというと、たいてい「数字が合わない」という話になります。棚卸しで数が違う、システムとExcelがずれている、といった精度の問題です。
それも起きます。実際、毎月半日をずれの確認と修正に使っていました。ただ、本当に困ったのはそこではなく、数字が合っていても判断ができないことでした。これが一番きついところです。
なお、この記事は複数チャネルを運用している段階の話です。そもそも在庫を持ちすぎる、あるいは欠品してしまうという段階であれば、在庫の持ちすぎと欠品が同じ原因から起きる仕組みを先に読んでください。
また、ここで書くズレを自社で抱えずAmazon側に預ける選択肢もあります。その判断はFBAに寄せると在庫管理がどう変わるかで扱っています。
結論：問題はExcelではない
先に結論を書きます。
在庫管理がうまくいかなくなる原因は、Excelを使っていることではありません。在庫の「定義」と「共有」が決まっていないことです。
Excelはこの2つの曖昧さを吸収してくれないため、そのまま表面化します。ただし、吸収してくれないだけであって、原因を作っているわけではありません。ここを取り違えると、在庫管理ツールを導入したのに何も解決しなかった、ということが起こります。
問題は2階建てになっています。一つずつ見ていきます。
1階：数字がずれる — 在庫の定義が決まっていない
自社倉庫だけで完結していれば、在庫の数え方に迷う場面は多くありません。棚にある数を数えれば済みます。
自社倉庫とFBAを併用するようになった瞬間、話が変わります。「どこにあるか分からない在庫」が生まれるからです。
ずれが生まれる4つの地点
倉庫間の移動中
本社倉庫から出してFBAへ送った在庫は、送った瞬間から着荷して反映されるまでのあいだ、どちらの在庫でもありません。浮きます。
やっかいなのは、FBA側での着荷から在庫反映までのタイミングが一律ではないことです。同じ日に送っても反映される日は違うため、棚卸しのタイミングがここに重なると確実にずれます。
引き当て済み
受注は入ったが、まだ出荷していない在庫です。物理的には棚にありますが、売り物としては既にありません。これを在庫として数えるかどうかで、答えが変わります。
梱包済み
出荷直前で、箱に詰め終わった状態の在庫です。棚にはありませんが、まだ倉庫から出てもいません。ここも判断が必要です。
FBAの返品処理中
お客様から返品された商品は、FBA倉庫内で検品され、再販可能なら在庫に戻り、不可なら別の扱いになります。この動きを把握していないと、数が合いません。
この4つのうち、どれか一つでもルールが決まっていないと、毎月の棚卸しで必ずずれます。そして厄介なのは、ずれの原因を特定する作業に時間がかかることです。うちの場合、毎月半日がこれに消えていました。
半日というのは、年間にすると6日分です。それだけの時間を、売上を一円も生まない作業に使っていたことになります。
Excelが悪いわけではない
この状態でExcelを使っていると、当然のようにずれます。それで「Excelでは限界だ」という結論になりがちです。
しかし、ずれの原因は「移動中の在庫をどちらに数えるか決めていない」ことであって、Excelを使っていることではありません。ルールが決まっていなければ、どんなツールを入れても同じずれが起きます。
むしろ在庫管理ツールは、導入時にこれらの定義を強制的に決めさせてくれる面があります。それで解決したように見えるのですが、解決したのはツールではなく、決めたルールのほうです。
2階：数字が合っていても判断できない — 情報が共有されていない
ここからが本題です。
仮に在庫の数字が完璧に合っていたとします。それでも冒頭の場面は解決しません。FBAの在庫が尽きそうで、本社に在庫があっても、何個送るべきか決められません。
足りないのは在庫数ではなく、これから入ってくる予定です。
発注状況が一人の頭の中にある
いま何を、何個発注していて、いつ納品されるのかが担当者の記憶と手元のメモにしかない状態だと、他の人間は判断ができません。
来週100個入ってくるなら、FBAへは在庫のほとんどを送ってしまってかまいません。何も入ってこないなら、本社にもある程度残しておく必要があります。同じ在庫数でも、正解が正反対になります。
そのたびにAさんに確認することになり、Aさんが休みなら翌日まで止まります。これが日常的に起きるようになると、在庫の精度とは別の次元で業務が回らなくなります。
置き場所が記憶にある
もう一つが、商品の置き場所です。
この商品はAの棚、これはBの棚、と担当者が覚えている状態です。本人が作業している限りは、むしろ効率的に見えます。検索するより速いからです。
問題は、その人以外が何もできなくなることです。棚卸しは進まず、ピッキングは遅れ、新しく入った人も戦力になりません。バーコードなり棚番号なり、誰が見ても分かる目印がないと、人を増やしても処理能力が上がりません。
担当者の記憶に頼っている状態は、一見すると問題なく回っています。その人が優秀であればあるほど、回ってしまう。だから気づくのが遅れます。
全員が同じルールで動き、数字で正確に把握できる。この状態を作らないと、規模が大きくなった時点で必ず破綻します。
前兆は「Aさんに聞かないと分からない」
破綻する前に、必ずサインが出ます。
それは在庫のずれの件数でも、出荷件数でもありません。「これ、Aさんに聞かないと分からない」という言葉が、業務中に出るようになったときです。
最初は月に何回かでしょう。それが週に何回かになり、やがて毎日になります。その頃には、Aさんは休めなくなっています。
この段階で手を打てば、まだ間に合います。逆にここを放置したまま出荷件数だけ増やすと、精度も速度も同時に落ちていきます。
ツールを入れる前に決めること
順序があります。ツールの検討はその後です。
在庫の定義を決める
最低限、以下を文章にして共有してください。口頭ではなく、誰でも読める形にすることが重要です。
- 移動中の在庫を、出庫元と入庫先のどちらに数えるか
- 引き当て済みを、在庫として扱うか
- 梱包済みを、どの時点で在庫から外すか
- 棚卸しの基準時点をいつにするか（出荷ベースか、着荷ベースか）
正解はありません。自社の運用に合っていて、全員が同じ答えを言えることのほうが重要です。
発注情報を共有する
何を、何個、いつ発注し、いつ入ってくるのかを、担当者以外も見られる場所に置きます。
凝ったものは要りません。スプレッドシート1枚で十分です。重要なのは、誰かに聞かなくても分かる状態を作ることであって、システムを入れることではありません。
置き場所に目印をつける
棚番号でもバーコードでも構いません。記憶に依存している部分を、物理的な表示に置き換えていきます。
全商品を一度にやろうとすると挫折します。動きの速い商品から順に、少しずつで構いません。
それでもツールが必要になる場合
ここまでやっても、規模が大きくなれば手作業の限界は来ます。
ただし、その時に導入するツールの効果は、ルールを決めてからのほうが圧倒的に高くなります。逆にルールが曖昧なまま導入すると、曖昧なデータが入るだけで、結局は人が見て判断することになります。
順序を守ってください。定義を決める、共有する、それでも足りなければ道具を入れる。この順です。
向かないケース
この記事の内容は、自社倉庫とFBAのような複数の保管場所を併用している場合の話です。
FBAのみで完結している、あるいは自社倉庫だけで売っているという場合は、ここまで複雑にはなりません。移動中の在庫という概念がそもそも発生しないからです。その場合は、引き当てのルールだけ決めておけば十分でしょう。
また、商品点数が数十点程度であれば、記憶に頼った運用でも回ります。無理に仕組み化するより、そのぶんを販売に使ったほうがいい段階もあります。
まとめ
在庫が合わない原因を、ツールのせいにしないでください。
合わないのは在庫の定義が決まっていないからで、判断できないのは情報が共有されていないからです。どちらもExcelの問題ではありません。
もし今日、社内で「それAさんに聞かないと分かりません」という言葉が出たなら、それが手を打つタイミングです。