すべてのガイド

によって 2026 年 9 月 6 日8 分で読めます

在庫スプレッドシートが機能しなくなったとき

スプレッドシートは、速度が失われ、何もアラートが発せられず、コミットされた在庫が表示されなくなるまで機能します。 4 つの失敗を表示順に示します。

スプレッドシートは特定の火曜日に動作を停止しません。そこに含まれるすべての数値は、入力された瞬間は正確であり、正確でなくなった後もまったく同じ信頼性で表示され続けます。これが障害モード全体であり、以下の 4 つのセクションはその 4 つのバージョンです。

この投稿は診断です。これは何かを買うべきだという議論ではなく、意図的に代替品の価格を設定しません。また、ファイル内にも残ります。販売データ、購入プロセス、資金ポジションなど、他の場所に現れる症状については、 店舗が手動予測を超えて成長している 10 の兆候 チェックリストです。

スプレッドシートが正常に開始される場所

小規模なカタログの場合、スプレッドシートは優れた在庫ツールであり、使用する上で妥協を感じる必要はありません。費用はかかりません。そこに含まれるすべての数値はあなた自身が計算したものであるため、あなた自身の推論との間にダッシュボードはありません。ソフトウェア モデルがないものなど、あらゆるものを列に追加できます。たとえば、11 月ではなく 3 月には信頼できるサプライヤー、ひっそりと製造中止する製品、年に 2 回まとめ買いする顧客などです。

数十の製品、1 つのサプライヤー、1 つの拠点がある場合、スプレッドシートで月次レビューを行うことで、把握する価値のあるものはすべて把握できます。以下にこれに矛盾するものはありません。

スプレッドシートには何が真実であったかが記録されます。それがいつなくなったのかを知る方法はありません。

以下に、スプレッドシートが構造的に実行できない 4 つのことを、通常重要になる順序で並べて示します。それらは蓄積されます。 4 番目が表示されるまでに、最初の 3 つはまだそこにあります。

Four spreadsheet failures accumulating as a store growsFour horizontal bands are stacked above a growth axis that runs left to right as catalog size, order types and the number of people with edit access all increase. Each band begins at a different point along that axis and then continues to the right edge without ending. Stale sales velocity begins first, when a single product changes pace. Missing alerts begin next, once there are too many products to check by eye. Invisible committed stock begins third, once pre-orders, wholesale or a second sales channel create a gap between the stock you own and the stock you can sell. Version drift begins last, when a second person gains edit access. Because no band ever stops, the fourth problem always arrives on top of the first three rather than replacing them.Nothing gets fixed by the next failure arrivingeach failure starts at its own point and stays1. velocity goes stale2. nothing fires an alert3. committed stock invisible4. version driftone SKU speeds uptoo many to eyeballpre-orders, wholesalea second editorcatalog size, order types, and people with edit access →
タイミングよりも順番の方が信頼できる。同じサイズの 2 つのストアは、注文タイプの数と途中でピックアップした編集者の数に応じて、この軸上の異なる点に位置する可能性があります。

失敗 1: ベロシティが古くなってしまう

ファイル内のどこかに、1 日あたりの単位数の列があります。他のすべての計算は、再注文ポイント、カバーの週数、推奨注文数量などに依存します。これは、毎日変更される唯一の列であり、手動で更新される頻度が最も低い列でもあります。

1日5単位入力すると、正解でした。この製品は現在 11 を販売しています。ファイル オブジェクトには何もありません。数式が実行され、並べ替えポイントは依然としてきれいな数値として表示され、シートは正しいときとまったく同じように表示されます。棚が空になった時点で、配達は 1 週間後であることがわかります。

これは、単一の製品の変更ペースだけが必要なため、最初に到着します。これは、どのカタログ サイズでも発生する可能性があります。明らかな解決策は、速度をより頻繁に再計算することです。これは、意味のある変更の間隔よりも再計算に時間がかかるまで機能します。 独自の Shopify 販売データから需要を導き出す 過去 90 日間の平均を超える、防御可能なベロシティの数値が実際に必要とする数値をカバーしています。

