JP2015079489A - 業務復旧支援システム、業務復旧支援装置、復旧状況管理装置およびプログラム - Google Patents

Abstract

【課題】災害の種類や規模、災害等により発生する被害の内容に関わらずに、中断したり実施レベルが低下したりした業務を効率よく復旧させることを可能とする。【解決手段】現場用端末装置は、業務を遂行するために不可欠なリソースの稼働状態を特定するステータス情報を入力するためのステータス情報入力手段と、ステータス情報入力手段により入力されたステータス情報および管理サーバから受信したステータス情報に基づき、各リソースの復旧対策を提示する対策情報提示手段と、を備える。管理サーバは、現場用端末装置から受信したリソースのステータス情報を管理し、復旧予定時間に対する復旧対策の実施状況の進度を求める。また、管理サーバは、リソースが属す業務の稼働が再開される時間を予測する。【選択図】図１３

Description

本発明は、災害等に起因して低下した業務を遂行する能力の復旧を支援するシステム、装置およびプログラムに関する。

企業等の組織において、災害や事故が発生した際の損害を抑制し、事業の継続や早期復旧を図るために、事業継続計画（ＢＣＰ：Business Continuity Plan）を予め策定しておくことが行われている。この事業継続計画を策定するには、通常、対象業務の実行プロセスや対象業務が依存する要素（経営要素や社外要素）を分析し、さらに災害や事故等が発生した場合の被害を想定して、事業を継続しまたは復旧させるための対策案を作ることが行われる。

従来から、この事業継続計画の策定を支援するためのシステムが提案されている。例えば、事業を構成するプロセスとプロセスで利用されるリソースとの関係を、プロセスでリソースが必要となる度合いとともに対応づけて保持し、保持された前記プロセスとリソースとの関係に基づいて、リソースの状態に係る情報からプロセスの状態に係る情報を推定することにより、災害や事故に伴う業務の変動状況を推定するシステムが提案されている（例えば、特許文献１を参照）。また、業務の遂行に用いられる各種リソースごとに障害発生から復旧までの状態変化をシミュレートし、時間経過に伴う各リソース及び業務の復旧過程を導出したり、障害発生時の縮退過程における状態変化を各種リソースごとにシミュレートし、各リソース及び業務の縮退過程を導出したりするシステムが提案されている（例えば、特許文献２を参照）。

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

従来、事業継続計画を策定し、実施するためには、地震その他の自然災害、感染症の流行等、起こり得る災害を想定し、災害が起きた際に生じる被害を予測する必要があった。しかし、起こり得る災害の種類や規模は様々であり、その全てを想定し、発生する被害を的確に予測して、適切な事業継続計画を策定することは容易ではない。そのため、現実的には、災害が起きた際に、実際に発生した被害に応じて、中断したり実施レベルが低下したりした業務を、予め作成された事業継続計画に基づいて効率良く復旧させることが困難な場合があった。

本発明の目的は、災害の種類や規模、災害等により発生する被害の内容に関わらずに、中断したり実施レベルが低下したりした業務を効率よく復旧させることを可能とすることにある。

上記の目的を達成するため、本発明は、次のようなシステムとして実現される。このシステムは、管理対象の業務の稼働状態に関する情報の入力を受け付ける現場用端末装置と、現場用端末装置により入力された情報を収集して管理する管理サーバと、を備える。
現場用端末装置は、業務を遂行するために不可欠なリソースとして設定されたリソースに関して、リソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報を入力するためのステータス情報入力手段と、このステータス情報入力手段により入力されたステータス情報を前記管理サーバへ送信し、管理サーバで管理されているリソースに関するステータス情報のうち、自装置以外の現場用端末装置から取得されたステータス情報を管理サーバから受信する通信手段と、ステータス情報入力手段により入力されたステータス情報および管理サーバから受信したステータス情報に基づき、業務における各リソースの稼働状態を、業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策を提示する対策提示手段と、を備える。
管理サーバは、現場用端末装置との間でステータス情報の送受信を行う通信手段と、この通信手段により現場用端末装置から受信したリソースのステータス情報を、リソースごとに、ステータス情報を送信した現場用端末装置に関連付けて管理する情報管理手段と、を備える。

より好ましくは、管理サーバの情報管理手段は、通信手段により現場用端末装置から受信したリソースのステータス情報に基づき、このリソースが属す業務の稼働状態を特定し管理する。
さらに好ましくは、現場用端末装置は、対策提示手段により提示される対策の実施状況を表す進捗情報を入力するための進捗情報入力手段をさらに備える。そして、通信手段は、進捗情報入力手段により入力された進捗情報を管理サーバへ送信し、管理サーバで管理されている進捗情報のうち、自装置以外の現場用端末装置から取得された進捗情報を管理サーバから受信する。対策提示手段は、進捗情報入力手段により入力された進捗情報および管理サーバから受信した進捗情報に基づき、対策の実施状況を提示する。管理サーバの情報管理手段は、通信手段により現場用端末装置から受信した進捗情報を、進捗情報に係るリソースと、進捗情報を送信した現場用端末装置とに関連付けて管理する。
さらに詳細には、この現場用端末装置のステータス情報入力手段は、少なくとも、（１）リソースが本来の状態で稼働している状態である第１段階と、（２）リソースは稼働しているが、本来の状態よりも稼働レベルが低下した状態である第２段階と、（３）リソースが稼働していない状態である第３段階と、を含む、複数の段階のいずれに該当するかを選択的に指定可能な入力インターフェイスを有する。

また、より好ましくは、管理サーバは、情報管理手段に管理されているステータス情報および進捗情報に基づいて得られるリソースごとの対策の実施状況に基づき、リソースが属す業務の稼働が再開される時間を予測する予測手段をさらに備える。
より詳細には、管理サーバは、管理対象の業務に属すリソースに関して、リソースの稼働状態を所定の稼働状態から業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、情報管理手段に管理されているステータス情報に基づき、リソースの稼働状態を通常の状態に復帰させるために実施すべき対策を特定し、特定された対策に係る目標時間に基づき、業務を稼働させるために必要な対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、情報管理手段に管理されている進捗情報に基づき、復旧予定時間に対する対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、をさらに備える。

また、本発明は、次のようなシステムとしても実現される。このシステムは、管理対象の業務を遂行するために不可欠なリソースとして設定されたリソースの稼働状態に関する情報を収集する情報収集サーバと、複数の情報収集サーバにより収集された情報を集約して管理する集約サーバと、を備える。
情報収集サーバは、リソースに関して、このリソースの稼働状態を所定の稼働状態から業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、この対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、管理対象の業務に属すリソースに関して、このリソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報、および、このステータス情報に基づいて特定される業務における各リソースの稼働状態を、通常の状態に復帰させるために実施すべき対策の実施状況を表す進捗情報を取得する情報取得手段と、この情報取得手段により取得されたリソースごとのステータス情報に基づき、リソースの稼働状態を通常の状態に復帰させるために実施すべき対策を特定し、特定された対策に係る目標時間に基づき、業務を稼働させるために必要な対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、情報取得手段により取得されたリソースごとの進捗情報に基づき、復旧予定時間に対する対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、を備える。
集約サーバは、情報収集サーバからリソースのステータス情報を取得して管理すると共に、個々のリソースと利用者との対応関係を管理し、利用者からの情報取得要求に応じて、この情報取得要求を行った利用者に対応付けられたリソースの稼働状態に関する情報を返す。

さらに本発明は、コンピュータを制御して上述した装置の各機能を実現するプログラムとしても実現される。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより、提供することができる。

本発明によれば、災害の種類や規模、災害等により発生する被害の内容に関わらずに、中断したり実施レベルが低下したりした業務を効率よく復旧させることが可能となる。

本実施形態の業務復旧支援システムの構成例を示す図である。 現場用端末装置の機能構成例を示す図である。 メニュー画面の構成例を示す図である。 リソース状態確認画面の構成例を示す図である。 稼働状態入力画面の構成例を示す図である。 復旧管理画面の構成例を示す図である。 対策情報確認画面の構成例を示す図である。 対策情報確認画面でチェックインの操作が行われた後の復旧管理画面の表示例を示す図である。 図８の状態の復旧管理画面から移行した対策情報確認画面の表示例を示す図である。 対策情報確認画面で終了報告の操作が行われた後の復旧管理画面の表示例を示す図である。 管理サーバの機能構成例を示す図である。 管理用端末装置の機能構成例を示す図である。 ダッシュボード画面の構成例を示す図である。 稼働状態提示画面の構成例を示す図である。 復旧状況確認画面の構成例を示す図である。 チェックイン確認画面の構成例を示す図である。 お客様窓口業務に関する対策情報の例を示す図である。 リソースの稼働低下時の対策として設定された業務支援の具体的な内容の例を示す図である。 障害の発生前における稼働レベル管理画面の状態を例示する図である。 障害発生時の稼働レベル管理画面の状態を例示する図である。 障害発生から１５分経過後の稼働レベル管理画面の状態を例示する図である。 障害発生から３０分経過後の稼働レベル管理画面の状態を例示する図である。 障害発生から９０分経過後の稼働レベル管理画面の状態を例示する図である。 障害発生から１００分経過後の稼働レベル管理画面の状態を例示する図である。 障害発生から１３０分経過後の稼働レベル管理画面の状態を例示する図である。 本実施形態の業務復旧支援システムを含む集約管理システムの構成例を示す図である。

以下、添付図面を参照して、本発明の実施形態について詳細に説明する。
本実施形態の業務復旧支援システムは、管理対象の業務に関して、その業務を遂行するために必要な各リソース（人的リソース、設備、資材など）の稼働状態を管理する。そして、リソースごとの稼働状態に応じて、予め定められた、各リソースを本来の稼働状態（業務を遂行するために要求される通常の状態）に復旧させるための対策を提示する。本実施形態では、災害等によって発生した被害に基づいて業務を復旧するための対策を設定するのではなく、業務を遂行するために必要な個々のリソースが本来の稼働状態に復帰するようにリソースごとに設定された対策を実施することにより、結果的に業務が復旧するように支援を行う。したがって、本実施形態による業務復旧支援システムを運用するにあたり、起こり得る災害を予め想定して被害を予測する必要はない。

＜システム構成例＞
まず、本実施形態が適用される業務復旧支援システムの全体構成について説明する。
図１は、本実施形態の業務復旧支援システムの構成例を示す図である。
図１に示すように、本実施形態の業務復旧支援システムは、現場用端末装置１００と、管理サーバ２００と、管理用端末装置３００とを備える。現場用端末装置１００と管理サーバ２００とは、ネットワーク４００を介して接続されており、管理用端末装置３００は、管理サーバ２００に直接接続されている。

現場用端末装置１００は、業務の遂行に必要な個々のリソースの稼働状態についての情報を入力するために用いられる装置である。現場用端末装置１００としては、通信機能を備えた携帯型の情報処理装置が好適である。例えば、電話機能を備えた携帯型情報機器（いわゆるスマートフォン）、タブレット型情報端末、ノート型パーソナルコンピュータ等を現場用端末装置１００として用いることができる。なお、使用環境によっては、デスクトップ型パーソナルコンピュータ等の据え置き型の装置を用いても良い。

この現場用端末装置１００は、現場担当者が所持し、その現場担当者が担当するリソースの稼働状態の情報を入力するために用いる。入力された情報は、ネットワーク４００を介して管理サーバ２００へ送信される。現場担当者は、通常、リソースごとに１名から数名が割り当てられ、これに伴って、現場用端末装置１００は、リソースごとに１台から数台が用意される。一方、１人の現場担当者が複数のリソースを担当することが可能であり、この場合、その現場担当者は、自身が所持する現場用端末装置１００を用いて、自身が担当する複数のリソースに関する情報を入力する。

また、現場用端末装置１００は、入力された個々のリソースの稼働状態に応じて、そのリソースを本来の稼働状態に戻すために実施すべき対策を提示する。したがって、現場担当者は、現場用端末装置１００を用いてリソースに関する情報を入力すると、入力したリソースに関して、稼働状態を本来の状態に戻すために実施すべき対策を現場用端末装置１００から得ることができる。

管理サーバ２００は、各現場用端末装置１００により入力されたリソースごとの稼働状態の情報を収集し、各リソースが属す業務ごとに管理する。そして、各現場用端末装置１００に、同じ業務に属すリソースに対応する現場用端末装置１００から収集した情報を配信する。これにより、各現場用端末装置１００は、自身が対応付けられたリソースが属す業務と同じ業務に属すリソースに関する情報を取得する。この情報は、現場用端末装置１００を用いて現場担当者が確認することができる。そのため、各現場担当者は、業務単位でリソースの稼働状態を把握することができ、例えば、特に稼働状態の復帰が遅れているリソースに対する対策を優先的に実施させることが可能となる。また、管理サーバ２００は、管理対象として設定された複数の業務に属すリソースの稼働状態の情報を収集し、管理する。これにより、業務の復旧が必要な事態が生じた際に、業務単位での復旧状況を把握することが可能となる。なお、管理サーバ２００は、例えば、パーソナルコンピュータを用いて実現される。この場合、管理サーバ２００を実現するパーソナルコンピュータは、演算手段であるＣＰＵと、記憶手段であるメモリおよび磁気ディスク装置等を備える。そして、記憶手段に格納されているプログラムをＣＰＵが読み出して実行することにより、後述する管理サーバ２００の各機能が実現される。

管理用端末装置３００は、管理サーバ２００において管理される情報を表示し、管理対象である各種業務の稼働状態や復旧状況を確認するために用いられる。すなわち、管理用端末装置３００は、管理サーバ２００の操作端末として機能する。図示の構成例では、管理用端末装置３００は、管理サーバ２００に直接接続されているが、ネットワーク４００や、ネットワーク４００とは異なる固有のネットワーク等を介して管理サーバ２００と接続されても良い。なお、管理用端末装置３００は、例えば、パーソナルコンピュータを用いて実現される。この場合、管理用端末装置３００を実現するパーソナルコンピュータは、演算手段であるＣＰＵと、記憶手段であるメモリおよび磁気ディスク装置等を備える。そして、記憶手段に格納されているプログラムをＣＰＵが読み出して実行することにより、後述する管理用端末装置３００の各機能が実現される。

ネットワーク４００の具体的な構成は、本実施形態のシステムの運用環境等に応じて適宜に設定される。例えば、インターネット等の既存のネットワークを用いて構成しても良いし、専用回線等を用いて構成しても良い。通信プロトコルや回線の種類は特に限定されず、無線回線か有線回線かも問わない。また、ネットワーク４００の一部が電話回線であっても良い。例えば、現場用端末装置１００が電話機能を備える場合、この電話機能によりネットワーク４００の電話回線に接続することができる。

