JP2021039636A - 営業支援装置および営業支援方法 - Google Patents

Abstract

【課題】商材の提案活動と商談の継続可否判断を効率的に行う。【解決手段】演算部と、記憶部と、を有する営業支援装置であって、記憶部は、商談の対象である商材と、商談において行われるべき複数の営業活動の内容と、それぞれの営業活動において想定される結果ごとの商材と顧客との適合度への影響量と、を対応付ける営業活動情報を保持し、適合度に基づいて商談の継続の可否を判断するための基準を含む判断基準情報を保持し、顧客との商談において行った営業活動の結果を示す商談進捗情報を保持し、演算部は、営業活動情報及び商談進捗情報に基づいて、顧客との商談において行った１以上の営業活動の結果に対応する適合度への影響量を集計し、集計された影響量に基づいて計算された適合度と、判断基準情報と、に基づいて、前記顧客との商談の継続の可否を判定し、判定の結果を出力する。【選択図】図１

Description

本発明は、商材の提案活動（商談）を支援する技術に関する。

背景技術として、特開２０１８−５５２６８号公報（特許文献１）がある。この公報は、営業プロセスの各段階において営業がやるべきことを予め整理し、営業にその都度指示し、そのやるべきことの達成状況から受注確度を定量的に試算し、確度情報をもとに商談の進捗を管理するためのシステム、手法を開示している。

特開２０１８−５５２６８号公報

一般に商談活動において営業員は、商談の進捗状況を踏まえて、次にとるべきアクションを決定する。進捗状況は例えば、顧客の課題やニーズを確認できている、顧客の予算や希望納期が確認できている、提案しようとしている商材の仕様や機能が顧客の課題やニーズとマッチしているか確認できている、商材にどのようなカスタマイズが必要か確認できている、などである。アクションは例えば、顧客に業務とその課題を確認する、予算や希望納期を確認する、投資判断を行う人物や部署を確認する、などである。アクションの選定及び進捗度の見極めを適切に行うことで、顧客に対して最適な商材を効率的に提案することが可能となり、また顧客にとっても必要な商材を素早く導入できるというメリットがある。

しかしながら、営業員について営業活動そのものの経験が少なかったり、これまで取り扱った経験が少なく仕様や機能が十分に把握できていない商材を提案したりしようとする場合は、とるべきアクションの選定及び進捗度の適切な判断が難しい。これに対して特許文献１の技術では営業員が商談においてやるべきことを営業員にその都度提示し、その達成状況から受注確度を試算することによって、営業員の適切なアクション実施と進捗度判断を実現している。

一方近年では、デジタルデータの収集・統合・分析を中心的機能とする、デジタルソリューションのビジネスが成長している。一般にデジタルソリューションは顧客の特定の業務課題をピンポイントで解決するものであり、顧客の業務全体を改善するような（受注生産的な）大規模なシステム、プロダクトと比べて小規模なものである。また顧客もデジタルソリューションをスモールスタート的に導入し、自身の課題を素早く解決することを求めている場合も多い。よってデジタルソリューションを提供する際には、顧客の個別要件に基づき時間をかけてソリューションを開発するのではなく、顧客の課題にあわせて提供可能なソリューションを素早く選定、提案することがより重要となる。

また、顧客の課題にふさわしいデジタルソリューションが無い場合は、商談を途中で打ち切ることも必要となる。早い段階での商談の打ち切りは、課題を素早く解決したい顧客にとっても不要な商談対応が無くなるためメリットも大きいが、一般に営業員は受注額や受注件数で評価されるため、受注可能性を無くす商談の打ち切り判断は困難である。さらに、デジタルソリューションは小規模なため、ソリューションの構築・デリバリにエンジニアリングリソースをあまりかけられない。よってデジタルソリューションを提案する際には、受注規模を踏まえて必要なリソースを確保できるかどうか、といった判断も必要となる。

このようにデジタルソリューションの商談においては、（１）顧客の課題やニーズと自身の商材がマッチしているかというマッチ度の判断、（２）商談の進捗やマッチ度に基づく商談の素早い打ち切り判断、（３）ソリューションの構築・デリバリに必要なエンジニアリングリソースが確保できるかの判断、が必要となる。特許文献１の技術では、営業が必要な営業アクションをどれくらいこなせているか、という指標に基づく商談の受注確度は試算可能であるが、営業員がすべき上記の三つの判断を支援はできない。

本発明は以上の状況を鑑み、商材、特にデジタルソリューションの提案活動（商談）において、顧客の課題とソリューションのマッチ度やエンジニアリングリソースの確保可否に基づき、営業員に商談を進捗、あるいはマッチ度を明らかにするためにとるべきアクションの提示と、商談の継続・打ち切り判断を促すことを目的とする。

上記の課題の少なくとも一つを解決するため、本発明は、演算部と、記憶部と、を有する営業支援装置であって、前記記憶部は、商談の対象である商材と、前記商談において行われるべき複数の営業活動の内容と、それぞれの前記営業活動において想定される結果ごとの前記商材と顧客との適合度への影響量と、を対応付ける営業活動情報を保持し、前記適合度に基づいて前記商談の継続の可否を判断するための基準を含む判断基準情報を保持し、顧客との商談において行った前記営業活動の結果を示す商談進捗情報を保持し、前記演算部は、前記営業活動情報及び前記商談進捗情報に基づいて、前記顧客との商談において行った１以上の営業活動の結果に対応する前記適合度への影響量を集計し、集計された前記影響量に基づいて計算された前記適合度と、前記判断基準情報と、に基づいて、前記顧客との商談の継続の可否を判定し、前記判定の結果を出力することを特徴とする。

本発明によれば、商材（例えばデジタルソリューション）を提案しようとする営業員が、商材の提案活動と商談の継続可否判断を効率的に行えるようになる。また商談が効率化されると顧客にとっても、必要な商材を素早く導入することが可能となる。上記した以外の課題、構成及び効果は、以下の実施形態の説明によって明らかにされる。

本発明の実施例におけるデジタルソリューション営業支援装置およびそれに附属するハードウェアのシステム構成を示す図である。 本発明の実施例におけるデジタルソリューション営業支援装置の機能構成例を示す図である。 本発明の実施例における、デジタルソリューション営業支援装置とその付随装置との間のデータのやり取りを表すデータフロー図である。 本発明の実施例における、デジタルソリューション営業支援方法のメインの処理フロー例を示す図である。 本発明の実施例における商談情報テーブルの一例を示す図である。 本発明の実施例におけるソリューション情報テーブルの一例を示す図である。 本発明の実施例における営業アクション情報テーブルの一例を示す図である。 本発明の実施例における商談進捗情報テーブルの一例を示す図である。 本発明の実施例における進捗度とマッチ度との関係性の一例を示す図である。 本発明の実施例における商談開始からの期間又は工数と進捗度との関係性に基づく商談の継続可否判断を示す模式図である。 本発明の実施例における判断基準情報テーブルの一例を示す図である。 本発明の実施例におけるマッチ度の観点での商談継続可否の判断を示す模式図である。 本発明の実施例における進捗度及びマッチ度に基づく総合判断の一例を示す図である。 本発明の実施例におけるエンジニアリングリソース情報テーブルの一例を示す図である。 本発明の実施例におけるエンジニアリングリソース確保可否判断の方法を示す模式図である。 本発明の実施例における営業アクション提示画面の例を示す図である。 本発明の実施例における営業アクションの結果を入力する画面の例を示す図である。 本発明の実施例における進捗度及びマッチ度の観点での商談継続可否判断を提示する画面の例を示す図である。 本発明の実施例におけるエンジニアリングリソース確保可否の観点での商談継続可否判断を提示する画面の例を示す図である。

以下に本発明の実施例について図面を用いて詳細に説明する。

＜発明の前提＞
ここでは本実施例のデジタルソリューション営業支援装置および営業支援手法に関し想定する前提について概説する。本実施例におけるデジタルソリューション営業業務は、商談の中で顧客から様々な情報を入手しながら、拡販対象であるデジタルソリューションが顧客の課題やニーズとマッチしているか、あるいは商談の規模などの観点でソリューションの構築・デリバリに必要なエンジニアリングリソースを確保できるか検討する活動とする。

本実施例の想定利用者は、デジタルソリューションの営業及び拡販を担う営業員を想定する。この営業員の役割は、複数業界の顧客に対して、自社が保有する複数のデジタルソリューションを拡販するものとする。営業員のスキルセットとしては、過去に特定業種の顧客に対して特定のデジタルソリューションを拡販した経験はあるが、複数の商材を複数業種の顧客に拡販した経験が少ないとする。よってこの営業員に対しては、商談の経験が少ない業種の顧客に拡販経験が少ないデジタルソリューションを提案する場合には、とるべき営業のアクションを提示するなど、何らかの支援が必要であると想定する。

本実施例ではデジタルソリューションの提案の相手は各種業務を行う企業体、団体を想定するが、個人に対する提案活動であっても良い。

また、本実施例で扱うデジタルソリューションは過去に他の顧客へ提供し、顧客価値があることを実証されたものであるとする。デジタルソリューションの過去導入実績も整理・蓄積されているものとする。顧客から聞き出した課題から全く新しいデジタルソリューションを開発、提供することは本実施例のスコープ外とする。

本実施例におけるデジタルソリューションの定義を述べる。本実施例では、デジタルデータの収集・統合・分析、分析結果に基づく情報システム、並びに、装置の制御を行う装置、ソフトウェアおよび情報システムを総称してデジタルソリューションと呼ぶ。

一般にデジタルソリューションは、顧客のある業務の特定の課題を解決するものが多い。また、社会やビジネス環境の急速なデジタル化にともない、デジタルソリューションを素早く導入し自身のデジタル化を進めようとする顧客が多いと考えられる。一方、デジタルソリューションはピンポイントの業務課題を解決するものであるため、課題の規模にもよるが、顧客からの大規模な投資が期待できない場合も多い。よって、顧客の個別用件を細かくヒアリングしそれに基づき新たなデジタルソリューションを設計、開発、デリバリしてしまうと、時間的にも費用的にも規模が大きくなるため、少ない投資で素早くデジタル化したいという顧客のニーズに反することになってしまう。よって、デジタルソリューションの提案活動においては、既に実績がある複数のデジタルソリューションの中から、予算及び納期の制約の下、顧客の課題やニーズに最適なものを選定、提案することが重要となる。自身のソリューションが顧客とマッチしない場合は、商談を打ち切ることも重要となる。このようにデジタルソリューション営業の主要な活動内容は顧客の課題やニーズと提案したいデジタルソリューションのマッチングを確かめる活動であると言える。

