エクセル在庫管理「壊れる前に起きていたこと」——現場3社の失敗から読み解く、見直しの起点 ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

 

Column

コラム

エクセル在庫管理「壊れる前に起きていたこと」——現場3社の失敗から読み解く、見直しの起点


TwitterFacebookLine

エクセル在庫管理「壊れる前に起きていたこと」——現場3社の失敗から読み解く、見直しの起点

執筆:Spes編集部

「在庫が合わない」と気づいたとき、たいていのケースではすでに何かが壊れた後だ。欠品・過剰在庫・棚卸差異——どれも発覚するのは結果であって、原因はもっと前の「静かな積み重ね」にある。

このコラムでは、エクセル在庫管理が実際に機能不全に陥った3つの現場事例を先に示し、「何が失敗の引き金になったか」を逆算して整理する。チェックリストや移行手順より先に、失敗のパターンを自社と照らし合わせてほしい

図:エクセル在庫管理が実際に崩れた3社のパターン(業種別)

Case A:製造業——「前任者しか知らなかった」入力ルール

Photo by Alexander Isreb on Pexels
Photo by Alexander Isreb on Pexels

金属部品の製造を手がける従業員35名の工場では、在庫管理のエクセルを10年以上ベテラン担当の渡辺さんが一人で維持してきた。シートの構造は複雑で、品番・ロット・保管場所を連携させるマクロが組まれていたが、そのロジックを理解していたのは渡辺さんだけだった。

渡辺さんが異動になった翌月、後任の山田さんが在庫数を手入力で修正したところ、マクロが意図しない動作をして部品の出庫数がマイナス表示に。在庫が「ある」ように見えた部品が実際はゼロで、ラインが15分間停止する事態になった。

この失敗が示すのは、在庫管理の「精度」より先に「運用可能性」が崩れるという順序だ。数式が正しくても、それを安全に使える人が限定されている状態は、すでにリスクを抱えている。業務が継続できるかどうかは「担当者の交代耐性」で決まる局面が多い。

この失敗が示す判断ポイント
エクセルの構造を「説明できる人が1人だけ」なら、それ自体がリスク。入力ルール・マクロの意図・例外処理の手順を誰でも参照できる状態にしておく必要がある。できない場合、ツールの乗り換えを検討する段階に来ている可能性が高い。

Case B:小売業——ファイル分散が生んだ「見えない二重発注」

Photo by Tima Miroshnichenko on Pexels
Photo by Tima Miroshnichenko on Pexels

日用品を扱う3店舗展開の小売チェーンでは、各店舗が独自のエクセルで在庫を管理し、週1回エリアマネージャーの鈴木さんがそれを集計していた。集計作業自体は手慣れたもので、問題は長らく表面化しなかった。

状況が変わったのは、仕入れ担当を変えたタイミングだ。新任担当の中村さんは集計前の各店舗ファイルを見て発注数を決めていたが、鈴木さんの集計ファイルとは更新タイミングがズレており、同じ商品を2つのルートで発注してしまった。結果、人気商品40個が過剰入荷。最終的に半数近くを値引き処分することになった。

ファイル分散環境では「最新の在庫数がどこにあるか」が常に曖昧になる。これは悪意でも注意不足でもなく、複数人が独立したファイルを持つ構造そのものの問題だ。店舗数が増えるほど、あるいは担当者が変わるほど、同様の事故が起きやすくなる。

図:ファイル分散環境では「どのファイルが正」か常に曖昧になる

Case C:EC事業者——繁忙期の手動転記が招いた過剰販売

アパレルEC事業者(楽天・Amazon・自社サイトの3モール展開)では、在庫数をエクセルで一元管理し、各モールの在庫設定は手動で更新していた。平時は担当の伊藤さんが15〜20分かけて3モールを更新するルーティンが機能していた。

問題が発生したのはセール期間中だ。売れ行きが想定の3倍に加速し、伊藤さんが楽天とAmazonを更新した後、自社サイトを更新するまでのわずか30分の間に自社サイトで在庫以上の注文が確定した。キャンセル対応・謝罪メール・返金手続きで約2日間の工数が消えた。

