JP6986845B2 - 業務支援装置、業務支援方法、業務支援システム、及びプログラム - Google Patents

Description

本発明は、業務支援装置、業務支援方法、業務支援システム、及びプログラムに関する。

顧客に関する業務を支援するシステムとして、担当者が特別な操作を行わなくても顧客からのアクセス履歴を把握できるシステムが開示されている（例えば、特許文献１参照）。

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

しかしながら、特許文献１に開示された技術では、単にアクセス履歴を表示するにすぎないため、担当者は顧客に関する情報を十分に把握することができず、担当者や顧客に適切な情報提供を行うことができないという問題点があった。

本発明は、このような事情に鑑みてなされたもので、その目的は、適切な情報提供を行うことが可能な業務支援装置、業務支援方法、業務支援システム、及びプログラムを提供することにある。

上述した課題を解決するために、本発明の一態様は、業務支援装置であって、データ形式が異なる複数の顧客関連情報を取得する取得部と、前記取得部により取得された顧客関連情報から所定の情報を抽出する抽出部と、前記抽出部により抽出された前記所定の情報を共通のデータ形式で記憶する記憶部と、前記記憶部により記憶された前記所定の情報から、顧客に関する事象を推定する推定部と、前記推定部により推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連部と、前記関連部により前記事象に関連付けられた前記所定の情報を出力する出力部と、を有し、前記抽出部は、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する。

また、本発明の一態様は、上記の業務支援装置において、特定の情報と、特定の情報に対応する対応情報を予め保持し、前記所定の情報が特定の情報である場合に、前記特定の情報に対応する対応情報を、予め保持されている対応情報によって生成する生成部を有し、前記出力部は、前記生成部により生成された前記対応情報を出力することを特徴とする。

また、本発明の一態様は、上記の業務支援装置において、前記所定の情報は、金融業務に関する情報であり、前記特定の情報は、口座の変化を示す情報、営業活動に関する情報、及び顧客の状態に関する情報の少なくとも１つの情報を含むことを特徴とする。

また、本発明の一態様は、上記の業務支援装置において、前記記憶部は、前記所定の情報を時系列で記憶することを特徴とする。

また、本発明の一態様は、上記の業務支援装置において、前記所定の情報、または前記推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する導出部を有することを特徴とする。

また、本発明の一態様は、上記の業務支援装置において、前記出力部は、商品ごとに導出された指標のうち、相対的に推奨度が大きい指標が導出された商品を示す商品情報を出力することを特徴とする。

また、本発明の一態様は、上記の業務支援装置において、前記出力部は、指標が所定の基準に到達した商品を示す商品情報を出力することを特徴とする。

上述した課題を解決するために、本発明の一態様は、コンピュータが実行する業務支援方法であって、データ形式が異なる複数の顧客関連情報を取得する取得ステップと、前記取得ステップにより取得された顧客関連情報から所定の情報を抽出する抽出ステップと、前記抽出ステップにより抽出された前記所定の情報を共通のデータ形式で記憶する記憶ステップと、前記記憶ステップにより記憶された前記所定の情報から、顧客に関する事象を推定する推定ステップと、前記推定ステップにより推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連ステップと、前記関連ステップにより前記事象に関連付けられた前記所定の情報を出力する出力ステップと、を有し、前記抽出ステップは、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する。

また、本発明の一態様は、上記の業務支援方法において、前記所定の情報、または前記推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する導出ステップを有することを特徴とする。

上述した課題を解決するために、本発明の一態様は、業務支援装置、データベースサーバ、及びデバイスを含む業務支援システムであって、前記業務支援装置は、前記データベースサーバから、データ形式が異なる複数の顧客関連情報を取得する取得部と、前記取得部により取得された顧客関連情報から所定の情報を抽出する抽出部と、前記抽出部により抽出された前記所定の情報を共通のデータ形式で記憶する記憶部と、前記記憶部により記憶された前記所定の情報から、顧客に関する事象を推定する推定部と、前記推定部により推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連部と、前記関連部により前記事象に関連付けられた前記所定の情報を前記デバイスに出力する出力部と、を有し、前記抽出部は、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する。

また、本発明の一態様は、上記の業務支援方法において、前記所定の情報、または前記推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する導出部を有することを特徴とする。

上述した課題を解決するために、本発明の一態様は、業務支援装置のコンピュータに、データ形式が異なる複数の顧客関連情報を取得する取得ステップと、前記取得ステップにより取得された顧客関連情報から所定の情報を抽出する抽出ステップと、前記抽出ステップにより抽出された前記所定の情報を共通のデータ形式で記憶する記憶ステップと、前記記憶ステップにより記憶された前記所定の情報から、顧客に関する事象を推定する推定ステップと、前記推定ステップにより推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連ステップと、前記関連ステップにより前記事象に関連付けられた前記所定の情報を出力する出力ステップと、を実行させるためのプログラムであり、前記抽出ステップは、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する、プログラム。

以上説明したように、この発明によれば、適時適切な情報提供を行うことが可能な業務支援装置、業務支援方法、業務支援システム、及びプログラムを提供できる。

本発明の実施形態に係る業務支援システムを含む概略構成を示す図である。 業務支援装置の概略構成を示す図である。 共通データ形式、応対履歴データ、勘定取引データ、及びキーワード等とタグとの対応の一例を示す図である。 データ抽出部による抽出例を示す図である。 事象推定部による推定例、及びフォロー情報生成部によるフォロー情報生成例を示す図である。 一覧画面例を示す図である。 ライフステージ表示例を示す図である。 フォロー画面例を示す図である。 業務支援システムで行われる処理例を示すシーケンス図である。 業務支援装置における支援ＤＢ更新処理手順を示したフローチャートである。 業務支援装置における要求対応処理手順を示したフローチャートである。 第２実施形態における業務支援装置の概略構成を示す図である。 スコアテーブル、販促テーブル、及び顧客スコアデータを示す図である。 指標ＤＢ更新処理手順を示したフローチャートである。 販促処理の手順を示したフローチャートである。 販促情報要求受信処理手順を示したフローチャートである。 販促情報要求に応じて表示される画面の一例を示す図である。

以下の実施形態では、銀行における業務を支援するシステムを、業務支援システムの一例として説明する。
［第１実施形態］
図１は、本発明の実施形態に係る業務支援システム１００を含む概略構成を示す図である。
業務支援システム１００は、業務支援装置２００、データベース群３００（以下、データベースをＤＢと称する）、及びデバイス群４００を含む。業務支援装置２００は、ＤＢ群３００に記憶された情報を取得可能である。なお、図１には、ＤＢそのものを記載されているが、ＤＢ群３００は、不図示のデータベースサーバに記憶されている。また、業務支援装置２００は、デバイス群４００の各々と通信可能である。

ＤＢ群３００は、勘定取引ＤＢ３００−１、応対履歴ＤＢ３００−２、ＡＴＭ（Automatic Teller Machine）操作履歴ＤＢ３００−３、及び外部情報ＤＢ３００−ｎを含む。以下の説明では、ＤＢ群３００に記憶されている情報を顧客関連情報と称する。

勘定取引ＤＢには、入出金に関する情報が記憶されている。応対履歴ＤＢには、顧客との交渉内容に関する情報が記憶されている。ＡＴＭ操作履歴ＤＢには、ＡＴＭにおける入出金や記帳に関する情報のほか、ＡＴＭ操作中に販促情報として画面に出した情報に対して顧客が操作した内容を示す情報等が記憶される。外部情報ＤＢには、Ｗｅｂから得られた情報（例えば、顧客のＳＮＳ（Social Networking Service）や新聞の電子版の記事から得られた情報等）が記憶されている。上述した勘定取引ＤＢ３００−１、応対履歴ＤＢ３００−２、ＡＴＭ操作履歴ＤＢ３００−３、及び外部情報ＤＢ３００−ｎの各々に記憶される情報のデータ形式は異なっている。このように、ＤＢ群３００には、取引や取引以外の各種データが記憶されているので、業務支援装置２００は、複数のチャネルから顧客関連情報を取得することが可能である。

