ERP 導入が行き詰まったら？撤退・パッケージ維持・カスタム追加の 3 つの道（Odoo／鼎新の導入後カスタマイズも）

ERP 導入が行き詰まったときは、予算追加やベンダー変更を急がず、まずどこで詰まっているかを見極めます。業務プロセスが合わない、データ移行、利用者が使わない、連携できない、のどれかです。データや利用者の問題なら、多くは今のシステムのまま立て直せます。合わない業務が一部だけなら、パッケージ ERP を残し、連携や追加モジュールで補います。中核業務がパッケージとまったく合わず、改修するほど保守が難しくなる場合に限り、撤退してカスタム開発を検討します。

よくあるのは、プロジェクトが数か月遅れ、コンサルタントからはカスタマイズ日数の追加を求められ、営業や倉庫はまだ Excel を使い、月末の照合も手作業のまま、という状況です。ここで最も起こりやすい失敗は、原因が分からないうちに全面的に入れ替えたり、今のシステムにカスタマイズを積み増し続けたりすることです。

ERP 導入が行き詰まったら、最初に何をすべき？

最初にすべきことは、新しい要望の追加をいったん止め、いま詰まっていることを一つずつ書き出し、プロセス・データ・利用者・連携のどれに当たるかを分類することです。分類ができれば、全部やり直すのではなく、どこを直すべきかが見えてきます。

具体的には、プロジェクトの関係者に次の 3 つを書いてもらいます。どの作業がまだシステムの外で Excel や紙で処理されているか、どの帳票の数字が合わないか、どの画面が使われていないか。この段階ではシステムを替えるかどうかは議論せず、まず事実を集めます。Panorama Consulting が毎年発表している ERP Report などの業界調査でも、ERP プロジェクトがスケジュールや予算を超過するのは珍しくなく、その原因はソフトそのものだけでなく、組織やデータにあることが多いと長く指摘されています。

ERP 導入はどこで詰まっている？よくある 4 つの詰まりどころの見分け方は？

ERP 導入の行き詰まりは、おおむね業務プロセスが合わない、データ移行、利用定着、連携できない、の 4 つに分けられます。前の 2 つはプロジェクトの中盤に、後の 2 つは稼働後に表面化することが多く、見分け方も解決策も異なります。

分類で注意したいのは「業務プロセスが合わない」が最も誤判定されやすいことです。実際の原因はマスターデータの未整備や、ある部署が慣れたやり方を変えたがらないことで、システムにできないように見えているだけ、という例がよくあります。

撤退・パッケージ維持・カスタム追加、3 つの選択肢はどう選ぶ？

違いは今の ERP がどこまで担えるかです。会計と在庫を管理できているなら、パッケージを残して不足だけを補います。中核業務が合わず保守も難しい場合に限り、撤退かカスタム開発を選びます。多くは「パッケージ維持＋カスタム追加」に落ち着きます。

撤退を検討すべきなのはどんなとき？

次のうち 2 つ以上に当てはまるなら、撤退を真剣に検討する価値があります。中核業務（価格計算、工番別原価、作業手配など）がパッケージを大幅に書き換えないと回らない。改修した部分をメーカーのバージョンアップのたびに作り直している。メーカーや該当バージョンの更新が止まっている。プロジェクトが大幅に遅れているのに、いつ決算を締められるか誰も答えられない。撤退は全部やり直すことではなく、会計や在庫のモジュールを残せる場合もあります。

パッケージを維持して導入を立て直せば済むのはどんなとき？

詰まりどころがデータ移行や利用定着に集中しているなら、システムの選定は誤っていないことがほとんどです。稼働範囲を財務と在庫に絞り、まず 1 つの部署で本当に使える状態にしてから他の業務へ広げるほうが、システムを替えるよりずっと早いことがよくあります。

カスタム追加が必要なのはどんなとき？

ERP の会計と在庫が安定していて、見積・品質検査・代理店受注などの一部の業務や、EC・POS との連携だけができない場合は、ERP の横に独立したモジュールを追加し、API でデータを ERP に書き戻します。こうすれば ERP のバージョンアップに影響せず、追加部分も単独で保守できます。選定時の詳しい比較は ERP はどう選ぶ？パッケージ・クラウド ERP・カスタム開発の判断基準をご覧ください。