失敗 2: 何もアラートが起動されない

スプレッドシートはプル システムです。それは開いたときだけ真実です。列 F に完璧な再注文ポイントがあっても、ファイルからその数値を超えるものは何も表示されないため、それでも不足する可能性があります。

ファイルは間違っていないため、これは最も過小評価されやすい失敗です。その中のすべての計算は正しいです。ギャップは完全に配信にあり、スプレッドシートをいくら改善してもギャップは埋まりません。条件付き書式を設定するとセルが赤くなりますが、誰かが見ているときはセルはまだ赤だけです。

Shopify 独自の低在庫バッジも同じ形をしています。これは、受信するメッセージではなく、アクセスするフィルターです。実際の通知への無料のネイティブ ルートは Shopify Flow ワークフローであり、両方のセットアップについては「 Shopify 在庫不足アラートのガイド。 2 番目に到着するのは、ファイルを開くまでの間にレビューを頭の中に留めておくことができないほどの製品だけが必要なためです。また、カタログが十分に大きくなり、レビューですべてをカバーできなくなると、 高 SKU カタログ全体での例外ごとの計画 これに代わる運用上の問題です。

失敗 3: コミットされた在庫が表示されない

スプレッドシートには製品ごとに 1 つの数値が保持されます。 Shopify はバリエーションごとに複数の異なる数量を保持しており、それらは交換可能ではありません。どちらをインポートまたは入力したかが、シートの「いくつあるか」という概念全体になります。

物理的に部屋にあるものと一致する数であるため、ほとんどの人が手元に持ち歩いています。手持には、まだ出荷していない注文に対してすでにコミットされているユニットが含まれます。したがって、卸売注文または一連の予約注文では、まだ棚に置かれ、シートにカウントされ、販売不可能になった 40 個のユニットが予約されます。シートには2週間の保証期間があると書かれていますが、店頭には売り切れと表示されています。在庫が入ってくると、鏡像エラーが発生します。つまり、未処理の発注書にあるユニットが手元にないため、手持に基づいて構築されたシートが喜んで 2 回目の発注を推奨します。

これらの量、それぞれが何を意味し、何がそれらを動かすのかについては、次のセクションで適切に説明されています。 Shopifyの在庫追跡の仕組み。スプレッドシートのポイントはさらに狭いです。スプレッドシートには 1 つのスロットがあり、プラットフォームには複数のスロットがあるため、ファイルが更新されるたびに誰かの頭の中で調整が行われる必要があります。これは、さらなる成長ではなく、特定の種類の成長を必要とする失敗です。予約注文や卸売りを行わず、1 つのチャネルを販売するストアでは、その条件を満たすことはできないかもしれません。

失敗 4: バージョンのドリフト

2 人目の人がファイルを編集できるようになったり、1 人が 2 台のマシンからファイルを編集したり、毎月のコピーがバックアップとして取得されたりした瞬間には、真実の複数のバージョンが存在し、どれが最新であるかを判断する信頼できる方法はありません。共有クラウドシートはドリフトではなくコピーを解決します。

具体的な被害は、手動によるオーバーライドが事後の計算と区別がつかないことです。荷物が届くことがわかっているので、数式に 200 と入力する人がいます。 3 週間後、セルの読み取り値は 200 になり、行上の他のすべてのセルとまったく同じように見えます。誰が、いつ、なぜ設定したかについての記録はないため、ファイルを監査する唯一の方法はファイルを再取得することです。カウントとレコードが一致しない場合、常に問題となるのは、何がいつ変更されたかということですが、スプレッドシートではどのような質問に答えることが最も困難ですか。 在庫の不一致を防ぐ その調査が実際に何を含むのかを説明します。

これはありきたりな理由で最後に到着します。ほとんどの店舗では、商品、注文の種類、チャネルを追加するよりも後、購入プロセスに 2 人目の人を追加します。

修正する価値がなくなった点