なお、上述したＤＢ群３００に含まれるＤＢは一例であり、顧客に関連する情報が記憶されたＤＢであればどのようなＤＢであってもよい。顧客に関連する情報が記憶されるＤＢとして、例えば顧客の嗜好、顧客の行動に関する情報を記憶したＤＢなどが挙げられる。また、顧客に関連する情報が記憶されるＤＢとして、コールセンタや窓口等における顧客との対話内容を録音した音声データ、または対話内容を音声認識技術によりテキスト化した情報を記憶したＤＢなども挙げられる。

デバイス群４００は、携帯端末４００−１、ＡＴＭ４００−２、コールセンタ端末４００−３、窓口端末４００−４を含む。携帯端末４００−１は、行員が例えば営業時に携帯する端末である。ＡＴＭ４００−２は、顧客自身が操作することで、入出金や記帳など各種銀行サービスを提供する。コールセンタ端末４００−３は、コールセンタのオペレータが使用する端末である。窓口端末４００−４は、窓口業務において使用される端末である。なお、上述したデバイス群４００に含まれるデバイスは一例であり、顧客に関連する操作が行われるデバイスであればどのようなデバイスであってもよい。顧客に関連する操作が行われるデバイスとして、顧客がネットバンキングで使用する携帯端末やパーソナルコンピュータなどが挙げられる。

図２は、業務支援装置２００の概略構成を示す図である。業務支援装置２００は、データ取得部２０１、データ抽出部２０２、データ記憶部２０３、フォロー情報生成部２０４、データ出力部２０５、事象推定部２０６、及び支援ＤＢ２０７を含む。
データ取得部２０１は、ＤＢ群３００からデータ形式が異なる複数の顧客関連情報を取得し、取得した顧客関連情報をデータ抽出部２０２に出力する。データ抽出部２０２は、データ取得部２０２により取得された顧客関連情報から所定の情報を抽出し、データ記憶部２０３に出力する。データ記憶部２０３は、データ抽出部２０２により抽出された所定の情報を共通のデータ形式で支援ＤＢ２０７に記憶する。所定の情報は銀行業務に関する情報である。共通のデータ形式については後述する。

事象推定部２０６は、データ記憶部２０３により支援ＤＢ２０７に記憶された所定の情報から、日本語解析を行うことで、顧客に関する事象を推定する推定処理を行う。具体的に、この推定処理は、文章情報から意味を推察し、機械学習を用いて自然言語処理を行い、教育を行っていくことで辞書が自動的に成長し、精度が向上するものである。

事象推定部２０６は、さらに推定された事象と、事象が推定された所定の情報とを関連付ける。顧客に関する事象として、本実施形態では、「就職」、「結婚」、「出産」、「マイホーム」、「子供進学」、「退職」、及び「相続」を例にしている。「就職」は、顧客の就職を示している。「結婚」は、顧客の結婚を示している。「出産」は、顧客または顧客の配偶者の出産を示している。「マイホーム」は、顧客のマイホームの取得を示している。「子供進学」は、顧客の子供の進学を示している。「退職」は、顧客または顧客の配偶者の退職を示している。「相続」は、顧客の相続を示している。

フォロー情報生成部２０４は、所定の情報が特定の情報である場合に、特定の情報に対応する対応情報として、フォロー情報を生成するフォロー情報生成処理を行う。フォロー情報生成部２０４は、特定の情報と、特定の情報に対応するフォロー情報を予め保持している。データ出力部２０５は、事象に関連付けられた所定の情報、及びフォロー情報をデバイス群４００に出力する。特定の情報やフォロー情報については後述する。

図３は、共通データ形式、応対履歴データ、勘定取引データ、及びキーワード等とタグとの対応の一例を示す図である。図３（ａ）は、共通データ形式を示す図である。共通データ形式は、「顧客ＩＤ」、「店番号」、「発生日時」、「チャネル」、「種別」、及び「取引内容」を含む。データ抽出部２０２は、この共通データ形式に含まれる「顧客ＩＤ」、「店番号」、「発生日時」、「チャネル」、「種別」、及び「取引内容」を、所定の情報として抽出する。
「顧客ＩＤ」は、図３（ａ）に限らず、図３（ｂ）（ｃ）においても、顧客を一意に識別するためのＩＤである。「店番号」は、勘定取引が行われた店舗、顧客応対が行われた店舗、ＡＴＭが設置された店舗等を一意に識別するための番号である。外部情報のように対応する店舗が存在しない場合、「店番号」はＮＵＬＬとする。

「発生日時」は、勘定取引が行われた日時、顧客応対が行われた日時、ＡＴＭが操作された日時である。外部情報の場合には、外部情報が取得された日時、または外部情報の配信日時である。「チャネル」は、取得したＤＢ名である。従って例えば勘定取引ＤＢ３００−１の場合は「勘定取引」である。「種別」は、勘定取引における取引種別（例えば給与振込等）、顧客応対における対応種別（例えば販促等）、ＡＴＭの操作種別（例えば入金等）、外部情報の種別（例えば、ＳＮＳ、新聞名等）である。「取引内容」は、種別に対応する情報である。例えば、種別が「給与振込」の場合は、その金額である。種別が「販促」の場合は、その販促した際の交渉内容である。種別が「入金」の場合は、その金額である。種別が「新聞名」であれば、新聞名である。この「取引内容」は、他のデータと比較して、大きいサイズ（例えば、２０００バイト）のデータが記憶可能になっている。

図３（ｂ）は、応対履歴データ形式を示す図である。応対履歴データ形式は、「顧客ＩＤ」、「店番」、「接触日時」、「交渉」、及び「交渉内容」を含む。「店番」は、共通データ形式における「店番号」に対応する。「接触日時」は、顧客との応対のために顧客と接触した日時である。「交渉」は、交渉の種別（例えば販促等）を示す。「交渉内容」は、顧客との会話内容や、顧客の反応等を示す。

図３（ｃ）は、勘定取引データ形式を示す図である。勘定取引データ形式は、「顧客ＩＤ」、「店番」、「取引日時」、「入出金」、及び「金額」を含む。「店番」は、共通データ形式における「店番号」に対応する。「取引日時」は、顧客と取引した日時を示す。「入出金」は、入出金の種別（例えば給与振込等）を示す。「金額」は、入出金された金額を示す。

図３（ａ）から図３（ｃ）に示されるように、応対履歴データ、及び勘定取引データのデータ形式は異なっている。このようにデータ形式が異なる複数の顧客関連情報からデータ抽出部２０２は、所定の情報として「顧客ＩＤ」、「店番号」、「発生日時」、「チャネル」、「種別」、及び「取引内容」に対応する情報を抽出する。そして、データ記憶部２０３は、抽出された所定の情報を共通データ形式のファイル（例えば、ＸＭＬ（eXtensible Markup Languag）形式のファイル）として支援ＤＢ２０７に記憶する。以下の説明では、共通データ形式のファイルを支援ファイルと称する。なお、支援ＤＢ２０７は、上述したようにＸＭＬ形式のＤＢであってもよいが、さらに当該ＤＢの項目ごとに規定のカラムサイズではないカラム長の制限のないＸＭＬ形式のＤＢでもよい。

