ERPとSalesforceの連携が失敗する理由と、その直し方

SAPとSalesforceの連携が失敗する原因は、たいてい技術ではなくビジネス側にあります。同期は動いていても、データが利用者の判断に使うには古すぎる。2つのシステムで、どちらの顧客レコードが正しいのかが食い違っている。更新で連携が壊れても、そのフローを誰も担当していない。対処法は、利用者の判断から逆算して設計し、先にデータを整え、規模に合ったミドルウェアを選び、すべてのフローにオーナーと障害時の計画を持たせることです。

この記事は、SalesforceをSAPにつなぐCIO、営業オペレーション担当、連携リードに向けて書いています。失敗の4つのパターン、連携の選択肢、信頼できる連携に必要なこと、そして仕様書のテンプレートを取り上げます。

私はこれまで、システム間の遅延がわずか1時間でも見積ミスが起き、失注につながった企業と仕事をしたことがあります。原因はたいてい、営業担当が見積の根拠にする在庫データにどれだけの鮮度が必要かを、誰も尋ねていなかったことです。

連携は、技術的には動いていて、商売としては壊れていることがあります。この違いが出発点です。

判断に対して同期の頻度が合っていない

バッチ同期で足りるデータもあります。しかし、納期回答に使う在庫（ATP）、価格、受注ステータスのように、顧客がいますぐの回答を期待するデータでは足りません。

失敗のパターンはこうです。連携チームが、データ量から見て技術的に都合のよい方式で作り、バッチの間隔も技術的な理由で決めます。その頻度が利用者の判断を支えられるかどうかを、ビジネス側の誰も確認しません。

仕様を決める前に、まず1つだけ質問してください。使い物になる範囲で、データはどこまで古くてよいのか。得意先マスタの更新なら、日次で足りるかもしれません。B2B営業の在庫状況であれば、15分を超えると問題です。

1. 01得意先マスタSAPからSalesforceへ、24時間
2. 02価格表SAPからSalesforceへ、1時間
3. 03在庫状況SAPからSalesforceへ、15分
4. 04成立した商談SalesforceからSAPへ、即時
5. 05受注ステータスSAPからSalesforceへ、15分
6. 06請求書と入金SAPからSalesforceへ、24時間

見積、受注、請求が一致する

データ品質のミスマッチ

Salesforceの会社名の表記がSAPの得意先マスタと違っていれば、同期のたびに不一致が生まれ、手作業での修正が必要になります。

私は、SalesforceとERPの間で基本的な顧客情報の突き合わせに毎週何時間も費やしているチームと仕事をしてきました。また、2つのシステムが「取引先」の定義を別々に持っていたために、顧客階層のマッピングだけで数週間かかったプロジェクトも見てきました。システムは何年も別々に保守され、誰もマッピングしていない形で乖離していたのです。

連携の前にデータを整えてください。当たり前に聞こえます。それでいて、最も一貫して省かれる工程です。

規模に合わないアーキテクチャ

ポイントツーポイント連携は、2つのシステム、少数のフロー、安定したプロセスならうまくいきます。始めるには最も安い方法です。

ただし、規模には耐えません。SAPのモジュールを追加する、Salesforceに新しい事業部が加わる、3つ目のシステムが入る。そのたびに接続が増えます。それぞれを個別に保守し、テストし、障害対応しなければなりません。

ミドルウェア（SAP Integration Suite、MuleSoft、Boomiなど）なら、一元的な監視とエラー処理を備えた、統制のとれた単一のレイヤーが手に入ります。引き換えに、アーキテクチャとガバナンスへの先行投資が必要です。ミドルウェアを導入しても、責任者を明確に置かない企業は、ポイントツーポイントと同じ問題を抱えたうえに、誰も理解していないプラットフォームまで抱えることになります。

連携ガバナンスの欠如

Salesforceのリリースも、SAPのサポートパッケージも、フローを壊す可能性があります。APIの変更、新しい入力規則、変更された項目、新しい認証要件などです。作って終わりにされた連携は、誰も回帰テストしなかった最初のアップグレードで壊れます。本稼働後の失敗で、私が最もよく目にするのがこれです。

