JP2021135704A

JP2021135704A - 顧客管理装置及びプログラム

Info

Publication number: JP2021135704A
Application number: JP2020030881A
Authority: JP
Inventors: 崇司宮本; Takashi Miyamoto
Original assignee: Fujifilm Business Innovation Corp
Current assignee: Fujifilm Business Innovation Corp
Priority date: 2020-02-26
Filing date: 2020-02-26
Publication date: 2021-09-13
Also published as: US20210264440A1; US11620655B2

Abstract

【課題】障害に応じて対応優先顧客を動的に抽出し得る技術を提供する。【解決手段】顧客管理装置１０は、プロセッサ１２，１４，１６を備える。プロセッサ１４は、システム１００の障害発生が検知された場合に、障害発生時のアクセス数を顧客毎に算出し、アクセス数に基づいて障害発生に対応すべき顧客の優先順位を出力する。障害発生時のアクセス数には、障害発生前の第１の一定時間内における第１のアクセス数、障害発生後の第２の一定時間内における第２のアクセス数、障害発生の直前に発生した他の障害発生後の第３の一定時間内における第３のアクセス数が含まれ得る。また、プロセッサ１４は、障害継続時間に応じて顧客の優先順位を変化させる。【選択図】図１

Description

本発明は、顧客管理装置及びプログラムに関する。

コンピュータシステムで何らかの障害が発生した場合、障害の復旧を行うとともに、当該コンピュータシステムを利用する顧客に対して速やかに対応する必要がある。

特許文献１には、インシデントの優先順位を自動的に決定することを課題として、ＳＬＡ（サービス品質保証：ＳｅｒｖｉｃｅＬｅｖｅｌＡｇｒｅｅｍｅｎｔ）遵守率により設定した複数のＳＬＡ遵守率ポイントと障害発生件数により設定した複数の障害件数ポイントと契約台数により複数の契約台数ポイントとを含む優先ポイントを設定した基本設定テーブルと、ＳＬＡ遵守率と障害発生件数と契約台数とに基づいて設定したＳＬＡ遵守率ポイントと障害件数ポイントと契約台数ポイントとを合算した顧客毎の優先ポイントを顧客毎に格納する顧客毎優先設定テーブルとを備える優先度設定データベースを設け、基本設定テーブルに設定したＳＬＡ遵守率ポイントと障害件数ポイントと契約台数ポイントと、ＳＬＡ契約情報データベース７のＳＬＡ遵守率と障害履歴データベースの障害発生件数と構成管理データベースの契約台数とを比較して顧客毎の優先ポイントを算出するインシデント期限管理システムが記載されている。

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

特開２０１４−１７４６９８号公報では、ＳＬＡ遵守率ポイントや障害件数ポイント等の複数のポイント（あるいはパラメータ）により対応優先顧客を抽出しているが、予め決められた静的なパラメータを用いているため、障害に応じて対応優先度を動的に変えることができない。

本発明は、障害に応じて対応優先顧客を動的に抽出し得る技術を提供することを目的とする。

請求項１に記載の発明は、障害発生を検知する検知部と、顧客情報を記憶する記憶部と、プロセッサと、を備え、前記プロセッサは、プログラムを実行することで、前記検知部で障害発生が検知された場合に、障害発生時のアクセス数を顧客毎に算出し、前記アクセス数に基づいて、前記記憶部に記憶された、障害発生に対応すべき顧客の優先順位を出力する、顧客管理装置である。

請求項２に記載の発明は、前記プロセッサは、障害発生前の第１の一定時間内における第１のアクセス数を顧客毎に算出し、障害発生後の第２の一定時間内における第２のアクセス数を顧客毎に算出し、前記第１のアクセス数と前記第２のアクセス数に基づいて、前記記憶部に記憶された、障害発生に対応すべき顧客の優先順位を出力する、顧客管理装置である。

請求項３に記載の発明は、前記プロセッサは、更に、前記障害発生の直前に発生した他の障害発生後の第３の一定時間内における第３のアクセス数を顧客毎に算出し、前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数に基づいて、前記優先順位を出力する、請求項２に記載の顧客管理装置である。