図３（ｄ）は、キーワードとタグとの対応例を示す図である。図３（ｅ）は、「行動」とタグとの対応例を示す図である。タグは、後述する顧客に関する事象に対応している。また、キーワードとは、主として共通データ形式における「取引内容」で検索するための文字列である。例えば、応対履歴ＤＢ３００−２や、外部情報ＤＢ３００−ｎをもとに作成された支援ファイル（以下、「日本語解析対象ファイル」ともいう）にて日本語解析とキーワードの検索とが行われる。図３での「行動」とは、主として共通データ形式における「種別」及び「取引内容」で検索するための文字列である。例えば、勘定取引ＤＢ３００−１や、ＡＴＭ操作履歴ＤＢ３００−３をもとに作成された支援ファイル（以下、「行動対象ファイル」ともいう）にて上記文字列の検索が行われる。

業務支援装置２００は、タグごとに、当該タグに対応するキーワードまたは「行動」が対応付けられた不図示のデータベースを備えている。図３（ｄ）、図３（ｅ）は、そのデータベースにおいて対応しているタグと、キーワードまたは「行動」の一例を示している。

図３（ｄ）の例では、タグ＜出産＞にキーワード「子供」が対応付けられており、タグ＜結婚＞に「指輪」が対応づけられている。例えば、共通データ形式における「取引内容」に「子供」が含まれている場合には、文章から「出産」を示すか否かを推定し、「出産」を示すと推定された場合には、「取引内容」における「子供」にタグ＜結婚＞が付け加えられる。

図３（ｅ）の例では、タグ＜退職＞にキーワード「３００万円以上入金」が対応付けられており、タグ＜就職＞に「給与振込」が対応づけられている。例えば、共通データ形式における「種別」が口座への入金を示し、「取引内容」に示される金額が３００万円以上の場合には、「種別」にタグ＜退職＞が付け加えられる。

図４は、データ抽出部２０２による抽出例を示す図である。データ抽出部２０２は、ＤＢ群３００の各々のデータ形式ごとに、共通データ形式に対応する項目を抽出するための抽出ルールを予め保持している。
図４（ａ）は、応対履歴データからの抽出例を示している。データ抽出部２０２は、応対履歴データの「顧客ＩＤ」を共通データの「顧客ＩＤ」に対応するデータとして抽出する。データ抽出部２０２は、応対履歴データの「店番」を共通データの「店番号」に対応するデータとして抽出する。データ抽出部２０２は、応対履歴データの「接触日時」を共通データの「発生日時」に対応するデータとして抽出する。データ抽出部２０２は、応対履歴データの「交渉」を共通データの「種別」に対応するデータとして抽出する。データ抽出部２０２は、応対履歴データの「交渉内容」を共通データの「取引内容」に対応するデータとして抽出する。なお、共通データの「チャネル」は、顧客関連情報が取得されたＤＢ名の「応対履歴」となる。

図４（ｂ）は、勘定取引データからの抽出例を示している。データ抽出部２０２は、勘定取引データの「顧客ＩＤ」を共通データの「顧客ＩＤ」に対応するデータとして抽出する。データ抽出部２０２は、勘定取引データの「店番」を共通データの「店番号」に対応するデータとして抽出する。データ抽出部２０２は、勘定取引データの「取引日時」を共通データの「発生日時」に対応するデータとして抽出する。データ抽出部２０２は、勘定取引データの「入出金」を共通データの「種別」に対応するデータとして抽出する。データ抽出部２０２は、勘定取引データの「金額」を共通データの「取引内容」に対応するデータとして抽出する。なお、共通データの「チャネル」は、顧客関連情報が取得されたＤＢ名の「勘定取引」となる。

上述したように、抽出されたデータは、支援ファイルとして支援ＤＢ２０７に記憶されるが、データ記憶部２０３は、支援ＤＢ２０７の顧客ごとに設けられたフォルダ内に１つの支援ファイルとしてに記憶する。こうして記憶された支援ファイルに対して、事象推定部２０６、及びフォロー情報生成部２０４が処理を行う。

図５は、事象推定部２０６による推定例、及びフォロー情報生成部２０４によるフォロー情報生成例を示す図である。図５（ａ）は、事象推定部２０６による推定例を示している。図５（ａ）では、図４（ａ）で示した応対履歴データから抽出されたデータが記憶された支援ファイル（ファイルＡとする）に対して処理を行った場合の推定例を示している。事象推定部２０６は、ファイルＡの「取引内容」に示される日本語を解析し、上述した事象に該当すると判定された文言をタグで関連付ける。

図５（ａ）において、事象推定部２０６は、「学資保険に興味を持たれてた」、という日本語から、事象として出産の可能性があると判定し、「学資保険」にタグ＜出産＞を付け加えたものをファイルＡ１として、顧客ＩＤが１１１１１のフォルダに記憶する。このように、事象推定部２０６は、事象と、事象が推定された「取引内容」とをタグによって関連付ける。タグによって関連付けることにより、例えば、「出産」に関する支援ファイルのみを取得する場合には、フォルダ内の支援ファイルに対してタグによる検索を行うことにより、事象に関連した支援ファイルのみを抽出することができる。

図５（ｂ）は、フォロー情報生成部２０４によるフォロー情報生成例を示している。図５（ｂ）では、図４（ｂ）で示した勘定取引データから抽出されたデータが記憶された支援ファイル（ファイルＢとする）に対して処理を行った場合のフォロー情報生成例を示している。フォロー情報生成部２０４は、上述したように所定の情報が特定の情報である場合に、特定の情報に対応する対応情報を生成する。本実施形態における特定の情報は、口座の変化を示す情報（例えば、給与振込、退職金振込み等）、営業活動に関する情報（ある商品を提案中であること、ある商品を顧客から断られたこと等）、及び顧客の状態（例えば、相続を行ったこと、クレーム対応が発生したこと）に関する情報の少なくとも１つの情報を含む。

ファイルＢの「種別」に示される「給与振込」が特定の情報に該当するため、フォロー情報生成部２０４は、「給与振込」に対応するフォロー情報である「定期預金をお勧めしてください」というフォロー情報を生成する。生成されたフォロー情報は、ファイルＢ１として、顧客ＩＤが１２３４５６のフォルダに記憶される。

図６は、支援ＤＢ２０７に記憶された顧客のフォルダ内に記憶された支援ファイルに基づく内容を窓口端末４００−４に表示した一覧画面例を示す図である。一覧画面は、チャネル欄６０１、内容欄６０２、及び登録日欄６０３で構成される。チャネル欄６０１には、内容欄６０２に表示されている内容の情報源となったＤＢ名に基づき、予め定められている名称が表示される。なお、特にチャネルを表示する必要がないもの（例えば、振込、振替等）の場合は、チャネルは表示されない。内容欄６０２には、共通データの「種別」または「取引内容」に基づくものが表示される。登録日欄６０３には、共通データの「発生日時」が表示される。この登録日欄６０３に示されるように、一覧画面では時系列で表示される。また、一覧画面では、ソート、ある項目について記載されたもののみを一覧表示することも可能である。

図７は、顧客の事象に関する内容を窓口端末４００−４に表示したライフステージ表示例を示す図である。図７（ａ）は、ライフステージ画面７００を示している。ライフステージ画面７００は、窓口端末４００−４が業務支援装置２００にライフステージ画面の生成を要求し、業務支援装置２００がフォルダ内の支援ファイルに基づきライフステージ画面を表示するための画面データを生成し、生成した画面データを窓口端末４００−４に送信することで、窓口端末４００−４にライフステージ画面が表示される。

ライフステージ画面７００は、各事象ごとに事象アイコン等で構成される。例えば、事象が「就職」の場合を例にして説明すると、事象アイコン７０２、登録ボタン７０３、及び確定日時欄７０４が表示される。事象アイコン及び登録ボタンは、図７（ａ）に示されるように、各事象ごと設けられる。また、確定日時欄は、事象が確定した事象のみ設けられる。事象アイコンが選択されると、図７（ｂ）の個別事象一覧画面７１０が表示される。

