よくある課題への参考アーキテクチャです。ERPは社内業務を問題なく回していますが、ECモールと通信することは想定されておらず、担当者が注文をシステム間で手入力し続けています。
これは参考アーキテクチャであり、導入事例ではありません。このページに顧客名や特定案件の数値は含まれていません。
課題
数年前に導入したERPが、在庫、会計、生産を安定して支えている企業。現在は加えて、2〜3のECモール、自社サイト、実店舗でも販売しています。
現状はこうです。毎朝、担当者が各チャネルから注文をダウンロードし、ERPに手入力します。在庫は1日1回しか更新されないため、売り越しが発生します。顧客から注文について問い合わせがあると、誰かが三つのシステムを開いて調べます。
ERPの入れ替えは答えになりません。ERPは役割を果たしていますし、置き換え費用は課題の大きさに見合いません。
提案する構成 — 中間層
ERPも改修せず、ECモール側も改修しません。その間に立ち、双方向にデータを翻訳し、状態を同期し続けるサービスを構築します。
中間層にする理由
- ERPに手を入れないため、稼働中の事業を危険にさらさない
- チャネルを追加する際は、コネクタを1本書くだけで済み、他に影響しない
- あるモールがAPIを変更しても、そのコネクタだけ直せばよい
- 不一致を追跡するとき、ログを見る場所が一か所に定まる
データ種別ごとに正の情報源を決める
このプロジェクトで最も重要な決定事項です。最初の1行を書く前に確定させてください。
| データ | 正の情報源 | 方向 |
|---|---|---|
| 商品マスタ、価格 | ERP | ERPから各チャネルへ配信 |
| 引当可能在庫 | ERP | ERPから配信、高頻度 |
| 新規注文 | 販売チャネル | チャネルからERPへ投入 |
| 出荷状況 | ERP | ERPからチャネルへ返す |
| 顧客情報 | 方針による | 明示的に決める必要あり。争点になりやすい箇所 |
難所は在庫
チャネルごとに在庫を固定配分すると在庫が遊びます。チャネルAは売り切れているのに、チャネルBが売れない在庫を抱える状態です。逆に全数量を全チャネルに見せれば、売り越しは確実に起きます。
実務的な中間解は、どのチャネルにも見せない安全在庫を確保し、残りを共有することです。注文が入った時点で、ERPの反映を待たずに中間層で在庫を減算します。これにより、同期の合間に二つのチャネルが同じ1点を売ることを防げます。
在庫は他のデータよりはるかに高頻度で同期してください。数時間ごとではなく、数分ごとです。
想定される障害点
| 状況 | 対処 |
|---|---|
| モールAPIの流量制限 | キューに積んで流量を抑え、在庫を他データより優先する |
| ERPの保守停止 | 中間層が注文をキューに保持し、復旧後に再送する |
| 注文の二重投入 | 注文ごとに一意キーを持たせ、ERP側で重複を拒否する |
| モールが予告なくAPIを変更 | 日次の自動チェックで構造変化を検知して通知する |
| 時間の経過とともにずれが蓄積 | 夜間に全件照合し、差異レポートを出す |
手動の経路は必ず残す
自動化がどれだけよくできていても、詰まった注文を担当者が確認し、手で流せる画面が必要です。いつか必ず、モールが想定外の形式でデータを返す日が来ます。そのとき開発者を呼ばずに対処できる必要があります。
進め方
- まず一方向から。 1つのモールから注文をERPへ取り込みます。手入力と2週間並行して運用し、注文単位で突き合わせます。
- 在庫同期を追加。 低い頻度と大きめの安全在庫から始め、確信が持てた分だけ詰めていきます。
- 残りのチャネルへ拡大。 コネクタを1本ずつ、順次追加します。
- 出荷状況を返す。 顧客対応の負荷が下がります。
- ダッシュボードと自動照合。 運用部門が毎日エンジニアを呼ばずに済むようにします。
ご用意いただきたいもの
- ERPのAPI仕様書。APIがない場合はデータベースへのアクセス
- 各モールの出店者アカウントと、APIキーを発行できる権限
- ERPと各チャネルの商品コード対応表 — 通常、最も煩雑な作業になります
- 安全在庫の方針の決定 — 売り越しリスクをどこまで許容するか
インフラ構築とソフトウェア開発の実務経験に基づいて執筆しています。スポンサーや製品の宣伝は含みません。