カスタマイズ費用が膨れ上がったときに採るべき選択肢とは

・「微修正で1,000万円、バージョンアップ対応で1億円」の見積もりが出た
・そもそも見積自体に費用を請求された
といった経験はありませんか。
今回は基幹システムでカスタマイズ費用が膨れ上がったときに採るべき選択肢をご紹介します。

多くの基幹システムでは、自社業務に合わせて基幹システムをカスタマイズすることができます。
ただカスタマイズが一定量を超えると、カスタマイズ額が飛躍的に高まり業務変更できなくなります。
この状況で追加カスタマイズを続けていくと、最終的には業務変更・バージョンアップ・リプレイスが不可能なブラックボックスシステムになってしまいます。

そもそも、何故カスタマイズ費用が高額になるのかをご説明します。
多くの上場企業向けERPはカスタマイズ前提で製品設計されています。
具体的にはパッケージベンダーが開発するERPの内部構造は公開され、導入ベンダーが案件に応じて改修を加えられるようになっています。この改修がカスタマイズと呼ばれますが、いわゆるアドオンです。

アドオンがベースとなるパッケージ仕様から離れたり、アドオン数が多くなりアドオン間で仕様調整が必要になればなるほど、アドオンで実施しなければならない影響範囲調査や実装量は増加します。つまり、カスタマイズすればするほど1開発にかかるカスタマイズ費用は大きくなる関係にあるということです。
これは既に存在しているカスタマイズの改修でも同様です。

カスタマイズはパッケージのバージョンアップ時にも大きなコストとしてかかります。
カスタマイズには種類があり、画面追加・計算ロジック変更・処理フロー変更・帳票追加・DBテーブル変更などがあります。
導入ベンダーが個社毎に実施したカスタマイズ内容をパッケージベンダーはほとんど把握していません。
パッケージベンダーは既存機能の仕様変更が発生しないように心掛けてはいますがバージョンアップでは一定数は既存機能の仕様変更が発生してしまいます。そこでパッケージ仕様変更の影響を受けるカスタマイズを持つ企業はカスタマイズの改修が必要になります。
多くのケースではカスタマイズをしているためバージョンアップ前調査としてカスタマイズへの影響範囲調査工数が必要になりますし、そもそもカスタマイズの仕様が残っていないケースではカスタマイズ自体の仕様調査工数がかかってきます。
これがカスタマイズ費用が高額になる理由です。

ではカスタマイズ費用が膨れ上がってしまった時は、どのような選択肢があるのでしょうか。

まず最初に検討すべきは、カスタマイズを減らして現行パッケージで使い続けるという選択肢です。
「カスタマイズを実施した当時は不可欠だったが、今となってはなくしても良い」ということは多々あります。
そこで現行基幹システムの使用感に大きな不満がないのであればそれを使い続けカスタマイズだけを減らす方が、基幹システムの刷新を行うよりも時間・コスト両面でリーズナブルです。
これは中堅企業向けのパッケージに多く見られる、パッケージベンダーがカスタマイズ対応するケースでオススメです。

次に検討すべきは、同一パッケージをゼロから再導入しつつカスタマイズは別システムで実現するという選択肢です。
基幹システムのリプレイスは現場部門に負担をかけること・機能GAPによる新たなカスタマイズリスクが発生し得ることから、現行基幹システムの使用感に大きな不満がないのであればそれを使い続けるほうが得策です。
パッケージは標準に近い使い方で利用しカスタマイズしていた部分は別システムで実現することで、業務変更による影響を基幹システムに及ぼさないという方法です。
これも中堅企業向けのパッケージに多く見られる、パッケージベンダーがカスタマイズ対応するケースでオススメです。

続いて検討すべきは、別のパッケージにリプレイスするという選択肢です。
現行基幹システムでカスタマイズしている領域が標準機能として備わっているパッケージを選定したり、思い切ってスクラッチで開発することでカスタマイズによる業務硬直化を解消しようという方法になります。
そのためカスタマイズ費用を浮かせるだけでは費用対効果が合わず、この選択肢を採るためにはリプレイス目的として業務効率化観点は必須になります。
この方法はカスタマイズ前提となる大手企業向けのパッケージを利用している場合にオススメです。
尚、この方法はカスタマイズの洗い出し・仕様調査をやりきれることが前提ですので、洗い出しきれない場合は次の選択肢になります。

最後に残された選択肢は、ASISを無視してTOBEを描きTOBE業務前提で新基幹システムを導入する選択肢です。
モダナイゼーションでターゲットとされるような、現行カスタマイズ・仕様・業務を洗い出しきれないレガシーシステムで採られるアプローチです。
この手法は稼働後に業務が回らないことが発覚するリスクが大きいため、平行稼働期間を長く取ること・前工程から順に徐々にシステムを置き換えていくことが大事です。

カスタマイズ費用が膨れ上がったときに採るべき選択肢をご紹介しました。
カスタマイズは便利な反面、過度なカスタマイズは業務硬直化と保守費用の増加につながります。
カスタマイズ費用が膨らむ前に、定期的にカスタマイズを減らせないか見直す機会を設けて普段からカスタマイズを減らす努力を心がけましょう。