顧客情報システム：中東の防衛メーカーの事例

これは、中東の中堅防衛メーカーが顧客情報システムをどう立て直したかを示す事例です。顧客データは3か所に分かれ、見積は価格が一貫しないまま出され、承認はメールの中で行方不明になっていました。解決策は、Microsoft Dynamicsに一本化した顧客レコード、Experlogix CPQによるルールベースの見積、そしてSAP Cloud Integrationを通じた、承認済み見積のSAP販売管理（SD）への自動引き渡しでした。見積の所要時間は平均で35%短縮されました。長く、構成が複雑で、コンプライアンスの負担が重い販売サイクルを持つ製造業の、営業オペレーション、IT、財務のリーダーに向けて書いています。再利用していただきたいのは、終盤にある展開の順序と教訓です。

防衛関連のチームが顧客情報システムを求めるとき、たいていCRM以上のものを意味しています。求めているのは構造です。長い販売サイクル、コンプライアンスの重いワークフロー、顔ぶれの変わる意思決定者の中で、複雑な判断が文脈とともに一か所に収まる場所です。

防衛関連企業でデジタルトランスフォーメーションディレクターを務めていた私は、まさにこの解決を求められました。問題は努力不足ではありませんでした。人々は仕事をしていました。問題は、その努力に居場所がなかったことです。共有のプラットフォームも、可視性もなく、売っているものと計画しているものが揃っていませんでした。

中東にある中堅の防衛メーカーです。縁の下で事業を営んでいました。公に知られたブランドではなく、目立つことが目的ではありませんでした。その部品は、軍用航空機や機密通信に使われていました。

どの販売も、詳細な経路をたどりました。エンジニアリングレビュー、コンプライアンスチェック、社内承認、バージョン管理された見積です。混沌としていたわけではありませんが、重いプロセスでした。

顧客情報システムは、崩れかけていました。営業は一つのプラットフォームを使い、サポートは別のものを使っていました。オペレーションは、スプレッドシート、オフラインのフォルダー、誰かが開く前にすでに古くなっている文書で動いていました。

何が壊れていて、何を失っていたかは次のとおりです。

壊れていたこと	影響
商談の流れや意思決定者を把握するCRMがなかった	各案件がどこまで進んでいるか、共有できる全体像がなかった
価格が手作業で扱われ、一貫した記録がなかった	古い数字や食い違う数字のまま見積が出されていた
承認がメールで行われ、失われたり遅れたりすることが多かった	コンプライアンスの監査証跡が不完全だった
顧客レコードがシステム間で重複し、細部が少しずつ違っていた	どちらが正確な版か、誰にも言えなかった

書類上は、構造化されているように見えました。見積を作成から納品まで追ってみると、そこで破綻していました。承認は、担当者が不明なまま止まりました。価格は、誰が見積を出すかで変わりました。見積はメールのスレッドに埋もれていました。チームは同じ質問を何度も互いに投げかけていました。どれも劇的な失敗ではありませんでしたが、数か月のうちに小さな遅れが積み重なり、販売サイクルの長い事業にとって、失われた勢いは多くの人が思う以上に響きました。

目標は、すべてを置き換えることではありませんでした。何も使いにくくすることなく、摩擦を減らすことでした。チームがすでに働いている方法をシステムに反映させ、硬直したプロセスに人を押し込めないようにするのです。

設定に手を付ける前に、チームと時間を過ごしました。業務が取り込みから納品までどう流れるか、ツールがどこで邪魔になるか、人々がどこでデータを信頼しなくなったかを見ました。

そのセッションから、3つの優先事項が出ました。

1. 共有の顧客レコードを1つ、営業、サポート、オペレーションが同じ形式で見られるようにする。並行する版は、もう作りません。
2. 構造化された見積。 個人の習慣や古いテンプレートではなく、構成と価格の一貫したルールに従う。
3. つながった受注実行。 承認済み見積からSAP SDへの引き渡しをきれいにし、手作業での再入力をなくす。

システム	解決したこと
Microsoft Dynamics CRM	営業活動と商談に紐づく、一つの顧客レコード
Experlogix Configure Price Quote（CPQ）	製品構成のルール、価格ロジック、見積バージョン
SAP販売管理（SD）	受注の実行と履行
SAP Cloud Integration（CPI）	CPQとCRMをSAP SDにつなぐ連携層

基盤としてのMicrosoft Dynamics。 顧客情報が正確で、文脈の全体とともに見える場所が一つ必要でした。Dynamicsは、データのもつれをほどき始める足がかりになりました。このプラットフォームに慣れていたことが助けになり、OutlookやTeamsとの相性も助けになりました。人々にやり直しを求めることはありませんでした。必要だったのは、事業の動き方に合わせた調整です。チームが同じデータを、機能をまたいで同じ形式で見るようになると、信頼が育ち始めました。

