DX提案が機能比較に陥る理由｜SI営業が「経営課題起点」の初期提案に切り替える方法

はじめに｜DX提案が似通って見えるのはなぜか

提案書を開いてみると、どれも似たように見えてしまう——そんな経験は、SI営業の方ならかなり身に覚えがあるのではないでしょうか。

「AI活用」「クラウド移行」「RPA導入」。言葉は違っても、最終的には機能の比較か価格の話になり、顧客からは「他社とどう違うのか」と聞かれる。そのたびに差別化ポイントを探すのですが、どこかすれ違いが続く。

この状況は、提案の工夫が足りないというより、提案の主語が最初から技術になっていることで起きやすくなっています。本コラムでは、DX提案が機能比較に陥る構造を整理したうえで、SI営業が初期提案を経営課題起点に組み直すための視点と型をお伝えします。

1. 課題と背景｜DX提案が形骸化する理由

1-1. プロダクトセリングからソリューションセリングへ

かつてのIT営業では、製品の機能・性能・価格を訴求する「プロダクトセリング」が主流でした。製品差が明確で、顧客側も導入対象を比較しやすかった時代には、この進め方でも一定の競争力を持てました。

しかし、顧客課題が複雑化するにつれて、製品説明だけでは商談が成立しにくくなります。業務プロセス、組織、データ、既存システム、意思決定の流れまで含めて考えなければ前に進まない案件が増え、そこで重視されるようになったのが「ソリューションセリング」です。顧客の業務課題・事業課題を起点にして、複数の施策を組み合わせて解決策を設計する考え方です。

この転換は、単に売り方が変わったという話ではありません。提案の主語を「製品」から「課題」へ移したということでした。

1-2. DX提案の正体｜「技術導入」という名のプロダクトセリング回帰

ところが近年のDX提案では、表面上は課題解決型を掲げながら、実際には再びプロダクトセリングに戻っている場面が少なくありません。「クラウド移行」「生成AI」「RPA」といった技術キーワードが前面に出て、「何を変えるのか」より先に「何を入れるのか」が提案の中心になっているからです。

この流れは、提案側だけの問題ではありません。顧客自身が「AI活用を提案してほしい」「RPAの事例を紹介してほしい」と、手段を主語に相談してくることも多くあります。そうなると提案側も、その要望に沿って技術起点で返したほうが速く、既存資料も流用しやすい。営業現場としては短期的に合理的です。

しかし、その瞬間に提案の土台は決まってしまいます。技術を主語にした提案は、「この技術で何ができるか」「どの機能があるか」「他社と何が違うか」という比較に入りやすくなります。経営課題との接続が後回しになれば、提案はソリューションのように見えても、実態は「技術導入の売り比べ」に戻っています。

1-3. 経営情報は持っていても、提案には使えていない

SI営業の多くは、アカウントプランニングの場で中期経営計画や決算情報を確認します。表面的には経営視点を持っているように見えます。しかし実際には、それが提案の起点にならず、「企業理解をした」で終わるケースが少なくありません。

ある外資系アナリティクスベンダーに在籍していたころ、アカウントプランのフォーマットを渡されると、前半に経営情報を貼り付け、後半に営業戦略を書く形が当たり前になっていました。ところが前半と後半はまったく接続されておらず、経営情報は「埋めるための素材」でしかありませんでした。転職先でアカウントプランニングに取り組む機会があり、業務課題を経営課題に接続する構造でプランを書いたところ、「生まれて初めて見るほど分かりやすい」と言われ、社内トレーニングの教材になりました。その経験で初めて、前半と後半が「別の資料」になっていたことの意味が腑に落ちました。

経営情報を読むことと、それを提案の主語として使うことは別物です。中期経営計画に書かれている重点テーマを、どの事業課題に落とし込み、どの業務ボトルネックと結びつけ、そこにどの技術施策を位置づけるのか。この変換作業がなければ、経営情報は提案の飾りにしかなりません。

2. 課題の構造｜DX提案が機能比較に陥る構造

2-1. 経営課題ではなく技術を起点にすると、提案は横並びになる

