# オーダーメイドのERPか、カスタマイズした既製のERPか？

ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、既製のERPが適しているのは業務プロセスを標準に合わせられる場合であり、オーダーメイドのERPが適しているのは、業務の進め方が異なる場合か、カスタマイズがアップグレードを危うくするほどになっている場合です。

> **要点：** 道は3つあります。既製のERPをそのまま使う道、設定を行い提供元の拡張ポイントで補った既製のERP、そしてオーダーメイドのERPです。既製のシステムのコアに深く手を入れる必要があるほど、独自の部分を別のモジュールに分けるか、独自のシステムを構築するほうが見合うようになります。どの道を選んでも、事前にデータクレンジングを行う段階的な移行のほうが、一度きりの大規模な切り替えよりもリスクは小さくなります。

## ERPとは何ですか？

ERP（enterprise resource planning、日本語では統合基幹業務システム）は、企業の基幹プロセスを1つのシステムにまとめるものです。Microsoftの定義によれば、ERPとは、財務、サプライチェーン、製造、人事、調達、プロジェクト管理といった基幹プロセスを組織が統合できるよう支援する、業務管理ソフトウェアです（[Microsoft: What is ERP?](https://www.microsoft.com/en-us/dynamics-365/topics/erp/what-is-erp)）。

実際のところ、ERPの価値は、同じデータが一度だけ生まれる点にあります。届いた注文が倉庫の出庫になり、出庫が請求書になり、請求書が会計仕訳と売掛金になります。これらのステップが別々のプログラムや表計算ファイルの中にあると、データは手作業で移され、それとともに間違いも移っていきます。顧客と営業の管理は関連する分野ですが、別の判断です。これについては[オーダーメイドのCRMを開発する価値があるのはどのような場合ですか？](https://www.mestersegesintelligenciakozpont.hu/ja/knowledge-base/when-is-a-custom-crm-worth-it)の記事でご説明しています。

## ERPへの3つの道

「オーダーメイドか既製か」という問いは、実際には3つの選択肢からの選択です。その境界ははっきりしたものではありませんが、費用、アップグレード、依存度の違いは大きなものです。

### 既製のERPをそのまま使う

企業は既製品を導入し、自社の業務プロセスを製品の標準的な進め方に合わせます。プロセスが一般的で、企業が慣れ親しんだ仕事の進め方を変える用意がある場合には、これがうまく機能します。利点は立ち上げの速さと、提供元が提供するアップグレードです。欠点は、製品でカバーできない部分が表計算ファイルや手作業として残ることです。

### 既製のERPを設定し、拡張して使う

ほとんどの導入事例は、このあたりに位置します。アップグレードのしやすさという観点では意味が大きく異なるため、次の3つを区別しておくことをお勧めします：

- **設定（コンフィギュレーション）：** 提供元があらかじめ用意した選択肢を、プログラミングなしで利用することです。ワークフロー、承認レベル、項目、帳票、権限などがこれにあたります。
- **拡張（エクステンション）：** 提供元がサポートし、ドキュメント化している拡張ポイントやインターフェースを通じて、製品自体のコードを変更せずに新しい機能を加えることです。
- **改変（コアのカスタマイズ）：** 提供元のコードやオブジェクトを書き換える、あるいはコピーして書き換えることです。最も自由度が高い方法ですが、提供元自身のドキュメントによれば、アップグレードの際に最も大きなリスクを伴います（下記参照）。

### オーダーメイドのERP

システムは企業独自の業務プロセスとデータモデルに基づいて構築され、本当に必要なものだけが作られます。アップグレードしなければならない提供元のコアはなく、追加開発は発注者が決めます。その代わり、開発、運用、保守の体制を、社内チームまたは契約した開発会社によって整える必要があります。オーダーメイドと既製のソフトウェアの一般的な比較については、[オーダーメイドのソフトウェアか、既製のソリューション（SaaS）か？](https://www.mestersegesintelligenciakozpont.hu/ja/knowledge-base/custom-software-vs-off-the-shelf)の記事で取り上げています。

## 過度なカスタマイズはなぜアップグレードを難しくするのですか？

既製のERPの提供元は、修正プログラムや新しいバージョンを定期的にリリースします。企業が提供元のコードを改変している場合、アップグレードのたびにその改変がまだ機能するかを確認しなければならず、書き直しが必要になることもよくあります。大手提供元自身のドキュメントも、同じ結論に達しています：

- **SAP：** 「clean core」（クリーンコア）のアプローチでは、拡張機能をSAPアプリケーションから厳密に分離し、明確に定義された、アップグレードに耐えるインターフェースを通じて保つ必要があります。標準オブジェクトを直接改変したりコピーしたりすることは、パッチやアップグレードのたびに徹底的な再テストが必要になりうるため、より問題が多いと提供元は考えています（[SAP Learning: Introducing the Clean Core Approach](https://learning.sap.com/courses/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/introducing-the-clean-core-approach_fcb6c662-7041-4c99-88bd-345636fae7f3)）。
- **Microsoft Dynamics 365：** Finance、Supply Chain、Commerceの各製品について、提供元は拡張に基づくモデルの理由として、クラウドと頻繁なアップデートには介入の度合いが小さいカスタマイズが求められ、それによってアップデートがカスタムソリューションに影響する可能性が低くなることを挙げています。これらの製品では拡張が唯一のカスタマイズ方法であり、アプリケーションコードの上書き（overlayering）はサポートされていません（[Microsoft Learn: Extensibility home page](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/extensibility/extensibility-home-page)）。
- **Odoo：** ドキュメントによれば、オーダーメイドのモジュールを含むデータベースは、そのモジュールが移行先のバージョンに対応するまでアップグレードできず、互換性の確保はオーダーメイドのモジュールの保守担当者の責任です（[Odoo: Upgrade](https://www.odoo.com/documentation/19.0/administration/upgrade.html)）。

SAPとMicrosoftから得られる教訓は同じです。コアには手を付けず、企業に固有の部分は、ドキュメント化されたインターフェースを通じて既製のシステムとやり取りする、切り離し可能な拡張機能や別のモジュールに置くということです。Odooの場合は、オーダーメイドのモジュールの保守状況によって、システムをいつアップグレードできるかが決まります。必要な独自性があまりに大きく、これをもはやきれいに実現できない場合は、オーダーメイドのERPやオーダーメイドのモジュールを選ぶべき強いサインです。

## ハンガリー特有の事情：NAV Online Számla、請求書発行、銀行、ECサイト

ハンガリー企業のERPは、ハンガリー国内のシステムとも連携しなければなりません。最も重要なのは、ハンガリー国税庁（NAV）のオンライン請求データ報告システムであるNAV Online Számlaです。NAVの案内によれば、2021年1月4日以降、ハンガリーの付加価値税法の請求書発行規定が適用されるすべての請求書、修正請求書、取消請求書について、データを報告することが義務付けられています（[NAV: Online Számla](https://onlineszamla.nav.gov.hu/)）。

システム間の接続（機械向けインターフェース）のサポート対象バージョンは3.0です（2026年10月17日確認）。インターフェース仕様書によれば、請求書発行ソフトは、処理の中で別途人の介入を必要とせず、自動的にデータを報告しなければなりません。NAVは送信されたデータを非同期で処理し、ソフトが処理の成功を確認し、その請求書に対応する受領メッセージを受け取るまでは、データ報告が完了したとはみなされません（[NAV Online Számla: Documentation](https://onlineszamla.nav.gov.hu/dokumentaciok)）。NAVは仕様書を随時改訂しており、2026年8月にも改訂版を公表しました。そのため、接続部分は保守し続ける必要があります。

ハンガリーで使うERPに通常求められる機能で、当社が接続するものは次のとおりです：

- **NAV Online Számla：** 機械向けインターフェースを通じた請求データの送信、処理結果の照会、エラーへの対応。
- **請求書発行サービス：** 請求書発行を外部の請求書発行サービスで続ける場合は、そのインターフェースを通じた接続。
- **銀行：** 銀行の取引明細と取引データの取り込み、入金と請求書の照合。
- **ECサイト：** ECサイトとERPの間での注文、在庫、価格の同期。
- **配送業者とその他のシステム：** 荷物の発送、既存のCRM、メール、カレンダー。

既製のERPを選ぶ際は、製品にハンガリー向けのローカライズがあるか、仕様書が変わったときに誰がNAVとの接続を保守するのか、ハンガリー国内の銀行や請求書発行サービスとの接続はどうなっているのかを確認することをお勧めします。オーダーメイドのERPでは、これらの接続も開発の一部です。システム同士の連携については、[業務プロセス自動化](https://www.mestersegesintelligenciakozpont.hu/ja/services/process-automation)のページで詳しくご説明しています。

## 判断のための比較表

| 観点 | 既製のERPをそのまま | 拡張した既製のERP | オーダーメイドのERP |
|---|---|---|---|
| 業務プロセスへの適合 | 企業が標準のプロセスに合わせる | 標準の大部分は合っており、いくつかの点が独自 | 業務の進め方が標準と大きく異なる |
| 立ち上げ | 設定で足りれば、通常は速い | 拡張機能の開発があるため長くなる | 開発期間が必要。段階的に稼働させることもできる |
| アップグレード | 提供元が提供し、リスクは小さい | アップグレードのたびに拡張機能を確認する必要がある | 発注者が時期を決め、開発会社が実施する |
| 独自のプロセス | 設定の範囲内のみ | 拡張ポイントまたは別のモジュールで対応 | どのようなビジネスロジックでも |
| 連携 | 提供元とそのパートナーのコネクターで | コネクターとオーダーメイドの連携 | インターフェースやデータにアクセスできるものなら何とでも |
| コスト構造 | 提供元の条件によるライセンス料またはサブスクリプション料金 | ライセンスに加え、拡張機能の開発と保守 | 開発、運用、追加開発 |
| 依存 | 提供元と製品の将来に依存 | 提供元と、拡張機能を開発するパートナーに依存 | ソースコードがあれば、別の開発会社でも発展させられる |
| 誰に向いているか？ | 一般的な業務の進め方で、早く立ち上げたい企業 | 標準が良い土台になるが、いくつかの点で異なる企業 | 業務の進め方や連携が独自である企業 |

組み合わせたソリューションもよく見られます。財務と会計には既製のERPを使い続け、企業に特有のプロセス（たとえば独自の生産スケジューリングや価格設定）は、インターフェースを通じて既製のシステムとやり取りする、別のオーダーメイドのモジュールで動かします。

## 古いシステムからの移行

ERPプロジェクトが白紙の状態から始まることはまれです。古いプログラム、既製のシステム、あるいは表計算ファイルの集まりがあり、そこに何年分ものデータが蓄積されています。移行の手順は次のとおりです：

1. **現状調査：** どのようなデータ、プロセス、接続があるのか、そして現在システムの外の表計算ファイルで行われていることは何か。
2. **データの棚卸しとデータクレンジング：** 重複した顧客、不完全な品目マスター、古くなった項目を、移行の前に整理します。
3. **データマッピング：** 古い項目をそれぞれ新しいシステムのどこへ移すのか、また古い完了済みの記録をどう扱うのか。
4. **試験移行：** 古いデータをテスト環境に移し、キーユーザーが実際の事例に照らして確認します。
5. **段階的な本番稼働：** 日々の業務が止まらないよう、モジュールごとまたは拠点ごとに、場合によっては新旧のシステムを短期間並行稼働させながら進めます。
6. **フォローアップ：** 本番稼働後の不具合修正、追加のトレーニング、運用。

すべてを一度に置き換える必要はありません。多くの場合、まず新しいモジュールを古いシステムの横に置き、古い部分を置き換えられるようになるまで、両者がインターフェースを通じてデータをやり取りするのが現実的な道です。

## リスクとその軽減策

- **大きすぎる第1段階：** すべてを一度に稼働させると、1つの不具合が会社全体を止めてしまいます。範囲を明確に区切ったモジュールから始めることをお勧めします。
- **整理されていないデータ：** 誤ったデータは、新しいシステムでも誤ったままです。データクレンジングはプロジェクトの一部であり、後回しにする作業ではありません。
- **隠れたプロセス：** 重要なステップの多くが、表計算ファイルや特定の社員の頭の中にしかありません。現状調査では、こうしたものも明らかにする必要があります。
- **キーユーザーの不在：** 日々の業務を担う人が設計とテストに参加しなければ、システムの横で表計算ファイルが使われ続けます。
- **連携の不具合：** 同期が止まっても見過ごされることがないよう、NAV、銀行、ECサイトとの接続にはログ記録とエラー通知が必要です。
- **一方的な依存：** 完全なソースコードとドキュメントを引き渡すことで、後で別の開発会社がシステムを引き継いで発展させられるようになります。

## ERPで人工知能が役立つのはどのような場面ですか？

大規模言語モデル（OpenAIのChatGPT、AnthropicのClaude、GoogleのGemini）は、これまで人が読み、書き写し、文章を作っていた場面で役立ちます：

- **文書：** 受け取った請求書、納品書、注文書からデータを読み取り、確認できる状態にして登録します。
- **メール：** 受信した注文メールを処理し、返信の下書きを用意します。
- **データへの質問：** たとえば、支払期限を過ぎた請求書が残っている顧客はどこかといったことを、ふだんの言葉でシステムに質問できます。
- **異常の通知：** 通常とは異なる項目（たとえば、その顧客の過去の注文と大きく異なる注文）を、確認のために目立たせます。

間違いが金銭的な損失につながる場面では、AIが提案し、人が承認します。言語モデルの組み込み方とデータ保護については、[AI統合](https://www.mestersegesintelligenciakozpont.hu/ja/services/ai-integration)のページでご説明しています。

## 当社の経験

当社は現在も、ERPとCRMを兼ね備えた大規模なシステムを開発しています。お客様名と製品名は公表していません。ERPで画面が難しい部分になることはめったにありません。社員がそのシステムを使うのか、それとも横で表計算ファイルを使い続けるのかを決めるのは、データモデル、権限、連携、そして古いデータの引き継ぎです。

## よくあるご質問

### オーダーメイドのERPを開発する価値があるのはどのような場合ですか？

企業の業務の進め方が既製のERPの前提と大きく異なり、その違いを維持したい場合、多くのシステムをつなぐ必要があり、それらに既製のコネクターがない場合、あるいは必要なカスタマイズが提供元のコアの改変を必要とするほどになっている場合です。既製のERPが設定だけでプロセスの大部分をカバーできるなら、通常はそのほうが早道です。その場合は、初回のご相談の際にそのようにお伝えします。

### 既製のERPはどこまでカスタマイズできますか？

さまざまな方法がありますが、どの方法をとるかが重要です。設定（コンフィギュレーション）と、提供元がサポートする拡張ポイントは、アップグレードにほとんど影響しません。一方、提供元のコードの改変は、アップグレードのたびに新たな作業を生む可能性があります。大手提供元（SAPとMicrosoft）のドキュメントは、コアに手を付けず、拡張機能を切り離しておくことを推奨しています。Odooのドキュメントによれば、オーダーメイドのモジュールの保守がアップグレードの前提条件です。

### 過度なカスタマイズにはどのようなリスクがありますか？

主なリスクは、アップグレードが高額で危険なものになることです。新しいバージョンのたびに改変部分を確認し、多くの場合は書き直さなければなりません。また提供元によっては、オーダーメイドの部分が新しいバージョンに対応するまで、アップグレード自体を実施できません。さらに、企業は拡張機能を開発するパートナーにも依存するようになります。カスタマイズの規模がそれを正当化するほどであれば、オーダーメイドのモジュールやオーダーメイドのERPの費用と比較することをお勧めします。

### 古いシステムからの移行はどのように進みますか？

現状調査、データクレンジング、データマッピングから始まり、テスト環境での試験移行を経て、モジュールごとに、あるいは新旧のシステムを短期間並行稼働させながら、段階的に本番稼働へ移ります。本番稼働の後は、不具合修正と運用が続きます。古いシステムは、インターフェースで新しいシステムとつないだまま、しばらく並行して動かすこともできます。

### NAV Online Számlaとも接続していただけますか？

はい。NAVのインターフェース仕様書の定めに従い、NAVの機械向けインターフェースを通じて請求データを送信し、処理結果を照会し、エラーに対応します。同じように、外部の請求書発行サービス、銀行、ECサイトとも接続します。

## 当社がお手伝いできること

Mesterséges Intelligencia Központ Kft. は、オーダーメイドのERP・CRM・業務管理システムを開発し、既製のシステム向けにオーダーメイドのモジュールと連携を構築し、それらを人工知能でつなぎます。初回のご相談は無料で、既製のERPで足りる場合はその旨もお伝えします。開発の機能規模をCOSMICファンクションポイント（ISO/IEC 19761）で測定し、そこからお見積もりとスケジュールを作成します。手法は[料金の考え方](https://www.mestersegesintelligenciakozpont.hu/ja/pricing)のページでご説明しています。ご要望に応じて秘密保持契約（NDA）を締結します。引き渡し後の運用・保守もお引き受けします。ソースコードと利用権の扱いは、契約で定めます。

詳しくは[業務ソフトウェア](https://www.mestersegesintelligenciakozpont.hu/ja/services/business-software)のページをご覧ください。御社のシステムについてご相談をご希望の場合は、[お問い合わせ](https://www.mestersegesintelligenciakozpont.hu/ja/contact)のページに記載の連絡先までご連絡ください。

## 出典

- [Microsoft: What is ERP?](https://www.microsoft.com/en-us/dynamics-365/topics/erp/what-is-erp)
- [SAP Learning: Introducing the Clean Core Approach](https://learning.sap.com/courses/practicing-clean-core-extensibility-for-sap-s-4hana-cloud/introducing-the-clean-core-approach_fcb6c662-7041-4c99-88bd-345636fae7f3)
- [Microsoft Learn: Extensibility home page (Finance and Operations)](https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/extensibility/extensibility-home-page)
- [Odoo: Upgrade（Odoo 19.0のドキュメント）](https://www.odoo.com/documentation/19.0/administration/upgrade.html)
- [NAV Online Számla: トップページ](https://onlineszamla.nav.gov.hu/)
- [NAV Online Számla: Documentation（インターフェース仕様書3.0）](https://onlineszamla.nav.gov.hu/dokumentaciok)