大企業の在庫管理システム刷新、なぜ「失敗」するのか——3つの実例から見えた、プロジェクト崩壊の共通パターン ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

失敗事例1：「現場データの統合」を後回しにした製造業大手

従業員3,000名規模の機械部品メーカーで、老朽化した在庫管理システムの全面刷新プロジェクトが始動した。情報システム部門の渡辺部長が陣頭指揮を執り、外部ベンダーと18か月のスケジュールで合意した。

問題が表面化したのは、本番稼働の3か月前だ。各工場が長年使い続けてきた独自の在庫コードと、新システムの品番体系が一致しないことが発覚した。A工場では「W-1024」、B工場では「WH1024」と表記されてきた同一品番が、新システムでは統一ルールを設けないまま移行されようとしていた。

「現場コードの統一は運用開始後に対応する」という判断が、プロジェクト初期に下されていた。結果として、稼働後も在庫の突き合わせに人手が必要な状態が続き、「旧システムと並行して管理しないといけない」という状況が8か月間続いた。

稼働後に発覚する「コード体系の不一致」は、大企業の刷新プロジェクトで最も頻繁に報告される失敗の一つだ。工場や倉庫が多いほど、統一にかかる調整コストは指数的に増える。

失敗事例2：ROIを定義しないまま承認を取った小売チェーン

全国200店舗を展開する小売チェーンの経営企画部門が、在庫管理システムの刷新をCEOに提案した。「在庫最適化でコストを削減できる」というスライドが経営会議を通過し、予算3億円が下りた。

しかし、誰も「どの数値が何%改善されれば成功か」を決めていなかった。

稼働後1年が経過しても、在庫回転率の改善幅は計測されず、廃棄ロスの前後比較もなされないまま「概ね順調」という報告が上がり続けた。2年後、外部コンサルタントが入った際に初めて、欠品率は横ばい、廃棄コストは微増という実態が判明した。

総務省が提示するデジタル化推進のガイドラインでも、大企業のDX施策における投資対効果（ROI）と定量目標の事前設定の重要性が繰り返し指摘されている（参考：総務省）。システム刷新の成否判定指標を「稼働前」に合意しておかないと、改善が進んでいるのか止まっているのか、誰にも判断できなくなる。

失敗事例3：統合先が決まらないまま移行を始めた総合商社

複数の事業部門を抱える総合商社が、部門ごとに乱立していた在庫管理システムを一本化するプロジェクトを立ち上げた。情報システム部門の伊藤マネージャーが各部門との折衝役を担ったが、「どの部門の業務フローを基準にするか」という合意が取れないまま、要件定義が始まった。

食品部門は「賞味期限管理が必須」と主張し、工業品部門は「ロット追跡を最優先にすべき」と譲らなかった。折衷案を積み重ねた結果、すべての部門の要求を「盛り込んだ」システムが設計されたが、誰にとっても操作が複雑で、現場担当者の研修に予定外の3か月を要した。

政府統計（参考：e-Stat（政府統計ポータル））でも、大企業の情報システム刷新における稼働後の運用定着率は、プロジェクト前の現場ヒアリング精度と相関することが各種調査で示されている。既存システムの統合・クラウド移行・現場データの一元化が成功の条件として挙げられているが、前提となる「統合対象の優先順位付け」が不十分だと、稼働後の定着率を大きく損なう。

3つの失敗に共通していた「プロジェクト設計の穴」

3つの事例を並べると、表面的な原因（コード不一致・ROI未定義・要件の拡散）は異なるが、根底にある構造は同じだ。「後で決める」「稼働してから調整する」という先送りが、大企業特有の組織慣性と組み合わさって、是正のタイミングを失わせる。

中小企業であれば、稼働後に問題が出ても担当者数名で即座に対処できる。しかし大企業では、部門間の合意プロセスだけで数週間を要し、その間も旧来の二重管理が続く。システム刷新プロジェクトのコストの大半は、この「稼働後の修正」フェーズで発生するケースが多い。

刷新プロジェクトを立て直すために、先に決めるべき3つのこと

失敗事例の逆算から、プロジェクト開始前に合意しておくべき事項が浮かび上がる。

• マスタデータの統一基準：拠点・部門ごとの在庫コード、品番表記、ステータス定義を一本化し、移行前に全拠点で確認する。「稼働後に整理する」は機能しない。
• 成功指標と計測タイミング：在庫回転率・欠品率・廃棄コスト・工数削減率のうち、どれを・いつまでに・何%改善するかを承認前に文書化する。「概ね改善」という表現は禁止ワードとして扱う。
• 業務フローの優先順位：複数部門が関与する場合、どの部門のフローを「基準」にし、他部門はそこに合わせるか別途設計するかを事前に決定する。全員の要求を同等に盛り込もうとすると、誰も使いこなせないシステムが生まれる。

これらは技術的な問題ではなく、組織的な合意の問題だ。情報システム部門が単独で解決できる性質のものではなく、経営層と現場責任者が同じテーブルについて決定する必要がある。

クラウド移行・一元化を進める際の現実的な着地点

既存システムの統合やクラウド移行を伴う刷新では、「全機能を一度に移行する」アプローチが最もリスクが高い。現場で機能している部分を先に温存し、段階的に移行範囲を広げる設計が、大企業では現実的な選択肢になることが多い。

在庫管理の一元化においては、複数拠点・複数倉庫のデータをリアルタイムで統合できるクラウドシステムの活用が有効な手段の一つだ。ただし、システム選定よりも前に「どのデータを・どの粒度で・誰が参照できる状態にするか」という設計が先行しないと、ツールが変わっても運用は変わらない。

システム刷新の方針や移行ステップの設計に迷いがある場合は、外部の専門家に現状の課題整理から相談するのが遠回りにならない選択肢だ。Spesでは、受発注・在庫管理の業務フロー設計から運用支援まで相談を受け付けている。まずは現状の課題を整理したい方はこちらから。

よくある質問

大企業の在庫管理システム刷新は、何か月前から準備を始めるべきですか？

規模にもよるが、500名超・拠点複数の場合は要件定義開始から稼働まで18〜24か月を想定するケースが多い。マスタデータの整備と部門間合意だけで3〜6か月を要することがあるため、「稼働希望日の2年前」からプロジェクト設計を始めるのが現実的な目安だ。

ベンダーはどの段階で選定すべきですか？

要件定義が完了し、優先する業務フローと成功指標が明確になった後が望ましい。ベンダー選定を先に進めると、提案内容に要件が引っ張られる逆転が起きやすい。自社の判断軸を先に固めることで、ベンダーの提案を適切に評価できる。

途中で頓挫したプロジェクトを立て直す方法はありますか？

まず「なぜ止まったか」の原因を、技術・組織・データの3軸で切り分けることが先決だ。多くの場合、技術的な問題より「誰が決定権を持つか」という組織的な曖昧さが根本にある。立て直しには、意思決定者を明確にした小さな成功体験を積み上げる段階的アプローチが機能しやすい。