請求項４に記載の発明は、前記プロセッサは、更に、一定期間内における利用回数を顧客毎に算出し、前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数と前記利用回数に基づいて、前記優先順位を出力する、請求項３に記載の顧客管理装置である。

請求項５に記載の発明は、前記プロセッサは、更に、契約期間を顧客毎に算出し、前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数と前記利用回数と前記契約期間に基づいて、前記優先順位を出力する、請求項４に記載の顧客管理装置である。

請求項６に記載の発明は、前記プロセッサは、更に、体験版の有無を顧客毎に決定し、
前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数と前記利用回数と前記体験版の有無に基づいて、前記優先順位を出力する、請求項４に記載の顧客管理装置である。

請求項７に記載の発明は、前記プロセッサは、更に、障害継続時間に基づいて、前記優先順位を出力する、請求項１〜６のいずれかに記載の顧客管理装置である。

請求項８に記載の発明は、コンピュータに、障害発生を検知するステップと、前記障害発生を検知した場合に、障害発生時のアクセス数を顧客毎に算出するステップと、前記アクセス数に基づいて、障害発生に対応すべき顧客の優先順位を出力するステップと、を実行させるプログラムである。

請求項１，８に記載の発明によれば、障害に応じて対応優先顧客を動的に抽出することができる。

請求項２に記載の発明によれば、更に、障害発生前の第１のアクセス数と、障害発生後の第２のアクセス数に基づいて対応優先顧客を動的に抽出できる。

請求項３に記載の発明によれば、更に、障害発生の直前に発生した他の障害発生後の第３のアクセス数に基づいて対応優先顧客を動的に抽出できる。

請求項４に記載の発明によれば、更に、一定期間内における利用回数に基づいて対応優先顧客を動的に抽出することができる。

請求項５に記載の発明によれば、更に、契約期間に基づいて対応優先顧客を動的に抽出することができる。

請求項６に記載の発明によれば、更に、体験版の有無に基づいて対応優先顧客を動的に抽出することができる。

請求項７に記載の発明によれば、更に、障害継続時間に基づいて対応優先顧客を動的に抽出することができる。

実施形態における顧客管理装置の構成図である。実施形態における障害ポイントテーブル説明図である。実施形態におけるログポイントテーブル説明図である。実施形態における契約期間ポイントテーブル説明図である。実施形態における顧客情報テーブル説明図である。実施形態における顧客・担当営業テーブル説明図である。実施形態における第１のインシデント／障害情報テーブル説明図である。実施形態における第２のインシデント／障害情報テーブル説明図である。実施形態における障害発生時の処理フローチャートである。実施形態における出力画面説明図である。

以下、図面に基づき本発明の実施形態について説明する。

＜基本原理＞
まず、本実施形態の基本原理について説明する。

従来のシステムでは、例えば、ＳＬＡ遵守率ポイントや障害件数ポイント等の複数のパラメータにより対応優先顧客を抽出しているが、これらは予め決められた静的なパラメータであるため、障害に応じて対応優先度を動的に変えることができない。例えば、障害の状況によっては特定の顧客の優先度を上げた方がよいと考えられる場合もあるところ、静的なパラメータのみでは対応し得ない。具体的には、コンピュータシステムにある障害が発生し、障害が継続している時間、すなわち復旧までに時間を要している場合において、より多く当該システムにアクセスして利用しようとしている顧客に対しては、速やかに対応する必要があるため対応優先度を上げるべきと考えられるが、静的なパラメータのみでは対応が困難である。

そこで、本実施形態では、障害発生に伴う動的なパラメータ、すなわち障害発生時のアクセス数を用いて顧客の対応優先度を決定して出力するように構成する。障害発生時のアクセス数が相対的に多い顧客の対応優先度を相対的に高くし、障害発生時のアクセス数が相対的に少ない顧客の対応優先度を相対的に低くする。

ここで、「障害発生時のアクセス数」とは、障害発生に関連付けられたアクセス数を意味する。障害発生に関連付けられたアクセス数は、障害発生の前後を問わない。すなわち、障害発生後のアクセス数のみならず、障害発生前のアクセス数も含まれ得る。但し、障害発生に関連付けられるためには、障害発生のタイミングを基点として、その前後の一定時間内のアクセス数であることが好ましい。例えば、障害発生後３時間以内のアクセス数、障害発生後復旧までのアクセス数、障害発生前１時間以内のアクセス数、障害発生前の２時間以内のアクセス数等である。

