JP2015103007A - 運用レポート管理システムおよび運用レポート管理プログラム - Google Patents

Abstract

【課題】運用レポートを簡易な処理により効率的に作成可能とするとともに、運用レポートが個人情報を含む場合には管理者の承認を行うよう制御する。
【解決手段】予め定義された、レポート１１１を構成する各報告内容を出力する複数のコンテンツ１５１を保持し、営業担当者からの、コンテンツ１５１の組み合わせの指定を受け付けて、指定された各コンテンツ１５１により、営業支援情報１２に基づいてそれぞれ作成された報告内容によってレポート１１１を作成するレポート作成部１１０と、コンテンツ１５１の組み合わせに係る情報をレポート構成の雛形として管理する雛形管理部１３０とを有し、レポート作成部１１０は、コンテンツ１５１の組み合わせの指定について、営業担当者から指定された雛形に係るレポート構成の内容に基づいて受け付けることが可能である。
【選択図】図１

Description

本発明は、証券会社等における営業担当者の営業活動を支援する技術に関し、特に、顧客に対して提出する運用レポート等の作成および管理を支援する運用レポート管理システムおよび運用レポート管理プログラムに適用して有効な技術に関するものである。

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

営業担当者は、営業活動の中で、例えば、月次や四半期、半期などの定期的なタイミングや、大きな売買があった場合などの特定のタイミングなどで、顧客に対して運用実績等の各種のレポートを作成して提示・報告する場合がある。複数の営業担当者が、それぞれ自身が担当する複数の顧客に対して、顧客毎に必要な情報をまとめた固有のレポートを作成して提示・報告することから、これらの作業をＳＦＡにより支援したいというニーズがある。

これに関連する技術として、例えば、特開２００２−７６８９号公報（特許文献１）には、信託契約等の主契約の受託者から再信託を受託する再信託契約の受託者が、信託財産等を管理または運用管理し、管理または運用管理した結果である再信託契約の管理レポートである資金決済処理（年金拠出金／年金給付金事務）・報酬計算処理・決算処理・レポート処理等を電子データ化して主契約の受託者名でコンピュータを通じて主契約の受託者または主契約の委託者に電送する構成からなるシステムが記載されている。

また、例えば、特開２００２−２７９１８７号公報（特許文献２）には、顧客を特定するための認証情報の入力をインターネットを通じて受け付ける認証情報受付手段と、認証情報受付手段が受け付けた認証情報に基づいて顧客を特定する顧客特定手段と、顧客特定手段が特定した顧客に適する情報を、提供可能な情報群の中から選択する情報選択手段と、顧客特定手段が特定した顧客へ、情報選択手段がその顧客向けに選択した情報をインターネットを通じて送信する送信手段とを有することで、証券等の電子商取引において、認証の完了した顧客に対し、その顧客に関連ある情報を迅速かつアクセス容易に提供することのできる電子商取引装置が記載されている。

特開２００２−７６８９号公報 特開２００２−２７９１８７号公報

上述したような従来技術では、顧客に対して顧客固有の情報やレポート等を閲覧可能としたり、データとして送信したりすることができる。しかしながら、例えば、高齢の顧客や富裕層の顧客などでは、自らＰＣ（Personal Computer）等の情報処理端末を操作してデータを閲覧する、というような行為を行わない、もしくは行うことが困難な顧客も多く想定される。このような顧客に対しては、営業担当者が個別に訪問し、紙媒体もしくは営業担当者が有する携帯型端末に持ち出した運用レポート等の資料を提示して説明・報告し、営業活動を行うということが必要となる。

顧客毎に必要な情報をまとめた固有の運用レポート等を営業担当者がその都度作成することは大きな負荷である。また、顧客に提出する資料に顧客の個人情報が含まれる場合には、持ち出しや提示に際して管理者の承認が必要であるなど、取り扱いのレベルが格段に厳しくなるが、営業担当者にとって、自身が作成した運用レポート等が管理者の承認対象の資料に該当するのか否かの判断や、該当するとした場合の承認処理などを行うことも大きな負荷となる。営業担当者にとっては、簡易な処理により効率的にレポートを作成できる環境が望まれる。

そこで本発明の目的は、顧客毎に固有の運用レポートを簡易な処理により効率的に作成可能とするとともに、作成された運用レポートが個人情報を含む場合には管理者の承認を行うよう制御する運用レポート管理システムおよび運用レポート管理プログラムを提供することにある。

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

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