撤退を決めたら、先に何を回収すべき？

撤退を決める前に、データ・文書・完成済みの成果を回収しておかないと、次のチームはゼロから始めることになります。次の順に一つずつ確認し、契約書や引き継ぎ記録に明記することをおすすめします。

1. データの完全なエクスポート：マスター、取引履歴、期首残高のデータ。出力形式が他のシステムで読み込めるかを確認します。
2. 要件と業務フローの文書：導入期間に整理した現行フロー、要件一覧、ギャップ分析。最も時間をかけた成果です。
3. 完成済みのカスタムプログラム：プログラムと設定が自社に帰属し、他のチームに保守を引き継げるかを確認します。
4. アカウントと権限の一覧：システム管理者アカウント、クラウドサーバーやデータベースへのアクセス権。
5. 未解決の課題一覧：導入中に詰まったことを一つずつ記録し、次のシステムや次のチームが最初に対応できるようにします。

導入後のカスタマイズは、元の導入コンサルタントと開発チームのどちらに頼む？

設定変更や帳票、標準機能の延長なら元の導入コンサルタントが最も早く、システム間連携や新しい業務フロー、プログラムが必要なモジュールなら開発チームが向いています。大事なのは価格より、変更をどこに置き誰が保守するかです。

両者が協力することもできます。導入コンサルタントが ERP 内の設定とインターフェースの公開を担当し、開発チームが外部モジュールと連携を担当します。分担するときは「どのデータはどちらを正とするか」を明記しておきます。たとえば在庫は ERP、EC の注文は EC プラットフォームを正とする、と決めておけば、問題が起きたときに誰に連絡すべきかが分かります。

Odoo や鼎新の導入後にカスタマイズするとき、それぞれ何に注意する？

Odoo は Studio で項目や画面を調整でき、深い要望にはカスタムモジュールが必要です。鼎新などのパッケージ ERP の二次開発は、多くの場合メーカーや販売代理店が担当します。共通の原則は、変更をできるだけ中核の外に置くことです。

Odoo：まず、その要望が Studio（Enterprise 版の設定ツール）で実現できるかを見極めます。項目の追加、フォームの調整、簡単な自動化などです。新しいデータモデル、複雑な計算、外部連携が必要ならカスタムモジュールを作ります。Odoo 公式のアップグレード解説によると、メジャーバージョンをまたぐアップグレードでは、カスタムモジュールは開発者側で別途対応する必要があります。モジュールが多く、改修が深いほど、アップグレードのたびのコストが増えます。

鼎新などのパッケージ ERP：まず、使っている製品とバージョンがどのインターフェースを公開しているかを確認します。API、データベースの読み取り、ファイル出力などです。ERP 内部の業務フローや帳票の調整は、通常メーカーや販売代理店のコンサルタントが担当します。EC・POS・倉庫・会員システムとデータをやり取りするなら、ERP 本体には手を入れず、ERP の外で連携を作れます。

どのシステムでも、カスタマイズの前に「この変更は次のバージョンアップで上書きされないか」を確認してください。上書きされるなら、できるだけ外部に置くことを優先します。

JoinX は行き詰まった ERP をどう支援する？

JoinX（哲煜科技）は、まず ERP が公開するインターフェースと既存データを棚卸しし、モジュール追加、連携、帳票の調整のどれで済むかを判断します。残せる ERP は残し、不要な全面入れ替えはおすすめしません。

台湾の百貨店・比漾百貨の公式サイトと EC を構築した際も、EC プラットフォームを既存の ERP・POS・会計システム（鼎新）と連携し、元の ERP は入れ替えませんでした。開発では仕様駆動開発（SDD）で業務フローと例外を明文化し、テスト駆動開発（TDD）で、変更のたびに既存の会計データに影響が出ないことを確認しています。連携の方法や実績は ERP システム連携サービスをご覧ください。

よくある質問