また、障害発生に関連付けられたアクセス数は、今回生じた障害に限定されず、それ以前に生じた障害に関連付けられたアクセス数であってもよい。例えば、今回生じた障害より前に生じた複数の障害のうちの最終障害後のアクセス数であってもよい。

従って、本実施形態における障害発生時のアクセス数には、
（１）今回の障害発生後の一定時間内のアクセス数
（２）今回の障害発生前の一定時間内のアクセス数
（３）今回の障害より前の最終障害発生後の一定時間内のアクセス数
のいずれも含まれる。本実施形態では、これらのアクセス数のいずれかを単独で、あるいは複数のアクセス数を組み合わせて顧客の対応優先度を決定する。対応優先度の決定方法を例示すると、以下の通りである。
（１）のみを用いる
（２）のみを用いる
（３）のみを用いる
（１）と（２）を用いる
（１）と（３）を用いる
（２）と（３）を用いる
（１）と（２）と（３）を用いる

そして、対応優先度は、これらのアクセス数の重み付け加算でスコアを算出し、当該スコアの高低により算出し得る。すなわち、重みをｐ、ｑ、ｒとすると、
スコア＝ｐ・（今回の障害発生後のアクセス数）＋ｑ・（今回の障害発生前のアクセス数）＋ｒ・（最終障害発生後のアクセス数）
により算出できる。ここで、ｐ≧０、ｑ≧０、ｒ≧０である。特に、障害発生前のアクセス数を重視する場合、ｐ＝０、ｒ＝０として、
スコア＝ｑ・（今回の障害発生前のアクセス数）
により算出できる。

勿論、重み付け加算は一例であり、（１）〜（３）のアクセス数を変数とする任意の関数を用いてスコアを算出し得る。

本実施形態では、（１）〜（３）の動的パラメータを用いて対応優先度を決定するが、これら以外のパラメータをさらに組み合わせて対応優先度を決定してもよい。これら以外のパラメータとしては、例えば、
・過去の一定時間内におけるアクセス数
・契約期間
・正規の顧客か体験版の顧客か
・障害継続時間の長さ
等が例示される。これらのパラメータも、単独で、あるいは適宜組み合わせて使用され得る。また、これらのパラメータは、上記の重みｐ、ｑ、ｒを調整するために用いられてもよい。例えば、過去の一定期間におけるアクセス数が大きい程、重みｑを大きくする、契約期間が短い程、重みｑを大きくする、体験版の顧客であれば重みｑを大きくする、障害継続時間が長い程、重みｑを大きくする等である。

障害継続時間に関しては、障害継続時間が長い場合、当該サービスをより多く利用する顧客に対する影響度がより大きいと考えられ、優先的に対応する必要があることから、障害継続時間が長い場合、重みｑを大きくして障害直前のアクセス数が多い顧客の優先度を上げることは合理的と考えられ、かつ、障害の状況に応じて動的に対応優先度を変化させることが可能となる。

さらに、障害継続中のアクセス数のみならず、障害復旧後のアクセス数に着目してスコアを算出してもよい。障害復旧後により多くアクセスした顧客に対しては、その後の対応優先度を上げる必要があるからである。

次に、本実施形態について、より具体的に説明する。

＜基本構成＞
図１は、本実施形態における顧客管理装置１０の構成ブロック図を示す。顧客管理装置１０は、複数のプロセッサ１２，１４，１６、障害ポイントテーブルデータ１８，ログポイントテーブルデータベース２０、契約期間ポイントテーブルデータベース２２、顧客情報テーブルデータベース２４，営業・顧客関連テーブルデータベース２６、及びインシデント／障害情報テーブルデータベース２８を備える。顧客管理装置１０は、プロセッサ、メモリ、入出力インターフェイス及び通信インターフェイスを備えるコンピュータで実現され得る。

プロセッサ１２は、顧客が利用するサービスを提供するシステム（あるいはサーバ）１００の情報、各種データベース１８〜２４の情報を用いて、顧客毎の対応優先度、すなわち顧客毎の優先順位を算出する。プロセッサ１２は、システム１００の運用担当５０に顧客毎の優先順位を出力して注意を促す