構成と価格のためのExperlogix CPQ。 以前は、見積の作り方があまりに多様でした。人々は記憶と手作業の修正に頼っていました。Experlogixには、製品の組み合わせに関する定義済みルール、構成に結びついた価格、案件の種類と金額に応じた承認ルーティングを設定しました。最初は窮屈に感じられ、そう言う人も遠慮はしませんでしたが、曖昧さがなくなりました。エンジニアリング部門に届く見積がきれいになり、営業は過去の案件の記憶で価格を調整しなくなりました。

SAP CPIを通じたSAP SD。 受注にはすでにSAP SDが使われていました。ギャップは引き渡しでした。承認済みの見積を、まだSAPに打ち直す必要があったのです。2つをSAP CPIで連携させ、承認済み見積がそのまま受注としてSAPに投入されるようにし、顧客データと受注データがDynamicsとSAPの間で同期されるようにしました。限界にぶつかったところには、カスタムロジックを追加しました。すべての場面で洗練されていたわけではありませんが、機能しました。

1. 01顧客レコードMicrosoft Dynamics、全チーム共通の一つの版
2. 02構成と価格設定組み合わせと価格に関するExperlogix CPQのルール
3. 03承認案件の種類と金額に応じてルーティング
4. 04受注の作成SAP CPIが承認済み見積をSAP SDに投入
5. 05履行SAP SD、顧客データは同期されたまま

再入力なし。承認から受注までの監査証跡あり

展開は、おおよそ6〜8か月かけて段階的に行いました。派手なことは何もなく、変更を重ね、各段階で検証しました。

1. パイロット。 CRMとCPQに焦点を当てた、少人数のユーザーと特定のシナリオ。エッジケースを試し、ギャップを洗い出し、拡大の前に変更を加えました。
2. データをきれいにする。 顧客レコードは、Dynamicsに入れる前に統合と重複排除を行い、コンプライアンス文書を適切な商談に紐づけました。これは、設定よりも時間がかかりました。
3. 部門へ展開する。 パイロットのワークフローが洗練されたところで、営業、サポート、オペレーションへ展開しました。
4. SAP SDは途中で連携する。 CPQからSAPへの連携は、上流のシステムが安定してから稼働させました。初期の問題が受注に波及しないようにするためです。

セキュリティとコンプライアンスは、初日から設計に組み込みました。防衛関連のクライアントにとって、監査証跡の完全性とロールベースのアクセス制御は、任意ではありません。アクセスロールを明確に定義し、承認の証跡を追跡しました。データの所在地は早い段階で決めました。防衛分野の規則に沿って、すべてのデータをUAE国内にとどめました。それで最初は少し進みが遅くなりましたが、後でもっと深刻な問題が起きるのを防げました。

研修は実践的でした。短いセッション、的を絞った資料、ライブデモ、ハウツー動画を、1回で終わらせず、数週間から数か月にわたって続けました。定着は、最初から完璧ではありませんでした。着実な支援と目に見える効果が、最初のためらいを乗り越えさせました。転機は、チームが実際の場面でツールを使い、返ってくるデータが正しいと分かったときでした。

成果	変わったこと
見積の所要時間	平均で35%短縮。多くの案件で数時間、複雑な案件では数日を削減
構成の正確さ	検証ルールが、エンジニアリングに届く前に誤りを防いだ
監査対応	コンプライアンスチェックに、直前の駆け込み作業が不要になった
チーム間の足並み	営業、サポート、オペレーションが同じ顧客レコードで働いた

35%の短縮は、最初の1週間で起きたわけではありません。初期のサイクルでは、まだ確認や訂正がありました。製品ルールと価格ロジックが一貫すると、見積が速くなりました。営業担当者は、承認を追いかけることも、使い回したテンプレートを直すこともなくなりました。システムがそれらのステップを処理しました。

テクノロジーより足並みが大事。 技術的な構築は、簡単なほうでした。難しかったのは、チームに唯一の正しい情報源を信頼してもらい、自分用の記録を持ち続けるのをやめてもらうことでした。データが信頼できると示してから、頼ってもらうよう求める必要がありました。

機能より連携の細部が大事。 CPQからSAP SDへの連携が、システム全体に価値をもたらしました。単独のCRMと単独の見積に、手作業の受注入力を組み合わせたものでは、それぞれ少し役に立つ程度でした。摩擦が消えたのは、それらをつなぐところです。

支援と研修が定着させる。 展開して放置するのは、納品したとは言えません。研修は本稼働後も数週間、数か月続けました。定着が根付くか崩れるかは、この期間で決まります。

アーキテクチャは今も通用します。顧客レコードにCRM、構造化された見積にCPQ、受注実行にERP連携です。今、同じ取り組みを始めるなら、3つのことが変わります。