以下、こうした前提を踏まえて、本実施例におけるデジタルソリューション営業支援装置および営業支援手法の具体的な構成について述べる。なお、本実施例においては、組み立て系製造業の顧客向けにデジタルソリューションを提案する状況を題材とするが、対象とする顧客業種に制約はない。また、特に断りの無い場合、デジタルソリューションのことを単にソリューションと表記する。

＜システム構成例＞
図１は、本発明の実施例におけるデジタルソリューション営業支援装置１０１およびそれに附属するハードウェアのシステム構成を示す図である。

図１に示すデジタルソリューション営業支援装置１０１は、ソリューションの営業担当者（以下、営業員）１００が営業活動を遂行する上で、顧客とソリューションのマッチングを確かめるために必要な営業アクション、商談の進捗度及び顧客とソリューションとのマッチング度合い（マッチ度）、並びに、進捗度及びマッチ度とソリューションの構築・デリバリに必要なエンジニアリングリソースの確保可否とに基づく商談の継続可否判断等を計算及び出力するための装置であり、一般にネットワークに接続されたサーバを用いることができる。

このデジタルソリューション営業支援装置１０１から出力される営業アクション、進捗度、マッチ度、及び商談の継続可否判断などは、営業支援装置１０１にネットワークを介して接続された操作・表示端末１０２を通じて営業員１００に提示される。また、営業員１００が入力する商談情報及び営業アクションの実施結果は、営業員１００が操作・表示端末１０２上で入力操作をすることで営業支援装置１０１に入力される。操作・表示端末１０２は、パーソナルコンピュータ、又はスマートフォン・タブレットなどの携帯情報端末を用いることができる。また、営業支援装置１０１には複数の操作・表示端末１０２が接続できるものとする（すなわち、複数の営業員が営業支援装置１０１を利用できる）。

ソリューションの構築・デリバリに必要なエンジニアリングリソースの空き状況を保持しているリソースＤＢ１０３は、ネットワークを介して、営業支援装置１０１と接続されている。営業支援装置１０１はリソースＤＢ１０３からリソースの空き状況を取得する。なお、営業支援装置１０１は、複数の組織又は部署が自身のリソース管理用に保有しているリソースＤＢ１０３それぞれと接続できるものとする。

＜機能構成＞
続いて、本実施例のデジタルソリューション営業支援装置１０１が備える機能について説明する。

図２は、本発明の実施例におけるデジタルソリューション営業支援装置１０１の機能構成例を示す図である。

本実施例におけるデジタルソリューション営業支援装置１０１が備える機能は、演算部１１０と、デジタルソリューション営業支援装置１０１の動作に必要な各種情報が記録されている記憶部１２０と、操作・表示端末１０２からの入力操作を受け付ける入力操作部１３０と、操作・表示端末１０２に表示する情報を生成及び送信する情報表示部１４０と、操作・表示端末１０２及びリソースＤＢ１０３とデータのやり取りをする通信部１５０と、デジタルソリューション営業支援装置１０１に登録されている文書、画像、音声又は動画などの各種電子ファイルが保存されるファイル保存領域１６０と、から構成される。

演算部１１０は、入力操作部１３０が受け付けた操作内容、入力情報に応じて、記憶部１２０内のテーブル及びファイル保存領域１６０内の電子データを検索する情報検索部１１１と、商談の情報を生成及び更新する商談情報生成・更新部１１２と、営業員１００がとるべき営業アクションを選定する営業アクション選定部１１３と、営業アクションの結果に応じて商談の進捗度を試算する進捗度試算部１１４と、営業アクションの結果に応じて顧客とソリューションのマッチ度を試算するマッチ度試算部１１５と、試算した進捗度に基づいて商談の継続可否判断をする進捗度判断部１１６と、試算したマッチ度に基づいて商談継続可否判断をするマッチ度判断部１１７と、ソリューションの構築・デリバリに必要なエンジニアリングリソースが確保できるか判断するリソース確保可否判断部１１８と、商談の最終的な結果から、商談継続可否判断に関する各種判断基準を更新する判断基準更新部１１９と、から構成される。商談及びソリューションに関する情報は記憶部１２０に蓄積されている。

商談情報生成・更新部１１２は、入力操作部１３０で受け付けた、顧客及び商談の状況に関する種々の情報を商談情報として構造化し、記憶部１２０に格納する。

営業アクション選定部１１３は、記憶部１２０に記録されている営業アクションの一覧と、同じく記憶部１２０に記録されている実施済みの営業アクションの一覧とを比較し、未実施の営業アクションを抽出するとともに、未実施営業アクションの中からマッチ度を大きく増減させる１以上のアクションを選定する。選定結果は、情報表示部１４０が操作・表示端末１０２を介して表示する。

進捗度試算部１１４は、記憶部１２０に記録されている、営業員が実施した営業アクションの結果から、商談の進捗度を試算する。営業員が実施した営業アクションの結果は、入力操作部１３０を介して受け付けられ、記憶部１２０に記録されている。進捗度試算部１１４による試算結果は、記憶部１２０に格納される。

マッチ度試算部１１５は、記憶部１２０に記録されている、営業員が実施した営業アクションの結果に基づき、顧客とソリューションとのマッチ度の増減を試算する。試算結果は、記憶部１２０に格納される。

進捗度判断部１１６は、記憶部１２０に記録されている進捗度の推移が、ソリューションごとに定義された商談継続可否の基準を超えているか判断する。判断結果は、記憶部１２０に格納される。

マッチ度判断部１１７は、記憶部１２０に記録されているマッチ度の値と推移が、ソリューションごとに定義された商談継続可否の基準を超えているか判断する。判断結果は、記憶部１２０に格納される。

リソース確保可否判断部１１８は、記憶部１２０に記録されている、想定される受注規模と、ソリューションの構築・デリバリに必要なエンジニアリングリソースの空き状況とから、その商談においてリソースを確保できるかどうかを判断する。受注規模及びエンジニアリングリソースの空き状況は、入力操作部１３０を介して受け付けられ、記憶部１２０に格納されている。リソース確保可否判断部１１８判断結果は、記憶部１２０に格納される。

判断基準更新部１１９は、記憶部１２０に格納されている進捗度、マッチ度の推移、商談進捗可否判断結果、及び商談の最終的な結果に基づき、商談の継続可否の判断基準を更新する。更新結果は記憶部１２０に格納される。

なお、演算部１１０内の各部の機能は、プロセッサがそれぞれに対応するプログラムを実行することによって実現されてもよい。例えば、演算部１１０はプロセッサを含み、演算部１１０内のメモリ又は記憶部１２０に格納されたプログラムを実行することによって各部の機能を実現してもよい。その場合、以下の説明において演算部１１０内の各部が実行する処理は、実際には演算部１１０のプロセッサがプログラムに従って実行する。

記憶部１２０における各テーブルの具体的なデータ構造の例については、後述する処理フローに関する説明に伴って述べる。ここでは、各テーブルの概要について説明する。本実施形態における記憶部１２０は、六つのテーブルから構成される。

商談情報テーブル１２１には、現在進行中または過去の商談に関して、商談開始日、ソリューション提案先の顧客の属性、提案する又は提案したソリューション名、及び商談結果などが、商談ごとに整理された商談情報として記録されている。

ソリューション情報テーブル１２２には、拡販対象となるソリューションごとに、対象業種、課題、必要工数及び納期などが記録されている。

営業アクション情報テーブル１２３には、営業員が顧客とソリューションのマッチ度を明らかにするために必要な営業アクションが、そのアクション実施によるマッチ度の増減値とともに記録されている。

商談進捗情報テーブル１２４には、商談ごとに、営業員がとった営業アクションとその結果が、進捗度とマッチ度の試算結果とともに記録されている。

判断基準情報テーブル１２５には、進捗度及びマッチ度に基づく商談の進捗可否判断の基準（閾値）が記録されている。

エンジニアリングリソース情報テーブル１２６には、ソリューションのデリバリに必要なエンジニアリングリソースの空き状況が、部署、組織及びソリューション名と関連付けられて記録されている。

＜データフロー例＞
図３は、本発明の実施例における、デジタルソリューション営業支援装置１０１とその付随装置との間のデータのやり取りを表すデータフロー図である。

このフローは、顧客との商談の開始にあわせて営業員１００が操作・表示端末１０２を介して商談情報を営業支援装置１０１に登録するところ（図３のＦ１）から、同じく営業員１００が操作・表示端末１０２を介して商談の受注結果を営業支援装置１０１に登録し（図３のＦ１９）、営業支援装置１０１が受注結果にあわせて商談の継続可否を判断する判断基準を学習（更新）するところ（図３のＦ２０）までを含む。

商談登録Ｆ１は、営業員１００が操作・表示端末１０２を介して入力した商談情報が、営業支援装置１０１内の商談情報テーブル１２１に記録される流れである。商談情報は例えば、顧客名、商談開始日、提案ソリューション及び担当営業員名などを含む。

アクション検索Ｆ２は、当該商談において未実施の営業アクションを、営業支援装置１０１が営業アクション情報テーブル１２３から検索する手続きである。

アクション提示Ｆ３は、アクション検索Ｆ２で検索された未実施の営業アクションについて、操作・表示端末１０２を介して営業員１００に提示する流れである。この際、マッチ度を大きく増減させるアクションが優先的に提示される。

アクション結果入力Ｆ４は、営業員が営業アクションを実施した結果を、操作・表示端末１０２を介して営業支援装置１０１に入力する流れである。入力されたアクションの実施結果は、商談進捗情報テーブル１２４に記録される。

進捗度・マッチ度試算Ｆ５は、営業支援装置１０１において、商談進捗情報テーブル１２４に記録されている営業アクションの実施結果に基づき、商談の進捗度、及び、顧客とソリューションとのマッチ度を試算する手続きである。試算結果は同じく商談進捗情報テーブル１２４に記録される。

進捗度・マッチ度提示Ｆ６は、営業支援装置１０１が操作・表示端末１０２を通じて営業員に対して進捗度とマッチ度の増減の結果を提示する手続きである。

