JP2015082155A - 営業支援システム - Google Patents

Abstract

【課題】顧客の口座が属する部店と、営業担当者が所属する組織上の部店の体系が相違していても、営業担当者毎のアクセス権を組織構造に基づいて制御可能とする。【解決手段】組織の階層構造に係る情報を保持する組織ＤＢ１６と、営業担当者の属性と、属する組織に係る情報を保持する営業担当者ＤＢ１７と、営業担当者が組織の階層構造において参照権限を有する範囲を特定する情報を保持する参照権限管理ＤＢ１９とを有し、第１の営業担当者について、第１の営業担当者に係る営業活動情報、および前記第１の営業担当者が属する組織がバックオフィスシステム２０においてアクセス権を有する顧客の口座の情報に加えて、前記参照権限管理ＤＢ１９に設定された、第１の営業担当者が参照権限を有する範囲の組織に所属する他の第２の営業担当者に係る営業活動情報の、全部もしくは一部を取得して、第１の営業担当者が有する営業支援端末４０上に表示させる。【選択図】図１

Description

本発明は、営業担当者の営業活動を支援する技術に関し、特に、証券会社等の金融機関における営業活動を支援する営業支援システムに適用して有効な技術に関するものである。

例えば、証券会社等の金融機関では、営業担当者の営業活動に際して、ＣＲＭ（Customer Relationship Management：顧客関係管理）システム等を用いて顧客情報を管理するとともに、営業担当者が営業活動に携行するタブレット端末などの携帯型端末によって顧客情報や営業資料等を外出先においても参照可能としたり、営業実績を記録したり等の処理を行うＳＦＡ（Sales Force Automation：営業支援システム）が活用され、営業活動の効率化が図られている。

このような分野での技術として、例えば、特開２０１３−１４０６３２号公報（特許文献１）には、指定された条件に基づいて、顧客情報記憶部に記憶されている情報を検索することにより、「大口入金」や「定期満期」等のイベントを検出するイベント情報検出部と、イベントに関する顧客の位置に、そのイベントを示すマークを配置させて、イベント配置地図を作成して営業担当者の端末に表示させるイベント配置地図生成部と、法人顧客とその法人の社員である個人顧客のイベントとの関係を検出し、イベント配置地図のイベント説明部に表示させるイベント関係検出部とを有し、顧客に生じたイベントを地図上に配置させることにより、営業活動の効率を高める営業活動支援システムが記載されている。

特開２０１３−１４０６３２号公報

上記のような仕組みでは、通常は、営業担当者が参照できる、すなわちアクセス権を有する顧客の情報は、当該営業担当者が直接担当している顧客の情報に限られる。しかしながら、企業として営業活動の効率化を図る観点から、例えば、他の営業担当者がどのような顧客に対してどのような活動を行っているのかを参照可能としたり、上司が配下の営業担当者の営業活動の内容や実績を把握可能としたりなど、営業担当者が所属する部店や課などの組織内において一定の範囲で顧客情報や営業活動情報についての情報共有を行いたい場合がある。

一方で、同じ金融機関内においても部店間で競争関係にある場合があり、他の部店の情報を参照不可としたい場合もある。また、同じ部店内の営業担当者間でも、雇用形態やランク等の相違により、他の営業担当者が管理・担当している顧客の情報を参照不可としたり、逆に共有したいという場合もあるなど、参照権限の制御を詳細に行いたい場合がある。

このような柔軟な制御を行う場合、営業担当者による顧客情報等へのアクセス権を、自身が直接担当する顧客に限らずに、組織等もしくは組織内の営業担当者の単位で他の営業担当者が担当する顧客についても与える等の制御を行うことが必要となる。しかしながら、証券会社においては、どの範囲の顧客までアクセス権を与えるかを組織構造（組織内に所属する各営業担当者の構成も含む）を単位として制御、管理することは非常に困難である。

これは、証券会社においては、一般的に、顧客の口座が属する（関連付けられている）部店と、営業担当者の組織上の所属という観点での部店とでは、体系やコード値などが一致しない場合が多いことによる。例えば、ある営業担当者が担当する顧客について、当該顧客の口座が属する部店がＡであるのに対し、当該営業担当者が組織上所属する部店はＢである、という状況が生じ得る。このような状況は、例えば、部店の新設や統廃合などの際に、顧客の便宜のために顧客の口座が属する部店（部店コード）は変更されないものの、営業担当者が所属する組織としての部店は変更される（その逆もある）等の対応の相違により生じ得る。

そこで本発明の目的は、顧客の口座が属する部店と、営業担当者が所属する組織上の部店の体系が相違していても、顧客の口座の情報に対する営業担当者毎のアクセス権を、営業担当者が所属する組織構造に基づいて制御可能とする営業支援システムを提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

