スキップしてメイン コンテンツに移動

営業マネジメントを整える③


(以前、noteに書いた記事をこちらに転載します)

営業マネジメントを掘り下げながら、それぞれのマネジメントレベルで営業支援アプリに必要な機能が何かを示していくことで、いろいろ考えるヒントにしたい、というシリーズ記事の第3回です。

前回は、営業マネジメントの基本の「き」というべき、「目標と実績の管理」について確認しました。


いつもの難しい図

今回は、そこからひとつ下に進んで、ちょっと専門用語っぽい「パイプライン管理」について、考えていきたいと思います。

パイプライン管理

受注目標を細分化して、実際に取れた受注実績とのギャップを定期的に確認していきましょう。というのが、「目標と実績の管理」でした。すごく大雑把な例で言えば、居酒屋やバー、レストランに、ワインを卸している事業者がいたときに、居酒屋とバーは受注目標に達しなかったけれど、レストランからの受注は目標を大幅に超えた。どうして、そうなった!?みたいなことを確認するのが「目標と実績の管理」です。
ただこれは、受注できた!とか、失注した!とか、結果が積み上がってきて初めて、見えてくるものです。居酒屋向けの受注が目標に達しない、ということを、もっと早くに知りたかった…早期に何か対策を取りたかった…みたいな問題も起こり得ます。
受注できるかできないか、という結果が出る前に、チェックポイントとかないの?
営業中の案件が、どれだけ受注に近づいてきているのか、前もって分からないの?
そういった疑問に答えるために登場するのが、今回のパイプライン管理です。

受注に至るまでのプロセスを定義する

営業案件がいくつかあるときに、それぞれの案件がどれくらい受注できそうか、ということを受注の確度で表すことがあります。「もう絶対取れる!」「何か一手打てば取れそうな気がする」「少し待てばワンチャンスありそう」みたいな感覚を、A、B、C、Dなどでランク分けをします。

また、いつごろ受注できそうか、みたいな見通しを立てることもあるでしょう。今月中に取れそうな案件と、来月には取れそうな案件、半年以内、今年度中、来年度以降、というように。

こうした営業担当者の勘みたいなものは、大事にした方がよいのですが、一方で、担当者の能力に依存するところも多くなります。ですから、感覚による分類に頼ると、人によって見通しが不正確になってしまうという問題が発生します。

そこで、次の図のように、受注に至るまでの段階を、客観的に判断できるように定義します。そして、その案件が、いまどの段階にいるのか、ということで、案件がどれだけ受注に近づいているかを表せるようにします。これなら営業担当者の勘に依存しません。

界隈では頻出のファネル(漏斗)というモデル

この段階(営業プロセス)ごとに、営業案件を管理する手法が、パイプライン管理というものです。

案件ごとの営業活動は、図の上から始まって下の方に進んでいきますが、それぞれの段階から次の段階へは、必ず通過できるわけではなくて、ある程度の確率で失注していきます。なので、ここでは逆ピラミッド型で表していて、下の方に行くほどに、図は小さく、案件数は少なくなっていきます。

それぞれの案件はどこで詰まっているか

管理するうえでは、逆ピラミッド型ではなくて、横にパイプが連なっているような感じで、表現することが多いです。まさにパイプライン。それぞれの段階に、何件の案件があって、想定される受注金額はどれくらいか、といったことをパッと見られるようにします。

パイプラインを流れていく案件たちの様子

こうして段階ごとに分けて案件を集計していくと、今年度中に目標の受注額を得るためには、今どれだけの案件がどの段階に積まれていないといけないのか、ということが見通しやすくなります。そして、案件がどこで詰まりやすいのか、ということも考えやすくなります。

マネージャーが常に確認していく

こうした情報は、営業担当者が自ら確認することも大切ですが、どちらかというと営業マネージャーが常に確認するものです。以下のようなことを考えながらパイプラインの様子を見ていきます。
  • 目標受注額や目標時期と照らし合わせて、各段階にある案件の数は適正かどうか
  • 次の段階に進行していく確率が著しく低い段階がないかどうか
  • 重要な案件が今どの段階で滞留しているか