進捗度・マッチ度判断Ｆ７は、営業支援装置１０１に格納されている、商談情報テーブル１２１、ソリューション情報テーブル１２２、商談進捗情報テーブル１２４、及び判断基準情報テーブル１２５に記録されている各種情報から、進捗度及びマッチ度の観点で商談が順調であるか分析し、商談の継続可否を判断する手続きである。判断の手法は後述する。判断結果は、商談進捗情報テーブル１２４に記録される。

進捗度・マッチ度判断結果提示Ｆ８は、進捗度及びマッチ度の観点での商談の継続可否の判断結果を、操作・表示端末１０２を介して営業員１００に提示する流れである。

継続判断（進捗・マッチ度）Ｆ９は、営業員１００が営業支援装置１０１によって提示された商談の継続可否判断を参考に、商談を実際に継続するかどうかの判断をする手続きである。判断結果は商談進捗情報テーブル１２４に記録される。

継続判断入力Ｆ１０は、営業員１００が自身の商談継続可否判断を、操作・表示端末１０２を介して営業支援装置１０１に入力する流れである。入力結果は、商談進捗情報テーブル１２４に記録される。ここで営業員の判断が、リソース確認実施の場合は、次の手続きであるリソース情報問合Ｆ１１にフローが遷移する。また、営業員の判断が商談継続の場合は、アクション検索Ｆ２に戻り、再び営業アクションを検索・実行する。さらに営業員の判断が、商談非継続の場合はそれを営業員の最終判断として、フローが最終判断入力Ｆ１８に遷移する。

リソース情報問合Ｆ１１は、営業員が商談が順調であると判断し、継続判断入力Ｆ１０で入力された判断がリソース確認実施であった場合に、営業支援装置１０１が提案するソリューションの構築・デリバリに必要なエンジニアリングリソースの空き状況を、当該リソースを保有する組織や部署が管理しているリソースＤＢ１０３に問い合わせるフローである。

リソース情報回答Ｆ１２は、リソースＤＢ１０３がリソース空き状況の問合せに対して、空き状況を回答するフローである。回答された情報はエンジニアリングリソース情報テーブル１２６に記録される。

受注規模入力Ｆ１３は、営業員１００が操作・表示端末１０２を介して、進めている商談の想定受注規模を営業支援装置１０１に入力する手続きである。入力結果は、商談情報テーブル１２１に記録される。

リソース確保可否判断Ｆ１４は、リソースの空き状況及び想定受注規模に基づいて、後述する手法を用いてリソースの確保可否の判断をする手続きである。判断結果は、商談進捗情報テーブル１２４に記録される。

リソース確保可否判断結果提示Ｆ１５は、リソースの確保可否判断結果を操作・表示端末１０２を介して営業員１００に提示する手続きである。

継続判断（リソース）Ｆ１６は、営業員１００が、営業支援装置１０１から提示されたリソース確保可否判断結果に基づいて、商談を中断するか判断する手続きである。

継続判断入力Ｆ１７は、継続判断（リソース）Ｆ１６での営業員の判断を、操作・表示端末１０２を介してデジタルソリューション営業支援装置１０１に入力する手続きである。入力結果は、商談進捗情報テーブル１２４に記録される。営業員の判断が議論継続の場合は、受注規模を大きくするための顧客との議論を行い、その結果を入力するために受注規模入力Ｆ１３に遷移する。また、営業員の判断が正式提案実施の場合は、その判断結果は最終判断入力Ｆ１８において営業支援装置１０１に入力される。また、営業員の判断が商談非継続の場合はそれを営業員の最終判断として、フローが最終判断入力Ｆ１８に遷移する。

最終判断入力Ｆ１８では、営業員１００の最終的な判断を操作・表示端末１０２を介して営業支援装置１０１に入力するフローである。入力結果は、商談進捗情報テーブル１２４に記録される。

受注結果入力Ｆ１９は、営業員１００の最終判断が正式提案実施の場合、最終的な受注・失注結果を営業員１００が操作・表示端末１０２を介して営業支援装置１０１に入力するフローである。また、営業員１００の判断が商談非継続の場合は、自動的にその旨が記録される。受注結果は、商談進捗情報テーブル１２４に記録される。

判断基準学習Ｆ２０は、商談進捗情報テーブル１２４に記録されている情報から、進捗度・マッチ度の判断基準を更新する手続きである。更新結果は、判断基準情報テーブル１２５に記録される。

以上が本実施例における、デジタルソリューション営業支援装置１０１とその付随装置の間のデータのやり取りの一例である。

＜処理フロー例＞
図４は、本発明の実施例における、デジタルソリューション営業支援方法のメインの処理フロー例を示す図である。

この処理フローは顧客との商談の開始から受注又は失注後の判断基準の学習までを含む。ソリューション提案後の契約作業、並びに、ソリューションの詳細設計、実装、導入及び運用などは本実施例において支援するものではない。ただし、これらの活動において参照可能な、過去のソリューション導入時の契約書、設計書、プログラム及び設定ファイルなどのデータは、ソリューションの導入実績を記録する際にあわせてファイル保存領域１６０に蓄積し、それを新しい商談において再利用しても良い。

メインの処理フローの商談情報登録ステップＳ１においては、ソリューションを顧客に対して提案する営業員１００が、商談開始にあたって顧客名及び提案しようとするソリューション名などの商談の基本的な情報を入力すると、営業支援装置１０１内の商談情報生成・更新部１１２がそれらを商談情報として整理し、商談情報テーブル１２１に記録する。この際の情報は、営業員１００が操作・表示端末１０２を使い、入力操作部１３０を介して営業支援装置１０１に入力されたものである。また、ソリューションの情報は、ソリューション情報テーブル１２２に記録されている。なお商談情報登録ステップＳ１は、図３で示すデータフロー図における、商談登録Ｆ１を実現する処理である。

図５は、本発明の実施例における商談情報テーブル１２１の一例を示す図である。

商談情報テーブル１２１は、商談ｉｄ１２１ａ、顧客名１２１ｂ、商談開始日１２１ｃ、担当営業所属部署１２１ｄ、担当営業名１２１ｅ、提案ソリューションｉｄ１２１ｆ、提案ソリューション名１２１ｇ、想定受注規模１２１ｈ、などから構成される。商談ｉｄ１２１ａは、商談を識別するユニークなｉｄ（identifier）である。提案ソリューションｉｄ１２１ｆは、顧客に提案するソリューションのｉｄである。想定受注規模１２１ｈは、想定される受注規模額である。

商談情報テーブル１２１の内容は、商談情報登録ステップＳ１でのみ記入又は更新されるのではなく、図４で示す一連の処理フローの中で随時情報が追加又は更新される。商談情報登録ステップＳ１においては、商談ｉｄ１２１ａから提案ソリューション名１２１ｇまでが入力される。また、過去に商談実績がある顧客については、その当時作成した商談情報を再利用しても良い。

また、顧客名１２１ｂ及び提案ソリューション名１２１ｇについては、情報間の一貫性及び再利用性を確保するために、予め定義された項目及び値の一覧の中から選択されるものとする。一覧は例えば、ファイル保存領域１６０にスプレッドシート又はＤＢの形式で保存されている。ただし、予め定義された項目及び値が当てはまらない顧客が出てきた場合は一覧を更新した上で、商談情報テーブルに選択及び入力する。

図６は、本発明の実施例におけるソリューション情報テーブル１２２の一例を示す図である。

ソリューション情報テーブル１２２は、ソリューションｉｄ１２２ａ、ソリューション名１２２ｂ、ソリューションの対象業種１２２ｃ、顧客課題１２２ｄ、顧客価値１２２ｅ、必要エンジニアリングリソース１２２ｆ、最低商談工数（訪問回数）１２２ｇ、最低商談期間１２２ｈ、最大商談工数（訪問回数）１２２ｉ、最大商談期間１２２ｊ、ソリューションの標準価格１２２ｋ、などから構成される。

ソリューションｉｄ１２２ａは、ソリューションを区別するユニークなｉｄである。顧客課題１２２ｄは、ソリューションが対象とする顧客課題である。顧客価値１２２ｅは、ソリューション導入によって実現する顧客価値である。必要エンジニアリングリソース１２２ｆは、ソリューションの構築・デリバリにあたって必要なエンジニアリングリソースの量を表す。最低商談工数（訪問回数）１２２ｇは、当該ソリューションの商談において最低限必要と考えられる商談工数を営業員が客先に訪問する回数で規定したものである。最低商談期間１２２ｈは、当該ソリューションの商談において最低限必要と考えられる商談期間を規定したものである。最大商談工数（訪問回数）１２２ｉは、当該ソリューションの商談においてかけられる商談工数の最大値を営業員が客先に訪問する回数で規定したものである。最大商談期間１２２ｊは、当該ソリューションの商談においてかけられる商談期間の最大値を規定したものである。ソリューションｉｄ１２２ａとソリューション名１２２ｂは、商談情報テーブル１２１内に記録されるものと整合性が取られているものとする。

メインの処理フロー（図４）の営業アクション取得ステップＳ２においては、情報検索部１１１が、営業アクション情報テーブル１２３から未実施の営業アクションを検索する。なお、本ステップは、図３で示すデータフロー図におけるアクション検索Ｆ２を実現する処理である。実施済みの営業アクションは、商談進捗情報テーブル１２４に記録されているものとする。

図７は、本発明の実施例における営業アクション情報テーブル１２３の一例を示す図である。

なお、営業アクションは、提案するソリューションによらず営業員が共通的に実施すべき営業アクションである共通営業アクションと、ソリューションごとに特有の実施すべき営業アクションであるソリューション別営業アクションに大別できるが、本実施例では営業アクション情報テーブル１２３は両者をまとめて保持するものとする。一方、共通営業アクションとソリューション別営業アクションを別に保持しても良い。

営業アクション情報テーブル１２３は、営業アクションのユニークなｉｄを表すｉｄ１２３ａ、営業アクションの内容１２３ｂ、該当ソリューション１２３ｃ、結果別マッチ度増減値１２３ｄ、などから構成される。