本発明の代表的な実施の形態による営業支援システムは、金融機関の営業担当者による顧客への営業活動を支援する営業支援システムであって、前記金融機関における組織の階層構造に係る情報を保持する組織情報保持部と、前記営業担当者の属性と、前記組織の階層構造において属する組織に係る情報を含む情報を保持する営業担当者情報保持部と、前記営業担当者が前記組織の階層構造において参照権限を有する範囲を特定する情報を保持する参照権限管理情報保持部と、を有し、第１の営業担当者について、前記第１の営業担当者に係る営業活動情報、および前記第１の営業担当者が属する組織がバックオフィスシステムにおいてアクセス権を有する顧客の口座の情報に加えて、前記参照権限管理情報保持部に設定された、前記第１の営業担当者が参照権限を有する範囲の組織に所属する他の第２の営業担当者に係る営業活動情報の、全部もしくは一部を取得して、前記第１の営業担当者が有する営業支援端末上に表示させるものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

すなわち、本発明の代表的な実施の形態によれば、顧客の口座が属する部店と、営業担当者が所属する組織上の部店の体系が相違していても、顧客の口座の情報に対する営業担当者毎のアクセス権を、営業担当者が所属する組織構造に基づいて制御することが可能となる。

本発明の一実施の形態である営業支援システムの構成例について概要を示した図である。 本発明の一実施の形態におけるバックオフィスシステムにおいて管理される各口座の所属部店と、各営業担当者の所属部店との関係の例について概要を示した図である。 本発明の一実施の形態における共有部店の設定において他の部店の口座情報を参照できる営業担当者を制限する例について概要を示した図である。 本発明の一実施の形態における自部店の口座の情報について自身が担当している口座の情報のみ参照可能とするよう制御する例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるバックオフィスシステムの部店ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるバックオフィスシステムの口座ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における営業支援システムのセールスマスタＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における営業支援システムの営業担当者ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における営業支援システムの顧客ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における組織の構造と各組織に所属する営業担当者との関係の例について概要を示した図である。 本発明の一実施の形態における営業支援システムの組織ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における組織の階層構造において各営業担当者が参照可能な範囲の設定の例について概要を示した図である。 本発明の一実施の形態における組織の階層構造において各営業担当者が参照可能な範囲の例について概要を示した図である。 本発明の一実施の形態における組織の階層構造において各営業担当者が参照可能な範囲の例について概要を示した図である。 本発明の一実施の形態における組織の階層構造において各営業担当者が参照可能な範囲の例について概要を示した図である。 本発明の一実施の形態における営業支援システムの参照権限管理ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態における営業担当者が複数の部店の口座の情報にアクセス可能な場合に参照可能な口座を制御する例について概要を示した図である。 本発明の一実施の形態における営業支援端末上に表示される画面例について概要を示した図である。 本発明の一実施の形態における営業支援端末上に表示される画面例について概要を示した図である。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

本発明の一実施の形態である営業支援システムは、証券会社等の金融機関において、営業担当者の営業活動を支援するためのＣＲＭシステムやＳＦＡとしての機能を有する情報処理システムであり、顧客情報を管理するとともに、営業担当者が営業活動に携行するタブレット端末などの携帯型端末によって顧客情報や営業資料等を外出先においても参照可能としたり、営業実績を記録したり等の処理を行うことによって営業活動の効率化を図るシステムである。

本実施の形態では、顧客情報の参照の際に、例えば、他の営業担当者がどのような顧客に対してどのような活動を行っているのかを参照可能としたり、上司が配下の営業担当者の営業活動の内容や実績を把握可能としたりなど、営業担当者が所属する部店や課などの組織内において一定の範囲で顧客情報や営業活動情報についての情報共有を行うことを可能とする。また、逆に、ある営業担当者が担当する顧客の情報について、他の特定の組織や営業担当者に対して参照不可とすることも可能とする。これらの制御により、企業として営業活動の効率化を図ることを可能とするものである。

＜システム構成＞
図１は、本発明の一実施の形態である営業支援システムの構成例について概要を示した図である。営業支援システム１０は、セキュアなネットワークを介して証券会社等において取引処理などの基幹業務を行うバックオフィスシステム２０と接続されている。また、インターネットやイントラネットなどのネットワーク３０を介して証券会社等の営業担当者が保有する情報処理端末である営業支援端末４０が接続されている。

営業支援システム１０は、例えば、サーバ機器や、クラウドコンピューティングサービス上に構築された仮想サーバなどのサーバシステムにより構成され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System：データベース管理システム）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムによって実装される顧客情報管理部１１や営業活動管理部１２、アクセス管理部１３などの各部を有する。また、データベースなどにより実装される顧客データベース（ＤＢ）１４、活動管理ＤＢ１５、組織ＤＢ１６、営業担当者ＤＢ１７、セールスマスタＤＢ１８、および参照権限管理ＤＢ１９などの各テーブルを有する。これらの各部やテーブル以外にも図示しない構成を有していてもよく、全体として、証券会社等におけるＣＲＭやＳＦＡとしての各種機能やサービスを実現している。