DX提案が機能比較に陥る出発点は、提案の起点が経営課題ではなく技術になっていることです。「AI」「RPA」「クラウド」「データ基盤」を主語にして提案を組み立てると、顧客から見えるのは「何を導入するか」になり、「何を変えるか」ではなくなります。

このとき提案は、自然と機能・価格・導入しやすさの比較に入ります。技術を起点にした提案では、各社の違いが「道具の違い」としてしか見えにくいからです。同じAI提案でも、経営アジェンダとの接続がなければ、顧客にとっては「どのAIが優れているか」「どこが安いか」という比較になります。

本来、企業ごとに異なるのは製品ではなく、経営課題です。目指す成長の形も、変革の制約条件も、優先順位も企業固有です。にもかかわらず、提案の起点を技術に置いた瞬間、その企業固有の文脈は後ろへ退き、提案は横並びになります。DX提案が似てしまうのは、提案者の工夫が足りないからというより、最初の主語を取り違えているからです。

2-2. 顧客の依頼と営業現場の省力化が、技術起点の提案を固定化する

この問題は、提案側の発想だけで起きているわけではありません。顧客の依頼のされ方と、営業現場の動き方が組み合わさることで、技術起点の提案が固定化されやすくなります。

顧客から「AI活用を提案してほしい」「RPAの事例を紹介してほしい」といった依頼が来ると、営業側はその依頼に沿って既存の資料や事例を出す方が速く、顧客の期待にも応えやすく見えます。技術テーマごとの資料は社内に用意されていることが多く、短期的には合理的だからです。

しかし、この合理性がそのまま提案の限界になります。顧客の言葉をそのまま主語にして既存資料で返すだけでは、提案は技術説明の域を出ません。そこに経営アジェンダへの接続や業務課題の構造化が入らない限り、どの提案も似た形になります。つまり、DX提案が機能比較に陥るのは、提案力不足というより、顧客の要望を技術名のまま受け取り、そのまま返してしまう構造があるからです。

2-3. 承認が止まる原因を、競合との比較だと思い込んでいた

SI営業の提案が機能比較に入り込みやすいもう一つの理由は、「承認が止まっている原因」の診断を誤りやすいことです。

外資系ITベンダーに在籍していたころ、あるSI案件でIT部門との関係は良好で、稟議も部門を通過していました。ところが役員会・ステアリングコミティで半年以上止まり、毎回「次年度課題」になる。最初は競合製品に押されているのだと思い、比較資料を作ったり役員同士の面談を設定したりしました。しかし実際の原因は、競合製品との競争ではなく、「欧州販売強化」「工場ライン組み替え」といった、IT投資と直接関係のない経営アジェンダとの競合でした。IRやアニュアルレポートを読む習慣がなく、その経営アジェンダに気づけていなかったのです。

この種の誤診は、技術起点の提案をしている限り起きやすくなります。提案の主語が技術であれば、「承認が止まる＝競合に負けている」という解釈に引っ張られます。しかし実際には、顧客の役員が比較しているのは「競合製品」ではなく、「自社の経営優先順位」です。提案が経営課題と接続されていなければ、技術は常に「比較対象の一つ」としてしか扱われません。

3. 解決策｜経営課題に接続した初期提案の設計

3-1. 技術を語る前に、「経営戦略 → 症状 → 技術施策」の順に並べる

DX提案を機能比較から抜け出させるには、提案の順番そのものを変えることが出発点になります。多くの提案は、AI・RPA・クラウド・データ基盤といった技術の説明から始まります。しかしこの順番では、顧客の頭の中でも「どの技術が優れているか」という比較が先に始まってしまいます。

提案はまず「経営戦略」から始めます。中期経営計画やIR情報の中で、顧客が今どの変革テーマを進めようとしているのかを確認する。そのうえで、その実行を妨げている現場の「症状」を置きます。「PoCが本番化しない」「提案が属人化している」「意思決定が遅い」といった状態です。そこまで整理して初めて、技術施策を「その症状を前進させるための手段」として位置づけます。