内容１２３ｂは、例えば営業員が顧客に対してヒアリング又は調査などを通じて確認すべき項目であり、「人手作業の実績値をとれているか？」など、Ｙｅｓ、Ｎｏ、不明などでアクション結果が記述可能な内容、又は、「人手作業の割合はどの程度か？」など定量的な数値をもとにアクション結果が記述可能な内容などが定義されている。

該当ソリューション１２３ｃは、当該アクションが共通営業アクションかソリューション別営業アクションかを表す。当該アクションがソリューション別営業アクションである場合、該当ソリューション１２３ｃには、その営業アクションがどのソリューション別営業アクションか示すために、例えばソリューションｉｄが記録されている。一方、当該アクションが共通営業アクションの場合、該当ソリューション１２３ｃには例えば、共通などと記録される。

結果別マッチ度増減値１２３ｄには、内容１２３ｂで定義されている営業アクション内容の結果に応じて顧客とソリューションのマッチ度の増減値が定義されている。営業アクション及びマッチ度の増減値は、ソリューションの構築時などに予め定義されたものであったり、あるいは商談を重ねて新たに追加又は更新されたものであったりしても良い。

図８は、本発明の実施例における商談進捗情報テーブル１２４の一例を示す図である。

なお、商談進捗情報テーブル１２４は、商談情報登録ステップＳ１において商談情報が入力・生成された際に、同一の商談の進捗情報を示すテーブルとして生成される。

商談進捗情報テーブル１２４は、商談ｉｄ１２４ａ、顧客名１２４ｂ、商談開始日１２４ｃ、最終営業判断１２４ｄ、商談最終結果１２４ｅ、商談進捗履歴１２４ｆなどから構成される。

商談ｉｄ１２４ａ、顧客名１２４ｂ及び商談開始日１２４ｃには、当該商談に関する商談情報テーブル１２１の商談ｉｄ１２１ａ、顧客名１２１ｂ及び商談開始日１２１ｃと同一の値が記録される。最終営業判断１２４ｄは、営業員による商談の継続に関する最終的な判断である。例えば、最終営業判断１２４ｄには、ソリューションを顧客に対して正式提案する「正式提案」、又は、途中で商談を中止させる「商談中止」、などが記録される。商談最終結果１２４ｅは、受注、失注又は中止など、商談の最終的な結果である。

商談進捗履歴１２４ｆには、商談の進捗履歴が記録される。例えば、商談進捗履歴１２４ｆは、年月日１２４ｇ、実施アクション１２４ｈ、進捗度１２４ｉ、マッチ度１２４ｊ、進捗度判断１２４ｋ、マッチ度判断１２４ｌ、営業員判断（進捗・マッチ度）１２４ｍ、リソース確保判断１２４ｎ、営業員判断（リソース）１２４ｏ、などから構成される。

年月日１２４ｇは、営業員が顧客訪問又はヒアリングをした年月日である。実施アクション１２４ｈには、顧客訪問又はヒアリングを通じて実施した営業アクションが営業アクションｉｄの形式で記録されている。進捗度１２４ｉは、当該営業アクションを実施後の商談の進捗度である。マッチ度１２４ｊは、当該営業アクション実施後の顧客とソリューションとのマッチ度である。進捗度判断１２４ｋには、進捗度の観点で営業支援装置１０１が導く商談の継続可否の判断が記録される。マッチ度判断１２４ｌには、マッチ度の観点で営業支援装置１０１が導く商談の継続可否判断が記録される。営業員判断（進捗・マッチ度）１２４ｍには、営業支援装置１０１が提示する進捗度又はマッチ度の観点での商談継続可否判断を受けて、営業員が下す商談継続可否の判断が記録される。リソース確保判断１２４ｎには、提案しようとしているソリューションの構築・デリバリに必要なエンジニアリングリソースを確保できるかの観点で営業支援装置１０１が導く商談の継続可否の判断が記録される。営業員判断（リソース）１２４ｏには、営業支援装置１０１が提示するリソース確保可否の観点での商談継続可否判断を受けて、営業員が下す商談継続可否判断が記録される。

進捗度及びマッチ度の試算、並びに商談進捗可否判断は、営業アクション取得ステップＳ２より後のステップで処理、記録されるものとする。

メインの処理フロー（図４）の営業アクション提示ステップＳ３においては、営業アクション取得ステップＳ２において検索・取得した未実施の営業アクションの中から、営業アクション選定部１１３がマッチ度を最も上昇させる営業アクションを複数個選定し、情報表示部１４０が操作・表示端末１０２を介して営業員１００に対して提示する処理である。営業アクション提示ステップＳ３は、図３で示すデータフロー図においては、アクション提示Ｆ３を実現する処理である。

マッチ度の上昇値は、営業アクション情報テーブル１２３の中のソリューション毎の結果別マッチ度増減値１２３ｄに基づく。また、提示する営業アクションの個数はいくつでも良いが、例えば、一度の顧客訪問又はヒアリングで営業員が実施可能な、最大でも１０個前後が望ましいと考えられる。

なお、営業アクション選定部１１３は、営業アクション取得ステップＳ２において、マッチ度を最も上昇させる営業アクションを一つのみ選択し、情報表示部１４０がそれを提示してもよい。しかし、上記のように、マッチ度の上昇量が比較的大きい営業アクションを複数選択して表示することで、例えば営業員１００が比較的実施しやすいものを選択して実施するなど、営業活動の自由度を損なわずに効率的な営業活動を支援することが可能になる。

メインの処理フローのアクション結果登録ステップＳ４は、営業員１００が操作・表示端末１０２を用いて入力した顧客訪問又はヒアリングにおいて実施した営業アクションの結果を、入力操作部１３０が受け付けて、商談進捗情報テーブル１２４に記録する処理である。この際、実施された営業アクションは営業アクション提示ステップＳ３で営業員１００に対して提示された営業アクションであることが想定されるが、提示されていない営業アクションであっても良い。営業アクション結果を入力する方法については、後述の画面表示例の部分で説明する。なお、アクション結果登録ステップＳ４は、図３で示すデータフロー図においては、アクション結果入力Ｆ４を実現する処理である。

メインの処理フローの進捗度・マッチ度算出・提示ステップＳ５においては、実施された営業アクションの結果に基づいて、商談の進捗度及び顧客とソリューションとのマッチ度を、それぞれ、進捗度試算部１１４及びマッチ度試算部１１５が試算する。試算結果は、商談進捗情報テーブル１２４に記録される。そして、試算結果は情報表示部１４０によって、操作・表示端末１０２上に表示されることで営業員１００に提示される。なお、進捗度・マッチ度算出・提示ステップＳ５は、図３で示すデータフロー図においては、進捗度・マッチ度試算Ｆ５及び進捗度・マッチ度提示Ｆ６を実現する処理である。

本実施例における、進捗度試算手法について述べる。本実施例では、商談の進捗度を、「提案ソリューションに関する営業アクションの実施済み率」とする。ここでの提案ソリューションに関する営業アクションとは、ソリューション別営業アクションと共通営業アクションの双方を含む。例えば、提案するソリューションに関する営業アクションの全体数がｍａ個、その中である時点での実施済み営業アクションの数がｍｂ個とすると、その時点での商談の進捗度は以下の式（１）のように試算できる。

（商談の進捗度）[％]＝ｍｂ÷ｍａ ・・（１）

例えば、営業アクションの総数が３０個、その内実施済みのアクション数を１５個とすると、商談の進捗度は、３０％１５＝５０％と試算できる。営業アクションの総数並びに実施済み営業アクション数は、営業アクション情報テーブル１２３及び商談進捗情報テーブル１２４から取得できる値である。なお、本実施例では進捗度の増加に対する影響は営業アクションごとに差が無いと仮定しているが、例えば営業アクションごとに進捗度の増加値が異なる場合は、ｉ番目の営業アクション実施時に商談の進捗度がｗｉ増加すると仮定すると、進捗度は以下の式（２）のように試算できる。

（商談の進捗度）[％]＝（実施済みの営業アクションのｗｉの和）÷（関連する営業アクションのｗｉの総和） ・・（２）

上記手法に基づいて、顧客訪問又はヒアリング実施のたびに商談の進捗度がどの程度増加するか試算する。

続いて本実施例における、マッチ度試算手法について述べる。本実施例では、マッチ度の初期値を５０とし、営業アクションごとに設定されたマッチ度の増減値（営業アクション情報テーブル１２３内の結果別マッチ度増減値１２３ｄ）を元に、以下の式（３）のように実施済みの営業アクションの増減値を足し合わせることによって試算する。

（マッチ度）＝５０＋（実施済み営業アクションのマッチ度増減値の総和） ・・（３）

例えば、現状のマッチ度が５５の時、二つの営業アクションの実施によりマッチ度がそれぞれ＋５、−３変化するとする。この時のマッチ度は、５５＋５−３＝５７となる。

マッチ度と進捗度は関係性がある。すなわち、営業アクションの実施によって進捗度が増加するとともに、マッチ度も増減する。

図９は、本発明の実施例における進捗度とマッチ度との関係性の一例を示す図である。

図９のグラフは、横軸を進捗度、縦軸をマッチ度とし、一つの商談の進捗度に対応するマッチ度をプロットした例である。図９中の値９ａは、進捗度０、すなわち営業アクション未実施状態に対応し、その際のマッチ度は初期値５０をとる。その後、進捗度の増加（すなわち営業アクションの実施）とともにマッチ度も増加する（例えば図９中の値９ｂ）。

なお、マッチ度については、理論上の最大値と最小値も考えられる。最大値は、提案するソリューションに関する営業アクションのうち、未実施の営業アクションの全てを実施した際に、マッチ度が全て増加した場合のマッチ度、最小値は逆に、提案するソリューションに関する営業アクションのうち、未実施の営業アクションの全てを実施した際に、マッチ度が全て減少した場合のマッチ度である。例えば図９における値９ｃ（すなわちエラーバーの上端）及び値９ｄ（すなわちエラーバーの下端）はそれぞれその時点でのマッチ度の最大値及び最小値を示す。

営業アクションの実施が進むにつれて、マッチ度が増減するとともに、最大値及び最小値も増減する。一般に実施済みの営業アクションが増えるにつれて、未実施の営業アクションが減ることから、最大値と最小値との間の幅も減少していく（すなわち、それ以後の進捗によってマッチ度の取りうる値の範囲が狭くなる）。換言すれば、マッチ度の値の不確実性が減少する。すなわち、営業アクションを実施することは、マッチ度の値の不確実性を減少させることと等しくなる。