＜現場用端末装置の機能構成＞
図２は、現場用端末装置１００の機能構成例を示す図である。
図２に示すように、本実施形態の現場用端末装置１００は、画像表示部１１０と、入力操作部１２０と、ユーザ・インターフェイス制御部１３０と、通信制御部１４０と、リソース情報記憶部１５０と、対策情報記憶部１６０とを備える。

画像表示部１１０は、例えば液晶ディスプレイ等のディスプレイ装置により実現され、各種の画面を表示する。本実施形態では、リソースの稼働状態の情報を提示する画面や、使用者（現場担当者）がデータやコマンドを入力するために用いられる入力画面等が表示される。

入力操作部１２０は、使用者（現場担当者）がデータや制御コマンドの入力操作を行うための入力デバイスである。本実施形態では、画像表示部１１０の表示画面に重ねて設けられたタッチパネルを入力操作部１２０として用いる。このような構成とすることにより、使用者（現場担当者）は、画像表示部１１０に表示される入力画面を見ながら、画面上の特定の位置（ボタンオブジェクトの表示位置等）にタッチすることにより、リソースに関する情報や各種のコマンドを入力することが可能となる。

ユーザ・インターフェイス制御部１３０は、画像表示部１１０に情報提示画面や入力画面を表示させる。そして、使用者（現場担当者）が入力操作部１２０を用いた操作を行うと、ユーザ・インターフェイス制御部１３０は、検出された操作を表示中の画面に対する入力操作として受け付ける。本実施形態において、ユーザ・インターフェイス制御部１３０が提供する画面の詳細については後述する。

通信制御部１４０は、入力操作部１２０の操作により入力されたリソースの稼働状態の情報を管理サーバ２００へ送信する。また、管理サーバ２００から他の現場用端末装置１００において入力されたリソースの稼働状態の情報等を受信する。また、特に図示しないが、現場用端末装置１００は、この通信制御部１４０の制御によりネットワーク４００を介して情報の送受信を行うためのネットワーク・インターフェイス（電話機能を備える現場用端末装置１００では、電話回線への接続機構を含む）を備える。

リソース情報記憶部１５０は、入力操作部１２０の操作により入力されたリソースの稼働状態の情報および通信制御部１４０が管理サーバ２００から受信したリソースの稼働状態の情報を保持する。このリソース情報記憶部１５０は、例えば、フラッシュメモリ等の書き換え可能な不揮発性メモリにより実現される。

対策情報記憶部１６０は、各リソースに関して、その稼働状態に応じて設定された実施すべき対策の情報を保持する。この対策情報記憶部１６０は、例えば、ＲＯＭ（Read Only Memory）等の不揮発性メモリにより実現される。

＜インターフェイス画面の構成＞
ここで、ユーザ・インターフェイス制御部１３０により画像表示部１１０に表示される各種の画面について説明する。本実施形態では、現場用端末装置１００における情報の入出力のためにユーザ・インターフェイス制御部１３０が制御する画面として、メニュー画面１００Ａと、リソース状態確認画面１００Ｂと、稼働状態入力画面１００Ｃと、復旧管理画面１００Ｄと、対策情報確認画面１００Ｅの５種類の画面を用意する。

図３は、メニュー画面１００Ａの構成例を示す図である。
メニュー画面１００Ａは、現場用端末装置１００を使用する際に初期的に表示され、各種の機能を呼び出すための画面である。図３に示す例では、メニュー画面１００Ａに、「通知」、「リソース」、「復旧情報」、「履歴」、「ログイン」、「チェックイン」の６個のボタン・オブジェクトが表示されている。「通知」ボタンは、現場用端末装置１００を用いて入力した情報を管理サーバ２００へ送信する処理を実行させるためのボタンである。「リソース」ボタンは、リソース状態確認画面１００Ｂを呼び出すためのボタンである。リソース状態確認画面１００Ｂの詳細については後述する。「復旧情報」ボタンは、復旧管理画面１００Ｄを呼び出すためのボタンである。復旧管理画面１００Ｄの詳細については後述する。「履歴」ボタンは、業務やリソースの復旧作業を行うのに伴ってやり取りされた通信等の履歴や内容を表示させるためのボタンである。「ログイン」ボタンは、現場用端末装置１００の使用者（現場担当者）の認証情報を入力して現場用端末装置１００を使用可能とするログイン操作を行うためのボタンである。「チェックイン」ボタンは、業務やリソースの復旧作業を現に行っている作業者を登録するチェックイン操作を行うためのボタンである。なお、図３に示すメニュー画面１００Ａの構成は例示に過ぎない。メニュー画面１００Ａの機能としては、少なくとも図示の「通知」ボタン、「リソース」ボタン、「復旧情報」ボタンに相当する機能が存在すれば良く、ボタンの種類や配置は図示の例に限定されない。

図４は、リソース状態確認画面１００Ｂの構成例を示す図である。
図３に示したメニュー画面１００Ａで「リソース」ボタンにタッチすると、ユーザ・インターフェイス制御部１３０により、リソース状態確認画面１００Ｂが呼び出されて、画像表示部１１０に表示される。図４に示す例では、リソース状態確認画面１００Ｂに、業務を遂行するために不可欠な「リソース」が並べて記載され、各「リソース」に関して、「ステータス」、「更新日時」の表示欄が設けられている。

リソース状態確認画面１００Ｂに記載される「リソース」は、業務において利用されるリソースのうち、そのリソースが稼働していないとその業務を遂行することができないような、不可欠なリソースである。各業務におけるそのような不可欠なリソースは、予め業務内容を分析して抽出しておく。また、図示の例では、４種類の「リソース」（「派遣スタッフ」、「自動倉庫」、「ＦＡＸ」、「ＰＣ」）がリソース状態確認画面１００Ｂに記載されているが、これらは例示に過ぎない。抽出された全ての「リソース」をリソース状態確認画面１００Ｂ上に一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各リソースを表示できるようにすることができる。

図４に示すリソース状態確認画面１００Ｂの「ステータス」は、「リソース」の稼働状態を示す情報である。この情報は、入力操作部１２０を操作して入力されるか、または管理サーバ２００からネットワーク４００を介して取得する。図示のリソース状態確認画面１００Ｂにおいて、稼働状態の情報が入力されていない「リソース」については、「ステータス」欄は空欄となり、稼働状態の情報が入力されている「リソース」については、「ステータス」欄に、入力されている稼働状態を表すマークが表示される。図示の例では、「派遣スタッフ」の「ステータス」欄は空欄であり、その他の各「リソース」の「ステータス」欄にはマークが表示されている。

ここで、リソースの稼働状態についてさらに説明する。本実施形態では、リソースの稼働状態を次の４段階で設定する。
・リソースが本来の状態で稼働しており、将来的にリソースの稼働が低下する要因が存在すると認識されない状態（Ｇｒｅｅｎ）
・リソースが本来の状態で稼働しているが、将来的にリソースの稼働が低下する要因が存在すると認識される状態（Ｙｅｌｌｏｗ）
・リソースは稼働しているが、本来の状態よりも稼働レベルが低下している状態（Ｏｒａｎｇｅ）
・リソースが稼働していない状態（Ｒｅｄ）

そこで、リソース状態確認画面１００Ｂの「ステータス」欄に表示されるマークは、上記の４段階（「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」）の稼働状態のいずれに該当するかに応じて、緑色、黄色、橙色、赤色に色分けして表示されるものとする（「ステータス」欄に表示されるマークではなく、「ステータス」欄自体を色分けして区別しても良い）。なお、リソースの稼働状態を４段階に分けたこと、各段階を「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」で表現したことは、いずれも例示に過ぎない。管理対象の業務やリソースの内容に応じて、稼働状態を３段階以下の段階数で設定しても良いし、５段階以上の段階数で設定しても良い。また、稼働状態の各段階を識別するために、色分け以外の識別方法を用いても良い。さらに、本実施形態におけるリソースの稼働状態に関する表現としては、上記の４段階に加え、稼働状態の情報が入力されていない場合（「ステータス」欄が空欄である場合）を一つの状態として把握することもできる。

図４に示すリソース状態確認画面１００Ｂの「更新日時」は、「リソース」の「ステータス」の情報が入力された日時を示す。２回目以降の入力（更新）が行われた場合は、最後の入力が行われた日時に書き換えられる。この日時は、「ステータス」の情報が自装置の入力操作部１２０の操作により入力された場合は、入力操作が行われた際に、現場用端末装置１００の時計機能（図示せず）から取得される。また、「ステータス」の情報を管理サーバ２００から受信して取得した場合は、「ステータス」の情報と共に管理サーバ２００から受信する。

以上のように、本実施形態において、リソース状態確認画面１００Ｂおよび入力操作部１２０は、ステータスの情報を入力するためのステータス情報入力手段として機能する。上記のように構成されたリソース状態確認画面１００Ｂにおいて、所望のリソースを選択する操作（例えば、「リソース」欄にタッチする操作等）を行うと、ユーザ・インターフェイス制御部１３０により、選択されたリソースに関する稼働状態入力画面１００Ｃが呼び出され、リソース状態確認画面１００Ｂに替えて画像表示部１１０に表示される。

図５は、稼働状態入力画面１００Ｃの構成例を示す図である。
図５に示す例では、図４に示したリソース状態確認画面１００Ｂで選択されたリソースの「派遣スタッフ」に関する稼働状態入力画面１００Ｃが表示されている。図示の稼働状態入力画面１００Ｃには、「ステータス」、「説明」の各表示欄と、リソースが該当する稼働状態を指定するための「チェック」欄とが設けられている。図示の稼働状態入力画面１００Ｃの「ステータス」欄には、リソースの稼働状態の種類を示す「Ｇｒｅｅｎ」「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」の各項目が記載されている。

図５に示す稼働状態入力画面１００Ｃの「説明」欄には、リソースの稼働状態の種類ごとに、そのリソースの稼働状態が「ステータス」欄に記載された状態であると判断するための基準が記載される。図５に示す例は、リソース「派遣スタッフ」に関する稼働状態入力画面１００Ｃであるので、リソース「派遣スタッフ」の稼働状態が「Ｇｒｅｅｎ」と判断されるための具体的な基準が稼働状態「Ｇｒｅｅｎ」に対応する「説明」欄に、リソース「派遣スタッフ」の稼働状態が「Ｙｅｌｌｏｗ」と判断されるための具体的な基準が稼働状態「Ｙｅｌｌｏｗ」に対応する「説明」欄に、リソース「派遣スタッフ」の稼働状態が「Ｏｒａｎｇｅ」と判断されるための具体的な基準が稼働状態「Ｏｒａｎｇｅ」に対応する「説明」欄に、リソース「派遣スタッフ」の稼働状態が「Ｒｅｄ」と判断されるための具体的な基準が稼働状態「Ｒｅｄ」に対応する「説明」欄に、それぞれ記載される。各「説明」欄に記載される稼働状態の判断基準は、予め業務やリソースの種類に応じて設定される。例えば、人的リソースであれば、全員で１０名のスタッフのうち、稼働人数が８名以上であれば「Ｇｒｅｅｎ」、５名以下であれば「Ｒｅｄ」等としたり、特定の人物が稼働可能であれば「Ｇｒｅｅｎ」、稼働できなければ「Ｏｒａｎｇｅ」等のように、具体的な実情に合わせて設定される。

図５に示す稼働状態入力画面１００Ｃの「チェック」欄には、ラジオボタン等の排他的な選択を行うためのオブジェクトが設けられている。現場用端末装置１００の使用者（現場担当者）は、「説明」欄の記載に基づいて、リソースの現在の状態が稼働状態のどの段階（ステータス）に該当するかを判断する。そして、該当するステータスの「チェック」欄をチェックする操作（例えば、「チェック」欄をタッチする操作等）を行うことにより、チェックされた「ステータス」が、そのリソースの稼働状態として指定される。図５に示す例では、「Ｙｅｌｌｏｗ」が指定されている（以下、４段階のステータスの何れかに特定された稼働状態の情報を「ステータス情報」と呼ぶ）。

上記のようにして、リソースのステータス情報が入力されると、ユーザ・インターフェイス制御部１３０は、操作対象のリソースと指定されたステータス情報および操作が行われた日時の情報とを関連付けて、リソース情報記憶部１５０に格納する。この後、画像表示部１１０の表示がリソース状態確認画面１００Ｂに移行すると、稼働状態入力画面１００Ｃで入力されたステータス情報が反映された画面が表示されることとなる。例えば、図４に示したリソース状態確認画面１００Ｂでは、「派遣スタッフ」の「ステータス」欄および「更新日時」欄が空欄になっていたが、図５に示したようにリソース「派遣スタッフ」のステータス情報が入力された後は、「派遣スタッフ」の「ステータス」欄には稼働状態が「Ｙｅｌｌｏｗ」であることを示すマークが記載され、「更新日時」欄には情報の入力操作が行われた日時が記載される。また、リソース情報記憶部１５０に格納されたリソースの情報（ステータス情報および更新日時の情報）は、例えば、図３に示したメニュー画面１００Ａの「通知」ボタンにタッチすることにより、現場用端末装置１００の個体識別情報と共に、管理サーバ２００へ送信される。これにより、リソースの稼働状態（ステータス）が管理サーバ２００へ報告される。

図６は、復旧管理画面１００Ｄの構成例を示す図である。
図３に示したメニュー画面１００Ａで「復旧情報」ボタンにタッチすると、ユーザ・インターフェイス制御部１３０により、復旧管理画面１００Ｄが呼び出されて、画像表示部１１０に表示される。図示の復旧管理画面１００Ｄには、「該当ステータス」、「タイトル」、「復旧対象」、「チェックイン」、「終了時刻」の各表示欄が設けられている。この復旧管理画面１００Ｄには、ステータス情報が「Ｇｒｅｅｎ」に該当するリソース以外のリソースに関する情報が表示される。ステータス情報が「Ｇｒｅｅｎ」に該当するリソースについては、復旧のための対策を実施する必要がないため、復旧管理画面１００Ｄには表示されない。

「該当ステータス」欄には、復旧対象となるリソースのステータス情報（稼働状態）が表示される。図６に示す例では、ステータス情報が「Ｙｅｌｌｏｗ」であるリソースと、ステータス情報が「Ｏｒａｎｇｅ」であるリソースとが各々一つずつ存在し、ステータス情報が「Ｒｅｄ」であるリソースが二つ存在することが示されている。また、図示の例では、ステータス情報の区分に基づいて、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」の順に各リソースのエントリーがソートされている。

