目次
この記事のポイント
- Salesforceは顧客（Account・Contact）を軸に、営業・サービス・マーケティングを横断する業務基盤
- SAPはモノ・カネ（受注・在庫・会計）を軸にした基幹基盤。役割が違うため「どちらかに寄せる」判断は避ける
- つまずくのは機能比較ではなく、データの持ち方・連携の粒度・導入順序の3点
- 連携は「リアルタイム」より項目（どのデータをいつ渡すか）の定義が先。定義が曖昧なまま作ると二重管理が残る
01WHAT Salesforceは「顧客」、SAPは「モノとカネ」を軸にする
Salesforce は、見込み客から顧客までの情報（誰と、いつ、何を話し、いくらで受注したか）を一元的に管理する CRM です。標準で Account（取引先）・Contact（取引先責任者）・Opportunity（商談）・Case（ケース）といったオブジェクトを持ち、営業・カスタマーサービス・マーケティングの活動を同じ顧客データの上で動かせます。一方 SAP は、受注・購買・在庫・生産・会計という「モノとカネの流れ」を正確に記録し、財務諸表につながる数字を保証する ERP です。顧客との関係を厚くするのが Salesforce、取引の事実を正しく残すのが SAPという役割分担になります。
なぜ「どちらかに寄せる」判断が失敗しやすいのか
ERP に顧客管理機能（SAP の販売管理や CRM）があり、Salesforce にも受注金額や商品を扱う機能があるため、機能表だけを並べると重なって見えます。しかし実際に必要なのは機能の重複を消すことではなく、同一の事実を二重に持たないことです。たとえば「受注金額の正」は SAP、「商談の進捗と顧客とのやり取りの正」は Salesforce と決めてしまえば、双方の機能は競合せず補完関係になります。逆にこの線引きを曖昧にしたまま導入すると、SAP と Salesforce で金額が食い違い、どちらが正しいかを毎月確認する運用が発生します。
導入検討の場で最初に起きる3つの論点
実務では、①顧客・商談データの「正」をどちらに置くか ②連携する項目と頻度（リアルタイムか日次か） ③どちらを先に整えるか、の3点で議論が止まりがちです。順番としては、まずデータの持ち方を決め、次に連携の粒度を決め、最後に導入順序（スモールスタートの範囲）を決めるのが安全です。
用語の前提：Cloud という単位は「製品の括り」
Sales Cloud／Service Cloud は別々のシステムではなく、同じプラットフォーム上の機能セットです。契約（ライセンス）の単位が分かれているため、必要な機能から順に追加する進め方が一般的です。
02POINTS 導入検討を前に進める4つのステップ
- 顧客データの「正」を決める。取引先名・担当者・商談金額・契約情報のうち、どの項目を Salesforce が正とし、どれを SAP から受け取るかを一覧表にします。ここが最初の成果物です。
- 連携項目と頻度を決める。受注確定・請求・出荷など、SAP 側で確定する事実だけを連携対象に絞ります。リアルタイムが必要なのは例外処理だけで、多くは日次・イベント駆動で足ります。
- スモールスタートの範囲を決める。営業部門 1 チーム・1 プロセス（例：見積から受注まで）に限定して開始し、運用の型を作ってから横展開します。
- 運用・内製化の担当を決める。項目追加やレポート作成をベンダー待ちにすると現場が離れます。管理者（Salesforce 管理者）を社内に置き、変更手順を文書化します。
最初の連携は「片方向・3 項目」から
受注確定後に SAP から Salesforce へ「受注番号・金額・ステータス」の3項目を渡すだけでも、営業は最新の契約状況を確認できます。双方向連携から始めるとエラー時の切り分けが難しくなるため、まず片方向で効果を出します。
03INSIGHT ADT は「SAP と Salesforce の境界線」の設計から支援します
当社は SAP の導入・移行・運用支援を主軸に、Salesforce の導入設計・開発・運用までを一貫して支援しています。強みは、SAP 側の受注・請求データがどう作られるかを理解したうえで Salesforce 側の連携設計を書けることです。連携の要件定義を CRM 側だけで完結させると、後工程で SAP 側の項目・タイミングと噛み合わず手戻りが発生します。
具体的には、①顧客・商談データの正の定義 ②連携項目表（項目名・型・更新契機・エラー時の扱い） ③導入順序と内製化計画、の3点を成果物として先に作ります。導入企業側に Salesforce 管理者を育てる前提で設計するため、運用開始後にベンダー依存になりにくい形になります。
現場でよく見かけるつまずきは 3 つあります。1 つ目は、SAP にある項目をそのまま Salesforce にも作り、結果として二重管理が残るケースです。2 つ目は、双方向のリアルタイム連携から始めてしまい、金額の差異が出たときにどちらが正しいか分からなくなるケース。3 つ目は、連携後に発生するエラー処理（再送・取消・権限不足）の担当を決めていないケースです。連携設計の成果物には「正常系」だけでなく「異常時の手順」を必ず含めてください。開始前にこの 3 点を決めておくだけで、稼働後の問い合わせ件数が大きく変わります。
豆知識：オブジェクトは「表」、項目は「列」
Salesforce の「オブジェクト」はデータベースの表、「項目（フィールド）」は列に相当します。標準オブジェクト（Account／Contact／Opportunity／Case）は変更できない土台で、業務固有の情報はカスタムオブジェクトやカスタム項目として追加します。SAP のテーブル設計に慣れた方ほど、この対応関係で整理すると早く理解できます。
まとめ
- Salesforce は顧客軸、SAP はモノ・カネ軸。優劣ではなく役割分担で考える
- 決めるべきは①データの正 ②連携項目と頻度 ③導入順序の3点
- 金額・商品・在庫は SAP を正とし、商談・対応履歴は Salesforce を正とする
- 連携は片方向・少項目から始め、項目表を成果物として残す
- 社内に Salesforce 管理者を置き、変更手順を文書化して内製化する
出典・参考
- Salesforce 公式サイト（製品・機能の一次情報） https://www.salesforce.com/jp/
- Salesforce Help（設定・データモデルの一次情報） https://help.salesforce.com/
- Trailhead（公式学習コンテンツ） https://trailhead.salesforce.com/ja
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-12）の情報です。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。
04FAQ よくある質問
Salesforce と SAP はどちらか一方に統合すべきですか？
役割が異なるため、どちらかに寄せる判断は現実的ではありません。顧客との関係（見込み〜受注前）は Salesforce、取引の事実（受注・在庫・会計）は SAP を正とし、必要な項目だけを連携する形が一般的です。
連携にはどんな方式がありますか？
代表的なのは、Salesforce 標準の外部データ連携、SAP 側の API（OData 等）を経由する方式、中継基盤（iPaaS／SAP BTP 等）を使う方式です。方式の前に「どの項目を・いつ・どちら向きに」を決めることが重要です。
導入期間の目安はどれくらいですか？
1 チーム・1 プロセスのスモールスタートであれば数か月で運用開始できることが多く、全社展開や SAP 連携を含めると半年〜1年以上を見込みます。範囲の切り方で大きく変わります。
社内に専任担当が必要ですか？
項目追加・レポート作成・ユーザー管理を継続するため、管理者（Salesforce 管理者）の設置を推奨します。外部に委託し続けると、現場の小さな要望が滞留し利用が定着しにくくなります。