メインの処理フロー（図４）の進捗度・マッチ度判断・提示ステップＳ６においては、進捗度及びマッチ度の観点で、商談の継続可否を進捗度判断部１１６及びマッチ度判断部１１７が判断基準情報テーブル１２５に記録されている判断基準に基づき判断し、その結果を商談進捗情報テーブル１２４に記録する。そして判断結果は、情報表示部１４０によって、操作・表示端末１０２上に表示されることで営業員１００に提示される。なお、進捗度・マッチ度判断・提示ステップＳ６は、図３で示すデータフロー図における進捗度・マッチ度判断Ｆ７及び進捗度・マッチ度判断結果提示Ｆ８を実現する処理である。

本実施例における、進捗度の観点での商談継続可否を判断する手法の一例を以下に示す。進捗度は、本実施例においては営業アクションの実施数である。一般的に、複数回顧客を訪問したり、またはある程度の期間商談を継続したりすると、営業アクションの実施数も伸び、それにともない進捗度も増える。一方、時間をかけて顧客訪問又はヒアリングの回数を重ねても、営業アクションの実施回数が伸びず、進捗度もあまり増加しない状況が考えられる。このような状況はすなわち、商談が停滞している状況と考えられる。

商談が停滞する要因はいくつか考えられる。例えば、商談に対して顧客が乗り気ではなかったり、顧客側の商談を進める体制が整ってなかったりして、商談の進める上で重要な議論ができないことなどが考えられる。このような状況では、ソリューションの提案側にとっては訪問回数及びヒアリングを重ねたとしても受注の見込みも少なく、また営業工数がかかり受注したとしても利益率が悪化する。また顧客としても、購入に繋がらない商談を進めることは業務上の負担も多く、また顧客がデジタルソリューション導入に期待する、有効なソリューションを素早く導入してデジタル化を加速する、といったことの妨げにもなる。

よって、商談が停滞している状況、すなわち商談開始からある程度の訪問回数又は期間を重ねた割には進捗度が伸びていない商談は、商談を中止する判断をすることが、ソリューションの提案側、顧客双方にとっても重要と考えられる。

そこで進捗度判断部１１６は、判断基準情報テーブル１２５に記録されている情報をもとに、商談開始からの期間や工数と進捗度との関係性から、商談の継続可否判断を導く。基本的には、訪問回数で表現される商談開始からの営業工数及び商談期間ごとに定められた、進捗度の基準を実際の進捗度が超えているかどうかで商談が順調かどうか判断する。ただし、商談開始直後は、顧客との関係性構築ができていないなどの理由で、詳細なヒアリングがしづらく、営業アクションを実施しづらい（すなわち進捗度が伸びづらい）可能性もある。よって商談開始から最低限の期間又は最低限の訪問回数に達するまでの間は、進捗度の大きさによらず継続可否判断を留保するものとする。

一方、商談開始からある程度の期間又は訪問回数を重ねても正式提案に繋がらない場合は、進捗度の大小に関わらず、何らかの理由で受注の見込みがないと考えて商談を中止にするべきと考えられる。なぜならばこういった判断を下さないと、営業側にとっては受注に繋がらない長期化した商談が蓄積し、その管理コストの負担が大きくなるからである。顧客側にとっても、何年も前の商談を継続されても、事業環境の変化又は別のソリューションを導入したなどの理由で商談を継続する意味も少なく、商談対応が無駄になるからである。また上記の基準はソリューション毎に異なると考えられる。例えば大規模なソリューションの場合は最低限必要な商談期間も小規模なものに比べると長くなるなどといったことがありうる。

以上のような基準と考え方に基づく、商談の継続可否判断について説明する。

図１０は、本発明の実施例における商談開始からの期間又は工数（期間及び工数のいずれか、又は、それらの両方に基づいて算出された指標）と進捗度との関係性に基づく商談の継続可否判断を示す模式図である。

図１０中のライン１０ａのが、ソリューション毎に定められた、営業工数又は商談期間ごとに定められた進捗度の基準である。ある営業工数又は商談期間における進捗度がこのラインを上回れば、商談が順調である、逆に下回れば、商談が停滞していると考える。

基準ライン１０ａの開始点１０ｂは、ソリューション毎に定義された商談に最低限必要な工数又は期間１０ｃ（以下、ソリューション最低工数・期間１０ｃとも記載する）において求められる最低限の進捗度である。ソリューション最低工数・期間１０ｃの値としては、例えば、ソリューション情報テーブル１２２中の最低商談工数（例えば訪問回数）１２２ｇ又は最低商談期間１２２ｈの値を用いる。

また、基準ライン１０ａの終了点１０ｄは、ソリューション毎に定義された、商談にかけてよい最大限の工数又は期間１０ｅ（以下、ソリューション最大工数・期間１０ｅとも記載する）において求められる最低限の進捗度である。ソリューション最大工数・期間１０ｅの値としては、例えば、ソリューション情報テーブル１２２中の最大商談工数（例えば訪問回数）１２２ｉ又は最大商談期間１２２ｊの値を用いる。

商談の期間又は工数がソリューション最低工数・期間１０ｃ以下の場合は進捗度の大きさによらず商談は継続可否の判断は留保する。商談の期間や工数がソリューション最大工数・期間１０ｅより大きい場合は進捗度の値によらず商談は継続不可と判断する。

以上を踏まえると、図１０において斜めハッチングされた領域１０ｆ内のいずれかの位置（例えば商談の位置１０ｇ）に商談の進捗度が位置づけられる場合は継続可であると判断できる。また図１０において横ハッチングされた領域１０ｈ内のいずれかの位置に商談の進捗度が位置づけられる場合は継続判断は留保する。商談の進捗度が領域１０ｆ及び１０ｈのいずれより外にある場合は継続不可と判断できる。

なお、基準ライン１０ａは図１０では直線で表現しているが、単調増加であれば曲線でもかまわない。また、上記では相談開始からの期間と営業工数を区別せずに用いたが、実際の判断では営業工数と期間どちらかのみで判断したり、両方ぞれぞれで判断したり、あるいは両方を含む何らかの指標に基づいて判断したりすることができる。両方それぞれで判断をした場合は、それぞれの判断のどちらかを採用、判断が一致した場合のみ採用、などのパターンが考えられるが、どのパターンを用いるかは、営業員の判断及び営業組織のポリシーなどから決められる。

上述した図１０における開始点１０ｂ及び終了点１０ｄの基準値は、本実施例では判断基準情報テーブル１２５に記録されている。

図１１は、本発明の実施例における判断基準情報テーブル１２５の一例を示す図である。

判断基準情報テーブル１２５は、ソリューションごとに作られ、ソリューションｉｄ１２５ａ、ソリューション名１２５ｂ、最低商談工数・商談期間における進捗度閾値１２５ｃ、最大商談工数・商談期間における進捗度閾値１２５ｄ及びマッチ度閾値１２５ｅなどから構成される。

ソリューションｉｄ１２５ａ及びソリューション名１２５ｂ、は、それぞれ、ソリューション情報テーブル１２２のソリューションｉｄ１２２ａ及びソリューション名１２２ｂと整合する。最低商談工数・商談期間における進捗度閾値１２５ｃは、図１０の開始点１０ｂに対応する。最大商談工数・商談期間における進捗度閾値１２５ｄは、図１０の終了点１０ｄに対応する。マッチ度閾値１２５ｅは、マッチ度に基づく判断に用いられる。これらのテーブルの数値はソリューション構築時に定義されるとともに、商談結果を反映するかたちで更新されても良い。

また、判断基準情報テーブル１２５は、基準ライン１０ａを定義する情報（例えば基準ライン１０ａが単調増加する直線である場合の傾き及び切片といった、基準ライン１０ａを表現するための関数のパラメータ等）をさらに含んでもよい。

次に、本実施例における、マッチ度の観点での商談継続可否の判断する手法の一例を以下に示す。本実施例では、ソリューションごとに定義されたマッチ度の基準値（判断基準情報テーブル１２５中のマッチ度閾値１２５ｅ）より、商談のマッチ度が上回っているかどうかで判断する。

図１２は、本実施例におけるマッチ度の観点での商談継続可否の判断を示す模式図である。

図１２は図９と同じ図に、マッチ度閾値１２ａのラインを追加したものである。マッチ度閾値は、判断基準情報テーブル１２５中のマッチ度閾値１２５ｅの値である。基本的には、進捗度にあわせて増減するマッチ度について、マッチ度１２ｂのようにマッチ度が閾値１２ａを超えたらマッチ度の観点で商談が順調であり、商談の継続可と判断する。一方先述のように、マッチ度には不確実性があるため、ある段階でマッチ度の値が閾値を超えていても、とりうる可能性がある最低値が閾値１２ａを下回る場合も考えられる。よって、とりうる値の最低値が閾値を超えるまで判断を留保する、というよりリスクをとらない方針も考えられる。これらの判断は、営業員の判断及び営業組織のポリシーなどから決められる。

例えば、既に実行された営業アクションに基づくマッチ度（すなわち図中の丸印で表示される点）が閾値１２ａを超えた場合に、商談継続可と判断してもよい。しかし、その場合でも、取りうるマッチ度の最低値（すなわちエラーバーの下端）が閾値１２ａの下にあれば、将来行う営業活動の結果によって、マッチ度が閾値１２ａを下回る可能性もある。このため、商談不成立のリスクを極力回避したい場合などには、エラーバーの下端が閾値１２ａを超えた場合に商談継続可と判断してもよい。一方、例えば商談不成立のリスクを許容して、少しでも可能性のある商談は継続するという方針であれば、エラーバーの上端が閾値１２ａを下回らない限り、商談継続可と判断することも考えられる。

上記の進捗度及びマッチ度に基づく判断結果を組み合わせ総合的な判断が生成される。

図１３は、本発明の実施例における進捗度及びマッチ度に基づく総合判断の一例を示す図である。

基本的にはマッチ度の基準で継続可の場合は、顧客とソリューションとがマッチしていると判断してよいので、商談の次のステップであるリソース確認という総合判断を導く。一方、マッチ度基準で継続不可の場合でも、進捗度基準で留保、継続可の場合はまだ商談を続けられる余地があるので、商談継続を導く。マッチ度、進捗度両方の基準で継続不可の場合は、商談中止を導く。