顧客情報管理部１１は、例えば、バックオフィスシステム２０から得ることができる顧客の基本的な情報の他に、各種の営業上有用な情報についても登録や参照を可能とし、ＣＲＭとしての機能を提供する。これらの顧客情報は、顧客ＤＢ１４に登録されて管理される。各営業担当者は、営業支援端末４０を利用して当該営業支援システム１０上の図示しないＷｅｂサーバプログラム等を介して顧客情報管理部１１にアクセスし、自身もしくは自身が属する組織内の他の営業担当者がアクセス権を有する顧客について、顧客情報を参照したり、営業支援端末４０にダウンロードして持ち出したり、また、収集・入力した顧客情報を新たに登録したりすることができる。

なお、営業担当者のマスタ情報は営業担当者ＤＢ１７に登録され管理されており、組織のマスタ情報は組織ＤＢ１６に登録され管理されている。また、各営業担当者が組織構造においてどの範囲の顧客情報を参照することができるかの情報は、参照権限管理ＤＢ１９に登録され管理されている。

営業活動管理部１２は、営業担当者の営業活動についての予定および実績を管理する機能を有する。各営業担当者の活動の予実管理は活動管理ＤＢ１５に登録され管理される。各営業担当者は、営業支援端末４０を利用して当該営業支援システム１０上の図示しないＷｅｂサーバプログラム等を介して営業活動管理部１２にアクセスし、自身もしくは自身が属する組織内の他の営業担当者の活動予定や実績を参照したり、自身の活動予定や実績を登録したりすることができる。

アクセス管理部１３は、参照権限管理ＤＢ１９を参照して、各営業担当者が参照することができる顧客情報を組織構造（組織内に所属する各営業担当者の構成も含む）に基づいて判定して制御する機能を有する。

バックオフィスシステム２０は、証券会社等において取引処理などの基幹業務を行う既存の情報処理システムであり、詳細な説明は省略するが、例えば、ＯＳやＤＢＭＳなどのミドルウェア上で稼働するソフトウェアプログラムによって実装される口座管理部２１、アクセス制御部２２、および取引処理部２３などの各部を有する。また、データベースなどにより実装される部店ＤＢ２４、口座ＤＢ２５、および取引履歴ＤＢ２６などの各テーブルを有する。これらの各部やテーブル以外にも図示しない構成を有していてもよく、全体として、証券会社等におけるバックオフィスシステムとしての各種機能やサービスを実現している。

口座管理部２１は、顧客の口座についてのマスタ情報を保持する口座ＤＢ２５に対して、口座の情報の登録や更新等の管理を行う機能や参照のための機能を有する。なお、各口座が属する部店のマスタ情報は部店ＤＢ２４に登録され管理される。アクセス制御部２２は、営業担当者等が口座ＤＢ２５や取引履歴ＤＢ２６などに保持されている顧客に係る情報にアクセスする際に、営業担当者等の属性や所属する組織などに基づいて設定・決定されるアクセス権に基づいてアクセス制御を行う機能を有する。すなわち、各営業担当者は、自身がアクセス権を有する顧客についてのみ口座の詳細な内容を参照することができる。取引処理部２３は、証券会社における有価証券の売買などの取引処理やその他の基幹業務に係る処理を行う機能を有する。顧客による取引の履歴は、取引履歴ＤＢ２６にログとして記録され、営業支援システム１０から営業情報として参照することが可能である。

営業支援端末４０は、例えば、ＰＣ（Personal Computer）などの情報処理端末からなり、図示しないＷｅｂブラウザによりネットワーク３０を介して営業支援システム１０等にアクセスして、顧客情報や営業活動情報などを参照することができる。ノート型ＰＣやタブレット端末などの携帯情報端末により構成して、これに営業活動情報などをダウンロードして携行することで、営業先で顧客に対して状況に応じて様々な営業資料を提示したり、営業担当者が外出先で活動予定や訪問する営業先の情報を確認したり、営業活動の実績を登録して報告したりなどの作業を行うこともでき、効果的かつ効率的な営業活動が可能となる。

本実施の形態では、上述したように、営業担当者が営業支援端末４０を介して顧客情報を参照等する際、自身が担当する顧客の情報だけでなく、自身が属する部店や課などの一定の範囲の組織内における他の営業担当者が担当する顧客の情報についても参照が可能となる。また、逆に、ある営業担当者が担当する顧客の情報について、他の特定の組織や営業担当者に対して参照不可とすることも可能となる。これらの制御により、組織内において一定の範囲で顧客情報や営業活動情報についての情報共有もしくは非共有を適切に行うことが可能となり、企業として営業活動の効率化を図ることが可能となる。

