昨年11月、深圳（シンセン）のスマートホームブランドから、慌てた様子で電話がかかってきた。商品はカリフォルニア州オンタリオの3PL倉庫に3週間も滞留したまま、ブラックフライデーの大波が目前に迫っているのに、在庫数がどうしても合わない。自社システムでは80,000ユニットあることになっているのに、倉庫側のシステムでは65,000ユニットと表示される。15,000ユニットが消えた——少なくとも帳簿上は。照合レポートを取り寄せて真相を突き止めた。SKUコード、計量単位、カートン仕様、すべてがバラバラだった。
これは例外的な話ではない。これまで越境ECセラーの米国フルフィルメント倉庫との連携を手伝ってきたが、同じパターンの繰り返しだ。APIの構築にかかる工数は全体のせいぜい2割。残りの8割はマスタデータに消える。SKUのコード体系、1カートンに何個入るか、基本単位が個なのかセットなのか、箱のバーコードがインナーカートンのものかアウターカートンのものか。APIが壊れればエラーメッセージが出る。マスタデータが間違っていても、システムは何も文句を言わない。ただ黙って誤った商品を出荷し、誤った数量を受け入れ、照合が永遠に合わない。
APIは2週間でできる。マスタデータには2か月かかる。
「APIが開いている倉庫を見つけた」「自社のITチームが2週間で連携を作った」——それでシステムが「つながった」と思う経営者が多い。はっきり言おう。これがこの業界で一番大きな誤解だ。
APIはただのパイプだ。そこを流れるものが正しいかどうかなど気にしない。あなたのERPが「US-PLUG-BLK-01」というSKUを送ってきても、倉庫のシステムには「PLUG-BLK-US-01」と登録されている。データは流れるが、倉庫のシステムは認識できず、入荷オーダーは止まる。もっと悪いのは、似た旧SKUに自動マッチングされて、商品が間違ったロケーションに格納されることだ。気づいたときには、誤ったSKUで何千ものカートンが出荷済みで、もう取り戻せない。
本当に時間を食うのは、両者を同じテーブルにつけてマスタデータを1行ずつ突き合わせる作業だ。SKUのコード体系、計量単位（個・セット・カートンの3階層）、カートン仕様（アウターカートンあたりの入り数、総重量と正味重量）、バーコードルール（インナーとアウターのコード体系、SSCCラベルを使うかどうか、誰が印刷するか）。私が携わったプロジェクトでは、この工程は最短で3週間、最長で2か月かかる。セラーのデータがどれだけぐちゃぐちゃかに完全に依存する。データがひどいと、SKUリストを整理するだけで社内議論が3ラウンド、倉庫との議論がさらに1ラウンド発生する。
バーコードはもう一つの地雷原だ。中国の工場はインナーカートンのバーコードを印刷する傾向があるが、米国の倉庫が欲しいのはアウターカートンのコードと、パレット単位管理のためのSSCCラベルだ。コードが合わないと、入荷作業は箱ごとの手作業による貼り替え地獄と化す。東莞（ドングアン）の家具セラーでは、初回出荷——40コンテナ、2023年11月——のバーコードが事前に誰も確認していなかった。倉庫はカートンごとに貼り替え手数料を請求した。1箱あたり数十セントが40コンテナ分で、数万ドルに膨れ上がった。お金の痛みもあったが、入荷処理で失った2週間のほうがもっと痛かった。
私の結論はシンプルだ。3PLを選ぶときはまず、既製のマスタデータテンプレートとSKUマッピングシートがあるかを確認しろ。なければ、価格がいくら魅力的でも、立ち上げスケジュールに1か月余分に見ておけ。この工程はショートカットできない。ここで節約した時間は、出荷ミスと在庫差異という形で必ず戻ってくる。
動くAPIはゴールではなくスタートラインだ
APIはできた。事前出荷通知（ASN）は流れる。在庫は毎日同期される。これで終わりか？とんでもない。
私が見てきた中で最も厄介な失敗パターン：連携はリアルタイムなのに、倉庫の入荷確定と自社ERPの入荷計上が別々のアクションになっている。商品が届き、倉庫がスキャンして、在庫が1つ増える。ところがERPは、経理が入荷書類を承認して初めて入荷を計上する——2日のタイムラグだ。その2日間、倉庫にはまだ実在しない「引き当て可能」在庫に対して注文が入り続ける。過剰販売、キャンセル、低評価レビュー——連鎖反応のフルコースだ。問題はインターフェースではない。両者が「在庫」の定義を違えていることだ。
だから統合計画では、インターフェースそのものより照合の仕組みが重要になる。私が譲らない3つの条件がある。第一に、自動の日次照合レポート。SKU単位で1行ずつ、合意した閾値を超える差異は赤でフラグ——そしてフラグの立った行は当日中に必ず誰かが対応する。第二に、月次の「在庫確定日」。両者が倉庫の実地棚卸に合わせて突き合わせ、差異に異議があれば証拠を出す側。責任のなすりつけ合いは禁止。第三に、ASNにはカートン仕様とロット番号を必ず入れ、倉庫は開梱しての個数数えはせずカートン単位で受け入れる——開梱カートンの差異責任は契約書に明記する。官僚的に聞こえるだろう。ピークシーズンにはこの3つすべてに感謝することになる。
ローンチ前チェックリスト：これらが揃うまで本番稼働するな
本番稼働の1週間前、両者を集めて突き合わせ会議を開き、このチェックリストを1項目ずつ潰していく。1つでも不合格なら、注文量は上げない。1週間遅れての本番稼働は数日分の売上を失うだけだ。未解決の穴を抱えたまま本番稼働すれば、ピークシーズン全体の評判と返品送料の請求書を失う。
リストはこれだ。
- SKUマスタデータシートが両者承認済み。コード体系、商品名、3階層の計量単位（個・セット・カートン）、カートン仕様、総重量と正味重量。1対1のマッピング。1対多は禁止。
- バーコードルールが文書で確定。インナー・アウターカートンのコード形式、SSCCラベルを誰が生成・印刷するか、ラベル貼付位置図を倉庫に送付し受領確認済み。
- ASNのフィールドマッピングを実物のASNでテスト済み。倉庫システムが全フィールドを正しく解析し、カートン数、ロット、（該当する場合）有効期限がすべて無事に届く。
- 在庫の定義が一致。両者が「引き当て可能在庫」の意味で合意（輸送中は含むか？品質保留は？引当済み注文は？）。同期頻度と最大遅延はSLAに明記。
- 照合プロセスがエンドツーエンドで回った。初回の日次照合レポートが生成され、差異ごとの責任者と対応期限が割り当て済み。
- 例外フローがリハーサル済み。入荷差異メモ、出荷ミスの補償、返品受入——それぞれ1回ずつ通しで確認し、倉庫チームも自社のカスタマーサービスも「誰に電話するか」を正確に把握。
- 段階的立ち上げ計画がある。初週は注文量の10〜20%だけを流し、きれいに回ったらフルボリュームへ。一度に全部切り替えるな——何か間違っていたら、全部が間違う。
この7項目を印刷して壁に貼れ。システム連携は結局、技術の話ではない。忍耐の話だ。地味なマスタデータの仕事をやり切れば、ピークシーズンもぐっすり眠れる。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