これらの判断は営業支援装置１０１が導くものであるので、最終的な判断は営業員自身が行う。その結果は操作・表示端末１０２を介して営業支援装置１０１に入力される（図３の継続判断（進捗・マッチ度）Ｆ９及び継続判断入力Ｆ１０に相当）。この判断は、商談進捗情報テーブル１２４の営業員判断（進捗・マッチ度）１２４ｍに記録される。営業員の判断が、リソース確認の場合は図４の処理フローは次のリソース情報取得ステップＳ７に遷移し、商談継続の場合は、営業アクション取得ステップＳ２に遷移する。

メインの処理フローのリソース情報取得ステップＳ７は、営業員の判断がリソース確認となった場合に、提案するソリューションの構築・デリバリに必要なエンジニアリングリソースの空き状況を、営業支援装置１０１が通信部１５０を用いて、当該リソースを保有している組織・部署が管理するリソースＤＢ１０３から取得し、エンジニアリングリソース情報テーブル１２６に記録する処理である。これは図３で示したデータフロー図においては、リソース情報問合Ｆ１１及びリソース情報回答Ｆ１２を実現する処理である。

図１４は、本発明の実施例におけるエンジニアリングリソース情報テーブル１２６の一例を示す図である。

エンジニアリングリソース情報テーブル１２６は、提案するソリューションのｉｄ１２６ａ、ソリューション名１２６ｂ、当該ソリューションを構築・デリバリするのに必要なリソースを保有する部署名である必要リソース保有部署１２６ｃ、リソースの空き状況１２６ｄ、リソース単価１２６ｅ、リソースの空き状況の確認日１２６ｆなどから構成される。

メインの処理フロー（図４）の受注規模取得ステップＳ８は、営業員１００が商談の過程で感触を得た想定受注規模を、操作・表示端末１０２を使って営業支援装置１０１に入力する処理である。入力された想定受注規模は、商談情報テーブル１２１中の想定受注規模１２１ｈに格納される。受注規模取得ステップＳ８は、図３で示すデータフロー図においては、受注規模入力Ｆ１３を実現する処理である。

メインの処理フローのリソース確保可否判断・提示ステップＳ９は、ソリューションの構築・デリバリに必要なエンジニアリングリソースの空き状況と想定受注規模などから、経済合理性の観点でその商談にエンジニアリングリソースをあててよいか判断し、その結果を商談進捗情報テーブル１２４中のリソース確保判断１２４ｎに記録するとともに、操作・表示端末１０２を介して営業員１００に提示する処理である。これは、図３で示すデータフロー図においては、リソース確保可否判断Ｆ１４及びリソース確保可否判断結果提示Ｆ１５を実現する処理である。

本処理における判断は、基本的には、該当ソリューションの構築・デリバリに必要なリソースが空いているか、という観点で行われる。さらに、想定受注規模が構築・デリバリに必要なリソースの単価と工数（リソースの活動期間）に見合うものかどうか、という要素も考慮する必要がある。両者を踏まえたリソース確保可否判断について説明する。

図１５は、本発明の実施例におけるエンジニアリングリソース確保可否判断の方法を示す模式図である。

具体的には、図１５は、受注規模と、投入する又は投入できるエンジニアリングリソースとの関係性を示す。位置１５ａは、該当商談の位置である。必要リソース１５ｂは、この商談で提案しようとしているソリューションの構築・デリバリに必要なリソースを示す。また、想定受注規模１５ｃは、営業員が商談の過程で得た感触に基づいて想定される受注規模を示す。また、空きリソース１５ｄのラインは、当該ソリューションの構築・デリバリに必要なエンジニアリングリソースの空き状況を示す。

基本的には、必要リソース１５ｂが空きリソース１５ｄより小さければ、ソリューションを構築・デリバリするために必要なリソースが確保できる状況である。これが一つ目の条件である。一方、必要なリソースは確保できても案件規模（受注額）が小さい場合、リソースを投入してもその受注が赤字になる可能性が出てくる。リソース確保可否の判断の際には以下の式（４）に示す条件も満たす必要がある。

（想定受注規模）＞（構築・デリバリに必要なリソースの総額）＝（リソース単価）×（必要リソース量）×（リソース投入期間） ・・（４）

本条件を図１５で表したのが、損益分岐点１５ｅのラインになる。損益分岐点１５ｅのラインは、受注規模に対して投入できるリソースの限界量を示している。商談がこのラインを超えることは、想定受注規模が必要なリソースの確保に対して不十分であることを表す。よって、最終的にリソースを確保してよいという判断は、上記の二つの条件を満たす、図１５における斜めハッチングの領域１５ｆに商談が位置する場合である。逆に商談が１５ｆの領域外に位置する場合は、リソース確保が経済合理的に困難であることを示す。

営業支援装置１０１が提示する、リソース確保可否判断結果を受けて営業員１００は、この場面でも商談の継続可否を判断し、その結果は操作・表示端末１０２を介して営業支援装置１０１に入力され、商談進捗情報テーブル１２４に記録される。これは図３で示すデータフロー図の継続判断（リソース）Ｆ１６、継続判断入力Ｆ１７及び最終判断入力Ｆ１８を実現する処理である。

リソース確保が可能な場合は、通常はそのままソリューションの正式提案という判断を最終判断として、その結果を操作・表示端末１０２を使って営業支援装置１０１に入力する。その結果は、商談進捗情報テーブル１２４に記録される。

一方リソース確保が難しい場合は、営業員はここでの商談中断という最終判断、あるいは最終判断をいったん留保して受注規模を上げるための顧客との交渉を継続する、といった判断を下す。前者の場合は、その判断が最終判断として扱われ、その結果を操作・表示端末１０２を使って営業支援装置１０１に入力する。その結果は、商談進捗情報テーブル１２４に記録される。後者の場合は、商談が継続され、処理フローは受注規模取得ステップＳ８に遷移する。

いずれにしても最終的には、営業員１００は正式提案もしくは商談中断という最終判断を行い、その結果は商談進捗情報テーブル１２４中の最終営業判断１２４ｄに記録される。

メインの処理フロー（図４）の商談結果取得ステップＳ１０においては、営業員１００の最終判断が正式提案であった場合に、提案した結果を営業員１００が操作・表示端末１０２を使って営業支援装置１０１に入力する処理である。入力結果は、商談進捗情報テーブル１２４中の商談最終結果１２４ｅに記録される。なおこれは、図３で示すデータフロー図における受注結果入力Ｆ１９を実現する処理である。

メインの処理フローの判断基準学習ステップＳ１１においては、受注結果に応じて、進捗度及びマッチ度の観点での商談継続判断の基準が更新される。これは図３で示すデータフロー図における判断基準学習Ｆ２０を実現する処理である。

例えば、マッチ度も十分に高かったにも関わらず失注した場合は、マッチ度の閾値が低すぎた可能性があるので、マッチ度の閾値を上げる（すなわち、判断基準情報テーブル１２５中のマッチ度閾値１２５ｅを高い方向に更新する）。

逆に、マッチ度が閾値より低かったために営業支援装置１０１が商談継続不可と出力したにも関わらず、営業員の判断で商談を継続して正式提案し、その結果受注に成功することもありうる。そのような場合は、マッチ度の閾値が高すぎた（すなわち判断基準が厳しすぎた）可能性があるため、マッチ度の閾値を下げる。

このように、営業支援装置１０１による各種判断の基準及び判断を行うための各種指標は商談の結果踏まえて適宜更新することが、判断の精度を上げるためにも望ましい。更新すべき基準・指標は例えば、営業アクション実施時のマッチ度の増減値、マッチ度の閾値、最低商談工数（訪問回数）などが考えられる。本更新作業は、本実施例では営業活動の専門家による人手で行ってもよいし、もしくは受注結果が多く存在する場合などは、最小二乗法など各種機械学習のアルゴリズムを使って行っても良い。いずれにしても更新結果は、営業支援装置１０１の一連の情報テーブルに反映・格納される。

＜画面表示例＞
以下では、図を用いて本実施例における画面表示と操作の一例を示す。すなわち、操作・表示端末１０２による表示の一例である。なお本実施例では、いわゆるタブレット端末又はスマートフォンなどスマートデバイスを前提とした画面表示例を示すが、本実施例の操作・表示端末１０２はスマートデバイスに限定されない。

図１６は、本発明の実施例における営業アクション提示画面の例を示す図である。

具体的には、図１６には、図４で示したメインの処理フローの営業アクション提示ステップＳ３における営業員が商談において実施すべき営業アクションが提示される、画面１６の一例を示す。なお本実施例では商談情報の入力画面も必要であるが、これは商談情報テーブル１２１に記録する商談の情報を入力・編集する画面であり、一般的な業務アプリケーションと同等であれば十分であるため、本実施例では特に述べない。

営業アクション表示画面１６は、アクション表示ボタン１６ｉを選択した際に表示される画面であり、進捗度表示領域１６ａ、マッチ度表示領域１６ｂ、商談概要表示領域１６ｃ、お勧め営業アクションの表示領域１６ｄ、営業アクションの概要表示領域１６ｅ、営業アクションの詳細を表示するボタン１６ｆ、営業アクションの実施結果を入力する画面を呼び出す結果入力ボタン１６ｇ、商談情報を登録・更新する画面を呼び出す商談情報登録・更新ボタン１６ｈ、その時点でのお勧め営業アクションを表示するためのボタン１６ｉ、商談の進捗状況を表示するための進捗確認ボタン１６ｊ、及び、受注結果を入力する画面を呼び出す受注結果ボタン１６ｋ、などから構成される。

進捗度表示領域１６ａには、その時点での商談の進捗度が表示される。マッチ度表示領域１６ｂには、顧客とソリューションとのマッチ度が表示される。進捗度表示領域１６ａ及びマッチ度表示領域１６ｂに表示される数値は、商談進捗情報テーブル１２４に格納されている。商談概要表示領域１６ｃには、商談に関する概要情報が表示される。これは、商談情報テーブル１２１に格納されている。お勧め営業アクションの表示領域１６ｄには、営業員が実施すべきとして営業アクション選定部１１３が選定した営業アクションが表示される。また、商談情報登録・更新ボタン１６ｈを押した際に表示される画面は前述の通り特に述べない。営業員はこの画面上で実施すべき営業アクションを確認する。詳細を知りたい場合は、詳細表示ボタン１６ｆを押して確認する。例えば、営業アクションの説明文がポップアップ表示されるなどが考えられるが、一般的な表示方法であるので本実施例では特に述べない。