顧客情報には、営業担当者による活動実績の情報や、バックオフィスシステム２０から得ることができる顧客の属性情報や口座の内容に係る情報などが含まれ得る。なお、バックオフィスシステム２０にて管理されている顧客の口座の内容（例えば、残高や保有資産など）に係る情報は、当該口座に対して対象の営業担当者がアクセス権を有しない場合には、アクセス制御部２２により、総額などのサマリー情報、概要情報のみ参照可能として詳細な内容については参照できないように制御するものとする。

＜アクセス可能な口座の管理＞
図２は、バックオフィスシステム２０において管理される各口座の所属部店と、各営業担当者の所属部店との関係の例について概要を示した図である。図２の例では、基本的な形態として、各部店（図２の例では、図左側の部店コード“１０”、“２０”、“３０”の各部店）にそれぞれ所属する営業担当者は、自部店の口座の情報についてアクセス権を有しており参照可能であるが、他の部店の口座についてはアクセス権を有さない。一方で、特定の部店については、自部店と合わせて一括的な取り扱いを可能とするため、共有部店という設定をすることが可能である。

図２の例では、部店コード“１０”の部店に対して、部店コード“２０”の部店を共有部店として設定している。これにより、部店コード“１０”に所属する営業担当者は、部店コード“２０”にて管理される口座の情報を参照することが可能となる。これを用いて、例えば、投資一任部店のような論理的な部店を実際の各営業店に対して共有設定することで、各営業店から投資一任部店を参照可能とすることができる。

なお、上述したように、部店の新設や統廃合などの際の対応の相違等によって、図２の左側に示した営業担当者が所属する組織上の部店の体系と、図２の右側に示した各口座が属する部店の体系とが必ずしも一致しない場合がある。すなわち、ある営業担当者にとって、自身が組織上所属する部店の部店コードと、自身が担当しておりアクセスが可能な顧客の口座が属する自部店の部店コードとが異なる場合もあり得る。

図３は、共有部店の機能において他の部店の口座情報を参照できる営業担当者を制限する例について概要を示した図である。ここでは、各部点の営業担当者に対して共有入力区分という区分を設定し、当該区分に応じて対象の営業担当者が共有部店である他の部店の口座の情報にアクセス可能とするか否かを制御する。図３の例では、部店コード“１０”の部店において、共有入力区分が“ＲＤ０２”の営業担当者のみ、部店コード“２０”の部店の口座の情報にアクセス可能とし、共有入力区分が“ＲＤ０１”の営業担当者には自部店の口座の情報へのアクセスのみ許可する場合を示している。これにより、共有部店の口座の情報を一律に参照可能とするのではなく、営業担当者の単位で共有部店の口座情報へのアクセスを制限することが可能となる。

図４は、さらに、自部店の口座の情報について自身が担当している口座の情報のみ参照可能とするよう制御する例について概要を示した図である。ここでは、各部店の営業担当者に対して業務ランクを設定し、当該ランクに応じて他の営業担当者が担当している口座の情報を参照できないようにする、すなわち、自身が担当している口座の情報のみ参照可能とする。図４の例では、部店コード“１０”の部店の営業担当者２は、ランクが“５（扱者限）”というものであり、自身が扱者となっている（担当している）口座の情報のみ参照可能となっていることを示している。これにより、例えば、個人契約の営業担当者などに対して、自身が担当している口座の情報のみ参照可能となるよう制限することができる。

図５〜図９は、上記のような口座情報へのアクセスの制御を行うためのデータ構成の例について示した図である。図５は、バックオフィスシステム２０の部店ＤＢ２４のデータ構成の例について概要を示した図である。部店ＤＢ２４は、各口座が属する部店のマスタ情報を保持するテーブルであり、例えば、図５（ａ）に示す部店マスタＤＢ２４ａと、図５（ｂ）に示す共有部店ＤＢ２４ｂの各テーブルからなる。

図５（ａ）の部店マスタＤＢ２４ａは、部店のマスタ情報を保持するテーブルであり、例えば、部店コード、部店名称、所在地、および連絡先などの各項目を有する。部店コードの項目は、各部店を一意に識別するためのコード値等の情報を保持する。部店名称の項目は、対象の部店の名称などの表示情報を保持する。所在地および連絡先の各項目は、それぞれ、対象の部店の住所等の所在地に係る情報、および電話番号や電子メールアドレスなどの連絡先の情報を保持する。

図５（ｂ）の共有部店ＤＢ２４ｂは、図２に示した共有部店の情報を保持するテーブルであり、例えば、部店コード、共有部店コード、および共有入力区分などの各項目を有する。部店コードの項目は、共有部店を判断する際の基準となる部店を特定する部店コードの情報を保持する。共有部店コードの項目は、対象の部店に対して共有部店となる部店を特定する部店コードの情報を保持する。共有入力区分の項目は、対象の共有部店の口座の情報にアクセスすることができる営業担当者の共有入力区分のコード値の情報を保持する。