「タイトル」欄には、復旧対象のリソースの名称が表示される。図示の例では、１番のエントリー（ステータス情報「Ｙｅｌｌｏｗ」）のリソース名「ａａａａａ」、２番のエントリー（ステータス情報「Ｏｒａｎｇｅ」）のリソース名「ｂｂｂｂｂ」、３番のエントリー（ステータス情報「Ｒｅｄ」）のリソース名「ｃｃｃｃｃ」、４番のエントリー（ステータス情報「Ｒｅｄ）のリソース名「ｄｄｄｄｄ」が、それぞれ表示されている。

「復旧対象」欄には、自装置（現場用端末装置１００）を使用する現場担当者が復旧を担当する（復旧対象の）リソースか否かを識別するための表示が行われる。図示の例では、１番のエントリー（ステータス情報「Ｙｅｌｌｏｗ」、リソース名「ｘｘｘｘｘ」）における「復旧対象」欄に、復旧対象であることを示す記号「φ」が表示されている。また、その他のエントリーにおける「復旧対象」欄には、復旧対象でないことを示す表示（図では図形□を記載）となっている。

「チェックイン」欄には、復旧対策の実施が開始されたリソースに関して、復旧対策を実施したり、指揮したりする主体（担当者）の識別情報（例えば、氏名）が表示される。通常、ステータス情報の入力を行った現場担当者が、該当するリソースの復旧対策の実施や指揮を行うことが多い。しかし、リソースを復旧させるための対策には、専門性を要する作業等が含まれる場合もあるため、ステータス情報の入力を行った現場担当者以外の者がリソースの復旧対策の実施や指揮を行う場合もある。なお、図６に示す例では、未だ復旧対策が実施されていない状態を示しており、復旧対象である１番のエントリーの「チェックイン」欄は空欄となっている。

「終了時刻」欄には、復旧対策の実施が終了した時刻が表示される。復旧対策の実施が開始された後、終了するまでの間は、復旧対策を実施中であることを示す情報（例えば、経過時間や「進行中」の文字メッセージ等）が表示される。なお、図６に示す例では、未だ復旧対策が実施されていない状態を示しており、復旧対象である１番のエントリーの「終了時刻」欄は空欄となっている。

以上のように、本実施形態において、復旧管理画面１００Ｄおよび入力操作部１２０は、復旧対策の実施状況を表す進捗情報を入力するための進捗情報入力手段として機能する。上記のように構成された復旧管理画面１００Ｄにおいて、復旧対象となっているリソースを選択する操作（例えば、復旧対象のエントリーの適当な欄にタッチする操作等）を行うと、ユーザ・インターフェイス制御部１３０により、選択されたリソースの現在の稼働状態（ステータス）に対する対策情報確認画面１００Ｅが呼び出され、復旧管理画面１００Ｄに替えて画像表示部１１０に表示される。

図７は、対策情報確認画面１００Ｅの構成例を示す図である。
図７に示す例では、図６に示した復旧管理画面１００Ｄで選択された１番のエントリーに登録されているリソース「ａａａａａ」に関する対策情報確認画面１００Ｅが表示されている。すなわち、図示の画面は、リソース「ａａａａａ」の稼働状態が「Ｙｅｌｌｏｗ」である場合に対する対策情報確認画面１００Ｅである。図示のように、対策情報確認画面１００Ｅには、実施すべき対策の内容を記載した「説明」と、その対策を実施するのに要すると想定される時間を示す「目標時間」の二つの項目が記載されている。また、復旧対策が実施される状態となることをシステムに入力するための「チェックイン」ボタンが設けられている。

対策情報確認画面１００Ｅに表示される「説明」および「目標時間」の内容は、対策情報記憶部１６０に格納されている。対策情報記憶部１６０には、管理対象である各リソースに関して、各ステータスに応じた「説明」および「目標時間」の表示内容が格納されている。そして、復旧管理画面１００Ｄで行われたリソースを選択する操作が行われると、ユーザ・インターフェイス制御部１３０により、選択されたリソースおよびステータスに対応する情報が対策情報記憶部１６０から読み出されて、対策情報確認画面１００Ｅに表示される。

使用者（現場担当者）は、対策情報確認画面１００Ｅの「説明」の記載により、そのリソースがその稼働状態（ステータス）である場合に、リソースの復旧のために何を行えば良いかを知ることができる。また、使用者（現場担当者）は、「目標時間」の記載により、「説明」に記載された対策をいつまでに完了することが望ましいかを知ることができる。なお、この目標時間は、厳守すべき時間ではなく、目標として推奨される時間に過ぎない。対策情報確認画面１００Ｅにおける「説明」に記載される対策の内容および「目標時間」は、リソースおよびその稼働状態（ステータス）別に、予め作成しておく。したがって、同じリソースであっても、稼働状態（ステータス）が異なる場合には、「説明」に記載される対策の内容が異なる場合がある。

以上のように、本実施形態において、対策情報確認画面１００Ｅは、各リソースの稼働状態を本来の状態に復帰させるために実施すべき対策を提示する対策提示手段として機能する。図７に示した対策情報確認画面１００Ｅにおいて、使用者（現場担当者）が「チェックイン」ボタンにタッチ（チェックインの操作）すると、ユーザ・インターフェイス制御部１３０は、「チェックイン」欄にチェックインを行った担当者の情報（以下、担当者情報）と、復旧対策の実施が開始された日時（チェックインが行われた日時）の情報（以下、開始日時情報）とを、操作対象のリソースに関連付けて、リソース情報記憶部１５０に格納する。そして、ユーザ・インターフェイス制御部１３０の制御により、画像表示部１１０の表示が復旧管理画面１００Ｄに戻る。また、リソース情報記憶部１５０に格納された復旧対策の実施に関する情報（担当者情報および開始日時情報）は、例えば、図３に示したメニュー画面１００Ａの「通知」ボタンにタッチすることにより、管理サーバ２００へ送信される。これにより、リソースの復旧対策の実施状況が管理サーバ２００へ報告される。なお、「チェックイン」ボタンにタッチされた際に特定される開始日時情報は、例えば、現場用端末装置１００の時計機能（図示せず）から取得される。

図８は、対策情報確認画面１００Ｅでチェックインの操作が行われた後の復旧管理画面１００Ｄの表示例を示す図である。
図６に示した復旧管理画面１００Ｄと比較すると、図８に示す例では、「チェックイン」欄に担当者情報であるチェックインを行った担当者の氏名（図示の例では「○○太郎」）が表示されている。また、「終了時刻」欄には、復旧対策を実施中であることを示す情報（図示の例では「進行中」の文字）が表示されている。

リソースに対する復旧対策の実施が完了したならば、担当者は、その旨をシステムに登録する。この操作は、例えば、対策情報確認画面１００Ｅを用いて行う。具体的には、図８に示した状態の復旧管理画面１００Ｄにおいて、まず、復旧対象のリソースを選択する操作を行い、画像表示部１１０の表示を対策情報確認画面１００Ｅに切り替える。

図９は、図８の状態の復旧管理画面１００Ｄから移行した対策情報確認画面１００Ｅの表示例を示す図である。
図７に示した対策情報確認画面１００Ｅと比較すると、図９に示す例では、チェックインが行われた日時（復旧対策の実施が開始された日時）を示す「スタート」、復旧対策の実施が完了した日時を示す「終了」、担当者情報を示す「チェックイン」の各項目が設けられている。このうち、既にチェックインが行われているので、「スタート」には、開始日時情報である日時（図示の例では、「2013/4/30 10:35:42」）が表示されており、「チェックイン」には、担当者情報（図示の例では、「○○太郎」）が表示されている。一方、復旧対策の実施が完了した旨の登録はこれから行うので、図示の例では、「終了」には日時が表示されていない。また、図７に示した対策情報確認画面１００Ｅに表示されていた「チェックイン」ボタンに替えて、復旧対策の実施が完了したことをシステムに入力するための「終了」ボタンが設けられている。

図９に示した対策情報確認画面１００Ｅにおいて、使用者（現場担当者）が「終了」ボタンにタッチ（終了報告の操作）すると、ユーザ・インターフェイス制御部１３０は、復旧対策の実施が終了した日時を示す情報（以下、終了日時情報）を、担当者情報および開始日時情報に関連付けて、リソース情報記憶部１５０に格納する。そして、ユーザ・インターフェイス制御部１３０の制御により、画像表示部１１０の表示が復旧管理画面１００Ｄに戻る。また、リソース情報記憶部１５０に格納された終了日時情報は、例えば、図３に示したメニュー画面１００Ａの「通知」ボタンにタッチすることにより、関連する担当者情報等と共に、管理サーバ２００へ送信される。これにより、リソースの復旧対策の実施状況（実施の完了）が管理サーバ２００へ報告される。なお、「終了」ボタンにタッチされた際に特定される終了日時情報は、例えば、現場用端末装置１００の時計機能（図示せず）から取得される。

図１０は、対策情報確認画面１００Ｅで終了報告の操作が行われた後の復旧管理画面１００Ｄの表示例を示す図である。
図８に示した復旧管理画面１００Ｄと比較すると、図１０に示す例では、「終了時刻」欄に、図８で表示されていた「進行中」に替えて、文字終了日時情報である日時（図示の例では、「2013/4/30 11:55:34」）が表示されている。

なお、上記の例では、復旧管理画面１００Ｄにおいて、入力操作部１２０を操作してステータス情報が入力されたリソースに関して、「復旧対象」欄に復旧対象であることを示す表示を行った。これは、あるリソースに関して、現場担当者が自身の現場用端末装置１００を用いてステータス情報を入力した場合、その現場担当者は、そのリソースに関する復旧対策を実施したり、指揮したりする立場である可能性が高いことに鑑みたものである。一方、リソースを復旧させるための対策には、専門性を要する作業が含まれる場合等もあるため、現場担当者自身がリソースの復旧対策の実施や指揮を行わない場合もあり得る。また反対に、現場担当者が、自身がステータス情報を入力したリソースとは異なるリソースの復旧対策の実施や指揮を行うことも考えられる。そこで、復旧管理画面１００Ｄにおいて、復旧対象のリソースを任意に選択して入力できるように構成しても良い。さらに、担当者情報についても、チェックインを行った担当者以外の復旧対策の作業者等の情報を入力可能な構成としても良い。

＜管理サーバの機能構成＞
図１１は、管理サーバ２００の機能構成例を示す図である。
図１１に示すように、本実施形態の管理サーバ２００は、対策情報格納部２１０と、通信制御部２２０と、稼働情報管理部２３０とを備える。

対策情報格納部２１０は、管理対象である各業務に関して、個々の業務を稼働させるために必要不可欠なリソースの稼働状態（ステータス）の定義情報および稼働状態に応じて設定された実施すべき対策の情報を保持する。また、各対策を実施する場合に、完了するまでに要すると予想される時間を目標時間（図７参照）として保持する。この対策情報格納部２１０は、メモリや磁気ディスク装置等による不揮発性の記憶手段により実現される。上述した現場用端末装置１００の対策情報記憶部１６０には、少なくとも、自装置の使用者である現場担当者が担当すべきリソース（またはそのリソースと同じ業務に属す各リソース）に関する情報が記憶されていれば良い。これに対し、管理サーバ２００の対策情報格納部２１０は、本実施形態の業務復旧支援システムの管理対象となっている全ての業務について、それらの業務を稼働させるために必要不可欠な各リソースの稼働状態に関する情報を保持する必要がある。現場用端末装置１００の対策情報記憶部１６０に記憶される情報は、管理サーバ２００の対策情報格納部２１０に格納されている情報の一部を抽出して提供するようにしても良い。

通信制御部２２０は、ネットワーク４００を介して現場用端末装置１００と接続し、データ交換を行う。具体的には、各現場用端末装置１００から送信されたリソースの稼働状態の情報を受信する。また、各現場用端末装置１００から受信したリソースの稼働状態の情報を、その情報を送信した現場用端末装置１００以外の現場用端末装置１００に配信する。また、特に図示しないが、通信制御部２２０は、管理用端末装置３００と接続してデータ交換を行う。管理サーバ２００は、この通信制御部２２０により現場用端末装置１００や管理用端末装置３００と情報の送受信を行うためのネットワーク・インターフェイスを備える。

稼働情報管理部２３０は、通信制御部２２０により現場用端末装置１００から受信したリソースの情報を、業務およびリソースごとに分類して、磁気ディスク装置等の記憶手段に保持する。具体的には、現場用端末装置１００から情報を受信したリソースごとに、情報を入力（送信）した現場用端末装置１００の個体識別情報、ステータス情報、更新日時の情報、担当者情報、開始日時情報および終了日時情報などを、現場用端末装置１００から取得して、記憶手段に格納する。

＜管理用端末装置の機能構成＞
図１２は、管理用端末装置３００の機能構成例を示す図である。
図１２に示すように、本実施形態の管理用端末装置３００は、画像表示部３１０と、入力操作部３２０と、稼働情報取得部３３０と、稼働情報編集出力部３４０とを備える。

画像表示部３１０は、例えば液晶ディスプレイ等のディスプレイ装置により実現され、各種の画面を表示する。本実施形態では、各業務におけるリソースや業務自体の稼働状態を確認するための画面や、業務の復旧の進捗状況を確認するための画面が表示される。

入力操作部３２０は、使用者（管理者）が制御コマンド等の入力操作を行うための入力デバイスである。具体的には、マウス等のポインティング・デバイスやキーボード等が用いられる。使用者（管理者）は入力操作部３２０を操作して、管理サーバ２００から必要な情報を取得し、編集して画像表示部３１０に表示させることができる。

稼働情報取得部３３０は、入力操作部３２０の操作により入力された制御コマンドにしたがって、管理サーバ２００から管理対象のリソースに関する情報を取得する。具体的には、管理サーバ２００の稼働情報管理部２３０により管理されている各リソースについての、ステータス情報、更新日時の情報、担当者情報、開始日時情報および終了日時情報を取得する。また、必要に応じて、対策情報格納部２１０に格納されている復旧対策の情報も取得する。また、特に図示しないが、管理用端末装置３００は、この稼働情報取得部３３０により管理サーバ２００から情報を取得するためのインターフェイスを備える。

稼働情報編集出力部３４０は、稼働情報取得部３３０により取得したリソースの情報に基づき、各リソースの稼働状態の管理画面や、業務の復旧状況の管理画面を生成し、画像表示部３１０に表示させる。各画面の詳細については後述する。

＜管理サーバおよび管理用端末装置による業務単位でのリソース管理＞
次に、管理サーバ２００および管理用端末装置３００によるリソース管理の例について説明する。
本実施形態では、リソース管理のために、ダッシュボード画面３００Ａ、稼働状態提示画面３００Ｂ、復旧状況確認画面３００Ｃ、チェックイン確認画面３００Ｄの４種類の画面を用意する。これらの画面は、管理サーバ２００から取得した情報に基づいて、管理用端末装置３００の稼働情報編集出力部３４０が生成し、画像表示部３１０に表示させる。