プロセッサ１４は、顧客情報テーブルデータベース２４及びインシデント・障害情報テーブルデータベース２８の情報を用いてスコアを算出する際の重みを決定する。

プロセッサ１６は、プロセッサ１２からの情報、及び営業・顧客関連データベース２６の情報を用いて、優先順位の高い顧客の担当営業６０に対してアラートを通知する。

障害ポイントテーブルデータベース１８は、システム１００に障害が発生した時の、その障害発生直前のアクセス数とポイント数を対応付けるテーブルを記憶する記憶部である。障害発生直前のアクセス数は、具体的には障害発生の１時間前あるいは２時間前のアクセス数である。アクセス数毎のポイント数は任意であるが、アクセス数が多いほどポイント数は大きくなるように対応付けられる。

ログポイントテーブルデータベース２０は、過去１ヶ月間のシステム１００へのアクセス数とポイント数を対応付けるテーブルを記憶する記憶部である。アクセス数毎のポイント数は任意であるが、アクセス数が多いほどポイント数は大きくなるように対応付けられる。

契約期間ポイントテーブルデータベース２２は、システム１００が提供するサービスの契約期間とポイント数を対応付けるテーブルを記憶する記憶部である。契約期間毎のポイント数は任意であるが、契約期間が長いほどポイント数は小さくなるように対応付けられる。

顧客情報テーブルデータベース２４は、システム１００の顧客毎の過去１ヶ月のアクセス数と契約開始日と体験版利用の有無と最終障害時のアクセス数とを対応付けるテーブルを記憶する記憶部である。最終障害時のアクセス数は、今回の障害よりも前に生じた障害のうちの最終の障害発生後の（一定時間内の）アクセス数である。

営業・顧客関連テーブルデータベース２６は、システム１００の顧客と担当営業とを対応付けるテーブルを記憶する記憶部である。

インシデント／障害情報テーブルデータベース２８は、第１のテーブルと第２のテーブルを記憶する。第１のテーブルは、日付とインシデント（障害）とインシデント内容と問い合わせの有無とを対応付けるテーブルである。第２のテーブルは、インシデントと顧客と障害時のアクセス数と契約期間と過去１ヶ月ログイン数と体験版の有無とを対応付けるテーブルである。障害時のアクセス数は、今回生じた障害後の（一定時間内の）アクセス数である。

プロセッサ１２は、システム１００でのインシデント（障害）発生を検知すると、プロセッサ１４に出力する。プロセッサ１４は、システム１００でのインシデント発生をプロセッサ１２からの出力により検知すると、第１のテーブルに当該インシデントの発生日付とインシデントの識別番号（ＩＤ）、インシデント内容をテーブルに登録するとともに、当該インシデントに対する問い合わせの有無をインシデント毎に登録する。また、プロセッサ１４は、問い合わせを受け付けると、顧客情報テーブルデータベース２４に記憶された顧客情報テーブルを参照して、第２のテーブルを更新していく。

プロセッサ１２，１４，１６は、いずれもメモリに記憶されたプログラムを読み出して実行することで処理を行う。本実施形態では、プロセッサ１２，１４，１６は別個に存在しているが、単一のプロセッサで実現してもよい。

また、プロセッサ１２，１４，１６は広義的なプロセッサを指し、汎用的なプロセッサ
（例えば CPU：Central Processing Unit等）や、専用のプロセッサ（例えば GPU：Graphics Processing Unit、ASIC：Application Specific Integrated Circuit、FPGA：Field Programmable Gate Array 、プログラマブル論理デバイス等）を含むものである。また、プロセッサ１２，１４，１６の動作は、１つのプロセッサによって成すのみでなく、物理的に離れた位置に存在する複数のプロセッサが協働して成すものであってもよい。また、プロセッサの各動作の順序は上記で記載した順序のみに限定されるものではなく、適宜変更してもよい。

