製品バンドルのコンポーネント需要を予測する方法
コンポーネントの実際の需要は、それ自体の売上に、それを含むすべてのバンドルを加えたものです。これがないと、バンドルの計算、作業、再注文ミスが発生します。
単独で販売されるコンポーネントと 2 つのバンドル内の両方で販売されるコンポーネントには、1 つの在庫番号を供給する 3 つの需要ストリームがあります。ストリームを個別に予測すると、その在庫数を 3 回注文することになります。商品ページだけを予測すると、棚で実際に失われる金額の約 3 分の 2 を注文することになります。
この記事は、そのための計算をエンドツーエンドで行ったものです。 Shopify がどのようにバンドルを表現し、コンポーネントの在庫を減らすかについては、 バンドル在庫管理ガイド;これは、下落が起こることを想定し、それによって作成される購入決定を扱います。
バンドルが予測を裏切る理由
このサイトのすべての予測方法は、1 つの SKU の過去の販売個数の列から始まります。これが機能するのは、通常の製品の場合、売上列と在庫の動きは 1 回カウントされる同じイベントであるためです。
バンドルはそれを断ち切ります。ギフトボックスはギフトボックスとして販売され、キャンドルが棚から離れます。計画ルーチンが製品リストをたどって、独自の履歴から各行を予測する場合、キャンドルはキャンドルの行から計画され、ギフト ボックスはギフト ボックスの行から計画されますが、そのルーチンでは 2 番目の行が 1 番目の行の在庫を消費することに気づきません。あなたの予測が正しく計算されれば、ろうそくの在庫は残り 5 週間あるはずです。
キャンドルの売上列とキャンドルの在庫の動きは、それを含むバンドルを発売した日から同じ数字でなくなりました。
計算
コンポーネントの需要 = スタンドアロンの販売数量 + それを含むすべてのバンドルの合計 (バンドルの販売数量 × バンドルごとのコンポーネントの数量)
素直に書きます。合計が真となるには 2 つの条件が成立する必要がありますが、どちらも見逃されがちです。
スタンドアロン フィギュアはスタンドアロンである必要があります。 スタンドアロン販売と呼ぶ数値に、バンドルによって消費されるユニットがすでに含まれている場合、バンドル条件を追加すると、それらのユニットは 2 回カウントされます。これは、このトピックの中で最も高価な間違いです。なぜなら、これは目に見えないからです。合計が大きく見え、合計が大きい方が安全だと感じ、誰もがその方法に疑問を抱く前に過剰注文が到着します。レポートでどのような数値が得られるかは次のセクションの主題であり、何かを計算する前に決定する価値があります。
すべての履歴は、バンドルの発売後の同じ期間をカバーする必要があります。 通常、バンドル販売は単独の販売にきれいに追加するのではなく、一部の販売を置き換えます。ツイン パックを発売する前にそのキャンドルが週に 40 個売れ、現在は週に 35 個売れ、ツイン パックでは週に 10 個売れているとします。このバンドルにより、実際の需要は 10 単位ではなく 5 単位追加されました。残りの 5 つは独立したカラムから出てきました。発売前のスタンドアロン履歴 40 に、今日のフルバンドル ドローの 21 を追加すると、実際の 56 に対して 1 週間に 61 が得られ、約 9% の高さになります。これは、四半期に 60 の余剰ユニットと、単位コスト 7 ドルで 420 ドルの現金を獲得できることになります。両方の半分に発射後の数値を使用すると、読み取っているスタンドアロンの数値に変位が焼き付けられているため、変位はすでに処理されています。
厄介なケースは、まだ発売されておらず、発売後の履歴が存在しないバンドルです。そこでは、バンドルの売上のうち、置き換えられた需要ではなく新たな需要が占める割合を推定し、それが推定であることを明示する必要があります。完全な相加性がその範囲の積極的な終端であり、中立的な終端ではないと仮定します。
うまくいった例
1 つのコンポーネント、2 つのバンドル、12 週間。 Cedar & Fig、250g は単独で販売され、Cedar & Fig ギフト ボックス (1 箱あたり 1 つのキャンドル) に入っており、ツインパック マルチパック (1 パックあたり 2 つのキャンドル) に入っています。
- スタンドアロン: 34、36、33、35、36、34、35、37、34、36、35、35。合計 420 ユニット、週 35 ユニット。
- ギフトボックス: 6、14、9、22、5、12、8、18、7、11、10、10。合計 132 ボックス、週 11 個、各キャンドル。
- ツインパック: 4、6、5、7、3、5、6、4、5、6、4、5。合計 60 パック、週に 5 個、各キャンドル 2 本です。
コンポーネント需要 = 420 + (132 × 1) + (60 × 2) = 420 + 132 + 120 = 12 週間で 672 ユニット。これは、キャンドル自体の販売が示唆する1日あたり5.0個に対して、週に56個、または84日間で1日あたり8.0個に相当します。
独自の商品ページで販売されるユニット
2 つのバンドルによって消費されるユニット
実際に棚から出たユニット
5.0 スタンドアロンと比較した 1 日あたりの実際の単位
週ごとに、その差は平均よりも大きく変動します。
| 週 | スタンドアロン | バンドルから | 合計 |
|---|---|---|---|
| 1 | 34 | 14 | 48 |
| 2 | 36 | 26 | 62 |
| 3 | 33 | 19 | 52 |
| 4 | 35 | 36 | 71 |
| 5 | 36 | 11 | 47 |
| 6 | 34 | 22 | 56 |
| 7 | 35 | 20 | 55 |
| 8 | 37 | 26 | 63 |
| 9 | 34 | 17 | 51 |
| 10 | 36 | 23 | 59 |
| 11 | 35 | 18 | 53 |
| 12 | 35 | 20 | 55 |
スタンドアロンの列は一度も 38 に達しません。2 つのバンドルは不安定ですが、ローソク足は不安定なので、実際の週間ドローは第 4 週の 71 でピークに達します。コンポーネントの変動性は、コンポーネントが内部にあるバンドルから継承されます。そのため、製品に何も変更がないにもかかわらず、安定した SKU が不安定な SKU のように動作し始める可能性があります。
これで、同じ数字が二重にカウントされます。ローソク足の数値にすでにバンドル駆動ユニットが含まれている場合、420 ではなく 672 と表示されます。とにかくバンドル期間を追加すると、1 日あたり 11 ユニット、つまりストアで消費するユニットより 37.5% 多い 924 ユニットを計画することになります。 12 週間の 1 サイクルでは、ストリームが 2 回カウントされたため、252 本の余剰キャンドル、単価 7 ドルの現金 1,764 ドルの現金が棚に置かれています。
Shopify からデータを取得する
販売履歴の取得とクリーニングはそれ自体の仕事であり、以下で説明します。 Shopifyの販売データから需要を予測する。バンドルでは、そのプロセスに 1 つの質問が追加されます。数字が何かを意味する前に、それに答える必要があります。 目の前にあるコンポーネント図はスタンドアロンのみですか、それともバンドル駆動ユニットがすでに含まれていますか?
Shopify は、バンドルが販売されるとコンポーネントの在庫レベルが減少することを文書化しています。 Shopify のバンドル ページで文書化されていないのは、製品販売レポートでバンドル販売がどのように関連付けられるかということですが、その答えは Shopify 独自のバンドル アプリとサードパーティのバンドル アプリでは異なる可能性があります。したがって、これを含めて一般的な答えを受け取らないでください。テストしてみましょう:
- コンポーネントの現在利用可能な数量と、その日に販売されたユニットに注目してください。
- それを含むバンドルを既知の数量で実際に注文します。
- 予想される量だけ移動されたコンポーネントの利用可能な数量を確認します。
- 同じ日の製品バリアント別売上レポートを確認して、コンポーネントのユニット数も移動したか、バンドルのみが移動したかを確認します。
コンポーネントの売上高が変動した場合、レポートにはすでに合計需要が表示されており、バンドル期間は二重カウントになります。バンドルのみが移動された場合、コンポーネント Figure はスタンドアロンとなり、上記の計算が記載どおりに適用されます。バンドル アプリごとに 10 分で、仮説上の質問ではなく、ストアに関する質問が解決されます。
エクスポート中に取り除かなければならないことがもう 1 つあります。それは、コンポーネントまたはバンドルが利用できなかった数週間です。在庫切れは、販売レポートでは需要ゼロとまったく同じように見えます。また、別のコンポーネントが在庫切れになったために販売できなかったバンドルでは、このコンポーネントにもゼロが生成されます。
コンポーネントのポイントを並べ替える
式に関しては何も変わりません。の 再注文ポイントの式 平均日次売上高、リードタイム、安全在庫を計算します。バンドル コンポーネントは、異なる最初の入力を与えるだけです。
スギとイチジク、250g、30 ユニットのバッファーで 12 日間のリードタイム:
- スタンドアロン需要のみ: (5 × 12) + 30 = 90 単位。
- 合計需要: (8 × 12) + 30 = 126 単位。
両者の差は 36 個で、1 日あたり 8 個の実需は 4 日半です。トリガーを 90 に設定すると、大きな失敗はありません。サイクルごとに 4 日半遅れて起動され、わずかに重いバンドル週が到来するまでバッファーが差異を吸収しますが、そうではありません。これが、バンドル関連の在庫切れのほとんどの背後にあるパターンです。間違った方法ではなく、3 つのストリームのいずれかに適切な方法が供給されたのです。
実用的なメモが 2 つあります。バンドルにはトリガー対象となる独自のストックが存在しないため、バンドルではなくコンポーネントにトリガーを設定します。また、コンポーネントを含むバンドルが追加、廃止、または価格変更されるたびに、コンポーネントのレートを再計算します。これらのそれぞれによって、合計のいずれかの条件が変更されるためです。
プロモーションバンドル
バンドル プロモーションは、すべてのコンポーネントに対する需要が一度に急増するものであり、コンポーネントによってその感じ方が大きく異なります。隆起のサイズの推定については、 プロモーションと在庫予測。ここで重要なのは、それがどのように着陸するかです。
ギフトボックスが週 11 個ではなく 40 個で 2 週間稼働するとします。キャンドルの抽選は週 56 個から 85 個になり、約半分の増加になります。同じ箱に入っている芯トリマーは単体での販売がまったくないため、その集客は週に 11 件から 40 件と 4 倍近くになります。スタンドアロンの需要が最も少ないコンポーネントは、バンドル プロモーションからの相対的な影響が最も大きく、通常は誰も視聴しない安価なコンポーネントです。
2 つのルールが続きます。何かを注文する前に、プロモーションをバンドル単位ではなくコンポーネント単位に変換してください。また、すべてのコンポーネントの納期をプロモーション日と照らし合わせて確認してください。期限内に到着しないコンポーネントは、他のすべてのものをどれだけ購入したかに関係なく、すべてのコンポーネントに上限を設けるためです。
コンポーネントが制約の場合
Shopify はコンポーネント製品の在庫レベルからバンドルの在庫状況を導き出し、在庫レベルが最も低い製品によって販売できるバンドルの数が決まります。計画の観点から言えば、1 つのコンポーネントがバンドル全体の上限を所有しており、他のものを追加購入しても上限は上がりません。
210 本のキャンドルと 64 個のトリマーがあれば、64 個のギフト ボックスを販売できます。さらに 200 本のろうそくを置いても、その数はまったく変わりません。したがって、バンドルのレビュー順序は、金額ではなくカバーとリードタイムによって実行されます。各コンポーネントがその複合需要に対して何週間のカバーを持っているかを計算し、昇順に並べ替えます。そのリストの先頭がバンドルの実際の制約になります。多くの場合、これはボックス内で最も安価なラインであるため、最初にレビューされることはほとんどありません。その数字が食いつく前に落ちるのを見るのは同じ仕事です 在庫切れが起こる前に予測する、製品ではなくコンポーネントに適用されます。
3 つのストリーム、2 つのバンドル、1 つのストック プールをスプレッドシート内で整列させておくことは、1 つのバンドルに対しては実行可能ですが、すぐに見苦しくなります。 StockCueの予測は、無料を含むすべてのプランでバンドルを認識します。バンドル販売フローはコンポーネントの需要に至るため、コンポーネントの再注文ポイントは、独自の製品ページではなく、コンポーネントを消費するすべてのものに対して計算されます。
よくある質問
単独で販売される製品とバンドルで販売される製品の総需要を計算するにはどうすればよいですか?
コンポーネントのスタンドアロン販売数を、それを含むすべてのバンドルの販売数に加算し、各バンドルで使用されるコンポーネントの数を掛けます。 12 週間で単体で 420 ユニットを販売するコンポーネントに、それぞれ 1 つを使用するギフト ボックスが 132 個、さらに 2 つを使用するツイン パックが 60 個ある場合、実際の需要は 420 ではなく 672 ユニットになります。この合計が正しくなるには 2 つの条件が必要です。スタンドアロンの数値には、バンドル駆動のユニットが既に含まれていてはならず、3 つの履歴すべてがバンドルの発売後の同じ期間のものである必要があります。
バンドル販売はShopify製品販売レポートに表示されますか?
一般的な答えを信頼するのではなく、自分のストアで確認してください。 Shopifyのバンドルのドキュメントには、バンドルが販売されるとコンポーネントの在庫レベルが減少すると記載されていますが、製品販売レポートで売上がどのように関連付けられるかについての記述はそれらのページで見つかりませんでした。また、Shopifyのファーストパーティのバンドルアプリとサードパーティのバンドルアプリでは動作が異なる可能性があります。バンドルに対して 1 つのテスト注文を出し、製品バリアント別の売上レポートでコンポーネントのユニット数が移動したかどうかを確認します。この 1 回のテストで、コンポーネントの図がスタンドアロンのみであるか、バンドル需要がすでに含まれているかがわかります。下流のすべては、どちらであるかを知ることに依存します。
バンドルコンポーネントの再注文ポイントを設定するにはどうすればよいですか?
他のすべての場合に使用するのと同じ再注文ポイントの計算式を使用し、単独の需要ではなく、組み合わせた需要を毎日の売上入力として使用します。 84 日間で 672 ユニットを描画するコンポーネントの場合、つまり 1 日あたり 8 ユニットであるため、12 日のリードタイムでは、96 ユニットのリードタイム需要に安全バッファを加えたものになります。代わりに 1 日あたり 5 のスタンドアロン レートを使用すると、トリガーは 60 プラス バッファーに設定され、実際のレートをすでに超えた後に起動されます。
1 つのコンポーネントがなくなると、他のコンポーネントはどうなりますか?
Shopify はコンポーネント製品の在庫レベルからバンドルの在庫状況を導き出し、在庫レベルが最も低い製品によって販売できるバンドル数が決定されるため、バンドルは販売できなくなります。他のコンポーネントはスタンドアロンの需要を維持し、特にバンドル内に配置するために購入したユニットは、不足しているコンポーネントが戻るまで動作を停止します。そのため、売上が最も高いコンポーネントではなく、リードタイムが最も長いコンポーネントが最も早い再注文トリガーに値します。
STOCKCUE
購入サイクルごとに 3 つの需要の流れを手動で合計することは、静かにその発生を停止するステップです。 StockCue の予測は、無料を含むすべてのプランでバンドルを認識するため、コンポーネントの再注文ポイントは、それを使用するバンドルをすでに考慮しています。
Shopify に StockCue をインストール →