これらのそれぞれには、スプレッドシート内に存在する修正が含まれています。スケジュールされたエクスポートまたはライブ接続により、速度が常に最新の状態に保たれます。カレンダーリマインダーはアラートを半分解決します。入荷が必要になるまで、手持在庫ではなく利用可能なインポートを行うことで、コミットされた在庫が処理されます。ロックされたセル、変更ログ、および 1 人の所有者により、ドリフトが軽減されます。

それらはすべて機能します。それらのそれぞれは、スプレッドシートに保守が必要な何かを追加するものでもあり、その保守は、そもそもスプレッドシートに留まることで回避できたコストとなります。

したがって、有用なテストは製品数ではありません。それは、意思決定にツールを使用するのではなく、ツールを正しく保つことに時間を費やしているかということです。信頼できるようになるまでに毎週 1 時間のメンテナンスが必要なスプレッドシートは、静かに管理するシステムになっています。この時点で比較を実行する価値があり、手動の維持と自動の再計算を比較することが重要です。 自動並べ替えと手動並べ替え のためのものです。決定は診断とは別の作業であり、この投稿は診断のみです。 スプレッドシートと計画ソフトウェアの決定 ゲートの有無、双方の実際のコスト、ファイルを保持することが正しい答えとなるケースについて説明します。

私たちは在庫アプリを作成しているので、1 つ開示します。 StockCue はその比較におけるオプションの 1 つであり、その無料プランは 50 SKU をカバーしており、何かを決定する前にその数値を自分のシートと比較して確認するには十分です。

STOCKCUE

特に最初の失敗をテストしたい場合、StockCue は無料を含むすべてのプランでの自分の注文履歴からベロシティと再注文ポイントを再計算します。そのため、購入方法を変更することなく、その数値をスプレッドシートの数値と比較できます。

Shopify に StockCue をインストール →

よくある質問

店舗が成長するにつれて在庫スプレッドシートが機能しなくなるのはなぜですか?

スプレッドシートには、誰かが入力した瞬間に何が真実であったかが記録されており、それが真実でなくなったことに気づくメカニズムがないからです。販売速度は変化し、注文はまだ物理的に棚にある在庫をコミットし、2 人目の担当者が 2 番目のコピーを編集します。すべてのセルは引き続き表示され、すべての数式は引き続き計算されるため、ファイルは入力が古くなったという信号を出しません。

実際にスプレッドシートで追跡できる SKU の数はいくつですか?

固定された数はなく、製品数は見た目よりも弱い予測因子です。このサイトの再注文ポイント ガイドでは、月次レビューを行うスプレッドシートの実際的な上限を約 30 SKU としていますが、これは妥当な開始値です。 3 つのサプライヤーと 1 つの卸売チャネルを持つ 15 の不安定な製品のカタログは、1 つのサプライヤーと 1 つの販売チャネルを持つ 60 の安定した製品よりも早くスプレッドシートを超えてしまいます。

スプレッドシートでコミットメント在庫を計算できますか?

手持数量ではなく利用可能な数量を意図的にインポートし、それをインポートし続ける場合に限ります。 Shopify はバリエーションごとに複数の個別の数量を追跡し、スプレッドシートにはほとんどの場合、製品ごとに 1 つの数値が保持されます。その数が手元にある場合、未履行の注文に対してすでに予約されているユニットが暗黙的に含まれるため、シートには買い物客が実際に購入できる数量よりも高く表示されます。

在庫スプレッドシートで最初にブレイクするものは何でしょうか?

通常、販売速度。これは他のすべての計算が依存する入力であり、毎日変更され、手動で更新される頻度は最も低くなります。また、サイレントに失敗します。その下流の再注文ポイントとカバー数値は計算を続け、正しく見え続けます。これらは、存在しないストアに関する質問に答えているだけです。

Shovon 氏、Devmerx 社ソフトウェア エンジニア

Shovon

ソフトウェアエンジニア

Shovon は、StockCue: Inventory Forecast の背後にあるスタジオである Devmerx の Shopify 在庫運用について書いています。

Shopify ストアに関してサポートが必要ですか?

Devmerx は、DTC ブランド向けに Shopify ストアを構築および最適化します。 20分間の無料相談をご予約ください。