(57)【要約】【課題】処理の実行状況を効率的に把握すること。【解決手段】記憶部１ａは、関連する処理Ｅ１，Ｅ２，Ｅ３の過去の実行実績を示す情報を記憶する。演算部１ｂは、処理Ｅ１，Ｅ２の実行状況を示す情報を取得する。演算部１ｂは、処理Ｅ１，Ｅ２の実行状況を示す情報を取得した際に、記憶部１ａに記憶された情報に基づいて処理Ｅ１，Ｅ２，Ｅ３のうち未実行の処理Ｅ３が実行済になっていると予測されたタイミングＴ３３で、当該未実行の処理Ｅ３の実行状況を取得する。【選択図】図１
2015022475.tif 000002
【特許請求の範囲】
【請求項１】
関連する複数の処理の実行状況を示す第１の情報を取得し、
前記第１の情報を取得した際に、前記複数の処理の過去の実行実績を示す第２の情報に基づいて前記複数の処理のうち、前記第１の情報を取得したタイミングで未実行の処理が実行済になっていると予測されたタイミングで、前記未実行の処理の実行状況を取得する、
処理をコンピュータに実行させる情報取得プログラム。
【請求項２】
前記予測されたタイミングは、前記未実行の処理の実行が完了すると予測されたタイミングである、請求項１記載の情報取得プログラム。
【請求項３】
前記予測されたタイミングでは前記未実行の処理に限定して実行状況を取得する、請求項１または２記載の情報取得プログラム。
【請求項４】
前記予測されたタイミングで前記未実行の処理が実行されていないことを検出すると、警告を行う、請求項１乃至３の何れか１項に記載の情報取得プログラム。
【請求項５】
前記予測されたタイミングは、前記未実行の処理の実行が完了すると予測されたタイミングよりも後のタイミングである、請求項１記載の情報取得プログラム。
【請求項６】
前記複数の処理は順番に実行される３以上の処理であり、
前記第１の情報に基づいて実行済である２以上の処理それぞれが実行された各時刻の時間間隔を取得し、当該時間間隔および前記第２の情報で示される前記複数の処理それぞれが実行された各時刻の時間間隔の比の平均を用いて前記未実行の処理が実行済となるタイミングを予測する、
請求項１乃至５の何れか１項に記載の情報取得プログラム。
【請求項７】
前記第２の情報で示される前記複数の処理それぞれが実行された各時刻の時間間隔の比に基づいて、前記未実行の処理の実行状況を前記予測されたタイミングで個別に取得するか否かを決定する、請求項６記載の情報取得プログラム。
【請求項８】
前記複数の処理は順番に実行される４以上の処理であり、
前記第１の情報に基づいて、実行済である３以上の処理それぞれが実行された各時刻の時間間隔の比を取得し、当該時間間隔の比と前記第２の情報で示される前記複数の処理それぞれが実行された各時刻の時間間隔の比の平均とに基づいて、前記未実行の処理の実行状況を前記予測されたタイミングで個別に取得するか否かを決定する、
請求項６または７記載の情報取得プログラム。
【請求項９】
前記複数の処理のうちの最初の処理が複数回実行された各時刻の時間間隔に基づいて、前記未実行の処理の実行状況を前記予測されたタイミングで個別に取得するか否かを決定する、請求項６乃至８の何れか１項に記載の情報取得プログラム。
【請求項１０】
前記第１の情報の取得は、所定周期で発生する複数のタイミングのうちの１つのタイミングで行われるものである、請求項１乃至９の何れか１項に記載の情報取得プログラム。
【請求項１１】
コンピュータが、
関連する複数の処理の実行状況を示す第１の情報を取得し、
前記第１の情報を取得した際に、前記複数の処理の過去の実行実績を示す第２の情報に基づいて前記複数の処理のうち、前記第１の情報を取得したタイミングで未実行の処理が実行済になっていると予測されたタイミングで、前記未実行の処理の実行状況を取得する、
情報取得方法。
【請求項１２】
関連する複数の処理の過去の実行実績を示す第１の情報を記憶する記憶部と、
前記複数の処理の実行状況を示す第２の情報を取得し、
前記第２の情報を取得した際に、前記第１の情報に基づいて前記複数の処理のうち、前記第２の情報を取得したタイミングで未実行の処理が実行済になっていると予測されたタイミングで、前記未実行の処理の実行状況を取得する、演算部と、
を有する情報取得装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は情報取得プログラム、情報取得方法および情報取得装置に関する。
【背景技術】
【０００２】
現在、クライアント装置とサーバ装置とを含む情報処理システムが利用されている。クライアント装置は、ユーザにより操作される。サーバ装置は、所定の業務に関する処理を実行する。クライアント装置は、所定の処理の実行をサーバ装置に依頼する。他のクライアント装置は当該処理の結果をサーバ装置から取得でき、当該結果を用いた別の処理の実行をサーバ装置に依頼し得る。例えば、当該情報処理システムを用いることで、組織内の複数のユーザが関与する一連の作業（例えば、受付、見積、決裁など）を円滑化し得る。
【０００３】
このような情報処理システムにおいて、業務に関する一連の処理の流れ（処理フロー）を可視化することが考えられている。例えば、ユーザにより解析の対象の範囲が決定されると、病院内システムにおける医療情報機器間の交信情報を収集し、解析することで、医療情報機器間における情報の受け渡しを示すワークフロー図を作成する提案がある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−３３７５４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
業務に関する情報を継続的に取得して、現状の業務を把握することが考えられる。例えば、業務を行いながらその実績を監視することで、処理フローの異常箇所やボトルネック箇所を抽出し、改善し得る。ところが、システム上で多くの業務が行われているほど、分析対象の情報量も増大し得る。このため、全ての業務に関する情報をリアルタイムに（または、比較的短い時間間隔で）監視し、分析しようとすると、情報を監視する処理負荷や、演算処理の負荷が増大し得る。
【０００６】
一方、比較的長い時間間隔（例えば、１日、１週間、１カ月など）で分析を行うとすると、改善箇所の迅速な提供を行えないという問題がある。例えば、あるタイミングまでに処理フローの一部分までの処理が完了していれば、当該一部分までの情報を取得できる。しかし、当該処理フローの残りの部分の取得は次回以降のタイミングまで待たれることになる。よって、当該処理フロー全体の実行状況を把握できるまでに遅延が生じてしまう。
【０００７】
１つの側面では、本発明は、処理の実行状況を効率的に把握できる情報取得プログラム、情報取得方法および情報取得装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
１つの態様では、コンピュータによって実行される情報取得プログラムが提供される。この情報取得プログラムは、コンピュータに、関連する複数の処理の実行状況を示す第１の情報を取得し、第１の情報を取得した際に、複数の処理の過去の実行実績を示す第２の情報に基づいて複数の処理のうち、第１の情報を取得したタイミングで未実行の処理が実行済になっていると予測されたタイミングで、未実行の処理の実行状況を取得する、処理をコンピュータに実行させる。
【０００９】
また、１つの態様では、情報取得方法が提供される。この情報取得方法では、コンピュータが、関連する複数の処理の実行状況を示す第１の情報を取得し、第１の情報を取得した際に、複数の処理の過去の実行実績を示す第２の情報に基づいて複数の処理のうち、第１の情報を取得したタイミングで未実行の処理が実行済になっていると予測されたタイミングで、未実行の処理の実行状況を取得する。
【００１０】
また、１つの態様では、情報取得装置が提供される。この情報取得装置は、記憶部と演算部とを有する。記憶部は、関連する複数の処理の過去の実行実績を示す第１の情報を記憶する。演算部は、複数の処理の実行状況を示す第２の情報を取得し、第２の情報を取得した際に、第１の情報に基づいて複数の処理のうち、第２の情報を取得したタイミングで未実行の処理が実行済になっていると予測されたタイミングで、未実行の処理の実行状況を取得する。
【発明の効果】
【００１１】
１つの側面では、処理の実行状況を効率的に把握できる。
【図面の簡単な説明】
【００１２】
【図１】第１の実施の形態の情報取得装置を示す図である。
【図２】第２の実施の形態の情報処理システムを示す図である。
【図３】監視サーバのハードウェア例を示す図である。
【図４】監視サーバの機能例を示す図である。
【図５】ログテーブルの例を示す図である。
【図６】イベントテーブルの例を示す図である。
【図７】フロー種別テーブルの例を示す図である。
【図８】プロセス管理テーブルの例を示す図である。
【図９】基準パラメータテーブルの例を示す図である。
【図１０】イベント間隔管理テーブルの例を示す図である。
【図１１】イベント間隔比評価テーブルの例を示す図である。
【図１２】業務発生間隔管理テーブルの例を示す図である。
【図１３】業務発生間隔評価テーブルの例を示す図である。
【図１４】例外プロセステーブルの例を示す図である。
【図１５】収集時刻テーブルの例を示す図である。
【図１６】定期収集の例を示す図である。
【図１７】ピンポイント収集の例を示す図である。
【図１８】ログ収集の例を示すフローチャートである。
【図１９】定期収集処理の例を示すフローチャートである。
【図２０】イベント間隔比の定常性評価の例を示すフローチャートである。
【図２１】業務発生間隔の定常性評価の例を示すフローチャートである。
【図２２】ピンポイント収集の実行判定の例を示すフローチャートである。
【図２３】ピンポイント収集処理の例を示すフローチャートである。
【図２４】ピンポイント収集の具体例を示す図である。
【図２５】複数のプロセスに対する定期収集の例を示す図である。
【発明を実施するための形態】
【００１３】
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報取得装置を示す図である。情報取得装置１は、業務に関する一連の処理の流れ（処理フロー）の実行状況を示す情報を取得する装置である。例えば、情報取得装置１は、取得した情報を用いて、業務を監視したり分析したりする。業務に関する処理は、情報取得装置１上で実行されるものでもよいし、情報取得装置１とネットワークを介して接続された他の装置上で実行されるものでもよい。例えば、情報取得装置１は、他の装置が出力する処理のログを取得して業務の監視や分析を行ってもよい。
【００１４】
情報取得装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭ（Random Access Memory）などの揮発性記憶装置でもよいし、ＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの不揮発性記憶装置でもよい。演算部１ｂは、ＣＰＵ（Central Processing Unit）、ＤＳＰ（Digital Signal Processor）、ＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field Programmable Gate Array）などを含み得る。演算部１ｂは、プログラムを実行するプロセッサであってもよい。ここでいう「プロセッサ」には、複数のプロセッサの集合（マルチプロセッサ）も含まれ得る。
【００１５】
記憶部１ａは、関連する複数の処理の過去の実行実績を示す情報を記憶する。例えば、ある業務は一連の処理Ｅ１，Ｅ２，Ｅ３を含む。処理Ｅ１，Ｅ２，Ｅ３はユーザによる所定の入力を受け付けて何らかの作業（例えば、受発注、見積、決裁など）に関する処理が行われたというイベントを示すものでもよい。
【００１６】
例えば、記憶部１ａには、当該業務が行われた過去の実績が複数登録されている。例えば、第１の実績は、時刻Ｔ１１に処理Ｅ１が実行され、時刻Ｔ１２に処理Ｅ２が実行され、時刻Ｔ１３に処理Ｅ３が実行されたことを示す。第２の実績は、時刻Ｔ２１に処理Ｅ１が実行され、時刻Ｔ２２に処理Ｅ２が実行され、時刻Ｔ２３に処理Ｅ３が実行されたことを示す。記憶部１ａには、更に複数の実績が記憶され得る。
【００１７】
演算部１ｂは、複数の処理のうち実行済である処理の実行実績を示す情報を取得する。例えば、演算部１ｂは、所定のスケジュールに従って当該情報を取得する。より具体的には、演算部１ｂは定期的な収集タイミングＴＢで、一連の処理Ｅ１，Ｅ２，Ｅ３のうち、実行済である処理Ｅ１，Ｅ２の実行実績を示す情報を取得する。当該実行実績は、時刻Ｔ３１に処理Ｅ１が実行され、時刻Ｔ３２に処理Ｅ２が実行されたことを示す。なお、図１では、定期的な収集タイミングＴＡ，ＴＣも例示されている。
【００１８】
演算部１ｂは、記憶部１ａに記憶された過去の実行実績を示す情報と、新たに取得した実行済である処理の実行実績を示す情報に基づいて複数の処理のうち未実行の処理が実行済になっていると予測されたタイミングで、当該未実行の処理の実行状況を取得する。
【００１９】
上記の例でいえば、収集タイミングＴＢにおいて、未実行の処理は処理Ｅ３である。演算部１ｂは、記憶部１ａに記憶された第１の実績や第２の実績、および、収集タイミングＴＢで取得した処理Ｅ１，Ｅ２の実行実績に基づいて予測されたタイミングＴ３３で、処理Ｅ３の実行状況を取得する。演算部１ｂがタイミングＴ３３を予測してもよい。
【００２０】
具体的には、演算部１ｂは、第１，第２の実績などから該当の業務の各処理が所定の時間間隔で実行されると分析し得る。例えば、処理Ｅ２，Ｅ３の時間間隔ΔＴが過去の実績からほぼ一定と判断すれば、処理Ｅ２が実行された時刻Ｔ３２から当該時間間隔ΔＴが経過した時点を処理Ｅ３の実行が完了するタイミングＴ３３と予測してもよい。
【００２１】
また、例えば、処理Ｅ１，Ｅ２の時間間隔ΔＴ１と処理Ｅ２，Ｅ３の時間間隔ΔＴ２との比ｒ＝（ΔＴ２／ΔＴ１）がほぼ一定と判断すれば、比ｒに基づいて処理Ｅ３が実行済になるタイミングＴ３３を予測し得る。具体的には、処理Ｅ１，Ｅ２が実行された時刻Ｔ３１，Ｔ３２から求まる時間間隔に比ｒを乗じた時間が時刻Ｔ３２から経過した時点を、処理Ｅ３の実行が完了するタイミングＴ３３と予測してもよい。
【００２２】
また、演算部１ｂは、上記のようにして計算された時点よりも所定時間だけ後ろにずらした時点を、タイミングＴ３３としてもよい。ユーザの都合によっては、上記の計算で得られた時点に処理Ｅ３が必ずしも実行されるとは限らないからである。演算部１ｂは、過去の実績を統計的に分析する際の誤差に応じて、後ろにずらす時間を定めてもよい。
【００２３】
情報取得装置１によれば、演算部１ｂにより、処理Ｅ１，Ｅ２，Ｅ３のうち実行済である処理Ｅ１，Ｅ２の実行実績を示す情報が取得される。演算部１ｂにより、取得された当該情報と処理Ｅ１，Ｅ２，Ｅ３の過去の実行実績を示す情報とに基づいて未実行の処理Ｅ３が実行済になっていると予測されたタイミングＴ３３で、未実行の処理Ｅ３の実行状況が取得される。
【００２４】
これにより、処理の実行状況を効率的に把握できる。ここで、例えば、全ての業務に関する情報を定期的に分析して、改善箇所などの提供を行うことが考えられる。しかし、このとき、業務によっては実行状況の迅速な把握が難しいことがある。上記で例示したように、業務に関する情報を定期的な収集タイミングＴＡ，ＴＢ，ＴＣで取得する場合を考える。この場合、収集タイミングＴＢでは処理Ｅ１，Ｅ２の実行実績を取得できるが、未実行である処理Ｅ３の実行実績を取得できない。処理Ｅ３の実行実績の取得は、次の収集タイミングＴＣまで待たれることになる。すなわち、当該処理Ｅ１，Ｅ２，Ｅ３を含む業務の実行状況を把握するまでに遅延が生じ、分析結果の迅速な提供が難しい。これに対し、収集タイミングＴＡ，ＴＢ，ＴＣの周期を短くすることも考えられる。しかし、当該周期を短くするほど、監視や分析のための処理の頻度が増大し、情報取得装置１の負荷が増大し得る。更に、処理Ｅ３が実行されるまで継続的に監視を行うことも考えられるが、この場合も継続的な監視のための負荷が問題となる。
【００２５】
そこで、情報取得装置１は、収集タイミングＴＢで未実行である処理Ｅ３の実行状況を、当該収集タイミングＴＢで取得された処理Ｅ１，Ｅ２の実行実績および過去の処理Ｅ１，Ｅ２，Ｅ３の実行実績に基づいて予測されたタイミングＴ３３で取得する。したがって、次の収集タイミングＴＣまで待つよりも早く、未実行の処理Ｅ３の実行状況を把握し得る。このため、例えば、処理Ｅ３が実行されていないなどの異常があれば、ユーザに早期に警告し得る。未実行の処理Ｅ３が収集タイミングＴＣまで放置されてしまうことの防止を図れる。また、タイミングＴ３３では処理Ｅ３に絞って分析を行えるため、他の業務も一緒に分析する場合に比べて、情報取得装置１の分析のための負荷の増大を抑制できる。
【００２６】
なお、演算部１ｂは、タイミングＴ３３では、処理Ｅ３に限定して実行状況を取得してもよい。すなわち、例えば収集タイミングＴＢで取得済みの処理Ｅ１，Ｅ２の実行状況を取得しないようにしてもよい。取得済みの情報を重複して取得するのは冗長な処理となるからである。冗長な処理を抑止することで、情報取得装置１の負荷を一層軽減でき、未完了の処理Ｅ３の実行状況の効率的な把握に寄与し得る。
【００２７】
［第２の実施の形態］
図２は、第２の実施の形態の情報処理システムを示す図である。第２の実施の形態の情報処理システムは、監視サーバ１００、業務サーバ２００および端末装置３００，３００ａ，３００ｂを含む。監視サーバ１００、業務サーバ２００および端末装置３００，３００ａ，３００ｂは、ネットワーク１０に接続されている。ネットワーク１０は、ＬＡＮ（Local Area Network）でもよいし、ＷＡＮ（Wide Area Network）やインターネットなどの広域ネットワークでもよい。
【００２８】
監視サーバ１００は、ＢＡＭ（Business Activity Monitoring）機能を提供するサーバコンピュータである。監視サーバ１００は、情報処理システムで実行される業務が適正に遂行されているか否かを監視する。監視サーバ１００は、業務サーバ２００で実行された業務に関する処理の履歴情報（ログ）を取得する。監視サーバ１００は、当該ログに基づいて、業務に関する処理フロー（業務フローという）を生成し、実際に行われた業務の流れを可視化したり、業務の実行状況を分析したりする。ここで、業務は１以上のユーザによる複数の作業（例えば、受発注、見積、決裁など）を含み得る。監視サーバ１００は、業務の分析結果を端末装置３００，３００ａ，３００ｂに提供する。監視サーバ１００は、第１の実施の形態における情報取得装置１の一例である。
【００２９】
業務サーバ２００は、端末装置３００，３００ａ，３００ｂからの指示により種々の業務に関する処理を行うサーバコンピュータである。業務サーバ２００は、業務に含まれる作業毎に、当該作業が行われたことを示すイベントの情報と、当該イベントが発生した時刻を示す情報とを含むログを継続的に生成し、記憶する。１つの業務は複数のイベントに対応付けることができる。業務サーバ２００は、監視サーバ１００に対して当該ログを提供する。なお、業務サーバ２００は、業務の内容に応じて複数台設けられてもよい。例えば、複数の業務サーバにより出力されたログを他のサーバ装置が集約して管理してもよい。その場合は、当該他のサーバ装置が監視サーバ１００に当該ログを提供してもよい。
【００３０】
端末装置３００，３００ａ，３００ｂは、ユーザによって利用されるクライアントコンピュータである。ユーザは、端末装置３００，３００ａ，３００ｂを操作して、ユーザの作業に関する処理の実行を業務サーバ２００に依頼する。また、端末装置３００，３００ａ，３００ｂは、監視サーバ１００にアクセスして、業務の分析結果を取得できる。ユーザは、端末装置３００，３００ａ，３００ｂを操作して、当該分析結果を閲覧する。例えば、ユーザは、イベントの発生状況から業務フローの遅滞箇所を把握し得る。
【００３１】
図３は、監視サーバのハードウェア例を示す図である。監視サーバ１００は、プロセッサ１０１、ＲＡＭ１０２、ＨＤＤ１０３、通信部１０４、画像信号処理部１０５、入力信号処理部１０６、ディスクドライブ１０７および機器接続部１０８を有する。各ユニットは監視サーバ１００のバスに接続されている。なお、業務サーバ２００および端末装置３００，３００ａ，３００ｂも、監視サーバ１００と同様のハードウェアを用いて実現できる。
【００３２】
プロセッサ１０１は、監視サーバ１００の情報処理を制御する。プロセッサ１０１は、例えばＣＰＵ、ＤＳＰ、ＡＳＩＣまたはＦＰＧＡなどである。プロセッサ１０１は、マルチプロセッサであってもよい。プロセッサ１０１は、ＣＰＵ、ＤＳＰ、ＡＳＩＣ、ＦＰＧＡなどのうちの２以上の要素の組合せであってもよい。
【００３３】
ＲＡＭ１０２は、監視サーバ１００の主記憶装置である。ＲＡＭ１０２は、プロセッサ１０１に実行させるＯＳ（Operating System）のプログラムやアプリケーションプログラムの少なくとも一部を一時的に記憶する。また、ＲＡＭ１０２は、プロセッサ１０１による処理に用いる各種データを記憶する。
【００３４】
ＨＤＤ１０３は、監視サーバ１００の補助記憶装置である。ＨＤＤ１０３は、内蔵した磁気ディスクに対して、磁気的にデータの書き込みおよび読み出しを行う。ＨＤＤ１０３には、ＯＳのプログラム、アプリケーションプログラム、および各種データが格納される。監視サーバ１００は、フラッシュメモリやＳＳＤ（Solid State Drive）などの他の種類の補助記憶装置を備えてもよく、複数の補助記憶装置を備えてもよい。
【００３５】
通信部１０４は、ネットワーク１０を介して他のコンピュータと通信を行える通信インタフェースである。通信部１０４は、有線通信インタフェースでもよいし、無線通信インタフェースでもよい。
【００３６】
画像信号処理部１０５は、プロセッサ１０１からの命令に従って、監視サーバ１００に接続されたディスプレイ１１に画像を出力する。ディスプレイ１１としては、ＣＲＴ（Cathode Ray Tube）ディスプレイや液晶ディスプレイなどを用いることができる。
【００３７】
入力信号処理部１０６は、監視サーバ１００に接続された入力デバイス１２から入力信号を取得し、プロセッサ１０１に出力する。入力デバイス１２としては、例えば、マウスやタッチパネルなどのポインティングデバイス、キーボードなどを用いることができる。
【００３８】
ディスクドライブ１０７は、レーザ光などを利用して、光ディスク１３に記録されたプログラムやデータを読み取る駆動装置である。光ディスク１３として、例えば、ＤＶＤ（Digital Versatile Disc）、ＤＶＤ−ＲＡＭ、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）、ＣＤ−Ｒ（Recordable）／ＲＷ（ReWritable）などを使用できる。ディスクドライブ１０７は、例えば、プロセッサ１０１からの命令に従って、光ディスク１３から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００３９】
機器接続部１０８は、監視サーバ１００に周辺機器を接続するための通信インタフェースである。例えば、機器接続部１０８にはメモリ装置１４やリーダライタ装置１５を接続できる。メモリ装置１４は、機器接続部１０８との通信機能を搭載した記録媒体である。リーダライタ装置１５は、メモリカード１６へのデータの書き込み、またはメモリカード１６からのデータの読み出しを行う装置である。メモリカード１６は、カード型の記録媒体である。機器接続部１０８は、例えば、プロセッサ１０１からの命令に従って、メモリ装置１４またはメモリカード１６から読み取ったプログラムやデータをＲＡＭ１０２またはＨＤＤ１０３に格納する。
【００４０】
図４は、監視サーバの機能例を示す図である。監視サーバ１００は、記憶部１１０、分析部１３０および出力部１４０を有する。記憶部１１０は、ＲＡＭ１０２またはＨＤＤ１０３に確保した記憶領域として実現できる。分析部１３０および出力部１４０は、プロセッサ１０１が実行するソフトウェアのモジュールとして実現できる。
【００４１】
記憶部１１０は、分析部１３０および出力部１４０の処理に用いられる各種の情報を記憶する。記憶部１１０が記憶する情報には、ログに含まれるイベントから業務フローを作成するために用いられる情報（業務フローの種別と複数のイベントとの対応関係の情報）や監視サーバ１００からログを取得するスケジュールを示す情報が含まれる。
【００４２】
分析部１３０は、業務サーバ２００が出力するログを収集して業務フローの実行状況を分析する。分析部１３０は、業務フローに含まれる各作業の実行状況を監視する。分析部１３０は、２種類のタイミングでログを収集し、業務フローの分析を行う。
【００４３】
第１のタイミングは、定期的なタイミングである。例えば、日次、週次、月次などで収集タイミングをスケジューリングすることが考えられる。定期的なログの収集（定期収集）では、分析部１３０は分析対象とする全ての業務についてログを収集し、分析する。
【００４４】
第２のタイミングは、業務ごとに指定された１つの時点である。１つの時点を指定したログの収集（ピンポイント収集）では、分析部１３０は、指定された業務に関するログを収集し、分析する。ピンポイント収集は、各業務フローのイベントのうち、定期収集で未取得であったイベントの発生状況（当該イベントの処理の実行状況）を把握するために行われる。なお、第１，第２のタイミングは上記スケジュールを示す情報として記憶部１１０に格納される。
【００４５】
分析部１３０は、各業務の過去の実行実績を分析して、業務毎に第２のタイミングを決定し、ピンポイント収集を行う。具体的には、分析部１３０は、業務毎に、当該業務に属する各イベントが発生した時間間隔（イベント間隔）の比の定常性の有無を評価する。１つの業務に着目した場合に、当該業務に属する複数のイベントのイベント間隔の比が所定の誤差で一定であれば、イベント間隔の比に定常性があると評価できる。この場合、業務フローのうち少なくとも最初の２つのイベントについてイベント間隔を測定できれば、未取得であるイベントが発生する時刻を予測できる。
【００４６】
また、分析部１３０は、業務毎の発生間隔（業務発生間隔）の定常性の有無も評価する。ここで、業務発生間隔とは、１つの業務に着目した場合に、当該業務に属する最初のイベントが発生した時刻の間隔である。ある業務について業務発生間隔が所定の誤差で一定である場合、当該業務の業務発生間隔は定常性があると評価できる。
【００４７】
出力部１４０は、分析部１３０による分析結果を提供する。例えば、出力部１４０は、業務フローを可視化した業務フロー図や業務フローのうち遅滞している作業の情報を端末装置３００，３００ａ，３００ｂに提供し得る。また、出力部１４０は、ディスプレイ１１に当該業務フロー図などの情報を表示させてもよい。
【００４８】
業務サーバ２００は、ログ記憶部２１０および業務処理部２２０を有する。ログ記憶部２１０は、業務サーバ２００が備えるＲＡＭやＨＤＤに確保した記憶領域として実現できる。業務処理部２２０は、業務サーバ２００が備えるプロセッサが実行するソフトウェアのモジュールとして実現できる。
【００４９】
ログ記憶部２１０は、業務処理部２２０が出力するログを記憶する。ログ記憶部２１０に記憶されたログは、分析部１３０により参照可能である。ただし、前述のように、業務サーバ２００からログを取得する他のサーバ装置を設けて、当該他のサーバ装置に監視サーバ１００に対するログの提供を行わせてもよい。
【００５０】
業務処理部２２０は、端末装置３００，３００ａ，３００ｂからの要求に応じて、種々の業務に関する処理を実行する。業務処理部２２０は、実行した処理に応じたログを生成し、ログ記憶部２１０に格納する。前述のように、当該ログは各処理が実行されたことを示すイベント情報と各処理が実行されたタイムスタンプとを含む。
【００５１】
図５は、ログテーブルの例を示す図である。ログテーブル１１１は、イベントの履歴（業務フローの各処理の実行実績）を示す情報である。ログテーブル１１１の情報は、分析部１３０により業務サーバ２００から取得され、記憶部１１０に格納される。ログテーブル１１１は、ＩＤ（IDentifier）、タイムスタンプ、作業者ＩＤおよびイベント名の項目を含む。
【００５２】
ＩＤの項目には、業務を識別する識別情報（ＩＤ）が登録される。同一の業務に関するログのレコードには、同一のＩＤが付与される。タイムスタンプの項目には、ログのレコードが記録された時刻を示すタイムスタンプが登録される。当該タイムスタンプは、イベントが発生した時刻またはイベントの処理が実行された時刻を示しているともいえる。例えば、当該タイムスタンプは、年月日時分秒で表され得る。ただし、説明を容易にするため、タイムスタンプを年月日時分で表している。作業者ＩＤの項目には、当該イベントに係る作業を行ったユーザのＩＤ（作業者ＩＤ）が登録される。イベント名の項目には、発生したイベントの名称が登録される。
【００５３】
例えば、ログテーブル１１１には、ＩＤが“００１”、タイムスタンプが“２０１３／０４／１５  １０：００”、作業者ＩＤが“Ｎ１”、イベント名が“受付”という情報が登録される。これは、イベント名“受付”のイベントに係る作業が作業者ＩＤ“Ｎ１”のユーザによって、２０１３年０４月１５日１０時００分に行われたことを示す。
【００５４】
当該レコードは、イベント名“受付”のイベントが２０１３年０４月１５日１０時００分に発生したことを示しているともいえる。また、当該レコードは、イベント名“受付”のイベントの処理が２０１３年０４月１５日１０時００分に実行されたことを示しているともいえる。
【００５５】
また、前述のように、ログテーブル１１１では関連するログについて同一のＩＤが付与されている。分析部１３０は、当該ＩＤにより関連するイベントを認識し得る。
図６は、イベントテーブルの例を示す図である。イベントテーブル１１２は、イベントＩＤとイベント名との対応関係を示す情報である。イベントテーブル１１２は、記憶部１１０に予め格納される。イベントテーブル１１２は、イベントＩＤおよびイベント名の項目を含む。
【００５６】
イベントＩＤの項目には、イベントＩＤが登録される。イベント名の項目には、イベントの名称が登録される。例えば、イベントテーブル１１２には、イベントＩＤが“Ｅ１１”、イベント名が“受付”という情報が登録されている。これは、イベントＩＤ“Ｅ１１”のイベントの名称は“受付”であることを示す。
【００５７】
このように、１つのイベント名に対して１つのイベントＩＤが対応付けられる。なお、以下の説明では、例えばイベントＩＤ“Ｅ１１”のイベントを指す場合に、イベント“Ｅ１１”のように略記することがある。
【００５８】
図７は、フロー種別テーブルの例を示す図である。フロー種別テーブル１１３は、業務フローの種別（フロー種別）とイベントＩＤとの対応関係を示す情報である。フロー種別テーブル１１３は、記憶部１１０に予め格納される。フロー種別テーブル１１３は、フロー種別ＩＤおよびイベントＩＤの項目を含む。
【００５９】
フロー種別ＩＤの項目には、フロー種別ＩＤが登録される。イベントＩＤの項目には、イベントＩＤが登録される。例えば、フロー種別テーブル１１３には、フロー種別ＩＤが“Ｆ１”、イベントＩＤが“Ｅ１１，Ｅ１２，Ｅ１３，Ｅ１４”という情報が登録されている。これは、フロー種別ＩＤ“Ｆ１”である業務フローは、イベント“Ｅ１１，Ｅ１２，Ｅ１３，Ｅ１４”の一連のイベントにより成立していることを示す。
【００６０】
ここで、フロー種別ＩＤ“Ｆ１”に対応付けられたイベントＩＤ“Ｅ１１，Ｅ１２，Ｅ１３，Ｅ１４”は、イベントの発生順序も規定している。すなわち、当該業務フローＩＤ“Ｆ１”の業務フローでは、最初にイベント“Ｅ１１”、２番目にイベント“Ｅ１２”、３番目にイベント“Ｅ１３”、最後にイベント“Ｅ１４”という順序で各イベントが発生することを意味する。なお、以下の説明では、例えば、フロー種別ＩＤ“Ｆ１”のフロー種別を指す場合に、フロー種別“Ｆ１”のように略記することがある。
【００６１】
図８は、プロセス管理テーブルの例を示す図である。プロセス管理テーブル１１４は、プロセスＩＤとフロー種別ＩＤとの対応関係を示す情報である。プロセス管理テーブル１１４は、記憶部１１０に格納される。プロセス管理テーブル１１４は、プロセスＩＤおよびフロー種別ＩＤの項目を含む。
【００６２】
プロセスＩＤの項目には、プロセスＩＤが登録される。ここで、プロセスとは、あるフロー種別に対して実際に発生した業務フローの実体（フローインスタンス）である。当該プロセスを業務プロセスということもある。同一のプロセスに属する複数のイベントは、共通のプロセスＩＤをもつ。第２の実施の形態では、プロセスＩＤをログテーブル１１１のＩＤに対応付けることができる。以下に示す例では、ログテーブル１１１でいうＩＤはプロセスＩＤに一致するものとする。ただし、プロセスＩＤは、ログテーブル１１１のＩＤの登録値から一意に導かれる情報でもよい。フロー種別ＩＤの項目にはフロー種別ＩＤが登録される。
【００６３】
例えば、プロセス管理テーブル１１４には、プロセスＩＤが“００１”、フロー種別ＩＤが“Ｆ１”という情報が登録される。これは、プロセスＩＤ“００１”のプロセス（フローインスタンス）は、フロー種別“Ｆ１”のプロセスであることを示す。なお、以下の説明では、例えば、プロセスＩＤ“００１”のプロセスを指す場合に、プロセス“００１”のように略記することがある。
【００６４】
図９は、基準パラメータテーブルの例を示す図である。基準パラメータテーブル１１５は、定常性の有無の評価用のパラメータをフロー種別毎に登録した情報である。基準パラメータテーブル１１５は、記憶部１１０に予め格納される。基準パラメータテーブル１１５は、フロー種別ＩＤ、判定基準数および基準の標準偏差の項目を含む。
【００６５】
フロー種別ＩＤの項目には、フロー種別ＩＤが登録される。判定基準数の項目には、分析を行うまでに蓄積すべきプロセスの数が登録される。分析は統計的な処理を用いて行われるため、サンプルとするプロセスの数がある程度蓄積されている方が信頼性の高い評価を行える。判定基準数は、サンプルとするプロセスの数の閾値に相当する（判定基準数以上のサンプルがなければ分析の対象外となる）。基準の標準偏差の項目は、業務発生間隔およびイベント間隔比の項目に細分化されている。
【００６６】
イベント間隔比の項目には、イベント間隔の比（イベント間隔比）が一定であると判断する際に用いられる統計誤差の値（標準偏差）が登録される。業務発生間隔の項目には、業務発生間隔が一定であると判断する際に用いられる統計誤差の値（標準偏差）が登録される。
【００６７】
例えば、基準パラメータテーブル１１５には、フロー種別ＩＤ“Ｆ１”、判定基準数“３”、イベント間隔比に関する基準の標準偏差“０．０３”、業務発生間隔に関する基準の標準偏差“２．５”という情報が登録されている。これは、業務フロー“Ｆ１”の場合、判定基準数“３”以上のプロセスがサンプルとして取得されている場合に定常性の有無を評価することを示す。また、業務フロー“Ｆ１”について計測されたイベント間隔比のばらつきが標準偏差“０．０３”で与えられる所定範囲内にある場合に、フロー種別“Ｆ１”のイベント間隔比がおおよそ一定である（定常性がある）と評価することを示す。また、業務フロー“Ｆ１”について計測された業務発生間隔のばらつきが標準偏差“２．５”で与えられる所定範囲内にある場合に、当該業務フロー“Ｆ１”の業務発生間隔がおおよそ一定である（定常性がある）と評価することを示す。
【００６８】
なお、判定基準数は、フロー種別に応じて適宜設定可能である。例えば、“５０”、“１００”のようにサンプル数の下限を決定して、統計の信頼性をより向上させることも考えられる。
【００６９】
図１０は、イベント間隔管理テーブルの例を示す図である。イベント間隔管理テーブル１１６は、イベントとイベントとの時間間隔を記録した情報である。イベント間隔管理テーブル１１６は、記憶部１１０に格納される。イベント間隔管理テーブル１１６は、フロー種別ＩＤ、プロセスＩＤ、間隔＃１、間隔＃２および間隔＃３の項目を含む。
【００７０】
フロー種別ＩＤの項目には、フロー種別ＩＤが登録される。プロセスＩＤの項目には、プロセスＩＤが登録される。間隔＃１の項目には、当該フロー種別ＩＤの業務フローのうち最初の（１番目の）イベントが発生してから２番目のイベントが発生するまでの所要時間が登録される。間隔＃２の項目には、２番目のイベントが発生してから３番目のイベントが発生するまでの所要時間が登録される。間隔＃３の項目には、３番目のイベントが発生してから４番目のイベントが発生するまでの所要時間が登録される。
【００７１】
ここで、フロー種別“Ｆ１”に関するプロセスＩＤには４つのイベントが属している。そのため、イベント間隔管理テーブル１１６では間隔＃１〜３を管理する。ただし、プロセスＩＤによっては、３または５以上のイベントが属するフロー種別もある。例えば、５つのイベントが属するフロー種別の場合、イベント間隔管理テーブル１１６では間隔＃１〜４が管理されることになる。
【００７２】
例えば、イベント間隔管理テーブル１１６には、フロー種別が“Ｆ１”、プロセスＩＤが“００１”、間隔＃１が“１ｈ（hour）”、間隔＃２が“２ｈ”、間隔＃３が“３ｈ”という情報が登録されている。これは、業務フロー“Ｆ１”のプロセス“００１”では、イベント“Ｅ１１”が発生してからイベント“Ｅ１２”が発生するまでの時間間隔が１時間であったことを示す。また、イベント“Ｅ１２”が発生してからイベント“Ｅ１３”が発生するまでの時間間隔が２時間であったことを示す。更に、イベント“Ｅ１３”が発生してからイベント“Ｅ１４”が発生するまでの時間間隔が３時間であったことを示す。
【００７３】
言い換えれば、業務フロー“Ｆ１”のプロセス“００１”では、イベント“Ｅ１１”の処理が完了してからイベント“Ｅ１２”の処理が完了するまでの時間間隔が１時間であったともいえる。また、イベント“Ｅ１２”の処理が完了してからイベント“Ｅ１３”の処理が完了するまでの時間間隔が２時間であったともいえる。更に、イベント“Ｅ１３”の処理が完了してからイベント“Ｅ１４”の処理が完了するまでの時間間隔が３時間であったともいえる。
【００７４】
間隔＃１〜３の項目は、プロセス毎のイベント間隔比を示しているともいえる。具体的には、プロセス“００１”の例では、イベント“Ｅ１１”〜“Ｅ１４”までの全体の所要時間は１時間＋２時間＋３時間＝６時間である。よって、全体の所要時間に対するイベント“Ｅ１１”〜“Ｅ１２”のイベント間隔比は、１／６である。全体の所要時間に対するイベント“Ｅ１２”〜“Ｅ１３”のイベント間隔比は、２／６＝１／３である。全体の所要時間に対するイベント“Ｅ１３”〜“Ｅ１４”のイベント間隔比は３／６＝１／２である。
【００７５】
なお、プロセス“１０１”のレコードでは、間隔＃３が未設定“−”（ハイフン）となっている。これは、図１０で示すタイミングにおいて、プロセス“１０１”のイベント“Ｅ１４”のログが未だ取得されていないためである。
【００７６】
図１１は、イベント間隔比評価テーブルの例を示す図である。イベント間隔比評価テーブル１１７は、イベント間隔比の統計を管理するための情報である。イベント間隔比評価テーブル１１７は、記憶部１１０に格納される。イベント間隔比評価テーブル１１７は、フロー種別ＩＤ、件数、イベント間隔、イベント間隔比の平均、イベント間隔比の標準偏差、例外範囲および定常性の項目を含む。
【００７７】
フロー種別ＩＤの項目には、フロー種別ＩＤが登録される。件数の項目には、統計処理に用いたプロセスのサンプル数が登録される。イベント間隔の項目には、どのイベントの間隔であるかを示す情報が登録される。イベント間隔比の平均（ｍ1）の項目には、イベント間隔比の過去の実績の平均が登録される。イベント間隔比の標準偏差（σ1）の項目には、イベント間隔比の過去の実績の平均に対する標準偏差が登録される。
【００７８】
例外範囲の項目には、イベント間隔比の例外の範囲が登録される。後述するように、何れかのイベント間のイベント間隔比が例外の範囲にあると判断されたプロセスは、イベント間隔比の平均および標準偏差を計算する際のサンプルから除外されることになる。例外範囲は、上記平均（ｍ1）および標準偏差（σ1）を用いて算出される。第２の実施の形態では一例として、ｍ1＋２σ1以上、ｍ1−２σ1以下を例外範囲とする。
【００７９】
また、定常性の項目には、当該フロー種別のイベント間隔比に定常性があるか否かを示す情報が登録される。定常性の項目の初期値は、定常性なしを示すものとする。
例えば、イベント間隔比評価テーブル１１７には、フロー種別ＩＤが“Ｆ１”、件数が“３”、イベント間隔が“間隔＃１（Ｅ１１〜Ｅ１２）”、イベント間隔比の平均が“０．１５８８”、イベント間隔比の標準偏差が“０．０１”、例外範囲が“０．１７８８以上、０．１３８８以下”、定常性が“あり”という情報が登録される。
【００８０】
これは、フロー種別“Ｆ１”について、イベント間隔比の平均／標準偏差を求めるために用いたプロセスのサンプル数が、プロセス“００１”、“０１１”、“０２１”の３つであることを示す。ここで、後述するようにイベント間隔管理テーブル１１６に登録されたプロセス“０３１”は偏差が大きくサンプルから除外される。また、イベント間隔管理テーブル１１６で示される時点において、プロセス“１０１”は未発生のイベントを含み不完全であるため、サンプルから除外される。
【００８１】
また、イベント“Ｅ１１”、“Ｅ１４”の各タイムスタンプ間の時間間隔（全体の時間間隔）に対するイベント“Ｅ１１”〜“Ｅ１２”の時間間隔の比の平均が“０．１５８８”、標準偏差が“０．０１”であることを示す。更に、全体の時間間隔に対するイベント“Ｅ１１”〜“Ｅ１２”の時間間隔の比が例外範囲“０．１７８８以上、０．１３８８以下”であるプロセスを例外として扱い、統計処理のサンプルから除外することを示す。また、フロー種別“Ｆ１”はイベント間隔比に定常性があると評価されていることを示す。
【００８２】
図１２は、業務発生間隔管理テーブルの例を示す図である。業務発生間隔管理テーブル１１８は、業務発生間隔を記録した情報である。業務発生間隔管理テーブル１１８は、記憶部１１０に格納される。業務発生間隔管理テーブル１１８は、フロー種別ＩＤ、プロセスＩＤ、タイムスタンプおよび業務発生間隔の項目を含む。
【００８３】
フロー種別ＩＤの項目には、フロー種別ＩＤが登録される。プロセスＩＤの項目には、プロセスＩＤが登録される。タイムスタンプの項目には、当該プロセスの最初のイベントのタイムスタンプが登録される。業務発生間隔の項目には、あるプロセスに着目したときに、当該プロセスと同一のフロー種別ＩＤで当該プロセスの直前に実行されたプロセスのタイムスタンプと、着目するプロセスのタイムスタンプとの間の時間間隔が登録される。なお、あるフロー種別ＩＤで最初に実行されたプロセスについては、直前に実行されたプロセスがないため業務発生間隔の項目には設定なしを示す“−”が登録される。
【００８４】
例えば、業務発生間隔管理テーブル１１８には、フロー種別ＩＤが“Ｆ１”、プロセスＩＤが“００１”、タイムスタンプが“２０１３／０４／１５  １０：００”および業務発生間隔が“−”という情報が登録されている。これは、業務フロー“Ｆ１”のプロセス“００１”に属する最初のイベントの発生時刻が２０１３年４月１５日１０時００分であることを示す。プロセス“００１”は、フロー種別“Ｆ１”の各プロセスの中で最初に発生したプロセスであるため、業務発生間隔は登録されていない。
【００８５】
また、業務発生間隔管理テーブル１１８には、フロー種別ＩＤが“Ｆ１”、プロセスＩＤが“０１１”、タイムスタンプが“２０１３／０４／１６  １０：００”および業務発生間隔が“２４ｈ”という情報が登録されている。これは、業務フロー“Ｆ１”のプロセス“０１１”に属する最初のイベントの発生時刻が２０１３年４月１６日１０時００分であることを示す。また、業務フロー“Ｆ１”の直前のプロセス“００１”のタイムスタンプと当該プロセス“０１１”のタイムスタンプとの時間間隔が“２４”時間であることを示す。
【００８６】
図１３は、業務発生間隔評価テーブルの例を示す図である。業務発生間隔評価テーブル１１９は、業務発生間隔の統計を管理するための情報である。業務発生間隔評価テーブル１１９は、記憶部１１０に格納される。業務発生間隔評価テーブル１１９は、フロー種別ＩＤ、件数、業務発生間隔の平均、業務発生間隔の標準偏差、例外範囲および定常性の項目を含む。
【００８７】
フロー種別ＩＤの項目には、フロー種別ＩＤが登録される。件数の項目には、評価に用いられたサンプル数が登録される。業務発生間隔の平均の項目には、業務発生間隔の過去の実績の平均（ｍ2）が登録される。業務発生間隔の標準偏差の項目には、業務発生間隔の過去の実績の平均に対する標準偏差（σ2）が登録される。
【００８８】
例外範囲の項目には、業務発生間隔の例外の範囲が登録される。後述するように、業務発生間隔が例外の範囲にあると判断されたプロセスは、業務発生間隔の平均および標準偏差を計算する際のサンプルから除外されることになる。例外範囲は、上記平均（ｍ2）および標準偏差（σ2）を用いて算出される。第２の実施の形態では一例として、ｍ2＋２σ2以上、ｍ2−２σ2以下を例外範囲とする。
【００８９】
また、定常性の項目には、当該フロー種別の業務発生間隔に定常性があるか否かを示す情報が登録される。定常性の項目の初期値は、定常性なしを示すものとする。
例えば、業務発生間隔評価テーブル１１９には、フロー種別ＩＤが“Ｆ１”、件数が“３”、業務発生間隔の平均が“２５ｈ”、業務発生間隔の標準偏差が“１ｈ”、例外範囲が“２７ｈ以上、２３ｈ以下”、定常性が“あり”という情報が登録されている。
【００９０】
これは、フロー種別“Ｆ１”について、業務発生間隔の平均／標準偏差を求めるために用いたプロセスのサンプル数が３であることを示す。また、業務発生間隔の平均が２５時間、標準偏差が１時間であることを示す。更に、業務発生間隔が例外範囲“２７時間以上、２３時間以下”であるプロセスを例外として扱い、統計処理のサンプルから除外することを示す。例えば、業務発生間隔管理テーブル１１８によれば、プロセス“０３１”が、次回の統計処理のサンプルから除外されることになる。更に、フロー種別“Ｆ１”は業務発生間隔に定常性があると評価されていることを示す。
【００９１】
なお、不完全なプロセスはサンプルから除外されるものとする。ただし、不完全なプロセスも最初のイベントにより業務発生間隔を把握できるので、当該不完全なプロセスもサンプルとして考慮して、業務発生間隔の平均／標準偏差を求めてもよい。
【００９２】
図１４は、例外プロセステーブルの例を示す図である。例外プロセステーブル１２０は、例外として扱うプロセスを登録する情報である。例外プロセステーブル１２０は、記憶部１１０に格納される。例外プロセステーブル１２０は、プロセスＩＤおよび例外内容の項目を含む。
【００９３】
プロセスＩＤの項目には、プロセスＩＤが登録される。例外内容の項目には、例外の内容を示す情報が登録される。例えば、例外プロセステーブル１２０には、プロセスＩＤが“０３１”、例外内容が“イベント間隔比に例外あり”という情報が登録されている。これは、プロセス“０３１”がイベント間隔比について例外と判定されていることを示す。
【００９４】
図１５は、収集時刻テーブルの例を示す図である。収集時刻テーブル１２１は、未発生のイベントに関するログをピンポイント収集する時刻を登録した情報である。収集時刻テーブル１２１は、記憶部１１０に格納される。収集時刻テーブル１２１は、プロセスＩＤ、イベントＩＤ、境界時刻およびピンポイント収集時刻の項目を含む。
【００９５】
プロセスＩＤの項目には、プロセスＩＤが登録される。イベントＩＤの項目には、未発生のイベントＩＤが登録される。境界時刻の項目には、イベントの発生時刻として許容される下限の（最も過去の）時刻が登録される。ピンポイント収集時刻の項目には、ピンポイント収集を行う時刻が登録される。境界時刻およびピンポイント収集時刻は、後述するようにイベント間隔比評価テーブル１１７に基づいて算出される。
【００９６】
例えば、収集時刻テーブル１２１には、プロセスＩＤが“１０１”、イベントＩＤが“Ｅ１４”、境界時刻が“２０１３／０４／１９  １５：５９”、ピンポイント収集時刻が“２０１３／０４／１９  １６：１３”という情報が登録される。これは、プロセス“１０１”の未発生のイベント“Ｅ１４”に関するログを２０１３年４月１９日１６時１３分にピンポイント収集することを示す。また、当該イベント“Ｅ１４”の発生時刻として許容される最も過去の時刻が２０１３年４月１９日１５時５９分であることを示す。
【００９７】
分析部１３０は、イベント間隔管理テーブル１１６および業務発生間隔管理テーブル１１８を用いてプロセス毎のイベント間隔および業務発生間隔を記録する。また、分析部１３０は、イベント間隔比評価テーブル１１７および業務発生間隔評価テーブル１１９をフロー種別毎に作成して、イベント間隔比および業務発生間隔をフロー種別毎に評価する。
【００９８】
ここで、前述のように分析部１３０は２つの方法でログを取得する。第１の方法は、定期収集による方法である。第２の方法は、ピンポイント収集による方法である。次に、ログ収集のこれらのパターンを説明する。
【００９９】
図１６は、定期収集の例を示す図である。分析部１３０は、業務サーバ２００から定期的にログを収集する。定期収集のタイミングは、記憶部１１０に予め記憶される。例えば、日次、週次、月次などのタイミングである。図１６では、定期収集のタイミングとして、定期収集タイミングＴ１，Ｔ２，・・・，Ｔ１００，Ｔ１０１，・・・が時系列に例示されている。
【０１００】
ここで、フロー種別“Ｆ１”に着目すると、定期収集タイミングＴ１以前には、フロー種別“Ｆ１”のプロセスに属するイベントが存在していない。このため、定期収集タイミングＴ１の時点では、フロー種別“Ｆ１”のプロセスに属するイベントのログは取得されない。
【０１０１】
また、定期収集タイミングＴ２以前で、定期収集タイミングＴ１よりも後の期間ではフロー種別“Ｆ１”のプロセス“００１”に属するイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”、“Ｅ１４”が存在している。このため、定期収集タイミングＴ２の時点では、フロー種別“Ｆ１”のプロセス“００１”に属するイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”、“Ｅ１４”のログが取得される。
【０１０２】
更に、定期収集タイミングＴ１０１以前で、定期収集タイミングＴ１００よりも後の期間ではフロー種別“Ｆ１”のプロセス“１０１”に属するイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”が存在している。このため、定期収集タイミングＴ１０１の時点では、フロー種別“Ｆ１”のプロセス“１０１”に属するイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”のログが取得される。ただし、定期収集タイミングＴ１０１の時点ではプロセス“１０１”に対応するイベント“Ｅ１４”は未発生である。したがって、定期収集タイミングＴ１０１ではイベント“Ｅ１４”のログは取得されないことになる。
【０１０３】
図１７は、ピンポイント収集の例を示す図である。図１６で例示したようにタイミングＴ１０１において、プロセス“１０１”のイベント“Ｅ１４”は未発生である。そこで、分析部１３０は、フロー種別“Ｆ１”の各プロセスの過去の実績からイベント“Ｅ１４”のログをピンポイントで収集するタイミングを計算する。具体的には、プロセス“１０１”について、イベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”の発生時刻が取得されている。よって、イベント“Ｅ１１”、“Ｅ１２”の時間間隔ΔＴａを得られる。また、イベント“Ｅ１２”、“Ｅ１３”の時間間隔ΔＴｂを得られる。
【０１０４】
また、これらの各イベントの時間間隔とイベント“Ｅ１３”、“Ｅ１４”の時間間隔の比の平均が過去の実績から分かっている。これらの情報からプロセス“１０１”のイベント“Ｅ１４”がイベント“Ｅ１３”の発生時刻からどの程度の時間が経過したときに発生し得るかを予測する。
【０１０５】
例えば、イベント“Ｅ１１”、“Ｅ１２”の時間間隔に対するイベント“Ｅ１３”、“Ｅ１４”の時間間隔の比の平均がｒ1であるとする。その場合、当該平均から予測される時刻τは、プロセス“１０１”のイベント“Ｅ１３”の発生時刻からｒ1×ΔＴａの時間が経過した時刻である。
【０１０６】
また、例えば、イベント“Ｅ１２”、“Ｅ１３”の時間間隔に対するイベント“Ｅ１３”、“Ｅ１４”の時間間隔の比の平均がｒ2であるとする。その場合、当該平均から予測される時刻τは、プロセス“１０１”のイベント“Ｅ１３”の発生時刻からｒ2×ΔＴｂの時間が経過した時刻である。分析部１３０は、ｒ1を用いて時刻τを計算してもよいし、ｒ2を用いて時刻τを計算してもよい。ただし、ｒ1，ｒ2のうち、標準偏差の小さい方を用いた方が、時刻τの予測の精度は高いと考えられる。
【０１０７】
更に、分析部１３０は、時刻τから時間２σが経過した時刻（“τ＋２σ”の時刻）をピンポイント収集タイミングＴｙと決定する。ここで、σはフロー種別“Ｆ１”のイベント“Ｅ１３”、“Ｅ１４”に対して求められているイベント時間比に関する標準偏差を時間に換算したものである。各イベントは、様々なユーザの操作によって行われるものであり、各ユーザの置かれている状況も多様である。このため、イベントの発生時刻に適度の遅延を許容した方が、ピンポイント収集での取得漏れの可能性は低くなる。
【０１０８】
図１８は、ログ収集の例を示すフローチャートである。以下、図１８に示す処理をステップ番号に沿って説明する。
（Ｓ１１）分析部１３０は、定期収集を行う時刻に到達したことを検出する。定期収集のスケジュール情報は、記憶部１１０に予め格納される。
【０１０９】
（Ｓ１２）分析部１３０は、業務サーバ２００からログの収集処理（定期収集）を行う。分析部１３０は、収集したログに基づいて業務フロー（プロセス）を作成し、業務の改善箇所の分析を行う。
【０１１０】
（Ｓ１３）分析部１３０は、定期収集時に作成したプロセスのうち、未発生のイベントを含み、３以上のイベントが発生済であるプロセスがあるか否かを判定する。ある場合、処理をステップＳ１４に進める。ない場合、処理を終了する（次の定期収集タイミングまで待機する）。
【０１１１】
（Ｓ１４）分析部１３０は、ピンポイント収集の実行判定処理を行う。分析部１３０は、定期収集を行った段階で、未発生のイベントを含み、３以上のイベントが発生済であるプロセスを、ピンポイント収集の候補とする。当該候補のうち、所定の条件を満たすプロセスをピンポイント収集の対象と決定し、プロセス毎にピンポイント収集のスケジュールを作成する。
【０１１２】
（Ｓ１５）分析部１３０は、作成したスケジュールに従って、プロセス毎にピンポイント収集を行う。また、分析部１３０は、ピンポイント収集の結果に応じて、ユーザに対する警告を行う。
【０１１３】
図１９は、定期収集処理の例を示すフローチャートである。以下、図１９に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１８のステップＳ１２の手順に相当する。
【０１１４】
（Ｓ２１）分析部１３０は、業務サーバ２００からログを取得し、ログテーブル１１１に登録する。例えば、当該ログには、プロセス“１０１”のイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”が発生したことを示すログも含まれる。このとき、分析部１３０は、過去に収集済のログ以外のログを収集する。
【０１１５】
（Ｓ２２）分析部１３０は、前回までに取得されているログと今回取得されたログとに基づいて、発生済のイベントの組をプロセス毎に特定する。例えば、今回取得されたログには、プロセス“１０１”のイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”のログが含まれている。したがって、分析部１３０は、プロセス“１０１”に対する発生済のイベントとしてイベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”を特定する。また、前回までに取得されているプロセスには、前回の定期収集時に未発生のイベントが存在していたプロセスもあり得る。今回取得されたログで当該未発生のイベントが発生したことを確認できれば、当該未発生のイベントを補完できる。このようにして、分析部１３０は収集したログからプロセス（業務フロー）を作成する。
【０１１６】
（Ｓ２３）分析部１３０は、プロセスとフロー種別との対応関係を特定して、プロセス管理テーブル１１４に登録する。具体的には、分析部１３０は、ログテーブル１１１のＩＤ（プロセスＩＤ）およびイベント名から、プロセス毎に発生したイベントの時系列を把握する。分析部１３０は、イベントテーブル１１２に基づいてイベント名をイベントＩＤに変換し、イベントＩＤをフロー種別テーブル１１３と照合してフロー種別ＩＤを得る。第２の実施の形態の例では、イベントＩＤとフロー種別ＩＤとは１対１に対応しているので、１のイベントＩＤからフロー種別ＩＤを判定し得る。ただし、複数のイベントＩＤの時系列からフロー種別ＩＤを判定するようにしてもよい。このようにフロー種別ＩＤを判定し、当該フロー種別ＩＤとログテーブル１１１のＩＤ（プロセスＩＤ）とを対応付けることができる。例えば、プロセスＩＤ“１０１”に対してフロー種別ＩＤ“Ｆ１”を対応付ける。分析部１３０は、この対応関係をプロセス管理テーブル１１４に登録する。
【０１１７】
（Ｓ２４）分析部１３０は、ステップＳ２３でイベントの組を構成したプロセスのうち、全てのイベントが発生済であるプロセスのプロセスＩＤに対応するフロー種別ＩＤを１つ選択する。
【０１１８】
（Ｓ２５）分析部１３０は、基準パラメータテーブル１１５を参照して、選択したフロー種別ＩＤの判定基準数を取得する。分析部１３０は、プロセス管理テーブル１１４を参照して、当該フロー種別に関し、判定基準数以上のプロセス（ただし、全てのイベントが発生済のもの）が存在しているか否かを判定する。全てのイベントが発生済であるプロセスの数が判定基準数以上存在する場合、処理をステップＳ２６に進める。全てのイベントが発生済であるプロセスの数が判定基準数以上存在しない場合、処理をステップＳ２９に進める。この判定により、十分なサンプルが確保されていないフロー種別の分析を省略でき、分析を効率化し得る。
【０１１９】
（Ｓ２６）分析部１３０は、選択したフロー種別は、３つ以上のイベントで成立するものであるか否かを判定する。３つ以上のイベントで成立するものである場合、処理をステップＳ２７に進める。２つ以下のイベントで成立するものである場合、処理をステップＳ２８に進める。フロー種別が３つ以上のイベントで成立するものであるか否かは、フロー種別テーブル１１３に基づいて判定できる。
【０１２０】
（Ｓ２７）分析部１３０は、選択したフロー種別について、イベント間隔比の定常性を評価する。詳細は後述する。
（Ｓ２８）分析部１３０は、選択したフロー種別について、業務発生間隔の定常性を評価する。詳細は後述する。
【０１２１】
（Ｓ２９）分析部１３０は、新規のプロセスＩＤが登録された全てのフロー種別を処理済であるか否かを判定する。新規のプロセスＩＤが登録された全てのフロー種別を処理済である場合、処理をステップＳ３０に進める。新規のプロセスＩＤが登録された全てのフロー種別を処理済でない場合、処理をステップＳ２４に進める。
【０１２２】
（Ｓ３０）分析部１３０は、収集したログによって構成されたプロセスについて、異常が検出されたプロセスがあれば、当該異常がある旨を警告するように出力部１４０に指示する。例えば、あるプロセスのうちの一部のイベントの発生時刻が当該プロセスのフロー種別がもつ定常性を逸脱して行われている場合に異常を検知し、当該イベントに対応する作業が定常的に行われていない旨を警告するように出力部１４０に指示する。
【０１２３】
図２０は、イベント間隔比の定常性評価の例を示すフローチャートである。以下、図２０に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１９のステップＳ２７の手順に相当する。以下の処理は、図１９のステップＳ２４で選択されたフロー種別（着目するフロー種別）について行われる。
【０１２４】
（Ｓ３１）分析部１３０は、着目するフロー種別の各プロセスについてイベント間隔をイベント間隔管理テーブル１１６に記録する。具体的には、ログテーブル１１１には、各イベントのタイムスタンプが登録されている。分析部１３０は、図１９のステップＳ２３で把握されたプロセス毎のイベントの時系列に沿って各イベント間のタイムスタンプの差を求め、各イベント間のイベント間隔とする。
【０１２５】
（Ｓ３２）分析部１３０は、イベント間隔比評価テーブル１１７を参照して、着目するフロー種別がイベント間隔比に定常性ありと評価されているか否かを判定する。イベント間隔比に定常性ありと評価されている場合、処理をステップＳ３３に進める。イベント間隔比に定常性ありと評価されていない場合（すなわち、定常性なしと評価されている場合）、処理をステップＳ３５に進める。
【０１２６】
（Ｓ３３）分析部１３０は、例外プロセステーブル１２０を参照して、着目するフロー種別のプロセスのうち、イベント間隔比について例外プロセスとして登録されているプロセスがあるか否かを判定する。例外プロセスがある場合、処理をステップＳ３４に進める。例外プロセスがない場合、処理をステップＳ３５に進める。例えば、例外プロセステーブル１２０には、フロー種別“Ｆ１”のプロセス“０３１”が登録されている。プロセス“０３１”の登録内容によれば“イベント間隔比に例外あり”と設定されている。このため、分析部１３０は、フロー種別“Ｆ１”に対して例外プロセスがあると判定することになる。
【０１２７】
（Ｓ３４）分析部１３０は、着目するフロー種別のうち、例外プロセステーブル１２０にイベント間隔比について例外プロセスとして登録されているプロセスを、統計処理のサンプルから除外する。例えば、分析部１３０は、フロー種別“Ｆ１”についてイベント間隔比の平均および標準偏差を求める場合は、プロセス“０３１”をサンプルから除外して計算を行うことになる。
【０１２８】
（Ｓ３５）分析部１３０は、着目するフロー種別について、イベント間隔比の平均および標準偏差を計算する。具体的には、分析部１３０は、イベント間隔管理テーブル１１６を参照して、サンプルとなるプロセス毎に、プロセスの全体の所要時間に対する各イベント間隔の比を計算する。なお、前述の通り、サンプルとなるプロセスは、全てのイベントが発生済であるプロセスである。そして、イベントの間隔毎にイベント間隔比の平均（ｍ1）を算出する。更に、イベント間隔比毎のばらつきを示す標準偏差（σ1）を算出する。また、ｍ1＋２σ1以上、ｍ1−２σ1以下の範囲を例外範囲として算出する。分析部１３０は、計算に用いたサンプル数（件数）、平均ｍ1、標準偏差σ1および例外範囲を、フロー種別に対応付けてイベント間隔比評価テーブル１１７に登録する。
【０１２９】
（Ｓ３６）分析部１３０は、全てのイベント間隔比の標準偏差が基準の標準偏差よりも小さいか否かを判定する。全てのイベント間隔比の標準偏差が基準の標準偏差よりも小さい場合、処理をステップＳ３７に進める。何れかのイベント間隔比の標準偏差が基準の標準偏差以上である場合、処理をステップＳ３８に進める。例えば、イベント間隔比評価テーブル１１７によれば、フロー種別“Ｆ１”のイベント間隔比の標準偏差は“０．０１”、“０．０２”、“０．０１”である。基準パラメータテーブル１１５によれば、フロー種別“Ｆ１”のイベント間隔比の基準の標準偏差は“０．０３”である。この場合、分析部１３０は、フロー種別“Ｆ１”について全てのイベント間隔比の標準偏差が基準の標準偏差よりも小さいと判定する。
【０１３０】
（Ｓ３７）分析部１３０は、着目するフロー種別を“定常性あり”と判断する。分析部１３０は、“定常性あり”とする判断結果をフロー種別に対応付けてイベント間隔比評価テーブル１１７に登録する。
【０１３１】
（Ｓ３８）分析部１３０は、着目するフロー種別を“定常性なし”と判断する。分析部１３０は、“定常性なし”とする判断結果をフロー種別に対応付けてイベント間隔比評価テーブル１１７に登録する。そして、処理を終了する。
【０１３２】
（Ｓ３９）分析部１３０は、着目するフロー種別について、イベント間隔比が例外範囲内であるイベントをもつプロセスがあるか否かを判定する。当該プロセスがある場合、処理をステップＳ４０に進める。当該プロセスがない場合、処理を終了する。例えば、イベント間隔管理テーブル１１６によれば、プロセス“０３１”はイベント間隔＃１，＃２，＃３の値が他のプロセスのイベント間隔に対してばらついており、イベント間隔比も他のプロセスのイベント間隔比と大きく異なる。例えば、プロセス“０３１”の間隔＃２のイベント間隔比は、２１／（７＋２１＋２２）＝０．４２≧０．３８９２である。このため、プロセス“０３１”はイベント間隔比が例外範囲内にあると判定される。
【０１３３】
（Ｓ４０）分析部１３０は、イベント間隔比が例外範囲内であると判断されたプロセスをイベント間隔比についての例外プロセスとして、例外プロセステーブル１２０に登録する。
【０１３４】
なお、ステップＳ３５では、過去に取得済のイベント間隔比の平均およびイベント間隔比の２乗和を用いて、新たに追加されたプロセスのイベント間隔分を考慮した平均および標準偏差の計算を簡略化し得る。例えば、イベント間隔比評価テーブル１１７に、イベント間隔毎のイベント間隔比の２乗和を保持しておく。そうすれば、あるイベント間のイベント間隔について、“今回の平均＝｛（前回件数×前回の平均）＋今回追加のイベント間隔比の合計｝／（前回件数＋今回追加の件数）”として求まる。また、“今回の２乗和＝前回の２乗和＋今回追加のイベント間隔比の２乗和”として求まる。
【０１３５】
したがって、“前回件数＋今回追加の件数＝今回件数”とすれば、“（今回の標準偏差の２乗）＝（今回の２乗和／今回件数）−（今回の平均の２乗）”を計算することで求まる。
【０１３６】
図２１は、業務発生間隔の定常性評価の例を示すフローチャートである。以下、図２１に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１９のステップＳ２８の手順に相当する。以下の処理は、図１９のステップＳ２４で選択されたフロー種別（着目するフロー種別）について行われる。
【０１３７】
（Ｓ４１）分析部１３０は、着目するフロー種別の各プロセスについて業務発生間隔を業務発生間隔管理テーブル１１８に記録する。具体的には、ログテーブル１１１には、各イベントのタイムスタンプが登録されている。分析部１３０は、図１９のステップＳ２３で把握された各プロセスについて、最初のイベントのタイムスタンプの差を求め、業務発生間隔とする。
【０１３８】
（Ｓ４２）分析部１３０は、業務発生間隔評価テーブル１１９を参照して、着目するフロー種別が業務発生間隔に定常性ありと評価されているか否かを判定する。業務発生間隔に定常性ありと評価されている場合、処理をステップＳ４３に進める。業務発生間隔に定常性ありと評価されていない場合（すなわち、定常性なしと評価されている場合）、処理をステップＳ４５に進める。
【０１３９】
（Ｓ４３）分析部１３０は、例外プロセステーブル１２０を参照して、着目するフロー種別のプロセスのうち、業務発生間隔について例外プロセスとして登録されているプロセスがあるか否かを判定する。例外プロセスがある場合、処理をステップＳ４４に進める。例外プロセスがない場合、処理をステップＳ４５に進める。例えば、例外プロセステーブル１２０には、フロー種別“Ｆ１”のプロセス“０３１”が登録されている。プロセス“０３１”の登録内容によれば“イベント間隔比に例外あり”であるが、業務発生間隔について例外とする旨は設定されていない。このため、分析部１３０は、フロー種別“Ｆ１”に対して例外プロセスがないと判定することになる。
【０１４０】
（Ｓ４４）分析部１３０は、着目するフロー種別のうち、例外プロセステーブル１２０に業務発生間隔について例外プロセスとして登録されているプロセスを、統計処理のサンプルから除外する。
【０１４１】
（Ｓ４５）分析部１３０は、着目するフロー種別について、業務発生間隔の平均および標準偏差を計算する。分析部１３０は、業務発生間隔管理テーブル１１８からサンプルとなるプロセスを抽出する。前述の通り、サンプルとなるプロセスは、全てのイベントが発生済であるプロセスである。そして、サンプルとなるプロセスに対して取得されている業務発生間隔の平均（ｍ2）を算出する。更に、業務発生間隔のばらつきを示す標準偏差（σ2）を算出する。また、ｍ2＋２σ2以上、ｍ2−２σ2以下の範囲を例外範囲として算出する。分析部１３０は、計算に用いたサンプル数（件数）、平均ｍ2、標準偏差σ2および例外範囲をフロー種別に対応付けて、業務発生間隔評価テーブル１１９に登録する。
【０１４２】
（Ｓ４６）分析部１３０は、業務発生間隔の標準偏差が基準の標準偏差よりも小さいか否かを判定する。業務発生間隔の標準偏差が基準の標準偏差よりも小さい場合、処理をステップＳ４７に進める。業務発生間隔の標準偏差が基準の標準偏差以上である場合、処理をステップＳ４８に進める。例えば、業務発生間隔評価テーブル１１９によれば、フロー種別“Ｆ１”の業務発生間隔の標準偏差は“１ｈ”である。基準パラメータテーブル１１５によれば、フロー種別“Ｆ１”の業務発生間隔の基準の標準偏差は“２．５”である。この場合、分析部１３０は、フロー種別“Ｆ１”について業務発生間隔の標準偏差が基準の標準偏差よりも小さいと判定する。
【０１４３】
（Ｓ４７）分析部１３０は、着目するフロー種別を“定常性あり”と判断する。分析部１３０は、“定常性あり”とする判断結果をフロー種別に対応付けて業務発生間隔評価テーブル１１９に登録する。
【０１４４】
（Ｓ４８）分析部１３０は、着目するフロー種別を“定常性なし”と判断する。分析部１３０は、“定常性なし”とする判断結果をフロー種別に対応付けて業務発生間隔評価テーブル１１９に登録する。そして、処理を終了する。
【０１４５】
（Ｓ４９）分析部１３０は、着目するフロー種別について、業務発生間隔が例外範囲内であるプロセスがあるか否かを判定する。当該プロセスがある場合、処理をステップＳ５０に進める。当該プロセスがない場合、処理を終了する。例えば、業務発生間隔管理テーブル１１８によれば、プロセス“０３１”の業務発生間隔“２７ｈ”はフロー種別“Ｆ１”の例外範囲“２７ｈ以上”に該当する。このため、プロセス“０３１”は業務発生間隔が例外範囲内にあると判定される。
【０１４６】
（Ｓ５０）分析部１３０は、業務発生間隔が例外範囲内であると判断されたプロセスを業務発生間隔についての例外プロセスとして、例外プロセステーブル１２０に登録する。
ここで、ステップＳ４５における業務発生間隔の平均および標準偏差の計算は、前述のイベント間隔比の平均および標準偏差の計算と同様の方法を用いて行える。業務発生間隔評価テーブル１１９に業務発生間隔の２乗和をフロー種別毎に記録しておいてもよい。
【０１４７】
なお、業務発生間隔の定常性評価では、未発生のイベントを含む不完全なプロセスをサンプルとして除外するものとした。ただし、不完全なプロセスであっても、最初のイベントが発生していれば業務発生間隔は得られるため、当該不完全なプロセスをサンプルとして用いて、業務発生間隔を評価してもよい。
【０１４８】
図２２は、ピンポイント収集の実行判定の例を示すフローチャートである。以下、図２２に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１８のステップＳ１４の手順に相当する。
【０１４９】
（Ｓ５１）分析部１３０は、未発生のイベントを含み、３以上のイベントが発生済であるプロセスを選択する。例えば、プロセス“１０１”では、イベント“Ｅ１４”は未発生であり、イベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”の３つのイベントが発生済である。よって、プロセス“１０１”はステップＳ５１の選択対象となる。
【０１５０】
（Ｓ５２）分析部１３０は、業務発生間隔評価テーブル１１９を参照して、選択したプロセスに対応するフロー種別の業務発生間隔に定常性があるか否かを判定する。定常性がある場合、処理をステップＳ５３に進める。定常性がない場合、処理をステップＳ５６に進める。
【０１５１】
（Ｓ５３）分析部１３０は、イベント間隔比評価テーブル１１７を参照して、選択したプロセスに対応するフロー種別のイベント間隔比に定常性があるか否かを判定する。定常性がある場合、処理をステップＳ５４に進める。定常性がない場合、処理をステップＳ５６に進める。
【０１５２】
（Ｓ５４）分析部１３０は、選択したプロセスの先頭の所定部分のイベント間隔比が、過去の実績のイベント間隔比に一致しているか否かを判定する。当該プロセスの先頭の所定部分のイベント間隔比が、過去の実績のイベント間隔比に一致している場合、処理をステップＳ５５に進める。当該プロセスの先頭の所定部分のイベント間隔比が、過去の実績のイベント間隔比に一致していない場合、処理をステップＳ５６に進める。例えば、先頭の所定部分として、プロセスにおける最初のイベントから３番目のイベントまでの部分が予め指定される。この場合、プロセス“１０１”の例では、イベント“Ｅ１１”〜“Ｅ１３”のイベント間隔比が過去の実績のイベント間隔比（間隔＃１、＃２）と所定の誤差（例えば、１０％程度）内で一致しているか否かを判定することになる。先頭の所定部分としては、３番目以降の何れかのイベントまでの部分を予め指定しておくことができる。
【０１５３】
（Ｓ５５）分析部１３０は、選択したプロセスに対するピンポイント収集タイミングＴｙ＝τ＋２σを算出し、収集時刻テーブル１２１に登録する。例えば、分析部１３０は、プロセス“１０１”について、イベント“Ｅ１４”のログをピンポイント収集する場合、イベント間隔比評価テーブル１１７の間隔＃３に対するσ1を用いて上記σを算出する。Ｔｙの算出方法は、図１７で説明した通りである。イベント間隔管理テーブル１１６に登録されたプロセス“１０１”の例では、２σは７分程度である。また、分析部１３０は、境界時刻τ−２σも計算して、収集時刻テーブル１２１に登録しておく。
【０１５４】
（Ｓ５６）分析部１３０は、未発生のイベントを含む全プロセスを処理済であるか否かを判定する。未発生のイベントを含む全プロセスを処理済である場合、処理を終了する。未処理のプロセスがある場合、処理をステップＳ５１に進める。
【０１５５】
このように、業務発生間隔、イベント間隔比および発生済のイベントのうち先頭の所定部分が過去の実績のイベント間隔比と一致するプロセスをピンポイント収集の対象とする。このようにすれば、ピンポイント収集の対象とするプロセスを定常性の比較的高いプロセスに絞り込むことができる。
【０１５６】
ただし、ステップＳ５２，Ｓ５４の両方または何れか一方の判定を行わずにピンポイント収集の実行判定を行ってもよい。例えば、先頭から２番目までのイベントが発生しており、３番目以降のイベントが発生していないプロセスもピンポイント収集の対象候補としたい場合には、ステップＳ５４の判定を行わないようにすればよい。ステップＳ５４の判定を行わないのであれば、分析部１３０は、図１８のステップＳ１３の判定を、「未発生のイベントを含み、“２”以上のイベントが発生済のプロセスがあるか否か」の判定とする。更に、この場合、ステップＳ５１では、「未発生のイベントを含み、“２”以上のイベントが発生済であるプロセスを選択する」ことになる。
【０１５７】
図２３は、ピンポイント収集処理の例を示すフローチャートである。以下、図２３に示す処理をステップ番号に沿って説明する。以下に示す手順は、図１８のステップＳ１５の手順に相当する。
【０１５８】
（Ｓ６１）分析部１３０は、収集時刻テーブル１２１に登録されたピンポイント収集の時刻に到達したことを検出する。
（Ｓ６２）分析部１３０は、ピンポイント収集の対象イベントのログ取得を試みる。例えば、分析部１３０は、プロセスＩＤおよびイベント名を指定して対象のログを送るように業務サーバ２００に指示してもよい。あるいは、分析部１３０は、現時刻までにログテーブル１１１に登録された各業務のログの中から対象のプロセスのイベントを検索してもよい。
【０１５９】
（Ｓ６３）分析部１３０は、ステップＳ６２の試行結果に基づいて、対象のイベントが発生しているか否かを判定する。発生している場合、処理をステップＳ６５に進める。発生していない場合、処理をステップＳ６４に進める。対象のイベントのログを取得できれば、対象のイベントが発生していることになる。対象のイベントのログを取得できなければ、対象のイベントが発生していないことになる。
【０１６０】
（Ｓ６４）分析部１３０は、出力部１４０にアラート通知を指示する。出力部１４０は、ピンポイント収集の対象のイベントに係る作業が行われていない旨を警告する。例えば、出力部１４０は、ディスプレイ１１に警告内容を表示させてもよい。出力部１４０は、予め定められた電子メールアドレスに対して、警告内容を記述した電子メールを送信してもよい。出力部１４０は、予め定められた端末装置に対して、警告内容を示すメッセージを送信して、当該端末装置のディスプレイに表示させてもよい。
【０１６１】
（Ｓ６５）分析部１３０は、ピンポイント収集で取得されたログのタイムスタンプを参照して、当該イベントが境界時刻τ−２σよりも前の時刻で発生しているか否かを判定する。境界時刻よりも前の時刻で発生している場合、処理をステップＳ６６に進める。境界時刻よりも後の時刻で発生している場合、処理をステップＳ６７に進める。
【０１６２】
（Ｓ６６）分析部１３０は、出力部１４０にアラート通知を指示する。出力部１４０は、ピンポイント収集の対象のイベントに係る作業が行われるのが早過ぎる（予定通りに作業が行われていない）旨を警告する。具体的な警告方法はステップＳ６４と同様である。
【０１６３】
（Ｓ６７）分析部１３０は、ピンポイント収集で取得されたイベントのログを用いて不完全であったプロセスを補完する（プロセスの構成）。例えば、分析部１３０はイベント間隔管理テーブル１１６で未登録となっているイベント間隔の値を埋めることができる。また、分析部１３０は、ユーザに提示する業務フロー図を補完することができる。
【０１６４】
（Ｓ６８）分析部１３０は、収集時刻テーブル１２１に登録された全てのプロセスについてピンポイント収集を完了したか否かを判定する。全て完了した場合、処理を終了する。未完了のピンポイント収集がある場合、次のピンポイント収集の時刻まで待機して、処理をステップＳ６１に進める。
【０１６５】
図２４は、ピンポイント収集の具体例を示す図である。図２４（Ａ）はプロセス“１０１”において、未発生であったイベント“Ｅ１４”をピンポイント収集により検出できた場合を例示している。図２４（Ｂ）はプロセス“１０１”において、未発生であったイベント“Ｅ１４”をピンポイント収集で検出できなかった場合を例示している。
【０１６６】
プロセス“１０１”の例の場合、過去のイベント間隔比の平均から予測される時刻τはイベント“Ｅ１３”の発生時刻から３時間６分（＝（０．４９２０／０．１５８８）×１時間）経過後である。イベント“Ｅ１３”の発生時刻は、１３時００分なのでτを１６時６分と予測できる。また、イベント“Ｅ１３”、“Ｅ１４”のイベント間隔比の標準偏差σ1＝０．０１を時間（分）に換算してσを求めると、σ＝（１／０．１５８８）×０．０１×６０分＝３．７７８分である。よって、２σは７分程度である。
【０１６７】
このため、イベント“Ｅ１４”のピンポイント収集タイミングＴｙ＝τ＋２σは１６時１３分となる。また、境界時刻τ−２σは１５時５９分となる。分析部１３０は、時刻Ｔｙのログ収集により、イベント“Ｅ１４”の発生を検出できれば、定期収集で取得済のプロセス“１０１”の他のイベントに対してイベント“Ｅ１４”を直ちに補完できる（図２４（Ａ）の例）。
【０１６８】
一方、分析部１３０は、時刻Ｔｙにおいて、イベント“Ｅ１４”の発生を検出できなければ、定常的に行われている業務が未実施である旨を出力部１４０により警告させる（図２４（Ｂ）の例）。なお、前述のように、時刻Ｔｙのログ収集により、イベント“Ｅ１４”の発生を検出できたとしても、発生タイミングが境界時刻１５時５９分よりも前であれば、業務の定常性を損なっている旨を出力部１４０により警告させる。
【０１６９】
図２５は、複数のプロセスに対する定期収集の例を示す図である。第２の実施の形態の情報処理システムでは、業務サーバ２００により複数の業務処理が行われている。このため、複数のフロー種別のプロセス（業務フロー）が並行して進行する。このため、あるタイミングで定期収集を行うとしても、そのタイミングにおいて各プロセスの全てのイベントが完了している可能性は低い。
【０１７０】
例えば、フロー種別“Ｆ１”、“Ｆ２”、“Ｆ３”のプロセスが並行して進行する場合に、業務サーバ２００が出力するログを定期収集タイミングＴ１０１で確認したとしても、各プロセスについて検出されるイベントの発生状況は次のようになり得る。
【０１７１】
監視サーバ１００は、フロー種別“Ｆ１”のプロセス“１０１”について、イベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”が発生していることを検出する。また、フロー種別“Ｆ２”のプロセス“１０２”について、イベント“Ｅ２１”、“Ｅ２２”、“Ｅ２３”が発生していることを検出する。更に、フロー種別“１０３”のプロセス“１０３”について、イベント“Ｅ３１”が発生していることを検出する。
【０１７２】
この場合、タイミングＴ１０１の時点において、プロセス“１０１”のイベント“Ｅ１４”が未発生である。プロセス“１０２”は全てのイベントが発生済である。プロセス“１０３”ではイベント“Ｅ３２”、“Ｅ３３”が未発生である。
【０１７３】
そこで、監視サーバ１００は、プロセス“１０１”、“１０３”が一定の条件を満たす場合に、未発生のイベントのログをピンポイント収集する。第２の実施の形態の例では、プロセス“１０１”のイベント“Ｅ１４”はピンポイント収集の対象となる。このため、次の定期収集タイミングＴ１０２よりも早いタイミングで、プロセス“１０１”の実行状況を把握できる。すなわち、プロセス“１０１”の実行状況を迅速に把握できる。また、プロセス“１０１”の実行状況に応じた警告も迅速に行える。
【０１７４】
他方、プロセス“１０３”のイベント“Ｅ３２”、“Ｅ３３”はピンポイント収集の対象とならない。プロセス“１０３”は、発生済のイベントがイベント“Ｅ３１”の１つのみだからである。このため、プロセス“１０３”の残りのイベント“Ｅ３２”、“Ｅ３３”の取得は、次の定期収集タイミングＴ１０２に行われる。なお、図２２のステップＳ５４の判定を行う場合には、フロー種別“Ｆ３”のプロセスはピンポイント収集の対象とならない（ステップＳ５４の判定はイベント数が４以上のプロセスに対して行えるものだからである）。一方、前述のように、図２２のステップＳ５４の判定を省略してもよい。この場合、ある定期収集のタイミングでイベント“Ｅ３１”、“Ｅ３２”が発生していれば、イベント“Ｅ３３”のピンポイント収集を行えることになる。
【０１７５】
定期収集タイミングＴ１０２でも同様にして業務サーバ２００が出力するログを参照して、各プロセスのイベントの発生状況が取得される。例えば、監視サーバ１００はフロー種別“Ｆ１”のプロセス“２０１”について、イベント“Ｅ１１”、“Ｅ１２”が発生していることを検出する。また、フロー種別“Ｆ２”のプロセス“１５２”について、イベント“Ｅ２１”、“Ｅ２２”、“Ｅ２３”が発生していることを検出する。また、フロー種別“Ｆ３”のプロセス“１０３”について、イベント“Ｅ３２”、“Ｅ３３”が発生していることを検出する。更に、フロー種別“Ｆ３”のプロセス“２０３”について、イベント“Ｅ３１”が発生していることを検出する。
【０１７６】
監視サーバ１００は、定期収集タイミングＴ１０２の後も同様にして、プロセス“２０１”のイベント“Ｅ１３”、“Ｅ１４”のログのピンポイント収集を行い得る（ただし、図２２のステップＳ５４の判定を行わない場合）。
【０１７７】
以上のように、監視サーバ１００によれば、処理の実行状況を効率的に取得できる。ここで、システムが出力するログを分析して業務フローの実行状況を把握するために、業務サーバ２００が出力するログを定期的に収集することが考えられる。しかし、上記のように定期収集を行うタイミングによっては、業務フローに含まれるイベントのログを全て収集することができない場合がある。すると、業務フローを組み立てられないために、業務の分析が遅延し得る。
【０１７８】
これに対して、定期収集の周期を短くすることも考えられる。しかし、ログを収集・分析する頻度が増大すると、監視サーバ１００の負荷が増大し得る。また、未発生分のイベントのログを定期収集時点から継続して監視し続けることも考えられる。しかし、この場合も常時ログの監視を行うことになり、監視サーバ１００の負荷が増大し得る。
【０１７９】
そこで、監視サーバ１００は、定期収集タイミングで未発生であるイベントの実行状況を、過去の実績から予測されたタイミングで取得する。したがって、次の定期収集タイミングまで待つよりも早く、未発生のイベントの実行状況を把握できる。このため、例えば、未発生のイベントに係る作業が行われていないなどの異常があれば、ユーザに早期に警告し得る。例えば、当該作業が次の定期収集タイミングまで放置されてしまうことの防止を図れる。
【０１８０】
また、ピンポイント収集では、対象とするイベントに限定して実行状況を取得し、ピンポイント収集のタイミングでは着目するイベント、プロセスおよびフロー種別に絞って分析を行える。このため、他の業務も一緒に分析する場合に比べて、監視サーバ１００の分析処理の負荷の増大を抑制できる。
【０１８１】
特に、発生した一連のイベントを分断することなくプロセスを構成できるので、業務の定常性の判定精度を向上できる。また、ピンポイント収集において、予測された時刻付近に対象のイベントが発生しなかった場合、または、許容される範囲外で当該イベントが発生した場合は、次の定期収集を待つよりも早く、定常性を逸脱したプロセスがある旨を警告できる。
【０１８２】
このように、未発生のイベントの発生状況を取得するための処理負荷の増大を抑制しながら、未発生のイベントの発生タイミングに合わせて、当該イベントの発生状況を迅速に確認できる。すなわち、未完了であるイベントの処理の実行状況も効率的に把握できる。その結果、定常的に行われている業務において、その定常性から逸脱した業務を即座に分析し、ボトルネックとなっている作業を把握して、業務改善を促進できる。
【０１８３】
なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク１３、メモリ装置１４およびメモリカード１６など）に記録できる。
【０１８４】
例えば、プログラムを記録した記録媒体を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
【符号の説明】
【０１８５】
１  情報取得装置
１ａ  記憶部
１ｂ  演算部
【図１】
2015022475.tif 000003
【図２】
2015022475.tif 000004
【図３】
2015022475.tif 000005
【図４】
2015022475.tif 000006
【図５】
2015022475.tif 000007
【図６】
2015022475.tif 000008
【図７】
2015022475.tif 000009
【図８】
2015022475.tif 000010
【図９】
2015022475.tif 000011
【図１０】
2015022475.tif 000012
【図１１】
2015022475.tif 000013
【図１２】
2015022475.tif 000014
【図１３】
2015022475.tif 000015
【図１４】
2015022475.tif 000016
【図１５】
2015022475.tif 000017
【図１６】
2015022475.tif 000018
【図１７】
2015022475.tif 000019
【図１８】
2015022475.tif 000020
【図１９】
2015022475.tif 000021
【図２０】
2015022475.tif 000022
【図２１】
2015022475.tif 000023
【図２２】
2015022475.tif 000024
【図２３】
2015022475.tif 000025
【図２４】
2015022475.tif 000026
【図２５】
2015022475.tif 000027