図６は、バックオフィスシステム２０の口座ＤＢ２５のデータ構成の例について概要を示した図である。口座ＤＢ２５は、各顧客の口座についてのマスタ情報を保持するテーブルであり、例えば、部店コード、口座番号、名義人姓、名義人名、開設日、扱者コード、および参照可能ランクなどの各項目を有する。

部店コードの項目は、対象の口座が属する部店を特定する部店コードの情報を保持する。口座番号の項目は、対象の口座を少なくとも部店内で一意に識別するための番号情報を保持する。名義人姓および名義人名の各項目は、それぞれ、対象の口座の名義人である顧客の姓および名の情報をそれぞれ漢字およびカナによって保持する。開設日の項目は、対象の口座を開設した日時の情報を保持する。扱者コードの項目は、対象の口座および当該口座を有する顧客を担当する営業担当者を特定するためのコード値等の情報を保持する。この値は、後述するセールスマスタＤＢ１８において実際の営業担当者のＩＤと関連付けられて登録されている。

図７は、営業支援システム１０のセールスマスタＤＢ１８のデータ構成の例について概要を示した図である。セールスマスタＤＢ１８は、各部店においてこれに属する各口座を担当する論理的な担当者である扱者のマスタ情報を保持するテーブルであり、例えば、部店コード、扱者コード、および営業担当者ＩＤなどの各項目を有する。

部店コードの項目は、対象の部店を特定する部店コードの情報を保持する。扱者コードの項目は、対象の扱者を少なくとも部店内で一意に識別するためのコード値等の情報を保持する。営業担当者ＩＤの項目は、対象の扱者に対応して関連付けられる実際の営業担当者を特定するＩＤ情報を保持する。このような扱者の定義により、実際の営業担当者の変更や異動などによる影響を極小化して柔軟に対応することができる。

図８は、営業支援システム１０の営業担当者ＤＢ１７のデータ構成の例について概要を示した図である。営業担当者ＤＢ１７は、営業担当者のマスタ情報を保持するテーブルであり、例えば、営業担当者ＩＤ、所属組織コード、氏名、連絡先、ランク、および共有入力区分などの各項目を有する。

営業担当者ＩＤの項目は、各営業担当者を一意に識別するためのＩＤ情報を保持する。所属組織コードの項目は、対象の営業担当者が所属する組織（例えば、部店に属する課の単位など）の組織コードの情報を保持する。この組織コードの値は、例えば、後述の図１１の例に示す組織ＤＢ１６に登録されている。氏名の項目は、対象の営業担当者の氏名の情報を保持する。連絡先の項目は、対象の営業担当者の電話番号や電子メールアドレスなどの連絡先の情報を保持する。ランクの項目は、対象の営業担当者の業務ランクを示す数値やコード値の情報を保持する。この値に応じて、例えば、上述の図４に示したように、部店内でアクセス可能な口座を制限するなどの制御を行うことができる。共有入力区分の項目は、対象の営業担当者がどの共有部店の口座の情報にアクセスすることができるかを示す共有入力区分のコード値の情報を保持する。

図９は、営業支援システム１０の顧客ＤＢ１４のデータ構成の例について概要を示した図である。顧客ＤＢ１４は、顧客に係るマスタ情報を保持するテーブルであり、例えば、顧客ＩＤ、顧客姓、顧客名、法人フラグ、部店コード、口座番号、口座種別、住所、電話番号、生年月日、および職業などの各項目を有する。

顧客ＩＤの項目は、保有する口座毎に各顧客を一意に識別するためのＩＤ等の情報を保持する。顧客姓および顧客名の項目は、対象の顧客の姓および名の情報をそれぞれ漢字およびカナによって保持する。法人フラグの項目は、対象の顧客が法人顧客であるか否かを識別するフラグ情報を保持する。法人顧客の場合は、上記の顧客姓の項目に法人の名称を保持する。

部店コードおよび口座番号の各項目は、対象の顧客が保有する口座が属する部店の部店コードおよび当該口座の口座番号の情報をそれぞれ保持する。口座種別の項目は、対象の口座の種別を特定するコード値等の情報を保持する。例えば、いわゆる一般口座か特定口座か、さらに、いわゆるファンドラップサービス等のための専用口座であるか等を特定するコード値等の情報を保持する。各顧客は、支店の口座の他に、ＳＭＡ（Separated Managed Account）やファンドラップ口座等の専用口座も含めて複数の口座を保有することができる。住所、電話番号、生年月日、および職業の各項目は、対象の顧客の属性情報として、把握できる限りで、住所、電話番号、生年月日、および職業の情報をそれぞれ保持する。住所には、郵便番号や住所コードの情報を含んでいてもよい。職業についても、コード値等の情報により保持することができる。

