カスタムERPとパッケージERPの選び方：拡張という第三の選択肢も含めて

このガイドは、スプレッドシートや最初に導入したパッケージでは対応しきれなくなった成長企業のオーナー、財務・業務責任者、ITマネージャーを対象としています。各ルートの比較、総所有コスト、判断に必要な問いを取り上げます。選択したERPをストアやCRMに接続する方法については、エンタープライズシステム統合ガイドで解説しています。

このガイドの内容

• 2択ではなく4つのルート
• ルートの比較
• カスタム開発が効果を発揮する場合、そうでない場合
• システムのライフタイムにわたる総所有コスト
• 判断のための6つの問い
• 統合はERPと同様に重要な決定要因です
• AIとERPの選択
• Netbaseのアプローチ
• 存在する納品実績と存在しないもの
• このガイドの限界
• よくある質問
• 次のステップ

2択ではなく4つのルート

この問いはよく「作るか買うか」として語られますが、実際には4つの選択肢があります。

• パッケージをそのまま使う。ERPプロダクトを設定し、それに合わせてプロセスを変更します。アップグレードはベンダーから提供されます。
• 拡張パッケージ。パッケージのコアを維持しつつ、OdooなどのスイートでよくあるようにEXTENSIONポイントを通じてカスタムモジュール・レポート・統合機能を追加します。
• 再利用可能なモジュールを活用したカスタム開発。パートナーが受注、在庫、プロジェクト、請求向けの既製モジュールを出発点とし、自社に固有の部分のみを構築します。ゼロから始めることなく、業務に合ったシステムが実現します。
• フルカスタム。すべてのモジュールを自社のビジネスに合わせて設計・構築し、システム全体を所有します。

実務では5つ目のパターンも一般的です。元帳や給与計算などの汎用業務にパッケージを使い、差別化が必要な業務向けにカスタムアプリケーションをAPIで接続する形です。

ルートの比較

カナダ事業開発銀行（BDC）は両方の側面をこう要約しています。パッケージシステムは「実績があり、事前テスト済みの機能を提供し、驚きが少なく、リスクを抑えて導入できることが多い」一方、「当初は手頃に見えるカスタムシステムが、ライフタイム全体では大幅に高くなる可能性がある」としています。

カスタム開発が効果を発揮する場合、そうでない場合

Martin Fowlerが提唱する「汎用 vs 戦略的」の二分法が最も実用的な判断基準です。汎用機能については「パッケージを購入し、ソフトウェアに合わせてビジネスプロセスを調整する」とされており、差別化要因となる戦略的機能こそがカスタムソフトウェアのコストを正当化する領域です。

• 通常は汎用：総勘定元帳、給与計算、税務申告、標準的な購買。パッケージがこれらをうまく処理し、規制変更にも対応します。
• しばしば戦略的：見積・価格設定の方法、製品構成、生産スケジューリング、B2Bアカウントのサービス提供、プロジェクト運営。これらはパッケージで回避策を強いられる領域であり、カスタムモジュールが効果を発揮します。

この判断をプロセスごとに適用してください。ほとんどの企業では、戦略的プロセスはいくつかで、汎用プロセスが多数を占めます。これは、全面的な選択ではなく、パッケージコアを中心とした拡張パッケージやカスタムモジュールが適切であることを示しています。

システムのライフタイムにわたる総所有コスト

初回の請求書ではなく、システムを運用する予定年数全体にわたってルートを比較してください。

• パッケージコスト：ユーザーまたはモジュール単位のライセンスまたはサブスクリプション、導入、トレーニング、プロダクトが対応していない箇所でスタッフが手作業で行う回避策のコスト。
• 拡張コスト：拡張機能の構築と、ベンダーアップグレードのたびに必要となる再テストが加わります。大規模なカスタマイズにより、アップグレードが最大の継続的コストになる場合があります。
• カスタムコスト：構築費用に加え、ホスティング、メンテナンス、セキュリティアップデート、コードを把握しているチームのコスト。
• 統合とデータ移行：どのルートでも費用が発生し、しばしば過小評価されます。

これらの間に一定の比率はありません。ユーザー数、プロセス、データ、システムの運用期間によって異なります。自社の数字でそれぞれのルートの費用を算出してください。

統合はERPと同様に重要な決定要因です

ERPが単独で機能することはほとんどありません。ストア、CRM、決済プロバイダー、配送業者はすべて、受注、在庫、顧客情報、請求書をERPと交換します。紙の上では適合しているルートが統合で失敗することがあります。選択前に、ERP・CRM・EC統合アーキテクチャを使ってそれらのフローと所有者をマッピングしてください。ドキュメント化されたAPIを持つパッケージ、またはAPIファーストで構築されたカスタムERPは、後の変更コストを抑えます。Netbaseのシステム・API統合サービスは、どのルートを選択しても、そのレイヤーを構築します。

Netbaseのアプローチ

NetbaseのERP支援はコンサルティングから始まります。プロセスマッピング、フィット・ギャップ分析、構築・購入・拡張の推奨です。ベトナム国内でローカルのOdoo導入パートナーと共にOdooのコンサルティングおよびカスタマイズを行い、あるクライアントをVtiger CRMからフルERPへアップグレードし、クラウドERPプラットフォームを構築した実績があります。製品化されたモジュールライブラリにはCRMとB2B営業エンジン、ワークフロー自動化ツールキット、Smart ERP Lightが含まれます。また、NetbaseのビジネスディビジョンであるCloodoは、CRM、HRM、クラウドERP、AIモジュールを1つのワークスペースに統合しています。製品化されたモジュールはライセンス提供であり、移転されません。一方、カスタム開発においてクライアント向けに作成されたIPはクライアントが所有します。ほとんどのNetbaseプロジェクトはディスカバリー後に合意された請負契約で納品されます。詳細はラボ型開発vs請負をご覧ください。ERP・CRM開発サービスでは契約の詳細を、クラウドERPはモジュールベースの出発点を説明しています。

存在する納品実績と存在しないもの

• 存在するもの。クラウドERPの実績は、Netbaseが2020年から米国クライアント（非公表）のオフショア開発・マネージングパートナーとして構築したマルチテナントクラウドERPを説明しています。第1フェーズではCRM、ワーク管理、API統合が含まれ、小売拡張が計画されています。Cloodoの実績はNetbase自身のデジタルワークプレイスを説明しています。OdooプロジェクトとVtiger CRMアップグレードはスコープのみの説明であり、クライアントは非公表です。
• 存在しないもの。これらの実績はいずれもコスト比較、導入期間、ライセンス削減額、ビジネス上の成果を公表しておらず、いずれかのルートが安価であることの証拠として提示されるものでもありません。Odooの実績はパートナーと共同で納品されており、OdooベンダーステータスはいかなるものもClaimedしていません。

このガイドの限界

• ルートとコストは定性的に説明されています。公開されているコスト比率はソースや方法によって異なり、Netbaseの数値としては使用していません。
• BDCとMartin Fowlerのページは、アクセス日時点の記載内容について引用しています。
• 国・地域によって異なる会計・税務・法的要件はこのガイドの範囲外です。

次のステップ

自社の差別化プロセス、ERPに接続する必要があるシステム、現在のツールの課題を共有していただければ、フィット・ギャップ分析とルートの比較を行うソリューションレビューを予約します。ERP・CRM開発やNetbaseのインサイトもご覧ください。

関連サービスとソリューション