連携プラットフォーム。 SAP CPIは現在、SAP Integration Suiteの中のCloud Integration機能で、API管理、イベントベースの連携、構築済みの連携コンテンツと並んでいます。Dynamics、CPQ、SAP SDという流れは、今なら設計の手間が減るでしょう。このプラットフォームについては、私のSAP Cloud Integrationガイドで取り上げています。

SAP自身のCRMも候補に入ります。 SAP SDをバックエンドに持つなら、新しい案件では、今ではJouleを備えたSAP Sales Cloudを、Microsoft Dynamicsと比較すべきです。ここでDynamicsが正しい選択だったのは、すでに慣れていたからです。答えは今も機能と連携の好みによりますが、SAPネイティブの選択肢は、以前より現実的な有力候補になっています。選択肢については、私のSAPに合うCRMの比較で取り上げています。

米国連邦政府の範囲には、別のホスティングモデルが必要です。 このクライアントには不要でしたが、米国連邦政府関連の事業を持つ防衛企業なら、SAP National Security Services（SAP NS2）を検討するでしょう。2025年に、米国内のみの運用で、S/4HANA Cloud Private EditionとSAP BTPをFedRAMP+ Impact Level 5で稼働させる暫定認可を受けました。

防衛特有の要件（監査証跡、ロールベースのアクセス制御、見積のバージョン管理、データ所在地）は、プラットフォームの世代にかかわらず当てはまります。コンプライアンス全般については、私のガイド公共部門におけるSAPコンプライアンスをご覧ください。

なぜ他のCRMプラットフォームではなくMicrosoft Dynamicsが選ばれたのですか？

リードから商談、販売後のエンゲージメントまで、顧客ライフサイクル全体を管理でき、防衛販売の長く複雑な案件サイクルにも対応できたからです。OutlookやTeamsとの相性が定着を助け、チームがすでに慣れていたことで、導入のハードルがさらに下がりました。

コンプライアンスの負担が重いクライアントにとって、アクセス制御、監査ログ、柔軟性、拡張の余地も決め手でした。

Experlogix CPQはどんな役割を果たし、なぜCPQが必要だったのですか？

防衛製品には複雑な構成ルールがあります。価格表では、製品バリエーション、コンプライアンス要件、顧客固有の条件の相互作用を捉えられません。CPQがなければ、各見積は、作る人がルールを知っているかどうかにかかっていました。

Experlogixは、そのルールを見積ツールに組み込みました。営業担当者は、見積を作っている最中に検証のフィードバックを受け取り、数日後にエンジニアリングから訂正を受けることはなくなりました。誤りが上流に移り、直すコストが安く済む段階で見つかるようになりました。

SAP SDはCRMやCPQとどのように連携されましたか？

SAP CPIがミドルウェアとして機能しました。Experlogixで承認された見積が、適切な明細、価格、顧客データを持つ受注をSAP SDに作成するフローを起動しました。CPIはまた、検証ルールでデータの不一致を防ぎながら、顧客データと受注データをDynamicsとSAPの間で同期させました。

以前は、誰かが承認済みの各見積を手作業でSAPに写していました。これを自動化したことで、再入力の誤りがなくなり、承認から受注までのきれいな監査証跡ができました。

実装中の最大の課題は何でしたか？

まずデータ品質です。顧客データは部門ごとに不統一で、重複や欠けている項目があり、Dynamicsが唯一の正しい情報源になる前に、きれいにする必要がありました。

2番目は連携のマッピングで、特に3つのシステムをまたぐ製品構成と価格でした。3番目は、営業、エンジニアリング、IT、財務の足並みをそろえることで、プロセスの一部の責任の所在が変わるときは特に大変でした。

セキュリティとコンプライアンスはどのように扱われましたか？

初日から組み込まれていました。すべてのコンポーネントが、社内のセキュリティポリシーと国の規制を満たす必要がありました。ロールベースのアクセス制御で、誰がどのレコードを見て、変更できるかを制限しました。見積、承認、データ変更を、完全な監査証跡が網羅しました。防衛分野の規則に沿って、すべてのデータがUAE国内にとどまりました。

設計がそれらの要件から始まったため、コンプライアンスレビューが来たときには、データはすでに適切な形になっていました。

展開にはどのくらいかかりましたか？

おおよそ6〜8か月で、段階的に行いました。CRMとCPQに焦点を当てたパイロットから始め、フィードバックを受けて部門に拡大し、上流のシステムが安定した時点で途中からSAP SDの連携を加えました。研修、サポート、チューニングは、期間を通じて続きました。

このモデルは、他の防衛企業や製造業にも応用できますか？

はい。販売サイクルが長く、製品が構成可能で、コンプライアンス文書が必要な場面なら、どこでも使えます。航空宇宙、産業機器、そして見積を出す前にエンジニアリングの検証が必要なあらゆる事業です。

具体的なツールよりも、連携のロジックが重要です。承認済み見積が再入力なしでERPに流れ、顧客レコードが唯一の正しい情報源になっていなければなりません。