SAP Integration Suite：SAP BTP上にあるSAPの連携プラットフォームで、SAP中心のシステム構成では自然な選択です。IDoc、BAPI、OData、SAPのメッセージ形式を得意とし、よくあるSAPのシナリオ向けに構築済みのコンテンツがあります。複雑な業務プロセスには、やはり独自の連携フローと、確かな連携スキルが必要です。まだSAP PI/POを使っている場合、そのメインストリームメンテナンスは2027年末に終了するため、新しいSalesforceのフローはそこに構築しないでください。RISEの場合は、追加で購入する前に、契約にすでに含まれているSAP BTPの利用権を確認してください。

MuleSoft：2018年からSalesforce傘下にあり、豊富なコネクタライブラリ、公式のSAP S/4HANAコネクタ、SAPのオーダー・トゥ・キャッシュ向けのアクセラレータテンプレートを備えています。すでに保有しているなら、有力な選択肢です。SAP色の強い組織にとっての落とし穴は、MuleSoftが別のスキルセットだということです。SAPプログラムを動かしているチームが、MuleSoftのアーキテクチャまで設計すべきチームである可能性は低いでしょう。

Boomi：クラウド型の連携プラットフォーム（2021年にDellから独立）で、SAPとSalesforceのコネクタを備え、MuleSoftより導入のハードルが低いのが特徴です。MuleSoftのコストや複雑さは避けつつ、統制のとれたミドルウェアを使いたい中堅企業には、妥当な選択です。

ポイントツーポイントのAPI：SalesforceとSAPの間でRESTやSOAPを直接呼び出す方式で、ミドルウェアのコストがかかりません。そのかわり、厳格なAPIのバージョン管理、リリースごとの回帰テスト、両方のシステムを理解するチームが必要です。単純で安定したケースなら問題ありません。複雑な用途では、負債を積み上げる仕組みになります。

SAP側のプラットフォームについては、私のSAP CPIとIntegration Suiteのガイドでさらに詳しく解説しています。CRMそのものの比較は、SAPと組み合わせる5つのCRMをご覧ください。

1. すべてのフローの仕様：項目、方向、頻度、キーのマッピング、そして2つのシステムが食い違ったときにどうするか。
2. 明示的な障害設計。同期が失敗したとき、処理中のデータはどうなるか。何回リトライするか。誰にアラートが届くか。手動での復旧手順は何か。ほとんどの連携は、この点の設計が不足しています。
3. アップグレードのたびの回帰テスト。Salesforceは年3回のメジャーリリースがあり、SAPにもサポートパッケージとアップデートがあります。重要なフローを網羅する自動テストスイートを、そのたびに事前に実行すべきです。
4. アラート付きの監視。黙って失敗するほうが、騒がしく失敗するよりたちが悪いものです。何日も積み上がったエラーは、数分で見つけたエラーよりはるかに直しにくくなります。
5. オーナー。連携が何をしているかを知り、壊れたことに気づき、直すためのアクセス権と権限を持つ人が1人必要です。

仕様書を書き始める前に、フローごとに1行ずつ埋めてください。空欄が残るなら、そのフローはまだ構築できる状態ではありません。以下の値は例示です。ご自身の値は、そのデータを使う人たちと合意してください。

フロー	方向	トリガーと頻度	許容できる最も古いデータ	システムオブレコード	失敗時の対応	オーナー
得意先マスタ	SAPからSalesforceへ	変更時	24時間	SAP	リトライし、その後データスチュワードにアラート	得意先マスタデータのオーナー
在庫状況	SAPからSalesforceへ	要求時、またはほぼリアルタイム	15分	SAP	「オペレーション部門に要確認」のフラグを表示	サプライチェーンシステムのリード
価格表と条件	SAPからSalesforceへ	変更時	1時間	SAP	古い価格での見積をブロック	価格管理マネージャー
成立した商談から受注伝票へ	SalesforceからSAPへ	クローズ時	即時	受注伝票が作成されるまではSalesforce、作成後はSAP	キューに保持し、営業オペレーションにアラート	営業オペレーションのリード
受注・出荷ステータス	SAPからSalesforceへ	マイルストーンごと	15分	SAP	リトライし、その後連携サポートにアラート	連携リード
請求書・入金ステータス	SAPからSalesforceへ	日次	24時間	SAP	財務システム担当にアラート	財務システムのリード