図１３は、ダッシュボード画面３００Ａの構成例を示す図である。
ダッシュボード画面３００Ａは、管理対象の業務全体の稼働状態を把握するための画面である。図１３に示す例では、業務全体（図では「全社」と記載）を対象とする情報として、稼働状態（ステータス）と、チェックイン数（復旧対策の実施にかかっている人数）とが表示されている。また、業務別の情報として、稼働状態（ステータス）と、業務に属す各リソースの稼働状態（ステータス）と、復旧対策として実施される作業手順のうち完了した作業の数（完了作業数）と、復旧対策としての全ての作業を完了するまでの目標日時と、チェックイン数とが表示されている。図示の例において、各リソースのステータスは、表示されたリソース名を囲む枠内をステータスの種類に合わせた色（緑色、黄色、橙色、赤色のいずれか）で塗りつぶすことで表現されている。

図示の例では、管理対象の個々の業務として、「物流」、「工場」、「品質」の３種類が記載されているが、これらは例示に過ぎない。管理対象の全ての業務をダッシュボード画面３００Ａ上に一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各業務を表示できるようにする。また、各業務に属すリソースは３種類ずつ（図示の例では、いずれも「スタッフ」、「オフィス」、「ＩＴサーバ」）が記載されているが、これも例示に過ぎない。各事業における全てのリソースをダッシュボード画面３００Ａ上に一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各リソースを表示できるようにする。

本実施形態において、業務全体のステータスおよび業務ごとの「ステータス」は、図４を参照して説明したリソースのステータスと同様に、「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」の４段階で示される。業務ごとのステータスは、その業務に属すリソースのステータスに基づいて決定され、業務全体のステータスは、業務ごとのステータスに基づいて決定される。具体的には、各業務のステータスは、その業務に属すリソースのステータスのうちで、最下位のステータスとなる。これは、業務の稼働状態は、その業務を遂行するために不可欠な個々のリソースの稼働状態よりも高い状態にはなり得ないからである。図１３に示す例では、業務「物流」には、「スタッフ」、「オフィス」、「ＩＴサーバ」の３種類のリソースが示されており、各リソースのステータスは、「スタッフ」および「ＩＴサーバ」が「Ｇｒｅｅｎ」であり、「オフィス」が「Ｙｅｌｌｏｗ」である。したがって、業務「物流」のステータスは、リソースのステータスのうちで最下位のステータスである「Ｙｅｌｌｏｗ」となっている。同様に、業務「工場」では、リソースのステータスのうちで最下位のステータスである「Ｏｒａｎｇｅ」となっている。また、業務「品質」では、全てのリソースのステータスが「Ｇｒｅｅｎ」であるので、業務「品質」のステータスも「Ｇｒｅｅｎ」となっている。

また、業務全体のステータスは、各業務のステータスのうちで、最下位のステータスとなる。これは、業務全体の稼働状態は、個々の業務の稼働状態よりも高い状態にはなり得ないからである。図１３に示す例では、上記のように、業務「物流」のステータスが「Ｙｅｌｌｏｗ」、業務「工場」のステータスが「Ｏｒａｎｇｅ」、業務「品質」のステータスが「Ｇｒｅｅｎ」であるので、業務全体のステータスは、これらのうちで最下位のステータスである「Ｏｒａｎｇｅ」となっている。

図１３に示すダッシュボード画面３００Ａにおいて、「チェックイン」は、「実際にチェックインしている人数／チェックイン可能な人数」で表される。ここで、図１３を参照すると、業務「物流」では、チェックイン可能な３人のうち、３人がチェックインしていることがわかる。同様に、業務「工場」では、チェックイン可能な１０人のうち、９人がチェックインしており、業務「品質」では、チェックイン可能な３人のうち、３人がチェックインしていることがわかる。そして、業務全体では、チェックイン可能な１２人のうち、１０人がチェックインしていることがわかる。ここで、各業務のチェックイン可能な人数の総数が１６人（＝３人＋１０人＋３人）であり、業務ごとのチェックインしている人数の総数が１５人（＝３人＋９人＋３人）であり、業務全体のチェックイン数とは値が異なっている。これは、各業務におけるチェックイン可能な担当者が部分的に重複していることを意味している。例えば、業務「工場」と業務「品質」の両方でチェックイン可能な担当者が両方の業務に関してチェックインしているような場合である。

図１３に示すダッシュボード画面３００Ａにおいて、「完了作業数」は、業務のステータスを現在の状態から「Ｇｒｅｅｎ」に復帰させるまでに実施すべき作業の数および進捗状況を示す。図１３に示す例では、「すでに実施した作業の数／実施すべき全作業数」で表されている。例えば、業務「物流」は、ステータス「Ｙｅｌｌｏｗ」からステータス「Ｇｒｅｅｎ」に復帰させるために実施すべき全作業の数が「５」であり、そのうち三つの作業が完了していることがわかる。

図１３に示すダッシュボード画面３００Ａにおいて、「目標日時」は、業務のステータスを「Ｇｒｅｅｎ」に復帰させる目標の日時を示す。この日時は、例えば、業務に属す各リソースの開始日時情報と、リソースおよびそのステータス情報に基づいて特定される目標時間の情報とに基づいて算出される。一例として具体的には、業務に属す各リソースの開始日時情報のうちで最も早い日時を基準とし、各リソースの目標時間の総和に相当する時間が経過した日時を目標日時とすることができる。

図１４は、稼働状態提示画面３００Ｂの構成例を示す図である。
図１４に示す例では、稼働状態提示画面３００Ｂに、業務「物流」に関してリソースの稼働状態に関する情報が表示されている。画面には、業務「物流」を遂行するために不可欠な「リソース」が並べて記載され、各「リソース」に関して、「ステータス」、「報告者」、「報告日時」の表示欄が設けられている。

稼働状態提示画面３００Ｂに記載される「リソース」は、業務において利用されるリソースのうち、そのリソースが稼働していないとその業務を遂行することができないような、不可欠なリソースである。すなわち、図４を参照して説明したリソース状態確認画面１００Ｂで表示される「リソース」と同様である。ただし、管理用端末装置３００の画像表示部３１０と現場用端末装置１００の画像表示部１１０の画面のサイズの差異のために、一度に表示される「リソース」の数は異なっている。また、図１３に示したダッシュボード画面３００Ａの業務別の情報には、図１４に示す「リソース」の一部が表示された状態となっている。稼働状態提示画面３００Ｂにおいても業務の遂行に不可欠なリソースの全てを一度に表示できない場合は、例えば、スクロール等で画面の表示範囲を移動させることにより、各リソースを表示できるようにすることができる。

また、稼働状態提示画面３００Ｂに記載される「ステータス」は、図４を参照して説明したリソースのステータスと同様に、「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」の４段階で示される。このステータスの情報は、現場用端末装置１００において入力され、管理サーバ２００により収集された、各リソースのステータス情報に基づいている。図１３に示したダッシュボード画面３００Ａにおける各リソースのステータスには、この稼働状態提示画面３００Ｂで表示される「ステータス」が反映されている。具体的には、図１４に示す例では、リソース「オフィス」のステータスが「Ｙｅｌｌｏｗ」、その他のリソースのステータスが全て「Ｇｒｅｅｎ」となっており、図１３に示す例においても、業務「物流」におけるリソース「スタッフ」、「オフィス」、「ＩＴサーバ」のステータスの表示と一致している。

また、稼働状態提示画面３００Ｂに記載される「報告者」は、該当するリソースのステータス情報を入力した現場用端末装置１００の使用者（現場担当者）を示す。この表示内容は、現場用端末装置１００において入力され、管理サーバ２００により収集された、各リソースのステータス情報を入力した現場用端末装置１００の個体識別情報に基づいている。なお、図１４に示す例では、リソース「社員」の報告者が「安否確認システム」となっている。これは、例えば、管理サーバ２００に設けられた機能（「安否確認システム」）によりステータス情報が入力されたことを示す。このリソース「社員」のステータスは、例えば、上記の担当者情報等に基づき、チェックイン可能な人数の総数と実際にチェックインしている人数との割合や、特定の担当者がチェックインしているか否か等に基づいて特定される。

また、稼働状態提示画面３００Ｂに記載される「報告日時」は、該当するリソースのステータス情報が入力された日時を示す。この表示内容は、現場用端末装置１００において入力され、管理サーバ２００により収集された、各リソースにおけるステータス情報の更新日時の情報に基づいている。

図１５は、復旧状況確認画面３００Ｃの構成例を示す図である。
図１５に示す例では、復旧状況確認画面３００Ｃに、業務「物流」のリソース「オフィス」に関して稼働状態の復旧状況を示す情報が表示されている。画面には、業務「物流」のリソース「オフィス」のステータスごとに、「対策」、「チェックイン」、「目標日時」、「完了日時」、「遅延」の各項目が表示されている。また、この復旧状況確認画面３００Ｃには、「Ｇｒｅｅｎ」以外のステータスに関する情報が表示される。ステータスが「Ｇｒｅｅｎ」である場合は、復旧のための対策を実施する必要がないためである。

図１５に示す復旧状況確認画面３００Ｃでは、ステータス「Ｙｅｌｌｏｗ」のエントリーが２個、ステータス「Ｏｒａｎｇｅ」のエントリーが２個、ステータス「Ｒｅｄ」のエントリーが２個、それぞれ表示されている。したがって、ステータスが「Ｙｅｌｌｏｗ」のときに実施すべき対策が二つあることがわかる。この二つの対策が完了すると、リソース「オフィス」の稼働状態は「Ｙｅｌｌｏｗ」に該当する状態から「Ｇｒｅｅｎ」に該当する状態へ復帰する。

同様に、ステータスが「Ｏｒａｎｇｅ」のときに実施すべき対策は二つである。この二つの対策が完了すると、リソース「オフィス」の稼働状態は「Ｏｒａｎｇｅ」に該当する状態から「Ｇｒｅｅｎ」に該当する状態へ復帰する。

同様に、ステータスが「Ｒｅｄ」のときに実施すべき対策は二つである。この二つの対策が完了すると、リソース「オフィス」の稼働状態は「Ｒｅｄ」に該当する状態から「Ｇｒｅｅｎ」に該当する状態へ復帰する。

図１５に示す復旧状況確認画面３００Ｃの「対策」には、該当する各ステータスのときに実施すべき対策の内容が表示される。この情報は、管理サーバ２００の対策情報格納部２１０から取得される。また、対策の内容は、該当するリソースおよびステータスに関する、図７に示した対策情報確認画面１００Ｅの「説明」欄の記載内容と同様である。

図１５に示す復旧状況確認画面３００Ｃの「チェックイン」には、該当する対策を実施するためにチェックインを行った担当者の氏名が表示される。この情報は、現場用端末装置１００において入力され、管理サーバ２００により収集された、担当者情報（図８参照）に基づいている。なお、図示の例において、チェックインが行われていない２番のエントリーには、「未」の文字が表示されている。

図１５に示す復旧状況確認画面３００Ｃの「目標日時」には、該当する対策の実施を完了する目標となる日時が表示される。この情報は、現場用端末装置１００において入力され、管理サーバ２００により収集された開始日時情報と、管理サーバ２００の対策情報格納部２１０に保持されている該当作業の目標時間の情報とに基づいて算出される。なお、図示の例において、チェックインが行われていない２番のエントリーには、開始日時情報が存在しないため、目標時間の値（「１時間」）がそのまま表示されている。

図１５に示す復旧状況確認画面３００Ｃの「完了日時」には、該当する対策の実施が実際に完了した日時が表示される。この情報は、現場用端末装置１００において入力され、管理サーバ２００により収集された終了日時情報に基づいている。なお、図示の例において、対策の実施が開始されているが、完了していない場合は「進行中」、対策の実施が開始されていない場合は「未着手」の文字が、それぞれ表示されている。また、復旧状況確認画面３００Ｃの「遅延」には、対策の実施の完了前に「目標日時」に表示された日時を経過してしまった場合に、「目標日時」以降の経過時間が表示される。

以上により、図１５に示す復旧状況確認画面３００Ｃによれば、１番のエントリー（ステータス「Ｙｅｌｌｏｗ」）の対策は、担当者「○○太郎」によりチェックインされており、目標日時が「2013/4/30 10:00」であり、対策の実施が完了していないが、遅延は発生していない、ということがわかる。同様に、２番のエントリー（ステータス「Ｙｅｌｌｏｗ」）の対策は、チェックインが行われておらず、対策の実施が未だ開始されていないこと、対策を実施するには１時間を要すること、がわかる。

図１６は、チェックイン確認画面３００Ｄの構成例を示す図である。
チェックイン確認画面３００Ｄは、業務単位でのチェックインの状況を管理するための画面である。図１６に示す例では、業務ごとにチェックインの状況を示す情報（「チェックイン数」、「総数」、「チェックイン率」）が表示されている。また、個々の業務に関して、チェックインした担当者の情報（「氏名」、「チェックイン日時」、「チェックアウト日時」）が表示される。なお、担当者の情報については、図１６に示す例では、業務「物流」の担当者の情報のみが表示されている。これらの情報の全てをチェックイン画面上に一度に表示できない場合は、例えば、所定の操作により個々の業務における担当者の情報の表示を切り替えたり、スクロール等で画面の表示範囲を移動させたりする機能を設けて、各情報を表示できるようにする。

＜対策情報の具体例＞
ここで、管理サーバ２００の対策情報格納部２１０に格納される情報（以下、対策情報）について、具体例を挙げて、さらに詳細に説明する。ここでは、対象業務の一例として、お客様窓口の業務を考える。

図１７は、お客様窓口業務に関する対策情報の例を示す図である。
図１７に示す例では、お客様窓口業務を遂行するために不可欠なリソースとして、「本社オペレータ」、「本社オフィス」、「地方オフィス」、「提携先オフィス」、「電話・ＰＣ」、「イントラ、データベースシステム」、「本社・基盤設備」の７種類のリソースが設定されている。すなわち、これら７種類のリソースの全てが稼働している場合（「Ｒｅｄ」以外のステータスである場合）に、お客様窓口業務が稼働している状態となる。なお、図示の例では、「本社オフィス」、「地方オフィス」、「提携先オフィス」の三つのリソースを「オフィス」という分類にまとめ、全体を「スタッフ」、「オフィス」、「設備」、「システム」、「インフラ」の５種類に分類している。

