ALPHA BRANDING Corp.

CaseScenario

Column

業務課題と経営課題の違い|DX提案が承認されない「翻訳ミス」3つの構造

光点と線が波のように広がる抽象的なデータネットワーク(情報の流れのイメージ)。
宮崎祥一の顔写真

執筆者:宮崎 祥一

Honeywell、Experian、Teradata、Avanade、SAS Instituteなどで、アナリティクス領域の事業開発に従事。製造業を中心に、医薬や金融など多様な業界において、導入事例が乏しい新領域の提案も含め、案件創出から受注までを主導してきました。2023年にHoneywellのAccount Management Directorを退任。現在は株式会社アルファブランディングを通じて、DXや新領域のソリューションにおける初期提案の設計支援を行っています。

はじめに|業務課題が正確なほど、静かに案件が止まる


「現場の課題はたしかに正しい。なのに、なぜか承認されない」。DX提案を担当していると、こういう詰まり方に出くわすことがあります。

止まっている原因を探しているとき、多くの場合、最初に疑うのはライバルの存在です。IT部門との関係は悪くない、稟議も通過している、でも役員会やステコミで半年動かない。そうなると「別のソリューションを推している役員がいるのではないか」と考えて、比較資料を作ったり、役員同士の面談を設定したりするものです。

ただ、実際に止まっている原因は、競合ではないことがほとんどです。IT投資とはまったく関係のない「欧州販売の強化」や「工場ラインの組み替え」といった経営アジェンダと、優先順位で負けているのです。IRやアニュアルレポートを読めばそれは書かれているのに、そこに目が向かないまま別の対策を打ち続けてしまいます。

このコラムでは、DX提案が止まる原因を「業務課題と経営課題の断絶」として整理し、その断絶が実務でどういう形で現れるか、どう変換すれば前に進みやすくなるかを見ていきます。

1. 課題と背景|経営が判断したいのは「改善案」ではない


1-1. 現場の課題が正確でも、承認の場では機能しない

DX提案の業務課題は、多くの場合かなり正確です。「入力が遅い」「二重登録がある」「PoCは回っているのに本番化できない」。これらは業務の不全をよく表しており、問題意識としても妥当です。

ただし、承認の場では、課題が正確であることと、投資すべき理由になることは別です。現場の症状は「困っていること」を示しますが、経営が判断したいのは「その問題に資源を配分する理由があるか」です。業務課題は提案の入口にはなっても、そのままでは承認理由になりません。

このズレを放置すると、提案は「良いことを言っているが、なぜ今それに投資するのかが分からない」という状態になります。現場の痛みが強いほど、そのまま説明してしまいやすく、経営側の判断形式に乗らないまま止まります。

1-2. 経営が見ているのは「資源配分」という別の問い

経営課題とは、改善すべきことの一覧ではありません。予算・人・時間という限られた資源を、どこに配分するかという判断です。何かを選ぶと同時に、何かを見送ることを含んでいます。

そのため、経営が見ているのは「業務が楽になるか」だけではありません。どの損失を止めるのか。どの成長に資源を振るのか。なぜ今なのか。他の案件より優先する理由はあるのか。こうした問いに接続できてはじめて、その提案は経営課題として扱われます。

承認の場で本当に競合しているのは、ライバル企業のソリューションではなく、「欧州販売強化」や「工場ライン組み替え」のような、まったく別の経営アジェンダであることも少なくありません。ITの話として提案したままでは、その競合に気づけません。

1-3. 翻訳できないと、判断の土俵ごと変わる

業務課題を経営課題へ変換できないと、提案は別の土俵に落ちます。「どの損失を止めるか」「どの成長に効くか」という価値判断で議論されるべき提案が、スペック比較や価格比較の場に移ります。

この状態になると、顧客担当者も既存の稟議フォーマットに沿って業務課題中心で資料を組み立てていくため、あとから経営課題に接続し直すことが難しくなります。翻訳の問題は、言葉が少しずれることではありません。提案が乗る判断の土俵そのものが変わることです。