図１７は、本発明の実施例における営業アクションの結果を入力する画面の例を示す図である。

具体的には、図１７には、図４で示したメインの処理フローの営業アクション結果登録ステップＳ４における営業員が商談において実施した営業アクションの結果を入力する画面１７の一例を示す。この画面は図１６で示した画面１６において結果入力ボタン１６ｇを押した際に表示される。

画面１７は例えば、ポップアップ表示される結果入力画面１７ａ、結果を入力する営業アクションが表示される営業アクション表示領域１７ｂ、営業アクションの結果を入力する上で参照すべきアクション内容の表示領域１７ｃ、いくつかの選択肢の中からアクション結果を選択するアクション結果選択ボタン１７ｄ、などから構成される。営業員は表示される内容を参照しつつ、選択肢として表示されているアクション結果の中から、実際に行った営業アクションの結果に最もあてはまるものを、選択ボタン１７ｄを押すことで入力する。なお本画面例では、アクション結果は選択式であるが、例えばテンキーで数値を入力するなどしても良い。入力された結果に基づく、実施済みの営業アクションは、商談進捗情報テーブル１２４に記録される。

図１８は、本発明の実施例における進捗度及びマッチ度の観点での商談継続可否判断を提示する画面の例を示す図である。

具体的には、図１８には、図４で示したメインの処理フローの進捗度・マッチ度判断・提示ステップＳ６で判断結果を提示する画面１８の一例を示す。なおこの画面は図１６で示した進捗確認ボタン１６ｊを押した際に表示される画面である。

画面１８は、進捗度が図示された進捗度図示領域１８ａ、現在の進捗度の数値を表示する進捗度表示領域１８ｂ、前回試算・表示してからの進捗度の増加値の表示領域１８ｂ、進捗度の観点で商談の継続可否の判断結果を表示する領域１８ｃ、マッチ度の推移が図示されたマッチ度図示領域１８ｄ、現在のマッチ度の数値を表示するマッチ度表示領域１８ｅ、前回試算・表示してからのマッチ度の増減値の表示領域１８ｆ、マッチ度の観点で商談の継続可否の判断結果を表示する領域１８ｇ、総合的な商談継続判断を表示する領域１８ｈ、及び営業員の判断を入力するボタン１８ｉから１８ｋなどから構成される。

ここで表示される進捗度及びマッチ度の試算値、あるいは判断結果は、それぞれ進捗度試算部１１４、マッチ度試算部１１５、進捗度判断部１１６及びマッチ度判断部１１７が商談進捗情報テーブル１２４及び判断基準情報テーブル１２５などに格納されている情報から、試算及び導出したものである。営業員はここで表示されている判断結果をもとに、商談継続に関する自身の判断をボタン１８ｌから１８ｋを押すことで選択し、入力する。選択及び入力結果は、商談進捗情報テーブル１２４に格納される。

図１９は、本発明の実施例におけるエンジニアリングリソース確保可否の観点での商談継続可否判断を提示する画面の例を示す図である。

具体的には、図１９には、図４で示したメインの処理フローのリソース確保可否判断・提示ステップＳ９において、リソース確保可否の判断結果を提示する画面１９の一例を示す。

画面１９は、リソースの確保可否を図示した領域１９ａ、確保可否判断を表示する領域１９ｂ、及び営業員による判断を選択・入力するボタン１９ｃから１９ｅ、などから構成される。

リソース確保可否の判断結果は、リソース確保可否判断部１１８が、ソリューション情報テーブル１２２及びエンジニアリングリソース情報テーブル１２６などに格納されている情報に基づいて試算及び導出したものである。営業員は提示された情報から自身の判断をボタン１９ｃから１９ｅを押すことで選択し、入力する。選択及び入力結果は、商談進捗情報テーブル１２４に格納される。

上記で説明した画面の他にも、図４で示したメインの処理フローにおける受注規模取得ステップＳ８、商談結果取得ステップＳ１０、または判断基準学習ステップＳ１１などにおいて、営業員が閲覧、操作・入力する画面が複数枚存在する。これらの画面は情報閲覧、操作・入力に関する一般的な業務アプリケーションと同等のものであれば十分なので、本実施例では特に述べない。

上記の実施例はデジタルソリューションを対象とする商談を例として説明したが、本実施例をデジタルソリューション以外の商材を対象とする商談にも適用することができる。本実施例におけるエンジニアリングリソースは、デジタルソリューションを提供するためのリソースであり、デジタルソリューション以外の商材が対象となる場合には、上記の説明におけるエンジニアリングリソースは、その商材を提供するためのリソースによって置き換えられる。

以上のように、本発明の一態様の営業支援装置は、演算部と、記憶部と、を有し、記憶部は、商談の対象である商材（例えばデジタルソリューション）と、商談において行われるべき複数の営業活動（営業アクション）の内容と、それぞれの営業活動において想定される結果ごとの商材と顧客との適合度（マッチ度）への影響量（例えば、結果別マッチ度増減値１２３ｄ）と、を対応付ける営業活動情報（例えば営業アクション情報テーブル１２３）を保持し、適合度に基づいて商談の継続の可否を判断するための基準を含む判断基準情報（例えば判断基準情報テーブル１２５）を保持し、顧客との商談において行った営業活動の結果を示す商談進捗情報（例えば商談進捗情報テーブル１２４）を保持し、演算部は、営業活動情報及び商談進捗情報に基づいて、顧客との商談において行った１以上の営業活動の結果に対応する適合度への影響量を集計し（例えばステップＳ５におけるマッチ度の算出）、集計された影響量に基づいて計算された適合度と、判断基準情報と、に基づいて、顧客との商談の継続の可否を判定し、判定の結果を出力する（例えばステップＳ６）。これによって、商材と顧客との適合の程度に基づいて、商談の継続可否を提示することで、効率的な営業活動を支援することができる。

ここで、演算部は、集計された影響量に基づいて計算された適合度を出力し、商談において行われるべき複数の営業活動のうち、まだ行っていない１以上の営業活動を、推奨営業活動（例えば図１６に示すお勧め営業アクション）として出力してもよい。このとき、演算部は、商談において行われるべき複数の営業活動のうち、適合度への影響量の大きさが上位である１以上の営業活動を、推奨営業活動として出力してもよい。これによって、適合度への影響が大きい営業活動が優先的に提示され、効率的な営業活動が支援される。

また、演算部は、営業活動情報及び商談進捗情報に基づいて、商談において行われるべき複数の営業活動のうち、まだ行っていない全ての営業活動の適合度への影響量から、まだ行っていない全ての営業活動を行った場合に適合度がとりうる最大値（例えば図９の値９ｃ）及び最小値（例えば値９ｄ）を計算し、集計された影響量に基づいて計算された適合度と、適合度がとりうる最大値及び最小値と、適合度に基づいて商談の継続の可否を判断するための基準と、の関係を示す情報を出力してもよい。このとき、適合度に基づいて商談の継続の可否を判断するための基準は、適合度の閾値（例えばマッチ度閾値１２５ｅ）を含み、演算部は、集計された影響量に基づいて計算された適合度と、適合度がとりうる最大値及び最小値と、の少なくともいずれかと適合度の閾値との関係に基づいて、顧客との商談の継続の可否を判定してもよい。これによって、例えば商談が成立しないリスクをどの程度許容するかといった基準に応じて柔軟な継続可否の判定をすることができる。

また、記憶部は、商材を提供するためのリソースの確保可能性を示す情報を含むリソース情報（例えばエンジニアリングリソース情報テーブル１２６）をさらに保持し、演算部は、リソース情報に基づいて、商材を提供するためのリソースの確保可能性を示す情報を出力してもよい。このとき、リソース情報は、リソースの単価を示す情報を含み、演算部は、商談において想定される受注金額の規模と、リソース情報とに基づいて、経済合理性の観点で投入可能なリソース量（例えば損益分岐点１５ｅ）と商材を提供するために必要なリソース量との関係を示す情報（例えば図１９の領域１９ａに示すような情報）を出力してもよい。また、演算部は、適合度及び判断基準情報に基づいて顧客との商談の継続の可否を判定した結果を出力した後、リソースを確認することを示す情報が入力された場合に、リソース情報に基づいて、商材を提供するためのリソースの確保可能性を示す情報を出力してもよい。これは、例えば継続判断入力Ｆ１０においてリソース確認が選択された場合の処理に相当する。これによって、実際に顧客に提案することができるかどうかの判断が支援される。

また、商材は、顧客の課題を解決するためのデジタルソリューションであり、リソースは、デジタルソリューションを提供するためのエンジニアリングリソースであり、リソースの確保可能性を示す情報は、エンジニアリングリソースの空き状況を示す情報（例えばリソース空き状況１２６ｄ）であってもよい。これによって、デジタルソリューションの営業活動が支援される。

また、判断基準情報は、商談の進捗度に基づいて商談の継続の可否を判断するための基準（例えば閾値１２５ｃ及び１２５ｄ等）を含み、演算部は、営業活動情報及び商談進捗情報に基づいて、顧客との商談の進捗度を計算し、進捗度、適合度及び判断基準情報に基づいて、顧客との商談の継続の可否を判定してもよい。このとき、演算部は、商談において行われるべき営業活動の数に対する、それらのうち既に行われた営業活動の数の比率を、進捗度として計算してもよい（例えば式（１））。あるいは、営業活動情報は、複数の営業活動の各々に対応する進捗の重みを示す値（例えば式（２）のｗｉ）を含み、商談において行われるべき営業活動の進捗の重みの合計に対する、それらのうち既に行われた営業活動の進捗の重みの合計の比率を、進捗度として計算してもよい（例えば式（２））。これによって、商談の進捗が適切に評価され、効率的な営業活動が支援される。

