電話処理システムおよび電話端末
【課題】インシデントに対応すべきグループに属する担当者の意思決定を支援する。
【解決手段】実施の１形態の電話処理システム１００は、電話制御装置１０と、複数の担当者ＴＥＬ１８とを備える。電話制御装置１０は、上記グループに対する通話要求が受け付けられたとき、複数の担当者ＴＥＬ１８それぞれに対する通話要求を順次発信し、上記グループに属する各担当者との通話状況を、少なくとも当該装置から通話要求を発信した担当者ＴＥＬ１８に対して通知する。担当者ＴＥＬ１８は、電話制御装置１０から通知された通話状況を、電話制御装置１０からの通話要求の着信履歴と対応づけてディスプレイに表示させる。
【解決手段】実施の１形態の電話処理システム１００は、電話制御装置１０と、複数の担当者ＴＥＬ１８とを備える。電話制御装置１０は、上記グループに対する通話要求が受け付けられたとき、複数の担当者ＴＥＬ１８それぞれに対する通話要求を順次発信し、上記グループに属する各担当者との通話状況を、少なくとも当該装置から通話要求を発信した担当者ＴＥＬ１８に対して通知する。担当者ＴＥＬ１８は、電話制御装置１０から通知された通話状況を、電話制御装置１０からの通話要求の着信履歴と対応づけてディスプレイに表示させる。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、データ処理技術に関し、特に、電話処理システムおよび電話端末に関する。
【背景技術】
【０００２】
サービス提供中の設備機器で発生する障害について、その障害へ対応すべき複数の担当者が予め定められていることがある。以下の特許文献１では、迅速な障害回復を図るために、複数の担当者のうち障害対応が可能な状態の担当者に対して、障害対応の指示を通知する技術が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２９３０１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
設備機器における障害発生を、その設備機器の運用者から複数の担当者へ電話連絡する場合、各担当者の電話端末へ順次連絡することがある。担当者は、運用者からの電話連絡に対応できなかった場合でも、その電話連絡の存在を着信履歴により把握できる。しかし、これまでの着信履歴は電話の発信元や着信時刻等を示すものにすぎず、担当者は、着信履歴を見ても、行うべきアクションを迅速に決定することは困難な場合があると本発明者は考えた。
【０００５】
本発明は、本発明者の上記課題認識に基づきなされたものであり、その主たる目的は、あるインシデントに対応すべきグループに属する担当者の意思決定を支援する技術を提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある態様の電話処理システムは、あるインシデントに対応すべき担当者のグループを管理するセンタ装置と、グループに属する複数の担当者が保持する複数の電話端末と、を備える。センタ装置は、グループに対する通話要求が受け付けられたとき、複数の電話端末のそれぞれに対する通話要求を順次発信する要求発信部と、グループに属する各担当者との通話状況を、複数の電話端末のうち少なくとも当該装置から通話要求を発信した電話端末に対して通知する通話状況通知部と、を有する。複数の電話端末のそれぞれは、センタ装置から通話要求の着信を受け付ける着信受付部と、センタ装置から各担当者との通話状況の通知を受け付ける通話状況受付部と、各担当者との通話状況を、通話要求の着信履歴と対応づけて表示させる表示制御部と、を有する。
【０００７】
本発明の別の態様は、電話端末である。この電話端末は、あるインシデントが発生した際、そのインシデントに対応すべきグループを管理する装置から、通話要求の着信を受け付ける着信受付部と、管理する装置から、グループに属する複数の担当者それぞれとの通話状況の通知を受け付ける通話状況受付部と、複数の担当者それぞれとの通話状況を、通話要求の着信履歴と対応づけて表示させる表示制御部と、を備える。
【０００８】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、あるインシデントに対応すべきグループに属する担当者の意思決定を支援できる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態の電話処理システムの構成を示す図である。
【図２】図１のインシデント管理装置の機能構成を示すブロック図である。
【図３】対応情報保持部が保持するデータの構成を模式的に示す図である。
【図４】図１の電話制御装置の機能構成を示すブロック図である。
【図５】グループ情報保持部が保持するデータの構成を模式的に示す図である。
【図６】図１の担当者ＴＥＬの機能構成を示すブロック図である。
【図７】担当者ＴＥＬのディスプレイに表示される着信履歴を模式的に示す図である。
【図８】図４の電話制御装置の動作を示すフローチャートである。
【図９】図２のインシデント管理装置の動作を示すフローチャートである。
【図１０】図６の担当者ＴＥＬの動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
本発明の実施の形態を説明する前に、まず概要を説明する。
データセンタにて稼働中のサーバで障害が発生した場合、そのデータセンタにおける運用者は、その障害に対応するべく予め定められたグループ（以下、「障害対応グループ」とも呼ぶ）に属する複数の担当者へ順次電話連絡を行う。この電話連絡を、以下では「トラブルコール」とも称する。各担当者は、トラブルコールを携帯電話にて受け付けるが、携帯電話を一時的に保持しないときや会議への参加中等、トラブルコールに応答できない場合もある。
【００１２】
このような場合、各担当者は、携帯電話の着信履歴を後から確認することで、トラブルコールがあったことを把握できる。しかし、そのトラブルコールに対して既に他の担当者が対応中か否か、運用者へのコールバックが必要か否か等の判断がつきにくく、自身がとるべき行動を迅速に意思決定することが困難であった。また、複数の担当者が運用者へコールバックした場合や、トラブルに対応する担当者（以下、「対応者」とも呼ぶ）の決定後に、別の担当者がコールバックした場合等、運用者から各担当者への指示が交錯し、運用者の負担が増加し、またミスの発生要因ともなっていた。
【００１３】
そこで、本実施の形態では、障害対応グループの各担当者の電話端末をグループ化し、運用者と各担当者との通話状況を、各担当者の電話端末における着信履歴に表示させる電話処理システムを提案する。このシステムによれば、障害対応グループの各担当者は、運用者からのトラブルコールに応答できなかった場合でも、運用者と他の担当者との通話状況を容易に把握でき、自身がとるべき行動を迅速かつ適切に意思決定しやすくなる。
【００１４】
図１は、実施の形態の電話処理システムの構成を示す。電話処理システム１００は、電話制御装置１０と、インシデント管理装置１２と、センタＴＥＬ１４と、外部ＴＥＬ１５と、担当者ＴＥＬ１８で総称される第１担当者ＴＥＬ１８ａ、第２担当者ＴＥＬ１８ｂ、第３担当者ＴＥＬ１８ｃとを備える。なお図１には不図示であるが、データセンタには、所定のサービスを外部へ提供するサーバ、例えばアプリケーションサーバやデータベースサーバ等が設置されている。
【００１５】
センタＴＥＬ１４は、データセンタの運用者により使用される電話端末である。インシデント管理装置１２は、データセンタにおいて発生したトラブル（以下、「インシデント」とも呼ぶ）への対応状況を管理する情報処理装置である。インシデント管理装置１２の詳細な構成は図２に関連して後述する。担当者ＴＥＬ１８は、障害対応グループの各担当者、本実施の形態では第１担当者〜第３担当者が保持する携帯電話端末である。担当者ＴＥＬ１８の詳細な構成は図６に関連して後述する。
【００１６】
電話制御装置１０は、障害対応グループに対する通話要求を中継し、障害対応グループの各担当者との通話状況を管理する情報処理装置である。電話制御装置１０と担当者ＴＥＬ１８とは、ＰＳＴＮ（Public Switched Telephone Networks）やＩＰ（Internet Protocol）網等、公知の通信網１６を介して接続される。電話制御装置１０の詳細な構成は図４に関連して後述する。外部ＴＥＬ１５は、障害対応グループ以外のメンバーが使用する電話端末である。
【００１７】
図２は、図１のインシデント管理装置１２の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、各機能ブロックは、コンピュータプログラムとして記録媒体に格納され、コンピュータのハードディスクにインストールされ、コンピュータのメインメモリに適宜読み出されてプロセッサにて実行されてもよい。
【００１８】
インシデント管理装置１２は、対応情報保持部２０と、対応情報設定部２２と、対応状況監視部２４とを備える。対応情報保持部２０は、インシデントへの対応に関する情報（以下、「インシデント対応情報」とも呼ぶ）を保持する記憶領域である。
【００１９】
図３は、対応情報保持部２０が保持するデータの構成を模式的に示す。インシデントＩＤフィールドには、インシデントを一意に特定するためのインシデントの識別情報が設定される。グループＩＤフィールドには、インシデントに対応する障害対応グループの識別情報が設定される。例えばＩＤ「アプリケーション」の障害対応グループ（以下、「アプリケーショングループ」とも呼ぶ）は、サーバに搭載されたアプリケーションソフトウェアの障害に対応する。一方で、ＩＤ「インフラ」の障害対応グループは、ネットワーク・ハードウェア・ＯＳ（Operating System）等、サーバの基盤部分の障害に対応する。担当者ＩＤフィールドには、インシデントに対応することが決定した担当者、すなわち対応者の識別情報が設定される。対応状況フィールドには、インシデントに対して対応者により実施されている作業の状況を示す情報が設定される。
【００２０】
図２に戻り対応状況監視部２４は、対応者による障害への対応状況を監視し、その対応状況が更新された場合は、更新後の対応状況をインシデントＩＤとともに対応情報設定部２２へ通知する。この対応状況には、「未接続」および「ログオン済」が含まれる。具体的には、対応状況監視部２４は、インシデント対応情報のそれぞれに設定された対応者のＩＤを特定し、その対応者端末による障害発生サーバへのアクセス状況を検出する。例えば、装置間で設定されたセッションを管理する装置（例えばファイヤウォール）から対応者端末と障害発生サーバとのセッション状態を取得してもよい。また、障害発生サーバのアクセスログから対応者端末による操作内容を取得してもよい。
【００２１】
また対応状況監視部２４は、対応情報保持部２０の各レコードについて、所定の対応状況から所定時間以上変化がない場合、言い換えれば、所定の対応状況が所定時間以上継続した場合は、対応状況の推移が異常である旨を決定して対応情報設定部２２へ通知する。さらに、その旨とグループＩＤとを対応づけて電話制御装置１０にも通知する。本実施の形態では、対応情報保持部２０へ新規レコードが追加される際に対応状況として「未接続」が設定される。その後、１時間が経過しても、対応状況「未接続」が継続する場合、すなわち対応者端末と障害発生サーバ間のセッションが未確立の場合に、対応状況の推移を異常として検出することとする。
【００２２】
対応情報設定部２２は、インシデント対応情報を対応情報保持部２０へ新規登録し、また、対応情報保持部２０に格納済のインシデント対応情報を更新する。例えば、あるインシデントに関するトラブルコールにより対応者が決定した場合、対応情報設定部２２は、そのインシデント・障害対応グループ・対応者それぞれのＩＤの入力を運用者から受け付ける。そして、それらのＩＤを設定した新規のインシデント対応情報を対応情報保持部２０に格納する。また対応情報設定部２２は、インシデントへの対応が完了した旨の入力を運用者から受け付け、そのインシデントに対応するインシデント対応情報を対応情報保持部２０から削除する。
【００２３】
また対応情報設定部２２は、特定のインシデントＩＤと対応づけられた対応状況の更新データを対応状況監視部２４から受け付けた場合、そのインシデントＩＤに対応するインシデント対応情報に対しその更新データを反映させる。また、特定のインシデントＩＤについてその対応状況の推移が異常である旨の通知を対応状況監視部２４から受け付けた場合、そのインシデントＩＤに対応するインシデント対応情報を対応情報保持部２０から削除する。
【００２４】
図４は、図１の電話制御装置１０の機能構成を示すブロック図である。電話制御装置１０は、グループ情報保持部３０と、要求受付部３２と、要求発信部３４と、通話状況設定部３６と、通話状況通知部３８とを備える。グループ情報保持部３０は、障害対応グループの情報と、そのグループに属する各担当者の情報とを対応づけて保持する記憶領域である。
【００２５】
図５は、グループ情報保持部３０が保持するデータの構成を模式的に示す。グループＩＤフィールドには、障害対応グループの識別情報が設定される。グループ電話番号フィールドには、障害対応グループの電話番号（以下、「グループ電話番号」とも呼ぶ）が設定される。担当者ＩＤフィールドには、障害対応グループに属する担当者それぞれの識別情報が設定される。担当者電話番号フィールドには、各担当者の電話番号（以下、「担当者電話番号」とも呼ぶ）が設定される。優先度フィールドには、１つの障害対応グループにおける各担当者への連絡順序が設定される。例えば、アプリケーショングループでは、第１担当者・第２担当者・第３担当者の順にトラブルコールが発信される。
【００２６】
図４に戻り要求受付部３２は、グループ電話番号を指定した、障害対応グループへの通話要求をセンタＴＥＬ１４や外部ＴＥＬ１５から受け付ける。例えば、センタＴＥＬ１４がＩＰ電話機である場合、要求受付部３２は、通話要求として、ＳＩＰ（Session Initiation Protocol）のＩＮＶＩＴＥメッセージをセンタＴＥＬ１４から受信してもよい。
【００２７】
要求発信部３４は、グループ電話番号を指定する通話要求が要求受付部３２において受け付けられた際、インシデント管理装置１２で保持されたインシデント対応情報を参照して、グループ電話番号で指定された障害対応グループが既に障害対応中であるか否かを判別する。本実施の形態では、グループ電話番号で指定された障害対応グループのＩＤを有するインシデント対応情報が存在する場合、既に障害対応中であると判定する。
【００２８】
通話要求で指定された障害対応グループが既に障害対応中である場合、要求発信部３４は、障害対応グループに設定された優先度によらず、インシデントへの対応者に対し通話要求を発信する。具体的には、対応者のＩＤをインシデント管理装置１２から取得し、そのＩＤと対応づけられた担当者電話番号をグループ情報保持部３０から取得する。そして、その担当者電話番号を指定した通話要求を通信網１６へ送出する。担当者ＴＥＬ１８がＩＰ電話機である場合、要求発信部３４は、通話要求として、ＳＩＰのＩＮＶＩＴＥメッセージを担当者ＴＥＬ１８に対して送信してもよい。
【００２９】
その一方で、通話要求で指定された障害対応グループが障害へ未対応である場合、要求発信部３４は、グループ情報保持部３０の保持データを参照して、通話要求で指定されたグループ電話番号に対応する複数の担当者電話番号を特定する。そして、優先度により規定される順序にしたがって、担当者ＴＥＬ１８それぞれの担当者電話番号を指定した通話要求を通信網１６へ順次送出する。例えば、最初に第１担当者ＴＥＬ１８ａへの通話要求を送信し、第１担当者ＴＥＬ１８ａからの応答が所定期間内にない場合は、続いて第２担当者ＴＥＬ１８ｂへの通話要求を送信する。
【００３０】
また要求発信部３４は、インシデントへの対応状況の推移が異常である旨の通知をインシデント管理装置１２から受け付けると、その通知で指定されたグループＩＤに対応する障害対応グループへの通話要求を再び発信する。すなわち、障害対応グループで規定された優先度にしたがって、各担当者へのトラブルコールを再開する。この場合、要求発信部３４は、センタＴＥＬ１４に対しても通話要求を送信することで、センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションを設定する。
【００３１】
また要求発信部３４は、担当者ＴＥＬ１８から通話要求に対する応答を受信すると、その応答を、要求受付部３２を介してセンタＴＥＬ１４へ通知する。以降、センタＴＥＬ１４と担当者ＴＥＬ１８間での通話セッションが確立され、運用者と担当者との会話が開始される。この通話セッションは、例えばＲＴＰ（Real-time Transport Protocol）セッションであってもよい。なお、外部ＴＥＬ１５と担当者ＴＥＬ１８間での通話セッション設定に関しても同様である。
【００３２】
通話状況設定部３６は、センタＴＥＬ１４と担当者ＴＥＬ１８間での通話状況、言い換えれば通話セッションの確立状況を示すデータ（以下、単に「通話状況」と呼ぶ）を設定する。本実施の形態の通話状況は、通話が要求された障害対応グループに属する複数の担当者それぞれに、通話可否および通話要求の発信時刻を対応づけた情報である。例えば、アプリケーショングループにおける通話状況は、第１担当者〜第３担当者のそれぞれに、通話ができたか（ＯＫ）否か（ＮＧ）、および、各担当者の担当者ＴＥＬ１８に対する要求発信部３４からの通話要求発信時刻を組み合わせた情報である。
【００３３】
通話状況設定部３６は、要求発信部３４から担当者ＴＥＬ１８のそれぞれへ送信された通話要求に対する応答結果に応じて通話状況を逐次更新する。具体的には、通話要求に対する応答タイムアウトを検出したタイミング、通話要求に対する担当者ＴＥＬ１８からの応答メッセージが受信された、すなわちセンタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが確立するタイミングで通話状況を更新する。なお前者の場合には通話ＮＧを設定し、後者の場合には通話ＯＫを設定する。
【００３４】
通話状況通知部３８は、通話状況設定部３６において通話状況が設定・更新された際、その通話状況を、同一の障害対応グループに属する各担当者の担当者ＴＥＬ１８へ通知する。ただし本実施の形態では、要求発信部３４により通話要求を発信済の担当者ＴＥＬ１８に対してのみ、障害対応グループにおける通話状況を、通話要求の識別情報とともに送信することとする。例えば、アプリケーショングループへのトラブルコールの場合、第２担当者ＴＥＬ１８ｂへの通話要求がタイムアウトした時点では、第１担当者ＴＥＬ１８ａおよび第２担当者ＴＥＬ１８ｂに対してのみ通話状況を送信する。
【００３５】
図６は、図１の担当者ＴＥＬ１８の機能構成を示すブロック図である。担当者ＴＥＬ１８は、着信受付部４０と、通話処理部４２と、通話状況受付部４４と、表示制御部４６を備える。なお担当者ＴＥＬ１８は、スピーカー、マイクロフォン、ディスプレイをさらに備えている。
【００３６】
着信受付部４０は、電話制御装置１０から送信された通話要求の着信を検出し、予め定められた着信動作（スピーカーでの音声出力や、ディスプレイでの画像表示等）を実行させる。通話処理部４２は、着信受付部４０において通話要求の着信が検出された際に、担当者による所定の通話選択操作（例えば受話ボタンの押下等）が実行されると、その通話要求に対する応答メッセージを電話制御装置１０へ送信する。そして、センタＴＥＬ１４や外部ＴＥＬ１５との間で通話セッションを確立する。通話状況受付部４４は、電話制御装置１０から送信された通話状況のデータを受信する。
【００３７】
表示制御部４６は、画像や文字情報をディスプレイに表示させる。表示制御部４６は、着信履歴表示制御部４８と、通話状況表示制御部５０とを含む。着信履歴表示制御部４８は、着信受付部４０により受け付けられた通話要求に対応する着信履歴をディスプレイに表示させる。通話状況表示制御部５０は、通話状況受付部４４により受け付けられた通話状況を、その通話状況とともに受け付けられた通話要求のＩＤに基づき、その通話状況に対応する通話要求の着信履歴内に表示させる。
【００３８】
なお、通話状況受付部４４は、電話制御装置１０において通話状況が更新されると、その更新データを電話制御装置１０から逐次取得する。そして、通話状況表示制御部５０は、通話状況の表示領域にその更新データを逐次反映させる。したがって、着信履歴内に表示される通話状況には、障害対応グループにおける最新の通話状況が反映される。
【００３９】
図７は、担当者ＴＥＬ１８のディスプレイに表示される着信履歴を模式的に示す。基本情報フィールド５２は、通話要求の受付日時や通話要求の発信元等、通話要求に関する基本情報の表示領域であり、着信履歴表示制御部４８によりその表示データが設定される。通話状況フィールド５４は、通話状況の表示領域であり、通話状況表示制御部５０によりその表示データが設定される。
【００４０】
図７の（ａ）は、アプリケーショングループへのトラブルコールにおいて、第１担当者ＴＥＬ１８ａが応答できなかった場合に、第１担当者ＴＥＬ１８ａに表示される着信履歴を示している。また図７の（ｂ）は、第１担当者ＴＥＬ１８ａの次に通話要求を受け付けた第２担当者ＴＥＬ１８ｂにおいて通話が成立した場合に、第１担当者ＴＥＬ１８ａに表示される着信履歴を示している。図７の（ｂ）で示す着信履歴を確認した第１担当者は、アプリケーショングループへのトラブルコールに対し第２担当者が対応したことを容易に確認でき、運用者へのコールバックが不要であると判断できる。
【００４１】
以上の構成による動作を以下説明する。
図８は、図４の電話制御装置１０の動作を示すフローチャートである。要求受付部３２は、グループ電話番号を指定する通話要求をセンタＴＥＬ１４や外部ＴＥＬ１５から受け付ける（Ｓ１０）。グループ電話番号により指定された障害対応グループにおいてインシデントへの対応者が既に決定されている場合（Ｓ１２のＹ）、要求発信部３４は、その対応者の担当者ＴＥＬ１８に対し通話要求を発信する（Ｓ１４）。インシデントへの対応者が未決定の場合（Ｓ１２のＮ）、要求発信部３４は、グループ電話番号により指定された障害対応グループに属する担当者について、当該装置から通話要求が未発信、かつ、優先度が最も高い担当者を特定する。そして、その担当者ＴＥＬ１８に対し通話要求を発信する（Ｓ１６）。
【００４２】
要求発信部３４は、通話要求に対する応答メッセージが担当者ＴＥＬ１８から受け付けられると、その応答メッセージを通話要求の発信元電話端末へ転送し、その発信元電話端末と担当者ＴＥＬ１８との間で通話セッションを成立させる。通話状況設定部３６は、通話要求に対する担当者ＴＥＬ１８からの応答結果に応じて通話状況を設定・更新する（Ｓ１８）。通話状況通知部３８は、設定・更新された通話状況を担当者ＴＥＬ１８へ通知する（Ｓ２０）。センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが成立しなければ（Ｓ２２のＮ）、Ｓ１６の処理へ戻る。センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが成立した場合は（Ｓ２２のＹ）、本図のフローを終了する。
【００４３】
図９は、図２のインシデント管理装置１２の動作を示すフローチャートである。対応情報設定部２２は、運用者により入力された新たなインシデント対応情報を受け付けて、そのインシデント対応情報を対応情報保持部２０へ新規に登録する（Ｓ３０）。対応状況監視部２４は、対応情報保持部２０で保持される各インシデントに対する、対応者による対応状況を定期的に取得し（Ｓ３２）、その対応状況を対応情報設定部２２により対応情報保持部２０へ反映させる（Ｓ３４）。インシデントに対する対応が完了した場合（Ｓ３６のＹ）、対応情報設定部２２は、そのインシデントに対応するレコードを対応情報保持部２０から削除する（Ｓ３８）。
【００４４】
インシデントへの対応が未完了であり（Ｓ３６のＮ）、対応状況「未接続」の継続時間が所定時間未満であれば（Ｓ４０のＮ）、Ｓ３２の処理に戻る。対応状況「未接続」が所定時間以上継続すると（Ｓ４０のＹ）、対応情報設定部２２は、そのインシデント対応情報を対応情報保持部２０から削除する（Ｓ４２）。また対応状況監視部２４はその旨を電話制御装置１０へ通知し、電話制御装置１０の要求発信部３４は、障害対応グループに属する担当者に対する通話要求の発信処理を再開する（Ｓ４４）。すなわち図８のＳ１６の処理が再開される。
【００４５】
図１０は、図６の担当者ＴＥＬ１８の動作を示すフローチャートである。着信受付部４０において通話要求が受け付けられると（Ｓ５０のＹ）、所定の着信動作が実行される。担当者による通話選択操作が検出されると（Ｓ５２のＹ）、通話処理部４２は、応答メッセージを電話制御装置１０へ送信し、外部の電話端末との通話処理が実行される（Ｓ５４）。通話選択操作が検出されなければ（Ｓ５２のＮ）、Ｓ５４はスキップされる。着信履歴表示制御部４８は、受け付けられた通話要求に対応する着信履歴をディスプレイに表示させる（Ｓ５６）。通話要求が受け付けられなければ（Ｓ５０のＮ）、Ｓ５２〜Ｓ５６はスキップされる。通話状況受付部４４が電話制御装置１０から通話状況のデータを受け付けると（Ｓ５８のＹ）、通話状況表示制御部５０はそのデータを、通話状況に対応する通話要求の着信履歴内に表示させる（Ｓ６０）。通話状況が通知されなければ（Ｓ５８のＮ）、Ｓ６０はスキップされる。
【００４６】
本実施の形態の電話処理システム１００によれば、障害対応グループへのトラブルコールに対する各担当者の通話状況が、電話制御装置１０から担当者ＴＥＬ１８へ通知され、担当者ＴＥＬ１８の着信履歴で表示される。そして、通話状況が更新されると、担当者ＴＥＬ１８のそれぞれにおける通話状況の表示も更新される。これにより、障害対応グループの各担当者は、自身がトラブルコールに応答できなかった場合でも、障害対応グループ全体におけるトラブルコールへの対応状況を容易に把握でき、自身で行うべきアクションを適切かつ迅速に意思決定できる。
【００４７】
また電話処理システム１００によれば、インシデントへの対応者が決定した後に、グループ電話番号への通話要求が受け付けられた場合、予め定められた障害対応グループにおける優先度によらず、対応者との通話セッションが設定される。そして、インシデントへの対応が完了後に、グループ電話番号への通話要求が受け付けられると、再び優先度にしたがってトラブルコールが発信される。言い換えれば、インシデントへの対応状況に応じて、複数の担当者ＴＥＬ１８に対する電話発信の順序が動的に変更される。これにより、インシデントへの対応中は、最新の対応状況を最も正確に把握している対応者に電話を転送して応答させることができる。
【００４８】
さらに電話処理システム１００によれば、インシデントへの対応者が決定した後に、対応者端末と障害発生サーバとが所定時間以上未接続であれば、トラブルコールの発信が再開される。したがって、対応者が障害対応作業に所定時間以上未着手であれば、トラブルコールの発信が再開されることになる。これにより、対応状況の推移が異常と判定される場合は新たな対応者が決定されるため、対応者に不測の事態が発生した場合でも障害回復の遅延を低減しやすくなる。
【００４９】
さらにまた電話処理システム１００によれば、通話状況の通知先は、トラブルコールを既に発信した担当者ＴＥＬ１８に限定される。これにより、トラブルコールが未着信の担当者は、そのトラブルコールの通話状況を受け取らないことになる。トラブルコールは夜間に発信されることもあり、障害対応グループの担当者全員に対し通話状況を通知すると、担当者の負担を増大させる場合もある。電話処理システム１００によれば、通話状況の通知先を限定することで、障害対応グループの担当者に対し本来不必要な負担を課すことを回避できる。
【００５０】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【００５１】
第１の変形例を説明する。上記実施の形態では、電話制御装置１０の通話状況通知部３８は、要求発信部３４から通話要求を発信済の担当者ＴＥＬ１８に対してのみ、障害対応グループでの通話状況を通知した。変形例では、要求発信部３４から通話要求を未発信の担当者ＴＥＬ１８に対しても、障害対応グループでの通話状況を通知してもよい。この場合、担当者ＴＥＬ１８の通話状況表示制御部５０は、通話状況とともに通知された通話要求の識別情報により、その通話状況に対応する通話要求が着信済か否かを判別する。通話状況に対応する通話要求が未着信であるときには、着信履歴とは異なる所定の表示領域、例えばトラブルコールへの対応状況を表示するよう定められた画面にその通話状況を表示させる。この変形例によれば、トラブルコールが未着信の担当者に対しても、そのトラブルコールへの対応状況を通知し、障害対応グループ内での情報共有を促進できる。
【００５２】
第２の変形例を説明する。上記実施の形態では、インシデント管理装置１２の対応状況監視部２４は、対応者端末と障害発生サーバとの接続状態を監視した。変形例では、対応状況監視部２４は、障害発生サーバのアクセスログ等により対応者端末によるプログラムファイルの更新を監視してもよく、所定時間以上経過してもプログラムファイルが未更新である場合に、対応状況の推移が異常であると判定してもよい。また、障害発生サーバから送信される障害回復の通知を監視してもよく、所定時間以上経過しても、その通知が受け付けられない場合に、対応状況の推移が異常であると判定してもよい。
【００５３】
第３の変形例を説明する。上記実施の形態では、電話制御装置１０の要求発信部３４は、インシデントへの対応者決定後は、障害対応グループへの通話要求をその対応者へ転送することとした。変形例では、要求発信部３４は、グループ電話番号とともに指定されたインシデントＩＤに応じて、通話要求の転送先を決定してもよい。
【００５４】
具体的には、要求受付部３２は、グループ電話番号とともにインシデントＩＤが指定された通話要求を、センタＴＥＬ１４や外部ＴＥＬ１５から受け付ける。インシデントＩＤが指定されていない場合は、新たにインシデントＩＤを発効する。要求発信部３４は、インシデント管理装置１２に保持されたインシデント対応情報を参照して、グループ電話番号に対応づけられたインシデントＩＤに対して対応者が決定済か否かを判別する。対応者が決定済であれば、その対応者の担当者ＴＥＬ１８へ通話要求を発信する。一方で対応者が未決定、すなわち新たなインシデントの場合は、障害対応グループで定められた優先度にしたがって通話要求を発信する。なお、別のインシデントに対応中の担当者ＴＥＬ１８に対しては通話要求の発信を抑止してもよい。
【００５５】
この変形例によれば、１つの障害対応グループにおいて複数のインシデントに対応する場合に、トラブルコールの転送先をインシデントに応じて細分化し、トラブルコールの転送先を適切に振分けることができる。すなわち、既に対応者が決定済のインシデントについてはその対応者へトラブルコールを転送でき、新規のインシデントについては優先度にしたがって各担当者へトラブルコールを転送できる。
【００５６】
第４の変形例を説明する。上記実施の形態では、センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが成立してインシデントへの対応者が決定すると、運用者はインシデント対応情報をインシデント管理装置１２へ登録した。しかし実際には、担当者が電話を受けて運用者と会話することにより、インシデントへの対応が不要であることが確認されることがあり、この場合にはそのインシデントは即時クローズされてもよい。すなわち、図９のＳ３０以降の処理は実行されず、運用者からのトラブルコールに対する各担当者の通話状況が、各担当者ＴＥＬ１８へ通知されるのみとなってもよい。また別の例として、Ｓ３０のインシデント対応情報の登録が一旦なされても、運用者によるクローズ処理がすぐに実行されることにより、Ｓ３６のＹからＳ３８が実行されて、そのインシデント対応情報が即時削除されてもよい。
【００５７】
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。
【００５８】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。例えば、請求項に記載のセンタ装置は、電話制御装置１０およびインシデント管理装置１２の組み合わせにより実現されてもよい。
【符号の説明】
【００５９】
１０ 電話制御装置、 １２ インシデント管理装置、 １４ センタＴＥＬ、 １５ 外部ＴＥＬ、 １８ 担当者ＴＥＬ、 ２０ 対応情報保持部、 ２２ 対応情報設定部、 ２４ 対応状況監視部、 ３０ グループ情報保持部、 ３２ 要求受付部、 ３４ 要求発信部、 ３６ 通話状況設定部、 ３８ 通話状況通知部、 ４０ 着信受付部、 ４２ 通話処理部、 ４４ 通話状況受付部、 ４６ 表示制御部、 ４８ 着信履歴表示制御部、 ５０ 通話状況表示制御部、 １００ 電話処理システム。
【技術分野】
【０００１】
この発明は、データ処理技術に関し、特に、電話処理システムおよび電話端末に関する。
【背景技術】
【０００２】
サービス提供中の設備機器で発生する障害について、その障害へ対応すべき複数の担当者が予め定められていることがある。以下の特許文献１では、迅速な障害回復を図るために、複数の担当者のうち障害対応が可能な状態の担当者に対して、障害対応の指示を通知する技術が提案されている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００５−２９３０１０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
設備機器における障害発生を、その設備機器の運用者から複数の担当者へ電話連絡する場合、各担当者の電話端末へ順次連絡することがある。担当者は、運用者からの電話連絡に対応できなかった場合でも、その電話連絡の存在を着信履歴により把握できる。しかし、これまでの着信履歴は電話の発信元や着信時刻等を示すものにすぎず、担当者は、着信履歴を見ても、行うべきアクションを迅速に決定することは困難な場合があると本発明者は考えた。
【０００５】
本発明は、本発明者の上記課題認識に基づきなされたものであり、その主たる目的は、あるインシデントに対応すべきグループに属する担当者の意思決定を支援する技術を提供することである。
【課題を解決するための手段】
【０００６】
上記課題を解決するために、本発明のある態様の電話処理システムは、あるインシデントに対応すべき担当者のグループを管理するセンタ装置と、グループに属する複数の担当者が保持する複数の電話端末と、を備える。センタ装置は、グループに対する通話要求が受け付けられたとき、複数の電話端末のそれぞれに対する通話要求を順次発信する要求発信部と、グループに属する各担当者との通話状況を、複数の電話端末のうち少なくとも当該装置から通話要求を発信した電話端末に対して通知する通話状況通知部と、を有する。複数の電話端末のそれぞれは、センタ装置から通話要求の着信を受け付ける着信受付部と、センタ装置から各担当者との通話状況の通知を受け付ける通話状況受付部と、各担当者との通話状況を、通話要求の着信履歴と対応づけて表示させる表示制御部と、を有する。
【０００７】
本発明の別の態様は、電話端末である。この電話端末は、あるインシデントが発生した際、そのインシデントに対応すべきグループを管理する装置から、通話要求の着信を受け付ける着信受付部と、管理する装置から、グループに属する複数の担当者それぞれとの通話状況の通知を受け付ける通話状況受付部と、複数の担当者それぞれとの通話状況を、通話要求の着信履歴と対応づけて表示させる表示制御部と、を備える。
【０００８】
なお、以上の構成要素の任意の組合せ、本発明の表現を装置、方法、システム、プログラム、プログラムを格納した記録媒体などの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【０００９】
本発明によれば、あるインシデントに対応すべきグループに属する担当者の意思決定を支援できる。
【図面の簡単な説明】
【００１０】
【図１】実施の形態の電話処理システムの構成を示す図である。
【図２】図１のインシデント管理装置の機能構成を示すブロック図である。
【図３】対応情報保持部が保持するデータの構成を模式的に示す図である。
【図４】図１の電話制御装置の機能構成を示すブロック図である。
【図５】グループ情報保持部が保持するデータの構成を模式的に示す図である。
【図６】図１の担当者ＴＥＬの機能構成を示すブロック図である。
【図７】担当者ＴＥＬのディスプレイに表示される着信履歴を模式的に示す図である。
【図８】図４の電話制御装置の動作を示すフローチャートである。
【図９】図２のインシデント管理装置の動作を示すフローチャートである。
【図１０】図６の担当者ＴＥＬの動作を示すフローチャートである。
【発明を実施するための形態】
【００１１】
本発明の実施の形態を説明する前に、まず概要を説明する。
データセンタにて稼働中のサーバで障害が発生した場合、そのデータセンタにおける運用者は、その障害に対応するべく予め定められたグループ（以下、「障害対応グループ」とも呼ぶ）に属する複数の担当者へ順次電話連絡を行う。この電話連絡を、以下では「トラブルコール」とも称する。各担当者は、トラブルコールを携帯電話にて受け付けるが、携帯電話を一時的に保持しないときや会議への参加中等、トラブルコールに応答できない場合もある。
【００１２】
このような場合、各担当者は、携帯電話の着信履歴を後から確認することで、トラブルコールがあったことを把握できる。しかし、そのトラブルコールに対して既に他の担当者が対応中か否か、運用者へのコールバックが必要か否か等の判断がつきにくく、自身がとるべき行動を迅速に意思決定することが困難であった。また、複数の担当者が運用者へコールバックした場合や、トラブルに対応する担当者（以下、「対応者」とも呼ぶ）の決定後に、別の担当者がコールバックした場合等、運用者から各担当者への指示が交錯し、運用者の負担が増加し、またミスの発生要因ともなっていた。
【００１３】
そこで、本実施の形態では、障害対応グループの各担当者の電話端末をグループ化し、運用者と各担当者との通話状況を、各担当者の電話端末における着信履歴に表示させる電話処理システムを提案する。このシステムによれば、障害対応グループの各担当者は、運用者からのトラブルコールに応答できなかった場合でも、運用者と他の担当者との通話状況を容易に把握でき、自身がとるべき行動を迅速かつ適切に意思決定しやすくなる。
【００１４】
図１は、実施の形態の電話処理システムの構成を示す。電話処理システム１００は、電話制御装置１０と、インシデント管理装置１２と、センタＴＥＬ１４と、外部ＴＥＬ１５と、担当者ＴＥＬ１８で総称される第１担当者ＴＥＬ１８ａ、第２担当者ＴＥＬ１８ｂ、第３担当者ＴＥＬ１８ｃとを備える。なお図１には不図示であるが、データセンタには、所定のサービスを外部へ提供するサーバ、例えばアプリケーションサーバやデータベースサーバ等が設置されている。
【００１５】
センタＴＥＬ１４は、データセンタの運用者により使用される電話端末である。インシデント管理装置１２は、データセンタにおいて発生したトラブル（以下、「インシデント」とも呼ぶ）への対応状況を管理する情報処理装置である。インシデント管理装置１２の詳細な構成は図２に関連して後述する。担当者ＴＥＬ１８は、障害対応グループの各担当者、本実施の形態では第１担当者〜第３担当者が保持する携帯電話端末である。担当者ＴＥＬ１８の詳細な構成は図６に関連して後述する。
【００１６】
電話制御装置１０は、障害対応グループに対する通話要求を中継し、障害対応グループの各担当者との通話状況を管理する情報処理装置である。電話制御装置１０と担当者ＴＥＬ１８とは、ＰＳＴＮ（Public Switched Telephone Networks）やＩＰ（Internet Protocol）網等、公知の通信網１６を介して接続される。電話制御装置１０の詳細な構成は図４に関連して後述する。外部ＴＥＬ１５は、障害対応グループ以外のメンバーが使用する電話端末である。
【００１７】
図２は、図１のインシデント管理装置１２の機能構成を示すブロック図である。本明細書のブロック図において示される各ブロックは、ハードウェア的には、コンピュータのＣＰＵをはじめとする素子や機械装置で実現でき、ソフトウェア的にはコンピュータプログラム等によって実現されるが、ここでは、それらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックはハードウェア、ソフトウェアの組合せによっていろいろなかたちで実現できることは、当業者には理解されるところである。例えば、各機能ブロックは、コンピュータプログラムとして記録媒体に格納され、コンピュータのハードディスクにインストールされ、コンピュータのメインメモリに適宜読み出されてプロセッサにて実行されてもよい。
【００１８】
インシデント管理装置１２は、対応情報保持部２０と、対応情報設定部２２と、対応状況監視部２４とを備える。対応情報保持部２０は、インシデントへの対応に関する情報（以下、「インシデント対応情報」とも呼ぶ）を保持する記憶領域である。
【００１９】
図３は、対応情報保持部２０が保持するデータの構成を模式的に示す。インシデントＩＤフィールドには、インシデントを一意に特定するためのインシデントの識別情報が設定される。グループＩＤフィールドには、インシデントに対応する障害対応グループの識別情報が設定される。例えばＩＤ「アプリケーション」の障害対応グループ（以下、「アプリケーショングループ」とも呼ぶ）は、サーバに搭載されたアプリケーションソフトウェアの障害に対応する。一方で、ＩＤ「インフラ」の障害対応グループは、ネットワーク・ハードウェア・ＯＳ（Operating System）等、サーバの基盤部分の障害に対応する。担当者ＩＤフィールドには、インシデントに対応することが決定した担当者、すなわち対応者の識別情報が設定される。対応状況フィールドには、インシデントに対して対応者により実施されている作業の状況を示す情報が設定される。
【００２０】
図２に戻り対応状況監視部２４は、対応者による障害への対応状況を監視し、その対応状況が更新された場合は、更新後の対応状況をインシデントＩＤとともに対応情報設定部２２へ通知する。この対応状況には、「未接続」および「ログオン済」が含まれる。具体的には、対応状況監視部２４は、インシデント対応情報のそれぞれに設定された対応者のＩＤを特定し、その対応者端末による障害発生サーバへのアクセス状況を検出する。例えば、装置間で設定されたセッションを管理する装置（例えばファイヤウォール）から対応者端末と障害発生サーバとのセッション状態を取得してもよい。また、障害発生サーバのアクセスログから対応者端末による操作内容を取得してもよい。
【００２１】
また対応状況監視部２４は、対応情報保持部２０の各レコードについて、所定の対応状況から所定時間以上変化がない場合、言い換えれば、所定の対応状況が所定時間以上継続した場合は、対応状況の推移が異常である旨を決定して対応情報設定部２２へ通知する。さらに、その旨とグループＩＤとを対応づけて電話制御装置１０にも通知する。本実施の形態では、対応情報保持部２０へ新規レコードが追加される際に対応状況として「未接続」が設定される。その後、１時間が経過しても、対応状況「未接続」が継続する場合、すなわち対応者端末と障害発生サーバ間のセッションが未確立の場合に、対応状況の推移を異常として検出することとする。
【００２２】
対応情報設定部２２は、インシデント対応情報を対応情報保持部２０へ新規登録し、また、対応情報保持部２０に格納済のインシデント対応情報を更新する。例えば、あるインシデントに関するトラブルコールにより対応者が決定した場合、対応情報設定部２２は、そのインシデント・障害対応グループ・対応者それぞれのＩＤの入力を運用者から受け付ける。そして、それらのＩＤを設定した新規のインシデント対応情報を対応情報保持部２０に格納する。また対応情報設定部２２は、インシデントへの対応が完了した旨の入力を運用者から受け付け、そのインシデントに対応するインシデント対応情報を対応情報保持部２０から削除する。
【００２３】
また対応情報設定部２２は、特定のインシデントＩＤと対応づけられた対応状況の更新データを対応状況監視部２４から受け付けた場合、そのインシデントＩＤに対応するインシデント対応情報に対しその更新データを反映させる。また、特定のインシデントＩＤについてその対応状況の推移が異常である旨の通知を対応状況監視部２４から受け付けた場合、そのインシデントＩＤに対応するインシデント対応情報を対応情報保持部２０から削除する。
【００２４】
図４は、図１の電話制御装置１０の機能構成を示すブロック図である。電話制御装置１０は、グループ情報保持部３０と、要求受付部３２と、要求発信部３４と、通話状況設定部３６と、通話状況通知部３８とを備える。グループ情報保持部３０は、障害対応グループの情報と、そのグループに属する各担当者の情報とを対応づけて保持する記憶領域である。
【００２５】
図５は、グループ情報保持部３０が保持するデータの構成を模式的に示す。グループＩＤフィールドには、障害対応グループの識別情報が設定される。グループ電話番号フィールドには、障害対応グループの電話番号（以下、「グループ電話番号」とも呼ぶ）が設定される。担当者ＩＤフィールドには、障害対応グループに属する担当者それぞれの識別情報が設定される。担当者電話番号フィールドには、各担当者の電話番号（以下、「担当者電話番号」とも呼ぶ）が設定される。優先度フィールドには、１つの障害対応グループにおける各担当者への連絡順序が設定される。例えば、アプリケーショングループでは、第１担当者・第２担当者・第３担当者の順にトラブルコールが発信される。
【００２６】
図４に戻り要求受付部３２は、グループ電話番号を指定した、障害対応グループへの通話要求をセンタＴＥＬ１４や外部ＴＥＬ１５から受け付ける。例えば、センタＴＥＬ１４がＩＰ電話機である場合、要求受付部３２は、通話要求として、ＳＩＰ（Session Initiation Protocol）のＩＮＶＩＴＥメッセージをセンタＴＥＬ１４から受信してもよい。
【００２７】
要求発信部３４は、グループ電話番号を指定する通話要求が要求受付部３２において受け付けられた際、インシデント管理装置１２で保持されたインシデント対応情報を参照して、グループ電話番号で指定された障害対応グループが既に障害対応中であるか否かを判別する。本実施の形態では、グループ電話番号で指定された障害対応グループのＩＤを有するインシデント対応情報が存在する場合、既に障害対応中であると判定する。
【００２８】
通話要求で指定された障害対応グループが既に障害対応中である場合、要求発信部３４は、障害対応グループに設定された優先度によらず、インシデントへの対応者に対し通話要求を発信する。具体的には、対応者のＩＤをインシデント管理装置１２から取得し、そのＩＤと対応づけられた担当者電話番号をグループ情報保持部３０から取得する。そして、その担当者電話番号を指定した通話要求を通信網１６へ送出する。担当者ＴＥＬ１８がＩＰ電話機である場合、要求発信部３４は、通話要求として、ＳＩＰのＩＮＶＩＴＥメッセージを担当者ＴＥＬ１８に対して送信してもよい。
【００２９】
その一方で、通話要求で指定された障害対応グループが障害へ未対応である場合、要求発信部３４は、グループ情報保持部３０の保持データを参照して、通話要求で指定されたグループ電話番号に対応する複数の担当者電話番号を特定する。そして、優先度により規定される順序にしたがって、担当者ＴＥＬ１８それぞれの担当者電話番号を指定した通話要求を通信網１６へ順次送出する。例えば、最初に第１担当者ＴＥＬ１８ａへの通話要求を送信し、第１担当者ＴＥＬ１８ａからの応答が所定期間内にない場合は、続いて第２担当者ＴＥＬ１８ｂへの通話要求を送信する。
【００３０】
また要求発信部３４は、インシデントへの対応状況の推移が異常である旨の通知をインシデント管理装置１２から受け付けると、その通知で指定されたグループＩＤに対応する障害対応グループへの通話要求を再び発信する。すなわち、障害対応グループで規定された優先度にしたがって、各担当者へのトラブルコールを再開する。この場合、要求発信部３４は、センタＴＥＬ１４に対しても通話要求を送信することで、センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションを設定する。
【００３１】
また要求発信部３４は、担当者ＴＥＬ１８から通話要求に対する応答を受信すると、その応答を、要求受付部３２を介してセンタＴＥＬ１４へ通知する。以降、センタＴＥＬ１４と担当者ＴＥＬ１８間での通話セッションが確立され、運用者と担当者との会話が開始される。この通話セッションは、例えばＲＴＰ（Real-time Transport Protocol）セッションであってもよい。なお、外部ＴＥＬ１５と担当者ＴＥＬ１８間での通話セッション設定に関しても同様である。
【００３２】
通話状況設定部３６は、センタＴＥＬ１４と担当者ＴＥＬ１８間での通話状況、言い換えれば通話セッションの確立状況を示すデータ（以下、単に「通話状況」と呼ぶ）を設定する。本実施の形態の通話状況は、通話が要求された障害対応グループに属する複数の担当者それぞれに、通話可否および通話要求の発信時刻を対応づけた情報である。例えば、アプリケーショングループにおける通話状況は、第１担当者〜第３担当者のそれぞれに、通話ができたか（ＯＫ）否か（ＮＧ）、および、各担当者の担当者ＴＥＬ１８に対する要求発信部３４からの通話要求発信時刻を組み合わせた情報である。
【００３３】
通話状況設定部３６は、要求発信部３４から担当者ＴＥＬ１８のそれぞれへ送信された通話要求に対する応答結果に応じて通話状況を逐次更新する。具体的には、通話要求に対する応答タイムアウトを検出したタイミング、通話要求に対する担当者ＴＥＬ１８からの応答メッセージが受信された、すなわちセンタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが確立するタイミングで通話状況を更新する。なお前者の場合には通話ＮＧを設定し、後者の場合には通話ＯＫを設定する。
【００３４】
通話状況通知部３８は、通話状況設定部３６において通話状況が設定・更新された際、その通話状況を、同一の障害対応グループに属する各担当者の担当者ＴＥＬ１８へ通知する。ただし本実施の形態では、要求発信部３４により通話要求を発信済の担当者ＴＥＬ１８に対してのみ、障害対応グループにおける通話状況を、通話要求の識別情報とともに送信することとする。例えば、アプリケーショングループへのトラブルコールの場合、第２担当者ＴＥＬ１８ｂへの通話要求がタイムアウトした時点では、第１担当者ＴＥＬ１８ａおよび第２担当者ＴＥＬ１８ｂに対してのみ通話状況を送信する。
【００３５】
図６は、図１の担当者ＴＥＬ１８の機能構成を示すブロック図である。担当者ＴＥＬ１８は、着信受付部４０と、通話処理部４２と、通話状況受付部４４と、表示制御部４６を備える。なお担当者ＴＥＬ１８は、スピーカー、マイクロフォン、ディスプレイをさらに備えている。
【００３６】
着信受付部４０は、電話制御装置１０から送信された通話要求の着信を検出し、予め定められた着信動作（スピーカーでの音声出力や、ディスプレイでの画像表示等）を実行させる。通話処理部４２は、着信受付部４０において通話要求の着信が検出された際に、担当者による所定の通話選択操作（例えば受話ボタンの押下等）が実行されると、その通話要求に対する応答メッセージを電話制御装置１０へ送信する。そして、センタＴＥＬ１４や外部ＴＥＬ１５との間で通話セッションを確立する。通話状況受付部４４は、電話制御装置１０から送信された通話状況のデータを受信する。
【００３７】
表示制御部４６は、画像や文字情報をディスプレイに表示させる。表示制御部４６は、着信履歴表示制御部４８と、通話状況表示制御部５０とを含む。着信履歴表示制御部４８は、着信受付部４０により受け付けられた通話要求に対応する着信履歴をディスプレイに表示させる。通話状況表示制御部５０は、通話状況受付部４４により受け付けられた通話状況を、その通話状況とともに受け付けられた通話要求のＩＤに基づき、その通話状況に対応する通話要求の着信履歴内に表示させる。
【００３８】
なお、通話状況受付部４４は、電話制御装置１０において通話状況が更新されると、その更新データを電話制御装置１０から逐次取得する。そして、通話状況表示制御部５０は、通話状況の表示領域にその更新データを逐次反映させる。したがって、着信履歴内に表示される通話状況には、障害対応グループにおける最新の通話状況が反映される。
【００３９】
図７は、担当者ＴＥＬ１８のディスプレイに表示される着信履歴を模式的に示す。基本情報フィールド５２は、通話要求の受付日時や通話要求の発信元等、通話要求に関する基本情報の表示領域であり、着信履歴表示制御部４８によりその表示データが設定される。通話状況フィールド５４は、通話状況の表示領域であり、通話状況表示制御部５０によりその表示データが設定される。
【００４０】
図７の（ａ）は、アプリケーショングループへのトラブルコールにおいて、第１担当者ＴＥＬ１８ａが応答できなかった場合に、第１担当者ＴＥＬ１８ａに表示される着信履歴を示している。また図７の（ｂ）は、第１担当者ＴＥＬ１８ａの次に通話要求を受け付けた第２担当者ＴＥＬ１８ｂにおいて通話が成立した場合に、第１担当者ＴＥＬ１８ａに表示される着信履歴を示している。図７の（ｂ）で示す着信履歴を確認した第１担当者は、アプリケーショングループへのトラブルコールに対し第２担当者が対応したことを容易に確認でき、運用者へのコールバックが不要であると判断できる。
【００４１】
以上の構成による動作を以下説明する。
図８は、図４の電話制御装置１０の動作を示すフローチャートである。要求受付部３２は、グループ電話番号を指定する通話要求をセンタＴＥＬ１４や外部ＴＥＬ１５から受け付ける（Ｓ１０）。グループ電話番号により指定された障害対応グループにおいてインシデントへの対応者が既に決定されている場合（Ｓ１２のＹ）、要求発信部３４は、その対応者の担当者ＴＥＬ１８に対し通話要求を発信する（Ｓ１４）。インシデントへの対応者が未決定の場合（Ｓ１２のＮ）、要求発信部３４は、グループ電話番号により指定された障害対応グループに属する担当者について、当該装置から通話要求が未発信、かつ、優先度が最も高い担当者を特定する。そして、その担当者ＴＥＬ１８に対し通話要求を発信する（Ｓ１６）。
【００４２】
要求発信部３４は、通話要求に対する応答メッセージが担当者ＴＥＬ１８から受け付けられると、その応答メッセージを通話要求の発信元電話端末へ転送し、その発信元電話端末と担当者ＴＥＬ１８との間で通話セッションを成立させる。通話状況設定部３６は、通話要求に対する担当者ＴＥＬ１８からの応答結果に応じて通話状況を設定・更新する（Ｓ１８）。通話状況通知部３８は、設定・更新された通話状況を担当者ＴＥＬ１８へ通知する（Ｓ２０）。センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが成立しなければ（Ｓ２２のＮ）、Ｓ１６の処理へ戻る。センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが成立した場合は（Ｓ２２のＹ）、本図のフローを終了する。
【００４３】
図９は、図２のインシデント管理装置１２の動作を示すフローチャートである。対応情報設定部２２は、運用者により入力された新たなインシデント対応情報を受け付けて、そのインシデント対応情報を対応情報保持部２０へ新規に登録する（Ｓ３０）。対応状況監視部２４は、対応情報保持部２０で保持される各インシデントに対する、対応者による対応状況を定期的に取得し（Ｓ３２）、その対応状況を対応情報設定部２２により対応情報保持部２０へ反映させる（Ｓ３４）。インシデントに対する対応が完了した場合（Ｓ３６のＹ）、対応情報設定部２２は、そのインシデントに対応するレコードを対応情報保持部２０から削除する（Ｓ３８）。
【００４４】
インシデントへの対応が未完了であり（Ｓ３６のＮ）、対応状況「未接続」の継続時間が所定時間未満であれば（Ｓ４０のＮ）、Ｓ３２の処理に戻る。対応状況「未接続」が所定時間以上継続すると（Ｓ４０のＹ）、対応情報設定部２２は、そのインシデント対応情報を対応情報保持部２０から削除する（Ｓ４２）。また対応状況監視部２４はその旨を電話制御装置１０へ通知し、電話制御装置１０の要求発信部３４は、障害対応グループに属する担当者に対する通話要求の発信処理を再開する（Ｓ４４）。すなわち図８のＳ１６の処理が再開される。
【００４５】
図１０は、図６の担当者ＴＥＬ１８の動作を示すフローチャートである。着信受付部４０において通話要求が受け付けられると（Ｓ５０のＹ）、所定の着信動作が実行される。担当者による通話選択操作が検出されると（Ｓ５２のＹ）、通話処理部４２は、応答メッセージを電話制御装置１０へ送信し、外部の電話端末との通話処理が実行される（Ｓ５４）。通話選択操作が検出されなければ（Ｓ５２のＮ）、Ｓ５４はスキップされる。着信履歴表示制御部４８は、受け付けられた通話要求に対応する着信履歴をディスプレイに表示させる（Ｓ５６）。通話要求が受け付けられなければ（Ｓ５０のＮ）、Ｓ５２〜Ｓ５６はスキップされる。通話状況受付部４４が電話制御装置１０から通話状況のデータを受け付けると（Ｓ５８のＹ）、通話状況表示制御部５０はそのデータを、通話状況に対応する通話要求の着信履歴内に表示させる（Ｓ６０）。通話状況が通知されなければ（Ｓ５８のＮ）、Ｓ６０はスキップされる。
【００４６】
本実施の形態の電話処理システム１００によれば、障害対応グループへのトラブルコールに対する各担当者の通話状況が、電話制御装置１０から担当者ＴＥＬ１８へ通知され、担当者ＴＥＬ１８の着信履歴で表示される。そして、通話状況が更新されると、担当者ＴＥＬ１８のそれぞれにおける通話状況の表示も更新される。これにより、障害対応グループの各担当者は、自身がトラブルコールに応答できなかった場合でも、障害対応グループ全体におけるトラブルコールへの対応状況を容易に把握でき、自身で行うべきアクションを適切かつ迅速に意思決定できる。
【００４７】
また電話処理システム１００によれば、インシデントへの対応者が決定した後に、グループ電話番号への通話要求が受け付けられた場合、予め定められた障害対応グループにおける優先度によらず、対応者との通話セッションが設定される。そして、インシデントへの対応が完了後に、グループ電話番号への通話要求が受け付けられると、再び優先度にしたがってトラブルコールが発信される。言い換えれば、インシデントへの対応状況に応じて、複数の担当者ＴＥＬ１８に対する電話発信の順序が動的に変更される。これにより、インシデントへの対応中は、最新の対応状況を最も正確に把握している対応者に電話を転送して応答させることができる。
【００４８】
さらに電話処理システム１００によれば、インシデントへの対応者が決定した後に、対応者端末と障害発生サーバとが所定時間以上未接続であれば、トラブルコールの発信が再開される。したがって、対応者が障害対応作業に所定時間以上未着手であれば、トラブルコールの発信が再開されることになる。これにより、対応状況の推移が異常と判定される場合は新たな対応者が決定されるため、対応者に不測の事態が発生した場合でも障害回復の遅延を低減しやすくなる。
【００４９】
さらにまた電話処理システム１００によれば、通話状況の通知先は、トラブルコールを既に発信した担当者ＴＥＬ１８に限定される。これにより、トラブルコールが未着信の担当者は、そのトラブルコールの通話状況を受け取らないことになる。トラブルコールは夜間に発信されることもあり、障害対応グループの担当者全員に対し通話状況を通知すると、担当者の負担を増大させる場合もある。電話処理システム１００によれば、通話状況の通知先を限定することで、障害対応グループの担当者に対し本来不必要な負担を課すことを回避できる。
【００５０】
以上、本発明を実施の形態をもとに説明した。この実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。以下変形例を示す。
【００５１】
第１の変形例を説明する。上記実施の形態では、電話制御装置１０の通話状況通知部３８は、要求発信部３４から通話要求を発信済の担当者ＴＥＬ１８に対してのみ、障害対応グループでの通話状況を通知した。変形例では、要求発信部３４から通話要求を未発信の担当者ＴＥＬ１８に対しても、障害対応グループでの通話状況を通知してもよい。この場合、担当者ＴＥＬ１８の通話状況表示制御部５０は、通話状況とともに通知された通話要求の識別情報により、その通話状況に対応する通話要求が着信済か否かを判別する。通話状況に対応する通話要求が未着信であるときには、着信履歴とは異なる所定の表示領域、例えばトラブルコールへの対応状況を表示するよう定められた画面にその通話状況を表示させる。この変形例によれば、トラブルコールが未着信の担当者に対しても、そのトラブルコールへの対応状況を通知し、障害対応グループ内での情報共有を促進できる。
【００５２】
第２の変形例を説明する。上記実施の形態では、インシデント管理装置１２の対応状況監視部２４は、対応者端末と障害発生サーバとの接続状態を監視した。変形例では、対応状況監視部２４は、障害発生サーバのアクセスログ等により対応者端末によるプログラムファイルの更新を監視してもよく、所定時間以上経過してもプログラムファイルが未更新である場合に、対応状況の推移が異常であると判定してもよい。また、障害発生サーバから送信される障害回復の通知を監視してもよく、所定時間以上経過しても、その通知が受け付けられない場合に、対応状況の推移が異常であると判定してもよい。
【００５３】
第３の変形例を説明する。上記実施の形態では、電話制御装置１０の要求発信部３４は、インシデントへの対応者決定後は、障害対応グループへの通話要求をその対応者へ転送することとした。変形例では、要求発信部３４は、グループ電話番号とともに指定されたインシデントＩＤに応じて、通話要求の転送先を決定してもよい。
【００５４】
具体的には、要求受付部３２は、グループ電話番号とともにインシデントＩＤが指定された通話要求を、センタＴＥＬ１４や外部ＴＥＬ１５から受け付ける。インシデントＩＤが指定されていない場合は、新たにインシデントＩＤを発効する。要求発信部３４は、インシデント管理装置１２に保持されたインシデント対応情報を参照して、グループ電話番号に対応づけられたインシデントＩＤに対して対応者が決定済か否かを判別する。対応者が決定済であれば、その対応者の担当者ＴＥＬ１８へ通話要求を発信する。一方で対応者が未決定、すなわち新たなインシデントの場合は、障害対応グループで定められた優先度にしたがって通話要求を発信する。なお、別のインシデントに対応中の担当者ＴＥＬ１８に対しては通話要求の発信を抑止してもよい。
【００５５】
この変形例によれば、１つの障害対応グループにおいて複数のインシデントに対応する場合に、トラブルコールの転送先をインシデントに応じて細分化し、トラブルコールの転送先を適切に振分けることができる。すなわち、既に対応者が決定済のインシデントについてはその対応者へトラブルコールを転送でき、新規のインシデントについては優先度にしたがって各担当者へトラブルコールを転送できる。
【００５６】
第４の変形例を説明する。上記実施の形態では、センタＴＥＬ１４と担当者ＴＥＬ１８との間で通話セッションが成立してインシデントへの対応者が決定すると、運用者はインシデント対応情報をインシデント管理装置１２へ登録した。しかし実際には、担当者が電話を受けて運用者と会話することにより、インシデントへの対応が不要であることが確認されることがあり、この場合にはそのインシデントは即時クローズされてもよい。すなわち、図９のＳ３０以降の処理は実行されず、運用者からのトラブルコールに対する各担当者の通話状況が、各担当者ＴＥＬ１８へ通知されるのみとなってもよい。また別の例として、Ｓ３０のインシデント対応情報の登録が一旦なされても、運用者によるクローズ処理がすぐに実行されることにより、Ｓ３６のＹからＳ３８が実行されて、そのインシデント対応情報が即時削除されてもよい。
【００５７】
上述した実施の形態および変形例の任意の組み合わせもまた本発明の実施の形態として有用である。組み合わせによって生じる新たな実施の形態は、組み合わされる実施の形態および変形例それぞれの効果をあわせもつ。
【００５８】
請求項に記載の各構成要件が果たすべき機能は、実施の形態および変形例において示された各構成要素の単体もしくはそれらの連携によって実現されることも当業者には理解されるところである。例えば、請求項に記載のセンタ装置は、電話制御装置１０およびインシデント管理装置１２の組み合わせにより実現されてもよい。
【符号の説明】
【００５９】
１０ 電話制御装置、 １２ インシデント管理装置、 １４ センタＴＥＬ、 １５ 外部ＴＥＬ、 １８ 担当者ＴＥＬ、 ２０ 対応情報保持部、 ２２ 対応情報設定部、 ２４ 対応状況監視部、 ３０ グループ情報保持部、 ３２ 要求受付部、 ３４ 要求発信部、 ３６ 通話状況設定部、 ３８ 通話状況通知部、 ４０ 着信受付部、 ４２ 通話処理部、 ４４ 通話状況受付部、 ４６ 表示制御部、 ４８ 着信履歴表示制御部、 ５０ 通話状況表示制御部、 １００ 電話処理システム。
【特許請求の範囲】
【請求項１】
あるインシデントに対応すべき担当者のグループを管理するセンタ装置と、
前記グループに属する複数の担当者が保持する複数の電話端末と、を備え、
前記センタ装置は、
前記グループに対する通話要求が受け付けられたとき、前記複数の電話端末のそれぞれに対する通話要求を順次発信する要求発信部と、
前記グループに属する各担当者との通話状況を、前記複数の電話端末のうち少なくとも当該装置から通話要求を発信した電話端末に対して通知する通話状況通知部と、を有し、
前記複数の電話端末のそれぞれは、
前記センタ装置から通話要求の着信を受け付ける着信受付部と、
前記センタ装置から前記各担当者との通話状況の通知を受け付ける通話状況受付部と、
前記各担当者との通話状況を、前記通話要求の着信履歴と対応づけて表示させる表示制御部と、を有することを特徴とする電話処理システム。
【請求項２】
前記センタ装置の通話状況通知部は、前記各担当者との通話状況が更新された際、更新後の通話状況を前記電話端末へ通知し、
前記電話端末の表示制御部は、前記通話要求の着信履歴と対応づけて表示させる通話状況を、前記更新後の通話状況へ切替えることを特徴とする請求項１に記載の電話処理システム。
【請求項３】
前記センタ装置の通話状況通知部は、当該装置から通話要求を未発信の電話端末に対しても、前記各担当者との通話状況を通知し、
前記電話端末の表示制御部は、前記各担当者との通話状況に対応する通話要求が未着信であっても、前記各担当者との通話状況を所定の表示領域に表示させることを特徴とする請求項１または２に記載の電話処理システム。
【請求項４】
前記センタ装置は、前記複数の担当者のうち前記インシデントに対応する担当者による対応状況を監視する対応状況監視部をさらに備え、
前記センタ装置の要求発信部は、前記対応状況の推移に応じて、前記複数の電話端末のそれぞれに対する通話要求の発信を再開することを特徴とする請求項１から３のいずれかに記載の電話処理システム。
【請求項５】
前記センタ装置の要求発信部は、前記インシデントに対応する担当者が決定された後、前記グループに対する通話要求が受け付けられた際は、前記インシデントに対応する担当者が保持する電話端末に対して通話要求を発信することを特徴とする請求項１から４のいずれかに記載の電話処理システム。
【請求項６】
あるインシデントが発生した際、そのインシデントに対応すべきグループを管理する装置から、通話要求の着信を受け付ける着信受付部と、
前記管理する装置から、前記グループに属する複数の担当者それぞれとの通話状況の通知を受け付ける通話状況受付部と、
前記複数の担当者それぞれとの通話状況を、前記通話要求の着信履歴と対応づけて表示させる表示制御部と、
を備えることを特徴とする電話端末。
【請求項１】
あるインシデントに対応すべき担当者のグループを管理するセンタ装置と、
前記グループに属する複数の担当者が保持する複数の電話端末と、を備え、
前記センタ装置は、
前記グループに対する通話要求が受け付けられたとき、前記複数の電話端末のそれぞれに対する通話要求を順次発信する要求発信部と、
前記グループに属する各担当者との通話状況を、前記複数の電話端末のうち少なくとも当該装置から通話要求を発信した電話端末に対して通知する通話状況通知部と、を有し、
前記複数の電話端末のそれぞれは、
前記センタ装置から通話要求の着信を受け付ける着信受付部と、
前記センタ装置から前記各担当者との通話状況の通知を受け付ける通話状況受付部と、
前記各担当者との通話状況を、前記通話要求の着信履歴と対応づけて表示させる表示制御部と、を有することを特徴とする電話処理システム。
【請求項２】
前記センタ装置の通話状況通知部は、前記各担当者との通話状況が更新された際、更新後の通話状況を前記電話端末へ通知し、
前記電話端末の表示制御部は、前記通話要求の着信履歴と対応づけて表示させる通話状況を、前記更新後の通話状況へ切替えることを特徴とする請求項１に記載の電話処理システム。
【請求項３】
前記センタ装置の通話状況通知部は、当該装置から通話要求を未発信の電話端末に対しても、前記各担当者との通話状況を通知し、
前記電話端末の表示制御部は、前記各担当者との通話状況に対応する通話要求が未着信であっても、前記各担当者との通話状況を所定の表示領域に表示させることを特徴とする請求項１または２に記載の電話処理システム。
【請求項４】
前記センタ装置は、前記複数の担当者のうち前記インシデントに対応する担当者による対応状況を監視する対応状況監視部をさらに備え、
前記センタ装置の要求発信部は、前記対応状況の推移に応じて、前記複数の電話端末のそれぞれに対する通話要求の発信を再開することを特徴とする請求項１から３のいずれかに記載の電話処理システム。
【請求項５】
前記センタ装置の要求発信部は、前記インシデントに対応する担当者が決定された後、前記グループに対する通話要求が受け付けられた際は、前記インシデントに対応する担当者が保持する電話端末に対して通話要求を発信することを特徴とする請求項１から４のいずれかに記載の電話処理システム。
【請求項６】
あるインシデントが発生した際、そのインシデントに対応すべきグループを管理する装置から、通話要求の着信を受け付ける着信受付部と、
前記管理する装置から、前記グループに属する複数の担当者それぞれとの通話状況の通知を受け付ける通話状況受付部と、
前記複数の担当者それぞれとの通話状況を、前記通話要求の着信履歴と対応づけて表示させる表示制御部と、
を備えることを特徴とする電話端末。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公開番号】特開２０１１−１３９４０１（Ｐ２０１１−１３９４０１Ａ）
【公開日】平成２３年７月１４日（２０１１．７．１４）
【国際特許分類】
【出願番号】特願２０１０−５５（Ｐ２０１０−５５）
【出願日】平成２２年１月４日（２０１０．１．４）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
【公開日】平成２３年７月１４日（２０１１．７．１４）
【国際特許分類】
【出願日】平成２２年１月４日（２０１０．１．４）
【出願人】（０００１５５４６９）株式会社野村総合研究所 (1,067)
【Ｆターム（参考）】
[ Back to top ]