図２は、障害ポイントテーブルデータベース１８に記憶される障害ポイントテーブルの一例を示す。障害直前（１時間前あるいは２時間前）のアクセス数とポイント数が対応付けられる。例えば、
障害直前アクセス数ポイント数
１２
２４
３８
等である。このテーブルを参照することで、障害直前アクセス数に応じたポイントを算出できる。なお、障害直前アクセス数が多いほどポイント数が大きくなるのは、アクセス数が多いということは今すぐにサービスを利用したい顧客である可能性が高いと考えられるため、その分だけポイントを高くするためである。また、障害後のアクセス数とポイント数も、図２のテーブルで対応付けられる。

図３は、ログポイントテーブルデータベース２０に記憶されるログポイントテーブルの一例を示す。過去１か月のアクセス数とポイント数が対応付けられる。例えば、
過去１か月アクセス数ポイント数
５回未満１
１０回未満２
１５回未満３
等である。このテーブルを参照することで、過去１か月アクセス数に応じたポイントを算出できる。なお、過去１ヶ月アクセス数が多いほどポイント数が大きくなるのは、アクセス数が多いほどその分だけアクティブな顧客であり、システム１００のサービスを多く利用している顧客であるため、その分だけポイントを高くするためである。

図４は、契約期間ポイントテーブルデータベース２２に記憶される契約期間ポイントテーブルの一例を示す。契約期間の長さ及び体験版利用顧客か否かとポイント数が対応付けられる。例えば、
契約期間体験版顧客か否かポイント数
１か月未満ＹＥＳ１０
１か月未満ＮＯ５
３か月未満ＹＥＳ８
３か月未満ＮＯ４
１５か月未満ＹＥＳ６
１５か月未満ＮＯ３
等である。このテーブルを参照することで、契約期間及び体験版顧客か否かに応じたポイントを算出できる。なお、契約期間が短いほどポイント数が高くなるのは、契約期間が短いほど新規顧客である可能性が高く、システム１００のサービスを解約するリスクも高いため、その分だけポイントを高くするためである。また、体験版顧客のポイント数が高くなるのも、新規顧客となる可能性が高いため、その分だけポイントを高くするためである。

図５は、顧客情報テーブルデータベース２４に記憶される顧客情報テーブルの一例を示す。顧客ＩＤと、過去１ヶ月アクセス数と、契約開始日と、体験版利用フラグと、最終障害時アクセス数とが対応付けられる。すなわち、顧客毎に、過去１ヶ月アクセス数、契約開始時、体験版利用フラグ、最終障害時アクセス数が対応付けられる。契約開始日を参照することで、システム１００の障害発生時における顧客毎の契約期間が算出される。また、体験版利用フラグを参照することで、システム１００の障害発生時における顧客毎の体験版利用の有無が決定される。体験版利用フラグＮＯは体験版顧客でない正規の顧客であることを意味し、体験版利用フラグＹＥＳは体験版顧客であることを示す。最終障害時アクセス数は、今回の障害より前の障害の内の最終障害時の一定時間内のアクセス数である。例えば、顧客ＩＤ＝ｃ２１ａ９８０１の顧客について、
過去１ヶ月アクセス数契約開始日体験版利用フラグ最終障害時アクセス数
３ 2019/1/10 ＮＯ３
等である。

図６は、営業・顧客関連テーブルデータベース２６に記憶される営業・顧客関連テーブルの一例を示す。顧客とその担当営業とが対応付けられる。例えば、
顧客ＩＤ担当営業ＩＤ
C21a9801 030b1234
等である。なお、担当営業の連絡先（電子メールアドレスや電話番号）等は、別途のテーブルで管理し得る。

図７は、インシデント・障害情報テーブルデータベース２８に記憶される第１のテーブルの一例を示す。この第１のテーブルでは、インシデント日時、インシデント（障害）ＩＤ、インシデント（障害）内容、及び問い合わせの有無が対応付けられる。例えば、
日付インシデントＩＤインシデント内容問い合わせ有無
2019-3-22 16:32 00000001 通信障害ＮＯ
等である。プロセッサ１２でシステム１００の障害を検知すると、プロセッサ１４は検知情報を用いて第１のテーブルに登録する。なお、システム１００の管理者が手動でこれらの項目を入力して登録してもよい。