上記のようなデータ構成により、営業担当者の異動等にも柔軟に対応しつつ、対象の口座に誰がアクセス権を有するか、すなわち、各営業担当者がどの口座にアクセスすることができるかを管理することができる。

＜アクセス可能な組織の範囲の管理＞
図１０は、営業支援システム１０において管理される組織の構造と各組織に所属する営業担当者との関係の例について概要を示した図である。ここでの組織は、証券会社等の企業における組織の階層構造を構成する各部署等からなり、本実施の形態では、図示するように、部店単位、各部店に属する課単位、各課に属する個人単位の３階層によって管理するが、階層の数はこれに限られない。基本的に、部店単位、課単位の層では、これに属する営業担当者は、当該組織の長や代表、責任者であり、その他の営業担当者は個人単位の層に属する。

図１１は、上記のような組織および営業担当者の管理を行うためのデータ構成として、営業支援システム１０の組織ＤＢ１６のデータ構成の例について概要を示した図である。組織ＤＢ１６は、組織構造のマスタ情報を保持するテーブルであり、例えば、組織コード、部店コード、組織名称、組織区分、親組織コード、所在地、および連絡先などの各項目を有する。

組織コードの項目は、各組織（部店やこれに属する課など）を一意に識別するためのコード値等の情報を保持する。部店コードの項目は、対象の組織が属する部店の部店コードの情報を保持する。対象の組織が部店の場合は、上記の組織コードは当該部店コードと一致していてもよい。組織名称の項目は、対象の組織の名称等の表示情報を保持する。組織区分の項目は、対象の組織の区分を示すコード値等の情報を保持する。例えば、部店であるか課であるか等を識別するためのコード値を設定することができる。親組織コードの項目は、対象の組織が属する親組織がある場合には、その組織を特定する組織コードの情報を保持する。これにより、組織の階層構造を把握することができる。所在地および連絡先の各項目は、それぞれ、対象の組織の住所等の所在地に係る情報、および電話番号や電子メールアドレスなどの連絡先の情報を保持する。

上記のような組織の階層構造において、本実施の形態では、各営業担当者が口座の情報や営業活動情報などを参照可能な範囲を設定可能とすることで、組織内の一定の範囲での情報の共有、もしくは参照の制限などの制御を行うことができる。図１２は、組織の階層構造において各営業担当者が参照可能な範囲の設定の例について概要を示した図である。また、図１３〜図１５は、それぞれ、組織の階層構造において各営業担当者が参照可能な範囲の例について概要を示した図である。

図１２の例では、部店単位の参照権限を有する営業担当者として、“支店長Ａ”、“課長ｂ”および“課員ａ２”が設定されていることを示している。また、課単位の参照権限を有する営業担当者として“課長ａ”が設定され、個人単位での参照しか許されていない営業担当者として、“課員ａ１”および“課員ｂ１”が設定されていることを示している。

ここで、部店単位の参照権限を有する営業担当者は、図１３に示すように、組織の階層構造において、対象の部店に属する全ての課、およびこれらの課にそれぞれ属する全ての営業担当者について参照権限を有する。すなわち、上記範囲に属する他の全ての営業担当者についての、担当顧客の情報や、口座の情報、営業活動情報などを参照することができる。また、図１２の例において、課単位の参照権限を有する営業担当者は、図１４に示すように、組織の階層構造において、対象の課に属する全ての営業担当者について参照権限を有する。また、図１２の例において、個人単位の参照権限しか有さない営業担当者は、図１５に示すように、自身がアクセス可能な情報に対してのみ参照権限を有する。

なお、上記のいずれの場合も、各営業担当者が参照可能な口座の情報については、上述の図２〜図４において示したアクセス可能な口座の制御が適用される。従って、他の営業担当者の情報に対する参照権限を有する場合であっても、当該他の営業担当者が担当する顧客の口座に対して自身がアクセス権を有していない場合は、当該口座についての詳細な内容は参照することができない。

図１６は、上記のような組織階層における参照可能範囲の制御を行うためのデータ構成として、営業支援システム１０の参照権限管理ＤＢ１９のデータ構成の例について概要を示した図である。参照権限管理ＤＢ１９は、各営業担当者についての組織構造における参照可能な範囲の設定情報を保持するテーブルであり、例えば、営業担当者ＩＤ、および参照可能範囲コードなどの各項目を有する。

営業担当者ＩＤの項目は、対象の営業担当者を特定するＩＤ情報を保持する。参照可能範囲コードの項目は、対象の営業担当者が参照可能な範囲が、部店単位であるのか、課単位であるのか、もしくは個人単位であるのかを識別可能とするコード値等の情報を保持する。組織階層において参照可能な範囲を特定することができる情報であれば、これに限らず、例えば、参照可能な範囲の組織に対応する組織コードなどの情報を保持してもよい。