事象アイコンには、３種類のアイコンＡ、Ｂ、Ｃが存在する。アイコンＡは、事象アイコン７０２のように、事象が確定していることを示す白文字で黒背景のアイコンである。アイコンＢは、事象アイコン７０５のように、事象が事象推定部２０６により推定されたことを示す黒文字に網掛けがなされたアイコンである。アイコンＣは、事象アイコン７０６のように、事象の確定や推定が行われていないことを示す黒文字に白背景のアイコンである。

業務支援装置２００は、ライフステージ画面の生成が要求されると、フォルダ内に事象の確定を示す支援ファイルが存在する場合には、当該事象についてアイコンＡと確定日時欄を含む画面データを生成する。業務支援装置２００は、フォルダ内に事象の確定を示す支援ファイルが存在せず、かつ事象が推定された支援ファイルが存在する場合には、当該事象についてアイコンＢの画面データを生成する。業務支援装置２００は、フォルダ内に事象の確定を示す支援ファイルが存在せず、かつ事象が推定された支援ファイルが存在しない場合には、当該事象についてアイコンＣの画面データを生成する。

図７（ｂ）は、個別事象一覧画面７１０を示している。個別事象一覧画面７１０は、個々の事象ごとに、当該事象に関連する情報を表示する画面である。個別事象一覧画面７１０は、チャネル欄７１１、内容欄７１２、登録時間欄７１３で構成される。チャネル欄７１１には、内容欄７１２に表示されている内容の情報源となったＤＢ名に基づき、予め定められている名称が表示される。なお、特にチャネルを表示する必要がないもの（例えば、事象の確定や推定等）の場合は、チャネルは表示されない。内容欄７１２には、共通データの「種別」または「取引内容」に基づくものが表示される。登録時間欄７１３には、共通データの「発生日時」が表示される。この登録時間欄７１３に示されるように、個別事象一覧画面では時系列で表示される。

さらに、事象が確定された場合には、その事象が確定された根拠が表示される。図７（ｂ）には、「住宅（マイホーム）」が確定されたことが表示されるとともに、その事象が確定された根拠である「２０１０年に○○銀行で住宅ローンを借りて、新築の戸建てを購入とのこと」が表示されている。こうした根拠は、登録ボタン選択時に表示される登録画面により行員により入力される。

図７（ｃ）は、登録画面７２０を示している。登録画面７２０は、ラジオボタン７２１、判定根拠欄７２２、及び登録ボタン７２３で構成される。事象を確定する場合、行員は、ラジオボタン７２１にて「登録」を選択し、判定根拠欄７２２にその根拠を入力する。そして登録ボタン７２３を選択することにより、事象が確定される。登録ボタン７２３が選択されると、窓口端末４００−４は、業務支援装置２００に事象の確定と、上記根拠とを示す確定要求を送信する。業務支援装置２００は、確定要求を受信すると、事象が確定されたこと、及び根拠が記載された支援ファイルを、顧客に対応するフォルダに作成する。

ラジオボタン７２１の「対象外」は、事象の確定を取り消すためのボタンである。例えば、「２０１０年に○○銀行で住宅ローンを借りて、新築の戸建てを購入」したのが、顧客の親戚の話であった場合などのように、根拠に誤りがあることが分かったときは、行員はラジオボタン７２１の「対象外」を選択し、判定根拠欄７２２に「親戚の話でした」などと入力し、登録ボタン７２３を選択することにより、確定を取り消すことができる。登録ボタン７２３が選択されると、窓口端末４００−４は、業務支援装置２００に事象が取り消られたことと、上記根拠とを示す取り消し要求を送信する。業務支援装置２００は、取り消し要求を受信すると、事象が取り消されたこと、及び根拠が記載された支援ファイルを、顧客に対応するフォルダに作成する。

図８は、フォロー情報を窓口端末４００−４に表示したフォロー画面例を示す図である。フォロー情報には、定期預金などの商品を勧めるように行員に促す情報の他に、「お礼」と「お詫び」を行員に促す情報がある。図８（ａ）は、フォロー情報が「お礼」を行員に促す情報の場合に表示されるフォロー画面例を示している。図８（ａ）のフォロー画面には、定期預金の預入や、口座開設した場合に、行員にお礼を伝えるように促すメッセージが表示される。図８（ｂ）は、フォロー情報が「お詫び」を行員に促す情報の場合に表示されるフォロー画面例を示している。図８（ｂ）のフォロー画面には、クレーム対応があったため、行員に気をつけるように促すメッセージが表示される。

図９は、業務支援システム１００で行われる処理例を示すシーケンス図である。図９のシーケンス図は、一例として勘定取引ＤＢ３００−１、業務支援装置２００、窓口端末４００−４との間で行われる処理例を示している。なお、上述したように、勘定取引ＤＢ３００−１はデータベースサーバに記憶されているので、実際にはデータベースサーバと業務支援システム１００とがやり取りを行うが、ここでは勘定取引ＤＢ３００−１として説明する。

業務支援装置２００は、顧客関連情報を取得するために、勘定取引ＤＢ３００−１にデータ要求を送信する（ステップＳ１０１）。データ要求を受信した勘定取引ＤＢ３００−１は、勘定取引データを送信する（ステップＳ１０２）。業務支援装置２００のデータ抽出部２０２は、勘定取引データから共通データを抽出し、データ記憶部２０３は、共通データが記録された支援ファイルを顧客ＩＤをもとに顧客フォルダに振り分ける（ステップＳ１０３）。

業務支援装置２００の事象推定部２０６は、顧客フォルダに振り分けられた支援ファイルに対して、推定処理を行う（ステップＳ１０４）。次いで、業務支援装置２００のフォロー情報生成部２０４は、顧客フォルダに振り分けられた支援ファイルに対して、フォロー情報生成処理を行う（ステップＳ１０５）。

窓口端末４００−４は、ライフステージ画面を表示するために、ステージ画面要求を、ステージ画面を表示したい顧客ＩＤとともに業務支援装置２００に送信する（ステップＳ１０６）。業務支援装置２００のデータ出力部２０５は、ステージ画面要求を受信すると、顧客ＩＤに対応するフォルダ内の支援ファイルから、ライフステージ画面を表示するための画面データを生成し、生成した画面データをステージ画面応答として窓口端末４００−４に送信する（ステップＳ１０７）。窓口端末４００−４は、登録画面７２０において登録ボタン７２３が選択されると、業務支援装置２００に確定要求を送信する（ステップＳ１０８）。業務支援装置２００は、確定要求を受信すると、事象が確定されたこと、及び根拠が記載された支援ファイルを、顧客に対応するフォルダに作成する（ステップＳ１０９）。

図１０は、業務支援装置２００における支援ＤＢ更新処理手順を示したフローチャートである。まず、業務支援装置２００のデータ取得部２０１は、ＤＢ群３００から顧客関連情報を取得する（ステップＳ２０１）。次いで、データ抽出部２０２は、取得された顧客関連情報から共通データを抽出する（ステップＳ２０２）。データ記憶部２０３は、共通データが記憶された支援ファイルを支援ＤＢ２０７に記憶する（ステップＳ２０３）。事象推定部２０６は、新たに記憶された支援ファイルに対して推定処理を行い、フォロー情報生成部２０４は、フォロー情報生成処理を行う（ステップＳ２０４）。

