クラウド ERP では足りないときは？残す・連携する・カスタム開発する

クラウド ERP で足りなくなるのは、たいてい 3 つの場面です。複雑な BOM と生産スケジューリング、EC・POS・倉庫・LINE との連携、そして帳票が作れない、伝票を二重入力しているという問題です。多くの場合、ERP を入れ替える必要はなく、パッケージを残して足りない部分を補います。中核業務そのものが競争力の場合に限り、カスタム開発を検討する価値があります。

月額制のクラウド ERP は、早く稼働でき、価格も明確です。2026 年 11 月時点で各社の公式サイトに掲載されている価格を見ると、会社全体で月額約 NT$1,500・人数無制限のプランもあれば、ユーザー数に応じて 1 人あたり月額数百台湾ドルのプランもあります。この価格帯は、業務が同業と近く、初めてシステム化する企業に向いています。問題が出てくるのは、会社が成長し、業務がソフトの標準と合わなくなってからです。

クラウド ERP はいつ足りなくなり始めるのか？

社員が ERP の外で Excel を開き始める、同じデータを 2 つのシステムに入力している、管理者が求める帳票を手作業で組み立てている。これがクラウド ERP では足りなくなってきたサインです。慌てて入れ替える前に、どこで詰まっているかを確かめます。

ERP の価値は、受注・購買・在庫・生産・会計を同じデータで連動させることです（Gartner の ERP の定義も、中核業務プロセスの統合を軸にしています）。どこか 1 つの工程が ERP の外に出ると連動が途切れ、月末の照合、在庫数、原価計算が合わなくなっていきます。

実務でよくあるのは次の 3 つです。

• 生産面：製品構成が多階層、代替部品が多い、能力に応じたスケジューリングが必要など、パッケージの BOM とスケジューリング機能では表現しきれない。
• 連携面：注文は EC、店舗 POS、LINE から入り、出荷は倉庫システムで行うため、データを手作業でインポート・エクスポートしている。
• 管理面：管理者が求める帳票が作れない、または 1 枚の伝票を ERP、Excel、承認システムにそれぞれ入力している。

以下の 3 節で、それぞれ 2 つの進め方を説明します。

複雑な BOM とスケジューリングは、モジュール追加かカスタム開発か？

BOM の階層が多い、作業実績入力やスケジュールボードが足りないだけなら、ERP を残して生産モジュールを追加すれば十分です。受注ごとに配合や工程を変えるなど、製造プロセス自体が競争力なら、生産管理をカスタム開発します。

BOM（部品表）は、製品がどの部品をいくつ使って構成されているかを示すもので、MRP はその BOM と受注から、何をいつ購入すべきかを計算します（ASCM のサプライチェーン辞典に両者の標準的な定義があります）。多くのクラウド ERP は標準的な多階層 BOM に対応していますが、顧客仕様によって部品が変わる、外注加工を工程ごとに価格設定する、設備と人員の実際の能力を考慮してスケジューリングする、といった場面では行き詰まりやすくなります。

進め方 1：パッケージを残してモジュールを追加。 ERP の品番・在庫・原価はまだ使いやすく、現場の工程だけが足りない場合に向いています。作業実績入力、スケジュールボード、品質検査などのモジュールを別に作り、完成数量と材料消費を ERP に書き戻します。単一業務のモジュールは NT$50 万〜100 万が一般的で、実績入力フォームやスケジュールボードのような小規模な追加は NT$15 万からです。

進め方 2：カスタム開発。 配合、工程、価格ルールそのものが会社の専門性で、パッケージでは多くの回り道が必要になり、ERP のバージョンアップのたびに設定し直している場合に向いています。カスタム開発では生産管理を独立したシステムにし、会計は ERP に残すのが一般的です。複数部門にまたがる中規模システムは、範囲によりますが NT$100 万〜250 万が一般的です。

EC・POS・倉庫・LINE と連携したいのに ERP が開放されていないときは？

まず ERP の API やファイル入出力の有無を確認します。API があれば直接連携でき、1 か所約 NT$5 万〜20 万です。ファイル出力だけなら定期的なファイル交換で同期し、出力も制限が多く連携先が増え続けるなら、受注センターをカスタム開発します。

よくある連携ニーズは次のとおりです。

• EC：ネットショップの注文を自動で ERP の売上伝票にし、在庫をショップに書き戻して売り越しを防ぐ。
• POS：店舗の売上と電子発票（台湾の電子インボイス）のデータを ERP に戻す。発行・取消・値引きを帳簿と一致させる必要があり、流れは台湾財政部の「電子発票実施作業要点」で確認できます。
• 倉庫（WMS）：ERP から倉庫へ出荷指示を出し、ピッキングと出荷の結果を書き戻す。
• LINE：注文確定、出荷、支払いのリマインドを LINE 公式アカウントで顧客に通知する。LINE の Messaging API はプッシュ送信と応答メッセージのインターフェースを提供していますが、プッシュ送信数は公式アカウントのプランによって課金されるため、月間の送信数を先に見積もっておきます。

