Mesterséges Intelligencia Központ
メニュー

オーダーメイドの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?）。

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

ERPへの3つの道

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

既製のERPをそのまま使う

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

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

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

オーダーメイドのERP

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

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

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

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

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

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

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

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

判断のための比較表

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

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

古いシステムからの移行

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

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

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

リスクとその軽減策

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

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

間違いが金銭的な損失につながる場面では、AIが提案し、人が承認します。言語モデルの組み込み方とデータ保護については、AI統合のページでご説明しています。

当社の経験

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

よくあるご質問

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

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

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

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

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

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

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

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

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

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

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

詳しくは業務ソフトウェアのページをご覧ください。御社のシステムについてご相談をご希望の場合は、お問い合わせのページに記載の連絡先までご連絡ください。

出典