各リソースには、「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」の４段階のステータスが設定されている。例えば、図１７の例におけるリソース「本社オペレータ」について参照すると、オペレータが平時の出社率である場合に、ステータスは「Ｇｒｅｅｎ」である。また、出社率が平時よりも少ないが、出社可能人数が回線数＋４以上である場合に、ステータスは「Ｙｅｌｌｏｗ」である。また、出社可能人数が回線数＋４よりも少ないが、回線数以上である場合には、ステータスは「Ｏｒａｎｇｅ」である。また、出社可能人数が回線数よりも少ない場合は、ステータスは「Ｒｅｄ」である。

また、リソース「本社オペレータ」の稼働が低下した場合の対策として、ステータスが「Ｙｅｌｌｏｗ」である場合、「Ｏｒａｎｇｅ」である場合および「Ｒｅｄ」である場合について、それぞれ設定される。なお、ステータスが「Ｇｒｅｅｎ」である場合は、通常業務が行われるため、地方オペレータによる業務支援は行われない。

図１８は、リソース「本社オペレータ」の稼働低下時の対策として設定された、地方オペレータによる業務支援の具体的な内容の例を示す図である。
図１８に示す例では、ステータスが「Ｙｅｌｌｏｗ」の場合に実施すべき対策として、三つの作業（アクション）が設定されている。各作業に対しては、目標時間（アクションごとの目標時間）としてそれぞれ「１時間」が設定されている。したがって、ステータスが「Ｙｅｌｌｏｗ」の場合に実施すべき対策を全て実施するための目標時間（トータルの目標時間）は「３時間」となっている。同様に、ステータスが「Ｏｒａｎｇｅ」の場合に実施すべき対策として、二つの作業（アクション）が設定されており、アクションごとの目標時間としてそれぞれ「１時間」が設定され、トータルの目標時間が「２時間」となっている。また、ステータスが「Ｒｅｄ」の場合に実施すべき対策として、二つの作業（アクション）が設定されており、アクションごとの目標時間としてそれぞれ「１時間」が設定され、トータルの目標時間が「２時間」となっている。

また、特に図示しないが、本実施形態では、図１７に示した各リソースにおけるステータスごとの対策に関して、図１８に示すように具体的な作業が設定される。したがって、個々のリソースに関して、図１７に示した基準に則ってステータスが特定されれば、本来の稼働状態（「Ｇｒｅｅｎ」）のリソース以外のリソースに関し、ステータスを「Ｇｒｅｅｎ」にするために実施すべき対策が確定する。

＜管理サーバおよび管理用端末装置による業務管理＞
次に、管理サーバ２００および管理用端末装置３００による業務管理の例について説明する。
本実施形態では、上記のようにして収集され、管理される業務ごとのリソースの稼働状態に関する情報に基づき、１または複数の組織（企業等）による複数の業務の稼働状態を管理することができる。本実施形態では、業務管理のために、稼働レベル管理画面３００Ｅを用意する。これらの画面は、管理サーバ２００から取得した情報に基づいて、管理用端末装置３００の稼働情報編集出力部３４０が生成し、画像表示部３１０に表示させる。

図１９〜図２５は、稼働レベル管理画面３００Ｅの構成例を示す図である。
稼働レベル管理画面３００Ｅは、管理対象の複数の業務における管理対象の全てのリソースの稼働状態を提示すると共に、このリソースの稼働状態に基づいて判断される業務自体の稼働状態を提示する画面である。また、この稼働レベル管理画面３００Ｅは、各リソースおよび業務の稼働状態に基づいて、現在稼働していないリソースや業務の復旧（稼働再開）時刻の予測（復旧予測）結果を提示する。本実施形態では、管理対象の業務を遂行するために必要なリソースが管理対象のリソースとして設定されるため、リソースの稼働状態の情報を収集することにより、そのリソースを含む業務の稼働状態を把握することができる。したがって、リソースの復旧予測に基づき、そのリソースが含まれる業務の復旧予測を行うことが可能となる。図１９〜図２５に示す例において、稼働レベル管理画面３００Ｅには、管理対象である業務およびリソースを一覧する管理項目欄３０１と、業務およびリソースの復旧予測結果を表示する稼働状態グラフ３０２とが表示されている。

図１９〜図２５に示す例において、管理項目欄３０１に表示される「業務」および「リソース」の各項目の表示には、各々のステータスが反映される。ここでは、「リソース」の各項目は、まず、ステータス（「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」）ごとにソートされ、各ステータスにおいて、さらに「業務」ごとにソートされる。具体的には、各リソースは、ステータスが「Ｒｅｄ」のリソース、「Ｏｒａｎｇｅ」のリソース、「Ｙｅｌｌｏｗ」のリソース、「Ｇｒｅｅｎ」のリソースの順に上から並べられる。また、「業務」の各項目は、その業務に属す全てのリソースのステータスのうちで最下位のステータスが反映される。したがって、例えば、ある業務についてステータスが「Ｒｅｄ」のリソースが一つでも存在するときは、その「業務」の項目全体が「Ｒｅｄ」となる。

また、図１９〜図２５に示す例において、稼働状態グラフ３０２には、縦軸を管理項目欄３０１に表示した「リソース」の数、横軸を時間として、現在時点で確認されているステータスごとのリソースの数を示すと共に、時間経過に伴って各リソースのステータスが変化する様子（予測結果）を示すグラフが表示される。図示の例では、横軸方向の１単位を１時間として、現在の３時間前から１６時間後までの各リソースにおけるステータスの様子とが表示される。以下、障害の発生およびその後の時間経過に伴う稼働レベル管理画面３００Ｅの表示の変化の具体例を、図１９〜図２５を参照して説明する。

図１９は、障害の発生前における稼働レベル管理画面３００Ｅの状態を例示する図である。
図１９に示す例において、管理項目欄３０１の「業務」には、上から順に、「業務コミュニケーション」、「業務アプリケーション」、「業務支払」、「業務お客様窓口」、「業務品質管理」、「業務物流」の６種の業務が表示されている。また、「リソース」には、各業務に対応付けて、管理対象（すなわち、各業務を遂行するために不可欠なものとして設定されたリソース）として、４１個（業務ごとに６個から８個）のリソースが表示されている。

管理項目欄３０１における各業務およびリソースの配置（順番）は、平常時においては特に限定されないが、例えば図１９に示すように、業務ごとにリソースを並べることで、視認性を高めることができる。また、障害発生後は、後述するように、各リソースを「Ｇｒｅｅｎ」、「Ｙｅｌｌｏｗ」、「Ｏｒａｎｇｅ」、「Ｒｅｄ」のステータスの順に下から上へ積み上がるように並べる。さらに、ステータスが「Ｏｒａｎｇｅ」のリソースおよび「Ｒｅｄ」のリソースにおいては、平常時の稼働状態（ステータス「Ｙｅｌｌｏｗ」以上）に復帰すると予想される時間（以下、復旧予定時間）の長いものが上に位置するように配置される。これにより、復旧したリソースや稼働していないリソースの数の認識が容易となり、復旧の度合いを直感的に把握し易くなる。

図１９に示す稼働レベル管理画面３００Ｅは、障害の発生前の状態であるので、表示される各業務および各リソースのステータスは、全て「Ｇｒｅｅｎ」となっている。稼働状態グラフ３０２においては、３時間前から現在までの全リソースのステータスが「Ｇｒｅｅｎ」であるだけでなく、障害発生前であるので、予測としての将来のステータス（稼働状態グラフ３０２において、「現在」の時点よりも右側の領域）においても「Ｇｒｅｅｎ」となっている。

図２０は、障害発生時の稼働レベル管理画面３００Ｅの状態を例示する図である。
リソースや業務の正常な稼働が妨げられるような障害が発生すると、各リソースの稼働状態を確認し、稼働レベルが低下したリソースを復旧させることが必要となる。本実施形態では、予め設定された事象（例えば、所定の規模以上の自然災害や事故等）が発生した場合に、これを契機として、現場用端末装置１００を用いたリソースに関する情報の収集を実行する。このとき、管理用端末装置３００に表示される稼働レベル管理画面３００Ｅは、一度、全ての情報が未入力の状態となる。図示の例では、管理項目欄３０１の全ての「業務」および「リソース」が、通常時とは異なる表示態様で表示され、情報が未入力であることを示している。また、稼働状態グラフ３０２においても、全ての時間、全てのリソースにおいて、情報が未入力（「情報なし」）であることを示す表示となっている。

さらに、リソースの情報の収集を開始すると、稼働状態グラフ３０２には、リソースおよび業務の復旧時の予測結果を示す復旧予測ラインが表示される。ここで、リソースに関しては、平常時の稼働状態にまで稼働レベルを戻すことを目標とするので、ステータスが「Ｙｅｌｌｏｗ」以上となる位置にリソースの復旧予測ラインが設定される。一方、業務に関しては、例えいくつかのリソースにおいて稼働レベルが低下していても、その業務に属す全てのリソースが稼働している状態となれば、業務自体の稼働は再開される。したがって、ステータスが「Ｏｒａｎｇｅ」以上となる位置に業務の復旧予測ラインが設定される。本実施形態では、業務の復旧予測ラインを破線で示し、リソースの復旧予測ラインを色の薄い実線で示すこととする。図２０の例では、未だ全てのリソースに関して、稼働状況の情報が取得されていないので、リソースの復旧予測ラインは表示されておらず、業務の復旧予測ライン３０３のみが表示されている。また、図２０において、業務の復旧予測ライン３０３は、現在（０ｈ）以降の全ての時点で復旧業務「０」に設定されている。

図２１は、障害発生から１５分経過後の稼働レベル管理画面３００Ｅの状態を例示する図である。
この時点までに、業務「業務アプリケーション」と業務「業務コミュニケーション」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄３０１を参照すると、業務「業務アプリケーション」に関しては、リソース「電気」、「本社オフィス」、「アプリ担当社員」が平常時通り稼働しており（ステータス「Ｇｒｅｅｎ」）、リソース「ＰＣ」は稼働レベルが低下しているが稼働している状態であり（ステータス「Ｏｒａｎｇｅ」）、リソース「アプリサーバ」、「公衆通信回線」は稼働していない状態である（ステータス「Ｒｅｄ」）。そして、リソース「社員自宅」については、未だ情報が取得されていない。また、業務「業務コミュニケーション」に関しては、リソース「電気」、「本社オフィス」、「イントラ担当社員」、「ＰＣ」が平常時通り稼働しており（ステータス「Ｇｒｅｅｎ」）、リソース「イントラネット」、「サポート担当社員」は稼働していない状態である（ステータス「Ｒｅｄ」）。そして、リソース「社員自宅」については、未だ情報が取得されていない。いずれの業務も、ステータスが「Ｒｅｄ」のリソースが存在するので、業務自体のステータスは「Ｒｅｄ」となっている。

なお、リソース「社員自宅」は、リソース「本社オフィス」と補完関係にあり、いずれか一方が稼働していれば、業務の稼働を保証する。したがって、ここでは、業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも、リソース「本社オフィス」が平常時通り稼働しているので（ステータス「Ｇｒｅｅｎ」）、業務が稼働を再開するために、リソース「社員自宅」が稼働することは必要としない。

次に、稼働状態グラフ３０２を参照すると、まず、事象の発生時である現在（０ｈ）以前の３時間については、事象発生前のステータス（「Ｇｒｅｅｎ」）に戻されている。そして、現在（０ｈ）の表示は、管理項目欄３０１の「リソース」の表示が反映され、７個のリソースが「Ｇｒｅｅｎ」、１個のリソースが「Ｏｒａｎｇｅ」、４個のリソースが「Ｒｅｄ」となっている。

また、現在（０ｈ）以降の表示については、報告のあった１２個のリソースに関して、ステータスが段階的に復旧する様子（予測結果）が示されている。そして、この予測に基づいて、業務の復旧予測ライン３０３と、リソースの復旧予測ライン３０４とが表示されている。

現場用端末装置１００の説明等において既に述べたように、個々のリソースについてステータスが特定されれば、そのリソースを復旧させるために実施すべき対策は特定される。そして、現場用端末装置１００の対策情報確認画面１００Ｅ（図７、図９参照）における「目標時間」、管理用端末装置３００のダッシュボード画面３００Ａ（図１３参照）や復旧状況確認画面３００Ｃ（図１５参照）における「目標日時」に示したように、実施すべき対策が特定されると、その実施に要する時間が決まる。そして、これらの情報に基づき、各リソースについて、復旧予定時間が算出される。

ここでは、ステータスが「Ｏｒａｎｇｅ」である業務「業務アプリケーション」のリソース「ＰＣ」の復旧予定時間は、現在（０ｈ）から４時間後であるものとする。このため、図２１に示す稼働状態グラフ３０２における４ｈの位置で、１個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。一方、ステータスが「Ｒｅｄ」である４個のリソースの復旧予定時間は、全て現在（０ｈ）から６時間後であるものとする。このため、図２１に示す稼働状態グラフ３０２における６ｈの位置で、４個のリソースのステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。そして、各リソースのステータスが「Ｇｒｅｅｎ」に移行する位置に沿って、リソースの復旧予測ライン３０４が表示されている。

業務に関しては、業務に属すリソースの一つでも稼働していない（ステータスが「Ｒｅｄ」）ときは、その業務は稼働しないが、業務に属す全てのリソースが稼働状態となれば、業務自体の稼働も再開されるので、現在（０ｈ）から６時間後には、今回報告された業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも復旧する。なお、上述したように、これらの業務が稼働するためには、リソース「社員自宅」の稼働は必要ない。したがって、業務の復旧予測ライン３０３は、６ｈの位置まで復旧業務「０」に設定されており、６ｈ以降は、各業務に属すリソースの数「１４」に設定されている。なお、上述したように、これらの業務が稼働するためには、リソース「社員自宅」の稼働は必要ない。したがって、業務の復旧予測ライン３０３は、情報が取得されているリソースの数「１２」ではなく、業務に属す全てのリソースの数「１４」に設定される。

図２２は、障害発生から３０分経過後の稼働レベル管理画面３００Ｅの状態を例示する図である。
この時点までに、業務「業務お客様窓口」と業務「業務支払」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄３０１を参照すると、業務「業務お客様窓口」に関しては、リソース「業務サーバ」、「外部委託業者」、「電話」、「本社オフィス」、「コール・システム」が平常時通り稼働しており（ステータス「Ｇｒｅｅｎ」）、リソース「オペレータ」は稼働レベルが低下しているが稼働している状態である（ステータス「Ｏｒａｎｇｅ」）。このように、業務「業務お客様窓口」は、１個のリソースのステータスが「Ｏｒａｎｇｅ」であり、その他の全てのリソースのステータスが「Ｇｒｅｅｎ」であるので、業務自体のステータスも「Ｏｒａｎｇｅ」となる。すなわち、業務自体が稼働している状態である。