本発明の代表的な実施の形態による運用レポート管理システムは、金融機関の顧客に対して提出する運用レポートの作成を管理する運用レポート管理システムであって、予め定義された、前記運用レポートを構成する各報告内容を出力する複数のコンテンツを保持し、営業担当者からの、前記運用レポートに含める前記コンテンツの組み合わせの指定を受け付けて、指定された前記各コンテンツにより、前記顧客について保持されている営業活動に係る情報に基づいてそれぞれ作成された前記報告内容によって前記運用レポートを作成するレポート作成部と、前記営業担当者から指定された前記コンテンツの前記組み合わせに係る情報を、レポート構成の雛形として管理する雛形管理部と、を有し、前記レポート作成部は、前記コンテンツの前記組み合わせの指定について、前記営業担当者から指定された前記雛形に係る前記レポート構成の内容に基づいて受け付けることが可能である。

また、本発明は、上記のような運用レポート管理システムとして機能するよう、コンピュータに処理を実行させるプログラムにも適用することができる。

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

すなわち、本発明の代表的な実施の形態によれば、顧客毎に固有の運用レポートを簡易な処理により効率的に作成可能とするとともに、作成された運用レポートが個人情報を含む場合には管理者の承認を行うよう制御することが可能となる。

本発明の一実施の形態である運用レポート管理システムの構成例について概要を示した図である。 本発明の一実施の形態におけるレポートのステータスの遷移の例について概要を示した状態遷移図である。 本発明の一実施の形態における営業支援サーバにより営業支援端末上に表示される画面例について概要を示した図である。 本発明の一実施の形態における営業支援サーバにより営業支援端末上に表示される他の画面例について概要を示した図である。 本発明の一実施の形態における“レポート管理”タブにおいて営業支援端末上に表示される画面例および提供される機能の例について概要を示した図である。 本発明の一実施の形態における“レポート管理”タブにおいて営業支援端末上に表示される他の画面例および提供される機能の例について概要を示した図である。 本発明の一実施の形態における“レポート管理”タブにおいて営業支援端末上に表示される他の画面例および提供される機能の例について概要を示した図である。 本発明の一実施の形態における“レポート管理”タブにおいて営業支援端末上に表示される他の画面例および提供される機能の例について概要を示した図である。 本発明の一実施の形態における“レポート管理”タブにおいて営業支援端末上に表示される他の画面例および提供される機能の例について概要を示した図である。 本発明の一実施の形態におけるコンテンツ管理ＤＢのデータ構成の例について概要を示した図である。 （ａ）、（ｂ）は、本発明の一実施の形態におけるレポート設定ＤＢのデータ構成の例について概要を示した図である。 本発明の一実施の形態におけるレポートＤＢのデータ構成の例について概要を示した図である。

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

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

本実施の形態では、営業担当者が、担当する顧客に対して提示して説明・報告する運用レポート等の書面や帳票（以下ではこれらを「レポート」と総称する場合がある）を、簡易な操作により効率的に作成可能とする。例えば、所定の報告事項について所定の手順により分析・集計を行ってグラフや表などにレイアウトして出力する機能を有するモジュールであるコンテンツを予め各種定義しておき、営業担当者は自由にこれを取捨選択して配置することでレポート構成を定義する。そして、当該レポート構成に基づいて、配置された各コンテンツのモジュールが実データを参照してグラフや表などを出力することで、レポートを自動作成する。使用したレポート構成は、再利用するために営業担当者毎に雛形として保持可能とする。

レポートは、例えば、ＰＤＦ（Portable Document Format）等の汎用的に取り扱い可能な形式で作成され、印刷したり、営業支援端末にダウンロードしたりして、営業担当者が顧客を訪問する際に持ち出すことができる。

各営業担当者により作成された各レポートについては、それぞれ、承認状況などのステータスを管理する。これにより、レポートの出力に際して、レポートが顧客の個人情報を含む場合には、管理者に対して承認依頼を行うワークフローを実行するとともに、承認状況のステータスに応じてレポートのファイルへのアクセス制御や印刷制御を行うことができる。例えば、承認が得られていない状態の場合には、ファイルのダウンロードやコピーによる持ち出しを禁止したり、印刷時に“ＤＲＡＦＴ”等の文字からなる背景を入れたりするなどの制御を行うことができる。

