ECと基幹システムを連携する際の設計ポイント｜失敗しないために決めておくべきこと

この記事でわかること
BtoB-ECを立ち上げるとき、多くの会社は「ECサイトをどう作るか」に意識を向けます。しかし運用が始まってから問題になるのは、サイトよりも「ECの受注データを基幹システムにどう取り込むか」——つまり連携の設計であることがほとんどです。本記事では、製造業・卸売業のBtoB受注でつまずきやすい設計ポイントと、CSV・API・RPAの選び方を、実務の順番に沿って整理します。

なぜ連携プロジェクトは失敗するのか

「ECと基幹をAPIでつなぐ」「CSVで連携する」——方式の話は、実は設計のごく一部です。データをやり取りする仕組み自体は、方式さえ決まれば大きく外しません。

本当に難しいのは、その手前にある問いです。

• どの項目を、どの粒度で渡すのか
• 得意先ごとに違う単価や掛け率を、どちらのシステムが持つのか
• 電話やFAXで入った「EC外の受注」と、どう突き合わせるのか
• 訂正・追加・返品が入ったとき、どちらを正とするのか

これらは技術の問題ではなく業務の問題です。ここが曖昧なままつなぐと、連携は動いても運用が回りません。「システムは連携できているのに、結局手作業でチェックしている」という状態は、ほぼ例外なくこの設計不足から生まれます。

設計前に決めておくべき6つのこと

つなぐ前に、少なくとも次の6点を決めておく必要があります。BtoB受注ならではの論点も併記します。

特に落とし穴になりやすい3点

① コード体系のズレ（品番・得意先コード）

ECと基幹で品番や得意先コードの体系が違うと、連携のたびに変換が必要になります。「ECの商品コード＝基幹の品番」と単純に対応づけられないケース（1商品が複数品番、セット品、入数違い）は、BtoB特有です。ここを設計初期に整理しないと、後から変換テーブルの保守に延々と手作業が発生します。「今は運用でカバーできている」ものほど、連携時に表面化します。

② EC外受注との突き合わせ

BtoBでは、EC稼働後も電話・FAX・メールでの受注が残るのが普通です。ECの受注だけを基幹に流す設計にすると、EC外の受注と二重管理になり、結局どこかで人が合算することになります。「ECはあくまで受注チャネルの一つ」という前提で、基幹側の受注をどう一本化するかまで含めて設計する必要があります。

③ 訂正・追加・返品が入ったときの「正」

受注後の訂正・数量変更・返品が、EC側で起きるのか基幹側で起きるのか。どちらを正とし、もう一方にどう反映するのか。ここを決めていないと、連携は動いていても数字が合わなくなり、信頼できないデータになります。「めったに起きないから後で」と後回しにされやすく、後回しにされた分だけ影響が大きくなる論点です。

連携方式（CSV / API / RPA）は業務が決まってから選ぶ

方式の選定は、上記の業務設計が固まった後に行うべきです。方式ありきで業務を歪めると、必ず無理が出ます。

APIが常に最適というわけではありません。受注件数・運用体制・基幹システムの仕様・予算によって、最適な方式は変わります。実際には、CSVのままの方が費用対効果が高いケースも珍しくありません。

方式ごとの違いと選び方は、別記事「RPA・CSV連携・API連携の違いと選び方」で詳しく整理しています。

よくある失敗

例1：「CSVを自動で取り込みたい」が入り口だった
ご相談の入り口は「CSVで手作業運用している受注データを、自動で基幹に取り込みたい」というものでした。しかし要件を整理すると、真の原因は別にありました。ECと基幹とで、品番や得意先コードなどのコード体系が一致していなかったのです。この状態で自動化しても、処理が速くなるだけで、不一致そのものは解消されません。そこで、コードの変換テーブルを用意し、対応しきれない例外は基幹側で吸収する設計に変更しました。これまで人が判断して吸収していたルールは、自動化すると必ず設計として定義しなければなりません。手作業で回っている業務ほど、連携時に「決めごと」として表に出す必要があります。

例2：EC外の受注を設計に含めていなかった
電話・FAX・メールでの受注が一定数残っているお客様で、当初は「ECの受注だけ」を基幹に連携する設計にしていました。EC化する範囲だけを見ていたため、EC外の受注は視野から外れていたのです。結果、EC外の受注と二重管理になり、締めのたびに担当者が両方を突き合わせて合算していました。基幹側を受注の一本化先と定め、ECは受注チャネルの一つとして流す設計に変更したことで、合算作業がなくなりました。「ECはチャネルの一つ」という前提を設計に入れられるかが分かれ目でした。

あわせて読まれています