図８は、インシデント・障害情報テーブルデータベース２８に記憶される第２のテーブルの一例を示す。この第２のテーブルでは、インシデント（障害）及び顧客毎に、障害時アクセス数、契約期間、過去１ヶ月アクセス数、体験版利用顧客か否かが対応付けられる。プロセッサ１４は、図７に示す第１のテーブル、図５に示す顧客情報テーブル、及び今回発生した障害後の一定時間内のアクセス数を集計して、この第２のテーブルを作成してインシデント・障害情報テーブルデータベース２８に記憶する。例えば、今回生じた障害のインシデントＩＤがＩＤ＝00000003であるとすると、
顧客ＩＤ障害時アクセス数契約期間過去１か月アクセス数体験版か
c21a9801 ３１か月３ＮＯ
等である。なお、障害時アクセス数は、障害後の一定時間内のアクセス数であるが、これとともに、障害直前の一定時間内のアクセス数及び最終障害時のアクセス数を併せて登録してもよい。最終障害時アクセス数は、図５に示す顧客情報テーブルを参照することで取得できる。プロセッサ１４は、この第２テーブルを参照することで、顧客毎に、
・障害直前の一定時間内のアクセス数
・障害後の一定時間内のアクセス数
・最終障害時の一定時間内のアクセス数
・過去１ヶ月の一定時間内のアクセス数
・契約期間
・体験版利用の有無
の情報を取得し得る。

なお、インシデント・障害情報テーブルデータベース２８に記憶される第１のテーブルには、上記のようにインシデント日時が登録されているので、プロセッサ１４は、これらの情報に加えて、インシデント日時を参照することで、障害継続時間の情報も取得し得る。

図９は、障害発生時における顧客管理装置１０の処理フローチャートの一例を示す。

システム１００に何らかの障害が発生すると、プロセッサ１４は、インシデント／障害情報テーブルデータベース２８に記憶されている第２のテーブルを参照して、システム１００の顧客毎の障害直前のアクセス数、障害後のアクセス数、最終障害時のアクセス数を取得する（Ｓ１０１、Ｓ１０２）。

また、プロセッサ１４は、顧客情報テーブルデータベース２４に記憶されている顧客情報テーブルを参照して、システム１００の顧客毎の過去１ヶ月アクセス数と契約情報を取得する（Ｓ１０３）。契約情報には、契約期間と体験版利用の有無が含まれる。

次に、プロセッサ１４は、障害中フラグがセットされているか否かを判定する（Ｓ１０４）。障害中フラグは、障害が発生したタイミングでセットされ、当該障害が復旧したタイミングで解除される。

障害が発生し、当該障害が継続している場合には、障害中フラグはセットされたままであるためＳ１０４でＹＥＳと判定され、プロセッサ１４は、長期障害判定時間より障害時間が長いか否かを判定する（Ｓ１０７）。ここで、長期障害判定時間は予め決められた時間であり、例えば３０分等と設定される。

障害継続時間が長期障害判定時間より長いと判定された場合（Ｓ１０７でＹＥＳ）、プロセッサ１４は、障害直前アクセス数の重みを２倍にする（Ｓ１０８）。障害継続時間が長期障害判定時間より長くないと判定された場合（Ｓ１０７でＮＯ）、プロセッサ１４は、Ｓ１０８の処理を実行せず重みを１のままとする。これは、障害継続時間が長い場合、当該サービスをより多く利用する顧客に対する影響度がより大きいと考えられ、優先的に対応する必要があることから、障害継続時間が長い場合に重みを大きくして障害直前のアクセス数が多い顧客の優先度を上げるためである。

他方、発生した障害が復旧すると、障害中フラグが解除されるためＳ１０４でＮＯと判定される。この場合、プロセッサ１４は、障害が復旧してから監視時間以上経過したか否かを判定する（Ｓ１０５）。ここで、監視時間は予め決められた時間であり、例えば１０分等と設定される。

障害が復旧してから監視時間以上経過した場合（Ｓ１０５でＹＥＳ）、監視時間以内にアクセスした顧客の障害直前アクセス数の重みを２倍にする（Ｓ１０６）。監視時間以内にアクセスのない顧客の重みはそのまま維持する。そして、上述したＳ１０７以降の処理を実行する。