提案の型は「経営戦略 → 現場の症状 → 技術施策」の順です。技術を消すのではなく、技術の役割を後ろへ下げる。この順番を守るだけで、提案は機能説明から経営課題の前進へと変わります。

外資系アナリティクスベンダーに在籍していたころ、米国本社のトップ営業の提案書を初めて見たとき、PowerPointではなくWord文書で書かれていました。顧客の経営課題から始まり、解決策、導入後の展望まで文章で書かれていて、その起点にはIR情報をもとに特定した経営課題がありました。機能説明から始まる自分の提案との違いはその一点だったと、いまも思っています。

3-2. 提案のゴールを「導入」ではなく「経営ゴールから逆算した変革テーマ」に置く

提案が似てしまうのは、ゴールが近すぎることも一因です。「AIを導入する」「クラウドへ移行する」「RPAを入れる」という近いゴールを置けば、提案はどうしても技術比較になります。導入しやすさ、機能差、費用対効果の短期比較が中心になり、他社との差別化は難しくなります。

一方、提案のゴールを「経営ゴール」から逆算すると、提案の意味は変わります。同じクラウド移行でも、「インフラコスト削減」がゴールなのか、「M&A後の統合スピードを上げて事業再編を加速する」のかでは、提案の価値も設計もまったく異なります。同じAI提案でも、「問い合わせ対応を自動化する」のか、「営業活動の再現性を高めて重点顧客攻略の精度を上げる」のかで、経営への接続の仕方は変わります。

目先のゴールが近いほど、提案のルートは固定されます。経営ゴールのように遠い到達点を置くほど、そこへ向かう道筋には複数の選択肢が生まれます。自社が得意な進め方や設計思想が提案の差になるのは、ここです。

3-3. 最小フレーム｜機能比較に入らない提案冒頭の型

ここまでの考え方は、提案の冒頭1ページに落とせなければ実務では機能しません。「この提案はどの経営テーマを扱い、何の症状を前に進め、何を判断してもらうものなのか」が一目で分かることが、機能比較を避けるための最小条件です。

以下のフレームで提案冒頭を組むと、顧客の会話は「どの機能が優れているか」ではなく、「このテーマをどう前に進めるか」に変わります。

【最小フレーム｜機能比較に入らない提案冒頭の型】

この順番で提案の冒頭を組むと、技術は比較対象の中心ではなく、経営課題を前に進めるための手段として位置づきます。提案の主語を変えるだけで、顧客の見え方も比較の軸も変わります。

まとめ

DX提案が機能比較に流れるのは、提案する側の力量の問題ではなく、提案の主語が最初から技術になっていることで起きやすい構造的な話です。顧客から技術名で相談され、既存資料で返す。それ自体は現場の自然な動きですが、その延長線上では提案は横並びになり、最終的には機能比較か価格比較に吸い込まれていきます。

まず試してみるとすれば、自社の直近の提案書を一つ開いて、冒頭に何が書かれているかを確認することです。技術の説明から始まっていれば、「どの経営テーマを扱うのか」「どの症状が止まっているのか」を先に置き直してみてください。提案書の骨格を変えなくても、冒頭の主語を変えるだけで、顧客との会話の入り方は変わってきます。

【次に読むべきコラム】
👉️ 業務課題と経営課題の違い｜DX提案が承認されない「翻訳ミス」3つの構造

【参考】CaseScenario™なら

DX提案が機能比較に戻りやすいのは、中期経営計画やIR情報を確認していても、それを提案の主語に変換する設計が現場に整っていないからです。

CaseScenario™は、この変換を支援する初期提案の設計図です。企業のIR情報や中期経営計画をもとに経営課題を体系化し、現場の業務課題や停滞症状を整理したうえで、「誰に、何を、どの順番で、どの論点で伝えるか」を設計します。業務課題を経営課題に翻訳し、案件化・検討開始・承認前進に必要な判断材料を初期段階で整えることが、CaseScenario™の役割です。

提案資料の見せ方を整えるためのサービスではありません。技術起点で流れやすいDX提案を、経営アジェンダに接続したソリューション提案へ組み替えるための設計図です。

👉 CaseScenario™の紹介ページはこちら