そして、どうやらここには問題がありそうだぞ、ということに気づいたら、該当する案件の詳細を調べていって、具体的に何が置きているのか確認し、対策を検討していく必要があります。

ここで必要になる営業支援アプリの機能

  • 目標管理の切り口に従って
  • 定義した段階ごとに案件を集計できて
  • そこから個別案件の詳細情報にアクセスできる
  • 各段階に案件が留まっている時間を集計できる
  • 可能ならば…
    • 段階ごとに必ずすべきことを定義して
    • 案件ごとに実施の有無を確認できる
最後に「可能ならば…」として書き加えたのは、どういうことかというと、パイプライン管理と合わせて、営業担当者の行動管理までやれると良いということです。例えば、営業担当者Aさんは、提案段階で見積書を出しているけれど、Bさんは顧客社内で決裁を取るときに見積書を出しているとします。そうすると、見積金額の合意が正式に取れているタイミングが、担当者によって違ってきて、受注の確度も違ってくるかもしれません。

なので、当社では提案時に必ず見積書をお客様に提示すること、というようなルールを設定して、営業支援アプリ上でもチェックできるようになっていると、営業プロセスを統一しやすくなります。

ここまで、目標に対して現状がどのようになっているか、ということを、どちらかというとマクロな視点で見える化していく方法を確認してきました。次からは、少しミクロな視点。つまり、個別の案件や、一人ひとりの営業担当者にフォーカスした営業マネジメントのための機能を考えてみたいと思います。

このブログの人気の投稿

簡単にできるIoT~振動の計測②

  前回 は、何を作るかを考えて、設計メモにまとめました。 簡単にできるIoT~振動の測定① 先日(といっても随分経ってしまっていますが…)とある方から、M5StickCというデバイスをいただきました。それで、どんなことができるのかと試してみたことを紹介します。 M5StickC このデバイスは親指(より少し小さい?)くらいのサイズですが、中にESP32-... まだプログラミング自体には触れていませんでしたし、大まかな設計をしただけですが、ここまで意外と考えることが多かったと思われるかもしれません。ですが、どう作るかよりも、何を実現するかの方が重要です。本来はもっと何を実現するかを模索するのに時間をかけるべきだと思います(そのためにシステムを試作することも含めて)。 さて、今回はさっそくこれを作ってみます。作る方法はネットでいろいろな人が教えてくれるので、それらを参考にすれば、すぐに作れます。 データを受け取って蓄積する側を作る まずは、Googleスプレッドシートに以下の図のような表を作り、M5StickCから受け取ったデータを書き込めるようにします(図では既にデータが蓄積されています)。 A列「gasCodeVer」:一応、動かしているスクリプトのバージョンを記録 B列「receiveTime」:データを受け取った時刻(receivedでないのはご愛嬌) C列「dataNum」:いくつデータが取れているかを記録 D列「data1」以降:加速度データ そのために、以下のことをします。 Googleドライブでスプレッドシートを作る 「ツール」→「スクリプトエディタ」からスクリプトエディタを開く Apps Scriptでスクリプト(コード)を書く 「デプロイ」→「新しいデプロイ」→「種類の選択」→「ウェブアプリ」からデプロイ 基本的なやり方は下の参考ページ(前半部分)を見れば、すぐに分かります。実際に手元で出る画面と少し違うところがあるかもしれませんが、だいたい一緒かな、という緩さをもって見ていくと良いと思います。 [M5Stack] M5Stackで取得したデータを、Google スプレットシートへ書き込む M5StackはWi-Fi機能との連携が特徴の一つとなりますが、やってみたくなるのがクラウド連携だと思います。そこで、今回は、Go...

