(57)【要約】【課題】災害や事故に伴う業務の変動状況を推定することを課題とする。【解決手段】事業に係る情報を推定する方法をコンピュータに実行させる事業情報推定プログラムであって、事業を構成するプロセスとプロセスで利用されるリソースとの関係を、プロセスでリソースが必要となる度合いとともに対応づけて保持し、保持された前記プロセスとリソースとの関係に基づいて、リソースの状態に係る情報からプロセスの状態に係る情報を推定する。また、プロセスによって構成される上位のプロセスと上位のプロセスを構成する下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに対応づけて保持し、保持された上位のプロセスと下位のプロセスとの関係に基づいて、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報をさらに推定する。【選択図】        図１
2007305067.tif 000002
【特許請求の範囲】
【請求項１】
事業に係る情報を推定する方法をコンピュータに実行させる事業情報推定プログラムであって、
事業を構成するプロセスと当該プロセスで利用されるリソースとの関係を、当該プロセスで当該リソースが必要となる度合いとともに対応づけて保持する保持手順と、
前記保持手順によって保持された前記プロセスと前記リソースとの関係に基づいて、当該リソースの状態に係る情報から当該プロセスの状態に係る情報を推定する推定手順と、
をコンピュータに実行させることを特徴とする事業情報推定プログラム。
【請求項２】
前記保持手順は、プロセスによって構成される上位のプロセスと当該上位のプロセスを構成する下位のプロセスとの関係を、当該上位のプロセスで当該下位のプロセスが必要となる度合いとともに対応づけてさらに保持し、
前記推定手順は、前記保持手順によって保持された前記上位のプロセスと前記下位のプロセスとの関係に基づいて、当該下位のプロセスの状態に係る情報から当該上位のプロセスの状態に係る情報をさらに推定することを特徴とする請求項１に記載の事業情報推定プログラム。
【請求項３】
前記推定手順は、前記リソースの状態に係る情報が、当該リソースが正常な状態であることを示す情報、当該リソースが対処を必要とする状態であることを示す情報、または当該リソースが復旧不能な状態であることを示す情報のいずれであるかに応じて、前記プロセスの状態に係る情報を推定することを特徴とする請求項１または２に記載の事業情報推定プログラム。
【請求項４】
前記推定手順は、前記プロセスの状態に係る情報として、当該プロセスが正常な状態であることを示す情報、当該プロセスが放置可能な状態であることを示す情報、または当該プロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定することを特徴とする請求項１〜３のいずれかひとつに記載の事業情報推定プログラム。
【請求項５】
事業に係る情報を推定する事業情報推定方法であって、
事業を構成するプロセスと当該プロセスで利用されるリソースとの関係を、当該プロセスで当該リソースが必要となる度合いとともに対応づけて保持する保持工程と、
前記保持工程によって保持された前記プロセスと前記リソースとの関係に基づいて、当該リソースの状態に係る情報から当該プロセスの状態に係る情報を推定する推定工程と、
を含んだことを特徴とする事業情報推定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、事業情報推定プログラム、事業情報推定方法および事業情報推定装置に関する。
【背景技術】
【０００２】
従来より、災害や事故（例えば、地震、火災・爆発、大規模なシステム障害など）に企業が遭遇した際に、企業が事業を継続するためにはどのような行動を取るべきかを示す事業継続計画（ＢＣＰ：Business Continuity Plan）を、企業において事前に策定することが求められている。ここで、事前に策定されたＢＣＰを実施する上では、経営層による的確な意思決定がなされる必要がある。このため、このような意思決定を支援することを目的として、意思決定に必要な情報を推定する方法が提案されている。
【０００３】
例えば、特許文献１では、災害情報が入力されることで被害状況を推定する方法が開示されている。具体的に例を挙げて説明すると、災害情報として、例えば、地震の発生日時、震源地、マグニチュードなどが入力されることで、被害状況（例えば、道路状況、個別の建物の使用可否、地域住民の被害、地域の火災の発生度合い、従業員の被害率など）を推定する方法である。
【０００４】
【特許文献１】特開平１１−３１６７８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
ところで、上記した従来の技術では、業務の状況を推定することができないという課題がある。すなわち、災害情報が入力されることで被害状況を推定する手法では、被害状況を推定するにすぎず、被害状況に応じて多様に変動する業務の状況などを推定することができない。
【０００６】
そこで、この発明は、上記した従来技術の課題を解決するためになされたものであり、災害や事故に伴う業務の変動状況を推定することが可能な事業情報推定プログラム、事業情報推定方法および事業情報推定装置を提供することを目的とする。
【課題を解決するための手段】
【０００７】
上述した課題を解決し、目的を達成するため、請求項１に係る発明は、事業に係る情報を推定する方法をコンピュータに実行させる事業情報推定プログラムであって、事業を構成するプロセスと当該プロセスで利用されるリソースとの関係を、当該プロセスで当該リソースが必要となる度合いとともに対応づけて保持する保持手順と、前記保持手順によって保持された前記プロセスと前記リソースとの関係に基づいて、当該リソースの状態に係る情報から当該プロセスの状態に係る情報を推定する推定手順と、をコンピュータに実行させることを特徴とする。
【０００８】
また、請求項２に係る発明は、上記の発明において、前記保持手順は、プロセスによって構成される上位のプロセスと当該上位のプロセスを構成する下位のプロセスとの関係を、当該上位のプロセスで当該下位のプロセスが必要となる度合いとともに対応づけてさらに保持し、前記推定手順は、前記保持手順によって保持された前記上位のプロセスと前記下位のプロセスとの関係に基づいて、当該下位のプロセスの状態に係る情報から当該上位のプロセスの状態に係る情報をさらに推定することを特徴とする。
【０００９】
また、請求項３に係る発明は、上記の発明において、前記推定手順は、前記リソースの状態に係る情報が、当該リソースが正常な状態であることを示す情報、当該リソースが対処を必要とする状態であることを示す情報、または当該リソースが復旧不能な状態であることを示す情報のいずれであるかに応じて、前記プロセスの状態に係る情報を推定することを特徴とする。
【００１０】
また、請求項４に係る発明は、上記の発明において、前記推定手順は、前記プロセスの状態に係る情報として、当該プロセスが正常な状態であることを示す情報、当該プロセスが放置可能な状態であることを示す情報、または当該プロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定することを特徴とする。
【００１１】
また、請求項５に係る発明は、事業に係る情報を推定する事業情報推定方法であって、事業を構成するプロセスと当該プロセスで利用されるリソースとの関係を、当該プロセスで当該リソースが必要となる度合いとともに対応づけて保持する保持工程と、前記保持工程によって保持された前記プロセスと前記リソースとの関係に基づいて、当該リソースの状態に係る情報から当該プロセスの状態に係る情報を推定する推定工程と、を含んだことを特徴とする。
【発明の効果】
【００１２】
請求項１または５の発明によれば、事業に係る情報を推定する方法をコンピュータに実行させる事業情報推定プログラムであって、事業を構成するプロセスとプロセスで利用されるリソースとの関係を、プロセスでリソースが必要となる度合いとともに対応づけて保持し、保持されたプロセスとリソースとの関係に基づいて、リソースの状態に係る情報からプロセスの状態に係る情報を推定するので、被害状況に応じて多様に変動する業務の状況などを推定する（リソースの被害状況に応じて変動するプロセスの状態を推定する）結果、災害や事故に伴う業務の変動状況を推定することが可能になる。また、災害等で直接のダメージを受けた目の前のリソース（例えば、要員、設備、資機材など）の状態に係る情報が入力されるだけでプロセスの状態を推定する結果、事実として存在する単純な情報を収集するのみで、業務の変動状況を推定することが可能になる。
【００１３】
また、請求項２の発明によれば、プロセスによって構成される上位のプロセスと上位のプロセスを構成する下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに対応づけてさらに保持し、保持された上位のプロセスと下位のプロセスとの関係に基づいて、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報をさらに推定するので、多段の業務によって構成された事業においても、被害状況に応じて多様に変動する業務の状況を推定する（リソースの被害状況に応じて変動するプロセスの状態を推定し、状態を推定されたプロセスによって構成されるプロセスの状態をさらに推定する）結果、多段の業務によって構成された事業においても、災害や事故に伴う業務の変動状況を推定することが可能になる。
【００１４】
また、請求項３の発明によれば、リソースの状態に係る情報が、リソースが正常な状態であることを示す情報、リソースが対処を必要とする状態であることを示す情報、またはリソースが復旧不能な状態であることを示す情報のいずれであるかに応じて、プロセスの状態に係る情報を推定するので、３段階で判定されたリソースの状態に係る情報からプロセスの状態を推定する結果、災害や事故に伴う業務の変動状況を、複雑な判定をせずに簡易に推定することが可能になる。
【００１５】
また、請求項４の発明によれば、プロセスの状態に係る情報として、プロセスが正常な状態であることを示す情報、プロセスが放置可能な状態であることを示す情報、またはプロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定するので、プロセスの状態を３段階で推定する結果、災害や事故に伴う業務の変動状況を、単純に推定することが可能になる。
【発明を実施するための最良の形態】
【００１６】
以下に添付図面を参照して、この発明に係る事業情報推定プログラム、事業情報推定方法、および事業情報推定装置の実施例を詳細に説明する。なお、以下では、実施例で用いる主要な用語、実施例１に係る事業情報推定装置の概要および特徴、実施例１に係る事業情報推定装置の構成および処理の手順、実施例１の効果を順に説明し、次に、他の実施例について説明する。
【実施例１】
【００１７】
［用語の説明］
まず最初に、以下の実施例で用いる主要な用語を説明する。「事業に係る情報」とは、事業継続計画（ＢＣＰ：Business Continuity Plan）に基づいた意思決定者による意思決定を支援するための情報のことである。具体的に説明すると、災害や事故（例えば、地震、火災・爆発、大規模なシステム障害など）に企業が遭遇した際には、事業を継続するための意思決定が、経営層などの意思決定者によってなされなければならず、この意思決定にあたっては、事業に関連する情報（例えば、被害状況、事業を構成する業務の変動状況など）が意思決定者によって把握されなければならない。このような情報を以下の実施例では「事業に係る情報」と呼ぶが、災害や事故に企業が遭遇した際に、これらの「事業に係る情報」が意思決定者によって把握されることは困難であることから、「事業に係る情報」は推定されることになる。
【００１８】
ところで、企業における事業は、通常、複数の業務によって構成されている。また、事業を構成する業務が、さらに下位の業務によって構成されている場合もある。具体的に例を挙げて説明すると、例えば、事業を構成する業務として『製造出荷業務』がある場合、『製造出荷業務』は、例えば、下位の業務である『部材調達』、『組立製造』、『生産管理』、および『物流』によって構成されている。このような場合、『製造出荷業務』、『部材調達』、『組立製造』、『生産管理』、および『物流』は、すべて事業を構成する「プロセス」であり、その中で、『製造出荷業務』は、プロセスによって構成される「上位のプロセス」であり、『部材調達』、『組立製造』、『生産管理』、および『物流』は、上位のプロセスを構成する「下位のプロセス」である。
【００１９】
また、事業におけるこれらの「プロセス」は、通常、リソースを利用している。具体的に例を挙げて説明すると、『部材調達』の業務は、取引先から部材を調達する業務であり、部材の供給元である取引先や、部材の調達を行う要員や、調達した部材を管理する情報システムをリソースとして利用する業務である。すなわち、『部材調達』のプロセスは、リソースとして、『取引先』、『要員』、および『情報システム』を利用する。
【００２０】
［実施例１に係る事業情報推定装置の概要および特徴］
続いて、図１を用いて、実施例１に係る事業情報推定装置の概要および特徴を説明する。図１は、実施例１に係る事業情報推定装置の概要および特徴を説明するための図である。なお、図１においては、「日常」における事業情報推定装置による出力画面、「発災直後」における事業情報推定装置による出力画面、および「最初の状況確認後」における事業情報推定装置による出力画面が、時系列で並べられている。
【００２１】
実施例１に係る事業情報推定装置は、上記したように、事業に係る情報を推定することを概要とし、災害や事故に伴う業務の変動状況を推定することを主たる特徴とする。
【００２２】
この主たる特徴について簡単に説明すると、実施例１に係る事業情報推定装置は、図１に示すように、事業を構成するプロセスと、プロセスで利用されるリソースとの関係を、プロセスでリソースが必要となる度合いとともに対応づけて保持する。また、事業情報推定装置は、プロセスによって構成される上位のプロセスと、上位のプロセスを構成する下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに対応づけて保持する。
【００２３】
ここで、「必要となる度合い」について説明すると、例えば、上記したプロセス『部材調達』と、リソース『取引先』、『要員』、および『情報システム』との間には、「部材の調達を行う要員が不足したり、調達した部材を管理する情報システムがダウンしたとしても、部材を調達することが不可能になるわけではないが、部材の供給元である取引先に重大な問題が発生すると、部材を調達することが不可能になるおそれがある」という「関係」が存在することを、業務の実態に即してあらかじめ仮定することができる。このように仮定された「関係」において、リソース『取引先』は、プロセス『部材調達』で「必要となる度合い」が高いリソース（必要条件）であり、一方、リソース『要員』や『情報システム』は、プロセス『部材調達』で「必要となる度合い」が低いリソース（それ以外）である。
【００２４】
また、実施例１に係る事業情報推定装置は、保持するプロセスとリソースとの関係に基づいて、リソースの状態に係る情報からプロセスの状態に係る情報を推定する。さらに、事業情報推定装置は、保持する上位のプロセスと下位のプロセスとの関係に基づいて、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報を推定する。
【００２５】
ここで、上記した事業情報推定装置による推定について具体的に例を挙げて説明すると、下位のプロセスとリソースとの関係が、下位のプロセスでリソースが必要となる度合いが高い関係である場合で、かつ、このリソースの状態に係る情報が「対処を必要」とする状態である場合には、実施例１に係る事業情報推定装置は、この下位のプロセスの状態に係る情報を、「優先的に対処を必要」とする状態であると推定する。例えば、図１の「最初の状況確認後」において示すように、下位のプロセス『部材調達』とリソース『取引先』との関係が、下位のプロセスでリソースが必要となる度合いが高い関係（必要条件）である場合で、かつ、このリソース『取引先』の状態に係る情報が「対処を必要」とする状態である場合には、事業情報推定装置は、下位のプロセス『部材調達』のプロセスの状態に係る情報を、「優先的に対処を必要」とする状態であると推定する。
【００２６】
また、他の例では、上位のプロセスと下位のプロセスとの関係が、上位のプロセスで下位のプロセスが必要となる度合いが高い関係である場合で、かつ、この下位のプロセスの状態に係る情報が「優先的に対処を必要」とする状態である場合には、実施例１に係る事業情報推定装置は、この上位のプロセスの状態に係る情報を、「優先的に対処を必要」とする状態であると推定する。例えば、図１の「最初の状況確認後」において示すように、上位のプロセス『製造出荷業務』と下位のプロセス『組立製造』との関係が、上位のプロセスで下位のプロセスが必要となる度合いが高い関係（必要条件）である場合で、かつ、この下位のプロセス『組立製造』の状態に係る情報が「優先的に対処を必要」とする状態である場合には、事業情報推定装置は、上位のプロセス『製造出荷業務』のプロセスの状態に係る情報を、「優先的に対処を必要」とする状態であると推定する。
【００２７】
このようにして、実施例１に係る事業情報推定装置は、被害状況に応じて多様に変動する業務の状況を推定する（リソースの被害状況に応じて変動するプロセスの状態を推定する）結果、災害や事故に伴う業務の変動状況を推定することが可能になる。また、実施例１に係る事業情報推定装置は、多段の業務によって構成された事業においても、被害状況に応じて多様に変動する業務の状況を推定する（リソースの被害状況に応じて変動するプロセスの状態を推定し、状態を推定されたプロセスによって構成されるプロセスの状態をさらに推定する）結果、多段の業務によって構成された事業においても、災害や事故に伴う業務の変動状況を推定することが可能になる。
【００２８】
ところで、実施例１に係る事業情報推定装置は、上記の他に、図１に示すように、プロセスの状態に係る情報と、リソースの状態に係る情報と、プロセスでリソースが必要となる度合いとをモニタに出力することにも特徴がある。また、実施例１に係る事業情報推定装置は、状態に係る情報や度合いを、状態や度合いに応じた形態で区分けしてモニタに出力することにも特徴がある。
【００２９】
ここで、状態の区分けについて説明すると、実施例１に係る事業情報推定装置は、状態に係る情報を、状態に応じた色で区分けしてモニタに出力する。すなわち、図１の凡例に示すように、実施例１に係る事業情報推定装置における色の区分けとしては、「グレー」、「オレンジ」、「緑」、「黄」、「赤」、および「黒」が用いられる。「グレー」は、プロセスまたはリソースが「不明」な状態であることを示す色であり、「オレンジ」は、情報が不足してプロセスまたはリソースが「推定不能」な状態であることを示す色であり、「緑」は、プロセスまたはリソースが「正常」な状態であることを示す色であり、「黄」は、プロセスが「放置可能」な状態であること、または、リソースが「対処を必要」とする状態であることを示す色であり、「赤」は、プロセスが「優先的に対処を必要」とする状態であることを示す色であり、「黒」は、リソースが「復旧不能」な状態であることを示す色である。
【００３０】
また、度合いの区分けについて説明すると、実施例１に係る事業情報推定装置は、プロセスでリソースが必要となる度合いを、度合いに応じて実線と破線とで区分けしてモニタに出力する。すなわち、図１の凡例に示すように、実施例１に係る事業情報推定装置は、「必要となる度合い」が高いリソースとプロセスとの関係については、実線の矢印で示し、「必要となる度合い」が低いリソースとプロセスとの関係については、破線の矢印で示す。
【００３１】
ここで、上記した事業情報推定装置による出力について具体的に説明すると、まず、実施例１に係る事業情報推定装置は、災害または事故の発生による事業情報推定開始の指示を受け付けると、全てのプロセスの状態に係る情報とリソースの状態に係る情報とが「不明」な状態であるとして、状態に係る情報を「グレー」にしてモニタに出力する。
【００３２】
次に、事業情報推定装置は、リソースの状態に係る情報の入力を受け付ける。例えば、図１を用いて説明すると、事業情報推定装置は、リソース『製品在庫』の状態に係る情報として、「正常」な状態であるとの情報の入力を受け付ける。そして、事業情報推定装置は、入力されたリソースの状態に係る情報をモニタに出力する。つまり、図１の「発災直後」において示すように、リソース『製品在庫』の状態に係る情報を「緑」にしてモニタに出力する。
【００３３】
続いて、実施例１に係る事業情報推定装置は、保持するプロセスとリソースとの関係に基づいて、リソースの状態に係る情報からプロセスの状態に係る情報を推定する。もっとも、この段階では、情報が不足してプロセス『物流』が「推定不能」な状態であるので、事業情報推定装置は、図１の「発災直後」において示すように、プロセス『物流』の状態に係る情報を「オレンジ」にしてモニタに出力する。
【００３４】
次に、実施例１に係る事業情報推定装置は、同様に、リソース『輸送手段』の状態に係る情報の入力を受け付け、同様の処理を行う。なお、図１の「発災直後」は、事業情報推定装置が、プロセスの状態に係る情報とリソースの状態に係る情報とを全て「グレー」にしてモニタに出力した後、リソース『製品在庫』と『輸送手段』との状態に係る情報の入力を順に受け付け、リソースの状態に係る情報と、関連するプロセスの状態に係る情報とを、モニタに出力した段階を示したものである。
【００３５】
こうして、実施例１に係る事業情報推定装置は、図１の「最初の状況確認後」において示すように、他のリソースについても同様に入力を受け付け、リソースの状態に係る情報をモニタに出力し、リソースの状態に係る情報から下位のプロセスの状態に係る情報を推定し、推定された下位のプロセスの状態に係る情報をモニタに出力する。また、実施例１に係る事業情報推定装置は、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報を推定し、推定された上位のプロセスの状態に係る情報をモニタに出力する。
【００３６】
すなわち、図１の「最初の状況確認後」において示すように、実施例１に係る事業情報推定装置は、例えば、リソース『情報システム』、『輸送手段』、および『製品在庫』が「正常」な状態であるとの情報の入力を受け付け、これらのリソースの状態に係る情報を「緑」にしてモニタに出力する。そして、事業情報推定装置が、これらのリソースの状態に係る情報からプロセス『物流』の状態に係る情報を推定すると、プロセス『物流』の状態に係る情報が「正常」な状態であると推定されるので、推定されたプロセス『物流』の状態に係る情報を「緑」にしてモニタに出力する。
【００３７】
また、他の例では、事業情報推定装置は、リソース『取引先』が「対処を必要」とする状態であるとの情報の入力を受け付け、リソース『取引先』の状態に係る情報を「黄」にしてモニタに出力する。そして、事業情報推定装置が、リソース『取引先』の状態に係る情報からプロセス『部材調達』の状態に係る情報を推定すると、プロセス『部材調達』の状態に係る情報が「優先的に対処を必要」とする状態であると推定されるので、推定されたプロセス『部材調達』の状態に係る情報を「赤」にしてモニタに出力する。
【００３８】
このようにして、実施例１に係る事業情報推定装置は、災害や事故に伴う業務の変動状況を、意思決定者に把握させることが可能になる。また、実施例１に係る事業情報推定装置は、プロセスやリソースの状態、プロセスでリソースが必要となる度合いなどを、意思決定者に直感的に認識させることが可能になる。また、状態に係る情報の出力について、トリアージ（医療機能が制約される状況下で、一人でも多くの傷病者に対して最善の治療を行うことを目的として、傷病者の緊急度や重症度などに応じて治療の優先順位を決めること）で採用されている識別色（重症群（赤）、中等症群（黄）、軽症群（緑）、死亡群（黒））の考え方を導入すると、状態に係る情報を、意思決定者により直感的に認識させることが可能になる。
【００３９】
［実施例１に係る事業情報推定装置の構成］
次に、図２〜図８を用いて、実施例１に係る事業情報推定装置を説明する。図２は、実施例１に係る事業情報推定装置の構成を示すブロック図であり、図３は、出力画面を説明するための図であり、図４は、関係保持部を説明するための図であり、図５は、推定方針記憶部を説明するための図であり、図６は、出力形態方針記憶部を説明するための図であり、図７は、リソース状態情報記憶部を説明するための図であり、図８は、推定結果記憶部を説明するための図である。
【００４０】
図２に示すように、実施例１に係る事業情報推定装置１０は、入力部１１と、出力部１２と、入出力制御ＩＦ部１３と、記憶部２０と、制御部３０とから構成される。
【００４１】
入力部１１は、制御部３０による各種処理に用いるデータや、各種処理をするための操作指示などを、キーボード、マウス、記憶媒体、または通信部などによって入力する手段である。具体的には、入力部１１は、後述する推定部３３による推定に用いられる下位のプロセスとリソースとの関係を、下位のプロセスでリソースが必要となる度合いとともに入力し、関係保持部２１に記憶させる。また、入力部１１は、推定部３３による推定に用いられる上位のプロセスと下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに入力し、関係保持部２１に記憶させる。
【００４２】
また、入力部１１は、後述する推定方針受付部３１によって設定が受け付けられる推定に用いられる方針を入力し、推定方針記憶部２２に記憶させる。また、入力部１１は、後述する出力形態方針受付部３２によって設定が受け付けられる形態に係る方針を入力し、出力形態方針記憶部２３に記憶させる。また、入力部１１は、推定部３３による推定に用いられるリソースの状態に係る情報を入力し、リソース状態情報記憶部２４に記憶させる。また、入力部１１は、災害または事故の発生による事業情報推定開始の指示を入力し、推定部３３による推定を開始させる。
【００４３】
出力部１２は、制御部３０による各種処理の結果や、各種処理をするための操作指示などを、モニタ、プリンタ、スピーカ、または通信部などに出力する手段である。具体的には、出力部１２は、入力部１１によってデータを入力させるための画面や、後述する推定結果記憶部２５に記憶された推定結果などを出力する。例えば、出力部１２は、図３に示すような画面を出力する。ここで、図３に示す出力画面について説明すると、出力部１２は、事業情報推定装置における関連情報として、災害の種類を示す「地震災害」といった情報や、「防災気象情報」や「安否確認」などのイベントに関連する情報（種別、日時、時刻、件名など）などを表示する。
【００４４】
また、例えば、出力部１２は、図３に示すように、「業務・プロセス」、「プロセス・リソース」、および「リソースビュー」の３つのフレームを設けて表示する。これらの中で、「業務・プロセス」は、プロセスによって構成される上位のプロセスを、「重要業務」、「一般業務」、および「その他」によって分類し、選択（クリック）された業務についてツリー状に表示するフレームである。具体的に例を挙げると、例えば、『製造出荷業務』のアイコンがクリックされると、図３において図示してはいないが、下位のプロセスである『部材調達』、『組立製造』、『生産管理』、および『物流』のアイコンをツリー状に表示する。
【００４５】
ところで、『製造出荷業務』のアイコンをみると、リソースの状態に係る情報も合わせて表示している（上位のプロセスである『製造出荷業務』が利用するリソースの状態に係る情報を、下位のプロセスとの関係を割愛して表示している）。なお、図３においては、説明の便宜上から、製造出荷業務のアイコンについてのみリソースの状態に係る情報を合わせて表示したが、全ての上位のプロセスのアイコンについて、リソースの状態に係る情報を合わせて表示することが通常である。
【００４６】
また、「プロセス・リソース」は、「業務・プロセス」のフレームにおいて選択された上位のプロセスについて、上位のプロセスと上位のプロセスを構成する下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに対応づけてツリー状に表示するフレームである。また、選択（クリック）された下位のプロセスについて、下位のプロセスと下位のプロセスで利用されるリソースとの関係を、下位のプロセスでリソースが必要となる度合いとともに対応づけてツリー状に表示する。また、「リソースビュー」は、「プロセス・リソース」のフレームにおいて選択されたリソースについて、具体的な情報を表示するフレームである。
【００４７】
ここで、図３における状態の区分けについて説明すると、出力部１２は、状態に係る情報を、状態に応じた色で区分けしてモニタに出力する。すなわち、図３の凡例に示すように、実施例１に係る事業情報推定装置における色の区分けとしては、「グレー」、「オレンジ」、「緑」、「黄」、「赤」、および「黒」が用いられる。「グレー」は、プロセスまたはリソースが「不明」な状態であることを示す色であり、「オレンジ」は、情報が不足してプロセスまたはリソースが「推定不能」な状態であることを示す色であり、「緑」は、プロセスまたはリソースが「正常」な状態であることを示す色であり、「黄」は、プロセスが「放置可能」な状態であること、または、リソースが「対処を必要」とする状態であることを示す色であり、「赤」は、プロセスが「優先的に対処を必要」とする状態であることを示す色であり、「黒」は、リソースが「復旧不能」な状態であることを示す色である。
【００４８】
また、図３における度合いの区分けについて説明すると、実施例１に係る事業情報推定装置は、プロセスでリソースが必要となる度合いを、度合いに応じて実線と破線とで区分けしてモニタに出力する。すなわち、図３の凡例に示すように、実施例１に係る事業情報推定装置は、「必要となる度合い」が高い下位のリソースとプロセスとの関係については、実線で示し、「必要となる度合い」が低い下位のリソースとプロセスとの関係については、破線で示す。
【００４９】
なお、図１に示す出力画面と、図３に示す出力画面との違いについて説明すると、図３に示す出力画面は、より多くの情報を一画面に出力することなどを目的として、ユーザインタフェースを変更したものである。もっとも、実施例１に係る事業情報推定装置は、プロセスの状態に係る情報とともにリソースの状態に係る情報を出力し、また、プロセスでリソースが必要となる度合いを出力し、さらに、状態に係る情報や度合いを、状態や度合いに応じた形態で区分けして出力する場合であれば、図１に示す出力画面である場合でも、図３に示す出力画面である場合でも、その他のユーザインタフェースによる出力画面である場合でも、いずれでもよい。また、図１または図３などの出力画面においては、説明の便宜上から、状態に係る情報を区分けする「色」を「パターン」に対応づけて示しているが、実際の出力画面は、「色」によるカラー表示で出力する。
【００５０】
入出力制御ＩＦ部１３は、入力部１１および出力部１２と、記憶部２０および制御部３０との間におけるデータ転送を制御する手段である。
【００５１】
記憶部２０は、制御部３０による各種処理に用いるデータを記憶する手段であり、特にこの発明に密接に関連するものとしては、図２に示すように、関係保持部２１と、推定方針記憶部２２と、出力形態方針記憶部２３と、リソース状態情報記憶部２４と、推定結果記憶部２５とを備える。なお、関係保持部２１は、特許請求の範囲に記載の「保持手順」に対応する。
【００５２】
かかる記憶部２０のなかで、関係保持部２１は、下位のプロセスと、下位のプロセスで利用されるリソースとの関係を、下位のプロセスでリソースが必要となる度合いとともに対応づけて保持する手段である。また、関係保持部２１は、プロセスによって構成される上位のプロセスと、上位のプロセスを構成する下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに対応づけて保持する手段である。具体的には、関係保持部２１は、後述する推定部３３による推定に用いられる下位のプロセスとリソースとの関係、および、推定部３３による推定に用いられる上位のプロセスと下位のプロセスとの関係を記憶する手段であって、入力部１１によって入力されたデータを記憶する手段である。
【００５３】
ここで、「必要となる度合い」について説明すると、例えば、プロセス『部材調達』と、リソース『取引先』、『要員』、および『情報システム』との間には、「部材の調達を行う要員が不足したり、調達した部材を管理する情報システムがダウンしたとしても、部材を調達することが不可能になるわけではないが、部材の供給元である取引先に重大な問題が発生すると、部材を調達することが不可能になるおそれがある」という「関係」が存在することを、業務の実態に即してあらかじめ仮定することができる。このように仮定された「関係」において、リソース『取引先』は、プロセス『部材調達』で「必要となる度合い」が高いリソース（必要条件）であり、一方、リソース『要員』や『情報システム』は、プロセス『部材調達』で「必要となる度合い」が低いリソース（それ以外）である。
【００５４】
例えば、関係保持部２１は、図４に示すように、上位のプロセス『製造出荷業務』と、『製造出荷業務』を構成する下位のプロセス『部材調達』、『組立製造』、『生産管理』、および『物流』との関係を、上位のプロセスで下位のプロセスが必要となる度合い（「下位プロセス」の隣の「必要度合い」の列に表示）とともに対応づけて保持する。すなわち、図４に示すように、実施例１の事例においては、上位のプロセス『製造出荷業務』で下位のプロセス『組立製造』、『生産管理』、および『物流』が必要となる度合いは高いが、上位のプロセス『製造出荷業務』で下位のプロセス『部材調達』が必要となる度合いは低い。
【００５５】
また、例えば、関係保持部２１は、図４に示すように、下位のプロセス『部材調達』、『組立製造』、『生産管理』、および『物流』と、リソースとの関係を、下位のプロセスでリソースが必要となる度合い（「リソース」の隣の「必要度合い」の列に表示）とともに対応づけて保持する。すなわち、図４に示すように、実施例１の事例においては、下位のプロセス『部材調達』でリソース『取引先』が必要となる度合いは高いが、リソース『要員』および『情報システム』が必要となる度合いは低い。その他の下位のプロセスについても同様である。なお、説明の便宜上から、図４においては、表形式の関係保持部２１を示したが、実際の関係保持部２１は、ＣＳＶ（Comma Separated Values）形式などの所定の形式でデータを記憶する。
【００５６】
推定方針記憶部２２は、推定に用いる方針を記憶する手段である。具体的には、推定方針記憶部２２は、後述する推定部３３によって、リソースの状態に係る情報から下位のプロセスの状態に係る情報が推定される際の方針や、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報が推定される際の方針を記憶する手段であって、入力部１１によって入力され、後述する推定方針受付部３１によって設定を受け付けられたデータを記憶する手段である。
【００５７】
例えば、推定方針記憶部２２は、図５の（Ａ）に示すように、リソースの状態に係る情報から下位のプロセスの状態に係る情報が推定される際の方針を記憶する。図５の（Ａ）に示される方針について説明すると、（Ａ）の一行目の方針は、下位のプロセスとリソースとの関係が、下位のプロセスでリソースが必要となる度合いが高い関係である場合（「必要度合い」の列が「必要条件」の場合）で、かつ、このリソースの状態に係る情報が「復旧不能」な状態である場合、もしくは、同じく下位のプロセスでリソースが必要となる度合いが高い関係である場合で、かつ、このリソースの状態に係る情報が「対処を必要」とする状態である場合のいずれかの場合が、下位のプロセスで利用されるリソースの中に１つ以上存在する時は、この下位のプロセスの状態に係る情報は、「優先的に対処を必要」とする状態であると推定する、という方針である。
【００５８】
また、（Ａ）の二行目の方針は、下位のプロセスとリソースとの関係が、下位のプロセスでリソースが必要となる度合いが低い関係である場合（「必要度合い」の列が「必要条件でない」の場合）で、かつ、このリソースの状態に係る情報が「復旧不能」な状態である場合、もしくは、同じく下位のプロセスでリソースが必要となる度合いが低い関係である場合で、かつ、このリソースの状態に係る情報が「対処を必要」とする状態である場合のいずれかの場合が、下位のプロセスで利用されるリソースの中に１つ以上存在する時は、この下位のプロセスの状態に係る情報は、「放置可能」な状態であると推定する（但し、一行目の方針を充たさないことが前提となる）、という方針である。
【００５９】
また、（Ａ）の三行目の方針は、上記した２つの方針以外の場合、すなわち、下位のプロセスで利用されるリソース全ての状態に係る情報が「正常」な状態である場合は、この下位のプロセスの状態に係る情報は、「正常」な状態であると推定する、という方針である。
【００６０】
また、推定方針記憶部２２は、図５の（Ｂ）に示すように、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報が推定される際の方針を記憶する。図５の（Ｂ）に示される方針について説明すると、（Ｂ）の一行目の方針は、上位のプロセスと下位のプロセスとの関係が、上位のプロセスで下位のプロセスが必要となる度合いが高い関係である場合（「必要度合い」の列が「必要条件」の場合）で、かつ、この下位のプロセスの状態に係る情報が「優先的に対処を必要」とする状態である場合、もしくは、同じく上位のプロセスで下位のプロセスが必要となる度合いが高い関係である場合で、かつ、この下位のプロセスの状態に係る情報が「放置可能」な状態である場合のいずれかの場合が、上位のプロセスで利用される下位のプロセスの中に１つ以上存在する時は、この上位のプロセスの状態に係る情報は、「優先的に対処を必要」とする状態であると推定する、という方針である。
【００６１】
また、（Ｂ）の二行目の方針は、上位のプロセスと下位のプロセスとの関係が、上位のプロセスで下位のプロセスが必要となる度合いが低い関係である場合（「必要度合い」の列が「必要条件でない」の場合）で、かつ、この下位のプロセスの状態に係る情報が「優先的に対処を必要」とする状態である場合、もしくは、同じく上位のプロセスで下位のプロセスが必要となる度合いが低い関係である場合で、かつ、この下位のプロセスの状態に係る情報が「放置可能」な状態である場合のいずれかの場合が、上位のプロセスで利用される下位のプロセスの中に１つ以上存在する時は、この上位のプロセスの状態に係る情報は、「放置可能」な状態であると推定する（但し、一行目の方針を充たさないことが前提となる）、という方針である。
【００６２】
また、（Ｂ）の三行目の方針は、上記した２つの方針以外の場合、すなわち、上位のプロセスを構成する下位のプロセス全ての状態に係る情報が「正常」な状態である場合は、この上位のプロセスの状態に係る情報は、「正常」な状態であると推定する、という方針である。
【００６３】
なお、実施例１においては、推定に用いる方針として図５に示す方針を説明したが、この発明はこれに限定されるものではなく、例えば、上位のプロセスと下位のプロセスとの関係が、上位のプロセスで下位のプロセスが必要となる度合いが高い関係である場合で、かつ、この下位のプロセスの状態に係る情報が「優先的に対処を必要」とする状態である場合にのみ、上位のプロセスの状態に係る情報を「優先的に対処を必要」とする状態であると推定する、といった方針など、事業の形態や状況に即して適切な推定が可能な方針であれば、具体的な方針の内容はいずれでもよい。
【００６４】
出力形態方針記憶部２３は、出力の形態に係る方針を記憶する手段である。具体的には、出力形態方針記憶部２３は、後述する形態出力部３４によって、プロセスやリソースの状態に係る情報や必要となる度合いが、状態や度合いに応じた形態で区分けされて出力される際の方針を記憶する手段であって、入力部１１によって入力され、後述する出力形態方針受付部３２によって設定を受け付けられたデータを記憶する手段である。
【００６５】
例えば、出力形態方針記憶部２３は、図６に示すように、プロセスやリソースの状態に係る情報が、状態に応じた色で区分けされて出力される際の方針を記憶する。図６に示される方針について説明すると、一行目の方針は、プロセスの状態に係る情報が、状態に応じた色で区分けされて出力される際の方針であり、出力形態方針記憶部２３は、「緑」は、プロセスが「正常」な状態であることを示す色であり、「黄」は、プロセスが「放置可能」な状態であることを示す色であり、「赤」は、プロセスが「優先的に対処を必要」とする状態であることを示す色である、との方針を記憶する。
【００６６】
また、二行目の方針は、リソースの状態に係る情報が、状態に応じた色で区分けされて出力される際の方針であり、出力形態方針記憶部２３は、「緑」は、リソースが「正常」な状態であることを示す色であり、「黄」は、リソースが「対処を必要」とする状態であることを示す色であり、「黒」は、リソースが「復旧不能」な状態であることを示す色である、との方針を記憶する。
【００６７】
なお、実施例１においては、出力形態方針記憶部２３が記憶する方針として、プロセスやリソースの状態に係る情報が、状態に応じた色で区分けされて出力される際の方針を説明したが、この発明はこれに限定されるものではなく、状態に応じた処理（例えば、「優先的に対処を必要」とする状態である場合には、メールを送信するなど）で区分けされて出力される際の方針など、状態に応じた形態で区分けされて出力される際の方針であれば、いずれでもよい。また、図６においては、出力形態方針記憶部２３が記憶する方針として、状態に応じた形態で区分けされて出力される際の方針の場合を説明したが、出力形態方針記憶部２３は、必要となる度合いに応じた形態で区分けされて出力される際の方針などについても記憶する。
【００６８】
リソース状態情報記憶部２４は、リソースの状態に係る情報を記憶する手段である。具体的には、リソース状態情報記憶部２４は、後述する推定部３３によって、リソースの状態に係る情報からプロセスの状態に係る情報が推定される際に用いられるリソースの状態に係る情報を記憶する手段であって、入力部１１によって入力されたデータを記憶する手段である。
【００６９】
例えば、リソース状態情報記憶部２４は、図７に示すように、リソースとリソースの状態に係る情報とを対応づけて記憶する。図７は、入力部１１によって入力されたリソースの状態に係る情報の一例を示したものであるが、リソース『取引先』の状態に係る情報が「対処を必要」とする状態であることを示し（対処要）、リソース『建物設備』の状態に係る情報が「復旧不能」な状態であることを示し（復旧不能）、リソース『情報システム』の状態に係る情報が「正常」な状態であることを示し（正常）、その他のリソースについても同様に、リソースの状態に係る情報を示している。
【００７０】
推定結果記憶部２５は、推定された結果を記憶する手段である。具体的には、推定結果記憶部２５は、後述する形態出力部３４によって所定の出力部に出力される際に用いられる推定結果を記憶する手段であって、後述する推定部３３によって、リソースの状態に係る情報から下位のプロセスの状態に係る情報が推定された結果や、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報が推定された結果を記憶する手段である。
【００７１】
例えば、推定結果記憶部２５は、図８に示すように、上位のプロセスと推定結果とを対応づけて保持し、下位のプロセスと推定結果とを対応づけて保持する。図８は、推定部３３によって推定された推定結果の一例を示したものであるが、上位のプロセス『製造出荷業務』の状態に係る情報の推定結果が「優先的に対処を必要」とする状態であることを示し（優先対処要）、下位のプロセス『部材調達』の状態に係る情報の推定結果が「優先的に対処を必要」とする状態であることを示し（優先対処要）、下位のプロセス『組立製造』の状態に係る情報の推定結果が「優先的に対処を必要」とする状態であることを示し（優先対処要）、下位のプロセス『生産管理』の状態に係る情報の推定結果が「放置可能」な状態であることを示し（放置可）、下位のプロセス『物流』の状態に係る情報の推定結果が「正常」な状態であることを示している（正常）。
【００７２】
なお、図８においては、推定結果記憶部２５が、上位のプロセスと推定結果と下位のプロセスと推定結果とを対応づけて記憶する他に、上位のプロセスで下位のプロセスが必要となる度合いと、下位のプロセスで利用されるリソースと、下位のプロセスでリソースが必要となる度合いと、各々のリソースの状態に係る情報とを対応づけてさらに記憶する場合を示したが、この発明はこれに限定されるものではなく、推定結果記憶部２５は、上位のプロセスと推定結果と下位のプロセスと推定結果とを対応づけて記憶するのみで、他の記憶部（例えば、関係保持部２１、リソース状態情報記憶部２４など）と、ＲＤＢ（Relational Data Base）などの仕組みを用いて連携する場合など、事業情報推定装置において所定のデータを対応づけて記憶している場合であれば、データベースの設計方針はいずれでもよい。なお、説明の便宜上から、図８においては、表形式の推定結果記憶部２５を示したが、実際の推定結果記憶部２５は、ＣＳＶ（Comma Separated Values）形式などの所定の形式でデータを記憶する。
【００７３】
ここで、図２に戻ると、制御部３０は、事業情報推定装置１０を制御して各種処理を実行する手段であり、特にこの発明に密接に関連するものとしては、図２に示すように、推定方針受付部３１と、出力形態方針受付部３２と、推定部３３と、形態出力部３４とを備える。なお、推定部３３は、特許請求の範囲に記載の「推定手順」に対応する。
【００７４】
かかる制御部３０のなかで、推定方針受付部３１は、推定に用いる方針について設定を受け付ける手段である。具体的には、推定方針受付部３１は、後述する推定部３３によって、リソースの状態に係る情報からプロセスの状態に係る情報が推定される際の方針や、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報が推定される際の方針であって、入力部１１によって入力された設定を受け付ける手段であり、設定を受け付けた方針を、推定方針記憶部２２に記憶させる。
【００７５】
例えば、推定方針受付部３１は、図５の（Ａ）に示すような、リソースの状態に係る情報からプロセスの状態に係る情報が推定される際の方針や、図５の（Ｂ）に示すような、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報が推定される方針について、設定を受け付ける。
【００７６】
出力形態方針受付部３２は、出力の形態に係る方針について設定を受け付ける手段である。具体的には、出力形態方針受付部３２は、後述する形態出力部３４によって、プロセスやリソースの状態に係る情報や必要となる度合いが、状態や度合いに応じた形態で区分けされて出力される際の方針であって、入力部１１によって入力された設定を受け付ける手段であり、設定を受け付けた方針を、出力形態方針記憶部２３に記憶させる。
【００７７】
例えば、出力形態方針受付部３２は、図６に示すような、プロセスやリソースの状態に係る情報が、状態に応じた色で区分けされて出力される際の方針について、設定を受け付ける。
【００７８】
推定部３３は、リソースの状態に係る情報からプロセスの状態に係る情報を推定する手段である。具体的には、推定部３３は、関係保持部２１に記憶されたプロセスとリソースとの関係に基づいて、推定方針記憶部２２に記憶された推定に用いる方針に従って、リソース状態情報記憶部２４に記憶されたリソースの状態に係る情報からプロセスの状態に係る情報を推定し、推定した結果を、推定結果記憶部２５に記憶させる。
【００７９】
また、推定部３３は、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報をさらに推定する手段である。具体的には、推定部３３は、関係保持部２１に記憶された上位のプロセスと下位のプロセスとの関係に基づいて、推定方針記憶部２２に記憶された推定に用いる方針に従って、推定結果記憶部２５に記憶された下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報をさらに推定し、推定した結果を、推定結果記憶部２５に記憶させる。
【００８０】
ここで、図８を用いて、実施例１における推定部３３の推定について、具体的に例を挙げて説明する。推定部３３は、下位のプロセス『部材調達』と、下位のプロセス『部材調達』で利用されるリソース『取引先』、『要員』、および『情報システム』との関係（順に、必要条件、必要条件でない、必要条件でない）に基づいて、リソース『取引先』、『要員』、および『情報システム』の状態に係る情報から、下位のプロセス『部材調達』の状態に係る情報を推定する。
【００８１】
図８において示される一例では、リソース『取引先』の状態に係る情報が「対処を必要」とする状態であり、リソース『要員』の状態に係る情報が「対処を必要」とする状態であり、リソース『情報システム』の状態に係る情報が「正常」な状態である。次に、実施例１における推定部３３は、推定方針記憶部２２に記憶された推定に用いる方針に従って推定を行うので、図５の（Ａ）に示される方針を参照し、必要条件であるリソース『取引先』の状態に係る情報が「対処を必要」とする状態である場合は、下位のプロセス『部材調達』の状態に係る情報は、「優先的に対処を必要」とする状態であると推定する。
【００８２】
ところで、下位のプロセス『部材調達』の状態に係る情報の推定結果は、他のリソースの状態に係る情報による推定結果に優先する。すなわち、例えば、必要条件でないリソース『要員』の状態に係る情報が「対処を必要」とする状態である場合は、下位のプロセス『部材調達』の状態に係る情報は、「放置可能」な状態である、と一旦推定することができる。しかしながら、結局、必要条件であるリソース『取引先』の状態に係る情報に基づく推定結果によって、「放置可能」な状態であるとの推定結果は覆る。
【００８３】
このように、下位のプロセスの状態に係る情報の推定は、下位のプロセスで利用されるリソースのうち、いずれのリソースの状態に係る情報に基づいて推定するかによって推定結果が異なってくる場合がある。したがって、実施例１における推定部３３は、下位のプロセスで利用されるリソースの中に必要条件であるリソースが存在する場合には、必要条件であるリソースの状態に係る情報の推定結果を優先することとし、必要条件であるリソースの状態に係る情報が「不明」な状態である場合には、下位のプロセスの状態に係る情報は「推定不能」な状態であると位置づける。
【００８４】
また、下位のプロセスの状態に係る情報の推定は、下位のプロセスで利用される複数のリソースのうち、一部のリソースの状態に係る情報が欠けていると、正しい推定結果が得られない場合がある。したがって、実施例１における推定部３３は、一部のリソースの状態に係る情報が欠けているために正しい推定結果が得られない場合には、下位のプロセスの状態に係る情報は「推定不能」な状態であると位置づける。
【００８５】
また、他の例では、推定部３３は、上位のプロセス『製造出荷業務』と、上位のプロセス『製造出荷業務』を構成する下位のプロセス『部材調達』、『組立製造』、『生産管理』、および『物流』との関係（順に、必要条件でない、必要条件、必要条件、必要条件）に基づいて、下位のプロセス『部材調達』、『組立製造』、『生産管理』、および『物流』の状態に係る情報から、上位のプロセス『製造出荷業務』の状態に係る情報を推定する。
【００８６】
図８において示される一例では、プロセス『部材調達』の状態に係る情報が「優先的に対処を必要」とする状態であり、プロセス『組立製造』の状態に係る情報が「優先的に対処を必要」とする状態であり、プロセス『生産管理』の状態に係る情報が「放置可能」な状態であり、プロセス『物流』の状態に係る情報が「正常」な状態である。次に、実施例１における推定部３３は、推定方針記憶部２２に記憶された推定に用いる方針に従って推定を行うので、図５の（Ｂ）に示される方針を参照し、必要条件であるプロセス『組立製造』の状態に係る情報が「優先的に対処を必要」とする状態である場合は、上位のプロセス『製造出荷業務』の状態に係る情報は、「優先的に対処を必要」とする状態であると推定する。
【００８７】
形態出力部３４は、推定されたプロセスの状態に係る情報と、リソースの状態に係る情報と、プロセスでリソースが必要となる度合いと、上位のプロセスで下位のプロセスが必要となる度合いとを、状態や度合いに応じた形態で区分けして出力させる手段である。具体的には、形態出力部３４は、推定結果記憶部２５に記憶されたプロセスの状態に係る情報の推定結果と、リソースの状態の係る情報と、プロセスでリソースが必要となる度合いと、上位のプロセスで下位のプロセスが必要となる度合いとを、出力形態方針記憶部２３に記憶された出力の形態に係る方針に従って、状態や度合いに応じた形態で区分けし、出力部１２に出力させる。
【００８８】
例えば、形態出力部３４は、図８に示すように、下位のプロセス『部材調達』の状態に係る情報の推定結果が、「優先的に対処を必要」とする状態である場合には、図６に示される方針を参照し、「赤」にして出力部１２に出力させる。また、他の例では、形態出力部３４は、図８に示すように、リソース『取引先』の状態に係る情報が、「対処を必要」とする状態である場合には、図６に示される方針を参照し、「黄」にして出力部１２に出力させる。
【００８９】
［実施例１に係る事業情報推定装置による処理の手順］
次に、図９を用いて、実施例１に係る事業情報推定装置による処理の手順を説明する。図９は、実施例１に係る事業情報推定装置による処理の手順を示すフローチャートである。なお、実施例１に係る事業情報推定装置１０は、日常の運用においては、事業を構成するプロセスの状態に係る情報と、プロセスで利用されるリソースの状態に係る情報とについて、「正常」な状態であるとの情報を推定結果記憶部２５において記憶し、形態出力部３４において全ての状態に係る情報を「緑」にして、出力部１２（モニタ）に出力している。以下は、事業情報推定装置１０が、日常の運用から、災害または事故の発生時の運用に切り替わった際の処理の手順を示すものである。
【００９０】
まず、実施例１に係る事業情報推定装置１０は、災害または事故の発生による事業情報推定開始の指示を受け付けたか否かを判断する（ステップＳ９０１）。指示を受け付けていない場合には（ステップＳ９０１否定）、事業情報推定装置１０は、事業情報推定開始の指示を待機する処理に戻る。
【００９１】
一方、指示を受け付けた場合には（ステップＳ９０１肯定）、事業情報推定装置１０は、プロセスの状態に係る情報とリソースの状態に係る情報とについて、全て「不明」な状態であるとの情報を推定結果記憶部２５において記憶し、形態出力部３４において全ての状態に係る情報を「グレー」にして、出力部１２に出力する（ステップＳ９０２）。
【００９２】
次に、事業情報推定装置１０は、リソースの状態に係る情報の入力を受け付けたか否かを判断する（ステップＳ９０３）。入力を受け付けていない場合には（ステップＳ９０３否定）、事業情報推定装置１０は、リソースの状態に係る情報の入力の受け付けを待機する処理に戻る。
【００９３】
一方、入力を受け付けた場合には（ステップＳ９０３肯定）、事業情報推定装置１０は、入力を受け付けたリソースの状態に係る情報について、推定結果記憶部２５において記憶し、形態出力部３４において所定の色にして、出力部１２に出力する（ステップＳ９０４）。
【００９４】
そして、事業情報推定装置１０は、推定部３３において、下位のプロセスとリソースとの関係に基づいて、リソースの状態に係る情報から下位のプロセスの状態に係る情報の推定を試行する（ステップＳ９０５）。ここで、実施例１に係る事業情報推定装置１０は、推定部３３において、入力を受け付けたリソースと関係のある下位のプロセスについて、推定を試行する。
【００９５】
続いて、事業情報推定装置１０は、下位のプロセスの状態に係る情報を推定できたか否かを判断する（ステップＳ９０６）。ここで、実施例１に係る事業情報推定装置１０は、入力を受け付けたリソースによって（または、過去に入力を受け付けたリソースとともに）推定することでは、一意の推定もしくは正しい推定をできない場合には、推定できなかった場合であると判断する。推定できなかった場合には（ステップＳ９０６否定）、事業情報推定装置１０は、下位のプロセスの状態に係る情報について、「推定不能」な状態であるとの情報を推定結果記憶部２５において記憶し、形態出力部３４において、この下位のプロセスの状態に係る情報を「オレンジ」にして、出力部１２に出力する（ステップＳ９１２）。そして、事業情報推定装置１０は、リソースの状態に係る情報の入力の受け付けを待機する処理に戻る。
【００９６】
一方、推定できた場合には（ステップＳ９０６肯定）、事業情報推定装置１０は、推定された下位のプロセスの状態に係る情報について、推定結果を推定結果記憶部２５において記憶し、形態出力部３４において、この下位のプロセスの状態に係る情報を所定の色にして、出力部１２に出力する（ステップＳ９０７）。
【００９７】
次に、事業情報推定装置１０は、推定部３３において、上位のプロセスと下位のプロセスとの関係に基づいて、上位のプロセスの状態に係る情報から下位のプロセスの状態に係る情報の推定を試行する（ステップＳ９０８）。
【００９８】
続いて、事業情報推定装置１０は、上位のプロセスの状態に係る情報を推定できたか否かを判断する（ステップＳ９０９）。ここで、実施例１に係る事業情報推定装置１０は、下位のプロセスの状態に係る情報によって（または、過去に推定された下位のプロセスの状態に係る情報とともに）推定することでは、一意の推定もしくは正しい推定をできない場合には、推定できなかった場合であると判断する。推定できなかった場合には（ステップＳ９０９否定）、事業情報推定装置１０は、上位のプロセスの状態に係る情報について、「推定不能」な状態であるとの情報を推定結果記憶部２５において記憶し、形態出力部３４において、この上位のプロセスの状態に係る情報を「オレンジ」にして、出力部１２に出力する（ステップＳ９１３）。そして、事業情報推定装置１０は、リソースの状態に係る情報の入力の受け付けを待機する処理に戻る。
【００９９】
一方、推定できた場合には（ステップＳ９０９肯定）、事業情報推定装置１０は、推定された上位のプロセスの状態に係る情報について、推定結果を推定結果記憶部２５において記憶し、形態出力部３４において、この上位のプロセスの状態に係る情報を所定の色にして、出力部１２に出力する（ステップＳ９１０）。
【０１００】
次に、事業情報推定装置１０は、他に入力可能なリソースの状態に係る情報があるか否かを判断する（ステップＳ９１１）。ある場合には（ステップＳ９１１肯定）、事業情報推定装置１０は、リソースの状態に係る情報の入力の受け付けを待機する処理に戻る。一方、他に入力可能なリソースの状態に係る情報がない場合には（ステップＳ９１１否定）、事業情報推定装置１０は、事業情報推定の処理を終了する。
【０１０１】
このようにして、実施例１に係る事業情報推定装置１０は、被害状況に応じて多様に変動する業務の状況を推定する（リソースの被害状況に応じて変動するプロセスの状態を推定する）結果、災害や事故に伴う業務の変動状況を推定することが可能になる。また、実施例１に係る事業情報推定装置１０は、多段の業務によって構成された事業においても、被害状況に応じて多様に変動する業務の状況を推定する（リソースの被害状況に応じて変動するプロセスの状態を推定し、状態を推定されたプロセスによって構成されるプロセスの状態をさらに推定する）結果、多段の業務によって構成された事業においても、災害や事故に伴う業務の変動状況を推定することが可能になる。
【０１０２】
なお、実施例１においては、事業情報推定装置１０が、リソースの状態に係る情報の入力を受け付けるごとに、リソースの状態に係る情報から下位のプロセスの状態に係る情報の推定を試行し、推定できたか否かを判断して次の処理に移行し、また、下位のプロセスの状態に係る情報が推定されるごとに、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報の推定を試行し、推定できたか否かを判断して次の処理に移行する場合を説明したが、この発明はこれに限定されるものではなく、全てのリソースの状態に係る情報の入力を受け付けてから、リソースの状態に係る情報から下位のプロセスの状態に係る情報を推定し、全ての下位のプロセスの状態に係る情報が推定されてから、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報を推定する場合や、必要条件であるリソースの状態に係る情報の入力を優先的に受け付けて、下位のプロセスの状態に係る情報も上位のプロセスの状態に係る情報も推定できる段階で随時推定する場合など、処理の順番はいずれでもよい。
【０１０３】
［実施例１の効果］
上記したように、実施例１によれば、事業に係る情報を推定する方法をコンピュータに実行させる事業情報推定プログラムであって、事業を構成するプロセスとプロセスで利用されるリソースとの関係を、プロセスでリソースが必要となる度合いとともに対応づけて保持し、保持されたプロセスとリソースとの関係に基づいて、リソースの状態に係る情報からプロセスの状態に係る情報を推定するので、被害状況に応じて多様に変動する業務の状況などを推定する（リソースの被害状況に応じて変動するプロセスの状態を推定する）結果、災害や事故に伴う業務の変動状況を推定することが可能になる。また、災害等で直接のダメージを受けた目の前のリソース（例えば、要員、設備、資機材など）の状態に係る情報が入力されるだけでプロセスの状態を推定する結果、事実として存在する単純な情報を収集するのみで、業務の変動状況を推定することが可能になる。
【０１０４】
また、実施例１によれば、プロセスによって構成される上位のプロセスと上位のプロセスを構成する下位のプロセスとの関係を、上位のプロセスで下位のプロセスが必要となる度合いとともに対応づけてさらに保持し、保持された上位のプロセスと下位のプロセスとの関係に基づいて、下位のプロセスの状態に係る情報から上位のプロセスの状態に係る情報をさらに推定するので、多段の業務によって構成された事業においても、被害状況に応じて多様に変動する業務の状況を推定する（リソースの被害状況に応じて変動するプロセスの状態を推定し、状態を推定されたプロセスによって構成されるプロセスの状態をさらに推定する）結果、多段の業務によって構成された事業においても、災害や事故に伴う業務の変動状況を推定することが可能になる。
【０１０５】
また、実施例１によれば、リソースの状態に係る情報が、リソースが正常な状態であることを示す情報、リソースが対処を必要とする状態であることを示す情報、またはリソースが復旧不能な状態であることを示す情報のいずれであるかに応じて、プロセスの状態に係る情報を推定するので、３段階で判定されたリソースの状態に係る情報からプロセスの状態を推定する結果、災害や事故に伴う業務の変動状況を、複雑な判定をせずに簡易に推定することが可能になる。
【０１０６】
また、実施例１によれば、プロセスの状態に係る情報として、プロセスが正常な状態であることを示す情報、プロセスが放置可能な状態であることを示す情報、またはプロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定するので、プロセスの状態を３段階で推定する結果、災害や事故に伴う業務の変動状況を、単純に推定することが可能になる。
【０１０７】
また、実施例１によれば、推定に用いる方針について設定を受け付け、設定が受け付けられた推定に用いる方針に従って、リソースの状態に係る情報からプロセスの状態に係る情報を推定するので、状況が変化した場合などには、変更された方針に従って推定する結果、災害や事故に伴う業務の変動状況を、状況に応じて臨機応変に推定することが可能になる。
【０１０８】
また、実施例１によれば、推定されたプロセスの状態に係る情報を所定の出力部（例えば、モニタ、スピーカ、通信部など）に出力するので、推定されたプロセスの状態に係る情報が出力される結果、災害や事故に伴う業務の変動状況を、意思決定者に把握させることが可能になる。
【０１０９】
また、実施例１によれば、リソースの状態に係る情報から推定されたプロセスの状態に係る情報とともに、リソースの状態に係る情報をさらに出力するので、推定されたプロセスの状態に係る情報とともに、リソースの状態に係る情報が出力される結果、災害や事故に伴う業務の変動状況と業務で利用されるリソースの情報とを、意思決定者に把握させることが可能になる。
【０１１０】
また、実施例１によれば、リソースの状態に係る情報から推定されたプロセスの状態に係る情報とリソースの状態に係る情報とともに、プロセスでリソースが必要となる度合いをさらに出力するので、プロセスを復旧するために必要となるリソースの優先順位を、意思決定者に認識させることが可能になる。また、多数のプロセスにおいて必要となる度合いが高いとされるリソースは重要なリソースであることや、いずれのプロセスにおいても必要となる度合いが高いとされないリソースは重要なリソースではないことなどを、意思決定者に認識させることが可能になる。
【０１１１】
また、実施例１によれば、状態に係る情報および／または度合いを、状態および／または度合いに応じた形態で区分けして出力するので、プロセスやリソースの状態、プロセスでリソースが必要となる度合いなどを、意思決定者に直感的に認識させることが可能になる。また、例えば、状態に係る情報の出力について、トリアージ（医療機能が制約される状況下で、一人でも多くの傷病者に対して最善の治療を行うことを目的として、傷病者の緊急度や重症度などに応じて治療の優先順位を決めること）で採用されている識別色（重症群（赤）、中等症群（黄）、軽症群（緑）、死亡群（黒））の考え方を導入すると、状態に係る情報を、意思決定者により直感的に認識させることが可能になる。
【０１１２】
また、実施例１によれば、形態に係る方針について設定を受け付け、設定が受け付けられた形態に係る方針に従って出力するので、プロセスやリソースの状態、プロセスでリソースが必要となる度合いなどを、臨機応変に変化させて、意思決定者に直感的に認識させることが可能になる。
【実施例２】
【０１１３】
さて、これまで実施例１として、リソースの状態に係る情報が、リソースが復旧不能な状態であることを示す情報である場合に、事業情報推定装置が、リソースの状態に係る情報が「復旧不能」な状態であることを示す情報のみをモニタに出力する手法を説明したが、この発明はこれに限定されるものではなく、事業情報推定装置が、リソースの代替リソースをさらにモニタに出力する手法にも、この発明を同様に適用することができる。以下では、実施例２として、事業情報推定装置が、リソースの代替リソースをさらにモニタに出力する手法について、図１０を用いて説明する。図１０は、代替リソースの出力を説明するための図である。
【０１１４】
実施例２に係る事業情報推定装置は、関係保持部において、下位のプロセスと、下位のプロセスで利用されるリソースとの関係を、下位のプロセスでリソースが必要となる度合いとともに対応づけて保持する他に、実施例１と異なり、代替可能なリソースについては、リソースと代替リソースとを対応づけて保持する。例えば、リソース『建物設備』の代替リソースとして、『代替設備』を対応づけて保持する。また、実施例２に係る事業情報推定装置は、推定結果記憶部において、同様に、リソースと代替リソースとを対応づけて保持する。
【０１１５】
なお、実施例２においては、リソースと代替リソースとを対応づけた情報を、関係保持部と推定結果記憶部とにそれぞれ保持する場合を説明したが、関係保持部における代替リソースの情報を、ＲＤＢなどの仕組みを用いて推定結果記憶部において連携して保持する場合など、事業情報推定装置においてデータを対応づけて保持している場合であれば、データベースの設計方針はいずれでもよい。
【０１１６】
また、実施例２に係る事業情報推定装置は、出力形態方針記憶部において、リソースの状態に係る情報が、状態に応じた色で区分けされて出力される際の方針を記憶する他に、実施例１と異なり、代替可能なリソースが「復旧不能」な状態である場合には、代替リソースが出力されるという方針を記憶する。例えば、リソース『建物設備』が「復旧不能」な状態である場合には、代替リソース『代替設備』が出力されるという方針を記憶する。
【０１１７】
また、実施例２に係る事業情報推定装置は、形態出力部において、推定されたプロセスの状態に係る情報と、リソースの状態に係る情報と、プロセスでリソースが必要となる度合いと、上位のプロセスで下位のプロセスが必要となる度合いとを、状態や度合いに応じた形態で区分けして出力する他に、実施例１と異なり、代替可能なリソースが「復旧不能」な状態である場合には、代替リソースをさらに出力部に出力させる。
【０１１８】
例えば、図１０に示すように、下位のプロセス『組立製造』で利用されるリソース『建物設備』の状態に係る情報が「復旧不能」な状態である場合には、実施例２に係る事業情報推定装置は、出力形態方針記憶部において記憶する方針を参照するとともに、関係保持部（または、推定結果記憶部）に保持した代替リソースを参照し、代替リソース『代替設備』をさらにモニタに出力させる。
【０１１９】
なお、図１０において、代替リソース『代替設備』の状態に係る情報が、「正常」な状態であることを示す情報（緑）ではなく、「対処を必要」とする状態であることを示す情報（黄）であるのは、『代替設備』が現在立ち上げ中で、未だ正常稼働の状態に至っていないことを示す意味である。
【０１２０】
このようにして、実施例２に係る事業情報推定装置は、代替可能なリソースが復旧不能な状態になった場合には、意思決定者に代替リソースを認識させることが可能になる。
【実施例３】
【０１２１】
また、これまで、実施例１に係る事業情報推定装置の出力画面として図１または図３に示す出力画面を説明し、実施例２に係る事業情報推定装置の出力画面として図１０に示す出力画面を説明したが、この発明はこれに限定されるものではなく、プロセスの状態に係る情報とともにリソースの状態に係る情報を出力し、また、プロセスでリソースが必要となる度合いを出力し、さらに、状態に係る情報や度合いを、状態や度合いに応じた形態で区分けして出力する場合であれば、その他のユーザインタフェースによる出力画面でもよい。以下では、実施例３に係る事業情報推定装置の出力画面として、図１１を説明する。図１１は、実施例３に係る事業情報推定装置の出力画面を説明するための図である。
【０１２２】
実施例３に係る事業情報推定装置の出力画面は、図１１に示すように、特に、度合いに応じた形態で区分けして出力する方針が、実施例１または実施例２と異なる。具体的に説明すると、図１１において、上位のプロセス『製造出荷業務』、下位のプロセス『組立製造』、『生産管理』、および『物流』については、プロセスの状態に係る情報が、「面塗り」で出力されている。一方、下位のプロセス『部材調達』については、プロセスの状態に係る情報が、「枠塗り」で出力されている。
【０１２３】
この「面塗り」と「枠塗り」との違いについて説明すると、実施例３に係る事業情報推定装置は、上位のプロセスで下位のプロセスが必要となる度合いを、度合いに応じて「面塗り」と「枠塗り」とで区分けしてモニタに出力する。すなわち、図１１の凡例に示すように、実施例３に係る事業情報推定装置は、「必要となる度合い」が高い上位のプロセスと下位のプロセスとの関係については、「面塗り」で出力し、「必要となる度合い」が低い上位のプロセスと下位のプロセスとの関係については、「枠塗り」で出力する。
【０１２４】
すなわち、図１１における出力画面は、上位のプロセス『製造出荷業務』で、下位のプロセス『組立製造』、『生産管理』、および『物流』が「必要となる度合い」は高いが、下位のプロセス『部材調達』については、「必要となる度合い」が低いことを示している。なお、図１１においては、上位のプロセスで下位のプロセスが必要となる度合いのみを、度合いに応じて「面塗り」と「枠塗り」とで区分けしてモニタに出力する出力画面を示したが、下位のプロセスでリソースが必要となる度合いも、度合いに応じて「面塗り」と「枠塗り」とで区分けしてモニタに出力してもよい。
【実施例４】
【０１２５】
ところで、これまで、実施例１〜実施例３に係る事業情報推定装置について説明したが、この発明は上記した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、実施例４に係る事業情報推定装置として、異なる実施例を説明する。
【０１２６】
［推定手法］
上記の実施例では、事業情報推定装置が、多段のプロセスで構成された事業（プロセスによって構成される上位のプロセスと、上位のプロセスを構成する下位のプロセスとで構成された事業）に係る情報を推定する場合を説明したが、この発明はこれに限定されるものではなく、一段のプロセスで構成された事業に係る情報を推定する場合にも、この発明を同様に適用することができる。この場合には、事業情報推定装置は、プロセスとリソースとの関係のみを保持し、リソースの状態に係る情報からプロセスの状態に係る情報のみを推定することになる。
【０１２７】
また、上記の実施例では、リソースの状態に係る情報が、リソースが正常な状態であることを示す情報、リソースが対処を必要とする状態であることを示す情報、またはリソースが復旧不能な状態であることを示す情報のいずれであるかに応じて、事業情報推定装置がプロセスの状態に係る情報を推定する場合を説明したが、この発明はこれに限定されるものではなく、リソースの状態に係る情報として、リソースが緊急な対処を必要とする状態であることを示す情報を加え、リソースの状態に係る情報が４つの情報のいずれであるかに応じて（リソースの状態に係る情報が、リソースが正常な状態であることを示す情報、リソースが対処を必要とする状態であることを示す情報、リソースが緊急な対処を必要とする状態であることを示す情報、またはリソースが復旧不能な状態であることを示す情報のいずれであるかに応じて）、プロセスの状態に係る情報を推定する場合など、リソースの状態に係る情報の種類や数が異なる場合にも、この発明を同様に適用することができる。
【０１２８】
また、上記の実施例では、事業情報推定装置が、プロセスの状態に係る情報として、プロセスが正常な状態であることを示す情報、プロセスが放置可能な状態であることを示す情報、またはプロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定する場合を説明したが、この発明はこれに限定されるものではなく、プロセスの状態に係る情報として、プロセスが対処を必要とする状態であることを示す情報を加え、プロセスの状態に係る情報が４つの情報のいずれかを推定する場合（プロセスの状態に係る情報が、プロセスが正常な状態であることを示す情報、プロセスが放置可能な状態であることを示す情報、プロセスが対処を必要とする状態であることを示す情報、またはプロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定する場合）など、プロセスの状態に係る情報の種類や数が異なる場合にも、この発明を同様に適用することができる。
【０１２９】
また、上記の実施例では、事業情報推定装置が、推定に用いる方針について設定を受け付け、設定を受け付けた方針に従って、リソースの状態に係る情報からプロセスの状態に係る情報を推定する場合を説明したが、この発明はこれに限定されるものではなく、事業情報推定装置があらかじめ保持する推定に用いる方針に従って、リソースの状態に係る情報からプロセスの状態に係る情報を推定する場合にも、この発明を同様に適用することができる。
【０１３０】
［出力手法］
また、上記の実施例では、事業情報推定装置が、プロセスの状態に係る情報とリソースの状態に係る情報とともに、プロセスでリソースが必要となる度合いを出力する場合を説明したが、この発明はこれに限定されるものではなく、事業情報推定装置が、プロセスでリソースが必要となる度合いを出力せずに、プロセスの状態に係る情報およびリソースの状態に係る情報のみを出力する場合や、プロセスでリソースが必要となる度合いおよびリソースの状態に係る情報を出力せずに、プロセスの状態に係る情報のみを出力する場合や、いずれも出力しない場合にも、この発明を同様に適用することができる。いずれも出力しない場合には、推定されたプロセスの状態に係る情報などを、事業情報推定装置が保持し、必要に応じて利用されることなどが考えられる。
【０１３１】
また、上記の実施例では、状態に係る情報や度合いを、状態に応じた色で区分けして出力し、度合いに応じた線種で区分けして出力する場合を説明したが、この発明はこれに限定されるものではなく、状態に係る情報をパターンで区分けして出力したり、度合いを線の太さで区分けして出力する場合や、状態に係る情報や度合いを区分けしないで出力する場合などにも、この発明を同様に適用することができる。
【０１３２】
［システム構成等］
また、上記の実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理（例えば、災害または事故の発生による事業情報推定開始の指示を受け付けた場合に、全ての状態に係る情報を「不明」な状態であると記憶させる処理など）の全部または一部を手動的におこなう（例えば、コマンドを入力することによって、全ての状態に係る情報を「不明」な状態であると記憶させるなど）こともでき、あるいは、手動的におこなわれるものとして説明した処理（例えば、リソースの状態に係る情報の入力など）の全部または一部を公知の方法で自動的におこなう（例えば、災害または事故の発生により自動的にリソースの状態に係る情報を収集するなど）こともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【０１３３】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示（例えば、図２など）のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる（例えば、関係保持部とリソース状態情報記憶部と推定結果記憶部とをひとつの記憶部に統合するなど）。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【０１３４】
［プログラム］
ところで、上記の実施例で説明した各種の処理は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１２を用いて、上記の実施例と同様の機能を有する事業情報推定プログラムを実行するコンピュータの一例を説明する。図１２は、事業情報推定プログラムを実行するコンピュータを示す図である。
【０１３５】
図１２に示すように、コンピュータ４０は、キャッシュ４１、ＲＡＭ４２、ＨＤＤ４３、ＲＯＭ４４およびＣＰＵ４５をバス４６で接続して構成される。ここで、ＲＯＭ４４には、上記の実施例と同様の機能を発揮する事業情報推定プログラム、つまり、図１２に示すように、推定方針受付プログラム４４ａと出力形態方針受付プログラム４４ｂと推定プログラム４４ｃと形態出力プログラム４４ｄとがあらかじめ記憶されている。
【０１３６】
そして、ＣＰＵ４５は、これらのプログラム４４ａと４４ｂと４４ｃと４４ｄとを読み出して実行することで、図１２に示すように、各プログラム４４ａと４４ｂと４４ｃと４４ｄとは、推定方針受付プロセス４５ａと出力形態方針受付プロセス４５ｂと推定プロセス４５ｃと形態出力プロセス４５ｄとなる。なお、各プロセス４５ａと４５ｂと４５ｃと４５ｄとは、図２に示した、推定方針受付部３１と出力形態方針受付部３２と推定部３３と形態出力部３４とにそれぞれ対応する。
【０１３７】
また、ＨＤＤ４３には、図１２に示すように、関係保持テーブル４３ａと推定方針テーブル４３ｂと出力形態方針テーブル４３ｃとリソース状態情報テーブル４３ｄと推定結果テーブル４３ｅとが設けられる。なお、各テーブル４３ａと４３ｂと４３ｃと４３ｄと４３ｅとは、図２に示した、関係保持部２１と推定方針記憶部２２と出力形態方針記憶部２３とリソース状態情報記憶部２４と推定結果記憶部２５とにそれぞれ対応する。
【０１３８】
ところで、上記した各プログラム４４ａと４４ｂと４４ｃと４４ｄとについては、必ずしもＲＯＭ４４に記憶させておく必要はなく、例えば、コンピュータ４０に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯディスク、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ４０の内外に備えられるハードディスクドライブ（ＨＤＤ）などの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどのを介してコンピュータ４０に接続される「他のコンピュータ（またはサーバ）」に記憶させておき、コンピュータ４０がこれらからプログラムを読み出して実行するようにしてもよい。
【０１３９】
（付記１）事業に係る情報を推定する方法をコンピュータに実行させる事業情報推定プログラムであって、
事業を構成するプロセスと当該プロセスで利用されるリソースとの関係を、当該プロセスで当該リソースが必要となる度合いとともに対応づけて保持する保持手順と、
前記保持手順によって保持された前記プロセスと前記リソースとの関係に基づいて、当該リソースの状態に係る情報から当該プロセスの状態に係る情報を推定する推定手順と、
をコンピュータに実行させることを特徴とする事業情報推定プログラム。
【０１４０】
（付記２）前記保持手順は、プロセスによって構成される上位のプロセスと当該上位のプロセスを構成する下位のプロセスとの関係を、当該上位のプロセスで当該下位のプロセスが必要となる度合いとともに対応づけてさらに保持し、
前記推定手順は、前記保持手順によって保持された前記上位のプロセスと前記下位のプロセスとの関係に基づいて、当該下位のプロセスの状態に係る情報から当該上位のプロセスの状態に係る情報をさらに推定することを特徴とする付記１に記載の事業情報推定プログラム。
【０１４１】
（付記３）前記推定手順は、前記リソースの状態に係る情報が、当該リソースが正常な状態であることを示す情報、当該リソースが対処を必要とする状態であることを示す情報、または当該リソースが復旧不能な状態であることを示す情報のいずれであるかに応じて、前記プロセスの状態に係る情報を推定することを特徴とする付記１または２に記載の事業情報推定プログラム。
【０１４２】
（付記４）前記推定手順は、前記プロセスの状態に係る情報として、当該プロセスが正常な状態であることを示す情報、当該プロセスが放置可能な状態であることを示す情報、または当該プロセスが優先的に対処を必要とする状態であることを示す情報のいずれかを推定することを特徴とする付記１〜３のいずれかひとつに記載の事業情報推定プログラム。
【０１４３】
（付記５）前記推定に用いる方針について設定を受け付ける推定方針受付手順をさらに備え、
前記推定手順は、前記推定方針受付手順によって設定が受け付けられた前記推定に用いる方針に従って、前記リソースの状態に係る情報から前記プロセスの状態に係る情報を推定することを特徴とする付記１〜４のいずれかひとつに記載の事業情報推定プログラム。
【０１４４】
（付記６）前記推定手順によって推定された前記プロセスの状態に係る情報を所定の出力部に出力する出力手順をさらに備えたことを特徴とする付記１〜５のいずれかひとつに記載の事業情報推定プログラム。
【０１４５】
（付記７）前記出力手順は、前記推定手順によって前記リソースの状態に係る情報から推定された前記プロセスの状態に係る情報とともに、当該リソースの状態に係る情報をさらに出力することを特徴とする付記６に記載の事業情報推定プログラム。
【０１４６】
（付記８）前記出力手順は、リソースの状態に係る情報が、当該リソースが復旧不能な状態であることを示す情報である場合には、当該リソースの代替リソースをさらに出力することを特徴とする付記７に記載の事業情報推定プログラム。
【０１４７】
（付記９）前記出力手順は、前記推定手順によって前記リソースの状態に係る情報から推定された前記プロセスの状態に係る情報と当該リソースの状態に係る情報とともに、当該プロセスで当該リソースが必要となる度合いをさらに出力することを特徴とする付記７または８に記載の事業情報推定プログラム。
【０１４８】
（付記１０）前記出力手順は、前記状態に係る情報および／または前記度合いを、当該状態および／または当該度合いに応じた形態で区分けして出力することを特徴とする付記６〜９のいずれかひとつに記載の事業情報推定プログラム。
【０１４９】
（付記１１）前記形態に係る方針について設定を受け付ける形態方針受付手順をさらに備え、
前記出力手順は、前記形態方針受付手順によって設定が受け付けられた前記形態に係る方針に従って出力することを特徴とする付記１０に記載の事業情報推定プログラム。
【０１５０】
（付記１２）事業に係る情報を推定する事業情報推定方法であって、
事業を構成するプロセスと当該プロセスで利用されるリソースとの関係を、当該プロセスで当該リソースが必要となる度合いとともに対応づけて保持する保持工程と、
前記保持工程によって保持された前記プロセスと前記リソースとの関係に基づいて、当該リソースの状態に係る情報から当該プロセスの状態に係る情報を推定する推定工程と、
を含んだことを特徴とする事業情報推定方法。
【産業上の利用可能性】
【０１５１】
以上のように、本発明に係る事業情報推定プログラム、事業情報推定方法および事業情報推定装置は、事業に係る情報を推定することに有用であり、特に、災害や事故に伴う業務の変動状況を推定することに適する。
【図面の簡単な説明】
【０１５２】
【図１】実施例１に係る事業情報推定装置の概要および特徴を説明するための図である。
【図２】実施例１に係る事業情報推定装置の構成を示すブロック図である。
【図３】出力画面を説明するための図である。
【図４】関係保持部を説明するための図である。
【図５】推定方針記憶部を説明するための図である。
【図６】出力形態方針記憶部を説明するための図である。
【図７】リソース状態情報記憶部を説明するための図である。
【図８】推定結果記憶部を説明するための図である。
【図９】実施例１に係る事業情報推定装置による処理の手順を示すフローチャートである。
【図１０】代替リソースの出力を説明するための図である。
【図１１】実施例３に係る事業情報推定装置の出力画面を説明するための図である。
【図１２】事業情報推定プログラムを実行するコンピュータを示す図である。
【符号の説明】
【０１５３】
１０  事業情報推定装置
１１  入力部
１２  出力部
１３  入出力制御ＩＦ部
２０  記憶部
２１  関係保持部
２２  推定方針記憶部
２３  出力形態方針記憶部
２４  リソース状態情報記憶部
２５  推定結果記憶部
３０  制御部
３１  推定方針受付部
３２  出力形態方針受付部
３３  推定部
３４  形態出力部
４０  コンピュータ
４１  キャッシュ
４２  ＲＡＭ
４３  ＨＤＤ
４４  ＲＯＭ
４５  ＣＰＵ
４６  バス
【図１】
2007305067.tif 000003
【図２】
2007305067.tif 000004
【図３】
2007305067.tif 000005
【図４】
2007305067.tif 000006
【図５】
2007305067.tif 000007
【図６】
2007305067.tif 000008
【図７】
2007305067.tif 000009
【図８】
2007305067.tif 000010
【図９】
2007305067.tif 000011
【図１０】
2007305067.tif 000012
【図１１】
2007305067.tif 000013
【図１２】
2007305067.tif 000014