事象推定部２０６により推定処理において事象が推定されたか、またはフォロー情報生成部２０４によりフォロー情報生成処理においてフォロー情報が生成されたか否かが判定される（ステップＳ２０５）。事象が推定されず、かつフォロー情報が生成されない場合には（ステップＳ２０５：ＮＯ）、本処理を終了する。事象が推定された場合には（ステップＳ２０５：ＹＥＳ）、事象推定部２０６は、対応する支援ファイルを支援ＤＢ２０７に追加する（ステップＳ２０６）。フォロー情報が生成された場合には（ステップＳ２０５：ＹＥＳ）、フォロー情報生成部２０４は、対応する支援ファイルを支援ＤＢ２０７に追加する（ステップＳ２０６）。

図１１は、業務支援装置２００における要求対応処理手順を示したフローチャートである。この要求処理手順は、デバイス群４００から送信される要求が、ステージ画面要求、一覧画面要求、個別事象一覧画面要求、フォロー情報要求、及び確定要求の場合の処理例を示している。
業務支援装置２００は、ステージ画面要求を受信したか否かを判定する（ステップＳ３０１）。ステージ画面要求を受信した場合には（ステップＳ３０１：ＹＥＳ）、データ出力部２０５は、支援ＤＢ２０７の顧客フォルダ内の全支援ファイルを取得する（ステップＳ３０２）。データ出力部２０５は、ライフステージ画面の画面データを生成する（ステップＳ３０３）。そして、データ出力部２０５は、画面データを送信して（ステップＳ３０４）、本処理を終了する。

ステップＳ３０１において、ステージ画面要求を受信していない場合には（ステップＳ３０１：ＮＯ）、業務支援装置２００は、一覧画面要求を受信したか否かを判定する（ステップＳ３０５）。一覧画面要求を受信した場合には（ステップＳ３０５：ＹＥＳ）、データ出力部２０５は、支援ＤＢ２０７の顧客フォルダ内の全支援ファイルを取得する（ステップＳ３０６）。データ出力部２０５は、一覧画面の画面データを生成する（ステップＳ３０７）。そして、データ出力部２０５は、画面データを送信して（ステップＳ３０４）、本処理を終了する。

ステップＳ３０５において、一覧画面要求を受信していない場合には（ステップＳ３０５：ＮＯ）、業務支援装置２００は、個別事象一覧画面要求を受信したか否かを判定する（ステップＳ３０８）。個別事象一覧画面要求を受信した場合には（ステップＳ３０８：ＹＥＳ）、データ出力部２０５は、支援ＤＢ２０７の顧客フォルダ内の事象に関連する支援ファイルを取得する（ステップＳ３０９）。データ出力部２０５は、個別事象一覧画面の画面データを生成する（ステップＳ３１０）。そして、データ出力部２０５は、画面データを送信して（ステップＳ３０４）、本処理を終了する。

ステップＳ３０８において、個別事象一覧画面要求を受信していない場合には（ステップＳ３０８：ＮＯ）、業務支援装置２００は、フォロー情報要求を受信したか否かを判定する（ステップＳ３１１）。フォロー情報要求を受信した場合には（ステップＳ３１１：ＹＥＳ）、データ出力部２０５は、支援ＤＢ２０７の顧客フォルダ内のフォロー情報を示す支援ファイルを取得する（ステップＳ３１２）。データ出力部２０５は、「お礼」と「注意情報」とを示すフォロー画面の画面データを生成する（ステップＳ３１３）。そして、データ出力部２０５は、画面データを送信して（ステップＳ３０４）、本処理を終了する。

ステップＳ３１１において、フォロー情報要求を受信していない場合には（ステップＳ３１１：ＮＯ）、確定要求を受信したこととなるので、データ記憶部２０３は、事象が確定されたこと、及び根拠が記載された支援ファイルを、顧客に対応するフォルダに作成して（ステップＳ３１４）、本処理を終了する。

以上説明したように、本実施形態における業務支援装置は、データ形式（例えば、応対履歴データ形式、勘定取引データ形式等）が異なる複数の顧客関連情報（例えば、応対履歴データ、勘定取引データ、ＡＴＭ操作履歴、外部情報等）を取得する取得部（例えば、データ取得部２０１等）と、前記取得部により取得された顧客関連情報から所定の情報（例えば、共通データ形式のデータ等）を抽出する抽出部（例えば、データ抽出部等）と、前記抽出部により抽出された前記所定の情報を共通のデータ形式で記憶する記憶部（例えば、データ記憶部２０３等）と、前記記憶部により記憶された前記所定の情報から、顧客に関する事象（例えば、就職、結婚、出産、マイホーム、子供進学、退職、相続等）を推定する推定部（例えば、事象推定部２０６等）と、前記推定部により推定された事象と、前記事象が推定された前記所定の情報とを関連付ける（例えば、事象が推定された支援ファイルに事象に該当すると判定された文言をタグで関連付けた支援ファイルを作成する等）関連部（例えば、事象推定部２０６等）と、前記関連部により前記事象に関連付けられた所定の情報を出力する出力部（例えば、データ出力部等）と、を有する。

本実施形態では、顧客関連情報として、応対履歴データ、勘定取引データ、ＡＴＭ操作履歴、及び外部情報を例にしたが、これに限るものではない。例えば、ネットバンキングに関するデータ、ローン審査情報、他銀行との取引情報など顧客や業務に関連する情報であれば、どのような情報であってもよい。また、勘定取引データとして、普通預金（口座開設・閉鎖、入出金）、定期預金（新約、預入、支払、解約）、カードローン（開設・閉鎖、実行・回収）、ローン（証貸）、振込・振替、注意情報、契約変更（住所変更、名字変更、等）を用いるようにしてもよい。

本実施形態では、所定の情報として「顧客ＩＤ」、「店番号」、「発生日時」、「チャネル」、「種別」、及び「取引内容」を例にしたが、これに限るものではない。これらの各情報のうちの一部の情報、または各情報の一部または全部と他の情報であってもよい。本実施形態では、異なるデータ形式の情報を共通データ形式の情報として記憶することで、情報を一元管理することが可能となる。また、共通データ形式であっても、顧客や、顧客の行為等を特定できるので有用性が担保される。さらに、「取引内容」のデータサイズが大きいため、交渉内容等を詳細に記憶することができる。また、「取引内容」のデータサイズは大きいため、フリースペースとしての活用することができる。例えば、共通データには含まれないが、顧客関連情報には含まれる種々のデータを記憶することが可能である。情報を共通データ形式で保存することにより、情報の表示形式も統一させることができるので、行員等は顧客に関する情報を十分に把握することができるようになる。また、事象を推定することにより、行員等に適切な情報提供を行うことが可能となる。

本実施形態では、事象として、就職、結婚、出産、マイホーム、子供進学、退職、及び相続を例にしたが、これに限るものではない。例えば、家族情報、保有動産（例えば車両）・不動産、保険、及び他行取引等が事象の例として挙げられる。本実施形態における事象推定部２０６は、例えばマイカーローンの借り入れがあった場合に車両の保有を推定する。また、事象推定部２０６は、例えば固定資産税の引き落としが発生した場合、不動産の保有を推定する。また、事象推定部２０６は、保険会社に対する口座振替が発生した場合や、生保窓口販売の取引（新契約、移動、消滅、等）が発生した場合に、保険の保有や解約を推定する。

本実施形態では、事象と、当該事象に該当すると判定された文言をタグを用いて関連付けているが、これに限るものではない。例えば、事象ごとにファイルを作成し、このファイルに、事象に該当すると判定された文言と、ファイル名とを記憶するようにしてもよい。

本実施形態におけるライフステージ画面に、家族情報の欄を設けるようにしてもよい。家族情報として、家族構成、口座の実質的管理者等が例として挙げられる。また、上述した支援ファイルにセールス履歴を記憶しておき、一覧画面や個別事象一覧画面において、セールス履歴を表示するようにしてもよい。セールス履歴として、例えば、「マイカーローンについて詳しく知りたいとのことで資料を再送する事とした。」、「○○銀行で借換したばかりであり、住宅ローンは不要とのこと。」、「投資信託２件で１千万円、保険商品１件で２０万円を購入して頂いた」などを表示する。このようにすることで、行員が情報を共有でき、無駄な営業を排除できたり、購入可能性の高いものをお勧めできるようになるため、効率的な営業活動を行うことができる。