＜システム構成＞
図１は、本発明の一実施の形態である運用レポート管理システムの構成例について概要を示した図である。運用レポート管理システム１は、営業支援サーバ１０と、これにインターネットやイントラネットなどのネットワーク２０を介して接続される、証券会社等の営業担当者が保有する情報処理端末である営業支援端末３０とを有する。

営業支援サーバ１０は、例えば、サーバ機器や、クラウドコンピューティングサービス上に構築された仮想サーバなどのサーバシステムにより構成され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System：データベース管理システム）、およびＷｅｂサーバプログラムなどの基盤ソフトウェア上で稼働するソフトウェアプログラムによって実装され、営業担当者の営業活動を支援する各種のサービスを提供する業務アプリケーションプログラムである１つ以上の支援サービス１１、およびレポート管理部１００を有する。

支援サービス１１により提供されるサービスとしては、例えば、データベースやファイルなどからなる営業支援情報１２として保持され、もしくは図示しないバックオフィスシステム等により保持される各種の顧客情報や営業情報を取得して営業支援端末３０上に表示させたり、営業支援端末３０を介して営業担当者の活動実績の登録を受け付けて記録したりなどが含まれる。営業支援サーバ１０は、上記以外に図示しない他の構成を有していてもよく、全体として、証券会社等におけるＣＲＭやＳＦＡとしての各種機能やサービスを実現している。

レポート管理部１００は、営業担当者による顧客に対するレポートの作成と、作成されたレポートの管理を行う機能を有し、さらに、レポート作成部１１０、作成レポート管理部１２０、雛形管理部１３０、および承認処理部１４０などの各部を有する。また、データベースやファイルなどからなるコンテンツ管理データベース（ＤＢ）１５０、レポート設定ＤＢ１６０、およびレポートＤＢ１７０などの各テーブルを有する。

レポート作成部１１０は、営業支援端末３０を介した営業担当者からの指示に基づいて、予め定義されてコンテンツ管理ＤＢ１５０に登録されているコンテンツ１５１を取捨選択して配置してレポート構成を定義し、当該レポート構成に基づいて、実際のコンテンツ１５１と、営業支援情報１２の情報や図示しないバックオフィスシステム等により保持される顧客情報等とに基づいて、レポート１１１を作成する機能を有する。なお、コンテンツ１５１は、上述したように、所定の報告事項について所定の手順により分析や集計を行ってグラフや表などにレイアウトする機能を有するモジュールやテンプレートとして構成され、実際のデータを入力として、これを分析や集計、加工した結果のグラフや表などを出力する機能を有する。

また、レポート作成部１１０は、営業担当者からの指示に基づいて、レポート構成を新規に作るのではなく、営業担当者毎の既存のレポート構成に係る情報を保持するレポート設定ＤＢ１６０から対象となるレポート構成を取得して、これに基づいてレポート１１１を作成することも可能である。既存のレポート構成としては、例えば、対象の営業担当者が前回作成したレポート１１１において使用したレポート構成や、後述する雛形管理部１３０を介してレポート設定ＤＢ１６０に雛形として設定・登録しておいたレポート構成を使用することができる。

作成レポート管理部１２０は、レポート作成部１１０により作成された各レポート１１１に係る情報をレポートＤＢ１７０に記録して管理することで、各レポート１１１を管理する機能を有する。管理機能には、レポート１１１のレポートＤＢ１７０への記録や、参照、レポートＤＢ１７０の登録内容の更新などの処理が含まれる。また、例えば、レポート１１１が顧客の個人情報を有する場合に、管理者による承認処理の状況を含むステータスを管理し、ステータスに応じてアクセス制御や出力制御を行う。また、すでに顧客に提示済みの過去のレポート１１１についても履歴情報として保持し、必要に応じてレポートＤＢ１７０を検索することにより呼び出すことが可能である。

雛形管理部１３０は、営業担当者毎に、レポート作成部１１０によりレポート１１１を作成する際に用いたレポート構成を再利用可能とするために、当該レポート構成を雛形とする旨の情報をレポート設定ＤＢ１６０に登録する機能を有する。また、既に雛形として登録されているレポート構成を削除したり、内容を編集して変更したりするメンテナンス機能を有していてもよい。

