【失敗例】スモールスタートはシステム開発の基本！でもそれだけじゃ失敗する

海外に多くの子会社を抱えるA社。基幹システムのパッケージを購入し、徐々に全拠点に広げる計画を立てていました。プロジェクト開始から3年後。最初の拠点へのシステム導入が完了し、運用上の課題や不足機能も見えてきています。

これらを改善し次の拠点への導入を始めようとした矢先、パッケージシステムの販売終了が決定してしまいました。

全拠点にシステム導入するまではサポートを続けてもらえるとのことでしたが、これではプロジェクト終了後すぐに次のシステムについて検討しなくてはいけません。

結局、全拠点に入れた後に長く使うことができないということで、もう一度システム選定からやり直すことになってしまいました。

基幹システムの刷新を検討しているB社。ERPを導入しデータを素早く正確に集めることを目的としたプロジェクトを立ち上げました。

ERPは販売管理や会計などのサブシステムが多岐に渡るため、まずは会計システム、次に販売管理システムという形で段階的にシステム導入する形で進めることにしています。

しかし、技術進歩の流れは速く、クラウド、Fintech（フィンテック）、IoTの話題が多く聞こえるようになってきました。

最初は順調にシステムの入れ替えが進んでいましたが、経営層からはクラウド化への対応、Fintech（フィンテック）の導入の声が日に日に強くなっています。

実はERPパッケージをバージョンアップすることでこれらの新技術には対応できることが分かっています。

しかし、それには導入済みのシステムの一部再設計が必要となるため、戻り作業となってしまいます。

結局、全システムの入れ替えが終わる前よりはダメージが小さいということで導入済みシステムの見直しに着手することになってしまいました。

全システムの入れ替えが完了するのはいつになるのか、今ではまったく見通しが立ちません。

オーダーメードでシステム開発を検討しているC社。複数のシステムにまたがっていて連携が悪い業務を一つにまとめたいと考えています。

現在利用中のシステムには全く使ってない機能もいくつかあるのですが、どれが必要でどれがいらないか、全体が把握できていません。

そこで、まずは絶対に必要と分かっている最低限の機能だけを集めたシステムを作成し、たまにしか使わなかったりあると便利な機能は必要な都度追加していくスモールスタートの形を取ることにしました。

最低限の機能だけを集めて運用開始したまでは良かったものの、利用者からは「これもほしい」「あれもあった方がいい」と機能追加の希望が後を絶ちません。

当初は1年の運用で必要な機能とそうでない機能の住み分けがはっきりすると想定していましたが、業務担当者の入れ替わりが激しいこともあり、終息のめどが立たなくなってしまいました。

このままでは、結局全機能を移植することになってしまいそうです。