上記のような、アクセス可能な口座の制御、およびアクセス可能な組織の範囲の制御を組み合わせることで、組織の階層構造において、一定の範囲での口座の情報も含む営業活動情報の共有、もしくは参照の制限などの制御を柔軟に行うことができる。

なお、上述の図５、図６〜図９、図１１、図１６で示した各テーブルのデータ構成（項目）はあくまで一例であり、同様のデータを保持・管理することが可能な構成であれば、他のテーブル構成やデータ構成であってもよい。

図１７は、上述した制御方法により、営業担当者が複数の部店の口座の情報にアクセス可能な場合に参照可能な口座を制御する例について概要を示した図である。図１７の上段の図では、上述の図１０〜図１５の例に示した手法により設定された、部店コード“１００”の部店の組織構造における各営業担当者の参照可能範囲の設定内容を示している。ここで、対象の営業担当者が“課員ａ２（営業担当者ＩＤ：２００）”であるとすると、図１７の例では、“課員ａ２”は、部店コード“１００”の部店に属する全ての営業担当者の営業活動情報を参照できることを示している。このような制御は、営業支援システム１０のアクセス管理部１３により実現される。

一方で、部店コード“１００”の部店に属する営業担当者は、図１７の中段の図に示す部店コード“１０”および部店コード“２０”の各部店に属する口座の情報が参照可能であることが示されている。このような制御は、上述の図２〜図４に示した手法によりバックオフィスシステム２０のアクセス制御部２２により実現される。ここでは、例えば、部店コード“１０”の部店に対して部店コード“２０”の部店を共有部店として設定することによって、これら複数の部店の口座の情報を参照可能とすることができる。

ここで、“課員ａ２”の業務ランクが、自身が扱者となっている口座の情報のみ参照が許可されるランクであった場合や、口座情報の検索・絞り込み等において自身が扱者となっている（自身が担当する）口座の情報のみを参照したい場合は、図１７の下段に示すセールスマスタＤＢ１８を参照して、実際の営業担当者のＩＤ情報を扱者コードに還元・変換する。

図１７の例では、“課員ａ２（営業担当者ＩＤ：２００）”は、部店コード“１０”の部店では扱者コード“１０”に対して、部店コード“２０”の部店では扱者コード“２０”に対して設定されていることを示している。従って、図１７の中段の図に示すように、バックオフィスシステム２０の口座ＤＢ２５において、それぞれ、部店コード“１０”の部店に属して扱者コードが“１０”となっている口座、および部店コード“２０”の部店に属して扱者コードが“２０”となっている口座が、“課員ａ２”がアクセス可能な口座の情報として把握される。

このように、各営業担当者が、組織構造においてどの範囲の情報を参照することができるか、どの部店の口座の情報にアクセスすることができるか、各部店において自身が扱者として担当する口座はどれか、という３つの観点による設定・定義情報を組み合わせる簡易な手法によって、必要な範囲で情報共有を図りつつ、特定の場合には参照を制限して情報共有させない、というような柔軟なアクセス制御を容易に実現することができる。

このようなアクセス制御により、例えば、課などの組織の責任者や管理者が、配下のメンバーである各営業担当者の営業活動の状況などを容易かつ的確に把握することが可能である。また、参照権限管理ＤＢ１９において、参照可能な組織を、自身が所属する組織ではなく、例えば、コールセンターの実施部署などの他の組織とすることにより、営業担当者同士の横のつながりだけでなく、これらの情報を必要とする他の部署との間で顧客情報や営業活動情報などを共有することも可能である。

＜画面および処理の概要＞
図１８および図１９は、営業担当者の営業活動を支援するために、営業支援システム１０により営業支援端末４０上に表示される画面例について概要を示した図である。営業支援端末４０上では、例えば、画面上部のタブにより、営業担当者単位での情報集約画面（“Dash board”タブ）と、顧客単位での情報集約画面（“Client360”タブ）を切り替えて表示することができる。図１８では、“Dash board”タブの画面例を示しており、また、図１９では、“Client360”タブの画面例を示している。

図１８に示した“Dash board”タブでは、対象の営業担当者の営業活動全般を支援するための情報を複数のタブによって切り替え可能な画面で表示する。図１８の例では、“サマリー”タブの画面例を示しており、サマリー情報として、例えば、各種のイベントが発生している顧客の件数や、該当する顧客のサマリー情報を一覧表示する“リード”欄、現在営業活動中の案件の内容や進捗状況の概要を一覧表示する“案件一覧”欄、営業担当者の活動状況をグラフ表示した“活動状況”欄、および営業担当者の営業日誌のサマリー情報を一覧表示する“営業日誌”欄などを表示している。また、“顧客一覧”や“案件一覧”、“営業日誌”などのタブでは、それぞれ、より詳細な内容を一覧表示する。

