去年ブラックフライデー明けの月曜朝、午前7時に携帯が鳴りました。顧客のCEOからのテキストです。「Lao Mi、うちのカスタマーサービスがオンラインで叩かれている。」
カリフォルニア州オンタリオにある120,000平方フィートの3PL倉庫から出荷するスキンケアブランド。ブラックフライデー中ずっと、ホームページには「全品2日配送」と大きく掲示されていました。月曜朝までに、1,000件以上の注文が「出荷待ち」のまま滞留し、電話は鳴り止まず、SNSでは詐欺師呼ばわりされていました。
その午後、私は彼らのオフィスで、OMSの納期コミットロジックを徹底的にほじくり返しました。倉庫は遅くありませんでした。ピッカーたちは一週間ずっと深夜過ぎまで働いていたのです。本当の問題は、システムが最初からそんな約束をすべきではなかったことでした。在庫引当可能数(ATP)と納期コミットは、多くのチームが一度設定したら忘れてしまうOMS機能です。そして、それが最も派手にあなたを辱める機能でもあります。
罠は3つ。順に見ていきましょう。
帳簿上の在庫は、建物の中にない
罠その1は古典です。ATPの計算式が間違っている。
Available-to-promiseは単純そうに見えます。在庫があれば売れる。しかし「ある」とは何でしょうか。こんな式で回っているシステムを、私は山ほど見てきました。手持ち在庫 − 引当 = 販売可能数。一見もっともです。間違いです。なぜなら手持ち在庫には、触れてはいけない3つのものが静かに紛れ込んでいるからです。輸送中の入荷在庫、ソフト予約(仮引当)在庫、QA凍結在庫です。
輸送中在庫が最も大きな被害を出します。小物家電の顧客は「もうすぐ着くし、3日で届くだろ」という理屈で、「すでに出荷済み、輸送中」の発注を販売可能としてカウントしていました。ブラックフライデーの直前週、8,000台の加湿器を積んだ船がロサンゼルス港沖で9日間連続バース待ちしていました。その間、サイトは売り続けました。3,000台以上、全て「3日配送」の約束付きで。コンテナが岸壁に着いた頃には、CSチームは謝り疲れていました。
予約在庫は2つ目の地雷です。大口B2B顧客の注文や、Amazon FBAの補充プランは、システム上で在庫を拘束しますが、まだ物理的には出荷していません。OMSプラットフォームの中には、予約を注文ヘッダーレベルでしか追跡できず明細レベルでは追えないものや、ATPから差し引かずに予約するものもあります。私が見た最悪のケース: 同じバッチがB2B注文に1回、FBA補充プランにまた1回予約され、ATPからの差し引きは0回。1つの在庫バッチが、3回売られました。
QA保留は最も陰険です。入荷ロットが抜き取り検査で不合格になり、サプライヤーの回答待ちで全バッチが凍結。WMSではロックされ、触れません。しかしOMSが手持ち総数だけを読むと、凍結ステータスは見えません。オンタリオのあのスキンケア倉庫では、ブラックフライデー直前にセラム20,000本がラベルの誤記でQAにロックされました。システムは何も起きていないように売り続けました。
点検方法は? 私のローテクな方法: OMSから回転の速いSKUを20件選びATP数値を抜き出し、倉庫にはその同じSKUについて「今すぐピックできる分」を実際に数えてもらいます。2つの数字が食い違えば、その差はあの3つのどれかです。直すときは欲張らないでください。式を「手持ち在庫 − 予約 − 凍結保留」に変え、輸送中在庫は別の行「入荷予定」として、入荷日ごとに切り分けて表示します。物理的に建物の中に入るまで、販売可能数には絶対に入れない。80,000平方フィートの倉庫で、その変更を2週間で回し切ったことがあります。売り過ぎのクレームは、その後ゼロになりました。
約束は倉庫A前提。荷物は倉庫Bから出る
罠その2はマルチ拠点フルフィルメントに潜んでいます。単一倉庫の計算は簡単です。今日出荷 + 配送業者の輸送日数。倉庫が増えると、一気にややこしくなります。
OMSが納期を約束するとき、2つの問いに答えなければなりません。どの倉庫が出すのか、それに何日かかるのか。システムの多くは、店頭表示の納期を「顧客に最も近い倉庫」で計算して見せ、注文成立後に引当エンジンが「在庫があり、コストが最も安いのは誰か」で拠点を選び直します。店頭は倉庫Aの2日を約束したのに、荷物は実際に倉庫Bを出て4日かかる。顧客はトラッキングページを見て、「カリフォルニアから発送」と書かれているのに自分はニューヨーク在住。それが怒りの電話の発信源です。
もっと微妙なのもあります。配送業者の締め時間です。システムは「今日出荷する」前提で約束を計算しますが、もう午後4時で、倉庫の当日締めが午後3時だったことに気づきません。その注文の出荷は実際には明日。約束は最初から1日足りませんでした。ピークシーズンには倉庫が締め時間を前倒しします。午後3時が午後2時になり、システムのパラメータは誰も更新せず、何週間も全ての約束が1日ずつ遅れ続けます。
直し方は逆方向です。約束ロジックと引当ロジックに同じルールを使わせます。店頭が納期を表示する前に、本番の引当パスを回し、実際にどの倉庫が出すかを突き止め、その拠点からの配送業者の輸送日数 + 締め時間チェックで計算します。当たり前の話です。世の中の中堅OMSプラットフォームの半分は、約束と引当が会話しない2つの別コードパスで回っている、と私は踏んでいます。システム選定で必ずやるデモはこれです。異なるZIPコード宛てに3件のテスト注文を入れ、約束された納期が実際の引当と合うか確認する。合わなければ、そのベンダーは落選です。
ピークシーズンが来ると、約束は全部崩れる
罠その3はピークシーズンのものです。ATPは1年中正しく見えるのに、11月になると崩れます。式は悪くありません。並行性(コンカレンシー)が問題です。
通常の日は1分あたり数十件の注文で、在庫の引き落としが追いつきます。ブラックフライデーの深夜0時は1分あたり数千件の注文が雪崩れ込み、ATPはまだ数分前に計算されたスナップショットで売り続けます。スナップショットには500台とある。実際は3秒で消えました。次の2分間に注文した全員が「在庫あり、2日配送」を約束されました。翌朝倉庫が来て、ピックできるものは何もない。選択肢は、1件ずつ謝るか、補充待ちで「2日」が「2週間」に伸びるのを眺めるかです。
もう1つあります。予約販売と通常在庫の二重売りです。マーケティングが「来週到着のバッチ」のライブコマース予約販売を走らせ、サイトは通常在庫を売り続けます。2つのチャネルが1つの在庫プールを共有していないので、同じ入荷バッチが2回約束されます。到着したとき、買い手の半分の分しかありません。残り半分の「2日配送」は「入荷次第ご連絡します」に変わります。
ピークシーズンの対策は3つのパートから成ります。まず、販促SKUには専用の在庫プールを用意し、日常の販売在庫から物理的に切り離す。予約販売は予約販売、通常在庫は通常在庫。相互に融通しない。次に、混雑の激しい時間帯はATPに悲観的ロックをかけるか、最低でもスナップショット更新を秒単位まで詰める。これはエンジニアの協力が必要で、現場だけではできません。3つ目は、ピーク前に「約束のストレステスト」を回すこと。前年のピーク注文量をテスト環境で再生し、ATPが嘘をつき始めるポイントを見る。壊れる場所を事前に知るのは、後から謝るよりずっと安い。
システムを入れ替えるな。この順番で点検せよ
このトラブルが起きると、多くのオーナーはOMSを総入れ替えしたがります。私の助言: まず診断してから決める。なぜなら10回中9回、これらの罠は設定の問題であり、プラットフォームの問題ではないからです。
この順番で点検します。まず、20 SKUの現物照合をして、ATPの式が予約と凍結保留を正しく差し引いているか確認する。次に、異なるZIPコードにテスト注文を入れ、店頭の約束納期を実際の引当と締め時間に突き合わせる。3つ目は、前年のピークを再生して、売り過ぎ注文を切り分ける。陳腐化した並行スナップショット由来は何件、予約販売と通常在庫が1つのプールを共有していた由来は何件。この3ステップの終わりには、根本原因が分かっています。
直す順番も優先度順です。式の修正が最優先。コード変更は不要です。約束と引当のルール統一が2番目。エンジニアの時間が必要です。並行ロックとプール分離が3番目。次のピークの1か月前に予定を入れます。この順番で、1日3,000件の倉庫でも、1四半期で納期精度を正常に戻せます。
最後に1つ質問です。あなたのシステムの納期コミット数値。最後に誰かがATPレポートを持って倉庫の現場を歩き、SKU単位で照合したのはいつですか。思い出せないなら、次の破られた約束は、もう既に出発しているはずです。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