承認処理部１４０は、レポート作成部１１０により作成されたレポート１１１が、顧客の個人情報が表示される項目を含むコンテンツ１５１を有する場合に、レポート作成者や担当者が上長等の管理者に対して承認申請を行うワークフローを実行する機能を有する。営業担当者は、例えば、承認が必要なレポートのリストを承認処理部１４０を介して取得し、当該リストから対象のレポート１１１を選択して承認申請を行う。承認処理部１４０が自動的に承認申請を行うようにしてもよい。また、管理者は、例えば、承認待ちレポートのリストを承認処理部１４０を介して取得し、当該リストから対象のレポート１１１を選択して承認可否の指定を入力し、さらに必要に応じてコメントを入力する。各レポート１１１についての承認状況のステータスはレポートＤＢ１７０により管理される。

営業担当者等が使用する営業支援端末３０は、例えば、ノート型ＰＣやタブレット端末などの携帯型端末からなり、図示しないＯＳ上で稼働するＷｅｂブラウザ等のソフトウェアプログラムを有する。Ｗｅｂブラウザにより、ネットワーク２０を経由して営業支援サーバ１０上の図示しないＷｅｂサーバプログラムを介してレポート管理部１００にアクセスし、レポート１１１の作成や出力などの各種管理機能を利用する。

＜レポートのステータス＞
本実施の形態では、上述したように、レポート作成部１１０により作成された各レポート１１１について、それぞれレポートＤＢ１７０によってステータスを管理する。図２は、レポート１１１のステータスの遷移の例について概要を示した状態遷移図である。レポート１１１が作成されると、作成レポート管理部１２０もしくはレポート作成部１１０は、まず、当該レポート１１１に、顧客の個人情報が表示される項目を含む（当該項目がオプション項目の場合は営業担当者により表示する旨の指定がされている）コンテンツ１５１を有しているか否か、すなわち管理者による承認が必要か否かを判定する。

承認が不要である場合は、“提示可能”というステータスとし、承認が必要である場合は、“要承認”とういステータスとして、レポートＤＢ１７０に登録する。ステータスが“提示可能”の場合には、作成レポート管理部１２０は、営業担当者からの指示により当該レポート１１１を営業支援端末にダウンロードしたり、印刷したりして出力することができる。営業担当者は、出力されたレポートを顧客に提示したり説明したりすることができる。一方、ステータスが“要承認”の場合は、営業担当者が承認申請をすることが必要であり、承認処理部１４０が承認申請を受け付けると、“承認申請中”というステータスに遷移する。

“承認申請中”のステータスのレポート１１１は、例えば、管理者がレポート管理部１００にアクセスしたときに承認待ちレポートのリストに表示されるようにする。対象のレポート１１１について承認処理部１４０が管理者からの承認を受け付けると、“提示可能”のステータスに遷移する。一方、非承認を受け付けた場合は、“非承認”のステータスに遷移する。“非承認”のステータスの場合に管理者から非承認の取り消しを受け付けると、“承認申請中”のステータスに戻る。

ステータスが“提示可能”以外の場合は、作成レポート管理部１２０は、営業担当者からの指示があっても対象のレポート１１１を営業支援端末にダウンロードできないようにアクセス制御することができる。また、印刷できないように制御したり、印刷できても“ＤＲＡＦＴ”などの背景が入るように制御したり、個人情報に該当する部分やコンテンツをマスクするように制御したりすることができる。これらにより、レポート１１１において顧客の個人情報が適切に取り扱われるようにすることができる。

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

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

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

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

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

図３、図４の各画面例では、表示中の“サマリー”タブ等のタブに加えて、それぞれ、“レポート管理”のタブを有している。図５〜図９は、“レポート管理”タブにおいて営業支援端末３０上に表示される画面例および提供される機能の例について概要を示した図である。

図５では、“Dash board”タブにおける“レポート管理”タブの画面例を示している。“レポート管理”タブは、さらに、“レポート一覧”、“申請管理”、“レポート編集”の各タブを有しており、図５では“レポート一覧”タブが選択されていることを示している。“レポート一覧”タブでは、レポート１１１の作成日や、ステータス、作成者や担当者などの条件について営業担当者からの入力を受け付けて、これらを検索キーとしてレポートＤＢ１７０を検索し、抽出されたレポート１１１の情報を下段の表に一覧表示する。なお、“Dash board”タブでは複数の顧客に対するレポート１１１が対象となる。