また、判断基準情報は、商談が開始されてからの経過期間及び商談において行われた営業活動の工数の少なくとも一方の所定の値である第１基準（例えばソリューション最低工数・期間１０ｃ）と、前記第１基準より大きい第２基準（例えばソリューション最大工数・期間１０ｅ）と、前記商談が開始されてからの経過期間及び商談において行われた営業活動の工数の少なくとも一方と進捗度とが満たすべき所定の関係（例えばソリューションごとの基準１０ａ）を示す情報と、を含み、演算部は、商談が開始されてからの経過期間及び商談において行われた営業活動の工数の少なくとも一方が第１基準に達していない場合、進捗度にかかわらず、商談の継続の可否の判定を保留し、商談が開始されてからの経過期間及び商談において行われた営業活動の工数の少なくとも一方が第２基準を超える場合、進捗度にかかわらず、商談を継続しないと判定し、商談が開始されてからの経過期間及び商談において行われた営業活動の工数の少なくとも一方が第１基準から第２基準までの範囲内である場合、商談が開始されてからの経過期間及び商談において行われた営業活動の工数の少なくとも一方と進捗度とが所定の関係を満たすか否かに基づいて、商談の継続の可否を判定してもよい。これによって、早すぎる段階での判断、及び、見込みのない商談が長期間継続すること等が防止される。

また、演算部は、商談の最終的な結果が入力されると（例えば商談結果取得ステップＳ１０）、進捗度及び適合度に基づいて行った商談の継続の可否の判断結果と、商談の最終的な結果との整合性が増すように、判断基準情報を更新してもよい（例えば判断基準学習ステップＳ１１）。これによって、適切な判断基準が得られ、商談継続可否の判断の精度が向上する。

なお、本発明は上述した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

上記の各構成、機能、処理部、処理手段等は、それらの一部または全部を、例えば集積回路で設計する等によってハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによってソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

また、図面には、実施例を説明するために必要と考えられる制御線及び情報線を示しており、必ずしも、本発明が適用された実際の製品に含まれる全ての制御線及び情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

１００ デジタルソリューションを提案する営業員
１０１ デジタルソリューション営業支援装置
１０２ 操作・表示端末
１０３ リソースＤＢ
１１０ 演算部
１１１ 情報検索部
１１２ 商談情報生成・更新部
１１３ 営業アクション選定部
１１４ 進捗度試算部
１１５ マッチ度試算部
１１６ 進捗度判断部
１１７ マッチ度判断部
１１８ リソース確保可否判断部
１１９ 判断基準更新部
１２０ 記憶部
１２１ 商談情報テーブル
１２２ ソリューション情報テーブル
１２３ 営業アクション情報テーブル
１２４ 商談進捗情報テーブル
１２５ 判断基準情報テーブル
１２６ エンジニアリングリソース情報テーブル
１３０ 入力操作部
１４０ 情報表示部
１５０ 通信部
１６０ ファイル保存領域

Claims (15)

1. 演算部と、記憶部と、を有する営業支援装置であって、
   前記記憶部は、
   商談の対象である商材と、前記商談において行われるべき複数の営業活動の内容と、それぞれの前記営業活動において想定される結果ごとの前記商材と顧客との適合度への影響量と、を対応付ける営業活動情報を保持し、
   前記適合度に基づいて前記商談の継続の可否を判断するための基準を含む判断基準情報を保持し、
   顧客との商談において行った前記営業活動の結果を示す商談進捗情報を保持し、
   前記演算部は、
   前記営業活動情報及び前記商談進捗情報に基づいて、前記顧客との商談において行った１以上の営業活動の結果に対応する前記適合度への影響量を集計し、
   集計された前記影響量に基づいて計算された前記適合度と、前記判断基準情報と、に基づいて、前記顧客との商談の継続の可否を判定し、
   前記判定の結果を出力することを特徴とする営業支援装置。
2. 請求項１に記載の営業支援装置であって、
   前記演算部は、
   前記集計された前記影響量に基づいて計算された前記適合度を出力し、
   前記商談において行われるべき複数の営業活動のうち、まだ行っていない１以上の営業活動を、推奨営業活動として出力することを特徴とする営業支援装置。
3. 請求項２に記載の営業支援装置であって、
   前記演算部は、前記商談において行われるべき複数の営業活動のうち、前記適合度への影響量の大きさが上位である１以上の営業活動を、前記推奨営業活動として出力することを特徴とする営業支援装置。
4. 請求項１に記載の営業支援装置であって、
   前記演算部は、
   前記営業活動情報及び前記商談進捗情報に基づいて、前記商談において行われるべき複数の営業活動のうち、まだ行っていない全ての営業活動の前記適合度への影響量から、前記まだ行っていない全ての営業活動を行った場合に前記適合度がとりうる最大値及び最小値を計算し、
   前記集計された影響量に基づいて計算された前記適合度と、前記適合度がとりうる最大値及び最小値と、前記適合度に基づいて前記商談の継続の可否を判断するための基準と、の関係を示す情報を出力することを特徴とする営業支援装置。
5. 請求項４に記載の営業支援装置であって、
   前記適合度に基づいて前記商談の継続の可否を判断するための基準は、前記適合度の閾値を含み、
   前記演算部は、前記集計された影響量に基づいて計算された前記適合度と、前記適合度がとりうる最大値及び最小値と、の少なくともいずれかと前記適合度の閾値との関係に基づいて、前記顧客との商談の継続の可否を判定することを特徴とする営業支援装置。
6. 請求項１に記載の営業支援装置であって、
   前記記憶部は、前記商材を提供するためのリソースの確保可能性を示す情報を含むリソース情報をさらに保持し、
   前記演算部は、前記リソース情報に基づいて、前記商材を提供するためのリソースの確保可能性を示す情報を出力することを特徴とする営業支援装置。
7. 請求項６に記載の営業支援装置であって、
   前記リソース情報は、前記リソースの単価を示す情報を含み、
   前記演算部は、前記商談において想定される受注金額の規模と、前記リソース情報とに基づいて、経済合理性の観点で投入可能なリソース量と前記商材を提供するために必要なリソース量との関係を示す情報を出力することを特徴とする営業支援装置。
8. 請求項６に記載の営業支援装置であって、
   前記演算部は、前記適合度及び前記判断基準情報に基づいて前記顧客との商談の継続の可否を判定した結果を出力した後、前記リソースを確認することを示す情報が入力された場合に、前記リソース情報に基づいて、前記商材を提供するためのリソースの確保可能性を示す情報を出力することを特徴とする営業支援装置。
9. 請求項６に記載の営業支援装置であって、
   前記商材は、前記顧客の課題を解決するためのデジタルソリューションであり、
   前記リソースは、前記デジタルソリューションを提供するためのエンジニアリングリソースであり、
   前記リソースの確保可能性を示す情報は、前記エンジニアリングリソースの空き状況を示す情報であることを特徴とする営業支援装置。
10. 請求項１に記載の営業支援装置であって、
    前記判断基準情報は、前記商談の進捗度に基づいて前記商談の継続の可否を判断するための基準を含み、
    前記演算部は、
    前記営業活動情報及び前記商談進捗情報に基づいて、前記顧客との商談の進捗度を計算し、
    前記進捗度、前記適合度及び前記判断基準情報に基づいて、前記顧客との商談の継続の可否を判定することを特徴とする営業支援装置。
11. 請求項１０に記載の営業支援装置であって、
    前記演算部は、前記商談において行われるべき前記営業活動の数に対する、それらのうち既に行われた営業活動の数の比率を、前記進捗度として計算することを特徴とする営業支援装置。
12. 請求項１０に記載の営業支援装置であって、
    前記営業活動情報は、前記複数の営業活動の各々に対応する進捗の重みを示す値を含み、
    前記商談において行われるべき前記営業活動の前記進捗の重みの合計に対する、それらのうち既に行われた営業活動の前記進捗の重みの合計の比率を、前記進捗度として計算することを特徴とする営業支援装置。
13. 請求項１０に記載の営業支援装置であって、
    前記判断基準情報は、前記商談が開始されてからの経過期間及び前記商談において行われた営業活動の工数の少なくとも一方の所定の値である第１基準と、前記第１基準より大きい第２基準と、前記商談が開始されてからの経過期間及び前記商談において行われた営業活動の工数の少なくとも一方と前記進捗度とが満たすべき所定の関係を示す情報と、を含み、
    前記演算部は、
    前記商談が開始されてからの経過期間及び前記商談において行われた営業活動の工数の少なくとも一方が前記第１基準に達していない場合、前記進捗度にかかわらず、前記商談の継続の可否の判定を保留し、
    前記商談が開始されてからの経過期間及び前記商談において行われた営業活動の工数の少なくとも一方が前記第２基準を超える場合、前記進捗度にかかわらず、前記商談を継続しないと判定し、
    前記商談が開始されてからの経過期間及び前記商談において行われた営業活動の工数の少なくとも一方が前記第１基準から前記第２基準までの範囲内である場合、前記商談が開始されてからの経過期間及び前記商談において行われた営業活動の工数の少なくとも一方と前記進捗度とが前記所定の関係を満たすか否かに基づいて、前記商談の継続の可否を判定することを特徴とする営業支援装置。
14. 請求項１０に記載の営業支援装置であって、
    前記演算部は、前記商談の最終的な結果が入力されると、前記進捗度及び前記適合度に基づいて行った前記商談の継続の可否の判断結果と、前記商談の最終的な結果との整合性が増すように、前記判断基準情報を更新することを特徴とする営業支援装置。
15. 演算部と、記憶部と、を有する計算機システムが実行する営業支援方法であって、
    前記記憶部は、
    商談の対象である商材と、前記商談において行われるべき複数の営業活動の内容と、それぞれの前記営業活動において想定される結果ごとの前記商材と顧客との適合度への影響量と、を対応付ける営業活動情報を保持し、
    前記適合度に基づいて前記商談の継続の可否を判断するための基準を含む判断基準情報を保持し、
    顧客との商談において行った前記営業活動の結果を示す商談進捗情報を保持し、
    前記営業支援方法は、
    前記演算部が、前記営業活動情報及び前記商談進捗情報に基づいて、前記顧客との商談において行った１以上の営業活動の結果に対応する前記適合度への影響量を集計する手順と、
    前記演算部が、集計された前記影響量に基づいて計算された前記適合度と、前記判断基準情報と、に基づいて、前記顧客との商談の継続の可否を判定する手順と、
    前記演算部が、前記判定の結果を出力する手順と、を含むことを特徴とする営業支援方法。
    

Images