このような画面により、営業担当者は、自身が担当する複数の顧客に対する営業活動のために有用な情報の提供を受けたり、営業活動の予実を管理したりすることができる。なお、上述したように、特定の営業担当者についての情報に限らず、例えば、組織の階層構造において当該営業担当者が参照可能な範囲に属する他の営業担当者についての情報も、個別もしくはサマリーの情報として表示して参照可能とすることができる。

図１９に示した“Client360”タブでは、検索等により選択された顧客、もしくは“Dash board”タブの画面において選択された特定の顧客についての営業活動を支援するための情報を複数のタブによって切り替え可能な画面として表示する。図１９の例では、“サマリー”タブの画面例を示しており、サマリー情報として、例えば、対象の顧客の口座番号や氏名や住所等の基本的な属性情報を表示する“基本属性”欄、対象の顧客の保有資産のサマリー情報を一覧表示する“資産”欄、対象の顧客について発生しているイベントの概要を一覧表示する“リード”欄、対象の顧客について現在活動中の案件の概要を一覧表示する“案件一覧”欄、および対象の顧客に対する営業担当者の営業活動の履歴のサマリー情報を一覧表示する“接触履歴”欄などを表示している。また、“収集情報”や“預り資産”、“投資状況”などのタブでは、それぞれ、より詳細な内容を表示する。

このような画面により、営業担当者は、特定の顧客に対する営業活動のために有用な情報の提供を受けたり、当該顧客に係る詳細なデータを参照したりすることができる。

以上に説明したように、本発明の一実施の形態である営業支援システム１０によれば、各営業担当者が、所属する組織構造においてどの範囲の情報を参照することができるか、どの部店の口座の情報にアクセスすることができるか、各部店において自身が扱者として担当する口座はどれか、という３つの観点による設定・定義情報を組み合わせる簡易な手法によって、営業担当者が顧客情報を参照する際に、顧客の口座が属する部店と、営業担当者が所属する組織上の部店の体系が相違していても、他の営業担当者との間で必要な範囲で情報共有を図りつつ、特定の場合には参照を制限して情報共有させない、というような柔軟なアクセス制御を容易に実現することができる。これにより、企業として営業活動の効率化を図ることが可能である。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、上記の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各図において、制御線や情報線は説明上必要と考えられるものを示しており、必ずしも実装上の全ての制御線や情報線を示しているとは限らない。実際にはほとんど全ての構成が相互に接続されていると考えてもよい。

本発明は、証券会社等の金融機関における営業活動を支援する営業支援システムに利用可能である。

１０…営業支援システム、１１…顧客情報管理部、１２…営業活動管理部、１３…アクセス管理部、１４…顧客データベース（ＤＢ）、１５…活動管理ＤＢ、１６…組織ＤＢ、１７…営業担当者ＤＢ、１８…セールスマスタＤＢ、１９…参照権限管理ＤＢ、
２０…バックオフィスシステム、２１…口座管理部、２２…アクセス制御部、２３…取引処理部、２４…部店ＤＢ、２４ａ…部店マスタＤＢ、２４ｂ…共有部店ＤＢ、２５…口座ＤＢ、２６…取引履歴ＤＢ、
３０…ネットワーク、
４０…営業支援端末。

Claims (2)

1. 金融機関の営業担当者による顧客への営業活動を支援する営業支援システムであって、
   前記金融機関における組織の階層構造に係る情報を保持する組織情報保持部と、
   前記営業担当者の属性と、前記組織の階層構造において属する組織に係る情報を含む情報を保持する営業担当者情報保持部と、
   前記営業担当者が前記組織の階層構造において参照権限を有する範囲を特定する情報を保持する参照権限管理情報保持部と、を有し、
   第１の営業担当者について、前記第１の営業担当者に係る営業活動情報、および前記第１の営業担当者が属する組織がバックオフィスシステムにおいてアクセス権を有する顧客の口座の情報に加えて、前記参照権限管理情報保持部に設定された、前記第１の営業担当者が参照権限を有する範囲の組織に所属する他の第２の営業担当者に係る営業活動情報の、全部もしくは一部を取得して、前記第１の営業担当者が有する営業支援端末上に表示させる、営業支援システム。
2. 請求項１に記載の営業支援システムにおいて、
   顧客の口座が属する組織において口座の管理を担当する扱者として設定された前記営業担当者の情報を保持するセールスマスタ情報保持部を有し、
   前記第１の営業担当者について、前記参照権限管理情報保持部に設定された参照権限を有する範囲が、前記第１の営業担当者個人である場合に、顧客の口座の情報として、前記第１の営業担当者が扱者となっている口座についてのみ参照を許可する、営業支援システム。

Images