進め方 1：パッケージを残して連携。 ERP 自体は使いやすく、データを自動で出し入れしたいだけの場合に向いています。JoinX が比漾百貨のウェブサイトと EC を構築した際も、既存の ERP、POS、鼎新（Digiwin）の会計システムを残し、連携によってオンラインとオフラインを統合しました。費用は連携ポイント単位で、1 つあたり約 NT$5 万〜20 万、ERP ベンダーの API モジュールは別途です。詳しくは ERP 連携サービスをご覧ください。

進め方 2：カスタム開発。 つなぐシステムが 3〜4 つを超えて互いに同期する必要がある、または ERP の API の制約が多く、連携のたびに回り道が必要な場合に向いています。このときはカスタムの「受注センター」をハブにして、EC・POS・倉庫・LINE をまずそこにつなぎ、ERP は会計だけを担います。中規模の受注システムは NT$100 万〜250 万が一般的です。

帳票が作れない、伝票を二重入力している場合はどうするか？

帳票が作れないのは、データは ERP にあっても形式が合わないためで、帳票ツールへの出力や帳票モジュールで解決します。二重入力は業務が ERP の外で途切れているためで、そのフォームや承認を ERP につなぎ直すか、工程ごとカスタム開発します。

二重入力のコストは過小評価されがちです。1 日に十数枚、1 枚を 2 回入力すれば、1 年で相当な人手になり、帳簿の入力ミスも生まれます。どの伝票を誰が入力し直しているかを数えれば、どこを補うべきかが分かります。

進め方 1：パッケージを残してモジュールを追加。 ERP のデータは揃っていて、見せ方や前段のフォームだけが足りない場合に向いています。たとえば見積書や購買依頼をオンラインフォームにし、承認後に自動で ERP の伝票にする、あるいは ERP のデータを定期的に帳票ツールへ取り込み、管理者が求める粗利や在庫回転の分析を作る、といった方法です。こうした小規模な追加は NT$15 万からです。

進め方 2：カスタム開発。 帳票に必要なデータがそもそも ERP になく、たとえば現場の作業時間、外勤の手配、会員の行動などで、しかもその業務が毎日変わる場合に向いています。ERP の外にフォームを積み上げるより、その業務プロセスを 1 つのシステムにして ERP と照合するほうが確実です。シンプルなカスタム ERP は約 NT$45 万からです。

残す・連携する・カスタム開発する、費用と期間はどう違うのか？

2026 年の台湾の案件で見ると、連携は 1 システム約 NT$5 万〜20 万、小規模な追加は NT$15 万から、モジュールは NT$50 万〜100 万、シンプルなカスタム ERP は約 NT$45 万からです。金額は連携先の数と ERP の開放度で決まります。

クラウド ERP の月額費用、ERP ベンダーの API モジュールとライセンス費用は別途です。カスタムシステム稼働後の保守は別契約になります。

どの進め方を選ぶべきかはどう判断するか？

次の順に確認すれば、ほとんどの企業は 3 番目で決められます。詰まっているのがデータの流れだけなら連携、業務がひとまとまり足りないならモジュール追加、中核業務まで回り道が必要な場合に限りカスタム開発です。

1. 毎日入力し直しているデータを書き出す：どの伝票が 2 か所以上で入力され、誰が、1 日に何枚入力しているか。
2. ERP の開放度を確認する：API があるか、スケジュールでインポート・エクスポートできるか、ベンダーの API モジュールの料金体系はどうか。
3. 足りないのがデータの流れか業務かを見極める：データはあるが同期していないなら連携、業務がまるごと ERP の外にあるならモジュール追加。
4. 中核業務が設定で対応できるかを確かめる：変える必要があるのが会社の競争力の源泉で、バージョンアップのたびに設定し直している場合に限り、カスタム開発を検討する。
5. 段階的に稼働させる：最も困っている工程から始め、安定したら次へ広げる。一度にすべてを入れ替えない。

パッケージ・クラウド・カスタム開発のより詳しい比較は、ERP はどう選ぶ？パッケージ・クラウド ERP・カスタム開発の判断基準をご覧ください。

カスタム開発を選んだ企業も、一度で完成させることはほとんどありません。欣晨快遞の物流管理システムとドライバー用 APP は 2025 年から段階的に拡張して第 5 版に、驊曖體育のヨガスタジオ管理システムは 2020 年から第 9 版までリリースを重ねてきました。どちらも中核業務を先に稼働させ、運営の必要に応じて拡張しています。

よくある質問