また、業務「業務支払」に関しては、リソース「電気通信回線」、「本社オフィス」、「工場社員」、「工場オフィス」、「銀行印」、「決済システム」が平常時通り稼働しており（ステータス「Ｇｒｅｅｎ」）、リソース「ＰＣ」は稼働レベルが低下しているが稼働している状態であり（ステータス「Ｏｒａｎｇｅ」）、リソース「決裁権限者」は稼働していない状態である（ステータス「Ｒｅｄ」）。そして、ステータスが「Ｒｅｄ」のリソースが存在するので、業務自体のステータスは「Ｒｅｄ」となっている。

また、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソース「社員自宅」に関しては、図２２に示す時点までにステータスの報告があり、受け付けた報告に基づいてステータス「Ｇｒｅｅｎ」に切り替わったものとする。

また、管理項目欄３０１において、ステータスが「Ｏｒａｎｇｅ」である３個のリソースの位置を比較すると、稼働状態グラフ３０２を参照して後述するように復旧予定時間の長い業務「業務お客様窓口」のリソース「オペレータ」が、他の２個のリソースよりも上に配置されている。同様に、ステータスが「Ｒｅｄ」である５個のリソースの位置を比較すると、稼働状態グラフ３０２を参照して後述するように復旧予定時間の長い業務「業務支払」のリソース「決裁権限者」が、他の４個のリソースよりも上に配置されている。

次に、稼働状態グラフ３０２を参照すると、現在（０ｈ）の表示は、管理項目欄３０１の「リソース」の表示が反映され、２０個のリソースが「Ｇｒｅｅｎ」、３個のリソースが「Ｏｒａｎｇｅ」、５個のリソースが「Ｒｅｄ」となっている。

また、現在（０ｈ）以降の表示については、報告のあった２８個のリソース（業務「業務アプリケーション」および業務「業務コミュニケーション」のリソース「社員自宅」を含む）に関して、ステータスが段階的に復旧する様子（予測結果）が示されている。そして、この予測に基づいて、業務の復旧予測ライン３０３と、リソースの復旧予測ライン３０４とが表示されている。

ここでは、ステータスが「Ｏｒａｎｇｅ」である業務「業務支払」のリソース「ＰＣ」の復旧予定時間は、現在（０ｈ）から４時間後であるものとする。また、ステータスが「Ｏｒａｎｇｅ」である業務「業務お客様窓口」のリソース「オペレータ」の復旧予定時間は、現在（０ｈ）から６時間後であるものとする。また、業務「業務アプリケーション」のリソース「ＰＣ」の復旧予定時間は、図２１にも示したように、現在（０ｈ）から４時間後である。このため、図２２に示す稼働状態グラフ３０２における４ｈの位置で、２個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。また、６ｈの位置で、１個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。

一方、ステータスが「Ｒｅｄ」であるリソースのうち、業務「業務アプリケーション」および業務「業務コミュニケーション」における４個のリソースの復旧予定時間は、現在（０ｈ）から６時間後であるが、業務「業務支払」のリソース「決裁権限者」は、グラフに表示される１６時間以内には復旧しない。このため、図２２に示す稼働状態グラフ３０２における６ｈの位置で、４個のリソースのステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。そして、各リソースのステータスが「Ｇｒｅｅｎ」に移行する位置に沿って、リソースの復旧予測ライン３０４が表示されている。

業務に関しては、今回報告された業務「業務お客様窓口」は、全てのリソースのステータスが「Ｏｒａｎｇｅ」以上なので、業務自体が稼働している。そして、現在（０ｈ）から６時間後には、業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも復旧する。これに対し、業務「業務支払」は、リソース「決裁権限者」がグラフに表示される１６時間以内に復旧しないため、業務自体も１６時間以内には稼働しない。したがって、業務の復旧予測ライン３０３は、６ｈの位置までは業務「業務お客様窓口」のリソースの数である「６」に設定されており、６ｈ以降は、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソースの総数を加えた「２０」に設定されている。

図２３は、障害発生から９０分経過後の稼働レベル管理画面３００Ｅの状態を例示する図である。
この時点までに、業務「業務品質管理」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄３０１を参照すると、業務「業務品質管理」に関しては、リソース「電気」、「本社オフィス」、「社員」、「社員自宅」、「データベース」が平常時通り稼働しており（ステータス「Ｇｒｅｅｎ」）、リソース「業務機器」は稼働レベルが低下しているが稼働している状態である（ステータス「Ｏｒａｎｇｅ」）。このように、業務「業務品質管理」は、１個のリソースのステータスが「Ｏｒａｎｇｅ」であり、その他の全てのリソースのステータスが「Ｇｒｅｅｎ」であるので、業務自体のステータスも「Ｏｒａｎｇｅ」となる。すなわち、業務自体が稼働している状態である。

また、管理項目欄３０１において、ステータスが「Ｏｒａｎｇｅ」である４個のリソースの位置を比較すると、稼働状態グラフ３０２を参照して後述するように復旧予定時間の長い業務「業務お客様窓口」のリソース「オペレータ」および業務「業務品質管理」のリソース「業務機器」が、他の２個のリソースよりも上に配置されている。ステータスが「Ｒｅｄ」である５個のリソースの位置については、図２２の例と同様に、業務「業務支払」のリソース「決裁権限者」が、他の４個のリソースよりも上に配置されている。

次に、稼働状態グラフ３０２を参照すると、図２３では、障害発生から９０分（１時間以上）が経過しているので、グラフの表示が１単位分進んでいる（図において、左へ移動している）。すなわち、図２３の稼働状態グラフ３０２における現在（０ｈ）は、障害発生から１時間経過後である。この現在（０ｈ）の表示は、管理項目欄３０１の「リソース」の表示が反映され、２５個のリソースが「Ｇｒｅｅｎ」、４個のリソースが「Ｏｒａｎｇｅ」、５個のリソースが「Ｒｅｄ」となっている。

また、現在（０ｈ）以降の表示については、報告のあった３４個のリソースに関して、ステータスが段階的に復旧する様子（予測結果）が示されている。そして、この予測に基づいて、業務の復旧予測ライン３０３と、リソースの復旧予測ライン３０４とが表示されている。

ここでは、ステータスが「Ｏｒａｎｇｅ」である業務「業務品質管理」のリソース「業務機器」の復旧予定時間は、障害発生から６時間後であるものとする。したがって、障害発生から１時間以上が経過している図２３においては、現在（０ｈ）から５時間後である。同様に、業務「業務お客様窓口」のリソース「オペレータ」の復旧予定時間は、障害発生から６時間後であるので、図２３においては、現在（０ｈ）から５時間後である。また、業務「業務支払」のリソース「ＰＣ」および業務「業務アプリケーション」のリソース「ＰＣ」の復旧予定時間は、障害発生から４時間後であるので、図２３においては、現在（０ｈ）から３時間後である。このため、図２３に示す稼働状態グラフ３０２における３ｈの位置で、２個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。また、５ｈの位置で、２個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。

一方、ステータスが「Ｒｅｄ」であるリソースのうち、業務「業務アプリケーション」および業務「業務コミュニケーション」における４個のリソースの復旧予定時間は、障害発生から６時間なので、図２３においては、現在（０ｈ）から５時間後である。そして、業務「業務支払」のリソース「決裁権限者」は、グラフに表示される１６時間以内には復旧しない。このため、図２３に示す稼働状態グラフ３０２における５ｈの位置で、４個のリソースのステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。そして、各リソースのステータスが「Ｇｒｅｅｎ」に移行する位置に沿って、リソースの復旧予測ライン３０４が表示されている。

業務に関しては、今回報告された業務「業務品質管理」は、業務「業務お客様窓口」と同様に、全てのリソースのステータスが「Ｏｒａｎｇｅ」以上なので、業務自体が稼働している。そして、障害発生から６時間後（図２３の現在（０ｈ）から５時間後）には、業務「業務アプリケーション」と業務「業務コミュニケーション」のいずれも復旧する。これに対し、業務「業務支払」は、リソース「決裁権限者」が復旧しないため、業務自体も１６時間以内には稼働しない。したがって、業務の復旧予測ライン３０３は、５ｈの位置までは業務「業務お客様窓口」および業務「業務品質管理」のリソースの総数である「１２」に設定されており、５ｈ以降は、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソースの総数を加えた「２６」に設定されている。

図２４は、障害発生から１００分経過後の稼働レベル管理画面３００Ｅの状態を例示する図である。
この時点までに、業務「業務物流」に関して、リソースの稼働状況の報告があったものとする。この結果、管理項目欄３０１を参照すると、業務「業務物流」に関しては、リソース「電気」、「社員」、「派遣スタッフ」、「本社オフィス」、「電話」が平常時通り稼働しており（ステータス「Ｇｒｅｅｎ」）、リソース「サーバ」、「ＰＣ」は稼働していない状態である（ステータス「Ｒｅｄ」）。このように、業務「業務物流」は、２個のリソースのステータスが「Ｒｅｄ」であるので、業務自体のステータスも「Ｒｅｄ」となる。

また、管理項目欄３０１において、ステータスが「Ｏｒａｎｇｅ」である４個のリソースの位置を比較すると、図２３の例と同様に、業務「業務お客様窓口」のリソース「オペレータ」および業務「業務品質管理」のリソース「業務機器」が、他の２個のリソースよりも上に配置されている。そして、ステータスが「Ｒｅｄ」である５個のリソースの位置を比較すると、稼働状態グラフ３０２を参照して後述するように復旧予定時間の最も長い業務「業務支払」のリソース「決裁権限者」が最上位に配置され、復旧予定時間が次に長い業務「業務物流」のリソース「サーバ」およびリソース「ＰＣ」が、業務「業務支払」のリソース「決裁権限者」よりも下で、他の４個のリソースよりも上に配置されている。

次に、稼働状態グラフ３０２を参照すると、現在（０ｈ）の表示は、管理項目欄３０１の「リソース」の表示が反映され、３０個のリソースが「Ｇｒｅｅｎ」、４個のリソースが「Ｏｒａｎｇｅ」、７個のリソースが「Ｒｅｄ」となっている。

また、現在（０ｈ）以降の表示については、報告のあった４１個のリソース（稼働状態グラフ３０２に表示される全てのリソース）に関して、ステータスが段階的に復旧する様子（予測結果）が示されている。そして、この予測に基づいて、業務の復旧予測ライン３０３と、リソースの復旧予測ライン３０４とが表示されている。

ここでは、ステータスが「Ｒｅｄ」である業務「業務物流」のリソース「サーバ」および「ＰＣ」の復旧予定時間は、障害発生から１２時間後であるものとする。したがって、障害発生から１時間以上が経過している図２４においては、現在（０ｈ）から１１時間後である。この他、ステータスが「Ｏｒａｎｇｅ」である各リソースおよびステータスが「Ｒｅｄ」である各リソースの復旧時間は、それぞれ図２３の例と同様である。したがって、図２４に示す稼働状態グラフ３０２における３ｈの位置で、２個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化し、５ｈの位置で、２個のリソースのステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。また、５ｈの位置で、４個のリソースのステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。さらに、１１ｈの位置で、２個のリソースのステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。また、業務「業務支払」のリソース「決裁権限者」に対応する１個のリソースのステータスが「Ｒｅｄ」の状態のまま維持される。そして、各リソースのステータスが「Ｇｒｅｅｎ」に移行する位置に沿って、リソースの復旧予測ライン３０４が表示されている。

業務に関しては、今回報告された業務「業務物流」は、図２４の現在（０ｈ）から１１時間後にリソース「サーバ」および「ＰＣ」が復旧すれば、全てのリソースが復旧し、業務が稼働する状態となる。他の業務の復旧予測に関しては、図２３について説明した通りである。したがって、業務の復旧予測ライン３０３は、５ｈの位置までは業務「業務お客様窓口」および業務「業務品質管理」のリソースの総数である「１２」に設定され、５ｈから１１ｈまでは、業務「業務アプリケーション」および業務「業務コミュニケーション」のリソースの総数を加えた「２６」に設定され、１１ｈ以降は、さらに業務「業務物流」のリソースの数を加えた「３３」に設定されている。

図２５は、障害発生から１３０分経過後の稼働レベル管理画面３００Ｅの状態を例示する図である。
この時点で、業務「業務アプリケーション」に関して、再度、リソースの稼働状況の報告があり、リソース「アプリサーバ」の復旧の見込みが立たなくなったものとする。この結果、管理項目欄３０１を参照すると、各業務および各リソースのステータスの表示は図２４の状態から変わらないが、復旧予定時間を計算できない業務「業務アプリケーション」のリソース「アプリサーバ」の表示位置が、管理項目欄３０１の最上位に移動している。

次に、稼働状態グラフ３０２を参照すると、図２５では、障害発生から１３０分（２時間以上）が経過しているので、グラフの表示が図２４の状態からさらに１単位分進んでいる（図において、左へ移動している）。すなわち、図２５の稼働状態グラフ３０２におけるの現在（０ｈ）は、障害発生から２時間経過後である。この現在（０ｈ）の表示は、管理項目欄３０１の「リソース」の表示が反映され、３０個のリソースが「Ｇｒｅｅｎ」、４個のリソースが「Ｏｒａｎｇｅ」、７個のリソースが「Ｒｅｄ」となっている。

また、現在（０ｈ）以降の表示については、復旧の見込みが立たないとの報告のあった１個のリソースは、ステータスの表示が消えている（稼働状態グラフ３０２の最上段）。そして、残りの４０個のリソースに関して、ステータスが段階的に復旧する様子（予測結果）が示され、この予測に基づいて、業務の復旧予測ライン３０３と、リソースの復旧予測ライン３０４とが表示されている。

図２５に示す例では、障害発生から２時間以上が経過しているので、ステータスが「Ｏｒａｎｇｅ」のリソースに関しては、障害発生からの復旧予定時間が４時間であった２個のリソースは、稼働状態グラフ３０２における２ｈの位置で、ステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。同様に、復旧時間が６時間であった２個のリソースは、４ｈの位置で、ステータスが「Ｏｒａｎｇｅ」から「Ｇｒｅｅｎ」に変化している。