営業担当者は、一覧に表示されたレポート１１１を選択して、編集や削除を行ったり、管理者に対する承認の申請を行ったり、定期レポートとして指定したり、雛形として設定したり等の作業を行うことができる。なお、定期レポートとして指定したレポート１１１のレポート構成は雛形と同様に取り扱われ、次回の提出月に定期レポートを作成する際にレポート構成を再利用することができる。

なお、一覧表示の右側の“ステータス”欄において、対象のレポート１１１についてのステータスを把握することができる。レポート１１１のステータスは、上述の図２に示した各ステータスのいずれかである。承認者が承認・非承認の際にコメントを入力している場合には、欄中の吹き出しアイコンを選択することでその内容を把握することも可能である。また、“確認”欄において、欄中の書類アイコンを選択することで、レポート１１１の内容自体を参照することができる。例えば、レポート１１１がＰＤＦファイルである場合には、一般的なＰＤＦビューワプログラムを起動して内容を表示させることができる。

図６では、“Dash board”タブにおける“レポート管理”タブの中の“申請管理”タブの画面例を示している。このタブは、レポート１１１の承認申請に対して承認権限を有する管理者等がユーザである場合にのみ表示もしくは選択可能とされる。“申請管理”タブでは、レポート１１１のステータスや申請日、担当者などの条件について管理者からの入力を受け付けて、これらを検索キーとしてレポートＤＢ１７０を検索し、抽出されたレポート１１１の情報を一覧表示する。

管理者は、例えば、一覧に表示されたレポート１１１から“ステータス”欄のステータスが“承認申請中”であるものを選択して、“承認”もしくは“非承認”ボタンを押下することで承認処理を行うことができる。吹き出しアイコンを選択してコメントを入力したり、“確認”欄において書類アイコンを選択してレポート１１１の内容を参照したりすることもできる。

図７では、“Client360”タブにおける“レポート管理”タブの画面例を示している。“レポート管理”タブは、さらに、“レポート一覧”、“定期レポート”、“レポート編集”の各タブを有しており、図７では“レポート一覧”タブが選択されていることを示している。“レポート一覧”タブでは、レポート１１１のステータスや作成日などの条件について営業担当者からの入力を受け付けて、これらを検索キーとしてレポートＤＢ１７０を検索し、抽出されたレポート１１１の情報を下段の表に一覧表示する。なお、“Client360”タブでは特定の顧客に対するレポート１１１が対象となる。

図５に示した“Dash board”タブにおける“レポート一覧”タブの場合と同様に、営業担当者は、一覧に表示されたレポート１１１を選択して、編集や削除を行ったり、管理者に対する承認の申請を行ったり、定期レポートとして指定したり、雛形として設定したり等の作業を行うことができる。また、同様に、“ステータス”欄においてレポート１１１のステータスを確認したり、“確認”欄においてレポート１１１の内容を参照したりすることも可能である。

図８では、“Client360”タブにおける“レポート管理”タブの中の“定期レポート”タブの画面例を示している。“定期レポート”タブでは、対象の顧客に対するレポート１１１のうち、定期レポートとして指定されたものの一覧を表示する。営業担当者は、一覧に表示された定期レポートを選択して、提出サイクルや提出月などの定期レポートの内容を編集したり、定期レポートとしての指定を削除したりすることができる。定期レポートとして設定されたレポート１１１は、例えば、レポート作成部１１０等により、提供月が近くなった際に、図３や図４に示した画面における“リード”欄にその旨を表示して営業担当者に注意を促すことができる。

図９では、“Client360”タブにおける“レポート管理”タブの中の“レポート編集”タブの画面例を示している。図９では“Client360”タブの場合を例としているが、“Dash board”タブの場合も同様である。

“レポート編集”タブでは、営業担当者は、顧客名や担当者、部店、口座番号、レポート名などのレポート１１１の属性情報を入力し、さらに、下段の表で、コンテンツ１５１のリストからレポート１１１に含めて出力するものを指定するとともに、出力の際の条件を指定することができる。各項目に付されている“★”印は必須の入力項目であることを示している。コンテンツ１５１や出力条件の指定に際しては、例えば、表の上部に配置されたボタンにより、前回レポート１１１を作成したときのレポート構成や、雛形として設定されているレポート構成を呼び出して再利用することも可能である。また、いくつかのコンテンツ１５１をグルーピングしたり、所定のコンテンツ１５１もしくはグループについては必ず出力されるようにしたりなどの制御を行ってもよい。