では、この断絶は実務でどういう形で現れるのか。次章で3つの類型に整理します。

2. 課題の構造|翻訳ミスが起きる3つの場所


翻訳ミスは、説明が足りないことから起きるわけではありません。業務課題を経営課題へ変換する途中で、問いの形式がずれることで起きます。代表的な類型は3つです。

2-1. 症状が「放置損失」に変換されていない

現場では「作業が大変」「待ち時間が長い」「入力が煩雑」といった不満が出発点になります。業務課題としては正確ですが、そのままでは経営判断に使えません。経営が知りたいのは不満の大きさではなく、それを放置したときにどの損失が発生し続けるのか、だからです。

たとえば、待ち時間が長いという症状は、そのままでは単なる不便です。しかしそれが失注や機会損失につながるのか、品質事故や顧客離反のリスクを高めているのかが見えれば、はじめて経営課題になります。症状を症状のまま置いてしまうことが、最初の翻訳ミスです。放置した場合のコストとして組み替えられていないと、提案は承認の土俵に乗りません。

2-2. KPIが現場止まりで、経営の指標に接続していない

処理時間・工数・作業時間短縮率など、改善効果を示す現場KPIは提案に欠かせません。ただし、それだけでは経営にとっての意味が見えません。

経営が見ているのは、その改善が売上・粗利・営業利益率・在庫回転・回収期間など、全社の指標にどうつながるかです。現場KPIだけで止まると、「改善は分かるが、それで何がどれだけ動くのか」が分からないため、判断材料として弱くなります。すべてを財務指標に置き換える必要はありませんが、少なくとも1つは経営が日常的に見ている指標につながっていないと、提案は現場改善の話から抜け出せません。

2-3. 現場の合意を、経営の承認と混同している

勉強会や関係部門との事前調整が上手くいくと、「あとは時間の問題だ」という感覚になることがあります。ただし、現場の合意と経営の承認は別物です。

以前、大手金融機関のグローバル業務部門への提案で、関連部門を集めた勉強会を何度も開き、現場の疑問や懸念を丁寧に潰していきました。担当者たちの理解は深まり、勉強会はうまくいっていると感じていました。しかし、承認は得られませんでした。後から分かったのは、担当者たちが各部門に戻った後に提出したレポートが、相当なボリュームになっていたことです。新しいビジネスモデルだということもあり、丁寧に書き上げたレポートを幹部は読んでいませんでした。丁寧な仕事が逆効果になった形です。

現場の合意は、幹部が判断できる材料の設計とは別の作業です。勉強会が終わった段階で、幹部向けのサマリー設計を提案できていなかったことが、この案件での敗因でした。現場の合意が揃っていても、経営が判断する形式に変換されていなければ、承認には至りません。これが3つ目の翻訳ミスです。

3. 解決策|業務課題を経営の問いへ変換する手順


翻訳ミスを防ぐために必要なのは複雑な理論ではなく、症状をどう置くか、何を損失として見るか、どんな問いに変えるかの順番を固定することです。

3-1. 症状を1行で固定し、「放置損失」に置き換える

最初にやるべきことは、顧客企業で起きている症状を1行で固定することです。ここで置くべきなのは単なる現場の不満ではなく、その企業で放置されている損失は何かです。

提案が前に進むようになったのは、課題の類似性を事例で説明することをやめ、その企業のIR情報をもとに「この会社にとって止めるべき損失は何か」を起点に、業務課題を経営の問いへ組み替えてからでした。機会損失・品質事故・顧客離反・監査リスク・手戻りコスト。何が積み上がっているのかを短く置くことで、提案の入口が変わります。経営が動くのは「改善できるか」よりも「放置すると何を失い続けるか」が見えたときです。

3-2. 損失を「経営の問い(Yes/No)」に変える

損失が見えても、それだけでは提案は通りません。次に必要なのは、その損失を止めるために何を判断すべきかを、Yes/Noの問いに変えることです。