一方、ステータスが「Ｒｅｄ」であるリソースのうち、業務「業務アプリケーション」のリソース「アプリサーバ」は復旧の見込みが立たないのでステータスが表示されていない（稼働状態グラフ３０２の最上段）。そして、障害発生からの復旧予定時間が６時間であった残りの３個のリソースは、稼働状態グラフ３０２における４ｈの位置で、ステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。また、復旧予定時間が１２時間であった業務「業務物流」の２個のリソースは、１０ｈの位置で、ステータスが「Ｒｅｄ」から「Ｇｒｅｅｎ」に変化している。また、業務「業務支払」のリソース「決裁権限者」に対応する１個のリソースのステータスが「Ｒｅｄ」の状態のまま維持される。そして、各リソースのステータスが「Ｇｒｅｅｎ」に移行する位置に沿って、リソースの復旧予測ライン３０４が表示されている。

業務に関しては、図２５では、図２４に示した業務の復旧予測ライン３０３がそのまま表示されれば、図の左方向へ１単位分ずれて、稼働状態グラフ３０２における４ｈの位置までは「１２」、４ｈから１０ｈまでは「２６」、１０ｈ以降は「３３」となる（図２５の復旧予測ライン３０３ａ）。しかし、今回の報告により、業務「業務アプリケーション」のリソース「アプリサーバ」に関して復旧の見込みが立たなくなったので、業務「業務アプリケーション」自体も稼働再開の見込みが立たなくなった。そのため、業務「業務アプリケーション」が稼働すると予想されていた稼働状態グラフ３０２の４ｈ以降では、図２４に示された復旧予測ライン３０３よりも業務「業務アプリケーション」のリソースの数（７個）だけ下がった値に設定される。すなわち、４ｈから１０ｈまでは「１９」、１０ｈ以降は「２６」に設定される（図２５の復旧予測ライン３０３ｂ）。

図２５に示す稼働レベル管理画面３００Ｅでは、上記のようにして得られた復旧予測ライン３０３ａと復旧予測ライン３０３ｂとを共に表示している。なお、図示の例では、復旧予測ライン３０３ｂを色の薄い破線で表示することにより、復旧予測ライン３０３ａと区別している。このような表示を行うことにより、順調に復旧作業が行われた場合の復旧予測（復旧予測ライン３０３ａ）に対する遅延が発生していることを視覚的に示すことができる。

以上説明したように、本実施形態によれば、リソースの稼働状態の情報を収集することにより、そのリソースを含む業務の稼働状態を把握することができる。そのため、図１９〜図２５を参照して説明したように、個々のリソース単独の復旧予測だけでなく、各リソースが含まれる業務単位での稼働の再開時期の予測を行うことが可能となる。

以上、本実施形態の構成および機能について説明したが、具体的なシステム構成や表示画面の構成は、上述した具体例には限定されない。本実施形態は、業務を遂行するために不可欠なリソースとして設定、抽出された個々のリソースについて、稼働状態の判断基準を設定する。また、各リソースの稼働状態が業務を遂行するために要求される通常の状態よりも低下した場合に、リソースおよび稼働状態ごとに、そのリソースの稼働状態を通常の状態に復帰させるために実施すべき対策を設定する。そして、個々のリソースごとに、稼働状態を低下させた原因（災害や事故等）の如何に関わらず、低下した稼働状態を通常の状態に復帰させるための対策を提示したり、対策の実施状況を示す情報を提示したり、各リソースを含む業務の稼働の再開時期を予測したりするものである。したがって、かかる技術思想を逸脱しない範囲において、種々の構成や機能を採ることが可能である。

例えば、本実施形態では、管理用端末装置３００を用いて管理サーバ２００からリソースに関する情報を取得し、適宜編集して上記の情報を提示するようにしたが、かかる情報処理を行う機能を管理サーバ２００に設け、管理用端末装置３００の代わりに、画像表示手段や入力デバイスを管理サーバ２００に設ける構成としても良い。この場合、上記実施形態における管理サーバ２００と管理用端末装置３００とを合わせて管理サーバとして把握される。

また、現場用端末装置１００において使用者（現場担当者）に提示される予め設定されている情報（「リソース」や「ステータス」の種類、ステータスに応じて実施すべき対策の内容や目標時間など）は、管理サーバ２００から現場用端末装置１００へ送信される構成としても良い。

さらに、現場用端末装置１００の各種の機能は、現場用端末装置１００にインストールされたアプリケーション・ソフトウェアによって実現されるようにしても良いし、管理サーバ２００に設けられたウェブ・アプリケーションによって実現し、現場用端末装置１００に提供される構成としても良い。

なお、上記の進度情報の評価や業務の復旧予定時間の予測は、リソースや業務が稼働するステータス「Ｏｒａｎｇｅ」となるときを基準として行ったが、ステータスが「Ｏｒａｎｇｅ」である場合のリソースや業務の稼働レベルは、本来の状態で稼働する「Ｇｒｅｅｎ」や「Ｙｅｌｌｏｗ」の場合と比べて低下している。そこで、本来の状態で稼働するステータス「Ｙｅｌｌｏｗ」となるときを基準として、進度情報の評価や復旧予定時間の予測を行っても良い。さらに、これらを組み合わせて行い、各々を区別して表現することにより、稼働を再開する時点と、本来の稼働状態に復帰する時点の双方について、進度情報や復旧予定時間の予測の情報を提示しても良い。

＜業務復旧支援システムの応用例＞
次に、本実施形態による業務復旧支援システムの応用例について説明する。
ここでは、商品の出荷業務やサービス業務のような対外的に品物やサービスを提供する業務を行う会社の業務管理に本実施形態のシステムを適用し、そのような複数のシステムの管理情報を集約して利用する応用例を説明する。

図２６は、本実施形態の業務復旧支援システムを含む集約管理システムの構成例を示す図である。
図２６に示すシステム構成では、全体集約サーバ６００に複数の個社別管理サーバ５００が接続されている。また、全体集約サーバ６００には、複数の利用者システムのサーバ（以下、利用者サーバ）７００が接続されている。全体集約サーバ６００と個社別管理サーバ５００との間の接続および全体集約サーバ６００と利用者サーバ７００との間の接続は、例えば、インターネット等の既存のネットワークを用いて行っても良いし、専用回線等を用いて行っても良い。通信プロトコルや回線の種類は特に限定されず、無線回線か有線回線かも問わない。なお、図２６に示す例では、全体集約サーバ６００に対して２台の個社別管理サーバ５００および３台の利用者サーバ７００を接続した構成が示されているが、全体集約サーバ６００に対する各サーバの接続数は、図示の構成例に限定されない。

図２６に示す例において、個社別管理サーバ５００は、本実施形態の業務復旧支援システムにおける管理サーバ２００に相当する。すなわち、個社別管理サーバ５００には、登録されたリソースの稼働状態に関する情報が、現場用端末装置１００から送られ、集められる。言い換えれば、個社別管理サーバ５００は、登録されたリソースの稼働状態に関する情報を収集する情報収集サーバとして機能する。また、個社別管理サーバ５００は、収集した情報に基づき、各リソースが含まれる業務の稼働状態を判断する。個社別管理サーバ５００は、管理サーバ２００の機能を有しているので、リソースおよび業務の稼働状態に関する情報を管理するため、図１３〜図１６を参照して説明したダッシュボード画面３００Ａ、稼働状態提示画面３００Ｂ、復旧状況確認画面３００Ｃ、チェックイン確認画面３００Ｄ、図１９〜図２５を参照して説明した稼働レベル管理画面３００Ｅを生成する。

本応用例では、会社ごとに個社別管理サーバ５００が設けられ、会社の業務の稼働状態が管理されるものとする。図２６に示す例では、会社Ａと会社Ｂがそれぞれ個社別管理サーバ５００を有している。ここで、各個社別管理サーバ５００により稼働状態が管理される業務には、上述したように、対外的に品物やサービスを提供する業務が含まれる。

対外的に品物やサービスを提供する業務に関する稼働状態に関しては、提供対象である個々の品物やサービスをそれぞれリソースとし、品物の出荷可否やサービスの提供可否についての情報を稼働状態の情報として設定することができる。例えば、品物の出荷が本来の状態（時間当たりの出荷量が本来の設定量に達している等）で可能であれば、ステータスが「Ｇｒｅｅｎ」や「Ｙｅｌｌｏｗ」となり、本来よりも低下したレベルで可能であれば、ステータスが「Ｏｒａｎｇｅ」となり、出荷不能であれば、ステータスが「Ｒｅｄ」となる。

全体集約サーバ６００は、全体集約サーバ６００に接続されている各個社別管理サーバ５００において管理されるリソースおよび業務の稼働状態に関する情報を集約して管理する。言い換えれば、全体集約サーバ６００は、情報収集サーバである個社別管理サーバ５００により収集された情報を集約する集約サーバとして機能する。全体集約サーバ６００が集約する稼働状態に関する情報には、各個社別管理サーバ５００で生成される各種の画面３００Ａ〜３００Ｅを含んでも良い。また、これらの画面３００Ａ〜３００Ｅを生成するために必要な情報を各個社別管理サーバ５００から取得し、全体集約サーバ６００において、各画面３００Ａ〜３００Ｅを生成するように構成しても良い。

また、全体集約サーバ６００は、利用者サーバ７００からの要求に応じて、集約管理しているリソースおよび業務の稼働状態に関する情報を返す。ここで、全体集約サーバ６００は、集約管理しているリソースおよび業務の稼働状態に関する情報に対するアクセス制御を行うことができる。

例えば、図２６に示すように、全体集約サーバ６００は、管理テーブル６０１等により、集約管理している個々のリソースおよび業務の稼働状態に関する情報と、各利用者との対応関係を管理する。そして、全体集約サーバ６００は、利用者サーバ７００から情報の取得要求を受け取った場合に、要求を行った利用者サーバ７００（利用者）に対応付けられているリソースおよび業務の稼働状態に関する情報のみを返す。図２６に示す管理テーブル６０１の例では、利用者αに対して、会社Ａの商品Ａ−１、Ａ−２、Ａ−３と、会社ＢのサービスＢＳ−１とが対応付けられている。また、利用者βに対して、会社Ａの商品Ａ−４、Ａ−５と、会社Ｂの商品Ｂ−１およびサービスＢＳ−１とが対応付けられている。また、利用者γに対して、会社Ｂの商品Ｂ−１、Ｂ−２およびサービスＢＳ−２が対応付けられている。したがって、例えば、利用者αの利用者サーバ７００から情報の取得要求が行われた場合、利用者サーバ７００は、会社Ａの業務「出荷」におけるリソース「商品Ａ−１」、「商品Ａ−２」、「商品Ａ−３」および会社Ｂの業務「サービス」におけるリソース「サービスＢＳ−１」の稼働状態に関する情報のみを取得することができる。

全体集約サーバ６００から各利用者サーバ７００に送られる情報には、図１３〜図１６を参照して説明したダッシュボード画面３００Ａ、稼働状態提示画面３００Ｂ、復旧状況確認画面３００Ｃ、チェックイン確認画面３００Ｄ、図１９〜図２５を参照して説明した稼働レベル管理画面３００Ｅを含むように構成しても良い。

＜集約管理システムの適用例＞
図２６に示した集約管理システムの具体的な適用例について説明する。
この例では、利用者サーバ７００を有する利用者α、利用者β、利用者γがそれぞれ自動車メーカであり、個社別管理サーバ５００を有する会社Ａ、会社Ｂが自動車部品の製造メーカであるものとする。そして、会社Ａおよび会社Ｂは、利用者α、利用者β、利用者γに対する部品の出荷業務を行っており、会社Ａおよび会社Ｂの各々の個社別管理サーバ５００は、各利用者α〜γに出荷している部品に関して、各部品をリソースとするリソースおよび業務の稼働状態に関する情報を管理している。この稼働状態に関する情報は、会社Ａおよび会社Ｂの個社別管理サーバ５００から、それぞれ全体集約サーバ６００へ送られ、全体集約サーバ６００において集約管理される。

自動車メーカである利用者α、利用者βおよび利用者γは、それぞれ全体集約サーバ６００へアクセスし、自身が購入している部品（リソース）に関する稼働状態の情報を取得することができる。これにより、利用者α、利用者βおよび利用者γは、自身が購入している部品の入荷が可能かどうかを判断することができる。すなわち、利用者α、利用者βおよび利用者γから見れば、自社の取引先である部品メーカの全てに問い合わせることなく、あたかも自社のリソースのごとく部品の供給情報を「稼働レベル情報」として参照することができる。そして、例えば、ある車種については部品が十分に供給されるので生産可能だが、他のある車種については部品が十分に供給されないので生産量を落とす必要がある、また他のある車種については部品供給が無いので生産できない等の判断を行うことが可能になる。

一方、部品の製造メーカである会社Ａおよび会社Ｂから見れば、個別の部品に関する出荷状態の情報を、お客様毎に個別に連絡する必要が無くなる。そのため、業務全体として利便性の向上や判断の時間の短縮を図ることができる。

なお、上記の例では、生産部品の出荷に関して稼働状態の情報を管理する例を説明したが、生産部品に限らず、各車種の自動車を生産するための様々なサービスやインフラ設備の稼働状態についても、全体集約サーバ６００で集約管理し、利用者サーバ７００からアクセスできるようにすることが可能である。

また、上記の例では、個々の部品（リソース）の出荷状態（稼働状態）の情報を利用者が取得し、利用者の業務において対応する例を示したが、管理対象である部品に関する業務の稼働状態の情報に基づいて、利用者の業務において対応することも考えられる。例えば、会社Ａの出荷業務の稼働レベルが低下している場合、自身が購入している部品（リソース）の出荷状態（稼働状態）は正常であっても、他の部品に関する稼働レベルが低下していることがわかり、会社Ａの業務に負荷が生じていることが想定される。そこで、自身が購入している部品の出荷についての稼働レベルが低下する場合に備えて、予め対策を取る準備をすることが可能となる。言い換えれば、本応用例においては、本実施形態による業務復旧支援システムにより扱われる稼働状態の情報を集約管理することにより、集約された情報の利用者の業務の稼働状態を、その業務を遂行するために要求される通常の状態に維持させるための支援を行うことができる。

上記の例においても明らかなように、本実施形態の業務復旧支援システムは、リソースや業務の稼働レベルを、その業務を遂行するために要求される通常の状態に維持し、また稼働レベルが低下した場合に、本来の稼働レベルに復旧させるための対策を取るための支援をする。そして、本実施形態の業務復旧支援システムが扱う情報には、稼働レベルを低下させた原因が含まれない。すなわち、災害や事故とは関係なく、単に業務上の負荷の増大等によって業務の稼働レベルが低下しているような場合にも、本来の稼働レベルに復旧させるための対策を取るための支援をすることができる。
さらに、本実施形態の業務復旧支援システムでは、管理対象の業務を遂行するために必要なリソースが管理対象のリソースとして設定されるため、リソースの稼働状態の情報を収集することにより、そのリソースを含む業務の稼働状態を把握することができる。