図９の例では、コンテンツ１５１のリストにおいて、例えば、“表紙”のコンテンツについて“出力”欄のチェックボックスにチェックがされており、出力されることを示している。正式なレポートとしてではなく参考資料の扱いとして提出する等の場合には、“表紙”のコンテンツ自体を出力しないことも可能である。さらに、“出力条件”欄において顧客名や担当者の顔写真その他の情報について項目毎に表示の有無をラジオボタンにより指定することができる。顧客名等の個人情報に該当する項目の表示を“あり”に指定した場合には、対象のレポート１１１は管理者による承認の対象として取り扱われる。各種のコンテンツ１５１について、どのようなグラフや表がどのようなレイアウトで出力されるのかを、“プレビュー”欄においてサンプル画像により確認できるようにしてもよい。

ここで設定した各コンテンツ１５１の構成については、表の下部に配置された“雛形登録”ボタンが押下されることにより、雛形管理部１３０によって新たに雛形のレポート構成として登録することが可能である。また、“登録”ボタンが押下されることにより、レポート作成部１１０によって、設定された内容に従って対応するコンテンツ１５１を順次呼び出して、営業支援情報１２や図示しないバックオフィスシステム等により保持される顧客情報等に基づいて集計を行ってグラフや表等を作成し、レイアウトした上でレポート１１１を自動的に作成する。

このように、レポート作成の際に、出力するコンテンツ１５１を営業担当者が選択することで容易に作成することを可能とし、作成効率を大きく向上させることができる。また、選択した各コンテンツ１５１の構成の情報をレポート構成の雛形として登録できるようにすることで、既存のレポート構成を再利用してレポート１１１の作成効率をさらに向上させることができる。

＜データ構成＞
図１０は、レポート管理部１００のコンテンツ管理ＤＢ１５０のデータ構成の例について概要を示した図である。コンテンツ管理ＤＢ１５０は、レポート１１１において所定の項目毎にグラフや表などを出力するモジュールからなるコンテンツ１５１についての情報を保持するテーブルであり、例えば、コンテンツＩＤ、コンテンツ名、コンテンツモジュール、出力条件、および要承認条件などの各項目を有する。

コンテンツＩＤの項目は、各コンテンツ１５１を一意に識別することができるＩＤ等の情報を保持する。コンテンツ名の項目は、対象のコンテンツ１５１についての表示名称のテキスト情報を保持する。当該名称は、例えば、上述の図９の例に示した“レポート編集”タブの画面における“コンテンツリスト”欄に表示される。コンテンツモジュールの項目は、対象のコンテンツ１５１のモジュールのパス等の呼び出しに係る情報を保持する。

出力条件の項目は、対象のコンテンツ１５１を出力する際に指定可能な各種条件、すなわちコンテンツ１５１を呼び出す際の引数やパラメータの項目を特定する情報を保持する。例えば、上述の図９の例に示した“レポート編集”タブの画面における“出力条件”欄に表示される各項目を特定する情報を保持する。必須項目か否かの情報を併せて保持してもよい。各項目の特定の手法については特に限定されず、適当な手法を適宜用いることができる。要承認条件の項目は、上記の出力条件のうち、出力することを指定された場合に、作成されたレポート１１１について管理者等による承認処理を要することになる（ステータスが“要承認”となる）項目を特定する情報を保持する。すなわち、顧客の個人情報が表示されることになる項目を特定する情報を保持する。個人情報が表示されない項目を要承認条件として指定することも可能である。

図１１は、レポート管理部１００のレポート設定ＤＢ１６０のデータ構成の例について概要を示した図である。レポート設定ＤＢ１６０は、営業担当者毎のレポート構成に係る設定情報を保持するテーブルであり、レポート構成ＤＢ１６０ａおよび定期レポート設定ＤＢ１６０ｂの各テーブルからなる。

レポート構成ＤＢ１６０ａは、営業担当者毎の既存のレポート構成の情報を保持するテーブルであり、例えば、ユーザＩＤ、前回構成、雛形１、雛形２、および雛形３などの各項目を有する。ユーザＩＤの項目は、対象の営業担当者を特定するＩＤ等の識別情報を保持する。前回構成の項目は、対象の営業担当者が前回作成したレポート１１１において設定されたレポート構成の情報を保持する。どのコンテンツ１５１が選択されてどのような出力条件が指定されているかというレポート構成の内容に係る情報自体を保持してもよいし、レポート構成の内容に係る情報を保持している設定ファイル等のパス情報を保持するようにしてもよい。

