ウランバ・ブログ
Salesforceで受注管理の実装時の傾向
Salesforceは営業管理（SFA）や顧客管理（CRM）として広く利用されていますが、「受注管理」に関しては課題を感じている企業も少なくありません。
結論から言うと、Salesforceの受注管理の課題は標準機能の前提理解不足・業務プロセスとの不一致・運用設計の甘さに起因するケースが大半です。本記事では、Salesforce受注管理における代表的な課題を整理し、背景と対処の選択肢を網羅的に解説します。
Salesforce受注管理の用語・前提整理
Salesforceで語られる「受注管理」は、以下のオブジェクトを前提に構成されます。
商談（Opportunity）：受注見込み案件。受注確度や金額を管理
商談商品（Opportunity Product）：商談に紐づく明細
契約（Contract）：継続取引や期間管理が必要な場合に使用
注文（Order）：受注後の正式な注文情報
標準では「商談＝受注管理」と誤解されがちですが、受注後業務（売上計上・請求・出荷）まで含めるかどうかで設計の難易度が大きく変わります。
Salesforce受注管理でよくある課題パターン
Salesforceにおける受注管理は、主に以下のオブジェクトを中心に構成されます。
商談（Opportunity）：案件・受注見込みを管理する単位
商談商品（Opportunity Product）：商談に紐づく商品明細
見積（Quote）：金額・条件を提示するための情報
受注（受注済み商談）：商談フェーズを「受注」に更新することで表現
重要な前提として、Salesforce標準では「受注専用オブジェクト」は存在せず、商談＝受注管理の中心という設計思想になっています。この前提を理解しないまま導入すると、後述する課題が顕在化しやすくなります。
Salesforce受注管理でよくある課題パターン
1. 商談フェーズと実際の受注業務が合わない
営業プロセスが複雑な場合、商談フェーズだけで受注状況を正確に表現できず、現場で混乱が生じます。
2. 見積・契約・請求との連携が弱い
Salesforce単体では、契約管理や請求管理まで一気通貫で行うには限界があります。
3. 商談商品管理が煩雑になる
商品点数が多い、割引条件が複雑な場合、入力負荷が高くなり運用が形骸化します。
4. 受注後の変更・キャンセル管理ができない
受注後の金額変更や一部キャンセルを標準機能で扱いづらい点も課題です。
5. 現場がExcel併用から抜け出せない
Salesforce上の受注情報が不十分なため、結局Excelで補完する運用が残ります。
課題が発生する原因・背景
これらの課題の背景には、以下の要因があります。
Salesforceが営業管理中心のツールであること
自社の受注業務を整理せずにシステムに当てはめている
標準機能とカスタマイズの線引きが曖昧
現場運用を考慮しない初期設計
特に「Salesforceで何でも管理できる」という前提で設計すると、
受注管理で無理が生じやすくなります。
Salesforce受注管理における対処法の選択肢
1. 商談＝受注と割り切ったシンプル運用
受注管理を商談フェーズに集約し、業務をSalesforceに合わせて簡素化します。
2. カスタムオブジェクトで受注管理を分離
商談とは別に「受注」オブジェクトを作成し、業務実態に近づける方法です。
3. 外部システムとの連携を前提にする
契約・請求・会計は基幹システムに任せ、Salesforceは受注前後の情報管理に集中します。
4. AppExchange製品の活用
見積・契約・受注管理に特化したアプリを導入する選択肢もあります。
注意点・よくある失敗例
カスタマイズを増やしすぎて保守性が低下する
現場の入力負荷が高く定着しない
「受注」の定義が部署ごとに異なるまま運用開始する
将来の業務拡張を考慮せず設計する
Salesforce受注管理は、システムの問題ではなく設計と運用の問題であるケースがほとんどです。自社の受注業務を整理した上で、適切な管理範囲と方法を選択することが重要です。