「当社は◯◯の損失を止めるために、◯◯領域へ段階投資し、一定条件を満たした場合のみ継続すべきか」という形まで落とせると、提案は「良い話」から「決めるべき案件」に変わります。問いがない提案は、どれだけ丁寧に説明しても判断に入りません。症状を損失に変え、その損失を経営の問いへ変えることが、翻訳の骨格です。

3-3. 指標を3つに絞り、分岐条件を先に置く

問いが置けたら、次は「何を見て前進と判断するか」を指標で固定します。指標を増やしすぎると議論が散るため、3つまでに絞ることが妥当です。

そのうち1つは、売上・粗利・在庫回転・回収期間など、財務に接続する指標にします。残り2つは現場KPIで構いません。ただし、指標を置くだけでは足りません。その指標をどう読めば前に進めるのかという分岐条件も必要です。どの状態なら継続するのか、どこまで届かなければ見直すのか。この条件がないと、指標は並んでいても判断には使えません。

3-4. 翻訳の観点を、顧客が書き始める前に渡す

ここまでの手順で翻訳の中身はかなり整います。ただし、顧客担当者が既存の稟議フォーマットで書き始めたあとでは、観点を変えることが難しくなります。一見すると前に進んでいるように見えても、そのフォーマット自体に経営の問いが入っていなければ、丁寧に作っても承認で止まります。

だからこそ「資料作成を手伝う」前に、「どの観点で整理するか」を先に渡す必要があります。具体的には、症状・放置損失・経営の問い・指標と分岐条件・初期対象範囲の5つをBefore/Afterで整理した観点表を、担当者が社内資料を書き始める前に共有しておくことです。翻訳ミスは内容の問題であると同時に、着手順の問題でもあります。

まとめ|まず3つだけ書き出してみてください


業務課題が正確なのに提案が止まるとき、説明の量を増やす方向に動きがちです。比較資料を作ったり、役員同士の面談を設定したりと、止まっている原因とは別の方向に手を打ち続けることになります。

止まっている原因の多くは、業務課題が経営の判断形式に変換されていないことにあります。競合との比較で負けているのではなく、まったく別の経営アジェンダと優先順位で競合していることに、気づけていないだけのことが少なくありません。

いま進めている提案があれば、「症状」「放置損失」「経営の問い」の3つだけでも書き出してみてください。3つが揃っているかどうかで、承認の土俵に乗っているかどうかがほぼ分かります。翻訳が先に設計されていると、顧客担当者が社内で説明を進める形も変わってきます。まずそこから確認してみてください。

【次に読むべきコラム】
👉️ 導入事例の制作を依頼する前に知っておくべきこと|営業が使わない事例になる理由

【参考】CaseScenario™なら


「症状を放置損失に変え、経営の問いへ接続する」という翻訳の方向は、本記事の手順である程度整理できます。ただし実務では、「どの損失を置くべきか」「どの指標なら経営が判断しやすいか」「どのタイミングで顧客へ渡すべきか」で迷うことが少なくありません。

CaseScenario™では、IR情報や中期経営計画をもとに業務課題を経営課題へ接続する初期提案の設計図を整えます。顧客担当者が社内説明に使いやすい観点と構成を初期段階で設計することで、案件化・検討開始・承認前進に必要な判断材料を先に揃えます。提案が業務改善の話で終わらず、役員会や稟議で判断が始まる形に近づけます。

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

ライブラリ

BtoB提案シリーズ

導入事例の制作を依頼する前に知っておくべきことを解説するコラムのバナー。営業が使わない事例になる理由と、担当者止まりを防ぐ設計の考え方を紹介。導入事例の制作を依頼する前に知っておくべきことを解説するコラムのバナー。営業が使わない事例になる理由と、担当者止まりを防ぐ設計の考え方を紹介。
「提案停滞」の文字と、足跡のシルエット図「承認停滞」の文字と、ビジネスパーソン3人のシルエット図「伝達不全」の文字と、4人の人物がネットワークで繋がっているシルエット図「PoC停滞」の文字と、進入禁止のテープのシルエット図「事例依存」の文字と、3つのバインダーのシルエット図「営業実務」の文字と、ジグソーパズルの3つのピースのシルエット図