CRMと生産管理の連携で起きた5つの落とし穴｜受注を送る数量・キャンセル・再送の設計

CRMと生産管理システムのAPI連携とは、CRMで確定した受注の情報を、生産管理システムへ自動で送り、製造の指示につなげる仕組みです。営業が受注を入れれば、工場側で同じ内容を打ち直さなくて済みます。二重入力をなくす効果は大きい一方で、「何を・いつ・何回送るか」を決めないまま作ると、製造の現場に誤った指示が届きます。

この記事は、中小の製造業（個別受注生産）で、CRMと生産管理システムの連携を構築し、受入テストを進める中で見つかった落とし穴をまとめたものです。システムはまだ受入テストの段階のため、導入の成果ではなく「どこでつまずき、どう設計を直したか」を書きます。特定の製品に依らず、受注を外部システムへ送る連携なら同じことが起きます。

個別受注生産の案件管理そのものの考え方は、個別受注生産の案件管理を仕組み化する方法で解説しています。この記事はその先の、受注を製造へ渡す連携に絞っています。受注・在庫・出荷の情報をどこで一本化するかという、連携より手前の設計は受注・在庫・出荷を一本化する設計の考え方で扱っています。

落とし穴①：受注数をそのまま送ると、在庫で足りる分まで製造指示が出るのでは？

最初の版では、受注明細の数量（受注総数）をそのまま生産管理システムへ送っていました。この設計だと、倉庫に在庫がある分まで「作ってください」という指示になります。受入テストで、在庫を入れて再送しても送信数が在庫と合わない、という指摘が出て、問題がはっきりしました。

直し方は、送る数量を変えることです。受注数から在庫の引き当て分を引いた「生産依頼数」を計算し、その数だけを送るように改修しました。検証用の環境で確かめた結果は次のとおりです（2026年9月時点）。

条件	送った生産依頼数	在庫の引き当て	生産管理システムへの送信
受注5・在庫0	5	0	送る
受注5・在庫3	2	3	送る
受注5・在庫5	0	5	送らない
全量を引き当てた受注の再送	—	—	「対象外」と表示して送らない
生産依頼数と外注数量が食い違う	—	—	不一致を記録して送らない

この表は、数量の計算と送信の可否を、次の段の中間システムに届くところまで確かめた結果です。生産管理システム側の受付は、検証時点では確認できていません（落とし穴④で詳しく書きます）。

ここで大事なのは、「0なら送らない」「数が合わなければ止める」を明示的に作ったことです。数量を計算するだけでは足りません。計算結果が0のとき、相手に0件の指示を送ってしまう作りもありうるからです。

もう1つ、決めておくべき点があります。生産依頼数が空のとき、何を送るかです。今回の実装では、空のときは受注数を送る動きになっていました。過去データや手入力の受注で空が起こりうるなら、空のときは送るのか止めるのかを、仕様として決めておく必要があります。

落とし穴②：明細をキャンセルした瞬間、製造まで取り消されるのでは？

受注明細のステータスを「キャンセル」に変えると、その場で生産管理システムの製造も取り消される作りでした。仕様としては正しく動いています。ところが受入テストでは、キャンセルの操作に確認と通知がほしい、という要望が出ました。

営業にとってのキャンセルは、画面の選択肢を1つ変えるだけの操作です。しかし工場から見ると、材料の手配や段取りが進んでいる案件が止まる、重い出来事です。この重さの差を、システムが埋めていませんでした。

設計の考え方は次のとおりです。

1. キャンセルの操作に、確認の画面を挟む（「製造中の場合、生産管理システム側の製造も取り消されます」と明示する）
2. キャンセルが確定したら、製造の担当者と受注の担当者に通知する
3. キャンセル時に、引き当てていた在庫を元に戻す

3つ目は検証済みです。全量を在庫で引き当てた受注を取り消すと、保管在庫が0から5に戻り、引き当て済み在庫が5から0に戻ることを確かめました。一方、一部を製造に回した受注の取消は、中間のシステムまでは届きましたが、生産管理システムの検証環境では受付まで確認できていません。在庫を戻す処理と、相手側の製造を取り消す処理は、別々に確かめる必要があります。

落とし穴③：受注が届かない原因は、1つではないのでは？

受入テストの初日に、受注データが生産管理システムへ流れないという報告がありました。調べると、原因は1つではなく、次の3つが重なっていました。

• 送る側の情報が足りない：商品に図面や材質が入っていない
• 受け取る側のマスタがない：仕入先や外注製品が、生産管理システムに登録されていない
• エラーの後に処理が動き直さない：一度エラーになった受注は、原因を直しても自動では再送されない

マスタを整備して送れるようになった後も、別の受注で、図面番号を入れてもエラーになる、という報告もありました。このときの原因は、取引先が相手側に登録されていないことでした。画面に出るエラーが「送信に失敗しました」だけだと、使う人は図面の入力ミスを疑い続けます。

対処は2つです。

1. 受注明細に「再送」ボタンを付け、原因を直した後に人が送り直せるようにする
2. エラー文を日本語で具体的にする（「取引先が生産管理システムに未登録です」のように、何を直せばよいかまで書く）

なお、送信に失敗した分をまとめて再送する機能は作らず、まず1件ずつの運用で始めました。原因が受注ごとに違うため、まとめて送り直しても同じエラーが返るだけになりやすいからです。

落とし穴④：画面の「再送完了」を、相手の受付成功と思い込んでいないか？

