こんにちは、SB テクノロジー (以下、SBT ) セールスコンサルティングチームの築地です。
昨今の情勢から、オンラインを活用した営業改革や DX (デジタルトランスフォーメーション) をテーマに新たな試みに挑戦されるお客様からたくさんのご相談をいただきます。
営業改革の責任者に任命されたお客様から「システム導入経験がないため何から始めればよいかわからない」と相談を受け、お話しを聞いてみると、要件はまとまっていない、ビジョンはあるけど計画はない、更には IT に関する知見が足りないメンバー体制でのプロジェクト推進と、とてもプロジェクトが成功できる状態ではないと驚きを隠せなかったことがあります。しかし、実際にそのような状態でプロジェクトマネージャー
(以下、PM ) 担当に任命される方は珍しくなく、そのような方からのご相談も増えています。
今回は、そんな時のヒントとなる、売上拡大に向けた営業プロセス改革プロジェクトについてのケーススタディです。
これから、もしかしたら今現在、営業改革プロジェクトの進行に頭を抱えている方に、SBT がどのようにプロジェクトの問題を解決し、推進したかをご紹介させていただきます。
今回のケーススタディのお客様(以下、A 社)をご紹介します。
A 社は、部品・器具の製造販売を行う企業です。世界各国に製造・販売拠点を置くグローバル展開で、国内でも高いシェアを誇ります。
そんな A 社はどのような目標を掲げ、何を解決するためにシステム導入プロジェクトを発足させたのでしょうか。
A 社は、「20XX 年に現状の売上を3倍にする」という大きな目標を掲げました。しかし、その目標を達成するためにはいくつかの課題もあり、その中には、現状、導入されているシステムでは解決がむずかしく、けれど、その課題を解決しなければ、目標達成に向かうこともできないという課題がありました。
A 社にはすでに SFA (Sales Force Automation の略称。営業支援システム) が導入されていました。しかし、既存の SFA はただの営業活動情報の登録場所で、情報を可視化する機能も足りないシステムでした。営業活動の情報を登録する側 (この場合は営業を担当される方々)
には時間を割いてまで登録するメリットもない、登録しなくても業務はまわると、既存 SFA を利用する人がほとんどいません。
分散された情報からは、営業担当者がどのような活動をし、何の結果につながっているかの可視化も俯瞰的な判断もできず、評価もできません。
ケーススタディ・プロフィールでご紹介しましたが、A 社は世界各国に製造・販売拠点を有するグローバル企業です。しかし、既存の SFA では、案件進行中はもとより、受注完了後の営業活動がどうなっているのか、正しい情報、ステータスを確認するだけでかなりの手間がかかっている状態でした。
課題1、課題2とも共通するのは、営業活動の正しい可視化、情報共有、それを基にした評価ができないために発生した課題です。
その結果、次のような状況になっていました。
大きな目標で、「20XX 年に現状の売上を3倍にする」を掲げている A 社です。この状況を解決するために「正しく営業活動が可視化され、評価されるプラットフォームの導入」が急務であると、A 社は考えました。
なぜ、営業改革プロジェクトが立ち上がったかは「目指すゴールと課題」を読んでいただければご理解いただけるでしょう。もう少しまとめます。
つまりは、既存 SFA 導入時の「システム導入時の方針検討不足」「運用を見越したシステム機能・ルール検討不足」がもたらした結果でしょう。
現状のままでは目標達成はできない、そのためには業務改善が必須であると、A 社の営業改革プロジェクトが発足しました。それではなぜ、A 社の営業改革プロジェクトに、SBT が参画できたのでしょうか。ポイントは2つあります。
この2つのポイントに評価をいただき、SBT の A 社営業改革プロジェクト参画が決定しました。
さぁ、A 社 新 SFA 「Dynamics 365」導入プロジェクトのスタートです。SBT は、以下のステップで導入を進めるプロジェクト計画を立てました。
大きく3ステップに分けたプロジェクト進行です。まずは、STEP1 の「アセスメント (製品 Fit & Gap) 」からスタートです。
さて、いきなりですが、あなたは、新規システム導入のプロジェクトの PM に任命されました。あなたは、システム導入の経験はなく、導入が決定した製品理解もないのに、PM
という重責を担ってしまいました。想像をしてみます……、胃がキリキリし、すっぱいものがこみあげてきました。
A 社 PM のご担当者はまさにその状況でした。進め方も、何を正とするかの承認基準もわからない、どうすれば A
社の業務改善につながるシステム導入となるかも見えない、不安しかない状況で、アセスメントが開始したのです。いいえ、開始されてしまったのです。
SBT の PM もその状況にいち早く気がつきました。整理されることなく提示されるご要望や現状の課題、A 社から提供される情報も不足している状況が続きました。けれど、A 社 PM
の様子からこれらの改善は難しいことは明白です。A 社から不足なく情報提供がされることが前提でのプロジェクトです。プロジェクト遅延の理由を、A
社の情報提供不足とすることは簡単なことです。しかし、SBT は、ここでプロジェクトの舵を大きく切りました。
鳴かぬなら鳴かせてみせようホトトギス作戦です。
STEP1 のアセスメントの目的は、A 社の要望、課題、現状の情報・データの状況から、新 SFA となる Dynamics 365
がどこまで実現できるか、実現できないならば代替案はあるか。代替案がなければどうするか、などを決めるのが目的です。その A 社から提示される情報が不足をしている、整理できていない、何が正しいかもわからない状態でアセスメントを進めたところで、既存 SFA の二の舞です。
SBT は、予定にはなかったビジネスコンサルタントを STEP1 のアセスメントに投入することを A 社に提案しました。コンサルタントを参画させる目的は次のとおりです。
これらをコンサルタントが実施することで、既存 SFA の二の舞にはせず、A 社の目標達成に貢献できる Dynamics 365 を構築するためのご提案です。
整理されず、次から次、後から後とでてくる要望、課題に対し、SBT はプロジェクトのフェーズをわけることを A 社に提案しました。
A 社からでてくる要望をすべて一度に構築してしまうリスクを、これまでの経験から SBT
は充分に理解していました。ベースとなる本当に必要な部分から構築し、段階的に機能改善・追加要望の構築することで、将来的には A 社の運用に沿った新 SFA 「Dynamics
365」になります。また、ベースとなる本当に必要な部分を先に構築し、実際に A 社で運用してもらうことで、本当に必要な機能改善か、追加要望かが明確になります。
まとめて全部実施することが必ずしも A 社の要望を満たすわけではないことを、SBT の PM は A 社 PM に説明をしました。
「鳴くまで待とうホトトギス」ではプロジェクトが頓挫してしまう。「殺してしまえホトトギス」では本末転倒。ならば、どうするかを考えた SBT の提案は、A 社に受け入れられ、プロジェクトは次のようになりました。
なぜ、このような提案を SBT がしたのか、疑問に思う方もいらっしゃるかもしれません。「プロジェクトが立ち上がるまで」で書いたことを少し思い出してください。既存 SFA がなぜ使われないシステムとなってしまったか。2つポイントを書きました。
SBT はこれが原因で起こる「後悔する、させてしまうシステム導入」を回避したかったのです。
SBT の提案も受け入れられ、その後は、順風満帆にプロジェクトは進み……、とはならないと予測された方がほとんどでしょう。銀の弾丸なんてありませんからね。
「STEP1 アセスメント (製品 Fit & Gap) とコンサルティングの実施」を進める中で、いくつも問題が発生しました。その都度、SBT は A 社の視点に立ち、どうしたら A 社の目標達成に貢献できるシステムを構築できるかを考え、問題を解決しました。では、どのような問題が発生し、どのように SBT が解決していったのでしょう。
A 社 PM、A 社のプロジェクトメンバーはシステム導入に不慣れです。IT リテラシーの差から、どうしても SBT とのコミュニケーションギャップが起きやすい状況になっていました。
アセスメント用の簡易的なプロトタイプを構築し、実際に操作してもらうことで、A 社とのギャップを埋め、SBT と共通認識を作りました。
例えば、家、自動車など、イメージしやすい例えで説明をし、A 社の理解を深めました。
当たり前なこと、と思われるかもしれませんが、実際にやってみると、適切な比喩はとても難しいです。比喩を誤ると間違ったインプットになりかねません。
IT の知見が足りなくても最終的な判断は A 社となります。ところが、やはり、これまで経験したことのないシステム導入、全社に関わる要件の判断など、A 社で判断ができないシーンが多々発生しました。
A 社に判断してもらう、決めてもらいたい時、常に、SBT から、SBT の過去案件、経験、他のお客様の事例を踏まえた案、SBT としてはどちらがよいと考えるかも添えて、A 社に提示しました。A 社の本質、なぜ、迷っているか、どこで悩んでいるかを洞察し続けたからこそできた対応です。
選択肢にはそれぞれメリット・デメリットが必ずあります。どちらを取るかも重要な判断基準となります。両方をきちんと A 社に伝え、A 社の判断の迷いを軽減するようにしました。
この A 社の 営業改革プロジェクトは A 社全体が関わるプロジェクトです。A 社の営業部門は多岐にわたり、それぞれで独自の文化を築き上げていました。それを改善し、A 社の掲げた「20XX 年に現状の売上を3倍にする」を達成するためのプロジェクトです。当然、A 社の部門間調整は必須で、それを調整するのは A 社 PM なのですが全体像が見えていない A 社 PM には難しい調整です。
A 社組織体制を把握し、必要となるステークホルダーを特定、SBT でファシリテーションを取って、A 社内の調整も実施しました。また、A 社部門間で必要となる調整も積極的に SBT 主導で進め、A 社 PM の負担を減らし、プロジェクトを進行しました。
「STEP1 アセスメント (製品 Fit & Gap) とコンサルティングの実施」を完了し、STEP2 へ進みました。
プロジェクト進行で発生する様々な課題・問題を、A 社視点に立ち、解決しながら上流工程である STEP1 を実施・完了したため、STEP2 ではシステムに対する大きな認識相違も発生することなく、順調に構築が進んでいきました。
実際に導入した結果、A 社の課題がどう改善され、どのような効果が生まれたかは、また別の機会にお伝えできれば、と思っています。
当初、このプロジェクトは、A 社からの提供される情報ありきで計画され、「STEP1 アセスメント (製品Fit & Gap)
」は2か月で完了するスケジュールでした。しかし、実際にプロジェクトが開始されると、整理されることなく提示されるご要望や現状の課題に情報の不足と、問題が山積みでした。
それを、ビジネスコンサルタントの参画、A 社……お客様側に入り込むプロジェクト進行により、プラス1か月をした、合計3か月で STEP1 を終わらせることができました。
システム導入に正解はありません。あえて言うのであれば、お客様に「このシステムを導入してよかった」と思っていただけたらそれが正解です。
SBT では、ひとりでも多くのお客様に「このシステムを導入してよかった」と思っていただけるよう、お客様の目標達成に向けて、お客様と共創する Dynamics 365 の導入を目指しています。お気軽にご相談ください。
関連ページ |