みなさん、こんにちは

前回、今までのＣＲＭ／ＳＦＡは、どうやらお客様とのリレーションシップを企業や組織単位でしか捉えてこなかったのではないか、という見解を述べさせていただきました。

ＣＲＭ／ＳＦＡは、まず企業データ（顧客／見込み客）が存在し、そのデータに対して名刺情報データが紐づく構造になっているのが大半だと思います。

その中でもお得意様企業データに対して、アカウント営業の責任者がメンテナンスするというルールを決めて、お得意先それぞれに予算枠を設定し、予算達成に向けたアカウントプラン（どの部署に対して、どのような案件/商材をいつまでに受注する等）を立てていきます。

昔は、これだけやっておけば良かったのかもしれません。

なぜならパレートの法則の通り、2割の重要顧客に対して営業活動をやっていれば8割の売り上げ予算を達成できていたからです。

誤解を恐れずに申し上げるとＣＲＭ／ＳＦＡは2割のお得意様のデータメンテナンスを行っていれば良かったのかもしれません（2割をメンテナンスするだけで、予実管理の8割はメンテナンスされる訳ですから）。

しかし、今やそのような収益構造になっている企業は、取引先企業の業績に大きく左右されるため新規顧客の開拓に力を割かねばなりません。

私は、ＣＲＭ／ＳＦＡが成功する条件は、データメンテナンスの質の高さや頻度の多さに左右すると思っています。

例えば、次のようなケースはご経験無いでしょうか。

・新しい顧客属性情報をメンテナンスしようとして検索したら、同名の顧客が複数件抽出されてどれをメンテナンスすればよいか分からない

・商談報告を登録しようとしたところ、客先担当者に同名のデータが複数件あって、どちらに商談を紐づけてよいかが分からない

・同じデータが複数件あるので、嫌気がさしてシステム自体を利用しない。

そうなるとデータの精度も落ちてきますし、最悪全く利用されないシステムになり、無駄な投資の代表格になってしまいます。

以上のような状況が、あまりにも酷くなってくるとデータクレンジングを行い、重複データをマージするという収益を生まない作業が新たに発生してしまいます。

このような負のスパイラルに入ってしまうのが、ＣＲＭ／ＳＦＡを導入された企業において大変多いように思われます。

どうすれば、このような問題を未然に防ぐことができるのでしょうか。

逆転の発想をすれば良いことになるのですが、これは次回とさせていただきます。

みなさん、こんにちは

今回は「ＣＲＭ/ＳＦＡ利用において、見落とされている労力の無駄」と題して見解を述べたいと思います。

みなさんの会社では、何かＣＲＭ／ＳＦＡをご利用されていますか？

ご利用されているならば、初めてお会いしたお客様の情報をＣＲＭ／ＳＦＡにデータ登録される時に、まず第一に何をされていますか？

そのお客様の情報をデータ登録する前に検索している？

以前の私ならその行為に対して、全く疑問を呈することはありませんでした。

なぜならば、既に存在しているデータであるにも関わらずデータ登録されてしまうと重複データが発生してしまうからです。これは、ＣＲＭ／ＳＦＡが利用されなくなる大きな理由の一つです。
だから重複データを発生させないことは、入力ルールを徹底して同一データが泣き分かれないようにするのを利用者に徹底してもらわねばなりません。

でも良く考えてみると不思議な行為ですね。データ登録するのに検索しなければならない、という行為。

このように当たり前と思っていることに生産性向上につながらない行為があるのではないでしょうか。

データ登録するのが目的なのにデータ検索しなければならないという無駄な行為は、ＣＲＭ／ＳＦＡを利用する人が多くなればなるほど、登録されるお客様情報が増えれば増えるほど益々無駄な行為が増大していきます。また、大手の会社になればなるほど登録されている営業先の会社や部署が多く、調べるのに結構時間がかかるのです。

その他、次のようなケースはいかがでしょうか。

