基幹システム入れ替えの費用はなにで決まるか——削れるコストと削れないコスト

費用の「相場感」が掴みにくい理由

基幹システムの入れ替え費用は、同規模の企業でも見積もりが大きく異なる。その理由は、費用の内訳がプロジェクトの条件によって大きく変動するからだ。

費用の内訳は、おおむね次の六つに分類される。

• ソフトウェアライセンス・クラウド利用料
• 初期設定・カスタマイズ開発
• データ移行作業
• 並行稼働期間のコスト（旧システム維持費を含む）
• 教育・研修
• プロジェクト管理・外部コンサルティング

このうち、交渉や設計の工夫で圧縮できる費用と、削ることで後工程に深刻な影響を与える費用とがある。どちらに属するかを最初に整理しないまま値引き交渉に入ると、削るべきでない部分が削られ、稼働後のトラブル対応費用として戻ってくる。

データ移行・並行稼働・教育が削れない理由

削ると後工程で必ず代償を払う費用が三つある。

データ移行は、旧システムから新システムへの単純なファイルの移送ではない。フォーマットの変換、不整合の修正、重複データの処理、移行後の検証まで含めて初めて完了する。この工程を短縮すると、稼働後に「伝票の数字が合わない」「過去の受注履歴が参照できない」という問題が頻発する。現場からの問い合わせ対応と手作業での修正が積み重なり、当初の削減分を上回るコストが発生する。

並行稼働は、新旧システムを一定期間同時に動かす工程だ。コストが二重にかかって見えるが、これは保険にあたる。切り替え直後に発覚した不具合を旧システム側でカバーしながら修正できる体制を維持するための費用である。並行期間を短くしすぎると、不具合が出た際に業務が止まるリスクを丸ごと抱えることになる。

教育は、システムの品質に関わらず外せない。日次・月次・年次で操作が異なる基幹システムでは、マニュアルを配布するだけでは現場が習得できない。教育を簡略化したプロジェクトでは、稼働後にサポートコストが急増する事例が繰り返されている。

削れるかどうかの判断基準は、「後で取り返せるか」ではなく「後で取り返すと何倍のコストになるか」で考える。

発注側の準備がコストを左右する

削れない費用をきちんと確保しながら全体の予算を抑えるには、発注側の準備の質が直接効いてくる。

1. 現行データの棚卸しを事前に済ませる：移行対象のデータを整理し、不要データを削除しておくだけで移行工数が減る。
2. 業務フローの「現状」を文書化しておく：要件定義の期間が短縮され、ベンダーが余計な調査に時間をかけなくなる。
3. 社内の窓口担当者を決めておく：確認待ちで工程が止まると、その待機時間が費用に乗ってくる。

これらの準備ができているかどうかで、同じ規模のプロジェクトでも初期コストに差が生じる。

プロジェクト体制をどう組むかは、コンサルを入れるかどうかの判断とも連動する。内部に情シス担当がいる場合といない場合では、発注側の準備コストの分担が変わるからだ。情シスをアウトソースしている企業では、外部担当者が発注窓口を担うケースも多く、役割の境界を計画段階で決めておくことが全体費用の抑制につながる。

費用を削るべき場所と守るべき場所を見誤ると、稼働後の対処コストが当初の節約分を上回る。内訳を分類し、削れない三つを先に確保する。それが、費用管理の起点になる。