システム内製化のトレンド

  これまで多くの企業にとって、ICTと言えば外から買ってくるものでした。もしくは、業者に発注して作ってもらうものでした。それがクラウドサービスになって、借りてくるもの、みんなでシェアしながら使うもの、になりましたが、今は社内で作るものになり始めています。いわゆる「内製化」です。 かつてソフトウェアを開発する企業に所属していた身としては、市場の大きな変化につながる話なので、とても気になっているのですが、多くの企業の方にとっては、まだまだ関心の薄い話題かもしれません。なので、なぜシステム内製化というトレンドが起こりつつあるかについて、僕の認識していることを少し書いておこうと思います。 とはいえ「なぜ」というのは非常に簡単な話です。経営、ビジネスモデル、事業の強み、といったものがICTと密接に関係するようになったからです。 アウトソーシングしていい業務と、してはいけない業務は何か、という議論をするとき、ひとつ大きな論点として、強みに直結するものかどうか、ということが挙げられます。その企業独自の強みを他社に依存すると、強みを持続させることも発展させることも危うくなるというのは分かりやすいと思います。システム内製化も同じ論点から出てくる話です。自社の強みの源泉となっている業務フローを支えるシステムだったら、自分たちの手の内に入れておくべきです。 また、今の時代が、不確実性が高く、かつ、変化の激しい時代である(と言われている)ことも、内製化の追い風になっています。不確実で変化の激しい市場に対応するビジネスは、その運用を柔軟に変化させ続けなければいけません。それも高速に。そのためには、システムもビジネスに追従して高速に変化させ続ける必要があります。システム開発を外注していたら、事業変化のスピードにはどうしたって追いつけません。システムが足を引っ張るようになります。必要なスピードを出すためには、社内で、ビジネスを回している従業員のすぐそばで、一体となって、開発をしていかなければならないのです。 そんなわけで、これまで「IT企業」とは言われていなかった企業が、続々とエンジニアの中途採用を始めて、自分たちでシステム開発をやれるようになってきています。そしてすべての企業が「IT企業」になる(逆に言えば「IT企業」という枠組みが消える)時代が来ようとしています。 もちろん、全ての...

簡単にできるIoT~振動の測定①

先日(といっても随分経ってしまっていますが…)とある方から、M5StickCというデバイスをいただきました。それで、どんなことができるのかと試してみたことを紹介します。 M5StickC M5StickC(本体のみ) このデバイスは親指(より少し小さい?)くらいのサイズですが、中にESP32-PICOというモジュールが搭載されていて、WiFiやBluetoothの通信ができます。また、MPU6886というモジュールも載っていて、加速度、ジャイロ、(デバイス内部の)温度センサーが使えます。液晶画面やボタンもついています。要するに、いくつかのセンサーと、操作や通信をする機能がコンパクトにまとまっているデバイスです。 そして、このデバイスのいいところは、デバイスを制御するためのソフトウェアを作るのも非常に簡単ということです。ネットワークにつながる部分が既に作り込まれていて、少し追加で設定するだけで、すぐにWiFi(そしてWiFiを経由してインターネット)との接続も可能です。 この手の電子工作モジュールがよく売られている SWITCH SCIENCE でも扱っています。 何を作るか 機械などに取り付けたセンサーから得られるデータを、クラウドに収集して分析して、人の行動の参考にしたり、他のシステムを動かしたり、機械のコントローラーにフィードバックして自動制御したり、というのがよくあるIoTの全体像です。M5StickCを使えば、このようなIoT的なシステムが簡単に構築できることが期待できます。 とはいえ、このデバイスでどんなデータを取得したら役に立つのか、というのは意外と難しい話です。昨今、ノーコード/ローコードで、プログラマでなくてもプログラミングができる!ということがよく言われます。しかし、システムを作る上で難しいのは、コードを書くところよりも、何を作るかを決めるところです。これはプログラマやエンジニアでも上手くできる人が少ないですし、ユーザー企業で現場の業務をよく知っている人ならできるというわけでもないです。課題をよく吟味して、業務やビジネスがどう変化すると良いのかを全体最適の視点から捉えないと、間違ったものを作ってしまいます。 本来は、課題があって、それから手段が検討されるわけですが、今回は手段が手元にあって、そこから何ができるか考えています。完全に間違いパターンで...