人材の流動化が激しくなってきている現在、お客様も転職されるケースがあるかと思います。
ＣＲＭ／ＳＦＡではそのようなケースの場合、そのお客様の職歴や商談履歴が寸断されるケースが多いと思います。
本当にそれで問題ないのでしょうか。

今までのＣＲＭ／ＳＦＡは、どうもお客様とのリレーションシップを企業や組織単位でしか捉えてこなかったのではないでしょうか。

このような課題感満載のＣＲＭ／ＳＦＡではあるがゆえ、ＳＦＡの賢者、グレン・ピーターセンでさえ失敗率は60%以上と言っているのかもしれませんし、新たなデータモデルアプローチを必要としているのかもしれませんね。

みなさん、こんにちは

今回は「営業におけるオペレーティングシステム（以下、ＯＳ）とは」と題して見解を述べたいと思います。
まずはＯＳとは何ぞや、というと様々なアプリケーションソフトから共通して利用される入出力機能やリソース管理などをするためのソフトウェアです。

ＯＳの主な目的は、大きく３つあると述べられています。（引用：wikipedia）
・ハードウェアの抽象化
・リソースの管理
・コンピュータの利用効率の向上

営業におけるＯＳというのが仮にあるとすれば、どのようになるかを「ハードウェアの抽象化」を今回は例にあげてみましょう。

まず、抽象化とは何でしょうか。

例えばプロパティは抽象化されたものの一種です。極端な話ですがハードウェアをプロパティ扱いすることにより、メーカーの違いをいちいち気にする必要はない、ということになると思います。
面倒くさいことや細かく煩わしいことから解放されるということになりますよね。

では、営業ＯＳでは何を抽象化するのでしょうか。

一般的に営業は属人的である、と言われています。
（よく俗人的という誤記をみかけますが、庶民的な営業という意味になってしまうので、意味分からなくなりますからご注意ください。）

属人的というのは、抽象化と相反するイメージです。

属人的の反対語は何でしょうか。「組織的」と私は解釈しています。

「組織的」というのは、抽象化という言葉にしっくりきます。ですので数々の組織論がこの世に存在しているのだと思います。
誤解を恐れずに述べると変数の型のようなものでしょう。

ということで、営業ＯＳの抽象化とは、「組織」を抽象化したもの、ということになるのではと思います。
では、「組織」にはどのようなものがあるのか？
機能別組織、事業部制組織、マトリクス組織、などなど。機能別組織やマトリクス組織の考え方はＰＭのあり方にも関係してきそうですね。

もう一方で、よく「仕組み」にしたい、ということを営業組織論の中で口にされるケースがあると思います。

「仕組み」というのが、メソッドなんでしょうね。
では「仕組み」にはどのようのものがあるか？
リードナーチャリングの仕組み、顕在案件化〜クロージングまでの仕組み、などなど。

なるほど、営業にもＯＳが必要になってきそうですね。

今回の見解も怖いぐらい「ぴったり」きましたね！？

では、次回は私が考えるＣＲＭ/ＳＦＡ利用において、見落とされている労力の無駄に対する見解を述べていきたいと思います。

みなさん、こんにちは

前回は営業も開発も「漏れなくダブりなく要求を洗い出せる」かどうかが、見積の精度を左右すること。
それによりストーリーポイント（実装する：受注する）に要する時間の相対的な評価基準が明確になるという概念がありそうだ、という見解を述べました。

以上の流れより、今回は営業におけるストーリーポイントが明確になり、時間軸を意識したパイプライン分析が可能かどうか、という視点で考察を述べていきたいと思います。

アジャイル開発では、プロジェクトでこなすべきToDoリストを「マスターストーリーリスト」と呼び、リストの項目には、ソフトウェアで実現したいフィーチャーが上がっています。

これを営業で例えると、お客様の実現したい目的を達成するために越えねばならない目標を要求仕様という自然言語で簡潔に記述することになります。

開発チームがユーザーストーリーを動くソフトウェアに変換する速度を「ベロシティ」と呼び、ベロシティにより開発チームの生産性の計測とプロジェクトの完了日の見通しを立てることができます。