事象推定部２０６は、顧客の連絡時間帯候補を推定することも可能である。例えば、コールセンタ端末４００−３が、業務支援装置２００に対して、「○月○日○時○分は不在でした」、「Ｘ月Ｘ日Ｘ時Ｘ分はつながりました」などの通話実績を送信することで、業務支援装置２００は、それらを支援ファイルとして支援ＤＢ２０７に記憶する。この支援ファイルに対して、事象推定部２０６は、日本語解析による推定で、つながらなかった時間帯、つながった時間帯を判定することができる。その判定結果をまとめることにより、時間帯ごとのつながった回数、つながらなかった回数を業務支援装置２００が記憶しておき、コールセンタ端末４００−３に表示させるようにする。このようにすることで、コールセンタの担当者が情報を共有でき、無駄な連絡を排除できたり、つながりやすい時間帯に連絡できるようになるため、効率的な営業活動を行うことができる。

本実施形態では、３種類の事象アイコンが設けられていたが、これに限るものではない。例えば、事象が事象推定部２０６により推定されたことを示すアイコンＢを、推定度合いによって色を濃くするなどして段階的に表示するようにしてもよい。例えば、ある事象について、推定されたファイルが所定数未満の場合は、薄く表示し、そうでない場合には、濃いめに表示するようにしてもよい。このようにすることにより、行員は事象の大体の確度を把握できるので、効率的な営業活動を行うことができる。

本実施形態では、業務支援装置を金融業務のうちの銀行業務に適用したが、これに限るものではない。例えば他の金融業務（保険業務、証券業務、リース業務、信販業務、貸金業務等）であっても、顧客関連情報が存在し、金融商品等の営業が行われるため、本実施形態で説明した業務支援装置を適用することができる。例えば、保険会社では、保険口座の開設等が可能であり、そして保険口座は契約の変更や保険金の支払い等により変化するため、フォロー情報生成部２０４は、それらの変化に対応する対応情報を生成することができる。

［第２実施形態］
次に、第２実施形態について説明する。第２実施形態は、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標（以下、「スコア」ともいう）を顧客ごとに導出する形態である。スコアが大きいほど推奨度が大きい。このスコアが所定の基準値に到達した商品を示す商品情報などがデバイス群４００に出力される。
図１２は、第２実施形態における業務支援装置５００の概略構成を示す図である。業務支援装置５００は、図２に示した構成に、新たに指標導出部２１０、及び指標ＤＢ２１１が加わった構成となっている。従って、業務支援装置５００は、第１実施形態で説明した全ての機能を含む。

指標導出部２１０は、所定の情報から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する。指標導出部２１０は、データ記憶部２０３により支援ＤＢ２０７に記憶された所定の情報に対し、日本語解析を行うことで、顧客に関する事象を推定したり、「行動」に基づいて、後述するスコアテーブルを用いてスコアを導出する。日本語解析によってスコアの増減対象となったものを、以下の説明ではスコア対象とも表現する。指標ＤＢ２１１は、指標導出部２１０により導出されたスコアを記憶したＤＢである。なお、指標導出部２１０は、事象推定部２０６による推定内容が示された支援ファイル（例えば、図５（ａ）のファイルＡ１など）から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出してもよい。すなわち、推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出してもよい。

図１３（ａ）は、スコアテーブルを示す図である。スコアテーブルは、キーワード及び「行動」ごとに、商品（図１３（ａ）ではローン、運用）に対するスコアが割り当てられたテーブルであり、指標導出部２１０が保持している。
指標導出部２１０は、例えば事象として「就職」を推定した場合には、ローンについてのスコアを２だけ加算し、運用についてのスコアを５だけ加算する。同様に、指標導出部２１０は、例えば「１００万円以上の入金」という「行動」に該当するものが存在した場合には、運用についてのスコアを２０だけ加算する。なお、図１３（ａ）では、スコアに加算するもののみが記載されているが、減算するものもある。例えば、引き落としができなかったという「行動」に該当するものが存在した場合には、運用のスコアが減算される。

図１３（ｂ）は、販促テーブルを示す図である。販促テーブルは、商品ごとに設けられた基準値と通知方法とを示す。基準値は、商品情報を出力するか否かを判定するための値である。データ出力部２０５は、スコアが基準に到達した商品を示す商品情報を出力する。通知方法は、商品情報の顧客への通知方法を示している。通知方法には、図１３（ｂ）に記載されているメールやＤＭ（Direct Mail）の他に、電話、窓口での対応などがある。
以上より、図１３（ｂ）における例えばローンは、スコアが５０に到達するとメールにより商品情報が出力される。

図１３（ｃ）は、指標ＤＢ２１１に記憶されている顧客スコアデータを示す図である。顧客スコアデータは、顧客ごと、また商品ごとに設けられる。例えば、商品が２つの場合には、顧客スコアデータは、１人の顧客に対して２つ設けられる。
顧客スコアデータは、顧客ＩＤ、商品ＩＤ、１月から１２月までのスコア、合計、及び状態フラグで構成される。商品ＩＤは、当該顧客スコアデータが対応する商品を示す。顧客スコアデータには、月ごとにスコアが設けられている。月初めに、全ての顧客スコアデータにおける今月のスコアが０で更新される。また、年が変われば、１月から上書きされていく。従って、月のスコアの有効期限は１年となっている。このように有効期限を設けることで、古い情報を排除することができる。
顧客スコアデータの更新タイミングは、顧客に対応する支援ファイルが新規に作成されたときである。ただし、新規支援ファイルにスコア対象が存在しない場合には、顧客スコアデータは更新されない。

顧客スコアデータにおける合計は、１月から１２月までのスコアの合計である。状態フラグは、販促状態を示すフラグであり、４つの値（未到達、通知済、未通知、購入済）を示す。未到達は、スコアが上記基準値に到達していないことを示す。通知済は、スコアが基準値に到達し、メールなどで顧客に商品をお勧めしたこと、またはＤＭ（Direct Mail）を送信したこと、または送信することをを示す。未通知は、スコアが基準値に到達しているが、未だに顧客に商品をお勧めしていないことをを示す。この未通知は、例えば、電話や窓口で顧客に商品を勧める場合に用いられる。電話や窓口で顧客に商品を勧めた場合には、フラグには通知済がセットされる。購入済みは、顧客が商品を購入済みであることを示す。

図１４は、業務支援装置５００における指標ＤＢ更新処理手順を示したフローチャートである。このフローチャートは、１人の顧客に対する更新処理手順を示している。
業務支援装置５００の指標導出部２１０は、新規支援ファイルが作成されたか否かを判定する（ステップＳ４０１）。データ記憶部２０３が新規支援ファイルを作成すると、顧客ＩＤとファイル名とを指標導出部２１０に通知するので、指標導出部２１０は、この通知を受信したことをもって新規支援ファイルが作成されたと判定する。

新規支援ファイルが作成されると（ステップＳ４０１：ＹＥＳ）、新規支援ファイルが日本語解析対象ファイルか否かを判定する（ステップＳ４０２）。新規支援ファイルが日本語解析対象ファイルの場合には（ステップＳ４０２：ＹＥＳ）、指標導出部２１０は、検索された支援ファイルに対し、日本語解析を行う（ステップＳ４０３）。指標導出部２１０は、日本語解析を行った結果、スコア対象が存在したか否かを判定する（ステップＳ４０４）。スコア対象が存在しなかった場合には（ステップＳ４０４：ＮＯ）、指標導出部２１０は、本処理を終了する。スコア対象が存在した場合には（ステップＳ４０４：ＹＥＳ）、指標導出部２１０は、ステップＳ４０７に進む。

