(57)【要約】  【課題】  システムの利用者が過去の案件活動に参加した有識者とコンタクトのない場合にも、利用者から有識者への人脈を提示する。  【解決手段】  サーバ計算機３０の案件情報ＤＢ４０は、案件参加者の識別子を含む案件情報を格納する。個人情報ＤＢ４１は、各組織構成員について複数の個人属性情報を格納する。人脈検索部３１２は、クライアント端末１０を介する利用者の検索要求に応答し、検索条件に合致する案件情報を検索してその中の案件参加者を有識者として抽出し、抽出された有識者の各々と利用者について個人情報ＤＢ４１を検索し、利用者と少なくとも１つの共通の属性情報をもつ有識者を抽出し、表示のためにクライアント端末１０へ送信する。【選択図】  図１
2007004504.tif 000002
【特許請求の範囲】
【請求項１】
組織の構成員に関する人脈情報を提供することによって組織活動を支援するシステムにおいて、
案件キーワードと案件参加者の構成員識別子とを含む案件情報を格納する案件情報データベースと、
各構成員について複数の個人属性情報を格納する個人情報データベースと、
入力された利用者の構成員識別子と前記案件キーワードとを含む検索条件の検索要求に応答して前記案件情報データベースを検索し、指定された案件キーワードに該当する案件から前記案件参加者を有識者として抽出する手段と、
前記有識者の各々と前記利用者について前記個人情報データベースを検索し、前記利用者と少なくとも１つの共通の属性情報をもつ有識者を抽出する手段と、
抽出された前記有識者についての情報を前記利用者の端末に表示させる手段とを有することを特徴とする組織活動支援システム。
【請求項２】
前記の共通の属性情報をもつ有識者が見つからない場合に、さらに前記個人情報データベースを検索して前記利用者と少なくとも１つの共通の属性情報をもち、かつ前記有識者と少なくとも１つの共通の属性情報をもつ構成員を人脈候補として抽出する手段を有し、
前記表示させる手段は、抽出された前記有識者についての情報に加えて、抽出された前記人脈候補についての情報を表示させることを特徴とする請求項１に記載の組織活動支援システム。
【請求項３】
さらに、第１の構成員と第２の構成員とのつながりである各ルートについて構成員間のコミュニケーションの強さを示す数値を格納するルート利用状況データベースと、
前記利用者と抽出された前記構成員との間のルートについて前記ルート利用状況データベースを参照し、各ルートのつながりの強さを示す人脈ポイントを計算することを特徴とする請求項１又は２に記載の組織活動支援システム。
【請求項４】
組織の構成員に関する人脈情報を提供することによって組織活動を支援する方法において、
案件キーワードと案件参加者の構成員識別子とを含む案件情報を案件情報データベースに格納するステップと、
各構成員について複数の個人属性情報を個人情報データベースに格納するステップと、
入力された利用者の構成員識別子と前記案件キーワードとを含む検索条件の検索要求に応答して前記案件情報データベースを検索し、指定された案件キーワードに該当する案件から前記案件参加者を有識者として抽出するステップと、
前記有識者の各々と前記利用者について前記個人情報データベースを検索し、前記利用者と少なくとも１つの共通の属性情報をもつ有識者を抽出するステップと、
抽出された前記有識者についての情報を前記利用者の端末に表示させるステップとを有することを特徴とする組織活動支援方法。
【請求項５】
前記の共通の属性情報をもつ有識者が見つからない場合に、さらに前記個人情報データベースを検索して前記利用者と少なくとも１つの共通の属性情報をもち、かつ前記有識者と少なくとも１つの共通の属性情報をもつ構成員を人脈候補として抽出するステップを有し、
前記表示させるステップは、抽出された前記有識者についての情報に加えて、抽出された前記人脈候補についての情報を表示させることを特徴とする請求項４に記載の組織活動支援方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、組織における構成員の活動を支援する技術に係わり、特に、組織の構成員についての人脈情報を提供することによって組織活動を支援する技術に関する。
【背景技術】
【０００２】
従来の営業支援技術として、特許文献１がある。本従来技術は、過去に行われた営業活動に関する情報をデータベースとして保持し、それに対し営業担当者が求める営業活動情報を保持していると思われる営業活動経験者（有識者）を検索し、その中から営業担当者と直接的若しくは間接的に営業案件を共にしたことのある有識者を抽出し、その有識者との情報交換・連絡の容易性を数値化し営業担当者に提供する技術が開示されている。より具体的には、営業活動案件ごとにその内容をデータベース化し、それに対し営業担当者が特定のテーマの案件と同一テーマの過去案件を検索し、該当過去案件の参加者（有識者）から検索者と直接的若しくは間接的に営業案件を共にしたことのある有識者を抽出する。その際に有識者の保有する情報の有効性と営業担当者と有識者の関係の深さを数値化することによって、営業担当者にとって新規の案件を扱う場合に、最も有効な情報を保有しているであろう人物から、最も連絡がとりやすい人脈で担当営業案件についての事前知識を得ることが可能となり、スムーズに営業活動が行うことができる。
【０００３】
【特許文献１】特開２００３−２１６７９９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、上記のような過去に行った営業案件のデータベースを基に人脈を検索する技術において、過去の営業活動を基に作成されたデータベースだけを基に有識者を検索しようとすると、このデータベースは頻繁に変化が生じる社内状況や人脈を反映していないため、出力される営業担当者と有識者との結びつきの数値が必ずしも現在の社内状況を正確に反映していない、との問題がある。
【０００５】
さらにこの技術を利用したい営業担当者は、これまで営業活動の経験が少ない、若しくは人脈に大きな広がりを持たない人物である可能性が高いため、この従来技術を利用して直接的又は間接的に面識のある有識者を検索するという方法の支援では不充分であり、必要な情報を得ることができないという問題がある。
【課題を解決するための手段】
【０００６】
本発明において、案件参加者の識別子を含む案件情報をデータベースに格納し、各組織構成員について複数の個人属性情報をデータベースに格納する。本発明は、利用者の検索要求に応答し、検索条件に合致する案件情報を検索してその中の案件参加者を有識者として抽出し、抽出された有識者の各々と利用者について個人情報データベースを検索し、利用者と少なくとも１つの共通の属性情報をもつ有識者を抽出する。
【発明の効果】
【０００７】
各構成員にとって未知であった人物に関する情報を、システムが保持している個人情報データベースから抽出し利用者に提供することが可能である。
【発明を実施するための最良の形態】
【０００８】
まず、本発明の実施形態の適用先について説明する。ここで具体化されている本発明適用先には、営業活動を行う企業、機関であり、広域エリアに向けた営業支援機能（見込み案件管理とそれに伴う人脈管理）への利用が挙げられる。例えば社内の案件紹介を推進するにあたって、ある人物が保有している社内外関係者の人脈（推進先顧客、利害関係顧客、社内組織関係者）の抽出を行うことが可能である。
【０００９】
本発明の実施形態について、フローチャートと図面を用いて説明する。本実施形態は、情報システムを顧客に提供している会社とその下の部署や部門、そこに属する人物（営業担当者等）が本実施形態の営業支援システムを利用して、今後の営業活動に有効な営業支援情報を検索するという状況を例示して説明する。しかし本発明はそれに限定されるものではなく、ＮＰＯなどのボランティア活動や公共団体など、組織活動を行う際の人脈情報の検索が行われるいずれの状況にも適用され得る。
【００１０】
まず、実施例の営業支援システムの概略構成図を図１に示す。システムは、サーバ計算機３０、クライアント端末１０−１，１０−２，１０−３、およびこれら装置間を接続するネットワーク２０から構成される。ネットワーク２０は、組織内社員が属する組織内のＬＡＮや組織を超えた企業全体を結ぶインターネットや専用線等である。
【００１１】
クライアント端末１０は、パーソナルコンピュータなどのコンピュータであり、入力装置および表示装置を備える。営業担当者はクライアント端末１０からサーバ計算機３０にアクセスし、営業活動を行う上で情報提供を求める案件に関するキーワードを入力し、その案件に携わったことのある人物を検索する。
【００１２】
サーバ計算機３０は、処理装置３１とこれに接続される記憶装置とを有する。処理装置３１は、ＣＰＵ、メモリおよびネットワーク２０を介するクライアント端末１０との通信を制御する通信制御部を備える。メモリは、案件管理部３１０、個人情報管理部３１１、人脈検索部３１２および係数算出部３１３の各プログラムを格納する。ＣＰＵは、メモリからこれらのプログラムを読み出して実行する。記憶装置は、案件情報データベース（以下ＤＢ）４０、個人情報ＤＢ４１、人脈ＤＢ４２、ルート利用状況ＤＢ４３、レスポンスポイントＤＢ４４、連絡回数ＤＢ４５、および共同作業期間ＤＢ４６を格納する。なお、図示していないが、サーバ計算機３０は、これ以外のＤＢとして過去の案件ごとの報告書、提案書、販売促進用資料などに関するＤＢを保持していてもよい。
【００１３】
更に、クライアント端末１０は、一般的に利用されているパーソナルコンピュータだけではなく、携帯電話機、ＰＤＡ、ゲーム機、ファックス機、デジタル機器等、ネットワーク接続可能ないずれのコンピュータチップを備える機器でもよい。またネットワーク２０に関しては、インターネットのほかに、ＷＡＮ（Wide Area Network）、ＡＴＭ回線、パソコン通信回線、ＬＡＮ、無線ネットワークなど様々なネットワークを採用することもできる。また、仮想専用ネットワーク技術を用いれば、インターネットにおいても通信に関する高い機密性を効率よく実現できる。
【００１４】
図２は、本システムの概略プロセスを説明する図である。サーバ計算機３０の案件情報ＤＢ４０は、過去の案件について、検索のための案件キーワードや参加者の社員ＩＤなどを格納する。個人情報ＤＢ４１は、各社員の個人属性情報を格納する。人脈ＤＢ４２は、社内の職位を通じた人脈の強さを示す情報を格納する。ルート利用状況ＤＢ４３は、ある社員と他の社員との間の関係をルートとしてとらえ、各ルートについて職位以外でのつながりの強さを示す情報を格納する。レスポンスポイントＤＢ４４、連絡回数ＤＢ４５および共同作業期間ＤＢ４６は、個人情報ＤＢ４１およびルート利用状況ＤＢ４３の数値を規格化するために用いられる。
【００１５】
サーバ計算機３０の案件管理部３１０は、案件情報ＤＢ４０の情報を登録し、更新する。個人情報管理部３１１は、個人情報ＤＢ４１の情報を登録し、更新する。係数算出部３１３は、人脈ＤＢ４２に格納される人脈係数を計算して人脈ＤＢ４２に格納する。
【００１６】
クライアント端末１０がサーバ計算機３０へ利用者識別子と検索条件を送信し、人脈検索を要求すると、人脈検索部３１２は、案件情報ＤＢ４０と個人情報ＤＢ４１を検索し、案件情報の中から案件参加者を有識者として抽出し、利用者と有識者について個人情報ＤＢ４１を検索し、各社員の個人属性情報を取得する。人脈検索部３１２は、共通の個人属性を通じたつながりの有無を判定する。利用者と有識者との間につながりがなければ、人脈検索部３１２は、さらに個人情報ＤＢ４１を検索し、利用者と有識者との間に介在し、共通属性を通じてつながりをもつ人脈候補を探索する。係数算出部３１３は、人脈ＤＢ４２およびルート利用状況ＤＢ４３を参照し、利用者、人脈候補、有識者の間の各ルートのつながりの強さを示す人脈ポイントを計算する。人脈検索部３１２は、人脈ポイントの大きい順に有識者、人脈候補を配列したリストをクライアント端末１０へ送信し、クライアント端末１０がこのリストを表示する。
【００１７】
クライアント端末１０側の利用者は、このリストから有識者あるいは人脈を選択し、選択した有識者あるいは人脈となる社員から情報提供を受けることができる。利用者は、人脈検索のタイミングであるルートについてのつながりの強さを再評価し、サーバ計算機３０へ送信すると、サーバ計算機３０は、この情報をＤＢにフィードバックし、ルート利用状況ＤＢ４３などを更新する。
【００１８】
さらに本システムでは、新規案件を案件情報ＤＢ４０に登録したり、新しい社員を個人情報ＤＢ４１に登録するタイミングでルート利用状況ＤＢ４３に新しいルートを登録したり、その内容を最新状態に更新できるという特徴をもつ。この特徴により、その時々の人脈情報をより正確に反映した情報提供が可能になる。つまり、本システムの目的は最も有効な情報を保有している有識者から営業案件に関する情報を事前に入手する、もしくは直接支援を要請するというものであるため、検索結果が常に現状の社内状況の変化に対応している必要がある。また係数算出部３１３は、常に最新状態のＤＢから人脈係数を算出する。これによって各人脈がどれだけ有力な情報を確実に提供可能かという観点から、利用者が求める情報を提供するに最も相応しい人脈を順に表示可能になる。
【００１９】
図３は、案件情報ＤＢ４０のデータ構成例を示す図である。案件情報ＤＢ４０に書き込まれるデータは、過去に行われた営業案件に関する情報であり、事前の定義に基づいて命名された案件キーワード４００、登録された案件名称４０１、案件の開始・終了時期４０２と、それに参加した組織の構成員あるいは社員の社員名４０３、案件に参加した社員の社員ＩＤ（識別子）４０４、案件参加者が案件終了後互いの案件への貢献度を評価し、登録した案件サポートポイント４０５、その案件の売り込み先顧客の顧客名４０６と、その売り込み先の成約ステータス４０７、案件成約率４０８等の情報を保持している。案件キーワード４００は、その案件が属する技術の分類やシステムを示すキーワードである。案件成約率４０８は、成約顧客数／売込先顧客総数によって計算される。
【００２０】
図４は、個人情報ＤＢ４１のデータ構成例を示す図である。この個人情報ＤＢ４１には、企業に属している社員の社員ＩＤ４０４、社員名４０３、その社員へ連絡手段（メール、電話、面会）で利用可能な手段数を当該社員が０〜３の数値で登録した連絡手段ポイント４１２、その社員が過去に参加したことのある参加案件４１３、登録者によりその案件のキーワードとして登録を指定されている案件キーワード４００、職位４１４、その社員の過去勤務先４１５、その社員が受信したメールの全体に対して1ヶ月以内にどれだけの割合でメールを返信したかを表すメール返信率４１６、各メール受信時刻から返信までの時間を測定しその数値を直近1ヶ月以内に受信した全メール分合算し、合計値を返信メール数で割った平均レスポンス時間４１７、それをレスポンスポイントＤＢ４４により変換したレスポンスポイント４１８、過去その社員が参加した案件の全ての成約率を案件数で割った成約率ポイント４１９、所属事業所４２３、所属部署４２４が保持されており、これら社員として保有しているデータの他に、出身の大学４２５や所属した研究室４２６、これらに加えて社員が社内外において所属する団体等を登録することも可能である。個人の受信メールに対する反応度を表す平均レスポンス時間４１７とレスポンスポイント４１８を総称してアクセスポイントと呼ぶ。
【００２１】
メール返信率４１６は、次式で計算される。
【００２２】
メール返信率４１６
＝受信メールに対する１ヶ月以内の返信メール数／1ヶ月以内の受信メール数
平均レスポンス時間４１７は、次式で計算される。
【００２３】
平均レスポンス時間４１７＝SMT／1ヶ月以内の返信メール数
MT…各メールについて、メール返信時刻―メール受信時刻
SMT…直近1ヶ月以内に受信した各メールのMT
図５は、人脈ＤＢ４２のデータ構成例を示す図である。このＤＢは、情報要求者４２０と情報提供者４２１の情報伝達力を社内職位別に定義した数値を保持する。ここでの考えは、「情報伝達性は社内職位によって変化する」というものであり、下位から直近の上位職位、若しくは同等職位間の情報伝達はスムーズに行われる可能性が高いという考えに基づいて初期値が定義されているが、この定義はシステム構築、メンテナンス時に、各社の思想に合わせて変更することが可能である。実施例としては「部長⇒主任」の情報伝達性を「８」と定義しているが、この定義し、若しくは役職は各組織の営業システム管理者により定義し、変更することが可能となる。
【００２４】
図６は、ルート利用状況ＤＢ４３のデータ構成例を示す図である。このＤＢは、本システムの利用状況を反映して変化する社員間の繋がり・連絡状況を反映する数値を保持している。社員ＩＤ４０４をもつある社員とその社員が過去にメールを送ったことがある相手社員ＩＤ４３０をもつ他の社員との繋がりをルートとみなし、そのルートについて、連絡のとりやすさを示す情報伝達ポイント４３１、社員ＩＤ４０４をもつ社員と相手社員ＩＤ４３０をもつ社員との間の連絡回数をカウントした連絡回数４５０、連絡回数４５０を連絡回数ＤＢ４５によりポイント化した連絡回数ポイント４５１、社員ＩＤ４０４をもつ社員が相手社員ＩＤをもつ社員と共同案件に携わったことがあればその共同作業期間を記録した共同作業期間４６０、および共同作業期間４６０を共同作業期間ＤＢ４６でポイント化した共同作業期間ポイント４６１等の情報を保持しているＤＢである。情報伝達ポイント４３１は、本実施例では１０点満点で評価される。情報伝達ポイント４３１は、そのルートのコンタクトに基づいて評価し直され、更新される。
【００２５】
図７は、レスポンスポイントＤＢ４４のデータ構成例を示す図である。このＤＢは、社員個人に関する情報伝達度の高さを表すレスポンスポイント４１８を算出する際に利用されるＤＢである。このＤＢは、利用者から受信した全メールに対する返信までの時間を合算した数値を、返信メール数で割った平均レスポンス時間４１７をポイントに変換する際に使用されるＤＢである。このレスポンスポイント４１８は、各人物の情報提供度合の良さとして判断するために利用される。
【００２６】
図８は、連絡回数ＤＢ４５のデータ構成例を示す図である。連絡回数ＤＢ４５は、ルート利用状況ＤＢ４３の連絡回数ポイント４５１を算出するために使用されるＤＢである。これは社員ＩＤ４０４をもつ社員から相手社員ＩＤ４３０をもつ社員への連絡回数４５０を規格化する数値であり、この社員ＩＤの人物から相手社員ＩＤの人物への繋がりの強さを表す数値として使用される。
【００２７】
図９は、共同作業期間ＤＢ４６のデータ構成例を示す図である。共同作業期間ＤＢ４６は、ルート利用状況ＤＢ４３の共同作業期間ポイント４６１を算出するために使用されるＤＢである。このＤＢを使用し、社員ＩＤ４０４の人物と相手社員ＩＤ４３０の人物が共に登録されている全案件の開始から終了までの期間を合算した数値である共同作業期間４６０を、共同作業期間ＤＢ４６で定義した数値に基づき共同作業期間ポイント４６１として算出する。
【００２８】
図１０は、サーバ計算機３０が実行するデータベース登録と人脈検索処理の手順を示すフローチャートである。まず案件管理部３１０は、案件参加者がクライアント端末１０を介して入力した案件情報とその評価に関する情報を受信し、案件情報ＤＢ４０に登録する（ステップ１００）。なお個人情報ＤＢ４１、人脈ＤＢ４２、ルート利用状況ＤＢ４３、レスポンスポイントＤＢ４４、連絡回数ＤＢ４５および共同作業期間ＤＢ４６は、事前に定義され、登録されている必要があり、評価の変更があったときには更新される。個人情報管理部３１１は、クライアント端末１０から入力される個人情報を個人情報ＤＢ４１に登録し、また更新要求により個人情報ＤＢ４１を更新する。
【００２９】
次に人脈検索部３１２は、利用者がクライアント端末１０を介して入力した検索条件を受け付ける（ステップ１０１）。検索条件は、案件キーワードと介在人数（人脈数）の条件を含む。介在人数は、利用者と有識者との間に何人の人間が介在することを許容するかを示す人数である。利用者が選択する案件キーワードは、案件名称の大分類であり、案件別の企業名等固有名詞を省いて定義したカテゴリーに分けて登録者が案件登録時に指定した用語群である。また介在人数の上限は事前にシステム管理者により規定され、記憶されている。例えば、案件キーワードが「ＣＲＭ」であるとすれば、人脈検索部３１２は、案件情報ＤＢ４０から「ＣＲＭ」という案件キーワード４００で登録された「ＣＲＭ」、「営業支援」といった語を含む案件を抽出する。
【００３０】
次に人脈検索部３１２は、案件キーワード４００に合致する案件情報を抽出する（ステップ１０２）。人脈検索部３１２は、抽出された案件に含まれる社員ＩＤ４０４をもつ人物（案件の参加者）について、個人情報ＤＢ４１を検索し、各参加者の共通属性を取得する（ステップ１０３）。利用者以外の案件参加者は有識者とみなされる。利用者以外の案件参加者を有識者として定義するのは、彼らが案件についての知識を有する者であり、利用者が求めている情報を保有している可能性のある人物であるとの認識に基づく。
【００３１】
共通属性検索の手順としては、個人情報ＤＢ４１から利用者の過去の参加案件４１３、過去勤務先４１５、所属事業所４２３、所属部署４２４、大学４２５および研究室４２６を抽出し、さらに案件の参加者の個人情報を抽出してその中の上記項目のデータを突合させ、合致する少なくとも１つの項目が共通属性である。
【００３２】
少なくとも１つの共通属性をもつ案件参加者があれば（ステップ１０４Ｙｅｓ）、係数算出部３１３は、そのような共通属性をもつ各案件参加者について、人脈ＤＢ４２、ルート利用状況ＤＢ４３、レスポンスポイントＤＢ４４、連絡回数ＤＢ４５および共同作業期間ＤＢ４６の情報を基に、人脈ポイントを算出する（ステップ１０９）。人脈ポイントは、有識者からどれだけ円滑に情報が伝達されるか、有識者がどれだけ有力な情報を持っているかという指標であり、具体的な算出方法に関しては以下の段落で説明する。
【００３３】
利用者と有識者の間に直接共通するような属性が存在しない場合（ステップ１０４Ｎｏ）には、人脈検索部３１２は、利用者と有識者を結ぶ人脈を検索する（ステップ１０５）。
【００３４】
人脈検索の手順は、まず初めに個人情報ＤＢ４１から有識者の個人情報を取得し、有識者の参加案件４１３、過去勤務先４１５、所属事業所４２３、所属部署４２４、大学４２５および研究室４２６と共通属性をもつ人物を抽出する。例えば、有識者の大学名としてＡ大学という属性があれば、社内でＡ大学出身者を抽出する。同様にその他属性についても、有識者と共通する個人属性を持つ社員を抽出してゆく。
【００３５】
この際、膨大な個人情報についての検索を行うが、情報を構造的に管理することにより、効率的な検索が可能となる。つまり、情報を階層ごとに管理することによって、検索時ある階層で該当しない場合は、それ以下の階層に対して検索を行わず、次項目に検索を進めることが可能になる。つまり、ある階層の情報の検索の結果として、該当する場合に、次にそれ以下の階層の情報についてさらに検索を行うものである。例えば、組織についての事業部、部署、大学名に属する学部や学科等の情報は、下位層で名称が一致しても上位層が異なれば別組織と見なせるため、構造化されたＤＢの上位階から検索を行い、一致しない場合は、下位層に対する一致検索を省略することが可能となる。ここで、階層化された情報には、ＸＭＬ等いわゆる構造化文書で規定される情報も含まれる。
【００３６】
このようにして抽出された有識者と共通の属性を持つ各人物の個人情報を個人情報ＤＢ４１から抽出し、利用者と共通の個人属性を保持している人物を抽出する。つまりこの人物こそが、検索者と有識者の両者に対して共通の個人属性を持つ人物であり、検索者と利用者を結ぶことが可能な人脈候補であると考えられる。
【００３７】
このような人物が存在した場合（ステップ１０６Ｙｅｓ）には、係数算出部３１３は、この人物を人脈として認識し、利用者、人脈、有識者の各人の関係を数値化した人脈ポイントを算出する（ステップ１０９）。
【００３８】
このような人物が抽出できなかった場合（ステップ１０６Ｎｏ）には、人脈検索部３１２は、先程抽出された有識者と共通属性を持つ人物を人脈候補とし、彼らの個人属性と共通する個人属性を持つ人物の個人情報を個人情報ＤＢ４１から抽出する（ステップ１０７）。そして、人脈検索部３１２は、新たな各人脈候補の参加案件４１３、過去勤務先４１５、所属事業所４２３、所属部署４２４、大学４２５および研究室４２６の中から利用者と共通する属性を持つ人物がいれば（ステップ１０８Ｙｅｓ）、その人物を新たな人脈として抽出し、係数算出部３１３が、利用者、人脈候補、有識者各個人間の結びつきを人脈ポイントとして算出する（ステップ１０９）。ステップ１０６，１０７を、人脈候補が利用者の指定した介在人数になるまで繰り返すことによって、最終的に利用者と有識者を結ぶ人脈が抽出され、これを本発明において利用者が求める人脈と呼ぶ。なお、人脈候補の検索回数あるいは人脈の介在人数については利用者が画面を介して指定することが可能である。
【００３９】
次に人脈検索部３１２は、得られた人脈候補と有識者の社員名４０３などの個人情報を人脈ポイントの大きい順に利用者のクライアント端末１０に表示する（ステップ１１０）。次に人脈検索部３１２は、クライアント端末１０を介する利用者、人脈候補および有識者の間の情報伝達ポイント４３１についての再評価を受け付け（ステップ１１１）、その利用者評価によりルート利用状況ＤＢ４３の関連するルートの情報伝達ポイント４３１を更新する（ステップ１１２）。
【００４０】
図１１は、利用者と有識者との間に介在する人脈候補を抽出する処理の具体例について説明する図である。利用者αの保有属性をａ，ｂ，ｃ，ｄとする。図１１は、与えられた案件キーワードによって案件情報ＤＢ４０を検索した結果、有識者Ａ，Ｂ又はＣが抽出された場合について説明している。有識者Ａの場合には、有識者Ａが利用者αと共通属性ａをもつため、さらに両者の間に介在する人脈候補を探索する必要がない。有識者Ｂの場合には、有識者Ｂが利用者αと共通属性をもたないため、有識者Ｂと共通属性ｊをもつ人脈候補Ｄが抽出された。人脈候補Ｄは、利用者αと共通属性ａをもつため、利用者α−人脈候補Ｄ−有識者Ｂのつながりをもつ人脈ルートが見つかった。利用者αと人脈候補Ｄとの間の人脈ポイント、および人脈候補Ｄと有識者Ｂとの間の人脈ポイント、さらに利用者αと有識者Ｂとの間の人脈ポイントを計算できる。有識者Ｃの場合には、有識者Ｃが利用者αと共通属性をもたないため、有識者Ｃと共通属性ｚをもつ人脈候補Ｅが抽出された。しかし人脈候補Ｅが利用者αと共通属性をもたないため、さらに人脈候補Ｅと共通属性ｆをもつ人脈候補Ｆが抽出された。人脈候補Ｆは、利用者αと共通属性ｃをもつため、利用者α−人脈候補Ｆ−人脈候補Ｅ−有識者Ｃのつながりをもつ人脈ルートが見つかった。このようにして最大で指定された介在人数までの共通属性でつながった人脈候補を抽出できる。
【００４１】
本発明では、利用者、有識者、人脈同士の関係を情報伝達性、情報有効性という概念を数値化したＤＢ上の数値を基に、検索者がどの有識者、人脈を通じて情報を収集することが最も効率的かを示す人脈ポイントを算出し、順位付けし、表示することを特徴とする。本実施例では、各人脈の繋がりの強さに応じて最大で１００点満点となるような数値を算出し、算出される数値が１００点に近いほど、その人脈が、利用者の望む情報を提供する能力が高いということを示すものとする。ただし、ここで示した各得点の算出方法やその項目は一例であってこれに限定されるものではない。
【００４２】
ここでの情報伝達性とは、各個人間のこれまでの情報交換、個人間の立場、共同作業期間に関する情報を基に、個人間に情報伝達がどれだけスムーズに行われるであろうかということを数値化したものである。この概念を数値化する際に利用されるのは、連絡手段ポイント４１２、メール返信率４１６、レスポンスポイント４１８、人脈係数４２２、情報伝達ポイント４３１、連絡回数ポイント４５１および共同作業期間ポイント４６１である。さらに情報有効性とは、有識者の保有している情報、及び本システムの利用者、人脈、有識者の各個人間でやりとりされる情報がどれだけ有効であるか、つまり成約率の高い案件、若しくは互いの情報提供が活発に行われた案件に関する情報提供が行われるであろう可能性を数値化するものであり、この概念を数値化する際に利用されるのは、案件サポートポイント４０５と成約率ポイント４１９である。
【００４３】
以上の情報伝達性と情報有効性という指標に関して、案件情報ＤＢ４０、個人情報ＤＢ４１、人脈ＤＢ４２、ルート利用状況ＤＢ４３、レスポンスポイントＤＢ４４、連絡回数ＤＢ４５および共同作業期間ＤＢ４６に蓄積された数値データを用いて、以下の方法で各人脈に対する数値化を行う。
【００４４】
まず、人脈と有識者それぞれが個人としてどれだけ有力な情報を保持しているか、どれだけ情報有効性があるかという指標について説明する。情報の有効性を表す案件サポートポイント４０５とは、これまで参加した案件において、どれだけその人物が案件への情報提供、参加に貢献したかということをこれまで案件を共にした人物が評価したものである。このポイントは参加案件が終了後、ＤＢに登録されるタイミングで、案件参加メンバがアンケートにより各個人に対し０〜１５の１５段階評価で得点付けし、それを参加案件全てで合算し、参加案件総数で割った平均値である。このポイントが高い人物は、各案件に積極的に取り組み、有意な情報を提供したということになり、情報提供を行うに相応しい人物と判断する。
【００４５】
成約率ポイント４１９とは、これまで個人が参加した案件キーワードで抽出される案件の成約率を平均したポイントであり、この値が高いということはその人物が保持している案件情報が有力であることを表す。このポイントは０．０〜１．０の値をとり、案件終了後に案件情報ＤＢ４０に各売り込み先に対する成約ステータス（契約成立、契約不成立）４０７が登録され、その値を過去参加案件の案件キーワード４００ごとに平均したものである。なお、ここで記述される「平均」という言葉には、いわゆる相加平均、加重平均、相乗平均が含まれる。つまり、成約数の和を案件数で割って算出してもよいということである。
【００４６】
個人の情報伝達力を表す数値として使用される連絡手段ポイント４１２とは、各個人が連絡手段としていくつの手段を提供しているかということを表す数値であり、当該社員が個人情報としてメール、電話、面会について連絡可能な手段がいくつあるかで０〜３までの数値を登録する。この数値が大きい人物ほど、積極的な情報交換が可能であると見なす。
【００４７】
もう一つの情報伝達力判断指標は、アクセスポイントと呼ばれる指標であり、この指標には、個人のメール返信に関わるメール返信率４１６、平均レスポンス時間４１７およびレスポンスポイント４１８が含まれる。メール返信率４１６は、その個人がこれまでこのシステムを通じて受信したメールに対して、どの程度返信をしたかを０．０〜１．０という割合で算出したものであり、このポイントが高いほど質問に対して積極的に返信を行ったと判断される。平均レスポンス時間４１７とは、本システムで受信したメールに対しての返信までの時間を分で表したもので、この時間を受信メール数で割った平均値を基に、レスポンスポイントＤＢ４４でレスポンスポイント４１８として、１５、１３、１０、５、１、０に変換する。
【００４８】
個人間の情報伝達力を表す指標の一つとして挙げられるのが人脈係数４２２であり、この値は上記方法で抽出された各個人間の職位を基に、人脈ＤＢ４２で定義した０〜１０の値を利用するものである。このＤＢは、各社内職位の差異による情報伝達力を数値化したものであり、同等職位であれば情報の伝達が早い、下位から上位への情報提供は早いなど、様々な組織固有の思想に基づいて定義した数値を基に各個人間の情報伝達度を０〜１０までの数値で表す。
【００４９】
さらにより詳しい個人間の情報伝達力を示す数値として利用されるのが、ルート利用状況ＤＢ４３の情報伝達ポイント４３１、連絡回数ポイント４５１および共同作業期間ポイント４６１である。ここに蓄積される情報は、過去案件を共にした個人間でこのシステムを利用して連絡をとった際の履歴である。情報伝達ポイント４３１とは、基点とされる個人からその相手に対する連絡の取りやすさを１０、８，６，４，２，０の値で評価したもの、連絡回数ポイント４５１とは、連絡相手への過去の連絡回数４５０を連絡回数ＤＢ４５によりポイントに変換して１５、１０、８、６、４、２、０の値で評価したもの、共同作業期間ポイント４６１とは社員ＩＤ４０４の人物と、相手社員ＩＤ４３０の人物が共に参加した案件開始・終了期間４０２の合計を月数に変換した共同作業期間４６０を共同作業期間ＤＢ４６でポイントに変換した１０、８、６、４、２、０の値を保持している。つまり、これら指標の数値が高いということは、この個人間の連絡回数が多い、若しくは繋がりが深いことを表し、連絡が取りやすい関係であることを示す。
【００５０】
上述の指標を使用し、各ルートの情報有効性と情報伝達性を包含する人脈ポイントを１００点満点とする点数を算出する際の一例を示す。まず、個人の案件に関する情報有効性について、０〜１５までの案件サポートポイント４０５と、それら参加案件の平均成約率を０．０〜１．０で表した成約率ポイント４１９を掛け合わせた値を算出し、最低で０点、最高で１５点という重み付けをする。さらに、個人の情報伝達性について、メール、電話、直接面会という３つの連絡手段のうち、どの手段での連絡を受け付けているか、さらにその中の特にシステムで管理可能なメール返信率４１６（０．０〜１．０の値をとる）、レスポンスポイント４１８（１５、１３、１０、５、１、０）という３つの数値を掛け合わせる。この値については、最低０点、最高４５点という重み付けをしている。さらに、個人間の情報伝達力に対しても重み付けを行う。人脈係数４２２という値は、事前に定義された各個人の職位を元に、個人の社内での距離を判断すると共に、個人間の情報伝達の容易性を示したものであるとし、１０までの値を事前に定義し、ＤＢ登録する。この定義はシステム構築時に営業管理関連部署等によって設定される。さらに、情報伝達ポイント４３１は、情報発信者からみた連絡の取りやすさを案件終了後に１０までの数値で評価し、登録したものである。さらに連絡回数４５０についても連絡回数ポイント４５１に変換し、この値が多いほどこれまで頻繁に連絡をとったことがあり、その人物からの情報収集が容易であると判断する。共同作業期間４６０についても、３ヶ月を一つの単位として、その人物とどれだけの期間同じ案件に携わったことがあるかということについて共同作業期間ポイント４６１に置き換え、点数付けをする。
【００５１】
上記の人脈ポイント算出方法を式で表すと以下のとおりである。
【００５２】
人脈ポイント＝（A×S）＋（RS×M×R）＋（JK＋JD＋RK＋K）            （数１）
A…案件サポートポイント４０５
S…成約率ポイント４１９
RS…連絡手段ポイント４１２
M…メール返信率４１６
R…レスポンスポイント４１８
JK…人脈係数４２２
JD…情報伝達ポイント４３１
RK…連絡回数ポイント４５１
K…共同作業期間ポイント４６１
上記数式は、有識者の案件情報の有効性とその人物への連絡のとり易さ、ルート間の繋がりの深さという３つの指標において、それぞれが持つ値を総合して、最高値である１００に近い有識者までの人物ルートを最も有効な人脈と定義する数式であるということが分かる。ただしこの計算方法はあくまで一例であって、より単純化、より高度化された計算式を用いてもよい。
【００５３】
人脈ポイントをもとに人脈ルートの評価を行う場合は、例えば下記のようにルートの強度を示す人脈ルートポイントを定義して計算することで行うことができる。
【００５４】
Ｒｐ…人脈ルートポイント
Ｐ…人脈ポイント
人脈ポイントの添字の意味：
(r_y)…利用者ｒと有識者ｙを繋ぐ
(r_ki)…利用者ｒと人脈候補ｉを繋ぐ
(ki_kj)…人脈候補ｉと人脈候補ｊを繋ぐ
(ki_y)…人脈候補ｉと有識者ｙを繋ぐ
と定義する。ただし人脈ポイントを１００点満点とする。
【００５５】
利用者と有識者が直接繋がる場合の人脈ルートポイント
Ｒｐ＝Ｐ(r_y)    （数２）
利用者と有識者の間に人脈候補１の一人が必要な場合の人脈ルートポイント
Ｒｐ＝Ｐ(r_kl)×Ｐ(kl_y)／１００    （数３）
利用者と有識者の間に人脈候補１から人脈候補ｎまでｎ人が必要な場合の人脈ルートポイント
Ｒｐ＝Ｐ(r_kl)×Ｐ(k1_k2)×Ｐ(k2_k3)×…×Ｐ(kn-1_kn)×Ｐ(kn_y)／１００n    （数４）
これにより、人脈ルートポイント（Ｒｐ）が計算される。Ｒｐは、人脈ポイントが高く関係強い人々を少ない仲介で繋ぐルートほどポイントが高くなる傾向となる。
【００５６】
人脈検索部３１２は、上記方法で求められた各指標の数値を全て合算し、検索された各人脈について検索のタイミングでルート情報が更新されるＤＢを使用して、常に最新の人脈状態の数値に基づいた人脈ポイントを算出し、点数の高い順に画面表示する。なお、本実施の形態では、小数点については、最終的な算出数値について四捨五入し、整数値を算出し、クライアント端末１０に表示させる。
【００５７】
この数値を基に、利用者は有識者にアクセスを行う際に、組織内人脈を選択する指標を得ることが可能になる。
【図面の簡単な説明】
【００５８】
【図１】実施例の営業支援システムの構成図である。
【図２】システムの概略プロセスを説明する図である。
【図３】案件情報ＤＢのデータ構成例を示す図である。
【図４】個人情報ＤＢのデータ構成例を示す図である。
【図５】人脈ＤＢのデータ構成例を示す図である。
【図６】ルート利用状況ＤＢのデータ構成例を示す図である。
【図７】レスポンスポイントＤＢのデータ構成例を示す図である。
【図８】連絡回数ＤＢのデータ構成例を示す図である。
【図９】共同作業期間ＤＢのデータ構成例を示す図である。
【図１０】実施例の人脈検索処理の手順を示すフローチャートである。
【図１１】人脈候補を抽出する処理を説明する図である。
【符号の説明】
【００５９】
１０…クライアント端末、３０…サーバ計算機、３１２…人脈検索部、４０…案件情報ＤＢ、４１…個人情報ＤＢ、４２…人脈係数ＤＢ、４３…ルート利用状況ＤＢ、
【図１】
2007004504.tif 000003
【図２】
2007004504.tif 000004
【図３】
2007004504.tif 000005
【図４】
2007004504.tif 000006
【図５】
2007004504.tif 000007
【図６】
2007004504.tif 000008
【図７】
2007004504.tif 000009
【図８】
2007004504.tif 000010
【図９】
2007004504.tif 000011
【図１０】
2007004504.tif 000012
【図１１】
2007004504.tif 000013