これを営業で例えると、いくつもあるお客様の要求仕様を「緊急性（時間の流れ）」と「優先度」の４象限にマッピングして、緊急性が高く、優先度も高い要望/要求に対して、目標達成する手段を提供できるまでの速度であり、お客様の目標達成見通しを立てることができることになります。

最後にイテレーションという概念です。
開発では、ユーザーストーリーをリリース可能な動くソフトウェアにする「分析・設計・開発・テスト」といった一連の工程のサイクルがあります。この反復のサイクルを継続して行い、1つずつ機能を追加開発していくことによりリスクを最小化しようとします。

これを営業で例えると、お客様の目的達成には、いくつかの目標達成の組み合わせが必要であり、その目標達成のためには時間軸を設けて仮説に対する振返りが必要となるため、ステップを踏んだ提案が必要になります。１つずつ提案、受注、納品、検証をしていくことによりリスクを最小化しようとします。
これを仮に営業イテレーションと呼ぶことにしましょう。

アジャイル開発における計画づくりにおいては

イテレーション数＝作業量の合計／チームの予想ベロシティ

で時間を割り出しますが

アジャイル営業における計画づくりにおいても

営業イテレーション数＝お客様の実現したい目的達成のための総目標数（要求仕様）／目標達成手段を提供できるまでの速度

営業イテレーションとは、変化が激しい今の時代に必要なメジャメントではないかと思います。

パイプライン分析は、メジャメントが無いとできません。
このようにすれば、手持ち案件（営業イテレーション数）がどれぐらいあるのか、ということを理論的に導き出すことも可能になるのではと思うのです。

次回以降は、営業におけるオペレーティングシステムとは何か？という視点で見解を述べていきたいと思います。

みなさん、こんにちは

前回は、営業にもアジャイル開発手法を用いることができるのではないかという視点でフィーチャーの説明に、磯野家に対する三河屋のサブちゃんの例を出して大変分かりやすく説明させていただきました。。。

今回は、営業におけるストーリーポイントについて考えてみることにしましょう。

営業マネージャー職の方は、「おい！！　この案件、いつ受注できるんだ！？」と一度は口に出されたことがおありになるでしょうし、担当の方は耳にタコができる位？に聞かされているセリフかもしれません。

開発でも同じようなことがあります。「これっていつリリースできるの！？」という感じで。

「不確実性コーン：初期段階の見積には大きな誤差がある」ということが開発においても営業においてもあると思うわけです。
では、不確実性はどれぐらい一般にあると言われているのでしょうか。

びっくりされる方もおられるかもしれませんが、開発プロジェクト当初においては、プロダクトを定義した初期の段階で、60%から160%の誤差が生じると言われています。

例えば見積では2か月でリリースできるとしたものは、ふたを開けてみれば1か月から4か月まで跳ね上がることになります。（見積よりも前倒しになる例は、あまり経験がありませんが。。。）

では、営業においてはどうでしょうか。。。

開発で捉えると某雑誌ではありませんが、「動かないコンピュータ」っていう最悪のケース「失注」もあるわけです。営業も見込当初においては、見込案件登録をCRM/SFAに登録した初期の段階で、開発にも負けないぐらいの誤差が生じるケースも多いのではないでしょうか。

ここで一旦、話を元に戻します。「ストーリー」とは「要求」の単位です。
ストーリーポイントとは、1つのストーリーを実装するのに要する時間の相対的な評価基準を指しています。

さて、営業ではどうでしょうか。要求そのものが潜在化しているケースが大半ではないでしょうか。

ということは、要求を顕在化させることができれば、その要求に対して営業する立場において、どのように提案していけばよいのか分かることになります。

ここで申し上げたいのは、営業も開発も「漏れなくダブりなく要求を洗い出す」かどうかが、見積を左右するということです。

それによりストーリーポイント：実装する：受注するのに要する時間の相対的な評価基準が明確になるということになろうかと思います。

では、次回は営業におけるストーリーポイントが明確になり、時間軸を意識したパイプライン分析が可能かどうか、という視点で考察を述べていきたいと思います。