(57)【要約】【課題】  従来において、ポイントを付与するサービスについて、複数種類のサービスが提供される場合、これを統合的に管理することは考慮されていなかった。【解決手段】  コンピュータを用いて、サービス受領者について、受けるサービス毎に、その評価情報を算出し、統合的にそのサービス受領者に対する評価情報（ランク）を決定する。より具体的には、サービスについての受領者である顧客を評価するための複数の評価項目それぞれについての評価情報および前記複数の評価項目それぞれの階層関係を記憶しておき、前記評価情報を前記階層関係に適用して、前記顧客の総合評価情報を算出し、前記評価情報のいずれかの変更を検知し、前記変更を検知した場合、当該変更に関係する評価項目を抽出し、抽出された前記評価項目について評価情報を変更し、変更された評価情報に基づいて、総合評価情報を再算出する。【選択図】  図１
2008084038.tif 000002
【特許請求の範囲】
【請求項１】
サービスを受ける顧客の情報を管理する顧客情報管理システムにおいて、
前記サービスについての受領者である顧客を評価するための複数の評価項目それぞれについての評価情報を記憶しておく手段と、
前記複数の評価項目それぞれの階層関係を記憶しておく手段と、
前記評価情報を前記階層関係に適用して、前記顧客の総合評価情報を算出する手段と、
前記評価情報のいずれかの変更を検知する手段と、
前記変更を検知した場合、当該変更に関係する評価項目を抽出する手段と、
抽出された前記評価項目について評価情報を変更する手段と、
変更された評価情報に基づいて、総合評価情報を再算出する手段とを有することを特徴とする顧客情報管理システム。
【請求項２】
請求項１に記載の顧客情報管理システムにおいて、
前記顧客は、複数のサービスを受領し、
前記複数の評価項目は、前記複数のサービスのそれぞれ毎に算出することを特徴とする顧客情報管理システム。
【請求項３】
請求項１に記載の顧客情報管理システムにおいて、
前記抽出する手段は、前記階層関係を用いて、前記変更された評価項目と上位もしくは下位の関係を有する評価項目を抽出することを特徴とする顧客情報管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のサービスを提供するサービス提供者の顧客管理を行う技術に関する。その中でも特に、顧客に対してポイントを付与したり、ランク付けを、複数のサービスから統合的に行うことをサポートする技術に関する。なお、サービス提供者には、銀行などの金融機関や地方公共団体などの機関が含まれる。
【背景技術】
【０００２】
従来、顧客を管理する技術として、特許文献１に開示される技術が提案されている。特許文献１においては、販売店（舗）から顧客別に与えられる点数換算のランク付けを如何にして行うかが記載されている。このために、特許文献１においては、顧客別に販売金額に応じたポイントを管理すると共に、顧客識別媒体に当該顧客のランク（サービス倍数情報）を格納しておき、上記のポイントにサービス倍数情報を掛け合わせることで、当該顧客の点数を算出することが記載されている。
【０００３】
【特許文献１】特開平７−６５２４３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、特許文献１においては、ポイントを付与するサービスについて、サービス提供側のサービスが「販売」との一種類のサービスしか考慮されていない。このため、複数種類のサービスが提供される場合、これを統合的に管理することは考慮されていなかった。
【０００５】
例えば、銀行の場合、預金や借り入れなどの複数種類のサービスを提供している。この場合、預金と借り入れでは、銀行（もしくは顧客）から見た場合、性格が別物である。つまり、銀行から見て預金は一顧客に対して金額が大きいほどコストがかからないなどの理由によりメリットが大きいが、借り入れに関しては、収益率や貸し倒れリスクなどを考慮すると必ずしも金額の大小がメリットの大小に直接影響するとは限らない。また、これらのサービスを統合的に管理する必要もある。
【０００６】
さらに、預金とのサービスを見ても、普通預金、定期預金ではその重み付けが異なっている。つまり、同じサービス受領者においても、その役割（受けるサービス）によっては重み付けが異なっている。
【課題を解決するための手段】
【０００７】
そこで、本発明では、コンピュータを用いて、サービス受領者について、受けるサービス毎に、その評価情報を算出し、統合的にそのサービス受領者に対する評価情報（ランク）を決定する。より具体的には、サービスを受ける顧客の情報を管理する顧客情報管理システムにおいて、前記サービスについての受領者である顧客を評価するための複数の評価項目それぞれについての評価情報を記憶しておく手段と、前記複数の評価項目それぞれの階層関係を記憶しておく手段と、前記評価情報を前記階層関係に適用して、前記顧客の総合評価情報を算出する手段と、前記評価情報のいずれかの変更を検知する手段と、前記変更を検知した場合、当該変更に関係する評価項目を抽出する手段と、抽出された前記評価項目について評価情報を変更する手段と、変更された評価情報に基づいて、総合評価情報を再算出する手段とを有することを特徴とする顧客情報管理システムが含まれる。
【０００８】
また、この顧客情報管理システムにおいて、前記顧客は、複数のサービスを受領し、前記複数の評価項目は、前記複数のサービスのそれぞれ毎に算出することを特徴とする顧客情報管理システムも本発明に含まれる。
【０００９】
また、これらの顧客情報管理システムにおいて、前記抽出する手段は、前記階層関係を用いて、前記変更された評価項目と上位もしくは下位の関係を有する評価項目を抽出することを特徴とする顧客情報管理システムも本発明に含まれる。
【００１０】
さらに、上記顧客情報管理システムを用いた顧客情報管理方法や顧客情報管理システムをコンピュータとして機能させるためのプログラムやこれを格納した記憶媒体も本発明に含まれる。
【発明の効果】
【００１１】
本発明によれば、より実態に即した形で顧客情報の管理が可能になる。
【発明を実施するための最良の形態】
【００１２】
本発明の実施の形態について、図面を用いて説明する。本実施の形態は、銀行におけるサービス受領者に対する評価情報（ランク）を例に説明するが、本発明はそれに限定されるものではない。
【００１３】
まず、本実施の形態におけるシステム構成図を図１に示す。
図１の１０１は、本方法を実現するための判定手段であり、演算装置１０２と記憶装置１０３とからなる。データは必要に応じて磁気記憶装置１０４から前記記憶装置１０３に読込まれる。また、データを処理するソフトウェアは前記磁気記憶装置１０７に保持されていたものを前記記憶装置１０３に読み出し、このソフトウェアに従い前記演算装置１０２によって処理および条件判断が実行されることにより、前記記憶装置１０３のデータが更新され、各データベースに更新されたデータが保存されるものである。メインフレームやサーバーなどはこれらの処理機構を有する。
【００１４】
１０５はキーボードやマウスなどの入力装置であり、１０６はモニタやプリンタなどの出力装置、１０７はイントラネットやインターネットなどとの通信装置であり、ネットワークを介して他システムとの連携を実現する。なお、前記判断手段１０１へのデータの入出力は前記入力装置１０５、前記出力装置１０６だけでなく前記通信装置１０７によって行われても良い。
【００１５】
図２は、顧客を一意に特定するためのＩＤである顧客ＩＤ２０１のほか顧客の氏名２０２、住所２０３、電話番号２０４など、顧客の基本属性のほかに、顧客に対する評価情報（以下、ランク）である顧客ランク２０５、および、そのランクを決定するために用いる顧客ポイント２０６などを管理する顧客属性情報データベースである。
【００１６】
図３は、前記顧客ランク２０５を判定するための判定基準を管理する顧客ランク条件データベースであり、顧客ランク３０１であることの判定基準となる顧客ランク基準ポイント３０２と判断条件である顧客ランク条件３０３を持つものである。図３の例では、ランクの上位から条件に対する適合を判断し、途中で適合する場合のランクを顧客ランクとし、最終的にどの条件とも適合しない場合、ランクは「Ｄ」となるものとしている。なお、「≧」は、顧客ポイント≧顧客ランク基準ポイントを表す。
【００１７】
図４は、顧客が銀行に対して持つ役割を一意に表す役割コード４０１とその役割に対する評価である役割ランク４０２、および、役割コードと役割ランクの組合せについて数値化するための換算顧客ポイント４０３などの情報を持つ役割ランク顧客ポイント換算データベースである。前記換算顧客ポイントとは、前記顧客ランク条件３０３に対して、前記顧客ランク基準ポイント３０２との比較によって前記顧客ランク２０５を決定するために用いる。
【００１８】
図５は、役割コード５０１や役割コードの役割名５０２など、役割に関する基本的な情報を管理する役割基本情報データベースである。図６は、顧客ＩＤ６０１と役割コード６０２のほかに、顧客の役割ごとの役割ランク６０３、および、そのランクを決定するために用いる役割ポイント６０４などを管理する役割属性情報データベースである。図７は、役割コード７０１とその役割における役割ランク７０２、および、役割ランクの判定基準である役割ランク基準ポイント７０３とその判断条件である役割ランク条件７０４を管理する役割ランク条件データベースである。図７の例では、ランクの上位から条件に対する適合を判断し、途中で適合する場合のランクを役割ランクとし、最終的にどの条件とも適合しない場合、ランクは「Ｄ」となるものとしている。なお、「≧」は、役割ポイント≧役割ランク基準ポイントを表す。
【００１９】
図８は、科目コード８０１と口座ランク８０２、および、科目コードと口座ランクの組合せに対する換算役割ポイント８０３などの情報を持つ口座ランク役割ポイント換算データベースある。換算役割ポイントは、前記役割ランク条件７０４に対して、前記役割ランク基準ポイント７０３との比較によって前記役割ランク６０２を決定するために用いる。図９は、科目コード９０１に対応する科目名９０２などの科目基本情報データベースである。
【００２０】
図１０は、口座を一意に表現する組合せである、店番１００１、科目コード１００２、口座番号１００３のほかに、口座の評価情報である口座ランク１００４、そのランクを決定するために用いる口座ポイント１００５、口座の所有者を表す顧客ＩＤ１００６、口座を所有している顧客の役割コード１００７や、口座の残高１００８、その口座の給与振込契約を表す給与振込１００９、水道料金の自動振込契約を表す水道料金自振１０１０などを管理する口座管理情報データベースである。
【００２１】
図１１は、口座を一意に表現する組合せである、店番１１０１、科目コード１１０２、口座番号１１０３のほかに、当該口座に関する評価項目となっている項目名をあらわす１１０４、および、その評価項目に関する評価情報である評価項目ランク１１０５、などを管理する評価項目データベースである。図１２は、科目コード１２０１と口座ランク１２０２ごとに、口座ランクの判断基準である口座ランク基準ポイント１２０３とその判断条件である口座ランク条件１２０４を管理する口座ランク条件データベースである。図１２の例では、ランクの上位から条件に対する適合を判断し、途中で適合する場合のランクを口座ランクとし、最終的にどの条件とも適合しない場合、ランクは「Ｄ」となるものとしている。なお、「≧」は、口座ポイント≧口座ランク基準ポイントを表す。
【００２２】
図１３は、科目コード１３０１と評価項目１３０２、評価項目ランク１３０３、および、科目コードと評価項目、評価項目ランクの組合せに対する換算口座ポイント１３０４などの情報を持つ評価項目ランク口座ポイント換算データベースである。換算口座ポイントは、前記口座ランク条件１２０４に対して、前記口座ランク基準ポイント１２０３との比較によって前記口座ランク１００４を決定するために用いる。なお、評価項目ランクとは、評価項目の評価情報（ランク）のことであり、評価項目とは、ランクを決定するために用いるデータ項目の呼称である。
【００２３】
図１４は、科目コード１４０１と評価項目１４０２、および、評価項目ランク１４０３ごとの評価項目ランクの判断基準である評価項目ランク基準ポイント１４０４とその判断条件である評価項目ランク条件１４０５を管理する評価項目ランク条件データベースである。図１４の例では、ランクの上位から条件に対する適合を判断し、途中で適合する場合のランクを評価項目ランクとし、最終的にどの条件とも適合しない場合、ランクは「Ｄ」となるものとしている。なお、「≧」は、評価項目データ値≧評価項目ランク基準ポイントを表す。
【００２４】
図１５は、一つの口座を表現する、店番１５０１、科目コード１５０２、口座番号１５０３の組合せのほかに、評価項目１５０５の情報を管理し、口座ごとに評価項目が更新されたことを管理する評価項目更新管理データベースである。なお、顧客ランク、役割ランク、口座ランクおよび評価項目ランクの関係は階層関係にあり、顧客ランクを最上位の階層とし、顧客ランクは役割ランクから算出され、役割ランクは口座ランクから算出され、口座ランクは評価項目ランクより算出される、という下位階層から上位階層を算出する。
【００２５】
以下、本実施の形態の処理内容について、説明する。本実施における最良の実施例の流れを図１６のフローチャートに沿って説明する。図１６のフローチャートは、顧客ランクや役割ランク等、各ランクがすでに計算されているものとし、定期的あるいはイベント発生などを契機に顧客ランクの算出処理を開始後、当該顧客の顧客ランクの算出に影響を与える評価項目の変更履歴を入力として、評価項目ランク、口座ランク、役割ランク、顧客ランクの順に階層を上がるようにランクの再計算行って、最終的に各ランクを確定するまでの流れを示したものである。なお、各ランクを再計算する場合は、当該顧客の顧客ランクの算出に影響を与える評価項目がそれぞれ変更になった特殊な例としてみなせる。
【００２６】
まず、顧客ランクを算出する流れについて、説明する。
図１６において、顧客ランクの更新処理を開始すると、当該顧客に関係する評価項目の変更履歴を変更履歴データベースより抽出するステップＳ１０１を実行する。評価項目変更履歴データベースの例として図１５の例を用いて説明すると、図１５の例では変更履歴は口座単位で管理しているため、顧客がどの口座を保有しているのかを特定した後、当該口座と一致する変更履歴を前記評価項目変更履歴データベースより抽出する手順になる。顧客ランクを計算する顧客の例として、図２の顧客属性情報データベースにおける顧客ＩＤ「1111111111」を例とすると、当該顧客は図１０の口座情報データベースの例では、店番「００１」科目コード「０００１」口座番号「１１１１１１１」の口座（以下、この３つの番号の組合せをもつ口座を「口座１」とする）と店番「００２」科目コード「０００２」口座番号「２２２２２２２」の口座（以下、この３つの組合せをもつ口座を「口座２」とする）の２つ持っていると判断する。ゆえに、この２つの口座について評価項目の変更履歴を抽出すると、図１５の評価項目変更履歴データベースの例では、口座１の例では評価項目「残高」および「給与振込」において変更が生じていると判断し、また、口座２の例では評価項目「残高」において変更が生じていると判断する。
【００２７】
次に、前記ステップＳ１０１において抽出された結果に対して、当該顧客に関係する評価項目の変更履歴が存在しない場合を想定し、評価項目が存在するかどうかを判断するステップＳ１０２を実行する。前記顧客ＩＤ「1111111111」の例では、上記説明の通り、当該顧客が保有する口座において評価項目の変更履歴が存在しており、肯定の判断を下す。
【００２８】
前記ステップＳ１０２において否定の場合は変更履歴がない場合であり、前回と顧客ランク算出のための条件が変わっていないため、算出される顧客ランクは前回と不変であることが自明であるため、顧客ランクを更新せず、不要な計算を実施することなく処理を終了する。一方、前記ステップＳ１０２において肯定の場合は、各評価項目ランクの変更履歴について、評価項目ランクを更新するための計算を行うステップＳ１０３を実施する。評価項目ランクの計算とは、前記変更履歴に対して、図１４の評価項目ランク条件データベースに記されている、科目コード、評価項目、基準ポイントとランク条件との比較により適合するものを抽出することで、その評価項目ランクを決定するというものである。
【００２９】
図１４の評価項目ランク条件データベースを用いて説明すると、前記顧客ＩＤ「1111111111」の口座１については評価項目「残高」と「給与振込」について評価項目ランクの更新のための計算を行い、口座２については評価項目「残高」について評価項目ランクの計算を行うことになる。代表例として、口座１について具体的に計算方法を説明すると、まず、図１０の前記口座情報データベースの例では、口座１の残高は「1,000,001」であることがわかる。一方、図１４の前記評価項目ランク条件データベースの例では、科目コード「１０１」、評価項目「残高」の場合、評価項目ランクが「Ａ」になるには基準の残高として「10,000,000」以上であることが必要であることがわかるが、前記残高は前記基準を満たないため、「A」ではないと判断する。そして、次のランク「Ｂ」の基準「1,000,000」について「A」と同様に評価すると、前記残高と前記基準の関係よりランクは「Ｂ」であると判断する。また、「給与振込」についても図１０の前記口座情報データベースにおいて、口座１の給与振込の契約が「有」であることがわかるため、図１５の前記評価項目ランク条件データベースの条件より、当該ランクは「Ａ」であると判断する。
【００３０】
なお、ここではランクの上位から当てはまるか否かを確認していったが、変更前のランクから当てはまるかを行ってもよい。通常、ランクの変更は一段階づつされるのが通常であるため、当てはまるかの確認処理が、このような手法を用いることで削減することが可能になる。また、「口座」が対象の場合、変更の理由が振込みなどの残高が増加する場合は、変更前のランクからランクアップする方向へ確認処理を行い、残高が減少する処理の場合、変更前のランクからダウンする方向へ確認処理を行ってもよい。
【００３１】
一方、口座２（顧客ＩＤ「2222222222」）については、図１０に示されるよう口座ランクが「Ｃ」であり、変更もされないので、このまま処理を終了する。
【００３２】
次に、前記ステップＳ１０３において行った評価項目ランクの計算において、計算前と計算後においてランクが変更された評価項目が存在するかどうかの判断を、各口座について行うステップＳ１０４を実施する。前記顧客ＩＤ「111111111」の場合、上記の通り、口座１についてランクが変更された評価項目「残高」「給与振込」があるため、肯定となる。一方、前記顧客ＩＤ「2222222222」の場合は、ランクが変更された評価項目が無いため、否定となる。
【００３３】
前記判断Ｓ１０４において否定の場合、評価項目ランクの変更は上位のランクには影響を及ぼさないため、その他のランクを変更することなく計算を終了する。そのため、評価項目の変化が口座ランクの変更に影響を及ぼすことなく、計算を終了させることができるため、計算量を減らすことができる。前記顧客ＩＤ「2222222222」の例では、各評価項目に変更が無いためこのままランクを変更せずに確定して終了する。
【００３４】
一方、前記判断Ｓ１０４において肯定の場合、評価項目ランクの変更による上位のランクに変更があるかを求めるため、上位の口座ランクの計算を実施するステップＳ１０５を実行する。計算方法は、今回変更になった評価項目ランクについて、図１３の評価項目ランク口座ポイント換算データベースに基づき、ランクをポイント換算したその値について、図１２の口座ランク条件データベースの科目コードに一致し、かつ、基準ポイントとそのランク条件を満たすような口座ランクを抽出することによる。なお、変更前の換算ポイントと変更後の換算ポイントとの差を計算することにより、評価項目のすべてを計算する必要性をなくし、計算量を減らしている。
【００３５】
前記顧客ＩＤ「1111111111」の例では、評価項目「残高」においてランクは「Ｂ」に変更になり、「給与振込」においてはランクが「Ａ」に変更になったため、これらを踏まえて計算を行う。まず「残高」の例では科目コードは「１０１」であるから、図１３の前記評価項目ランク口座ポイント換算データベースより、換算口座ポイントはランク「Ｃ」と「Ｂ」はそれぞれ「１０」と「２０」であることがわかるため、その差分が「１０」であることがわかる。また、「給与振込」の例でも科目コードは「１０１」であるから、同様に、図１３より換算口座ポイントはランク「Ｂ」と「Ａ」それぞれ「０」と「３０」であることがわかる。従って、その差分は「３０」ポイントであることがわかる。図１０の前記口座情報データベースの例では、口座１の口座ランクは「Ｃ」であり、その口座ポイントは「６０」であるが、今回の差分を加えることにより、新たな口座ポイントとして「１００」を算出する。これは、図１２の前記口座ランク条件データベースの例において、科目コード「１０１」、口座ランク基準ポイント「１００」に対して口座ランク条件「≧（だいなり）」を満たすので、口座１はランク「Ｂ」であると判断する。
【００３６】
次に、前記ステップＳ１０５において行った口座ランクの計算において、計算前と計算後において口座ランクが変更された口座があるかないかの判断を、それぞれの役割について行うステップＳ１０６を実施する。前記顧客ＩＤ「111111111」の場合、上記の通り、口座１について口座ランクを変更しているため、肯定となる。
【００３７】
前記判断Ｓ１０６において、否定の場合、口座ランクの変更は上位のランクには影響を及ぼさないため、その他のランクを変更することなく計算を終了する。そのため、口座ランクの変化が役割ランクの変更に影響を及ぼすことなく、計算を終了させることができるため、計算量を減らすことができる。
【００３８】
一方、前記判断Ｓ１０６において肯定の場合、口座ランクの変更による上位のランクに変更があるかを求めるため、上位である役割ランクの計算を実施するステップＳ１０７を実行する。役割ランクの計算方法は、今回変更になった口座ランクについて、図８の口座ランク役割ポイント換算データベースに基づき、ランクをポイント換算したその値について、図７の役割ランク条件データベースの役割コードに一致し、かつ、基準ポイントとそのランク条件を満たすような役割ランクを抽出することによる。なお、口座ランクが変更された当該口座を保有する顧客の役割は、図１０の口座情報データベースでわかるものである。また、変更前の換算ポイントと変更後の換算ポイントとの差を計算することにより、口座ランクのすべてを用いて役割ランクを算出する必要性をなくし（一部の口座ランクを用いる）、計算量を減らしている。
【００３９】
前記顧客ＩＤ「1111111111」の例では、口座ランクが「Ｃ」から「Ｂ」に変更になった前記口座１について換算役割ポイントを算出する。前記口座１の科目コードは図１０の前記口座情報データベースの例から「１０１」であることがわかるため、図８の前記口座ランク役割ポイント換算データベースの例において、科目コード「１０１」、口座ランク「Ｂ」について、その換算役割ポイントは「２０」であると判断する。また同様に、口座ランク「Ｃ」についてはその間算役割ポイントは「１０」であるため、口座ランク「Ｂ」と「Ｃ」において役割ポイントの差分として「１０」ポイントの違いがあることがわかる。図６の前記役割情報データベースの例では、前記顧客ＩＤ「1111111111」の役割ＩＤ「１０１」の役割ランクは「Ｃ」であり、その役割ポイントは「９０」であるが、今回の差分「１０」を加えることにより、新たな役割ポイントとして「１００」を算出する。これは、図７の前記役割ランク条件データベースの例において、役割コード「１０１」、役割ランク基準ポイント「１００」に対して役割ランク条件「≧」を満たすので、前記顧客ＩＤ「1111111111」の役割ＩＤ「１０１」のランクは「Ｂ」であると判断する。
【００４０】
次に、前記ステップＳ１０７において行った役割ランクの計算において、計算前と計算後において役割ランクが変更された役割があるかないかの判断を行うステップＳ１０８を実施する。前記顧客ＩＤ「111111111」の場合、上記の通り、役割ＩＤ「１０１」の役割について役割ランクを変更しているため、肯定となる。
【００４１】
前記判断Ｓ１０８において、否定の場合、役割ランクの変更は上位のランクには影響を及ぼさないため、その他のランクを変更することなく計算を終了する。そのため、役割ランクの変化が顧客ランクの変更に影響を及ぼすことなく、計算を終了させることができるため、計算量を減らすことができる。
【００４２】
一方、前記判断Ｓ１０８において肯定の場合、役割ランクの変更による上位のランクに変更があるかを求めるため、上位である顧客ランクの計算を実施するステップＳ１０９を実行する。顧客ランクの計算方法は、今回変更になった役割ランクについて、図４の役割ランク顧客ポイント換算データベースに基づき、ランクをポイント換算したその値について、図３の顧客ランク条件データベースの顧客ＩＤに一致し、かつ、基準ポイントとそのランク条件を満たすような顧客ランクを抽出することによる。なお、変更前の換算ポイントと変更後の換算ポイントとの差を計算することにより、役割ランクのすべてを用いて顧客ランクを算出する必要性をなくし、計算量を減らしている。
【００４３】
前記顧客ＩＤ「1111111111」の例では、役割ランクが「Ｃ」から「Ｂ」に変更になった前記役割ＩＤ「１０１」について換算顧客ポイントを算出する。前記役割「１０１」は図４の前記役割ランク顧客ポイント換算データベースの例において、役割コード「１０１」、役割ランク「Ｂ」について、その換算役割ポイントは「２０」であると判断する。また同様に、役割ランク「Ｃ」についてはその間算役割ポイントは「１０」であるため、役割ランク「Ｂ」と「Ｃ」において顧客ポイントの差分として「１０」ポイントの違いがあることがわかる。図２の前記顧客情報データベースの例では、前記顧客ＩＤ「1111111111」の顧客ランクは「Ｃ」であり、その役割ポイントは「９０」であるが、今回の差分「１０」を加えることにより、新たな顧客ポイントとして「１００」を算出する。これは、図３の前記顧客ランク条件データベースの例において、顧客ランク基準ポイント「１００」に対して顧客ランク条件「≧」を満たすので、前記顧客ＩＤ「1111111111」のランクは「Ｂ」であると判断する。
【００４４】
以上により、当該顧客に関係する評価項目の内容変化に対して当該顧客の顧客ランクの算出を行うことができる。また、途中で評価項目の変更の影響を収束させることができるようになっているため、各ランクの算出処理を途中で終了させることができる。
【００４５】
また、本実施の形態は各階層において評価項目ごと、口座ごと、役割ごとに独立してランク算出を行っているため、評価項目ランク、口座、役割における追加・変更・削除において、それぞれ各データベースにレコードを追加・変更・削除するだけでよく、プログラムコードの修正・変更は不要、もしくは本実施ではない場合に比べて大幅に縮小されるという特徴を有する。
【００４６】
さらに、本実施の形態は下位階層から上位階層に向けてランクからランクを算出していくものであり、各階層が同じ（もしくは同様の）アルゴリズムで処理されているため、階層の追加・変更・削除が容易である。これは、提携する複数金融機関が一人の顧客に対してそれぞれ保有する複数の顧客ランク情報を連携することで、金融グループとしての一つの新たな顧客ランクの設定が容易に実現できる、という特徴を有する。また、これは同一の業界だけでなく、業界の垣根を越えてクレジットカード会社、地方公共団体等の異なる企業・団体においてランク付けされたデータを基にした、新たな顧客のランクを算出することをも容易にする。
【００４７】
さらに、ランクの追加・変更・削除を容易にするため、各ランク条件データベースのランク基準ポイントの適切な値の設定をサポートする機能や基準ポイントの自動計算を実施しても良い。
図１７のように、ある階層のランク１７０２がn個あり、これらから上位階層のランク１７０１を算出するものとし、あるｍ番目のランクにおいて、ランクの分類数をＡｍ＋１個（ただし、ｍ＝１、２、・・・、ｎ）、換算ポイントの上位のランクと下位のランクのポイントの差分をａｍで一定であるものとする。このとき、前記ｍ番目のランクの換算ポイントｐｍは、ｐｍ＝ａｍ×ｋｍ（ただし、ｋｍ＝０、１、・・・、Ａｍ）で表せる。また、上位階層のランクポイントをこれらの総和から算出するものとすると、上位階層のランクポイントＰはＰ＝ｐ１＋ｐ２＋・・・＋ｐｍ＋・・・＋ｐｎ＝ａ１×ｋ１＋ａ２×ｋ２＋・・・＋ａｍ×ｋｍ＋・・・＋ａｎ×ｋｎ表せる。
また、同様に上位階層のランクの分類数をＢ＋１個とし、基準ポイントはランクごとの差分がｂポイントの定数であるものとすると、ランク条件の基準ポイントはＳ＝ｂ×ｈ（ただし、ｈ＝０、１、・・・、Ｂ）で表せる。
ところで、前記上位ランク１７０１におけるランクと前記下位ランク１７０２の換算ポイントの総和との関係を考えると、図１８はその関係を表す図である。ただし、説明の便宜上、図１７の条件を簡略化し上位ランクはＡ〜Ｄの４段階（Ｂ＝３）としてある。
さて、下位階層のランク１７０２の換算ポイントと上位階層のランク１７０１の基準ポイントとの関係において、図１８より、前記ランク条件基準ポイントＳの最大値をＳｍａｘ、前記換算ポイントＰの最大値をＰｍａｘとすると、Ｐｍａｘ≧Ｓｍａｘを満たしていなくてはならない。なぜなら、本条件が満たされていないと、上位ランク１７０１におけるランク「Ａ」が実現される可能性がなく、上記定義にあわないからである。前記条件式Ｐｍａｘ≧Ｓｍａｘを以下、条件式１と呼ぶことにすると、条件式１はＰｍａｘ＝ａ１×Ａ１＋ａ２×Ａ２＋・・・＋ａｍ×ｋｍ＋・・・＋ａｎ×Ａｎ≧Ｓｍａｘ＝ｂ×Ｂであるので、従って、前記下位階層ランク１７０２の追加変更削除を行う場合、前記条件を満たすように前記上位階層ランク１７０１における基準ポイントの差分ｂと分類数Ｂを設定すればよい。したがって、前記条件をデータベースに登録しておき、前記基準ポイントｂと前記分類数Ｂの設定を手動で行う際に前記条件を読み出し、条件判定の結果によってはユーザに設定値の変更を要求する仕組みを設けても良い。
このようなユーザのランクにおける基準ポイントの設定における条件は、これだけではない。前記下位階層のランク１７０２のランクの変化によって前記上位階層のランク１７０１のランクの変更が常時発生するような前記基準ポイント差分ｂと前記分類数Ｂを設定することは、本発明の趣旨に反するものである。また、同様に下位階層の換算ポイントにおける最小の変化によって、上位階層のランク変更が１つ以上のランクを飛び越して行われることは、前記の飛び越されたランクは不要であるため、その設定は不適切である。従って、こうした不適切な設定を排除するような制約を複数個、データベースに保持しておき、前記ランクポイント差分ｂおよびランク分類数Ｂの人手による設定を複数の制約によってサポートしてもよい。
今、前記下位階層ランク１７０２同士はそれぞれ独立であり、かつ、複数のランクが同時に変更されないとし、現在、図１８のように換算ポイントｘがあり、前記下位階層ランク１７０２における換算ポイントの変更幅が最小のものをａｍｉｎポイント（ただし、ａｍｉｎはａ１からａｎで最小のもの）とすると、前記上位階層１７０１のランクの変更との関係から、最小の変更値ａｍｉｎによって例えばランク「Ｃ」からランク「Ａ」のように２つ以上のランクの変更にならないようにするため、ｂ≧ａｍｉｎであるように条件を設けてもよい。この条件を条件式２とする。
前記条件式１および前記条件式２をデータベースに保持しているものとすれば、人手によって前記基準ポイントｂや前記分類数Ｂの値が設定されるとき、前記条件式１および前記条件式２について、どちらかあるいは同時に満たすような前記基準ポイント差分ｂと前記分類数Ｂが設定されたかを判断してもよい。
さらに条件を追加し、例えば、ａｍｉｎ＝ａｍ＝ａ、Ａｍ＝Ａ（ただし、ｍ＝１、２、・・・、ｎ）とすると、前記条件式１はａ１×Ａ１＋ａ２×Ａ２＋・・・＋ａｍ×ｋｍ＋・・・＋ａｎ×Ａｎ＝ｎ×ａ×Ａ≧ｂ×Ｂであり、前記条件式２はｂ≧ａより、ｎ×Ａ≧Ｂ（等号成立はａ＝ｂ）であるから、この条件を満たすようなＢであるかを判定してもよい。これを条件式３とする。さらには、データベースに条件式４としてａ＝ｂであることが設定されていれば、前記条件式３より、Ｂ＝ｎ×Ａ（ただし、ｎとＡは既知）を自動計算することができて、一意にＢを算出することも可能である。
このような条件は必ずしも上記の例に限られるものではなく、目的に応じて条件の組合せを選択し、その条件に基づいて手動による設定値の評価や設定値の自動計算を行ってもよい。
【図面の簡単な説明】
【００４８】
【図１】顧客管理システムの概要
【図２】顧客属性情報データベース
【図３】顧客ランク条件データベース
【図４】役割ランク顧客ポイント換算データベース
【図５】役割基本情報データベース
【図６】役割属性情報データベース
【図７】役割ランク条件データベース
【図８】口座ランク役割ポイント換算データベース
【図９】役割基本情報データベース
【図１０】口座情報データベース
【図１１】評価項目データベース
【図１２】口座ランク条件データベース
【図１３】評価項目ランク口座ポイント換算データベース
【図１４】評価項目ランク条件データベース
【図１５】評価項目変更履歴データベース
【図１６】本実施の形態の処理の流れを示すフローチャート
【図１７】評価ランクの階層関係を模式的に示す図
【図１８】評価ポイントの算出方法を模式的に示す図
【符号の説明】
【００４９】
１０１…判定手段、１０２…演算装置、１０３…記憶装置、１０４…磁気記憶装置、１０５…入力装置、１０６…出力装置、１０７…通信装置
【図１】
2008084038.tif 000003
【図２】
2008084038.tif 000004
【図３】
2008084038.tif 000005
【図４】
2008084038.tif 000006
【図５】
2008084038.tif 000007
【図６】
2008084038.tif 000008
【図７】
2008084038.tif 000009
【図８】
2008084038.tif 000010
【図９】
2008084038.tif 000011
【図１０】
2008084038.tif 000012
【図１１】
2008084038.tif 000013
【図１２】
2008084038.tif 000014
【図１３】
2008084038.tif 000015
【図１４】
2008084038.tif 000016
【図１５】
2008084038.tif 000017
【図１６】
2008084038.tif 000018
【図１７】
2008084038.tif 000019
【図１８】
2008084038.tif 000020