「許容できる最も古いデータ」の列は、ほとんどのチームが一度も埋めない列です。連携チームだけで決めず、判断を下す利用者と合意してください。すでに遅れが出ている場合は、SAP Integration Suiteの導入遅延で、よくある原因を取り上げています。

顧客レコードが一致しない。原因：2つの顧客マスタを一度も揃えていない。対処：本稼働の前に突き合わせを行い、顧客データのシステムオブレコードをSAPにして、マッピングを連携の中で強制します。

受注ステータスがSalesforceで更新されない。原因：連携が見積から受注まではカバーしているが、ステータスのコールバックをカバーしていない。対処：SAP SDから、受注のマイルストーンごとにSalesforceへステータス更新を返します。

見積価格と請求価格が違う。原因：Salesforce上で価格を手作業で管理しており、SAPの価格条件から乖離していく。対処：SAPを価格マスタとし、連携を通じて価格をSalesforceに取り込みます。

SAPのアップデート後に連携が壊れる。原因：アップグレード計画に連携の回帰テストが入っていない。対処：SAPのアップデートごとに、連携の回帰テストをスコープに含めます。

SalesforceはSAPと連携できますか？

はい。SAP Integration Suite、MuleSoft、Boomi、その他の連携プラットフォーム、または直接のAPIで可能です。典型的なフローは、得意先マスタの同期、成立した商談から受注伝票への連携、受注・出荷ステータスのSalesforceへの返送、見積用の価格のSalesforceへの取り込み、請求書・入金ステータスです。得意先マスタの同期は簡単です。複雑な価格設定、多数の会社コード、リアルタイムの在庫を伴うクオート・トゥ・キャッシュの全体は、大きなプロジェクトになります。

SalesforceはERPですか、それともCRMですか？

CRMです。パイプライン、商談、顧客とのやり取り、マーケティング、サービスを管理します。会計仕訳を転記したり、在庫を管理したりはしません。財務、調達、在庫、生産のERPはSAPです。うまく連携すれば、営業担当はSalesforceで在庫と入金ステータスを確認でき、経理はSAPで案件金額を確認できます。

ERPとCRMの連携が失敗する最大の理由は何ですか？

要件を、利用者の判断からではなく、技術から定義してしまうことです。連携は、間違った仕様に対しては正しく作られます。4時間前のデータ、請求書と合わない価格、遅れるステータス更新といった具合です。技術仕様を書く前に、各利用者グループがそのデータで下す判断と、必要な鮮度を文書にしてください。

ERPとSalesforceの連携を、長期にわたってどう保守しますか？

Salesforceのリリースと、SAPのアップデートのたびに、重要なフローの自動回帰テストを実行します。重要なフローはすべて、1日の終わりのレポートではなく、失敗した時点で発報するアラートで監視します。監視にアクセスでき、両システムの変更計画に加わるオーナーを指名してください。

SalesforceとのSAP連携に、SAP Integration Suiteを使うべきなのはどんなときですか？

SAPが主役のシステムであり、SAP BTPを利用でき、フローにIDoc、BAPI、SAPのメッセージ形式といったSAP固有のコンテンツが含まれるときです。すでにMuleSoftやBoomiに大きく投資している場合、チームにSAPの連携スキルがない場合、SAPが非SAP中心のフローの脇役にすぎない場合には、弱い選択になります。Salesforceをスコープに含む新規のRISEプログラムでは、自然な出発点です。

ERPとSalesforceの連携プロジェクトには、どれくらいかかりますか？

構築済みのコンテンツを使った標準的なスコープ（得意先マスタの同期、見積から受注まで、基本的な受注ステータス）なら、データがきれいで、専任の連携開発者がいる前提で、スコーピングから本稼働まで通常8〜16週間です。複雑な価格設定、複数のエンティティ、与信管理、リアルタイムの在庫を含むクオート・トゥ・キャッシュの全体では、通常4〜9か月かかります。超過の主な原因は、プロジェクトの途中で見つかるデータの問題と、構築中に追加されるフローです。構築を始める前に、データ品質の評価を実施してください。