情報システム部門が在庫管理システム選定で「やり直し」になった3つの失敗——IT責任者が導入前に押さえるべき判断基準と選定プロセスの見直し方 ─ 在庫管理のDXに | 完全無償クラウド型ソフト「Spes」

失敗パターン1：TCOを見ていなかった

中堅卸売業の情シス担当、伊藤さんが最初にぶつかったのが「導入後に費用が膨らむ」問題だった。初期費用とライセンス料だけで比較し、カスタマイズ費用・保守費用・運用工数（社内SE稼働）を積算していなかった。

結果として、3年間のトータルコストで当初見積もりの1.8倍になった。現場部門からは「予算オーバーで次の改善投資が止まった」と批判を受けた。

e-Stat（政府統計ポータル）が整備するIT投資・システム導入効果に関するデータでも、企業のシステム導入プロセスにおいてTCO換算と業務改善効果の数値化が判断基準として重要視されている。初期費用だけで比較するフェーズはすでに終わっている、と捉えるべきだ（参照：e-Stat 政府統計ポータル）。

失敗パターン2：既存システムとの連携を後回しにした

製造業で情シスリーダーを務める渡辺さんのケースは、別の種類の失敗だ。在庫管理システム単体の機能評価は十分に行ったが、ERPや会計システム、EDIとのデータ連携設計を「導入後に詰める」として先送りした。

実際に稼働を開始すると、受注データの二重入力が発生し、現場の手戻りが増えた。「システムを入れたのに作業が増えた」という声が上がり、現場の協力を得るのが難しくなった。

連携設計は要件定義の段階から確認し、PoC時点でテスト済みにしておくことが望ましい。

卸売・流通業における情報システム部門の役割に関しては、政府統計（stat.go.jp）の業種別IT投資動向データでも、受発注処理の自動化・業務効率化を目的とした連携が主要な導入目的として挙がっている。在庫管理システムを「単体の在庫台帳」として評価するのではなく、周辺システムとのデータフローの中で評価する視点が必要だ（参照：政府統計総合窓口 stat.go.jp）。

失敗パターン3：セキュリティ・保守要件を機能評価より後に回した

情シス担当の中村さんが所属する企業では、クラウド型の在庫管理システムを選定する際に、機能デモと価格比較を中心に評価を進めた。セキュリティ要件（アクセス権限の粒度、ログ管理、データ所在地）と保守・障害対応のSLA確認は「契約交渉フェーズで詰める」と想定していた。

しかし、実際に契約条件を確認すると、自社の情報セキュリティポリシーに合わない点が複数あり、調整に2ヶ月を要した。選定したベンダーがその条件に応じられず、一度決定した選定をやり直すことになった。

総務省が整備するデジタル化・情報セキュリティ対策のガイドラインでも、クラウドサービス採用時にはセキュリティ・可用性・スケーラビリティを機能要件と並行して確認することが推奨されている（参照：総務省）。機能評価の後にセキュリティ確認、という順序は、スケジュールを大幅に圧迫するリスクを持つ。

情シス視点での選定基準：何を軸にするか

3つの失敗パターンから浮かび上がる選定基準の軸を整理すると、以下の4つになる。

これらの軸は、どれか一つが抜けていると後工程で必ず問題が浮上する。現場部門がシステムに慣れてきた頃に「実は連携できない」「実はセキュリティ要件を満たしていない」が発覚すると、対処コストが最大になる。

クラウド型在庫管理システムで確認すべき運用設計のポイント

クラウド型のシステムを選ぶ場合、機能の豊富さよりも「自社の運用フローに合わせられるか」が定着率を左右する。バーコード・ハンディ端末との連携、複数倉庫・複数拠点の一元管理、ECモールや卸先との在庫連動を必要とする企業では、それぞれの要件を事前にリストアップし、ベンダーに対してPoC（概念実証）での動作確認を求めることが現実的な手段だ。

Spesのようなクラウド型在庫・受発注管理SaaSは、バーコード・ハンディ連携や複数拠点の在庫一元管理を標準機能として備えており、EC・卸との在庫連携を想定した設計になっている。選定候補の一つとして検討する際には、自社の既存システムとの連携仕様を具体的に確認してほしい。初期段階での相談であれば、要件整理の段階から対応可能なケースが多い。

選定プロセスで「どこから整理すればいいかわからない」という段階であれば、Spesへの問い合わせページから現状の課題を共有してみることも一つの選択肢だ。要件が固まっていない段階からの相談にも対応している。

よくある質問

情報システム部門が在庫管理システムの選定を主導するとき、現場部門との役割分担はどうすべきか？

要件定義・ベンダー評価・セキュリティ確認は情シスが主導し、業務フローの確認・現場テスト（UAT）は現場部門が主体になる体制が一般的だ。最初から「情シスが全部決める」か「現場任せ」のどちらかに偏ると、選定後のギャップが大きくなる。キーユーザーを早期にアサインし、PoC段階で現場フィードバックを取る設計が定着率を高める。

RFPを作るべきか、それとも複数ベンダーに直接デモを依頼すべきか？

要件が明確であればRFPで比較したほうが判断基準を揃えやすい。ただし、要件がまだ固まっていない段階では先にデモを見てから要件を絞り込む進め方が現実的なことも多い。規模・複雑度・社内リソースによって判断が変わるため、どちらが正解というものではない。

導入失敗のリスクを下げるために、情シスが最初にやるべきことは何か？

現状の業務フローと「システムで解決したい問題」を紙一枚に整理することだ。「在庫が合わない」「二重入力が多い」「拠点間でデータが見えない」など、具体的な課題を列挙してから要件定義に入ると、ベンダーとの会話が具体的になる。選定基準が「機能の多さ」になってしまうと、高機能だが使われないシステムを選ぶリスクが上がる。