雛形１〜３の各項目は、それぞれ、対象の営業担当者により雛形として指定されているレポート構成の情報を保持する。本実施の形態では、各営業担当者は雛形を３つまで登録できるものとしているが、登録可能数はこれに限られるものではない。

定期レポート設定ＤＢ１６０ｂは、営業担当者毎に定期レポートとして提出するレポート１１１の情報を保持するテーブルであり、例えば、ユーザＩＤ、レポート名、サイクル、および提出月などの各項目を有する。ユーザＩＤの項目は、対象の営業担当者を特定するＩＤ等の識別情報を保持する。レポート名の項目は、対象の営業担当者が定期レポートとして設定したレポート１１１を特定する名称やタイトルの情報を保持する。

サイクルの項目は、対象の定期レポートについての提出サイクルを特定する情報を保持する。上述の図８の“定期レポート”タブの画面例における“サイクル”欄に示したように、例えば、“毎月”や“四半期”、“半期”、“毎年”などのサイクルを指定することができる。提供月の項目は、対象の定期レポートを提出する月のパターンを特定する情報を保持する。例えば、サイクルが“四半期”の場合は、“１、４、７、１０”など、“半期”の場合は“１、７”などの値が設定される。また、“毎年”の場合は“１”〜“１２”のいずれかの値が設定される。“毎月”の場合は“−”が設定される。

図１２は、レポート管理部１００のレポートＤＢ１７０のデータ構成の例について概要を示した図である。レポートＤＢ１７０は、各営業担当者によって作成されたレポート１１１に係る情報を過去の履歴分も含めて保持するテーブルであり、例えば、ユーザＩＤ、レポート名、レポートパス、顧客名、口座番号、担当者、申請日時、申請者、承認日時、承認者、コメント、ステータス、および作成日時などの各項目を有する。

ユーザＩＤの項目は、対象の営業担当者を特定するＩＤ等の情報を保持する。レポート名の項目は、対象の営業担当者が作成したレポート１１１を特定する名称やタイトルの情報を保持する。レポートパスの項目は、対象のレポート１１１のファイルが存在するパスの情報を保持する。顧客名および口座番号の各項目は、それぞれ、対象のレポート１１１の提出先の顧客の氏名や名称の情報および口座番号の情報を保持する。担当者の項目は、対象のレポート１１１の提出先の顧客についての担当者を特定する氏名やユーザＩＤ等の情報を保持する。

申請日時および申請者の各項目は、それぞれ、対象のレポート１１１が顧客の個人情報を含むために管理者による承認が必要である場合に、対象のレポート１１１についての申請処理を行った日時および申請者を特定する氏名やユーザＩＤ等の情報を保持する。承認日時および承認者の各項目は、それぞれ、対象のレポート１１１について承認申請がされた場合に、これに対する承認処理を行った日時および承認者を特定する氏名やユーザＩＤ等の情報を保持する。コメントの項目は、対象のレポート１１１に対して承認処理において承認者からコメントが付された場合にそのテキスト情報を保持する。ステータスの項目は、対象のレポート１１１のステータスを特定するコード値等の情報を保持する。作成日時の項目は、対象のレポート１１１が作成された日時の情報を保持する。

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

以上に説明したように、本発明の一実施の形態である運用レポート管理システム１によれば、営業担当者が、担当する顧客に対して提示して説明・報告するレポート１１１を簡易な操作により効率的に作成可能とする。例えば、予め定義された、所定の報告事項について集計等を行ってグラフや表などにレイアウトする機能を有するコンテンツを、営業担当者が自由に取捨選択して配置し、レポート構成を定義することで、当該レポート構成に基づいて実データを参照してレポート１１１を自動作成することが可能となる。また、使用したレポート構成を、再利用するために営業担当者毎に雛形として保持することで、より効率的なレポート作成が可能となる。

また、各営業担当者により作成された各レポート１１１について、それぞれ、承認状況などのステータスを管理する。これにより、レポート１１１の出力に際して、レポート１１１が顧客の個人情報等を含む場合には、手動もしくは自動により管理者等に対して承認依頼を行うワークフローを実行し、承認状況のステータスに応じてレポート１１１のファイルへのアクセス制御や印刷制御を行うことが可能となり、レポート作成をより効率的にすることができる。

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