ECの場合、繁忙期の売れ行き加速そのものは「望ましい状態」だ。しかし手動転記の運用では、需要の高まりが直接的に在庫管理の破綻リスクになる。売上増加と運用負荷が比例する構造は、事業が伸びるほど危うくなる

在庫連携の自動化(例えばネクストエンジンのような受注・在庫一元管理ツールとの連携)があれば、モールをまたぐ在庫の同期を自動化でき、手動転記の遅延リスクを構造的に排除できる。導入コストと照らしながら、「繁忙期に同じ失敗をあと何回するか」で費用対効果を試算するのが現実的な判断軸になる。

3つの失敗に共通する「壊れる前の징候」

事例を並べると、業種は違っても失敗の前段階には共通したサインがあることが分かる。

징候具体的な場面リスクレベル
入力ルールが属人化している「あの人がいないと分からない」が常態化
複数ファイルに分散している「最新はどこ?」が発生する
更新に時間差がある「今の在庫」が常にズレている中〜高
需要増加・担当者変更で負荷が急増する繁忙期・異動・採用直後に事故が集中する
差異の原因が追えない棚卸の結果が合わなくても「なぜ」が分からない

これらの징候は、在庫数字そのものが崩れる前から現場に現れていることが多い。「まだ回っている」は「問題がない」とは違う。手が足りていて偶然抑えられているだけの状態は、担当者の交代や繁忙期が引き金になって表面化する。

現状を見直す起点——「何をやめるか」から考える

エクセルから別のツールに移行する判断は、「完全に壊れてから」では遅い。一方で、「とりあえずシステムを入れる」でも失敗する。3社の事例から導ける現実的な順番は以下の通りだ。

  1. 今の運用の「交代耐性」を確認する——担当者が1週間不在になったとき、在庫管理が維持できるか
  2. ファイルの分散数を数える——在庫に関するエクセルが何個存在するか棚卸しする
  3. 「更新タイムラグ」が許容できるか業種ごとに判断する——EC・小売は即時性が求められる。製造業は品目・ロットの追跡性が優先される
  4. ツール検討は「やめる作業」を決めてから——何を手動でやらなくするかが決まれば、必要な機能の要件が絞れる

クラウド型の在庫・受発注管理ツール(Spesのようなバーコード連携・複数拠点一元管理に対応したSaaS)は、上記の運用課題に対して「入力の自動化」「ファイル統合」「リアルタイム在庫確認」という形で対応できる。ただし自社の「どの失敗を先になくすか」が整理できていないと、導入後の活用精度が下がる

現場の課題を整理した上で、具体的な仕組みの選び方を相談したい場合は、こちらからお問い合わせください。業種・規模・現在の運用状況をヒアリングした上でご案内します。

よくある質問

エクセルをやめるタイミングはいつが正解ですか?

「壊れてから」は遅い。判断の起点は、①担当者交代後に運用が続けられるか、②更新タイムラグによる誤発注・欠品がすでに起きているか、の2点で確認するのが実際的だ。どちらかが「怪しい」と感じるなら、移行の検討を始めるタイミングとして見てよい。

SKU数が少なければエクセルで十分ではないですか?

SKU数より「運用する人数」と「更新頻度」のほうが重要なことが多い。SKUが10品目でも、複数人が別々のタイミングで更新するなら分散・タイムラグのリスクは生じる。逆に1人が管理し更新頻度も低い環境では、シンプルなエクセル管理が合理的な場合もある。

ツール移行で現場の抵抗を減らすにはどうすればいいですか?

「使い方を覚えるコスト」と「今の失敗が繰り返されるコスト」を並べて現場と共有するのが実際に機能しやすい。「便利になる」より「あの棚卸差異がなくなる」という具体的な課題解決として伝えると受け入れられやすい。

本記事で取り上げた参考統計データの一次情報はe-Stat(政府統計ポータル)で確認できます。業種別の中小企業実態調査なども同ポータルから参照できます。

TwitterFacebookLine