(58)【調査した分野】(Int.Cl.,DB名)
前記管理サーバの前記情報管理手段は、前記通信手段により前記現場用端末装置から受信した前記リソースの前記ステータス情報に基づき、当該リソースが属す前記各業務の稼働状態を特定し管理すること、を特徴とする、請求項1に記載の業務復旧支援システム。
前記管理サーバは、前記情報管理手段に管理されている前記ステータス情報および前記進捗情報に基づいて得られる前記リソースごとの前記対策の実施状況に基づき、当該リソースが属す前記各業務の稼働が再開される時間を予測する予測手段をさらに備えること、を特徴とする、請求項1または請求項2に記載の業務復旧支援システム。
【発明を実施するための形態】
【0014】
以下、添付図面を参照して、本発明の実施形態について詳細に説明する。
本実施形態の業務復旧支援システムは、管理対象の業務に関して、その業務を遂行するために必要な各リソース(人的リソース、設備、資材など)の稼働状態を管理する。そして、リソースごとの稼働状態に応じて、予め定められた、各リソースを本来の稼働状態(業務を遂行するために要求される通常の状態)に復旧させるための対策を提示する。本実施形態では、災害等によって発生した被害に基づいて業務を復旧するための対策を設定するのではなく、業務を遂行するために必要な個々のリソースが本来の稼働状態に復帰するようにリソースごとに設定された対策を実施することにより、結果的に業務が復旧するように支援を行う。したがって、本実施形態による業務復旧支援システムを運用するにあたり、起こり得る災害を予め想定して被害を予測する必要はない。
【0015】
<システム構成例>
まず、本実施形態が適用される業務復旧支援システムの全体構成について説明する。
図1は、本実施形態の業務復旧支援システムの構成例を示す図である。
図1に示すように、本実施形態の業務復旧支援システムは、現場用端末装置100と、管理サーバ200と、管理用端末装置300とを備える。現場用端末装置100と管理サーバ200とは、ネットワーク400を介して接続されており、管理用端末装置300は、管理サーバ200に直接接続されている。
【0016】
現場用端末装置100は、業務の遂行に必要な個々のリソースの稼働状態についての情報を入力するために用いられる装置である。現場用端末装置100としては、通信機能を備えた携帯型の情報処理装置が好適である。例えば、電話機能を備えた携帯型情報機器(いわゆるスマートフォン)、タブレット型情報端末、ノート型パーソナルコンピュータ等を現場用端末装置100として用いることができる。なお、使用環境によっては、デスクトップ型パーソナルコンピュータ等の据え置き型の装置を用いても良い。
【0017】
この現場用端末装置100は、現場担当者が所持し、その現場担当者が担当するリソースの稼働状態の情報を入力するために用いる。入力された情報は、ネットワーク400を介して管理サーバ200へ送信される。現場担当者は、通常、リソースごとに1名から数名が割り当てられ、これに伴って、現場用端末装置100は、リソースごとに1台から数台が用意される。一方、1人の現場担当者が複数のリソースを担当することが可能であり、この場合、その現場担当者は、自身が所持する現場用端末装置100を用いて、自身が担当する複数のリソースに関する情報を入力する。
【0018】
また、現場用端末装置100は、入力された個々のリソースの稼働状態に応じて、そのリソースを本来の稼働状態に戻すために実施すべき対策を提示する。したがって、現場担当者は、現場用端末装置100を用いてリソースに関する情報を入力すると、入力したリソースに関して、稼働状態を本来の状態に戻すために実施すべき対策を現場用端末装置100から得ることができる。
【0019】
管理サーバ200は、各現場用端末装置100により入力されたリソースごとの稼働状態の情報を収集し、各リソースが属す業務ごとに管理する。そして、各現場用端末装置100に、同じ業務に属すリソースに対応する現場用端末装置100から収集した情報を配信する。これにより、各現場用端末装置100は、自身が対応付けられたリソースが属す業務と同じ業務に属すリソースに関する情報を取得する。この情報は、現場用端末装置100を用いて現場担当者が確認することができる。そのため、各現場担当者は、業務単位でリソースの稼働状態を把握することができ、例えば、特に稼働状態の復帰が遅れているリソースに対する対策を優先的に実施させることが可能となる。また、管理サーバ200は、管理対象として設定された複数の業務に属すリソースの稼働状態の情報を収集し、管理する。これにより、業務の復旧が必要な事態が生じた際に、業務単位での復旧状況を把握することが可能となる。なお、管理サーバ200は、例えば、パーソナルコンピュータを用いて実現される。この場合、管理サーバ200を実現するパーソナルコンピュータは、演算手段であるCPUと、記憶手段であるメモリおよび磁気ディスク装置等を備える。そして、記憶手段に格納されているプログラムをCPUが読み出して実行することにより、後述する管理サーバ200の各機能が実現される。
【0020】
管理用端末装置300は、管理サーバ200において管理される情報を表示し、管理対象である各種業務の稼働状態や復旧状況を確認するために用いられる。すなわち、管理用端末装置300は、管理サーバ200の操作端末として機能する。図示の構成例では、管理用端末装置300は、管理サーバ200に直接接続されているが、ネットワーク400や、ネットワーク400とは異なる固有のネットワーク等を介して管理サーバ200と接続されても良い。なお、管理用端末装置300は、例えば、パーソナルコンピュータを用いて実現される。この場合、管理用端末装置300を実現するパーソナルコンピュータは、演算手段であるCPUと、記憶手段であるメモリおよび磁気ディスク装置等を備える。そして、記憶手段に格納されているプログラムをCPUが読み出して実行することにより、後述する管理用端末装置300の各機能が実現される。
【0021】
ネットワーク400の具体的な構成は、本実施形態のシステムの運用環境等に応じて適宜に設定される。例えば、インターネット等の既存のネットワークを用いて構成しても良いし、専用回線等を用いて構成しても良い。通信プロトコルや回線の種類は特に限定されず、無線回線か有線回線かも問わない。また、ネットワーク400の一部が電話回線であっても良い。例えば、現場用端末装置100が電話機能を備える場合、この電話機能によりネットワーク400の電話回線に接続することができる。
【0022】
<現場用端末装置の機能構成>
図2は、現場用端末装置100の機能構成例を示す図である。
図2に示すように、本実施形態の現場用端末装置100は、画像表示部110と、入力操作部120と、ユーザ・インターフェイス制御部130と、通信制御部140と、リソース情報記憶部150と、対策情報記憶部160とを備える。
【0023】
画像表示部110は、例えば液晶ディスプレイ等のディスプレイ装置により実現され、各種の画面を表示する。本実施形態では、リソースの稼働状態の情報を提示する画面や、使用者(現場担当者)がデータやコマンドを入力するために用いられる入力画面等が表示される。
【0024】
入力操作部120は、使用者(現場担当者)がデータや制御コマンドの入力操作を行うための入力デバイスである。本実施形態では、画像表示部110の表示画面に重ねて設けられたタッチパネルを入力操作部120として用いる。このような構成とすることにより、使用者(現場担当者)は、画像表示部110に表示される入力画面を見ながら、画面上の特定の位置(ボタンオブジェクトの表示位置等)にタッチすることにより、リソースに関する情報や各種のコマンドを入力することが可能となる。
【0025】
ユーザ・インターフェイス制御部130は、画像表示部110に情報提示画面や入力画面を表示させる。そして、使用者(現場担当者)が入力操作部120を用いた操作を行うと、ユーザ・インターフェイス制御部130は、検出された操作を表示中の画面に対する入力操作として受け付ける。本実施形態において、ユーザ・インターフェイス制御部130が提供する画面の詳細については後述する。
【0026】
通信制御部140は、入力操作部120の操作により入力されたリソースの稼働状態の情報を管理サーバ200へ送信する。また、管理サーバ200から他の現場用端末装置100において入力されたリソースの稼働状態の情報等を受信する。また、特に図示しないが、現場用端末装置100は、この通信制御部140の制御によりネットワーク400を介して情報の送受信を行うためのネットワーク・インターフェイス(電話機能を備える現場用端末装置100では、電話回線への接続機構を含む)を備える。
【0027】
リソース情報記憶部150は、入力操作部120の操作により入力されたリソースの稼働状態の情報および通信制御部140が管理サーバ200から受信したリソースの稼働状態の情報を保持する。このリソース情報記憶部150は、例えば、フラッシュメモリ等の書き換え可能な不揮発性メモリにより実現される。
【0028】
対策情報記憶部160は、各リソースに関して、その稼働状態に応じて設定された実施すべき対策の情報を保持する。この対策情報記憶部160は、例えば、ROM(Read Only Memory)等の不揮発性メモリにより実現される。
【0029】
<インターフェイス画面の構成>
ここで、ユーザ・インターフェイス制御部130により画像表示部110に表示される各種の画面について説明する。本実施形態では、現場用端末装置100における情報の入出力のためにユーザ・インターフェイス制御部130が制御する画面として、メニュー画面100Aと、リソース状態確認画面100Bと、稼働状態入力画面100Cと、復旧管理画面100Dと、対策情報確認画面100Eの5種類の画面を用意する。
【0030】
図3は、メニュー画面100Aの構成例を示す図である。
メニュー画面100Aは、現場用端末装置100を使用する際に初期的に表示され、各種の機能を呼び出すための画面である。
図3に示す例では、メニュー画面100Aに、「通知」、「リソース」、「復旧情報」、「履歴」、「ログイン」、「チェックイン」の6個のボタン・オブジェクトが表示されている。「通知」ボタンは、現場用端末装置100を用いて入力した情報を管理サーバ200へ送信する処理を実行させるためのボタンである。「リソース」ボタンは、リソース状態確認画面100Bを呼び出すためのボタンである。リソース状態確認画面100Bの詳細については後述する。「復旧情報」ボタンは、復旧管理画面100Dを呼び出すためのボタンである。復旧管理画面100Dの詳細については後述する。「履歴」ボタンは、業務やリソースの復旧作業を行うのに伴ってやり取りされた通信等の履歴や内容を表示させるためのボタンである。「ログイン」ボタンは、現場用端末装置100の使用者(現場担当者)の認証情報を入力して現場用端末装置100を使用可能とするログイン操作を行うためのボタンである。「チェックイン」ボタンは、業務やリソースの復旧作業を現に行っている作業者を登録するチェックイン操作を行うためのボタンである。なお、
図3に示すメニュー画面100Aの構成は例示に過ぎない。メニュー画面100Aの機能としては、少なくとも図示の「通知」ボタン、「リソース」ボタン、「復旧情報」ボタンに相当する機能が存在すれば良く、ボタンの種類や配置は図示の例に限定されない。
【0031】
図4は、リソース状態確認画面100Bの構成例を示す図である。
図3に示したメニュー画面100Aで「リソース」ボタンにタッチすると、ユーザ・インターフェイス制御部130により、リソース状態確認画面100Bが呼び出されて、画像表示部110に表示される。
図4に示す例では、リソース状態確認画面100Bに、業務を遂行するために不可欠な「リソース」が並べて記載され、各「リソース」に関して、「ステータス」、「更新日時」の表示欄が設けられている。
【0032】
リソース状態確認画面100Bに記載される「リソース」は、業務において利用されるリソースのうち、そのリソースが稼働していないとその業務を遂行することができないような、不可欠なリソースである。各業務におけるそのような不可欠なリソースは、予め業務内容を分析して抽出しておく。また、図示の例では、4種類の「リソース」(「派遣スタッフ」、「自動倉庫」、「FAX」、「PC」)がリソース状態確認画面100Bに記載されているが、これらは例示に過ぎない。抽出された全ての「リソース」をリソース状態確認画面100B上に一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各リソースを表示できるようにすることができる。
【0033】
図4に示すリソース状態確認画面100Bの「ステータス」は、「リソース」の稼働状態を示す情報である。この情報は、入力操作部120を操作して入力されるか、または管理サーバ200からネットワーク400を介して取得する。図示のリソース状態確認画面100Bにおいて、稼働状態の情報が入力されていない「リソース」については、「ステータス」欄は空欄となり、稼働状態の情報が入力されている「リソース」については、「ステータス」欄に、入力されている稼働状態を表すマークが表示される。図示の例では、「派遣スタッフ」の「ステータス」欄は空欄であり、その他の各「リソース」の「ステータス」欄にはマークが表示されている。
【0034】
ここで、リソースの稼働状態についてさらに説明する。本実施形態では、リソースの稼働状態を次の4段階で設定する。
・リソースが本来の状態で稼働しており、将来的にリソースの稼働が低下する要因が存在すると認識されない状態(Green)
・リソースが本来の状態で稼働しているが、将来的にリソースの稼働が低下する要因が存在すると認識される状態(Yellow)
・リソースは稼働しているが、本来の状態よりも稼働レベルが低下している状態(Orange)
・リソースが稼働していない状態(Red)
【0035】
そこで、リソース状態確認画面100Bの「ステータス」欄に表示されるマークは、上記の4段階(「Green」、「Yellow」、「Orange」、「Red」)の稼働状態のいずれに該当するかに応じて、緑色、黄色、橙色、赤色に色分けして表示されるものとする(「ステータス」欄に表示されるマークではなく、「ステータス」欄自体を色分けして区別しても良い)。なお、リソースの稼働状態を4段階に分けたこと、各段階を「Green」、「Yellow」、「Orange」、「Red」で表現したことは、いずれも例示に過ぎない。管理対象の業務やリソースの内容に応じて、稼働状態を3段階以下の段階数で設定しても良いし、5段階以上の段階数で設定しても良い。また、稼働状態の各段階を識別するために、色分け以外の識別方法を用いても良い。さらに、本実施形態におけるリソースの稼働状態に関する表現としては、上記の4段階に加え、稼働状態の情報が入力されていない場合(「ステータス」欄が空欄である場合)を一つの状態として把握することもできる。
【0036】
図4に示すリソース状態確認画面100Bの「更新日時」は、「リソース」の「ステータス」の情報が入力された日時を示す。2回目以降の入力(更新)が行われた場合は、最後の入力が行われた日時に書き換えられる。この日時は、「ステータス」の情報が自装置の入力操作部120の操作により入力された場合は、入力操作が行われた際に、現場用端末装置100の時計機能(図示せず)から取得される。また、「ステータス」の情報を管理サーバ200から受信して取得した場合は、「ステータス」の情報と共に管理サーバ200から受信する。
【0037】
以上のように、本実施形態において、リソース状態確認画面100Bおよび入力操作部120は、ステータスの情報を入力するためのステータス情報入力手段として機能する。上記のように構成されたリソース状態確認画面100Bにおいて、所望のリソースを選択する操作(例えば、「リソース」欄にタッチする操作等)を行うと、ユーザ・インターフェイス制御部130により、選択されたリソースに関する稼働状態入力画面100Cが呼び出され、リソース状態確認画面100Bに替えて画像表示部110に表示される。
【0038】
図5は、稼働状態入力画面100Cの構成例を示す図である。
図5に示す例では、
図4に示したリソース状態確認画面100Bで選択されたリソースの「派遣スタッフ」に関する稼働状態入力画面100Cが表示されている。図示の稼働状態入力画面100Cには、「ステータス」、「説明」の各表示欄と、リソースが該当する稼働状態を指定するための「チェック」欄とが設けられている。図示の稼働状態入力画面100Cの「ステータス」欄には、リソースの稼働状態の種類を示す「Green」「Yellow」、「Orange」、「Red」の各項目が記載されている。
【0039】
図5に示す稼働状態入力画面100Cの「説明」欄には、リソースの稼働状態の種類ごとに、そのリソースの稼働状態が「ステータス」欄に記載された状態であると判断するための基準が記載される。
図5に示す例は、リソース「派遣スタッフ」に関する稼働状態入力画面100Cであるので、リソース「派遣スタッフ」の稼働状態が「Green」と判断されるための具体的な基準が稼働状態「Green」に対応する「説明」欄に、リソース「派遣スタッフ」の稼働状態が「Yellow」と判断されるための具体的な基準が稼働状態「Yellow」に対応する「説明」欄に、リソース「派遣スタッフ」の稼働状態が「Orange」と判断されるための具体的な基準が稼働状態「Orange」に対応する「説明」欄に、リソース「派遣スタッフ」の稼働状態が「Red」と判断されるための具体的な基準が稼働状態「Red」に対応する「説明」欄に、それぞれ記載される。各「説明」欄に記載される稼働状態の判断基準は、予め業務やリソースの種類に応じて設定される。例えば、人的リソースであれば、全員で10名のスタッフのうち、稼働人数が8名以上であれば「Green」、5名以下であれば「Red」等としたり、特定の人物が稼働可能であれば「Green」、稼働できなければ「Orange」等のように、具体的な実情に合わせて設定される。
【0040】
図5に示す稼働状態入力画面100Cの「チェック」欄には、ラジオボタン等の排他的な選択を行うためのオブジェクトが設けられている。現場用端末装置100の使用者(現場担当者)は、「説明」欄の記載に基づいて、リソースの現在の状態が稼働状態のどの段階(ステータス)に該当するかを判断する。そして、該当するステータスの「チェック」欄をチェックする操作(例えば、「チェック」欄をタッチする操作等)を行うことにより、チェックされた「ステータス」が、そのリソースの稼働状態として指定される。
図5に示す例では、「Yellow」が指定されている(以下、4段階のステータスの何れかに特定された稼働状態の情報を「ステータス情報」と呼ぶ)。
【0041】
上記のようにして、リソースのステータス情報が入力されると、ユーザ・インターフェイス制御部130は、操作対象のリソースと指定されたステータス情報および操作が行われた日時の情報とを関連付けて、リソース情報記憶部150に格納する。この後、画像表示部110の表示がリソース状態確認画面100Bに移行すると、稼働状態入力画面100Cで入力されたステータス情報が反映された画面が表示されることとなる。例えば、
図4に示したリソース状態確認画面100Bでは、「派遣スタッフ」の「ステータス」欄および「更新日時」欄が空欄になっていたが、
図5に示したようにリソース「派遣スタッフ」のステータス情報が入力された後は、「派遣スタッフ」の「ステータス」欄には稼働状態が「Yellow」であることを示すマークが記載され、「更新日時」欄には情報の入力操作が行われた日時が記載される。また、リソース情報記憶部150に格納されたリソースの情報(ステータス情報および更新日時の情報)は、例えば、
図3に示したメニュー画面100Aの「通知」ボタンにタッチすることにより、現場用端末装置100の個体識別情報と共に、管理サーバ200へ送信される。これにより、リソースの稼働状態(ステータス)が管理サーバ200へ報告される。
【0042】
図6は、復旧管理画面100Dの構成例を示す図である。
図3に示したメニュー画面100Aで「復旧情報」ボタンにタッチすると、ユーザ・インターフェイス制御部130により、復旧管理画面100Dが呼び出されて、画像表示部110に表示される。図示の復旧管理画面100Dには、「該当ステータス」、「タイトル」、「復旧対象」、「チェックイン」、「終了時刻」の各表示欄が設けられている。この復旧管理画面100Dには、ステータス情報が「Green」に該当するリソース以外のリソースに関する情報が表示される。ステータス情報が「Green」に該当するリソースについては、復旧のための対策を実施する必要がないため、復旧管理画面100Dには表示されない。
【0043】
「該当ステータス」欄には、復旧対象となるリソースのステータス情報(稼働状態)が表示される。
図6に示す例では、ステータス情報が「Yellow」であるリソースと、ステータス情報が「Orange」であるリソースとが各々一つずつ存在し、ステータス情報が「Red」であるリソースが二つ存在することが示されている。また、図示の例では、ステータス情報の区分に基づいて、「Yellow」、「Orange」、「Red」の順に各リソースのエントリーがソートされている。
【0044】
「タイトル」欄には、復旧対象のリソースの名称が表示される。図示の例では、1番のエントリー(ステータス情報「Yellow」)のリソース名「aaaaa」、2番のエントリー(ステータス情報「Orange」)のリソース名「bbbbb」、3番のエントリー(ステータス情報「Red」)のリソース名「ccccc」、4番のエントリー(ステータス情報「Red)のリソース名「ddddd」が、それぞれ表示されている。
【0045】
「復旧対象」欄には、自装置(現場用端末装置100)を使用する現場担当者が復旧を担当する(復旧対象の)リソースか否かを識別するための表示が行われる。図示の例では、1番のエントリー(ステータス情報「Yellow」、リソース名「xxxxx」)における「復旧対象」欄に、復旧対象であることを示す記号「φ」が表示されている。また、その他のエントリーにおける「復旧対象」欄には、復旧対象でないことを示す表示(図では図形□を記載)となっている。
【0046】
「チェックイン」欄には、復旧対策の実施が開始されたリソースに関して、復旧対策を実施したり、指揮したりする主体(担当者)の識別情報(例えば、氏名)が表示される。通常、ステータス情報の入力を行った現場担当者が、該当するリソースの復旧対策の実施や指揮を行うことが多い。しかし、リソースを復旧させるための対策には、専門性を要する作業等が含まれる場合もあるため、ステータス情報の入力を行った現場担当者以外の者がリソースの復旧対策の実施や指揮を行う場合もある。なお、
図6に示す例では、未だ復旧対策が実施されていない状態を示しており、復旧対象である1番のエントリーの「チェックイン」欄は空欄となっている。
【0047】
「終了時刻」欄には、復旧対策の実施が終了した時刻が表示される。復旧対策の実施が開始された後、終了するまでの間は、復旧対策を実施中であることを示す情報(例えば、経過時間や「進行中」の文字メッセージ等)が表示される。なお、
図6に示す例では、未だ復旧対策が実施されていない状態を示しており、復旧対象である1番のエントリーの「終了時刻」欄は空欄となっている。
【0048】
以上のように、本実施形態において、復旧管理画面100Dおよび入力操作部120は、復旧対策の実施状況を表す進捗情報を入力するための進捗情報入力手段として機能する。上記のように構成された復旧管理画面100Dにおいて、復旧対象となっているリソースを選択する操作(例えば、復旧対象のエントリーの適当な欄にタッチする操作等)を行うと、ユーザ・インターフェイス制御部130により、選択されたリソースの現在の稼働状態(ステータス)に対する対策情報確認画面100Eが呼び出され、復旧管理画面100Dに替えて画像表示部110に表示される。
【0049】
図7は、対策情報確認画面100Eの構成例を示す図である。
図7に示す例では、
図6に示した復旧管理画面100Dで選択された1番のエントリーに登録されているリソース「aaaaa」に関する対策情報確認画面100Eが表示されている。すなわち、図示の画面は、リソース「aaaaa」の稼働状態が「Yellow」である場合に対する対策情報確認画面100Eである。図示のように、対策情報確認画面100Eには、実施すべき対策の内容を記載した「説明」と、その対策を実施するのに要すると想定される時間を示す「目標時間」の二つの項目が記載されている。また、復旧対策が実施される状態となることをシステムに入力するための「チェックイン」ボタンが設けられている。
【0050】
対策情報確認画面100Eに表示される「説明」および「目標時間」の内容は、対策情報記憶部160に格納されている。対策情報記憶部160には、管理対象である各リソースに関して、各ステータスに応じた「説明」および「目標時間」の表示内容が格納されている。そして、復旧管理画面100Dで行われたリソースを選択する操作が行われると、ユーザ・インターフェイス制御部130により、選択されたリソースおよびステータスに対応する情報が対策情報記憶部160から読み出されて、対策情報確認画面100Eに表示される。
【0051】
使用者(現場担当者)は、対策情報確認画面100Eの「説明」の記載により、そのリソースがその稼働状態(ステータス)である場合に、リソースの復旧のために何を行えば良いかを知ることができる。また、使用者(現場担当者)は、「目標時間」の記載により、「説明」に記載された対策をいつまでに完了することが望ましいかを知ることができる。なお、この目標時間は、厳守すべき時間ではなく、目標として推奨される時間に過ぎない。対策情報確認画面100Eにおける「説明」に記載される対策の内容および「目標時間」は、リソースおよびその稼働状態(ステータス)別に、予め作成しておく。したがって、同じリソースであっても、稼働状態(ステータス)が異なる場合には、「説明」に記載される対策の内容が異なる場合がある。
【0052】
以上のように、本実施形態において、対策情報確認画面100Eは、各リソースの稼働状態を本来の状態に復帰させるために実施すべき対策を提示する対策提示手段として機能する。
図7に示した対策情報確認画面100Eにおいて、使用者(現場担当者)が「チェックイン」ボタンにタッチ(チェックインの操作)すると、ユーザ・インターフェイス制御部130は、「チェックイン」欄にチェックインを行った担当者の情報(以下、担当者情報)と、復旧対策の実施が開始された日時(チェックインが行われた日時)の情報(以下、開始日時情報)とを、操作対象のリソースに関連付けて、リソース情報記憶部150に格納する。そして、ユーザ・インターフェイス制御部130の制御により、画像表示部110の表示が復旧管理画面100Dに戻る。また、リソース情報記憶部150に格納された復旧対策の実施に関する情報(担当者情報および開始日時情報)は、例えば、
図3に示したメニュー画面100Aの「通知」ボタンにタッチすることにより、管理サーバ200へ送信される。これにより、リソースの復旧対策の実施状況が管理サーバ200へ報告される。なお、「チェックイン」ボタンにタッチされた際に特定される開始日時情報は、例えば、現場用端末装置100の時計機能(図示せず)から取得される。
【0053】
図8は、対策情報確認画面100Eでチェックインの操作が行われた後の復旧管理画面100Dの表示例を示す図である。
図6に示した復旧管理画面100Dと比較すると、
図8に示す例では、「チェックイン」欄に担当者情報であるチェックインを行った担当者の氏名(図示の例では「○○太郎」)が表示されている。また、「終了時刻」欄には、復旧対策を実施中であることを示す情報(図示の例では「進行中」の文字)が表示されている。
【0054】
リソースに対する復旧対策の実施が完了したならば、担当者は、その旨をシステムに登録する。この操作は、例えば、対策情報確認画面100Eを用いて行う。具体的には、
図8に示した状態の復旧管理画面100Dにおいて、まず、復旧対象のリソースを選択する操作を行い、画像表示部110の表示を対策情報確認画面100Eに切り替える。
【0055】
図9は、
図8の状態の復旧管理画面100Dから移行した対策情報確認画面100Eの表示例を示す図である。
図7に示した対策情報確認画面100Eと比較すると、
図9に示す例では、チェックインが行われた日時(復旧対策の実施が開始された日時)を示す「スタート」、復旧対策の実施が完了した日時を示す「終了」、担当者情報を示す「チェックイン」の各項目が設けられている。このうち、既にチェックインが行われているので、「スタート」には、開始日時情報である日時(図示の例では、「2013/4/30 10:35:42」)が表示されており、「チェックイン」には、担当者情報(図示の例では、「○○太郎」)が表示されている。一方、復旧対策の実施が完了した旨の登録はこれから行うので、図示の例では、「終了」には日時が表示されていない。また、
図7に示した対策情報確認画面100Eに表示されていた「チェックイン」ボタンに替えて、復旧対策の実施が完了したことをシステムに入力するための「終了」ボタンが設けられている。
【0056】
図9に示した対策情報確認画面100Eにおいて、使用者(現場担当者)が「終了」ボタンにタッチ(終了報告の操作)すると、ユーザ・インターフェイス制御部130は、復旧対策の実施が終了した日時を示す情報(以下、終了日時情報)を、担当者情報および開始日時情報に関連付けて、リソース情報記憶部150に格納する。そして、ユーザ・インターフェイス制御部130の制御により、画像表示部110の表示が復旧管理画面100Dに戻る。また、リソース情報記憶部150に格納された終了日時情報は、例えば、
図3に示したメニュー画面100Aの「通知」ボタンにタッチすることにより、関連する担当者情報等と共に、管理サーバ200へ送信される。これにより、リソースの復旧対策の実施状況(実施の完了)が管理サーバ200へ報告される。なお、「終了」ボタンにタッチされた際に特定される終了日時情報は、例えば、現場用端末装置100の時計機能(図示せず)から取得される。
【0057】
図10は、対策情報確認画面100Eで終了報告の操作が行われた後の復旧管理画面100Dの表示例を示す図である。
図8に示した復旧管理画面100Dと比較すると、
図10に示す例では、「終了時刻」欄に、
図8で表示されていた「進行中」に替えて、文字終了日時情報である日時(図示の例では、「2013/4/30 11:55:34」)が表示されている。
【0058】
なお、上記の例では、復旧管理画面100Dにおいて、入力操作部120を操作してステータス情報が入力されたリソースに関して、「復旧対象」欄に復旧対象であることを示す表示を行った。これは、あるリソースに関して、現場担当者が自身の現場用端末装置100を用いてステータス情報を入力した場合、その現場担当者は、そのリソースに関する復旧対策を実施したり、指揮したりする立場である可能性が高いことに鑑みたものである。一方、リソースを復旧させるための対策には、専門性を要する作業が含まれる場合等もあるため、現場担当者自身がリソースの復旧対策の実施や指揮を行わない場合もあり得る。また反対に、現場担当者が、自身がステータス情報を入力したリソースとは異なるリソースの復旧対策の実施や指揮を行うことも考えられる。そこで、復旧管理画面100Dにおいて、復旧対象のリソースを任意に選択して入力できるように構成しても良い。さらに、担当者情報についても、チェックインを行った担当者以外の復旧対策の作業者等の情報を入力可能な構成としても良い。
【0059】
<管理サーバの機能構成>
図11は、管理サーバ200の機能構成例を示す図である。
図11に示すように、本実施形態の管理サーバ200は、対策情報格納部210と、通信制御部220と、稼働情報管理部230とを備える。
【0060】
対策情報格納部210は、管理対象である各業務に関して、個々の業務を稼働させるために必要不可欠なリソースの稼働状態(ステータス)の定義情報および稼働状態に応じて設定された実施すべき対策の情報を保持する。また、各対策を実施する場合に、完了するまでに要すると予想される時間を目標時間(
図7参照)として保持する。この対策情報格納部210は、メモリや磁気ディスク装置等による不揮発性の記憶手段により実現される。上述した現場用端末装置100の対策情報記憶部160には、少なくとも、自装置の使用者である現場担当者が担当すべきリソース(またはそのリソースと同じ業務に属す各リソース)に関する情報が記憶されていれば良い。これに対し、管理サーバ200の対策情報格納部210は、本実施形態の業務復旧支援システムの管理対象となっている全ての業務について、それらの業務を稼働させるために必要不可欠な各リソースの稼働状態に関する情報を保持する必要がある。現場用端末装置100の対策情報記憶部160に記憶される情報は、管理サーバ200の対策情報格納部210に格納されている情報の一部を抽出して提供するようにしても良い。
【0061】
通信制御部220は、ネットワーク400を介して現場用端末装置100と接続し、データ交換を行う。具体的には、各現場用端末装置100から送信されたリソースの稼働状態の情報を受信する。また、各現場用端末装置100から受信したリソースの稼働状態の情報を、その情報を送信した現場用端末装置100以外の現場用端末装置100に配信する。また、特に図示しないが、通信制御部220は、管理用端末装置300と接続してデータ交換を行う。管理サーバ200は、この通信制御部220により現場用端末装置100や管理用端末装置300と情報の送受信を行うためのネットワーク・インターフェイスを備える。
【0062】
稼働情報管理部230は、通信制御部220により現場用端末装置100から受信したリソースの情報を、業務およびリソースごとに分類して、磁気ディスク装置等の記憶手段に保持する。具体的には、現場用端末装置100から情報を受信したリソースごとに、情報を入力(送信)した現場用端末装置100の個体識別情報、ステータス情報、更新日時の情報、担当者情報、開始日時情報および終了日時情報などを、現場用端末装置100から取得して、記憶手段に格納する。
【0063】
<管理用端末装置の機能構成>
図12は、管理用端末装置300の機能構成例を示す図である。
図12に示すように、本実施形態の管理用端末装置300は、画像表示部310と、入力操作部320と、稼働情報取得部330と、稼働情報編集出力部340とを備える。
【0064】
画像表示部310は、例えば液晶ディスプレイ等のディスプレイ装置により実現され、各種の画面を表示する。本実施形態では、各業務におけるリソースや業務自体の稼働状態を確認するための画面や、業務の復旧の進捗状況を確認するための画面が表示される。
【0065】
入力操作部320は、使用者(管理者)が制御コマンド等の入力操作を行うための入力デバイスである。具体的には、マウス等のポインティング・デバイスやキーボード等が用いられる。使用者(管理者)は入力操作部320を操作して、管理サーバ200から必要な情報を取得し、編集して画像表示部310に表示させることができる。
【0066】
稼働情報取得部330は、入力操作部320の操作により入力された制御コマンドにしたがって、管理サーバ200から管理対象のリソースに関する情報を取得する。具体的には、管理サーバ200の稼働情報管理部230により管理されている各リソースについての、ステータス情報、更新日時の情報、担当者情報、開始日時情報および終了日時情報を取得する。また、必要に応じて、対策情報格納部210に格納されている復旧対策の情報も取得する。また、特に図示しないが、管理用端末装置300は、この稼働情報取得部330により管理サーバ200から情報を取得するためのインターフェイスを備える。
【0067】
稼働情報編集出力部340は、稼働情報取得部330により取得したリソースの情報に基づき、各リソースの稼働状態の管理画面や、業務の復旧状況の管理画面を生成し、画像表示部310に表示させる。各画面の詳細については後述する。
【0068】
<管理サーバおよび管理用端末装置による業務単位でのリソース管理>
次に、管理サーバ200および管理用端末装置300によるリソース管理の例について説明する。
本実施形態では、リソース管理のために、ダッシュボード画面300A、稼働状態提示画面300B、復旧状況確認画面300C、チェックイン確認画面300Dの4種類の画面を用意する。これらの画面は、管理サーバ200から取得した情報に基づいて、管理用端末装置300の稼働情報編集出力部340が生成し、画像表示部310に表示させる。
【0069】
図13は、ダッシュボード画面300Aの構成例を示す図である。
ダッシュボード画面300Aは、管理対象の業務全体の稼働状態を把握するための画面である。
図13に示す例では、業務全体(図では「全社」と記載)を対象とする情報として、稼働状態(ステータス)と、チェックイン数(復旧対策の実施にかかっている人数)とが表示されている。また、業務別の情報として、稼働状態(ステータス)と、業務に属す各リソースの稼働状態(ステータス)と、復旧対策として実施される作業手順のうち完了した作業の数(完了作業数)と、復旧対策としての全ての作業を完了するまでの目標日時と、チェックイン数とが表示されている。図示の例において、各リソースのステータスは、表示されたリソース名を囲む枠内をステータスの種類に合わせた色(緑色、黄色、橙色、赤色のいずれか)で塗りつぶすことで表現されている。
【0070】
図示の例では、管理対象の個々の業務として、「物流」、「工場」、「品質」の3種類が記載されているが、これらは例示に過ぎない。管理対象の全ての業務をダッシュボード画面300A上に一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各業務を表示できるようにする。また、各業務に属すリソースは3種類ずつ(図示の例では、いずれも「スタッフ」、「オフィス」、「ITサーバ」)が記載されているが、これも例示に過ぎない。各事業における全てのリソースをダッシュボード画面300A上に一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各リソースを表示できるようにする。
【0071】
本実施形態において、業務全体のステータスおよび業務ごとの「ステータス」は、
図4を参照して説明したリソースのステータスと同様に、「Green」、「Yellow」、「Orange」、「Red」の4段階で示される。業務ごとのステータスは、その業務に属すリソースのステータスに基づいて決定され、業務全体のステータスは、業務ごとのステータスに基づいて決定される。具体的には、各業務のステータスは、その業務に属すリソースのステータスのうちで、最下位のステータスとなる。これは、業務の稼働状態は、その業務を遂行するために不可欠な個々のリソースの稼働状態よりも高い状態にはなり得ないからである。
図13に示す例では、業務「物流」には、「スタッフ」、「オフィス」、「ITサーバ」の3種類のリソースが示されており、各リソースのステータスは、「スタッフ」および「ITサーバ」が「Green」であり、「オフィス」が「Yellow」である。したがって、業務「物流」のステータスは、リソースのステータスのうちで最下位のステータスである「Yellow」となっている。同様に、業務「工場」では、リソースのステータスのうちで最下位のステータスである「Orange」となっている。また、業務「品質」では、全てのリソースのステータスが「Green」であるので、業務「品質」のステータスも「Green」となっている。
【0072】
また、業務全体のステータスは、各業務のステータスのうちで、最下位のステータスとなる。これは、業務全体の稼働状態は、個々の業務の稼働状態よりも高い状態にはなり得ないからである。
図13に示す例では、上記のように、業務「物流」のステータスが「Yellow」、業務「工場」のステータスが「Orange」、業務「品質」のステータスが「Green」であるので、業務全体のステータスは、これらのうちで最下位のステータスである「Orange」となっている。
【0073】
図13に示すダッシュボード画面300Aにおいて、「チェックイン」は、「実際にチェックインしている人数/チェックイン可能な人数」で表される。ここで、
図13を参照すると、業務「物流」では、チェックイン可能な3人のうち、3人がチェックインしていることがわかる。同様に、業務「工場」では、チェックイン可能な10人のうち、9人がチェックインしており、業務「品質」では、チェックイン可能な3人のうち、3人がチェックインしていることがわかる。そして、業務全体では、チェックイン可能な12人のうち、10人がチェックインしていることがわかる。ここで、各業務のチェックイン可能な人数の総数が16人(=3人+10人+3人)であり、業務ごとのチェックインしている人数の総数が15人(=3人+9人+3人)であり、業務全体のチェックイン数とは値が異なっている。これは、各業務におけるチェックイン可能な担当者が部分的に重複していることを意味している。例えば、業務「工場」と業務「品質」の両方でチェックイン可能な担当者が両方の業務に関してチェックインしているような場合である。
【0074】
図13に示すダッシュボード画面300Aにおいて、「完了作業数」は、業務のステータスを現在の状態から「Green」に復帰させるまでに実施すべき作業の数および進捗状況を示す。
図13に示す例では、「すでに実施した作業の数/実施すべき全作業数」で表されている。例えば、業務「物流」は、ステータス「Yellow」からステータス「Green」に復帰させるために実施すべき全作業の数が「5」であり、そのうち三つの作業が完了していることがわかる。
【0075】
図13に示すダッシュボード画面300Aにおいて、「目標日時」は、業務のステータスを「Green」に復帰させる目標の日時を示す。この日時は、例えば、業務に属す各リソースの開始日時情報と、リソースおよびそのステータス情報に基づいて特定される目標時間の情報とに基づいて算出される。一例として具体的には、業務に属す各リソースの開始日時情報のうちで最も早い日時を基準とし、各リソースの目標時間の総和に相当する時間が経過した日時を目標日時とすることができる。
【0076】
図14は、稼働状態提示画面300Bの構成例を示す図である。
図14に示す例では、稼働状態提示画面300Bに、業務「物流」に関してリソースの稼働状態に関する情報が表示されている。画面には、業務「物流」を遂行するために不可欠な「リソース」が並べて記載され、各「リソース」に関して、「ステータス」、「報告者」、「報告日時」の表示欄が設けられている。
【0077】
稼働状態提示画面300Bに記載される「リソース」は、業務において利用されるリソースのうち、そのリソースが稼働していないとその業務を遂行することができないような、不可欠なリソースである。すなわち、
図4を参照して説明したリソース状態確認画面100Bで表示される「リソース」と同様である。ただし、管理用端末装置300の画像表示部310と現場用端末装置100の画像表示部110の画面のサイズの差異のために、一度に表示される「リソース」の数は異なっている。また、
図13に示したダッシュボード画面300Aの業務別の情報には、
図14に示す「リソース」の一部が表示された状態となっている。稼働状態提示画面300Bにおいても業務の遂行に不可欠なリソースの全てを一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各リソースを表示できるようにすることができる。
【0078】
また、稼働状態提示画面300Bに記載される「ステータス」は、
図4を参照して説明したリソースのステータスと同様に、「Green」、「Yellow」、「Orange」、「Red」の4段階で示される。このステータスの情報は、現場用端末装置100において入力され、管理サーバ200により収集された、各リソースのステータス情報に基づいている。
図13に示したダッシュボード画面300Aにおける各リソースのステータスには、この稼働状態提示画面300Bで表示される「ステータス」が反映されている。具体的には、
図14に示す例では、リソース「オフィス」のステータスが「Yellow」、その他のリソースのステータスが全て「Green」となっており、
図13に示す例においても、業務「物流」におけるリソース「スタッフ」、「オフィス」、「ITサーバ」のステータスの表示と一致している。
【0079】
また、稼働状態提示画面300Bに記載される「報告者」は、該当するリソースのステータス情報を入力した現場用端末装置100の使用者(現場担当者)を示す。この表示内容は、現場用端末装置100において入力され、管理サーバ200により収集された、各リソースのステータス情報を入力した現場用端末装置100の個体識別情報に基づいている。なお、
図14に示す例では、リソース「社員」の報告者が「安否確認システム」となっている。これは、例えば、管理サーバ200に設けられた機能(「安否確認システム」)によりステータス情報が入力されたことを示す。このリソース「社員」のステータスは、例えば、上記の担当者情報等に基づき、チェックイン可能な人数の総数と実際にチェックインしている人数との割合や、特定の担当者がチェックインしているか否か等に基づいて特定される。
【0080】
また、稼働状態提示画面300Bに記載される「報告日時」は、該当するリソースのステータス情報が入力された日時を示す。この表示内容は、現場用端末装置100において入力され、管理サーバ200により収集された、各リソースにおけるステータス情報の更新日時の情報に基づいている。
【0081】
図15は、復旧状況確認画面300Cの構成例を示す図である。
図15に示す例では、復旧状況確認画面300Cに、業務「物流」のリソース「オフィス」に関して稼働状態の復旧状況を示す情報が表示されている。画面には、業務「物流」のリソース「オフィス」のステータスごとに、「対策」、「チェックイン」、「目標日時」、「完了日時」、「遅延」の各項目が表示されている。また、この復旧状況確認画面300Cには、「Green」以外のステータスに関する情報が表示される。ステータスが「Green」である場合は、復旧のための対策を実施する必要がないためである。
【0082】
図15に示す復旧状況確認画面300Cでは、ステータス「Yellow」のエントリーが2個、ステータス「Orange」のエントリーが2個、ステータス「Red」のエントリーが2個、それぞれ表示されている。したがって、ステータスが「Yellow」のときに実施すべき対策が二つあることがわかる。この二つの対策が完了すると、リソース「オフィス」の稼働状態は「Yellow」に該当する状態から「Green」に該当する状態へ復帰する。
【0083】
同様に、ステータスが「Orange」のときに実施すべき対策は二つである。この二つの対策が完了すると、リソース「オフィス」の稼働状態は「Orange」に該当する状態から「Green」に該当する状態へ復帰する。
【0084】
同様に、ステータスが「Red」のときに実施すべき対策は二つである。この二つの対策が完了すると、リソース「オフィス」の稼働状態は「Red」に該当する状態から「Green」に該当する状態へ復帰する。
【0085】
図15に示す復旧状況確認画面300Cの「対策」には、該当する各ステータスのときに実施すべき対策の内容が表示される。この情報は、管理サーバ200の対策情報格納部210から取得される。また、対策の内容は、該当するリソースおよびステータスに関する、
図7に示した対策情報確認画面100Eの「説明」欄の記載内容と同様である。
【0086】
図15に示す復旧状況確認画面300Cの「チェックイン」には、該当する対策を実施するためにチェックインを行った担当者の氏名が表示される。この情報は、現場用端末装置100において入力され、管理サーバ200により収集された、担当者情報(
図8参照)に基づいている。なお、図示の例において、チェックインが行われていない2番のエントリーには、「未」の文字が表示されている。
【0087】
図15に示す復旧状況確認画面300Cの「目標日時」には、該当する対策の実施を完了する目標となる日時が表示される。この情報は、現場用端末装置100において入力され、管理サーバ200により収集された開始日時情報と、管理サーバ200の対策情報格納部210に保持されている該当作業の目標時間の情報とに基づいて算出される。なお、図示の例において、チェックインが行われていない2番のエントリーには、開始日時情報が存在しないため、目標時間の値(「1時間」)がそのまま表示されている。
【0088】
図15に示す復旧状況確認画面300Cの「完了日時」には、該当する対策の実施が実際に完了した日時が表示される。この情報は、現場用端末装置100において入力され、管理サーバ200により収集された終了日時情報に基づいている。なお、図示の例において、対策の実施が開始されているが、完了していない場合は「進行中」、対策の実施が開始されていない場合は「未着手」の文字が、それぞれ表示されている。また、復旧状況確認画面300Cの「遅延」には、対策の実施の完了前に「目標日時」に表示された日時を経過してしまった場合に、「目標日時」以降の経過時間が表示される。
【0089】
以上により、
図15に示す復旧状況確認画面300Cによれば、1番のエントリー(ステータス「Yellow」)の対策は、担当者「○○太郎」によりチェックインされており、目標日時が「2013/4/30 10:00」であり、対策の実施が完了していないが、遅延は発生していない、ということがわかる。同様に、2番のエントリー(ステータス「Yellow」)の対策は、チェックインが行われておらず、対策の実施が未だ開始されていないこと、対策を実施するには1時間を要すること、がわかる。
【0090】
図16は、チェックイン確認画面300Dの構成例を示す図である。
チェックイン確認画面300Dは、業務単位でのチェックインの状況を管理するための画面である。
図16に示す例では、業務ごとにチェックインの状況を示す情報(「チェックイン数」、「総数」、「チェックイン率」)が表示されている。また、個々の業務に関して、チェックインした担当者の情報(「氏名」、「チェックイン日時」、「チェックアウト日時」)が表示される。なお、担当者の情報については、
図16に示す例では、業務「物流」の担当者の情報のみが表示されている。これらの情報の全てをチェックイン画面上に一度に表示できない場合は、例えば、所定の操作により個々の業務における担当者の情報の表示を切り替えたり、スクロール等で画面の表示範囲を移動させたりする機能を設けて、各情報を表示できるようにする。
【0091】
<対策情報の具体例>
ここで、管理サーバ200の対策情報格納部210に格納される情報(以下、対策情報)について、具体例を挙げて、さらに詳細に説明する。ここでは、対象業務の一例として、お客様窓口の業務を考える。
【0092】
図17は、お客様窓口業務に関する対策情報の例を示す図である。
図17に示す例では、お客様窓口業務を遂行するために不可欠なリソースとして、「本社オペレータ」、「本社オフィス」、「地方オフィス」、「提携先オフィス」、「電話・PC」、「イントラ、データベースシステム」、「本社・基盤設備」の7種類のリソースが設定されている。すなわち、これら7種類のリソースの全てが稼働している場合(「Red」以外のステータスである場合)に、お客様窓口業務が稼働している状態となる。なお、図示の例では、「本社オフィス」、「地方オフィス」、「提携先オフィス」の三つのリソースを「オフィス」という分類にまとめ、全体を「スタッフ」、「オフィス」、「設備」、「システム」、「インフラ」の5種類に分類している。
【0093】
各リソースには、「Green」、「Yellow」、「Orange」、「Red」の4段階のステータスが設定されている。例えば、
図17の例におけるリソース「本社オペレータ」について参照すると、オペレータが平時の出社率である場合に、ステータスは「Green」である。また、出社率が平時よりも少ないが、出社可能人数が回線数+4以上である場合に、ステータスは「Yellow」である。また、出社可能人数が回線数+4よりも少ないが、回線数以上である場合には、ステータスは「Orange」である。また、出社可能人数が回線数よりも少ない場合は、ステータスは「Red」である。
【0094】
また、リソース「本社オペレータ」の稼働が低下した場合の対策として、ステータスが「Yellow」である場合、「Orange」である場合および「Red」である場合について、それぞれ設定される。なお、ステータスが「Green」である場合は、通常業務が行われるため、地方オペレータによる業務支援は行われない。
【0095】
図18は、リソース「本社オペレータ」の稼働低下時の対策として設定された、地方オペレータによる業務支援の具体的な内容の例を示す図である。
図18に示す例では、ステータスが「Yellow」の場合に実施すべき対策として、三つの作業(アクション)が設定されている。各作業に対しては、目標時間(アクションごとの目標時間)としてそれぞれ「1時間」が設定されている。したがって、ステータスが「Yellow」の場合に実施すべき対策を全て実施するための目標時間(トータルの目標時間)は「3時間」となっている。同様に、ステータスが「Orange」の場合に実施すべき対策として、二つの作業(アクション)が設定されており、アクションごとの目標時間としてそれぞれ「1時間」が設定され、トータルの目標時間が「2時間」となっている。また、ステータスが「Red」の場合に実施すべき対策として、二つの作業(アクション)が設定されており、アクションごとの目標時間としてそれぞれ「1時間」が設定され、トータルの目標時間が「2時間」となっている。
【0096】
また、特に図示しないが、本実施形態では、
図17に示した各リソースにおけるステータスごとの対策に関して、
図18に示すように具体的な作業が設定される。したがって、個々のリソースに関して、
図17に示した基準に則ってステータスが特定されれば、本来の稼働状態(「Green」)のリソース以外のリソースに関し、ステータスを「Green」にするために実施すべき対策が確定する。
【0097】
<管理サーバおよび管理用端末装置による業務管理>
次に、管理サーバ200および管理用端末装置300による業務管理の例について説明する。
本実施形態では、上記のようにして収集され、管理される業務ごとのリソースの稼働状態に関する情報に基づき、1または複数の組織(企業等)による複数の業務の稼働状態を管理することができる。本実施形態では、業務管理のために、稼働レベル管理画面300Eを用意する。これらの画面は、管理サーバ200から取得した情報に基づいて、管理用端末装置300の稼働情報編集出力部340が生成し、画像表示部310に表示させる。
【0098】
図19〜
図25は、稼働レベル管理画面300Eの構成例を示す図である。
稼働レベル管理画面300Eは、管理対象の複数の業務における管理対象の全てのリソースの稼働状態を提示すると共に、このリソースの稼働状態に基づいて判断される業務自体の稼働状態を提示する画面である。また、この稼働レベル管理画面300Eは、各リソースおよび業務の稼働状態に基づいて、現在稼働していないリソースや業務の復旧(稼働再開)時刻の予測(復旧予測)結果を提示する。本実施形態では、管理対象の業務を遂行するために必要なリソースが管理対象のリソースとして設定されるため、リソースの稼働状態の情報を収集することにより、そのリソースを含む業務の稼働状態を把握することができる。したがって、リソースの復旧予測に基づき、そのリソースが含まれる業務の復旧予測を行うことが可能となる。
図19〜
図25に示す例において、稼働レベル管理画面300Eには、管理対象である業務およびリソースを一覧する管理項目欄301と、業務およびリソースの復旧予測結果を表示する稼働状態グラフ302とが表示されている。
【0099】
図19〜
図25に示す例において、管理項目欄301に表示される「業務」および「リソース」の各項目の表示には、各々のステータスが反映される。ここでは、「リソース」の各項目は、まず、ステータス(「Green」、「Yellow」、「Orange」、「Red」)ごとにソートされ、各ステータスにおいて、さらに「業務」ごとにソートされる。具体的には、各リソースは、ステータスが「Red」のリソース、「Orange」のリソース、「Yellow」のリソース、「Green」のリソースの順に上から並べられる。また、「業務」の各項目は、その業務に属す全てのリソースのステータスのうちで最下位のステータスが反映される。したがって、例えば、ある業務についてステータスが「Red」のリソースが一つでも存在するときは、その「業務」の項目全体が「Red」となる。
【0100】
また、
図19〜
図25に示す例において、稼働状態グラフ302には、縦軸を管理項目欄301に表示した「リソース」の数、横軸を時間として、現在時点で確認されているステータスごとのリソースの数を示すと共に、時間経過に伴って各リソースのステータスが変化する様子(予測結果)を示すグラフが表示される。図示の例では、横軸方向の1単位を1時間として、現在の3時間前から16時間後までの各リソースにおけるステータスの様子とが表示される。以下、障害の発生およびその後の時間経過に伴う稼働レベル管理画面300Eの表示の変化の具体例を、
図19〜
図25を参照して説明する。
【0101】
図19は、障害の発生前における稼働レベル管理画面300Eの状態を例示する図である。
図19に示す例において、管理項目欄301の「業務」には、上から順に、「業務コミュニケーション」、「業務アプリケーション」、「業務支払」、「業務お客様窓口」、「業務品質管理」、「業務物流」の6種の業務が表示されている。また、「リソース」には、各業務に対応付けて、管理対象(すなわち、各業務を遂行するために不可欠なものとして設定されたリソース)として、41個(業務ごとに6個から8個)のリソースが表示されている。
【0102】
管理項目欄301における各業務およびリソースの配置(順番)は、平常時においては特に限定されないが、例えば
図19に示すように、業務ごとにリソースを並べることで、視認性を高めることができる。また、障害発生後は、後述するように、各リソースを「Green」、「Yellow」、「Orange」、「Red」のステータスの順に下から上へ積み上がるように並べる。さらに、ステータスが「Orange」のリソースおよび「Red」のリソースにおいては、平常時の稼働状態(ステータス「Yellow」以上)に復帰すると予想される時間(以下、復旧予定時間)の長いものが上に位置するように配置される。これにより、復旧したリソースや稼働していないリソースの数の認識が容易となり、復旧の度合いを直感的に把握し易くなる。
【0103】
図19に示す稼働レベル管理画面300Eは、障害の発生前の状態であるので、表示される各業務および各リソースのステータスは、全て「Green」となっている。稼働状態グラフ302においては、3時間前から現在までの全リソースのステータスが「Green」であるだけでなく、障害発生前であるので、予測としての将来のステータス(稼働状態グラフ302において、「現在」の時点よりも右側の領域)においても「Green」となっている。
【0104】
図20は、障害発生時の稼働レベル管理画面300Eの状態を例示する図である。
リソースや業務の正常な稼働が妨げられるような障害が発生すると、各リソースの稼働状態を確認し、稼働レベルが低下したリソースを復旧させることが必要となる。本実施形態では、予め設定された事象(例えば、所定の規模以上の自然災害や事故等)が発生した場合に、これを契機として、現場用端末装置100を用いたリソースに関する情報の収集を実行する。このとき、管理用端末装置300に表示される稼働レベル管理画面300Eは、一度、全ての情報が未入力の状態となる。図示の例では、管理項目欄301の全ての「業務」および「リソース」が、通常時とは異なる表示態様で表示され、情報が未入力であることを示している。また、稼働状態グラフ302においても、全ての時間、全てのリソースにおいて、情報が未入力(「情報なし」)であることを示す表示となっている。
【0105】
さらに、リソースの情報の収集を開始すると、稼働状態グラフ302には、リソースおよび業務の復旧時の予測結果を示す復旧予測ラインが表示される。ここで、リソースに関しては、平常時の稼働状態にまで稼働レベルを戻すことを目標とするので、ステータスが「Yellow」以上となる位置にリソースの復旧予測ラインが設定される。一方、業務に関しては、例えいくつかのリソースにおいて稼働レベルが低下していても、その業務に属す全てのリソースが稼働している状態となれば、業務自体の稼働は再開される。したがって、ステータスが「Orange」以上となる位置に業務の復旧予測ラインが設定される。本実施形態では、業務の復旧予測ラインを破線で示し、リソースの復旧予測ラインを色の薄い実線で示すこととする。
図20の例では、未だ全てのリソースに関して、稼働状況の情報が取得されていないので、リソースの復旧予測ラインは表示されておらず、業務の復旧予測ライン303のみが表示されている。また、
図20において、業務の復旧予測ライン303は、現在(0h)以降の全ての時点で復旧業務「0」に設定されている。
【0106】
図21は、障害発生から15分経過後の稼働レベル管理画面300Eの状態を例示する図である。
この時点までに、業務「業務アプリケーション」と業務「業務コミュニケーション」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄301を参照すると、業務「業務アプリケーション」に関しては、リソース「電気」、「本社オフィス」、「アプリ担当社員」が平常時通り稼働しており(ステータス「Green」)、リソース「PC」は稼働レベルが低下しているが稼働している状態であり(ステータス「Orange」)、リソース「アプリサーバ」、「公衆通信回線」は稼働していない状態である(ステータス「Red」)。そして、リソース「社員自宅」については、未だ情報が取得されていない。また、業務「業務コミュニケーション」に関しては、リソース「電気」、「本社オフィス」、「イントラ担当社員」、「PC」が平常時通り稼働しており(ステータス「Green」)、リソース「イントラネット」、「サポート担当社員」は稼働していない状態である(ステータス「Red」)。そして、リソース「社員自宅」については、未だ情報が取得されていない。いずれの業務も、ステータスが「Red」のリソースが存在するので、業務自体のステータスは「Red」となっている。
【0107】
なお、リソース「社員自宅」は、リソース「本社オフィス」と補完関係にあり、いずれか一方が稼働していれば、業務の稼働を保証する。したがって、ここでは、業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも、リソース「本社オフィス」が平常時通り稼働しているので(ステータス「Green」)、業務が稼働を再開するために、リソース「社員自宅」が稼働することは必要としない。
【0108】
次に、稼働状態グラフ302を参照すると、まず、事象の発生時である現在(0h)以前の3時間については、事象発生前のステータス(「Green」)に戻されている。そして、現在(0h)の表示は、管理項目欄301の「リソース」の表示が反映され、7個のリソースが「Green」、1個のリソースが「Orange」、4個のリソースが「Red」となっている。
【0109】
また、現在(0h)以降の表示については、報告のあった12個のリソースに関して、ステータスが段階的に復旧する様子(予測結果)が示されている。そして、この予測に基づいて、業務の復旧予測ライン303と、リソースの復旧予測ライン304とが表示されている。
【0110】
現場用端末装置100の説明等において既に述べたように、個々のリソースについてステータスが特定されれば、そのリソースを復旧させるために実施すべき対策は特定される。そして、現場用端末装置100の対策情報確認画面100E(
図7、
図9参照)における「目標時間」、管理用端末装置300のダッシュボード画面300A(
図13参照)や復旧状況確認画面300C(
図15参照)における「目標日時」に示したように、実施すべき対策が特定されると、その実施に要する時間が決まる。そして、これらの情報に基づき、各リソースについて、復旧予定時間が算出される。
【0111】
ここでは、ステータスが「Orange」である業務「業務アプリケーション」のリソース「PC」の復旧予定時間は、現在(0h)から4時間後であるものとする。このため、
図21に示す稼働状態グラフ302における4hの位置で、1個のリソースのステータスが「Orange」から「Green」に変化している。一方、ステータスが「Red」である4個のリソースの復旧予定時間は、全て現在(0h)から6時間後であるものとする。このため、
図21に示す稼働状態グラフ302における6hの位置で、4個のリソースのステータスが「Red」から「Green」に変化している。そして、各リソースのステータスが「Green」に移行する位置に沿って、リソースの復旧予測ライン304が表示されている。
【0112】
業務に関しては、業務に属すリソースの一つでも稼働していない(ステータスが「Red」)ときは、その業務は稼働しないが、業務に属す全てのリソースが稼働状態となれば、業務自体の稼働も再開されるので、現在(0h)から6時間後には、今回報告された業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも復旧する。なお、上述したように、これらの業務が稼働するためには、リソース「社員自宅」の稼働は必要ない。したがって、業務の復旧予測ライン303は、6hの位置まで復旧業務「0」に設定されており、6h以降は、各業務に属すリソースの数「14」に設定されている。なお、上述したように、これらの業務が稼働するためには、リソース「社員自宅」の稼働は必要ない。したがって、業務の復旧予測ライン303は、情報が取得されているリソースの数「12」ではなく、業務に属す全てのリソースの数「14」に設定される。
【0113】
図22は、障害発生から30分経過後の稼働レベル管理画面300Eの状態を例示する図である。
この時点までに、業務「業務お客様窓口」と業務「業務支払」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄301を参照すると、業務「業務お客様窓口」に関しては、リソース「業務サーバ」、「外部委託業者」、「電話」、「本社オフィス」、「コール・システム」が平常時通り稼働しており(ステータス「Green」)、リソース「オペレータ」は稼働レベルが低下しているが稼働している状態である(ステータス「Orange」)。このように、業務「業務お客様窓口」は、1個のリソースのステータスが「Orange」であり、その他の全てのリソースのステータスが「Green」であるので、業務自体のステータスも「Orange」となる。すなわち、業務自体が稼働している状態である。
【0114】
また、業務「業務支払」に関しては、リソース「電気通信回線」、「本社オフィス」、「工場社員」、「工場オフィス」、「銀行印」、「決済システム」が平常時通り稼働しており(ステータス「Green」)、リソース「PC」は稼働レベルが低下しているが稼働している状態であり(ステータス「Orange」)、リソース「決裁権限者」は稼働していない状態である(ステータス「Red」)。そして、ステータスが「Red」のリソースが存在するので、業務自体のステータスは「Red」となっている。
【0115】
また、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソース「社員自宅」に関しては、
図22に示す時点までにステータスの報告があり、受け付けた報告に基づいてステータス「Green」に切り替わったものとする。
【0116】
また、管理項目欄301において、ステータスが「Orange」である3個のリソースの位置を比較すると、稼働状態グラフ302を参照して後述するように復旧予定時間の長い業務「業務お客様窓口」のリソース「オペレータ」が、他の2個のリソースよりも上に配置されている。同様に、ステータスが「Red」である5個のリソースの位置を比較すると、稼働状態グラフ302を参照して後述するように復旧予定時間の長い業務「業務支払」のリソース「決裁権限者」が、他の4個のリソースよりも上に配置されている。
【0117】
次に、稼働状態グラフ302を参照すると、現在(0h)の表示は、管理項目欄301の「リソース」の表示が反映され、20個のリソースが「Green」、3個のリソースが「Orange」、5個のリソースが「Red」となっている。
【0118】
また、現在(0h)以降の表示については、報告のあった28個のリソース(業務「業務アプリケーション」および業務「業務コミュニケーション」のリソース「社員自宅」を含む)に関して、ステータスが段階的に復旧する様子(予測結果)が示されている。そして、この予測に基づいて、業務の復旧予測ライン303と、リソースの復旧予測ライン304とが表示されている。
【0119】
ここでは、ステータスが「Orange」である業務「業務支払」のリソース「PC」の復旧予定時間は、現在(0h)から4時間後であるものとする。また、ステータスが「Orange」である業務「業務お客様窓口」のリソース「オペレータ」の復旧予定時間は、現在(0h)から6時間後であるものとする。また、業務「業務アプリケーション」のリソース「PC」の復旧予定時間は、
図21にも示したように、現在(0h)から4時間後である。このため、
図22に示す稼働状態グラフ302における4hの位置で、2個のリソースのステータスが「Orange」から「Green」に変化している。また、6hの位置で、1個のリソースのステータスが「Orange」から「Green」に変化している。
【0120】
一方、ステータスが「Red」であるリソースのうち、業務「業務アプリケーション」および業務「業務コミュニケーション」における4個のリソースの復旧予定時間は、現在(0h)から6時間後であるが、業務「業務支払」のリソース「決裁権限者」は、グラフに表示される16時間以内には復旧しない。このため、
図22に示す稼働状態グラフ302における6hの位置で、4個のリソースのステータスが「Red」から「Green」に変化している。そして、各リソースのステータスが「Green」に移行する位置に沿って、リソースの復旧予測ライン304が表示されている。
【0121】
業務に関しては、今回報告された業務「業務お客様窓口」は、全てのリソースのステータスが「Orange」以上なので、業務自体が稼働している。そして、現在(0h)から6時間後には、業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも復旧する。これに対し、業務「業務支払」は、リソース「決裁権限者」がグラフに表示される16時間以内に復旧しないため、業務自体も16時間以内には稼働しない。したがって、業務の復旧予測ライン303は、6hの位置までは業務「業務お客様窓口」のリソースの数である「6」に設定されており、6h以降は、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソースの総数を加えた「20」に設定されている。
【0122】
図23は、障害発生から90分経過後の稼働レベル管理画面300Eの状態を例示する図である。
この時点までに、業務「業務品質管理」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄301を参照すると、業務「業務品質管理」に関しては、リソース「電気」、「本社オフィス」、「社員」、「社員自宅」、「データベース」が平常時通り稼働しており(ステータス「Green」)、リソース「業務機器」は稼働レベルが低下しているが稼働している状態である(ステータス「Orange」)。このように、業務「業務品質管理」は、1個のリソースのステータスが「Orange」であり、その他の全てのリソースのステータスが「Green」であるので、業務自体のステータスも「Orange」となる。すなわち、業務自体が稼働している状態である。
【0123】
また、管理項目欄301において、ステータスが「Orange」である4個のリソースの位置を比較すると、稼働状態グラフ302を参照して後述するように復旧予定時間の長い業務「業務お客様窓口」のリソース「オペレータ」および業務「業務品質管理」のリソース「業務機器」が、他の2個のリソースよりも上に配置されている。ステータスが「Red」である5個のリソースの位置については、
図22の例と同様に、業務「業務支払」のリソース「決裁権限者」が、他の4個のリソースよりも上に配置されている。
【0124】
次に、稼働状態グラフ302を参照すると、
図23では、障害発生から90分(1時間以上)が経過しているので、グラフの表示が1単位分進んでいる(図において、左へ移動している)。すなわち、
図23の稼働状態グラフ302における現在(0h)は、障害発生から1時間経過後である。この現在(0h)の表示は、管理項目欄301の「リソース」の表示が反映され、25個のリソースが「Green」、4個のリソースが「Orange」、5個のリソースが「Red」となっている。
【0125】
また、現在(0h)以降の表示については、報告のあった34個のリソースに関して、ステータスが段階的に復旧する様子(予測結果)が示されている。そして、この予測に基づいて、業務の復旧予測ライン303と、リソースの復旧予測ライン304とが表示されている。
【0126】
ここでは、ステータスが「Orange」である業務「業務品質管理」のリソース「業務機器」の復旧予定時間は、障害発生から6時間後であるものとする。したがって、障害発生から1時間以上が経過している
図23においては、現在(0h)から5時間後である。同様に、業務「業務お客様窓口」のリソース「オペレータ」の復旧予定時間は、障害発生から6時間後であるので、
図23においては、現在(0h)から5時間後である。また、業務「業務支払」のリソース「PC」および業務「業務アプリケーション」のリソース「PC」の復旧予定時間は、障害発生から4時間後であるので、
図23においては、現在(0h)から3時間後である。このため、
図23に示す稼働状態グラフ302における3hの位置で、2個のリソースのステータスが「Orange」から「Green」に変化している。また、5hの位置で、2個のリソースのステータスが「Orange」から「Green」に変化している。
【0127】
一方、ステータスが「Red」であるリソースのうち、業務「業務アプリケーション」および業務「業務コミュニケーション」における4個のリソースの復旧予定時間は、障害発生から6時間なので、
図23においては、現在(0h)から5時間後である。そして、業務「業務支払」のリソース「決裁権限者」は、グラフに表示される16時間以内には復旧しない。このため、
図23に示す稼働状態グラフ302における5hの位置で、4個のリソースのステータスが「Red」から「Green」に変化している。そして、各リソースのステータスが「Green」に移行する位置に沿って、リソースの復旧予測ライン304が表示されている。
【0128】
業務に関しては、今回報告された業務「業務品質管理」は、業務「業務お客様窓口」と同様に、全てのリソースのステータスが「Orange」以上なので、業務自体が稼働している。そして、障害発生から6時間後(
図23の現在(0h)から5時間後)には、業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも復旧する。これに対し、業務「業務支払」は、リソース「決裁権限者」が復旧しないため、業務自体も16時間以内には稼働しない。したがって、業務の復旧予測ライン303は、5hの位置までは業務「業務お客様窓口」および業務「業務品質管理」のリソースの総数である「12」に設定されており、5h以降は、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソースの総数を加えた「26」に設定されている。
【0129】
図24は、障害発生から100分経過後の稼働レベル管理画面300Eの状態を例示する図である。
この時点までに、業務「業務物流」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄301を参照すると、業務「業務物流」に関しては、リソース「電気」、「社員」、「派遣スタッフ」、「本社オフィス」、「電話」が平常時通り稼働しており(ステータス「Green」)、リソース「サーバ」、「PC」は稼働していない状態である(ステータス「Red」)。このように、業務「業務物流」は、2個のリソースのステータスが「Red」であるので、業務自体のステータスも「Red」となる。
【0130】
また、管理項目欄301において、ステータスが「Orange」である4個のリソースの位置を比較すると、
図23の例と同様に、業務「業務お客様窓口」のリソース「オペレータ」および業務「業務品質管理」のリソース「業務機器」が、他の2個のリソースよりも上に配置されている。そして、ステータスが「Red」である5個のリソースの位置を比較すると、稼働状態グラフ302を参照して後述するように復旧予定時間の最も長い業務「業務支払」のリソース「決裁権限者」が最上位に配置され、復旧予定時間が次に長い業務「業務物流」のリソース「サーバ」およびリソース「PC」が、業務「業務支払」のリソース「決裁権限者」よりも下で、他の4個のリソースよりも上に配置されている。
【0131】
次に、稼働状態グラフ302を参照すると、現在(0h)の表示は、管理項目欄301の「リソース」の表示が反映され、30個のリソースが「Green」、4個のリソースが「Orange」、7個のリソースが「Red」となっている。
【0132】
また、現在(0h)以降の表示については、報告のあった41個のリソース(稼働状態グラフ302に表示される全てのリソース)に関して、ステータスが段階的に復旧する様子(予測結果)が示されている。そして、この予測に基づいて、業務の復旧予測ライン303と、リソースの復旧予測ライン304とが表示されている。
【0133】
ここでは、ステータスが「Red」である業務「業務物流」のリソース「サーバ」および「PC」の復旧予定時間は、障害発生から12時間後であるものとする。したがって、障害発生から1時間以上が経過している
図24においては、現在(0h)から11時間後である。この他、ステータスが「Orange」である各リソースおよびステータスが「Red」である各リソースの復旧時間は、それぞれ
図23の例と同様である。したがって、
図24に示す稼働状態グラフ302における3hの位置で、2個のリソースのステータスが「Orange」から「Green」に変化し、5hの位置で、2個のリソースのステータスが「Orange」から「Green」に変化している。また、5hの位置で、4個のリソースのステータスが「Red」から「Green」に変化している。さらに、11hの位置で、2個のリソースのステータスが「Red」から「Green」に変化している。また、業務「業務支払」のリソース「決裁権限者」に対応する1個のリソースのステータスが「Red」の状態のまま維持される。そして、各リソースのステータスが「Green」に移行する位置に沿って、リソースの復旧予測ライン304が表示されている。
【0134】
業務に関しては、今回報告された業務「業務物流」は、
図24の現在(0h)から11時間後にリソース「サーバ」および「PC」が復旧すれば、全てのリソースが復旧し、業務が稼働する状態となる。他の業務の復旧予測に関しては、
図23について説明した通りである。したがって、業務の復旧予測ライン303は、5hの位置までは業務「業務お客様窓口」および業務「業務品質管理」のリソースの総数である「12」に設定され、5hから11hまでは、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソースの総数を加えた「26」に設定され、11h以降は、さらに業務「業務物流」のリソースの数を加えた「33」に設定されている。
【0135】
図25は、障害発生から130分経過後の稼働レベル管理画面300Eの状態を例示する図である。
この時点で、業務「業務アプリケーション」に関して、再度、リソースの稼働状況の報告があり、リソース「アプリサーバ」の復旧の見込みが立たなくなったものとする。この結果、管理項目欄301を参照すると、各業務および各リソースのステータスの表示は
図24の状態から変わらないが、復旧予定時間を計算できない業務「業務アプリケーション」のリソース「アプリサーバ」の表示位置が、管理項目欄301の最上位に移動している。
【0136】
次に、稼働状態グラフ302を参照すると、
図25では、障害発生から130分(2時間以上)が経過しているので、グラフの表示が
図24の状態からさらに1単位分進んでいる(図において、左へ移動している)。すなわち、
図25の稼働状態グラフ302におけるの現在(0h)は、障害発生から2時間経過後である。この現在(0h)の表示は、管理項目欄301の「リソース」の表示が反映され、30個のリソースが「Green」、4個のリソースが「Orange」、7個のリソースが「Red」となっている。
【0137】
また、現在(0h)以降の表示については、復旧の見込みが立たないとの報告のあった1個のリソースは、ステータスの表示が消えている(稼働状態グラフ302の最上段)。そして、残りの40個のリソースに関して、ステータスが段階的に復旧する様子(予測結果)が示され、この予測に基づいて、業務の復旧予測ライン303と、リソースの復旧予測ライン304とが表示されている。
【0138】
図25に示す例では、障害発生から2時間以上が経過しているので、ステータスが「Orange」のリソースに関しては、障害発生からの復旧予定時間が4時間であった2個のリソースは、稼働状態グラフ302における2hの位置で、ステータスが「Orange」から「Green」に変化している。同様に、復旧時間が6時間であった2個のリソースは、4hの位置で、ステータスが「Orange」から「Green」に変化している。
【0139】
一方、ステータスが「Red」であるリソースのうち、業務「業務アプリケーション」のリソース「アプリサーバ」は復旧の見込みが立たないのでステータスが表示されていない(稼働状態グラフ302の最上段)。そして、障害発生からの復旧予定時間が6時間であった残りの3個のリソースは、稼働状態グラフ302における4hの位置で、ステータスが「Red」から「Green」に変化している。また、復旧予定時間が12時間であった業務「業務物流」の2個のリソースは、10hの位置で、ステータスが「Red」から「Green」に変化している。また、業務「業務支払」のリソース「決裁権限者」に対応する1個のリソースのステータスが「Red」の状態のまま維持される。そして、各リソースのステータスが「Green」に移行する位置に沿って、リソースの復旧予測ライン304が表示されている。
【0140】
業務に関しては、
図25では、
図24に示した業務の復旧予測ライン303がそのまま表示されれば、図の左方向へ1単位分ずれて、稼働状態グラフ302における4hの位置までは「12」、4hから10hまでは「26」、10h以降は「33」となる(
図25の復旧予測ライン303a)。しかし、今回の報告により、業務「業務アプリケーション」のリソース「アプリサーバ」に関して復旧の見込みが立たなくなったので、業務「業務アプリケーション」自体も稼働再開の見込みが立たなくなった。そのため、業務「業務アプリケーション」が稼働すると予想されていた稼働状態グラフ302の4h以降では、
図24に示された復旧予測ライン303よりも業務「業務アプリケーション」のリソースの数(7個)だけ下がった値に設定される。すなわち、4hから10hまでは「19」、10h以降は「26」に設定される(
図25の復旧予測ライン303b)。
【0141】
図25に示す稼働レベル管理画面300Eでは、上記のようにして得られた復旧予測ライン303aと復旧予測ライン303bとを共に表示している。なお、図示の例では、復旧予測ライン303bを色の薄い破線で表示することにより、復旧予測ライン303aと区別している。このような表示を行うことにより、順調に復旧作業が行われた場合の復旧予測(復旧予測ライン303a)に対する遅延が発生していることを視覚的に示すことができる。
【0142】
以上説明したように、本実施形態によれば、リソースの稼働状態の情報を収集することにより、そのリソースを含む業務の稼働状態を把握することができる。そのため、
図19〜
図25を参照して説明したように、個々のリソース単独の復旧予測だけでなく、各リソースが含まれる業務単位での稼働の再開時期の予測を行うことが可能となる。
【0143】
以上、本実施形態の構成および機能について説明したが、具体的なシステム構成や表示画面の構成は、上述した具体例には限定されない。本実施形態は、業務を遂行するために不可欠なリソースとして設定、抽出された個々のリソースについて、稼働状態の判断基準を設定する。また、各リソースの稼働状態が業務を遂行するために要求される通常の状態よりも低下した場合に、リソースおよび稼働状態ごとに、そのリソースの稼働状態を通常の状態に復帰させるために実施すべき対策を設定する。そして、個々のリソースごとに、稼働状態を低下させた原因(災害や事故等)の如何に関わらず、低下した稼働状態を通常の状態に復帰させるための対策を提示したり、対策の実施状況を示す情報を提示したり、各リソースを含む業務の稼働の再開時期を予測したりするものである。したがって、かかる技術思想を逸脱しない範囲において、種々の構成や機能を採ることが可能である。
【0144】
例えば、本実施形態では、管理用端末装置300を用いて管理サーバ200からリソースに関する情報を取得し、適宜編集して上記の情報を提示するようにしたが、かかる情報処理を行う機能を管理サーバ200に設け、管理用端末装置300の代わりに、画像表示手段や入力デバイスを管理サーバ200に設ける構成としても良い。この場合、上記実施形態における管理サーバ200と管理用端末装置300とを合わせて管理サーバとして把握される。
【0145】
また、現場用端末装置100において使用者(現場担当者)に提示される予め設定されている情報(「リソース」や「ステータス」の種類、ステータスに応じて実施すべき対策の内容や目標時間など)は、管理サーバ200から現場用端末装置100へ送信される構成としても良い。
【0146】
さらに、現場用端末装置100の各種の機能は、現場用端末装置100にインストールされたアプリケーション・ソフトウェアによって実現されるようにしても良いし、管理サーバ200に設けられたウェブ・アプリケーションによって実現し、現場用端末装置100に提供される構成としても良い。
【0147】
なお、上記の進度情報の評価や業務の復旧予定時間の予測は、リソースや業務が稼働するステータス「Orange」となるときを基準として行ったが、ステータスが「Orange」である場合のリソースや業務の稼働レベルは、本来の状態で稼働する「Green」や「Yellow」の場合と比べて低下している。そこで、本来の状態で稼働するステータス「Yellow」となるときを基準として、進度情報の評価や復旧予定時間の予測を行っても良い。さらに、これらを組み合わせて行い、各々を区別して表現することにより、稼働を再開する時点と、本来の稼働状態に復帰する時点の双方について、進度情報や復旧予定時間の予測の情報を提示しても良い。
【0148】
<業務復旧支援システムの応用例>
次に、本実施形態による業務復旧支援システムの応用例について説明する。
ここでは、商品の出荷業務やサービス業務のような対外的に品物やサービスを提供する業務を行う会社の業務管理に本実施形態のシステムを適用し、そのような複数のシステムの管理情報を集約して利用する応用例を説明する。
【0149】
図26は、本実施形態の業務復旧支援システムを含む集約管理システムの構成例を示す図である。
図26に示すシステム構成では、全体集約サーバ600に複数の個社別管理サーバ500が接続されている。また、全体集約サーバ600には、複数の利用者システムのサーバ(以下、利用者サーバ)700が接続されている。全体集約サーバ600と個社別管理サーバ500との間の接続および全体集約サーバ600と利用者サーバ700との間の接続は、例えば、インターネット等の既存のネットワークを用いて行っても良いし、専用回線等を用いて行っても良い。通信プロトコルや回線の種類は特に限定されず、無線回線か有線回線かも問わない。なお、
図26に示す例では、全体集約サーバ600に対して2台の個社別管理サーバ500および3台の利用者サーバ700を接続した構成が示されているが、全体集約サーバ600に対する各サーバの接続数は、図示の構成例に限定されない。
【0150】
図26に示す例において、個社別管理サーバ500は、本実施形態の業務復旧支援システムにおける管理サーバ200に相当する。すなわち、個社別管理サーバ500には、登録されたリソースの稼働状態に関する情報が、現場用端末装置100から送られ、集められる。言い換えれば、個社別管理サーバ500は、登録されたリソースの稼働状態に関する情報を収集する情報収集サーバとして機能する。また、個社別管理サーバ500は、収集した情報に基づき、各リソースが含まれる業務の稼働状態を判断する。個社別管理サーバ500は、管理サーバ200の機能を有しているので、リソースおよび業務の稼働状態に関する情報を管理するため、
図13〜
図16を参照して説明したダッシュボード画面300A、稼働状態提示画面300B、復旧状況確認画面300C、チェックイン確認画面300D、
図19〜
図25を参照して説明した稼働レベル管理画面300Eを生成する。
【0151】
本応用例では、会社ごとに個社別管理サーバ500が設けられ、会社の業務の稼働状態が管理されるものとする。
図26に示す例では、会社Aと会社Bがそれぞれ個社別管理サーバ500を有している。ここで、各個社別管理サーバ500により稼働状態が管理される業務には、上述したように、対外的に品物やサービスを提供する業務が含まれる。
【0152】
対外的に品物やサービスを提供する業務に関する稼働状態に関しては、提供対象である個々の品物やサービスをそれぞれリソースとし、品物の出荷可否やサービスの提供可否についての情報を稼働状態の情報として設定することができる。例えば、品物の出荷が本来の状態(時間当たりの出荷量が本来の設定量に達している等)で可能であれば、ステータスが「Green」や「Yellow」となり、本来よりも低下したレベルで可能であれば、ステータスが「Orange」となり、出荷不能であれば、ステータスが「Red」となる。
【0153】
全体集約サーバ600は、全体集約サーバ600に接続されている各個社別管理サーバ500において管理されるリソースおよび業務の稼働状態に関する情報を集約して管理する。言い換えれば、全体集約サーバ600は、情報収集サーバである個社別管理サーバ500により収集された情報を集約する集約サーバとして機能する。全体集約サーバ600が集約する稼働状態に関する情報には、各個社別管理サーバ500で生成される各種の画面300A〜300Eを含んでも良い。また、これらの画面300A〜300Eを生成するために必要な情報を各個社別管理サーバ500から取得し、全体集約サーバ600において、各画面300A〜300Eを生成するように構成しても良い。
【0154】
また、全体集約サーバ600は、利用者サーバ700からの要求に応じて、集約管理しているリソースおよび業務の稼働状態に関する情報を返す。ここで、全体集約サーバ600は、集約管理しているリソースおよび業務の稼働状態に関する情報に対するアクセス制御を行うことができる。
【0155】
例えば、
図26に示すように、全体集約サーバ600は、管理テーブル601等により、集約管理している個々のリソースおよび業務の稼働状態に関する情報と、各利用者との対応関係を管理する。そして、全体集約サーバ600は、利用者サーバ700から情報の取得要求を受け取った場合に、要求を行った利用者サーバ700(利用者)に対応付けられているリソースおよび業務の稼働状態に関する情報のみを返す。
図26に示す管理テーブル601の例では、利用者αに対して、会社Aの商品A−1、A−2、A−3と、会社BのサービスBS−1とが対応付けられている。また、利用者βに対して、会社Aの商品A−4、A−5と、会社Bの商品B−1およびサービスBS−1とが対応付けられている。また、利用者γに対して、会社Bの商品B−1、B−2およびサービスBS−2が対応付けられている。したがって、例えば、利用者αの利用者サーバ700から情報の取得要求が行われた場合、利用者サーバ700は、会社Aの業務「出荷」におけるリソース「商品A−1」、「商品A−2」、「商品A−3」および会社Bの業務「サービス」におけるリソース「サービスBS−1」の稼働状態に関する情報のみを取得することができる。
【0156】
全体集約サーバ600から各利用者サーバ700に送られる情報には、
図13〜
図16を参照して説明したダッシュボード画面300A、稼働状態提示画面300B、復旧状況確認画面300C、チェックイン確認画面300D、
図19〜
図25を参照して説明した稼働レベル管理画面300Eを含むように構成しても良い。
【0157】
<集約管理システムの適用例>
図26に示した集約管理システムの具体的な適用例について説明する。
この例では、利用者サーバ700を有する利用者α、利用者β、利用者γがそれぞれ自動車メーカであり、個社別管理サーバ500を有する会社A、会社Bが自動車部品の製造メーカであるものとする。そして、会社Aおよび会社Bは、利用者α、利用者β、利用者γに対する部品の出荷業務を行っており、会社Aおよび会社Bの各々の個社別管理サーバ500は、各利用者α〜γに出荷している部品に関して、各部品をリソースとするリソースおよび業務の稼働状態に関する情報を管理している。この稼働状態に関する情報は、会社Aおよび会社Bの個社別管理サーバ500から、それぞれ全体集約サーバ600へ送られ、全体集約サーバ600において集約管理される。
【0158】
自動車メーカである利用者α、利用者βおよび利用者γは、それぞれ全体集約サーバ600へアクセスし、自身が購入している部品(リソース)に関する稼働状態の情報を取得することができる。これにより、利用者α、利用者βおよび利用者γは、自身が購入している部品の入荷が可能かどうかを判断することができる。すなわち、利用者α、利用者βおよび利用者γから見れば、自社の取引先である部品メーカの全てに問い合わせることなく、あたかも自社のリソースのごとく部品の供給情報を「稼働レベル情報」として参照することができる。そして、例えば、ある車種については部品が十分に供給されるので生産可能だが、他のある車種については部品が十分に供給されないので生産量を落とす必要がある、また他のある車種については部品供給が無いので生産できない等の判断を行うことが可能になる。
【0159】
一方、部品の製造メーカである会社Aおよび会社Bから見れば、個別の部品に関する出荷状態の情報を、お客様毎に個別に連絡する必要が無くなる。そのため、業務全体として利便性の向上や判断の時間の短縮を図ることができる。
【0160】
なお、上記の例では、生産部品の出荷に関して稼働状態の情報を管理する例を説明したが、生産部品に限らず、各車種の自動車を生産するための様々なサービスやインフラ設備の稼働状態についても、全体集約サーバ600で集約管理し、利用者サーバ700からアクセスできるようにすることが可能である。
【0161】
また、上記の例では、個々の部品(リソース)の出荷状態(稼働状態)の情報を利用者が取得し、利用者の業務において対応する例を示したが、管理対象である部品に関する業務の稼働状態の情報に基づいて、利用者の業務において対応することも考えられる。例えば、会社Aの出荷業務の稼働レベルが低下している場合、自身が購入している部品(リソース)の出荷状態(稼働状態)は正常であっても、他の部品に関する稼働レベルが低下していることがわかり、会社Aの業務に負荷が生じていることが想定される。そこで、自身が購入している部品の出荷についての稼働レベルが低下する場合に備えて、予め対策を取る準備をすることが可能となる。言い換えれば、本応用例においては、本実施形態による業務復旧支援システムにより扱われる稼働状態の情報を集約管理することにより、集約された情報の利用者の業務の稼働状態を、その業務を遂行するために要求される通常の状態に維持させるための支援を行うことができる。
【0162】
上記の例においても明らかなように、本実施形態の業務復旧支援システムは、リソースや業務の稼働レベルを、その業務を遂行するために要求される通常の状態に維持し、また稼働レベルが低下した場合に、本来の稼働レベルに復旧させるための対策を取るための支援をする。そして、本実施形態の業務復旧支援システムが扱う情報には、稼働レベルを低下させた原因が含まれない。すなわち、災害や事故とは関係なく、単に業務上の負荷の増大等によって業務の稼働レベルが低下しているような場合にも、本来の稼働レベルに復旧させるための対策を取るための支援をすることができる。
さらに、本実施形態の業務復旧支援システムでは、管理対象の業務を遂行するために必要なリソースが管理対象のリソースとして設定されるため、リソースの稼働状態の情報を収集することにより、そのリソースを含む業務の稼働状態を把握することができる。