今回の連携は、CRMから中間のシステムを経由して生産管理システムへ届く、多段の構成です。検証のとき、受注明細の画面で再送ボタンを押すと「再送完了」と表示されました。ところが経由先のレコードを確かめると、生産管理システムの検証環境は「対象データが見つかりません」というエラーを返していました。

画面の「完了」は、次の段に渡したことしか意味していませんでした。最終的な受け手が受け付けたかどうかは、別に確かめないと分かりません。

この経験から、連携の設計では次の3点を区別しています。

確認したいこと	どこで見るか
CRMが送信処理を実行したか	CRMの画面表示・実行ログ
次のシステムに届いたか	経由先のレコード
最終的な受け手が受け付けたか	相手側の応答（成功・エラーの内容）を記録した項目

運用で使う画面には、3つ目の結果を表示するのが理想です。それができない間は、「画面の完了表示は相手の受付を保証しない」と運用手順に書いておきます。

落とし穴⑤：一度送った商品を、あとから自由に編集できてしまうのでは？

受入テストで、商品の編集と途中保存についての要望があり、仕様を見直しました。生産管理システムに一度送った商品を、CRM側で書き換えると、両方のデータが食い違います。そこで、初回の送信が済んだ商品に「送信済み」の印を付け、それ以降は編集をロックする仕様にしました。送信前なら、途中保存も編集も自由です。

ただし、この印にも限界があります。印は「CRMが一度送った」ことを示すだけで、相手側に今も登録されていることは示しません。検証では、印が付いている商品でも、相手側の受付で「対象データが見つかりません」になる例がありました。

マスタの運用ルールも同時に決めておくべきです。受入テストの途中で、重複していた材質のマスタを削除したところ、その材質を使っていた商品の材質欄が空になり、生産管理システム側のコードと合わなくなりました。使用中のマスタは削除せず無効にする、といったルールを先に決めておけば防げます。

生産管理システムとの連携前に何を決めておけばいいですか？

ここまでの5つを、設計の前に決めておく項目として並べ直します。

1. 在庫に責任を持つのはどちらのシステムか
2. 送る数量は受注数か、在庫を引き当てた後の数か。0のとき、空のとき、数が合わないときにどうするか
3. 受注のキャンセルは、相手側で何を起こすか。確認の画面と通知を挟むか。在庫を戻すか
4. 相手が受け付けるために、事前登録が必要なマスタは何か（商品・図面・材質・仕入先・外注品・工程など）
5. エラー時に、何が足りないかが日本語で分かるか
6. 送信に失敗した受注を、誰がどこから送り直すか（1件ずつか、まとめてか）
7. 画面の「完了」は、どの段階の成功を意味しているか。最終的な受け手の応答をどこに残すか
8. 一度送ったデータの編集をどこまで許すか。マスタの削除を許すか
9. どちらのシステムのコード（商品番号など）で相手とやり取りするか
10. 検証用の環境で、在庫0・一部・全量・取消・不一致の各条件を試したか。テストデータを確実に消したか

連携の不具合は、作った人の手元では見えにくく、受入テストで現場の方が触って初めて出てきます。今回も、ここに挙げた落とし穴の多くは、営業と製造の担当者の方からの指摘で見つかりました。設計の段階でこのリストを双方で確かめておくと、テストの手戻りを減らせます。

システムを足すたびに受け渡しの決めごとは増えます。ツールを増やすほど全体がかみ合わなくなる問題は、MAツール・CRM導入が失敗する理由（部分最適の罠）にまとめています。連携の前提となる、見込み客から受注までの流れをCRMでどう管理するかから整理したい場合は、見込み客から受注までのプロセス管理の支援でご相談を受け付けています。

決めることを洗い出す段階の進め方は、要件定義のヒアリングで漏れを防ぐ「全部見せてください会」にまとめています。

よくある質問

生産管理システムとCRMは、どちらで在庫を持つべきですか？

連携を作る前に、どちらが在庫に責任を持つかを1つに決めてください。今回の構築では、生産管理システムは製品在庫を持たず、在庫の引き当てはCRM側の役割と整理しました。この前提が決まっていないと、送る数量の計算も、キャンセル時に在庫を戻す処理も設計できません。

送信に失敗した受注は、まとめて再送できるようにすべきですか？

最初は1件ずつの再送で十分なことが多いです。今回の構築でも、一括再送は、まず1件ずつの運用で始めました。失敗の原因が受注ごとに違うため、原因を直さずにまとめて再送しても、同じエラーが繰り返されるだけだからです。先に用意すべきは、何が足りないかが分かる日本語のエラー文です。

生産管理システムとの連携テストは、本番環境で行ってもよいですか？

避けてください。製造指示や取消が実際の現場に届くおそれがあります。CRM・生産管理システムの双方に検証用の環境を用意し、在庫0・一部在庫・全量在庫・取消・数量の不一致といった条件を表にして、1つずつ結果を記録するのが安全です。テストで作ったデータは、削除した後に本当に消えたかまで確かめます。

生産管理システムのベンダーと、どこまで仕様を詰めればよいですか？

最低限、①相手が受け付けるために事前登録が必要なマスタ（商品・図面・仕入先・外注品・工程など）、②エラー時に返ってくる内容、③取消を受けたときに相手側で何が起きるか、の3点は書面で確認してください。今回の落とし穴の多くは、この3点のどれかが曖昧だったことから起きています。