高SKU店舗の在庫計画

1,200 SKU のカタログでは、毎週 1,200 件の購入決定が行われるわけではありません。 30個ほど生産します。大規模なカタログを計画する際の難しい部分は、すべてを見直すことではなく、すべてを人が考えなければならない 30 項目に変えるフィルターを構築することです。

在庫に関するアドバイスのほとんどは、頭の中に保持できるカタログ用に書かれています。同じ仕事でもできないときはこんな感じです。手動レビューと自動レビューの境界線はどこにあるのか、またなぜそこにあるのかについては、次の記事で説明しています。 自動並べ替えと手動並べ替え;この投稿はその線の向こう側から始めて、それが残した運用上の問題を扱います。

数百 SKU を超えると何が変わるのか

各 SKU に 90 秒を与えます。これは、手元の在庫を確認し、過去数週間の売上をざっと確認し、すでに処理中の注文書があるかどうかを確認するには十分な長さです。どれについても適切に考えるのに十分な時間はありません。次に、乗算します。

その算術こそが問題なのです。レビューの時間はカタログ サイズに応じて調整されますが、週はそうではありません。そのため、数百の SKU 未満のどこかで完全なパスが適合しなくなり、誰も 1 つとしてラベル付けしない部分的なパスになります。レビューは引き続きカレンダー上で行われます。カタログをカバーしなくなるだけです。

2 番目に変わるのは、間違いの形状です。小さなカタログでは製品のことを知っているため、間違いは通常、自分が気づいて間違えたものです。大きなエラーの場合、そのエラーは誰も見ていないものです。 SKU は、プロセスのどの段階でもそれが取り上げられなかったため、誰一人意見を形成することなく 11 日間ゼロのままになることがあります。沈黙は物事がうまくいっている証拠ではなくなります。

3 番目の変更は、作業単位が移動することです。数十の SKU の下では、製品ごとに計画します。カタログには 9 社のサプライヤーが含まれており、実際に送信するのはサプライヤーの注文であり、個々の SKU に関する決定は、最小注文金額、ケースパック、今週このベンダーに注文を開始する価値があるかどうかなど、発送される順序によって制約されます。 SKU ごとに SKU を計画し、最小限のサプライヤーを見つけると、先ほど行ったレビューが無駄になります。

最初にセグメント化してから、例外ごとにレビューします

2 つのフィルターをこの順序で適用します。 1 つ目は、今週どの製品が注目に値するかを決定します。 2 つ目は、実際に決定が必要なのはどれかを決定します。

セグメンテーションは耐久性のあるフィルターです。通常は四半期に 1 回、ゆっくりと変化し、製品の収益とその需要の予測可能性によってカタログを分割します。両方の等級の背後にある計算については、次のとおりです。 ABC-XYZ在庫分析、および結果として得られる層を処理する順序 (各層が確認される頻度を含む) は、次のとおりです。 再注文する商品の優先順位付け。どちらも、この投稿の主題ではなく、ここでの前提条件です。

例外ルールは毎週のフィルターであり、ほとんどの店舗が決して書き留めない部分です。例外ルールは、true の場合、SKU を人間の前に置く条件です。他のものはすべて邪魔になりません。実用的なスターティングセット:

これらをサンプル ストア (1,200 SKU、9 サプライヤー、1 か所) で実行します。 1,200 人のうち、180 人がウィークリー層にいます。ルールは、そのうち 23 件が再注文ポイントを下回っており、5 件は注文が約束日を過ぎており、7 件は予測がしきい値を超えていたとフラグを立てます。 4 つの SKU は一度に 2 つのルールをトリップするため、1 週間のキューは 1,200 ではなく 31 製品になります。

毎週の買い物ルーティン

フィルターが存在すると、ルーチンは保護するのに十分短いものになります。 31 件の決定をそれぞれ約 2 分で行うと約 1 時間になりますが、1 時間あれば忙しい一週間を乗り切ることができます。

フィルタを実行します。閲覧はしません。 大きなカタログには、何か間違っているものがないかを探してスクロールしてしまうという誘惑があります。スクロールすると、視覚的に印象的なものはすべて見つかりますが、緊急のものとは異なり、はるかに時間がかかります。

