「基幹システムの費用が、事業の規模に対して重い」。
こうした声を、経営者から聞くことが増えています。導入した当時は妥当だったが、いまの事業規模や使い方と釣り合わなくなっている。そんな状態です。
この記事では、ERP導入支援を手がけるベンチャーネットが、ライセンス費用を見直したい企業の選択肢を整理します。
なお、この記事では特定の製品が安い・高いという比較はしません。規模も機能の範囲も違う製品を金額だけで並べても、判断材料にならないためです。代わりに、費用の発生する構造の違いを解説します。
読み終えると、次の3つが分かります。
- 「費用が重い」と感じる原因が、どこにあるのか
- 4つの選択肢が、それぞれどんな課金構造なのか
- 見直しを、どの順序で進めればよいか
まず「何が重いのか」を切り分ける
見直しの前に、必要な作業があります。費用の中身を分解することです。
基幹システムの費用は、次の要素で構成されています。
| 費用の種類 | 内容 |
|---|---|
| ライセンス費用 | ソフトウェアを使う権利にかかる費用 |
| 保守費用 | サポートや更新に対する費用 |
| 運用費用 | 日々の利用を支える人件費・委託費 |
| 改修費用 | 業務変更に伴う設定変更や開発 |
「費用が重い」と感じるとき、その原因がどこにあるかで、打つべき手はまったく変わります。
ライセンスが重いのか。使っていない機能に払い続けているのか。改修のたびに費用が発生する構造なのか。ここを切り分けないまま製品を替えても、同じ問題が繰り返されます。
よくある「重さ」の3つのパターン
規模に対して製品が大きすぎる
導入時は成長を見込んで上位の製品を選んだが、想定した規模に至っていない。あるいは事業構造が変わり、当時ほどの機能が必要なくなった。
この場合、規模に合った選択肢への見直しが検討対象になります。
使っていない機能に払っている
全社にライセンスを配ったが、実際に使っているのは一部の部署だけ。あるいは、契約したモジュールのうち稼働しているのが半分以下。
この場合、製品を替える前に契約内容の見直しで改善する余地があります。
改修のたびに費用がかさむ
独自の作り込みが多く、業務が変わるたびに開発費用が発生する。バージョンアップのたびに、確認と修正の費用がかかる。
この場合、原因はライセンスではなく設計にあります。製品を替えても、同じ設計思想で作れば同じことが起きます。
4つの選択肢と、その課金構造
ベンチャーネットは、基幹システムを4つの選択肢で捉えています。それぞれ、費用の発生の仕方が異なります。
| 選択肢 | 課金の構造 |
|---|---|
| SAP | 大規模向け。ライセンスと保守料の体系 |
| NetSuite | ユーザー数とモジュール構成に応じたクラウド契約 |
| Odoo | ユーザー単位のサブスクリプション。無料版という選択肢もある |
| AIスクラッチ開発 | 継続ライセンスではなく、自社資産としての開発 |
上位ERPから下の段へ移る場合
規模に対して製品が大きすぎる場合、下の段への移行が検討対象になります。
このとき変わるのは、金額の大小だけではありません。費用の発生の仕方そのものが変わります。
たとえばOdooの場合、有償プランはアプリの数ではなくユーザー数で料金が決まります。機能を追加してもライセンスの考え方は変わりません。詳しくはOdooの料金体系の記事で解説しています。
一方で、上位のERPが持つ機能（連結管理、高度な統制など）は失われます。それが自社に必要かどうかが、判断の分かれ目です。
無料版という選択肢
Odooには無料のCommunity版があります。ライセンス費用はかかりません。
ただし、費用が消えるわけではありません。費用が「ライセンス」から「人と時間」に置き換わる構造です。
- サーバーの費用
- 構築・保守の工数
- バージョンアップ対応の工数
- 不具合対応の時間
社内に技術者がいて余力があるなら成立します。いなければ、外部に依頼する費用が発生します。
スクラッチ開発という選択肢
業務が固有すぎてパッケージに乗らない場合、必要な機能だけを開発する選択肢があります。
継続的なライセンス費用ではなく、自社の資産として持つ形になります。
ただし、ここは誤解が起きやすい部分です。ライセンスがない＝安い、ではありません。 開発費用が発生し、その後の保守費用も必要です。作った後に誰が面倒を見るのかまで含めて、費用を考える必要があります。
見直しを進める5つのステップ
ステップ1：費用の中身を分解する
まず、ライセンス・保守・運用・改修の内訳を出します。ここが出発点です。
ステップ2：使われ方を確認する
契約しているライセンス数のうち、実際に使われているのは何人分か。契約モジュールのうち、稼働しているのはどれか。
意外に、ここで改善の余地が見つかることがあります。
ステップ3：譲れない要件を洗い出す
いまの製品で「これがあるから助かっている」機能を挙げます。
連結決算、多通貨対応、監査対応。これらが必要なら、下の段に移ると業務が回らなくなります。
ステップ4：移行のコストを見積もる
乗り換えには費用がかかります。
- データ移行
- 業務の再設計
- 現場の再教育
- 一時的な業務停止のリスク
削減できる年間費用と、移行にかかる一時費用を並べて比較する必要があります。数年かけて回収できるかどうかが判断基準になります。
ステップ5：3〜5年後から逆算する
最後に、将来から見直します。
いま小さくても、成長が見込まれるなら、下の段に移ってからまた上に戻ることになります。二度の乗り換えは、二度の負担です。
判断の基準は、いまの規模ではなく3〜5年後の姿です。
見直しで失敗しないための注意点
金額だけで判断しない
ライセンス費用が下がっても、運用の負担が増えれば総額は変わりません。
比較するなら、「自社が必要とする業務範囲を満たすのに、総額でいくらかかるか」を同じ条件で並べる必要があります。
原因が設計にある場合、製品を替えても解決しない
改修のたびに費用がかさむ状態は、多くの場合、作り込みすぎが原因です。
同じ思想で新しい製品に作り替えれば、数年後に同じ問題が起きます。乗り換えを、業務と設計を見直す機会にすることが重要です。
「安くする」を目的にしない
費用の見直しは手段です。目的は、事業に合った基盤を持つことです。
安くすることだけを目的にすると、必要な機能まで削ってしまい、業務が回らなくなることがあります。
よくある質問
どれくらい費用が下がりますか？
一概には言えません。
現在の契約内容、必要な業務範囲、ユーザー数によって大きく変わるためです。まずは費用の内訳と使われ方を出すところから始めてください。そこが分からないままでは、どの会社も正確な見積もりは出せません。
乗り換えずに費用を下げる方法はありますか？
あります。
使われていないライセンスの整理、契約モジュールの見直し、契約条件の交渉など、製品を替えずにできることが残っている場合があります。乗り換えは負担も大きいため、まずこちらを確認するのが順序です。
無料のERPに移せば、費用はゼロになりますか？
なりません。
ライセンス費用は不要になりますが、サーバー費用と構築・運用の工数が発生します。社内に担える人がいなければ、外部への委託費がかかります。費用の性質が変わるだけで、消えるわけではありません。
スクラッチ開発なら、ずっと費用がかからないのでは？
そうではありません。
初期の開発費用があり、その後も保守と改修の費用が必要です。継続ライセンスがない代わりに、システムを維持する責任を自社が持つことになります。この点を見落とすと、数年後に苦しくなります。
まとめ：構造を見てから、選択肢を選ぶ
この記事の要点です。
- 「重い」の原因を、ライセンス・保守・運用・改修に分解する
- 使われていないライセンスの整理で改善する場合もある
- 選択肢は4つ。それぞれ課金の構造が違う
- 無料版もスクラッチ開発も、費用が消えるわけではなく性質が変わる
- 移行の一時費用と、削減できる年間費用を並べて判断する
- 判断の基準は、いまの規模ではなく3〜5年後の姿
費用の見直しは、単なるコスト削減ではありません。「自社の事業規模に、どんな基盤が釣り合うのか」を考え直す作業です。
そしてこれは、システムの話であると同時に経営の話です。何を自社で持ち、何を外部に任せるのか。その線引きを決める判断だからです。
ベンチャーネットは、SAP、NetSuite、Odoo、AIスクラッチ開発の4つをすべて扱っています。だからこそ、特定の製品に誘導する必要がありません。見直した結果「いまの製品を続けるのが最善」という結論になれば、そうお伝えします。
「うちの費用は、構造として妥当だろうか」と感じたら、その整理からご一緒します。
もう少し詳しく知りたい方へ
関連記事
