あなたはShopifyの店舗、Amazon、そして実店舗のレジの背後で、同じ青いセラミックマグカップを販売しているとしよう。ダッシュボードには「残り12個」と表示されている。ある客がレジで最後の1個を購入したちょうど3秒後、別の州にいる誰かがAmazonで「今すぐ購入」をクリックする。おめでとう——あなたはたった今、2つの異なるプラットフォームで在庫ありと表示されていた商品を売り越してしまった。そして今、あなたは謝罪メールと返金、場合によっては傷ついた出品者評価という代償を払うことになる。これは稀な例外ではない。複数チャネルで販売する企業が、数字の整合性を保つ仕組みを持たないまま販売を始めた瞬間に、デフォルトで起きることなのだ。
在庫の不整合——不正確な在庫数によって生じる欠品と過剰在庫の合計コスト——は、IHLグループの調査によれば、世界の小売業者から年間およそ1兆7,700億ドル、世界の小売売上高全体のおよそ6.5%を奪っている。中小規模のマルチチャネル販売事業者がその中でも過大な割合を負担しているのは、彼らこそが長い一日の終わりにスプレッドシートで手作業の在庫照合を行っている当事者だからだ。
そもそもなぜ在庫はずれていくのか
あなたが販売するすべてのチャネルは、それぞれ独自に「在庫が何個あるか」を記録している。Shopifyにはある数字があり、Amazonセラーセントラルには別の数字があり、実店舗のPOSシステムにはさらに別の数字がある。これら3つの数字をほぼリアルタイムで積極的に同期させる仕組みがなければ、いずれかのチャネルで最初の販売が発生した瞬間から数字は乖離し始める。ずれの大半は、いくつかの特定の失敗ポイントに起因する。
高速販売時の同期遅延
フラッシュセールや再入荷アナウンスの最中に1時間あたり20個が動いているのに、プラットフォーム間の在庫同期が30分に1回しか実行されないなら、数字が追いつくまでの間に10個を売り越してしまう可能性がある。販売速度が速いほど、同期の遅さが招くコストは大きくなる。2つ以上のチャネルでまとまった販売量をこなしている事業者は、一般に5分未満の同期間隔が必要だ。それより遅ければ、プロモーションはそのまま売り越しイベントに変わってしまう。
幻の在庫
「幻の在庫」とは、システム上は存在することになっているが、実際には誰も見つけられず販売もできない在庫を指す業界用語だ。それは通常、一つの大きなミスではなく、小さなミスの積み重ねから生まれる——入荷時に間違ったSKUにスキャンされたパレット、返金はされたが販売可能在庫に再登録されなかった返品、注文処理中のピッキングミス、あるいはバックヤードから棚へ移動されたのに数字が更新されなかった商品。いずれも単体では大したことに見えない。しかし年間数千件の取引に積み重なると、それらは静かにあなたの数字を蝕んでいく。
手作業での照合とスプレッドシート
チャネル間の整合性を保つ「仕組み」が、担当者が定期的に各プラットフォームを確認してスプレッドシートを更新することだけなのであれば、それは実質的に在庫を照合しているのではなく、保存された瞬間にすでに古くなっているスナップショットを撮っているにすぎない。このように分断されたシステムで運用している企業の在庫精度は63%程度まで落ち込むと報告されている一方、集中管理された自動在庫追跡を使う企業では95%以上に達する。
記録されない返品・破損・目減り
顧客に返金されたものの、2週間「検品待ち」の山に放置されている返品商品は、販売チャネルからは見えない存在になる——販売可能な在庫でもなければ、破損として償却されたわけでもない。これがすべてのチャネルのすべての返品で積み重なると、あなたの想像の中にしか存在しない在庫のプールが膨らんでいく。
照合の失敗が実際に招くコスト
同期されていない在庫がもたらす財務的な打撃は、抽象的な話ではない。Amazonでの売り越し1件だけでも、顧客への埋め合わせのための特急配送費、対応にかかる人件費、そして出品者パフォーマンス指標への悪影響——頻発すればリスティングの抑制やアカウント審査につながりかねない——を合計すると、40〜150ドルのコストが発生し得る。顧客側では、その打撃はさらに拡大する。オンライン購入者の69%は、商品が品切れと表示された瞬間に購入をあきらめ、競合他社から購入する。91%は再入荷通知を待とうとしない。43%は、たった一度の悪い在庫体験の後、恒久的にブランドを乗り換えると答えている。実店舗では同じ力学が異なる形で表れる——52%の買い物客は、欠品のせいで買うつもりだった商品を買わずに店を出た経験があると答えており、多くの場合、店員に裏在庫を確認してもらうことすらせず、何も買わずに立ち去っている。
見落とされがちな記帳上のコストもある。売上原価も、粗利益も、貸借対照表上の在庫評価額も、すべてはユニット数の正確さに依存している。帳簿上は4万ドルの在庫を保有していることになっているのに、実地棚卸の結果、記録されていない目減りや幻の在庫のせいで実際には3万4,000ドルしかないと判明したなら、その6,000ドルの差はどこかに現れなければならない——たいていはその四半期の利益を静かに食いつぶす評価減という形で、しかもそれは、ちょうど事業が本当に健全なのかを見極めようとしているタイミングで起きる。
実際に機能する照合システムを構築する
単一の信頼できる情報源を確立する
最もレバレッジの高い対策はただ一つ、1つのシステム——通常は専用の在庫管理システム（IMS）や、各チャネルの間に位置するミドルウェア層——を唯一の正式な記録として指定し、すべての販売チャネルとPOSがそこに更新情報を送り込む形にすることだ。各プラットフォームが互いに直接やり取りしようとする構成はやめるべきである。4つ以上のチャネルで販売するようになった段階では、手作業による照合の人件費と、手作業ゆえの売り越しリスクを織り込んで計算すれば、専用IMSがほぼ確実にトータルコストで有利になる。
バッチではなく、ほぼリアルタイムで同期する
Eコマースの動きがもっと緩やかだった時代は、日次あるいは1時間ごとのバッチ同期でも許容できた。しかしもうそうはいかない。物理在庫を扱うすべてのチャネルにおいて、5分未満の同期間隔を目指すべきだ。それを達成できないチャネルは、信頼するのではなく、積極的に監視すべき照合リスクとして扱うこと。
年1回ではなく、サイクルカウントを行う
年に一度、業務を止めて全数の実地棚卸を行うやり方では、問題が始まってから数カ月後にようやくそれを発見することになる。サイクルカウント——在庫の一部を継続的にローテーションでチェックしていく手法——なら、不一致がまだ小さく追跡可能なうちに発見できる。優先順位付けの実践的な方法として、ABC分析でカタログを分類し、「A」商品（売れ筋、または不一致が多いSKU）は毎週、「B」商品は毎月、「C」商品は四半期ごとにカウントするとよい。こうすることで、ほとんど動かない商品にまで均等に労力を割くのではなく、実際に財務リスクが集中している場所にカウントの労力を集中させられる。
勘で補充するのではなく、実際の再発注点を設定する
再発注点を求めるシンプルで説得力のある計算式は次の通りだ：（1日あたりの平均販売数 × サプライヤーのリードタイム日数）＋需要の急増や同期の遅延を吸収するための約25%のバッファ。カタログ全体への展開が負担に感じるなら、まずは売上高上位20SKUだけから始めるとよい——たいていの場合、そこに欠品リスクと在庫価値の大部分が集中しているからだ。
返品・入荷ワークフローを重点的に監査する
幻の在庫の多くは入荷と返品の段階で発生するため、この2つのワークフローには特に重点的な精査が必要だ。入荷したすべてのユニットにスキャン・確認のステップを義務付け、返品商品は一定期間内に「販売可能として再入庫する」か「破損・償却として記録する」かのどちらかにする、という厳格なルールを設けよう。未確定の中間状態のまま放置してはならない。
在庫数だけでなく、帳簿も照合する
在庫照合は業務上の作業であるだけでなく、会計上の作業でもある。実地棚卸に対して行うすべての調整——破損品の償却、幻の在庫の修正、処理済み返品の再入庫——は、スプレッドシートのセルを黙って書き換えるのではなく、記録として残る仕訳として財務記録に反映されるべきだ。ここで、プレーンテキストかつバージョン管理された記帳が真価を発揮する。すべての在庫調整が上書きされる数字ではなく追跡可能な取引になっていれば、在庫評価額がいつ、なぜ変化したのかを実際に確認でき、税務申告時や貸し手のデューデリジェンスで不一致が見つかった際にも、後からそれを再現することができる。
在庫数と同じくらい帳簿も引き締めておく
Shopify・Amazon・POS間で在庫を照合するのは、仕事の半分にすぎない——そのユニット数は最終的に、売上原価、利益率、貸借対照表の中に正しく反映される必要がある。Beancount.ioはプレーンテキスト会計を提供し、すべての調整について完全に監査可能でバージョン管理された記録を残せるようにする。だから6,000ドルの在庫評価減も、税務申告の時期になって慌てて追いかける謎ではなく、あなたが説明できる追跡可能な仕訳になる。無料で始めることで、なぜ開発者や財務に強い経営者たちがプレーンテキスト会計に乗り換えているのかを実感してほしい。