数量を決定する前に、サプライヤーごとにグループ化します。 1 つのベンダーからの 6 つの SKU は、1 回の注文と 1 回の送料です。同じ 6 つを 3 つのベンダーに分散させるのは、まったく異なる決定です。最初にグループ化すると、前倒しする価値のあるニアミスも表面化します。つまり、再注文時点から 2 週間後の SKU は、いずれにせよ出荷される注文に追加する価値があります。

キューにあるものについてのみ数量を決定します。 それ以外のすべてはルールによってすでにレビューされています。

約束の日付を記録して送信します。 約束日がどこかに保存されていない場合、注文遅延ルールは比較するものが何もなく、2 番目の例外ルールは実行されなくなります。

意図的にスキップした内容とその理由を書き留めます。 これは誰もが落とすステップです。これがないと、意識的に再注文しないと決めた SKU が毎週再びキューに表示され、キューによって徐々に SKU を無視するよう訓練されてしまいます。

週次以下の階層では、より長いクロックで同じルーチンが実行されます。月次でカタログの中央を通過し、四半期ごとに末尾をスイープします。これは、ほとんどの店舗にとって、再注文というよりも、何が存続すべきかを決定することに重点が置かれています。

自動化する必要があるもの

テストは簡単です。人が覚えているかどうかに関係なく、起こらなければならないことはすべて自動化の対象となります。売上データ以外からの理由が必要なものはそうではありません。すべての大規模なカタログのメモリ テストで 4 つの項目が不合格になります。

SKU ごとに再計算された販売速度。 速度は他のほぼすべての数値の入力であり、常に変動します。大規模なカタログ全体にわたって手動で再計算することは難しくありませんが、継続するのが不可能なだけです。

ポイントを並べ替えます。速度とリードタイムの​​移動に応じて再計算されます。 再注文ポイントは、その後ろにある 2 つの数字が存在する限りのみ正しいものとなります。サプライヤーが 12 日から 19 日にずれても、シート上の数字は問題ではなく、間違っているだけです。実際にその再計算がどのように機能するかについては、次の記事で説明します。 自動再注文の推奨事項。

例外スキャン自体。 スキャンは毎週実行するよりも毎日実行する価値があります。実行にコストがかからず、最大 6 日後ではなく、発生した当日に交差点を捕捉できるからです。

注文書のステータス。 注文を追跡する時間がまだある間に、誰かが注文が約束の日付を過ぎていることに気づく必要があります。これは予定された比較であり、判断ではありません。

これら 4 つを自動化するということは、ファイル以外の何かがサプライヤーの記録、リードタイム、再注文パラメータを保持し、時計に従って実行する必要があることを意味します。 StockCue ここでは、ほとんどの投稿よりもプランの制限が重要です。無料利用枠は 50 SKU をカバーしますが、これはどの定義から見ても高 SKU ストアではないため、このサイズのカタログは、最大 2,000 SKU の拡張または無制限の拡張を意味します。季節調整を伴う予測は無料を含むすべてのプランで実行されますが、発注書、受け取り、在庫数はスターターから開始されるため、数量だけでなく購入ワークフローも必要なストアは最初から有料レベルを検討しています。

マニュアルのままにしておくべきもの

例外ルールは、それに気づくのは得意ですが、その理由を知るのは苦手です。以下のすべては、その理由が販売履歴の外にある決定であり、まさに自動化ルールが機能しない場所です。

既知の一回限りのものすべて。 来月のプロモーション、サプライヤーの最低注文数量の変更、卸売アカウントが一度大量の注文をした後、それを繰り返さないなど。歴史は一つのことを語りますが、あなたは別のことを知っています。

新製品。 販売履歴のない SKU は、ルールに従って計画することはできません。見積もりの​​みを行ってから、最初の数週間は注意深く監視します。

承認自体。 間違ったリードタイムに基づいて構築された推奨事項は、目に見えて間違っているというよりは、明らかに間違っており、自動化をいくら行っても、それ自体の不適切な入力にフラグを立てることはできません。誰かがその数字を見て、それが注文になる前に妥当であると判断する必要があります。

