SFAコラム
案件管理の「案件」、定義できますか？
SFA導入の“盲点”を徹底解説
質問です。
貴社の「案件」の定義を教えてください。
SFAとは、「Sales Force Automation」の頭文字をとった略語です。
大抵は「営業支援システム」と訳されますが、その中心機能は「案件管理」にあります。
「案件管理」とは端的にいうと、ある「案件」についてお客様に引合いをいただいてから、その「案件」が受注/失注するまでの販売プロセスを管理することをいいます。
そのため、管理すべき「案件」とは何か？何をもって「案件」とするのか？という定義をしっかりと決めておく必要があります。
しかし、現実の導入プロジェクトの中では、この点が十分に議論されないまま進んでしまうことも少なくありません。
実は案件の定義が考慮されていないと、プロセス管理やデータ集計、データ活用がうまく行えない事態に陥る可能性もあるのです。
今回は、「案件」とは？という、きわめてシンプルかつ本質的な問いについて考えていきたいと思います。
受注/失注まで、案件管理の基本パターン
まずは簡単な例から考えていきます。
あるベンチャー企業が自社製品を開発し、その拡販のために営業をかけることとします。
このようなケースでは、売るものが1つしかないので、単純に「案件＝単一製品」となります。
弊社のアルテマブルーを具体例に取り上げてみましょう。
例えばWebサイトから「アルテマブルー」の引合いがくると、図1赤背景のように「1案件」として登録されます。今後は、案件ごとに受注/失注までのプロセスを管理することになります。
これが最も基本的なケースで、入力、プロセス管理、データ集計、データ活用と、何をとっても問題なく行えます。
SFAを利用する上での基本パターンといえます。
【図1】
集計結果にみる「案件」定義の難しさ
それでは、1件の引合いに対し、複数製品を提案しているケースではどうでしょうか。
図2の赤背景を例にとると、大枠としての案件名は「営業支援システム導入提案」となります。
しかし、提案している製品の内容をみると「kintone」と「名刺管理サービス」がセットになっています。
両製品ともに、受注か失注するのであれば問題はありません。しかし「いずれか一方だけ受注したケースではどうするのか」、そこを考える必要があります。
プロセス管理の面では、引合いごとの分類で影響がなくとも、集計がネックになってくるからです。
【図2】
例えば、案件管理の基本的な集計である「受注率」で考えてみます。
大枠の案件単位でみてみると図3のようになります
【図3】
同じデータを製品ごとに分けて、もう少し細かくみると図4のようになります。
【図4】
顧客ごとの引合い件数に応じたケースでは、「案件数」は図3の単位でいいでしょう。
しかし、最終的に集計をとる際は、製品単位で受注率や受注/失注要因、競合情報を分析できる状態にすることが求められることもあります。
その場合、例えば図4のような形でデータ集計ができると便利です。
このような集計は一見簡単にできそうな気がしますが、実はそうではありません。
ある程度の高度なシステムならば、基本機能だけで実現可能なことでも、安価なシステムでは、情報を振り分けられないことも多くあるのです。
そのため、安価なシステムを利用している場合は、図5のようにあらかじめ製品ごとに案件を分け、受注/失注を管理しておかなければなりません。
そうすることで、名刺管理サービスとkintone、それぞれの案件数と受注数が簡単に集計できるようになります。
ただし、この方法でも問題があります。
製品ごとの受注/失注情報はみえやすくなりますが、今度は案件発生件数の把握が困難になるためです。
図5の赤背景事例でみると、本来の案件発生件数は1件にも関わらず2件の案件レコードを作ることになるため、案件発生数をカウントしようとした場合、実態と集計結果が異なります。
これが「案件」定義の難しさの一つです。
【図5】
「案件」定義はSFAで決まる！？
別の事例もみてみましょう。
いわゆる「SIer」といわれるシステムを構築している企業の場合、システムの初期構築をした後に、追加開発案件というものが発生してきます。
その場合、図6にあるような形で、初期構築案件と追加開発案件を分けて管理をしていくことが一般的です。
【図6】
追加開発案件を分けて管理すること自体は問題ありません。
しかし、このまま集計をすると、図7のように、初期案件に紐づけされた追加案件も、別の「1案件」として集計されてしまいがちです。
【図7】
案件数「9」に対し、受注率が「55.6％」となるので、結果からすると「受注率がよく営業が強い！」という判断となります。それでは、初期構築案件のみに限って計算をしてみるとどうでしょうか。
図8のようになります。
【図8】
案件数「6」に対し、受注数は「2」となりました。
このように、先ほどの結果とは大きく異なる結果となるのです。
数値指標として、どちらの数字をベースに評価/検証していくのでしょうか。
新規開拓の強化を目的としている場合は、間違いなく後者となります。
また、図6の赤背景の3つの案件は、プロジェクトとしては1件です。
このプロジェクト単位で集計した合計売上や合計粗利をみることも、必要になるかもしれません。
「案件管理」は、プロセス管理だけをするのであれば難しいことではありません。
しかし、最終的な集計を考えると「案件」をどのように定義し、どのようにデータ管理をするのかもしっかりと検討する必要があります。
実は同じSFAという製品でも、どこまでの集計が可能か、また、集計できるようなデータ管理/蓄積ができるかはSFAごとに大きく異なります。
そのため、SFAによって「案件」の定義が異なることも起こりうるのです。
案件管理が難しいケースとは？
中には「案件」という括りが難しいケースもあります。
新規開拓であれば、多くの場合「案件」括りが可能ですが、ルートセールスの場合は注意が必要です。
例えば、消耗品販売や部品卸会社などのように、商品点数がものすごく多かったり、製品が低価格だったりするゆえに、注文が発生しても営業マンを介さないケースがこれに該当します。
訪問時にカタログや価格表を渡し、あとはメールやFAX、最近ではwebで注文をいただく場合、「案件」で括るのは難しくなります。
このように、「案件管理」とするのが困難なケースでは「案件管理」ではなく「活動管理」「顧客管理」を中心に行うことになるでしょう。
SFA導入を成功させる「定義」のポイント
これまでみてきたように、「案件」という言葉は非常に難しく、決して簡単に考えることのできない問題です。
SFAを導入する際には、以下の5つの点について、しっかりと社内で検討しておくことを強くお勧めします。
- ・「案件管理」の目的とはどのようなことなのか？
- ・「案件」の何を管理すべきなのか？
- ・どのような数値で評価/検証していくのか？
- ・自社にとっての「案件」とはどのような定義なのか？
- ・そもそも、自社のビジネスモデルを考えた場合に必要なのは「案件管理」なのか？
とはいえ、SFAを活用した経験のない企業が、このような検討を独自で行うことは簡単ではありません。
そこで、キヤノンエスキースシステムではご契約前に「無料デモ画面作成」というメニューを用意しております。
簡単な要件定義を行い、お客様専用のデモ画面を作成し、トライアルで検証していただくまでを行います。
その中で、本コラムにあるような点についてもディスカッションを行っていきます。
ぜひお気軽にお問い合わせください！