新規支援ファイルが日本語解析対象ファイルではない場合には（ステップＳ４０２：ＮＯ）、指標導出部２１０は、新規支援ファイルを行動対象ファイルとして、スコア対象の「行動」を検索する（ステップＳ４０５）。指標導出部２１０は、検索を行った結果、スコア対象の「行動」が存在したか否かを判定する（ステップＳ４０６）。スコア対象の行動が存在しなかった場合には（ステップＳ４０６：ＹＥＳ）、指標導出部２１０は、本処理を終了する。スコア対象の行動が存在した場合には（ステップＳ４０６：ＹＥＳ）、指標導出部２１０は、ステップＳ４０７に進む。

指標導出部２１０は、スコアを加減算する（ステップＳ４０７）。ここでは、支援ファイルに存在した全てのスコア対象に対応するスコアの加減算が行われる。例えば、スコア対象が「マイホーム」の場合は、ローンのスコアが１０だけ加算されるため、ローンに対応する顧客スコアデータにおいて加算が行われる。一方、スコア対象が「結婚」の場合は、ローンのスコアが５だけ加算され、運用のスコアが５だけ加算されるため、ローンと運用の各々に対応する２つの顧客スコアデータにおいて加算が行われる。

指標導出部２１０は、今月のスコアを更新する（ステップＳ４０８）。ここでは、ステップＳ４０７の加減算で算出された値を現在のスコアに加算する更新が行われる。指標導出部２１０は、合計を更新して（ステップＳ４０９）、更新されたスコアに応じて販促処理を行い（ステップＳ４１０）、本処理を終了する。

図１５は、指標ＤＢ更新処理のステップＳ４０８の販促処理の手順を示したフローチャートである。指標導出部２１０は、スコアが基準点に初めて到達した商品があるか否かを判定する（ステップＳ５０１）。基準点に初めて到達した商品であるか否かは、スコアが基準点に到達し、かつ状態フラグが未到達を示しているか否かで判定できる。スコアが基準点に初めて到達した商品がない場合には（ステップＳ５０１：ＮＯ）、指標導出部２１０は、販促を行うことなくそのまま処理を終了する。
スコアが基準点に初めて到達した商品がある場合には（ステップＳ５０１：ＹＥＳ）、指標導出部２１０は、販促テーブルを参照して、通知方法がメールか否かを判定する（ステップＳ５０２）。通知方法がメールの場合には（ステップＳ５０２：ＹＥＳ）、データ出力部２０５は、顧客あてに商品情報を示す販促メールを送信する（ステップＳ５０３）。指標導出部２１０は、状態フラグに通知済をセットして（ステップＳ５０４）、本処理を終了する。

ステップＳ５０２において、通知方法がメールではない場合には（ステップＳ５０２：ＮＯ）、指標導出部２１０は、通知方法がＤＭか否かを判定する（ステップＳ５０５）。通知方法がＤＭの場合には（ステップＳ５０５：ＹＥＳ）、指標導出部２１０は、顧客ＩＤをＤＭ送信リストに追加し（ステップＳ５０６）、上記ステップＳ５０４に進む。このＤＭ送信リストは、データ出力部２０５により、銀行のＤＭ送付担当のＰＣ（不図示）に出力され、その後ＤＭが送信される。
通知方法がＤＭではない場合には（ステップＳ５０５：ＮＯ）、指標導出部２１０は、状態フラグに未通知をセットして（ステップＳ５０７）、本処理を終了する。このように、業務支援装置５００は、スコアが所定の基準に到達した商品を示す商品情報を出力する。

次に説明する販促情報要求受信処理は、デバイス群４００、顧客のＰＣ、顧客のスマートフォンから販促情報要求を受信し、スコアに応じて商品情報を含む販促情報を出力する処理である。販促情報要求はパラメータとして顧客ＩＤを含んでいる。
図１６は、販促情報要求受信処理手順を示したフローチャートである。指標導出部２１０は、販促情報要求を受信すると、顧客ＩＤでスコアＤＢを検索する（ステップＳ６０１）。指標導出部２１０は、検索して得られた顧客スコアデータに示される合計が大きい順に商品をソートする（ステップＳ６０２）。

指標導出部２１０は、販促情報要求の要求元が行員端末か否かを判定する（ステップＳ６０３）。ここでの行員端末とは、携帯端末４００−１、コールセンタ端末４００−３、窓口端末４００−４のような行員が利用する端末である。要求元が行員端末の場合には（ステップＳ６０３：ＹＥＳ）、指標導出部２１０は、後述するスコアリストを示す画面データを生成する（ステップＳ６０４）。データ出力部２０５は、生成した画面データを要求元に出力して（ステップＳ６０５）、本処理を終了する。
要求元が行員端末ではない場合には（ステップＳ６０３：ＮＯ）、指標導出部２１０は、要求元が顧客ＰＣか否かを判定する（ステップＳ６０６）。要求元が顧客ＰＣの場合には（ステップＳ６０６：ＹＥＳ）、指標導出部２１０は、未通知の商品でスコア１位から３位の商品を示すインターネットバンキング画面の画面データを生成する（ステップＳ６０７）。データ出力部２０５は、生成した画面データを要求元に出力して（ステップＳ６０５）、本処理を終了する。スコア１位から３位の３つの商品を示す画面データを生成する理由は、ＰＣの画面はスマートフォンやＡＴＭ４００−２と比較して広く、広告スペースを広く設けることが出来るためである。

要求元が顧客ＰＣではない場合には（ステップＳ６０６：ＮＯ）、指標導出部２１０は、要求元は顧客のスマートフォンかＡＴＭ４００−２と判定し、未通知の商品でスコア１位の商品を示す画面データを生成する（ステップＳ６０８）。データ出力部２０５は、生成した画面データを要求元に出力して（ステップＳ６０５）、本処理を終了する。スコア１位の商品のみを示す画面データを生成する理由は、スマートフォンやＡＴＭ４００−２の画面はＰＣの画面と比較して狭く、広告スペースを広く設けることが出来ないためである。要求元がＡＴＭ４００−２の場合には、ＡＴＭ用の画面が生成され、要求元がスマートフォンの場合には、スマートフォン用の画面が生成される。

図１７は、販促情報要求に応じて表示される画面の一例を示す図である。図１７（ａ）は、スコアリスト画面を示す図である。このスコアリスト画面は、上記ステップＳ６０４で生成された画面データを表示したものである。図１７（ａ）に示されるように、スコアリスト画面には、スコアが高い順に商品名、スコア、基準値、及び状態とが含まれる。このうちの「状態」は、上述した状態フラグに示される内容である。
スコアリスト画面により、例えば「状態」が未通知の場合には、行員は顧客に対して商品の営業活動を行うことができたり、スコアが基準値に近い場合は、例外的に商品の営業活動を行うこともできる。

図１７（ｂ）は、インターネットバンキング画面を示す図である。このインターネットバンキング画面は、上記ステップＳ６０７で生成された画面データを表示したものである。図１７（ｂ）に示されるように未通知の商品でスコア１位から３位の３つの商品の広告８０１が表示されている。
インターネットバンキング画面にスコア１位から３位の３つの商品の広告を表示することで、顧客により適した広告を表示できるので、スコアを考慮しない場合と比較して、効率よく営業活動を行うことができる。このように、業務支援装置５００は、商品ごとに導出された指標のうち、相対的に推奨度が大きい指標が導出された商品を示す商品情報を出力する。