本発明は、顧客に対して提出する運用レポート等の作成および管理を支援する運用レポート管理システムおよび運用レポート管理プログラムに利用可能である。

１…運用レポート管理システム、
１０…営業支援サーバ、１１…支援サービス、１２…営業支援情報、
２０…ネットワーク、
３０…営業支援端末、
１００…レポート管理部、１１０…レポート作成部、１１１…レポート、１２０…作成レポート管理部、１３０…雛形管理部、１４０…承認処理部、１５０…コンテンツ管理ＤＢ、１５１…コンテンツ、１６０…レポート設定ＤＢ、１６０ａ…レポート構成ＤＢ、１６０ｂ…定期レポート設定ＤＢ、１７０…レポートＤＢ。

Claims (7)

1. 金融機関の顧客に対して提出する運用レポートの作成を管理する運用レポート管理システムであって、
   予め定義された、前記運用レポートを構成する各報告内容を出力する複数のコンテンツを保持し、
   営業担当者からの、前記運用レポートに含める前記コンテンツの組み合わせの指定を受け付けて、指定された前記各コンテンツにより、前記顧客について保持されている営業活動に係る情報に基づいてそれぞれ作成された前記報告内容によって前記運用レポートを作成するレポート作成部と、
   前記営業担当者から指定された前記コンテンツの前記組み合わせに係る情報を、レポート構成の雛形として管理する雛形管理部と、を有し、
   前記レポート作成部は、前記コンテンツの前記組み合わせの指定について、前記営業担当者から指定された前記雛形に係る前記レポート構成の内容に基づいて受け付けることが可能である、運用レポート管理システム。
2. 請求項１に記載の運用レポート管理システムにおいて、
   前記レポート作成部は、指定された前記コンテンツに含まれる各項目の全部もしくは一部について、前記営業担当者からの出力条件の指定を受け付け、
   前記コンテンツは、指定された前記出力条件に基づいて前記報告内容をそれぞれ作成する、運用レポート管理システム。
3. 請求項１または２に記載の運用レポート管理システムにおいて、
   さらに、前記報告内容に前記顧客の個人情報が含まれる場合に、前記営業担当者からの指示に基づいて、前記運用レポートについて管理者による承認を申請するワークフローを実行する承認処理部を有する、運用レポート管理システム。
4. 請求項３に記載の運用レポート管理システムにおいて、
   さらに、前記各運用レポートについて、前記承認の状況を含むステータスの情報を管理する作成レポート管理部を有する、運用レポート管理システム。
5. 請求項４に記載の運用レポート管理システムにおいて、
   前記作成レポート管理部は、前記運用レポートの前記ステータスが、承認の申請が不要、もしくは承認の申請に対して承認がされた状態以外である場合は、前記営業担当者が前記運用レポートのデータを他の情報処理端末にダウンロードすること、もしくは前記運用レポートを正常に印刷出力することを許可しないよう制御する、運用レポート管理システム。
6. 請求項１〜５のいずれか１項に記載の運用レポート管理システムにおいて、
   定期的に前記顧客に対して提出する前記運用レポートに係るレポート構成の情報、および提出サイクルと提出月の情報を保持し、提出月が近づいた際に前記営業担当者にその旨を通知する、運用レポート管理システム。
7. 金融機関の顧客に対して提出する運用レポートの作成を管理する運用レポート管理システムとして機能するよう、コンピュータに処理を実行させる運用レポート管理プログラムであって、
   予め定義された、前記運用レポートを構成する各報告内容を出力する複数のコンテンツについて、営業担当者からの、前記運用レポートに含める前記コンテンツの組み合わせの指定を受け付けて、指定された前記各コンテンツにより、前記顧客について保持されている営業活動に係る情報に基づいてそれぞれ作成された前記報告内容によって前記運用レポートを作成するレポート作成処理と、
   前記営業担当者から指定された前記コンテンツの前記組み合わせに係る情報を、レポート構成の雛形として管理する雛形管理処理と、をコンピュータに実行させ、
   前記レポート作成処理は、前記コンテンツの前記組み合わせの指定について、前記営業担当者から指定された前記雛形に係る前記レポート構成の内容に基づいて受け付けることが可能である、運用レポート管理プログラム。