以上のようにして重みを調整した後、次に、プロセッサ１４は、取得した情報を用いて顧客毎にスコアを重み付け加算で算出する（Ｓ１０９）。すなわち、プロセッサ１４は、
スコア＝ａ・（障害直前アクセス数）＋ｂ・（障害後アクセス数）＋ｃ・（最終障害時アクセス数）＋ｄ・（過去１ヶ月アクセス数）＋ｅ・（契約期間及び体験版利用の有無）
によりスコアを算出する。

上式におけるａ、ｂ、ｃ、ｄ、ｅは、それぞれ障害直前アクセス数、障害後アクセス数、最終障害時アクセス数、過去１ヶ月アクセス数、契約期間及び体験版利用の有無の重みである。障害直前アクセス数、障害後のアクセス数、及び最終障害時アクセス数とポイント数との関係は図２に示すテーブルで規定され、過去１ヶ月アクセス数とポイント数との関係は図３に示すテーブルで規定され、契約期間及び体験版利用の有無とポイント数との関係は図４に示すテーブルで規定される。従って、プロセッサ１４は、これらの情報及びテーブルを参照して顧客毎のスコアを算出する。例えば、それぞれの重みをａ＝ｂ＝ｃ＝ｄ＝ｅ＝１とし、ある顧客の情報が、
障害直前アクセス数＝３
障害後アクセス数＝２（監視時間内にアクセス有り）
最終障害時アクセス数＝０
過去１ヶ月アクセス数＝１０回未満
契約期間＝３ヶ月未満
体験版の有無＝ＮＯ
であり、障害時間が長期障害判定時間より短いと、スコアは、重みａがＳ１０６の処理で２倍となっているから、
スコア＝２・８＋１・４＋１・０＋１・２＋１・４＝２６
となる。また、障害時間が長期障害判定時間より長いと、スコアは、重みａがＳ１０８の処理でさらに２倍となるから、
スコア＝４・８＋１・４＋１・０＋１・２＋１・４＝４２
となる。

また、別の顧客の情報が、
障害直前アクセス数＝１
障害後アクセス数＝０（監視時間内にアクセス無し）
最終障害時アクセス数＝０
過去１ヶ月アクセス数＝５回未満
契約期間＝３ヶ月未満
体験版の有無＝ＮＯ
であり、障害時間が長期障害判定時間より短いと、スコアは、重みａは１のままであるから、
スコア＝１・２＋１・０＋１・０＋１・１＋１・４＝７
となる。また、障害時間が長期障害判定時間より長いと、スコアは、重みａがＳ１０８の処理で２倍となるから、
スコア＝２・２＋１・０＋１・０＋１・１＋１・４＝９
となる。

プロセッサ１４は、顧客毎のスコアを算出すると、次に、スコアが同一の顧客が存在するか否かを判定し、スコアが同一であれば、障害直前アクセス数が少ない顧客の順位を上げるように顧客毎の順位を決定する（Ｓ１１０）。勿論、これは一例であり、スコアが同一の場合には任意のルールに従ってその優劣を決定してもよい。

プロセッサ１４は、以上のようにして顧客毎にスコアを算出し、スコアの高い順に顧客を抽出すると、抽出した顧客情報をプロセッサ１２に出力する。プロセッサ１２は、優先順位を運用担当５０に出力するとともに、プロセッサ１６に出力する（Ｓ１１１）。

図１０は、プロセッサ１２により運用担当５０に出力される顧客毎の優先順位画面３０の一例を示す。

画面３０には、障害発生時刻、障害復旧時刻、長期障害判定時間、障害復旧後監視時間が表示され、算出された顧客毎の優先順位３２が表示される。

障害復旧時刻は、発生した障害が継続している間は空欄のままである。この障害復旧時刻が空欄であることは、障害発生中フラグがセットされていることを意味する。

また、長期障害判定時間は、Ｓ１０７の処理で用いられる判定時間であり、障害復旧後監視時間は、Ｓ１０５の処理で用いられる監視時間である。

顧客毎の優先順位は、スコアが高い順にソートされて顧客が表示され、具体的には順位、顧客ＩＤ、顧客名、及び算出スコアが表示される。

