お問い合わせ

新価値創造マネジメントの新潮流

第5回 ソリューション提供のジレンマを解消するポイント

高橋 儀光

 前回は、お客様の困りごとありきでソリューション提案をする際に、提案内容に自社の強みが介在しないジレンマが生じるケースに言及しました。今回は、このジレンマを解消するためのポイントを解説します。

ソリューション提案はお客様の半歩先から

 前回コラムで解説しましたが、従来の「何をつくるのか」をあらかじめお客様と合意してからの開発と、ソリューション志向の開発とのもっとも大きな違いは、ソリューション提案は、お客様自身がそもそも「何をしたいのか」が明確になっていない状態からスタートする点です。この状態を逆手に取り、あえて最初から理想的なソリューションは提案しないというのがポイントになります。

 お客様の「これはこういうものだ」という諦め状態から、お客様の何歩も先を行く理想的な状態に持っていく解を持っていたとしても、まずはお客様の目先の状態が明らかに改善される、半歩先くらいのちょっとしたメリットを実感できる提案から始めるのです(下図)。

col_takahashi_05_01.png

 お客様のトレンド・価値観の変化を洞察・共有することで、せっかくお客様の困りごとに気づき、理想的な提案を持っているにも関らずそれを提案しないというのは、従来の開発の発想からすると意外に思われるかもしれません。一気に理想的な提案をすれば、競合他社に対しダントツの差別化提案で引き離せる可能性があるにも関らず、あえてお客様の半歩先くらいの提案で始めるのは2つの理由があります。

時間的猶予を設ける

 1つは、提案内容に自社の強みが介在しない場合、自社の強みを構築するための時間的猶予を設けるためです。第2回のコラムで解説しましたが、ソリューション提案は、「モノ」と「サービス」との組み合わせになることが多くなります。早急に理想的な提案を実現するためには、自社の現有リソースにないものは外部からの調達が必要になります。たとえば、コアデバイスは自社開発・製造で提供できても、システム全体のソリューション提供のためには、ソフトウェアの調整・カスタム提供が必要となり、ここは自社の現有リソースにはないとします。初期の普及段階はいいですが、「モノ」がある程度行き渡ると、付加価値の源泉は「モノ」よりも、むしろ「サービス」にその比重が移ります(下図)。

col_takahashi_05_02.png

 ソリューションの付加価値、すなわち自社が儲けるための原資が「サービス」に移ってしまったときに、それが外部調達で左から右に流れていくだけだとしたらどうでしょう。これでは継続的な事業開発にはなりません。よって、理想的なソリューションに段階的に持っていくことで、その間に最終的なソリューションで付加価値の源泉となるものを、自社内に構築するのです。

事業リスクを極小化する

 2つ目の理由は、事業化リスクを極小化するためです。あまりにも先進的な提案は、お客様自身も経験がないため、ソリューション導入にあたっての社内承認稟議も慎重になります。

 かつてApple社は1993年にNewtonという画期的な携帯情報端末を発売しました。Windows95もまだ発売されていなかった当時としては、IT業界にとってまさにプロダクトイノベーションの宝庫で、タッチパネルによる手書き文字認識や無線通信、パソコンとの同期機能などの世界初の機能を満載した理想的なものでした。ですが、製品開発は成功したにも関らず結果としてはまったく売れず、Apple社と当時Newton用のプロセッサを受託製造していたARM社までも経営難に追い詰められ、事業的には大失敗となりました。これは極端な事例ですが、あまりにも先進的な提案は、お客様側でそれを受け入れる準備がまだできていないリスクが存在します。

 そこで、まずは半歩先くらいのお役立ちで、お客様の投資規模も抑えてわかりやすいメリットが出るところから始めて、お客様の懐に入り込んでいくことが重要です。部分的な提供だけでは自社の先行開発投資が回収できないこともありますが、ソリューション提供は「損して得を取る」発想へと、ものづくりの価値観を根本的に変えていく必要があるのです。

ソリューション開発では、開発日程・製品仕様は日々大きく変動する

 このようにお客様の半歩先をいく提案を繰り返しながら、段階的に最終的に目指す理想形へとお客様と二人三脚で進んでいくのがソリューション開発の基本プロセスとなります。このプロセスがお客様との信頼関係を構築するうえで重要となり、本コラムの最初で解説した、単純なサプライヤーの一社ではなく、お客様のビジネスパートナーとなりえる理由でもあります。

 とはいえ、これは従来の「何をつくるか」が確定してからの開発とは大きく異なり、最終的な開発日程・製品仕様が不確定なままでスタートするため、自社の設計・開発部門や生産計画・製造部門にとっては先の計画が立てにくく、非常にやりにくい開発となります。

 次回以降では、ソリューション提案が実現できた後の、ソリューション開発を実行していくうえでの開発プロジェクトマネジメント上のポイントについて解説します。

オピニオンから探す

研究開発現場マネジメントの羅針盤 〜忘れがちな正論を語ってみる〜

  • 第30回 心理的安全性は待つものではなく、自ら獲得するもの
  • 「自分自身を技術を通して表現する」という技術者の生き方とは?
  • TCFDに基づく情報開示推進のポイント
  • オンラインサービスは新たなCXをもたらしたのか? オンラインサービス体験から見えた、メリットデメリット
  • 一人一人の「能率」を最大化させる、振り返りのマネジメント「YWT」のすすめ
  • 第5回(最終回) 全社員をデジタル人材に!
  • 第5回(最終回) 全社員をデジタル人材に!

業務改革を同時実現する『基幹システム再構築』推進

  • 第1回 基幹システム再構築を行う背景
  • 品質保証の「本質」を考える ~顧客がもつ、企業に対しての「当たり前」~

オピニオン一覧

コラムトップ