図１７（ｃ）は、ＡＴＭ４００−２に表示された画面を示す図である。この画面は、上記ステップＳ６０８で生成された画面データを表示したものである。図１７（ｃ）に示されるように未通知の商品でスコア１位の商品の広告８０２が表示されている。
ＡＴＭ４００−２やスマートフォンの画面にスコア１位の商品の広告を表示することで、画面の大きさに適し、最もスコアの大きい広告を表示できるので、スコアを考慮しない場合と比較して、効率よく営業活動を行うことができる。

また、上記実施形態では、スコア対象ごと、また商品ごとに加減算するスコアが設定され、さらにスコア対象も種々のキーワードや「行動」に基づくため、より多面的に判断された商品を提供することが可能となる。

以上説明した実施形態において、顧客が購入した商品を考慮して商品情報を提供するようにしてもよい。例えば、顧客が購入した商品を購入した他の顧客が購入した商品の商品情報を提供するようにしてもよい。

上記販促処理では、顧客スコアデータの１年の合計で販促を行うか否かが判断されているが、ある一定期間（例えば、キャンペーン期間や販売強化期間など）の合計で販促を行うか否かを判断してもよい。このようにすることで、一定期間に関連する商品の販促処理を行うことができる。

さらに、業務支援装置に、先読み機能を設けるようにしてもよい。例えば、退職が近いことなど、これから発生する事象を先読み可能な機能を設ける。これは、退職金が入金した時点で、顧客がその使い道を決定していることがあるためである。この先読み機能によれば、退職が近いことが判明した時点で営業活動を行うことが可能となるため、タイミングを逃すことなく効率よく営業活動を行うことが可能となる。なお、退職先読み方法の例として、顧客の勤務先、誕生日は既知であるので、同一の勤務先に勤務していた他の顧客が何歳で退職したかなどを記録しておき、その退職年齢に基づき判定するという方法や、ネット上から勤務先の企業に関するデータを収集し、得られたデータに基づき判定する方法などがある。このように、各チャネルからデータを収集し、収集したデータを分析することで発生する事象を先読みすることができる。そして、先読みした事象を出力することで適時適切な情報提供を行う業務支援装置を提供することができる。

上述した実施形態における業務支援装置２００、または業務支援装置５００の処理をコンピュータで実現するようにしてもよい。その場合、この機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現してもよい。なお、ここでいう「コンピュータシステム」とは、ＯＳや周辺機器等のハードウェアを含むものとする。また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。さらに「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムを送信する場合の通信線のように、短時間の間、動的にプログラムを保持するもの、その場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリのように、一定時間プログラムを保持しているものも含んでもよい。また上記プログラムは、前述した機能の一部を実現するためのものであってもよく、さらに前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるものであってもよく、ＦＰＧＡ（FieldProgrammable Gate Array）等のプログラマブルロジックデバイスを用いて実現されるものであってもよい。

以上、この発明の実施形態について図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計等も含まれる。

１００ 業務支援システム、２００ 業務支援装置、２０１ データ取得部
２０２ データ抽出部、２０３ データ記憶部、２０４ フォロー情報生成部
２０５ データ出力部、２０６ 事象推定部、２０７ 支援データベース
３００ データベース群、４００ デバイス群、２１０ 指標導出部、２１１ 指標ＤＢ

Claims (12)

1. データ形式が異なる複数の顧客関連情報を取得する取得部と、
   前記取得部により取得された顧客関連情報から所定の情報を抽出する抽出部と、
   前記抽出部により抽出された前記所定の情報を共通のデータ形式で記憶する記憶部と、
   前記記憶部により記憶された前記所定の情報から、顧客に関する事象を推定する推定部と、
   前記推定部により推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連部と、
   前記関連部により前記事象に関連付けられた前記所定の情報を出力する出力部と、
   を有し、
   前記抽出部は、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する、業務支援装置。
2. 特定の情報と、特定の情報に対応する対応情報を予め保持し、前記所定の情報が特定の情報である場合に、前記特定の情報に対応する対応情報を、予め保持されている対応情報によって生成する生成部を有し、
   前記出力部は、前記生成部により生成された前記対応情報を出力することを特徴とする請求項１に記載の業務支援装置。
3. 前記所定の情報は、金融業務に関する情報であり、前記特定の情報は、口座の変化を示す情報、営業活動に関する情報、及び顧客の状態に関する情報の少なくとも１つの情報を含むことを特徴とする請求項２に記載の業務支援装置。
4. 前記記憶部は、前記所定の情報を時系列で記憶することを特徴とする請求項１から請求項３のいずれか１項に記載の業務支援装置。
5. 前記所定の情報、または前記推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する導出部を有することを特徴とする請求項１から請求項４のいずれか１項に記載の業務支援装置。
6. 前記出力部は、商品ごとに導出された指標のうち、相対的に推奨度が大きい指標が導出された商品を示す商品情報を出力することを特徴とする請求項５に記載の業務支援装置。
7. 前記出力部は、指標が所定の基準に到達した商品を示す商品情報を出力することを特徴とする請求項５に記載の業務支援装置。
8. コンピュータが実行する業務支援方法であって、
   データ形式が異なる複数の顧客関連情報を取得する取得ステップと、
   前記取得ステップにより取得された顧客関連情報から所定の情報を抽出する抽出ステップと、
   前記抽出ステップにより抽出された前記所定の情報を共通のデータ形式で記憶する記憶ステップと、
   前記記憶ステップにより記憶された前記所定の情報から、顧客に関する事象を推定する推定ステップと、
   前記推定ステップにより推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連ステップと、
   前記関連ステップにより前記事象に関連付けられた前記所定の情報を出力する出力ステップと、
   を有し、
   前記抽出ステップは、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する、業務支援方法。
9. 前記所定の情報、または前記推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する導出ステップを有することを特徴とする請求項８に記載の業務支援方法。
10. 業務支援装置、データベースサーバ、及びデバイスを含む業務支援システムであって、
    前記業務支援装置は、
    前記データベースサーバから、データ形式が異なる複数の顧客関連情報を取得する取得部と、
    前記取得部により取得された顧客関連情報から所定の情報を抽出する抽出部と、
    前記抽出部により抽出された前記所定の情報を共通のデータ形式で記憶する記憶部と、
    前記記憶部により記憶された前記所定の情報から、顧客に関する事象を推定する推定部と、
    前記推定部により推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連部と、
    前記関連部により前記事象に関連付けられた前記所定の情報を前記デバイスに出力する出力部と、
    を有し、
    前記抽出部は、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する、業務支援システム。
11. 前記所定の情報、または前記推定された事象から、顧客へ提供可能な商品ごとに顧客への推奨度を示す指標を顧客ごとに導出する導出部を有することを特徴とする請求項１０に記載の業務支援システム。
12. 業務支援装置のコンピュータに、
    データ形式が異なる複数の顧客関連情報を取得する取得ステップと、
    前記取得ステップにより取得された顧客関連情報から所定の情報を抽出する抽出ステップと、
    前記抽出ステップにより抽出された前記所定の情報を共通のデータ形式で記憶する記憶ステップと、
    前記記憶ステップにより記憶された前記所定の情報から、顧客に関する事象を推定する推定ステップと、
    前記推定ステップにより推定された事象と、前記事象が推定された前記所定の情報とを関連付ける関連ステップと、
    前記関連ステップにより前記事象に関連付けられた前記所定の情報を出力する出力ステップと、
    を実行させるためのプログラムであり、
    前記抽出ステップは、データ形式が異なる複数の前記顧客関連情報ごとに、前記共通のデータ形式に対応する項目を抽出するための抽出ルールを保持し、当該抽出ルールを用いて前記顧客関連情報から前記所定の情報を抽出する、プログラム。

Images