どの倉庫にどの在庫を保管すべきでしょうか?
ある場所で在庫が過剰で、別の場所で在庫がなくなるのは、購入の問題ではなく、配置の問題です。何をどこに配置するかを決定する方法と、いつリバランスするかを決定する方法。
6 週間前、あなたは 300 単位のシダー & イチジク (250 g) を受け取り、それを 2 つの拠点に均等に 150 ずつ分割しました。現在、ポートランドには 3 ユニットが残っており、オースティンには 87 ユニットが残っています。店舗レベルの在庫レポートでは、週 35 個の販売に対して 90 個のユニットが示されています。これは、2 週間半強の在庫があり、12 日間のリード タイムを余裕で超えていることになります。この数字には、ポートランドが在庫切れであり、何かが動くまで在庫がないことを示すものは何もありません。
これは配置の問題であり、追加購入しても問題は解決されません。場所の仕組み、場所ごとの数量、転送の実行については、次のとおりです。 複数のShopifyロケーションにわたる在庫の管理。この投稿は、その前に行われる決定、つまり、そもそも何をどこに配置するかについてです。
症状
ポートランドではシダーとイチジクを 1 日あたり 3.5 個、オースティンでは 1.5 個販売しているため、この店では 1 日あたり 5 個で 70/30 が配分されます。順序を 50/50 に分割すると、ポートランドに 43 日間、オースティンに 100 日間の保障を与えることになります。6 週間が経過すると、その計算は完了です。
部隊はポートランドに残され、1日の援護下に置かれた
部隊はオースティンに残され、8週間強の援護期間を経たばかり
店舗レベルの数レポートをカバーする週数
店舗レベルの数値は、空の店舗と、販売に 2 か月かかるコストで 609 ドルの在庫を保有している店舗の平均です。単一の数値が行うのは平均化であるため、単一の数値レポートではそれがわかりません。 1 つの場所内で同じ障害が発生し、全体的には在庫が十分にあり、適切な在庫がまったくない場合は、次の方法でカバーされます。 在庫が多すぎてまだ在庫がない。場所によっては、原因も解決方法も異なります。
原因は偶数分割でした。解決策は、Cedar & Fig をすでに 6 週間分所有しているため、追加注文しないことです。修正するには、一部を移動し、均等に分割しないようにする必要があります。
実際に最適化される配置
明確に言えば、配置は 1 つの取引です。つまり、ユニットが顧客に到達するまでに移動する距離と、そのユニットのバッファを何回保持する必要があるかです。
後半に歯がある理由は、Shopify の設計上の事実です。 「各拠点の在庫は独立しており、他の拠点と共有したりプールしたりすることはできません。」オースティンのユニットは、ポートランドでは部分的に利用できません。両方の拠点が在庫切れを起こさずに独自の需要に対応する場合、両方に独自のバッファーが必要であり、1 つの SKU に 2 つのバッファーがある方が、同じ合計需要に対して 1 つのバッファーよりも常に総在庫量が多くなります。この追加在庫は配達距離が短くなる代償であり、一部の SKU に対して支払う価値のある価格であり、他の SKU に対しては支払う価値はありません。
この問題を解決できない原因は、Shopify が注文をルーティングするだけで、在庫を割り当てないという違いです。注文ルーティングは、注文後にどの既存の店舗が注文を処理するかを決定します。 Shopifyのヘルプセンターは、在庫割り当て計画を文書化しておらず、入荷した荷物のどのくらいが各拠点に送られるべきかを推奨しておらず、拠点間のリバランスも行っておらず、ある拠点が不足しているのに別の拠点が何か月も保証されているというフラグを立てません。ルーティングは履行時の決定です。配置は計画上の決定であり、それはあなたのものです。
集中化または分散化
この選択の正直なバージョンは、カタログの形式と注文の地域という、ビジネスに関する 2 つの要素によって決まります。
一元化 つまり、1 つの場所にすべてが保管され、どこにでも発送できるということです。 SKU ごとに 1 つのバッファー、正確に保つための 1 つのカウント、割り当ての決定や転送はありません。遠方からの注文の場合は、配達時間と送料を支払います。どこからでもほぼ均等に注文が来る店舗、またはカタログのほとんどが動きの遅い店舗では、これが正しい答えであることが多く、人々が予想するよりも長い間正しい答えであり続けます。
配布中 これは、各場所がその近くの需要に対応する在庫を保持していることを意味します。輸送時間が短縮され、地域内での注文の場合は送料が安くなり、販売する商品が揃う小売フロアが実現します。重複したバッファ、より多くのカウント、より多くの予測作業、そして分割が失敗した場合の時折の転送でその料金を支払います。注文の重要なシェアが各場所の近くに集中し、関連する SKU が複数の場所でのバッファをサポートできるほど高速に移動するときに、そのコストを返済します。
カタログ全体でこれらのいずれかを選択する人はほとんどいません。ほとんどの店舗にとって実行可能な答えは、頭部を分散し、尾部を集中化することです。ボリュームの大部分を構成する 20 ~ 30 個の SKU は、実際の需要に対応するすべての場所に在庫され、その他のものはすべて 1 か所に保管され、さらに出荷されます。
SKUごとの決定
3 つの質問が、一度に 1 つの SKU にこの順序で適用されます。
最初の質問は通常、見た目で解決されます。 2 つ目は、ほとんどの店舗が誤解している点です。店舗全体で週に 10 個、小規模な場所で 2 個を販売する SKU には需要パターンがなく、注文が少数で、それに対するバッファーを保持していることは、ノイズに対して在庫を保持していることになります。一連の場所がそもそも判読可能かどうかを判断することが主題です。 複数の場所にわたる予測。
3 番目の問題は、推測するよりも算数を行う価値のある問題です。 1 年以上かけてその SKU を発送するのに費やした金額と、決して移動しない 2 番目のバッファーにロックされている現金を比較してください。ここで引用できるベンチマークはありません。引用されている割合は、ソフトウェアを販売している誰かから引用されたものです。独自の配送料と単価は、意味をもつ唯一の入力です。
3 つの質問すべてをオーバーライドする 2 つの例外。小売店では、棚が空になると別の種類のコストがかかるため、計算に関係なく、売り場で販売できるものを陳列する必要があります。そして、本物の速度を約束した SKU は、バッファーにかかるコストが何であれ、約束した顧客の近くに属します。
場所ごとの目標の設定
SKU が複数の場所に在庫されると、各場所に独自のターゲットが必要になります。そのターゲットを単位で設定するのは間違いです。保障日数で設定して変換します。
Cedar & Fig のリードタイムは 12 日で、およそ 30 日ごとに購入するため、各拠点は 42 日プラス、決めたバッファーをカバーする必要があります。ポートランドでは 1 日あたり 3.5 個販売されるため、3.5 掛ける 42 は 147 個になります。オースティンは 1 日に 1.5 個売れるため、1.5 掛ける 42 は 63 個になります。合計すると 210 個となり、同じ 42 日間で 1 日当たり 5 個となり、需要がある場所で分割されます。の 目標在庫レベルの計算 SKU ごとにすでに使用しているものと同じです。変わるのは、毎日どの量の餌を与えるかだけです。
同じロジックを受信注文に適用すれば、この投稿の冒頭の混乱を防ぐことができます。
| 300 単位の注文の分割 | ポートランド、3.5/日 | オースティン、1.5/日 | カバーの日数 |
|---|---|---|---|
| 均等に各 150 | 150台 | 150台 | 43 対 100 |
| 需要シェア別、70/30 | 210台 | 90台 | 60 対 60 |
両方の行で同じ 300 ユニットがビジネスに投入されます。 2 番目の場合のみ、両方の場所が同じ日に在庫切れになります。いずれにしても、その日は再注文を計画していた日なので、これが望ましいことになります。単位を同等にすることが目標ではありません。イコールカバーです。
計画すべき制限が 1 つあります。Shopify には場所ごとの再注文ポイント フィールドがないため、これらのターゲットは管理者ではなくスプレッドシートまたはアプリ内に存在します。 Shopify には、店舗レベルの数字がまだ健全に見える一方で、ポートランドが独自の基準を超えたことを示すものは何もありません。
リバランスと並べ替え
場所が狭い場合は、2 つの機器と 1 つのテストを使用して、どちらに手を伸ばせばよいかを示します。
店舗の合計日額料金を使用して、すべての場所の補償日数を合計します。合計が健全で、ある場所には余剰カバーがあるのに、別の場所にはまったくカバーがない場合、問題は流通にあり、在庫に何も費やすことなく移転によって問題が解決されます。それがこの投稿の冒頭のケースです。1 日あたり 5 ユニットに対して 90 ユニットは合計 18 日であり、ポートランドの不足が存在するのは、これらのユニットのうち 87 ユニットがテキサスにあるためです。合計が本当に不足している場合、転送は不足分を移動するだけであり、発注書が必要になります。
その決定の完全版は、双方向で次のとおりです。 発注書と在庫転送の比較。配置に関して特に追加すべき点が 1 つあります。同じ SKU に対して繰り返し実行する必要がある転送は修正ではなく、症状です。ポートランドがオースティンからの補充を毎月必要とする場合、配置比率は間違っており、答えはユニットを移動し続けることではなく、次の注文の分割方法を変更することです。
Shopify はこれを提案しません。転送は手動で作成され、自動転送の推奨は行われないため、トリガーは自分のレビューによってもたらされる必要があります。
配置の検討
配置は並べ替えよりもゆっくりと進むため、通常は上位 SKU を四半期ごとにパスするだけで十分です。何を見るべきか。
- 現在注文を分割している比率に対する、四半期の地域別の各 SKU の需要シェア。いくつかのポイントのドリフトには対処する価値があります。
- 四半期内に複数の修正転送が必要な SKU。それは配置比率が失敗したということであり、不運ではありません。
- 配布するあらゆるものについて、場所ごとに並べてカバーする日数。広いギャップは、この投稿の冒頭にある問題の初期バージョンです。
- まったく売れなかった場所に在庫されている SKU。その株は単一の場所に撤退する候補です。
- オンライン注文を履行するように設定されていない場所に在庫が置かれている。この設定をオフにすると、「その場所に割り当てられた在庫が製品のオンライン数量から削除され」、それらのユニットはオンライン顧客がアクセスできない場所に配置されます。
最後の項目は、以前よりも監査が容易になりました。 2026 年 5 月に公開された変更以降、バリアントを満たしていない場所にある手持在庫が「表示され、更新できるようになりました」。利用可能な数量はダッシュで表示され、「場所はこのバリアントを満たしていません」という警告が表示されます。この在庫は非表示であるという古いガイダンスは時代遅れです。
レビューを進めるには、店舗の開店または閉店、ルーティング ルールの変更、リード タイムの変更、店舗全体で不均一に実施されるプロモーションの 4 つのイベントが必要です。
これらはどれも難しい算術ではありません。これは算術演算であり、四半期ごとに場所ごとの SKU ごとにやり直す時間は誰もないため、結果が変動します。 StockCue 無料を含むすべてのプランの予測と季節性、Starter からのロケーション スコープの在庫数により需要側を最新に保つため、決定しているロケーションごとの数値は実際に検証された数値になります。拠点間の移動はスケール機能です。配置を推奨するものではなく、現在は場所ごとの再注文ポイントがないため、分割は依然としてユーザーが決定することになります。
STOCKCUE
配置の決定は、その背後にある数に応じて決まります。 StockCue の在庫数は Starter からの場所に限定されているため、次に何を保持するかを決定する前に、各場所が実際に何を保持しているかを確認できます。
Shopify に StockCue をインストール →よくある質問
動きの速い製品はすべての場所に保管する必要がありますか?
通常、その通りです。なぜなら、高速輸送業者には、バッファーをサポートするのに十分な需要が各拠点にあり、長距離輸送を繰り返し行うと積み重なるのに十分な量があるからです。動きの遅い企業はその逆のケースです。1 つの場所での需要が少なすぎて 2 番目のバッファーを正当化できないため、通常はそれらを 1 か所にプールしてさらに出荷する方が安価な解決策となります。テストはカタログごとではなく、SKU ごとに行われます。
各拠点の目標在庫レベルを設定するにはどうすればよいですか?
単位ではなく、カバー日数単位で作業します。各拠点が保持する日数を決定します。これは、注文間のギャップにサプライヤーのリードタイムとバッファーを加えたもので、その日数にその拠点独自の日次売上率を掛けます。同じ SKU を異なる料金で販売する 2 つの場所では、販売数量と日数が大きく異なります。これが重要です。
在庫を移動するか、追加注文した方が安くなりますか?
それは、すべての拠点の合計ポジションが不足しているのか、単に分散が悪いのかによって異なります。合計で十分なユニットを保有しており、1 つの拠点に余剰日数のカバーがある場合は、在庫を費やすことなく転送によって修正されます。合計が不足している場合、ユニットの移動は不足分のみを再配置するため、発注書が必要になります。
どの場所に何が保管されているかをどのくらいの頻度で確認する必要がありますか?
配置は再注文よりも遅い決定であるため、通常は上位 SKU を四半期ごとにパスするだけで十分です。特定のイベントでは、早期のレビューを強制する必要があります。たとえば、拠点の開設または閉鎖、フルフィルメント ルーティング ルールの変更、リード タイムの移動、拠点間での需要シェアが数ポイント変動した SKU などです。