１００…現場用端末装置、１００Ａ…メニュー画面、１００Ｂ…リソース状態確認画面、１００Ｃ…稼働状態入力画面、１００Ｄ…復旧管理画面、１００Ｅ…対策情報確認画面、１１０…画像表示部、１２０…入力操作部、１３０…ユーザ・インターフェイス制御部、１４０…通信制御部、１５０…リソース情報記憶部、２００…管理サーバ、２１０…対策情報格納部、２２０…通信制御部、２３０…稼働情報管理部、３００…管理用端末装置、３００Ａ…ダッシュボード画面、３００Ｂ…稼働状態提示画面、３００Ｃ…復旧状況確認画面、３００Ｄ…チェックイン確認画面、３００Ｅ…稼働レベル管理画面、３０１…管理項目欄、３０２…稼働状態グラフ、３０３、３０４…復旧予測ライン、３１０…画像表示部、３２０…入力操作部、３３０…稼働情報取得部、３４０…稼働情報編集出力部

上記の目的を達成するため、本発明は、次のようなシステムとして実現される。このシステムは、業務全体のステータスを決定する各業務の稼働状態に関する情報の入力を受け付ける現場用端末装置と、現場用端末装置により入力された情報を収集して管理する管理サーバと、を備える。
現場用端末装置は、業務全体のステータスを決定する各業務を遂行するために不可欠なリソースとして設定されたリソースに関して、リソースの稼働状態が、各業務の具体的な実情に合わせて設定され予め定められた複数の段階のいずれに該当するかを特定するステータス情報を入力するためのステータス情報入力手段と、このステータス情報入力手段により入力されたステータス情報を前記管理サーバへ送信し、管理サーバで管理されているリソースに関するステータス情報のうち、自装置以外の現場用端末装置から取得されたステータス情報を管理サーバから受信する通信手段と、ステータス情報入力手段により入力されたステータス情報および管理サーバから受信したステータス情報に基づき、業務における各リソースの稼働状態を、業務全体のステータスを決定する各業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策を提示する対策提示手段と、を備える。
管理サーバは、現場用端末装置との間でステータス情報の送受信を行う通信手段と、この通信手段により現場用端末装置から受信したリソースのステータス情報を、リソースごとに、ステータス情報を送信した現場用端末装置に関連付けて管理する情報管理手段と、を備える。

より好ましくは、管理サーバの情報管理手段は、通信手段により現場用端末装置から受信したリソースのステータス情報に基づき、このリソースが属す各業務の稼働状態を特定し管理する。
さらに好ましくは、現場用端末装置は、対策提示手段により提示される対策の実施状況を表す進捗情報を入力するための進捗情報入力手段をさらに備える。そして、通信手段は、進捗情報入力手段により入力された進捗情報を管理サーバへ送信し、管理サーバで管理されている進捗情報のうち、自装置以外の現場用端末装置から取得された進捗情報を管理サーバから受信する。対策提示手段は、進捗情報入力手段により入力された進捗情報および管理サーバから受信した進捗情報に基づき、対策の実施状況を提示する。管理サーバの情報管理手段は、通信手段により現場用端末装置から受信した進捗情報を、進捗情報に係るリソースと、進捗情報を送信した現場用端末装置とに関連付けて管理する。
さらに詳細には、この現場用端末装置のステータス情報入力手段は、少なくとも、（１）リソースが本来の状態で稼働している状態である第１段階と、（２）リソースは稼働しているが、本来の状態よりも稼働レベルが低下した状態である第２段階と、（３）リソースが稼働していない状態である第３段階と、を含む、複数の段階のいずれに該当するかを選択的に指定可能な入力インターフェイスを有する。

また、より好ましくは、管理サーバは、情報管理手段に管理されているステータス情報および進捗情報に基づいて得られるリソースごとの対策の実施状況に基づき、リソースが属す各業務の稼働が再開される時間を予測する予測手段をさらに備える。
より詳細には、管理サーバは、業務全体のステータスを決定する各業務に属すリソースに関して、リソースの稼働状態を所定の稼働状態から各業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、情報管理手段に管理されているステータス情報に基づき、リソースの稼働状態を通常の状態に復帰させるために実施すべき対策を特定し、特定された対策に係る目標時間に基づき、各業務を稼働させるために必要な対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、情報管理手段に管理されている進捗情報に基づき、復旧予定時間に対する対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、をさらに備える。

また、本発明は、次のようなシステムとしても実現される。このシステムは、業務全体のステータスを決定する各業務を遂行するために不可欠なリソースとして設定されたリソースの稼働状態に関する情報を収集する情報収集サーバと、複数の情報収集サーバにより収集された情報を集約して管理する集約サーバと、を備える。
情報収集サーバは、リソースに関して、このリソースの稼働状態を所定の稼働状態から各業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、この対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、業務全体のステータスを決定する各業務に属すリソースに関して、このリソースの稼働状態が、各業務の具体的な実情に合わせて設定され予め定められた複数の段階のいずれに該当するかを特定するステータス情報、および、このステータス情報に基づいて特定される各業務における各リソースの稼働状態を、通常の状態に復帰させるために実施すべき対策の実施状況を表す進捗情報を取得する情報取得手段と、この情報取得手段により取得されたリソースごとのステータス情報に基づき、リソースの稼働状態を通常の状態に復帰させるために実施すべき対策を特定し、特定された対策に係る目標時間に基づき、各業務を稼働させるために必要な対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、情報取得手段により取得されたリソースごとの進捗情報に基づき、復旧予定時間に対する対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、を備える。
集約サーバは、情報収集サーバからリソースのステータス情報を取得して管理すると共に、個々のリソースと利用者との対応関係を管理し、利用者からの情報取得要求に応じて、この情報取得要求を行った利用者に対応付けられたリソースの稼働状態に関する情報を返す。

Claims (11)

1. 管理対象の業務の稼働状態に関する情報の入力を受け付ける現場用端末装置と、
   前記現場用端末装置により入力された情報を収集して管理する管理サーバと、を備え、
   前記現場用端末装置は、
   前記業務を遂行するために不可欠なリソースとして設定されたリソースに関して、当該リソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報を入力するためのステータス情報入力手段と、
   前記ステータス情報入力手段により入力されたステータス情報を前記管理サーバへ送信し、当該管理サーバで管理されている前記リソースに関するステータス情報のうち、自装置以外の前記現場用端末装置から取得されたステータス情報を当該管理サーバから受信する通信手段と、
   前記ステータス情報入力手段により入力されたステータス情報および前記管理サーバから受信したステータス情報に基づき、前記業務における各リソースの稼働状態を、当該業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策を提示する対策提示手段と、を備え、
   前記管理サーバは、
   前記現場用端末装置との間で前記ステータス情報の送受信を行う通信手段と、
   前記通信手段により前記現場用端末装置から受信した前記リソースの前記ステータス情報を、当該リソースごとに、当該ステータス情報を送信した当該現場用端末装置に関連付けて管理する情報管理手段と、
   を備えること、を特徴とする、業務復旧支援システム。
2. 前記管理サーバの前記情報管理手段は、前記通信手段により前記現場用端末装置から受信した前記リソースの前記ステータス情報に基づき、当該リソースが属す前記業務の稼働状態を特定し管理すること、を特徴とする、請求項１に記載の業務復旧支援システム。
3. 前記現場用端末装置は、前記対策提示手段により提示される前記対策の実施状況を表す進捗情報を入力するための進捗情報入力手段をさらに備え、
   前記通信手段は、前記進捗情報入力手段により入力された進捗情報を前記管理サーバへ送信し、当該管理サーバで管理されている進捗情報のうち、自装置以外の前記現場用端末装置から取得された進捗情報を当該管理サーバから受信し、
   前記対策提示手段は、前記進捗情報入力手段により入力された進捗情報および前記管理サーバから受信した進捗情報に基づき、前記対策の実施状況を提示し、
   前記管理サーバの前記情報管理手段は、前記通信手段により前記現場用端末装置から受信した前記進捗情報を、当該進捗情報に係るリソースと、当該進捗情報を送信した当該現場用端末装置とに関連付けて管理すること、
   を特徴とする、請求項１または請求項２に記載の業務復旧支援システム。
4. 前記管理サーバは、前記情報管理手段に管理されている前記ステータス情報および前記進捗情報に基づいて得られる前記リソースごとの前記対策の実施状況に基づき、当該リソースが属す前記業務の稼働が再開される時間を予測する予測手段をさらに備えること、を特徴とする、請求項３に記載の業務復旧支援システム。
5. 前記管理サーバは、
   管理対象の業務に属す前記リソースに関して、当該リソースの稼働状態を所定の稼働状態から当該業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、当該対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、
   前記情報管理手段に管理されている前記ステータス情報に基づき、当該リソースの稼働状態を前記通常の状態に復帰させるために実施すべき対策を特定し、特定された当該対策に係る前記目標時間に基づき、前記業務を稼働させるために必要な当該対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、
   前記情報管理手段に管理されている前記進捗情報に基づき、前記復旧予定時間に対する前記対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、
   をさらに備えること、を特徴とする、請求項３または請求項４に記載の業務復旧支援システム。
6. 管理対象の業務を遂行するために不可欠なリソースとして設定されたリソースに関して、当該リソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報を入力するためのステータス情報入力手段と、
   前記ステータス情報入力手段により入力されたステータス情報に基づいて特定される前記業務における各リソースの稼働状態を、当該業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策の実施状況を表す進捗情報を入力するための進捗情報入力手段と、
   前記ステータス情報入力手段により入力されたステータス情報および前記進捗情報入力手段により入力された進捗情報を外部サーバへ送信し、自装置以外の端末装置から取得されたステータス情報および進捗情報を当該外部サーバから受信する通信手段と、
   前記ステータス情報入力手段により入力されたステータス情報および前記外部サーバから受信したステータス情報に基づき、前記リソースごとの前記対策を提示し、前記進捗情報入力手段により入力された進捗情報および前記外部サーバから受信した進捗情報に基づき、前記対策の実施状況を提示する
   対策提示手段と、
   を備えることを特徴とする、業務復旧支援装置。
7. 前記ステータス情報入力手段は、少なくとも、
   前記リソースが本来の状態で稼働している状態である第１段階と、
   前記リソースは稼働しているが、本来の状態よりも稼働レベルが低下した状態である第２段階と、
   前記リソースが稼働していない状態である第３段階と、
   を含む、複数の段階のいずれに該当するかを選択的に指定可能な入力インターフェイスを有すること、を特徴とする、請求項６に記載の業務復旧支援装置。
8. 管理対象の業務を遂行するために不可欠なリソースとして設定されたリソースに関して、当該リソースの稼働状態を所定の稼働状態から当該業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、当該対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、
   管理対象の業務に属す前記リソースに関して、当該リソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報、および、当該ステータス情報に基づいて特定される当該業務における各リソースの稼働状態を、前記通常の状態に復帰させるために実施すべき対策の実施状況を表す進捗情報を取得する情報取得手段と、
   前記情報取得手段により取得された前記リソースごとの前記ステータス情報に基づき、当該リソースの稼働状態を前記通常の状態に復帰させるために実施すべき対策を特定し、特定された当該対策に係る前記目標時間に基づき、前記業務を稼働させるために必要な当該対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、
   前記情報取得手段により取得された前記リソースごとの前記進捗情報に基づき、前記復旧予定時間に対する前記対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、
   を備えることを特徴とする、復旧状況管理装置。
9. 前記情報取得手段により取得された前記ステータス情報および前記進捗情報に基づいて得られる前記リソースごとの前記対策の実施状況に基づき、当該リソースが属す前記業務の稼働が再開される時間を予測する予測手段をさらに備えること、を特徴とする、請求項８に記載の復旧状況管理装置。
10. コンピュータに、
    管理対象の業務を遂行するために不可欠なリソースとして設定されたリソースに関して、当該リソースの稼働状態を所定の稼働状態から当該業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、当該対策の実施を完了するのに要する時間として設定された目標時間とを格納した記憶装置に対してデータの読み書きを行う機能と、
    管理対象の業務に属す前記リソースに関して、当該リソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報、および、当該ステータス情報に基づいて特定される当該業務における各リソースの稼働状態を、前記通常の状態に復帰させるために実施すべき対策の実施状況を表す進捗情報を取得する機能と、
    取得された前記リソースごとの前記ステータス情報に基づき、当該リソースの稼働状態を前記通常の状態に復帰させるために実施すべき対策を特定し、特定された当該対策に係る前記目標時間に基づき、前記業務を稼働させるために必要な当該対策の実施を完了するのに要する時間である復旧予定時間を計算する機能と、
    前記リソースごとの前記進捗情報に基づき、前記復旧予定時間に対する前記対策の実施状況の進度を表す進度情報を出力する機能と、
    を実現させることを特徴とする、プログラム。
11. 管理対象の業務を遂行するために不可欠なリソースとして設定されたリソースの稼働状態に関する情報を収集する情報収集サーバと、
    複数の前記情報収集サーバにより収集された情報を集約して管理する集約サーバと、を備え、
    前記情報収集サーバは、
    前記リソースに関して、当該リソースの稼働状態を所定の稼働状態から前記業務を遂行するために要求される通常の状態に復帰させるために実施すべき対策と、当該対策の実施を完了するのに要する時間として設定された目標時間とを格納した情報格納手段と、
    管理対象の業務に属す前記リソースに関して、当該リソースの稼働状態が、予め定められた複数の段階のいずれに該当するかを特定するステータス情報、および、当該ステータス情報に基づいて特定される当該業務における各リソースの稼働状態を、前記通常の状態に復帰させるために実施すべき対策の実施状況を表す進捗情報を取得する情報取得手段と、
    前記情報取得手段により取得された前記リソースごとの前記ステータス情報に基づき、当該リソースの稼働状態を前記通常の状態に復帰させるために実施すべき対策を特定し、特定された当該対策に係る前記目標時間に基づき、前記業務を稼働させるために必要な当該対策の実施を完了するのに要する時間である復旧予定時間を計算する復旧予定時間計算手段と、
    前記情報取得手段により取得された前記リソースごとの前記進捗情報に基づき、前記復旧予定時間に対する前記対策の実施状況の進度を表す進度情報を出力する進度情報出力手段と、を備え、
    前記集約サーバは、
    前記情報収集サーバから前記リソースのステータス情報を取得して管理すると共に、個々の当該リソースと利用者との対応関係を管理し、利用者からの情報取得要求に応じて、当該情報取得要求を行った利用者に対応付けられた当該リソースの稼働状態に関する情報を返すこと、
    を特徴とする、集約管理システム。

Images