なお、図９の処理フローチャートから理解されるように、スコアの算出及び顧客の優先順位は、障害が継続中にも算出され得る。従って、障害復旧後では、障害継続中の算出結果とは異なる結果が得られる可能性があるため、再計算ボタンが表示される。運用担当５０が再計算ボタンを操作すると、プロセッサ１２はプロセッサ１４に再計算を指示し、プロセッサ１４は、プロセッサ１２からの当該指示に基づいて顧客毎のスコアを再算出する。

具体的には、障害復旧後の監視時間内にアクセスした顧客については、Ｓ１０６の処理で重みａがさらに２倍されて再算出されるため、スコアが高くなり優先順位が上がることになる。

＜変形例＞
本実施形態では、
スコア＝ａ・（障害直前アクセス数）＋ｂ・（障害後アクセス数）＋ｃ・（最終障害時アクセス数）＋ｄ・（過去１ヶ月アクセス数）＋ｅ・（契約期間及び体験版利用の有無）
によりスコアを算出しているが、これらの重みは任意に設定できる。例えば、ｂ＝ｃ＝０として、より簡易に、
スコア＝ａ・（障害直前アクセス数）＋ｄ・（過去１ヶ月アクセス数）＋ｅ・（契約期間及び体験版利用の有無）
によりスコアを算出してもよい。
また、障害後アクセス数として、障害後復旧前アクセス数と復旧後アクセス数の２つのアクセス数を用い、
スコア＝ａ・（障害直前アクセス数）＋ｂ１・（障害後復旧前アクセス数）＋ｂ２・（復旧後アクセス数）＋ｄ・（過去１ヶ月アクセス数）＋ｅ・（契約期間及び体験版利用の有無）
によりスコアを算出してもよい。

１０顧客管理装置、１２，１４，１６プロセッサ、１８障害ポイントテーブルデータベース、２０ログポイントテーブルデータベース、２２契約期間ポイントテーブルデータベース、２４顧客情報テーブルデータベース、２６営業・顧客関連テーブルデータベース、２８インシデント／障害情報テーブルデータベース。

Claims

障害発生を検知する検知部と、
顧客情報を記憶する記憶部と、
プロセッサと、
を備え、前記プロセッサは、プログラムを実行することで、
前記検知部で障害発生が検知された場合に、障害発生時のアクセス数を顧客毎に算出し、
前記アクセス数に基づいて、前記記憶部に記憶された、障害発生に対応すべき顧客の優先順位を出力する、
顧客管理装置。
前記プロセッサは、
障害発生前の第１の一定時間内における第１のアクセス数を顧客毎に算出し、
障害発生後の第２の一定時間内における第２のアクセス数を顧客毎に算出し、
前記第１のアクセス数と前記第２のアクセス数に基づいて、前記記憶部に記憶された、障害発生に対応すべき顧客の優先順位を出力する、
顧客管理装置。
前記プロセッサは、更に、前記障害発生の直前に発生した他の障害発生後の第３の一定時間内における第３のアクセス数を顧客毎に算出し、
前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数に基づいて、前記優先順位を出力する、
請求項２に記載の顧客管理装置。
前記プロセッサは、更に、一定期間内における利用回数を顧客毎に算出し、
前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数と前記利用回数に基づいて、前記優先順位を出力する、
請求項３に記載の顧客管理装置。
前記プロセッサは、更に、契約期間を顧客毎に算出し、
前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数と前記利用回数と前記契約期間に基づいて、前記優先順位を出力する、
請求項４に記載の顧客管理装置。
前記プロセッサは、更に、体験版の有無を顧客毎に決定し、
前記第１のアクセス数と前記第２のアクセス数と前記第３のアクセス数と前記利用回数と前記体験版の有無に基づいて、前記優先順位を出力する、
請求項４に記載の顧客管理装置。
前記プロセッサは、更に、障害継続時間に基づいて、前記優先順位を出力する、
請求項１〜６のいずれかに記載の顧客管理装置。
コンピュータに、
障害発生を検知するステップと、
前記障害発生を検知した場合に、障害発生時のアクセス数を顧客毎に算出するステップと、
前記アクセス数に基づいて、障害発生に対応すべき顧客の優先順位を出力するステップと、
を実行させるプログラム。