製品を引き続きカタログに掲載するかどうか。 いかなる例外ルールも「これを運ぶのをやめてください」を発動することはありません。中止はマージン、ストレージ、範囲に関する商業上の決定であり、SKU が削除されるたびにシステム全体で保持する必要があるものが 1 つ減るため、これは高 SKU ストアが実行できる単一の最高価値の手動パスです。

スプレッドシートから離れる

「スプレッドシートを使用せずに 1,000 の SKU を管理する」という表現がこの問題をよく言いますが、これは問題を少し誤って診断します。行数は壊れるものではありません。スプレッドシートは文句なしに 1,200 行を保持し、どのアプリよりも速く並べ替え、各行の再注文ポイントを喜んで計算します。

スプレッドシートでできないことは、スプレッドシートが閉じている間に操作を行うことです。その中のすべての再計算は、人が再計算をすることを忘れないことによって行われます。火曜日に誰も開かなければ、ファイル内の何も実行されず、ファイル内の何も手を挙げず、ファイル内の数値は、誰かが最後に自由な午後を過ごしたときとまったく同じくらい新鮮なままです。 40 SKU の場合、その差は数分の作業です。 1,200 では、実行されるフィルターと原理的に存在するフィルターの違いになります。

通常、移動のクリーン バージョンは削除ではありません。再計算をツールに移行しているほとんどの店舗では、サプライヤーの癖、ケースパックのルール、8 月に 3 週間休業するベンダーに関するメモなど、常に優れていたものをファイルに保存しています。このように分割してもコストはかからず、どのソフトウェアにもフィールドが存在しないコンテキストが維持されます。

その取引をする価値があるかどうか、切り替えるのにどれくらいの費用がかかるか、そして正直な答えは今いる場所にそのまま留まるというストアプロファイルについては、独自の分析に値する決定です。 スプレッドシートと在庫計画ソフトウェアの比較 スプレッドシートが完全に勝つ場合も含めて、それを乗り越えます。

よくある質問

1,000 以上の SKU の在庫をどのように管理していますか?

レビューではなくフィルタリングによって。カタログをセグメント化して、小さな層が頻繁に注目され、残りがより長いサイクルで実行されるようにしてから、例外ルール (再注文ポイントを下回っている、約束日を過ぎた注文、大幅に変動した予測) を適用して、決定が必要な製品のみが届くようにします。大規模なカタログで進行中の作業は、すべての製品を調べるのではなく、そのフィルターを維持することです。

SKU の高いストアはどのくらいの頻度で再注文ポイントを確認する必要がありますか?

再注文ポイントは、背後にある入力が変動するたびに再計算する必要があります。再注文ポイントは、速い売り手の場合は毎週を意味し、安定した遅い売り手の場合は四半期ごとを意味します。間隔は、再計算を誰かが忘れずに行われるかどうかほど重要ではありません。これは、数か月前に設定された再注文ポイントが目に見えてではなく暗黙的に失効するためです。収益貢献と需要の変動に応じてカタログを階層化するのが、管理しやすくするための通常の方法です。

大規模なカタログで最初に自動化すべきものは何ですか?

販売速度と再注文ポイントの再計算。これは、誰かがファイルを開くかどうかに関係なく、スケジュールに従って実行する必要がある部分だからです。次に例外スキャンが行われます。レビュー日ではなく毎日、現在の在庫と現在の再注文ポイントを比較する必要があります。注文書のステータスが 3 番目です。納期の遅れは、追跡する時間がまだある間は有益な情報にすぎないためです。

スプレッドシートで 1,000 の SKU を実行できますか?

はい、多くの店舗がそうしています。スプレッドシートは 1,000 行を問題なく処理できます。できないことは、閉じている間に何かを再計算したり、最後に見てから何かが変わったことを知らせたりすることです。その取引にお金を払う価値があるかどうかは、実際にどのくらいの検討時間がかかるか、また再注文を逃した場合にどのくらいの費用がかかるかによって決まります。