JP6163931B2 - 情報取得プログラム、情報取得方法および情報取得装置 - Google Patents

情報取得プログラム、情報取得方法および情報取得装置 Download PDF

Info

Publication number
JP6163931B2
JP6163931B2 JP2013149565A JP2013149565A JP6163931B2 JP 6163931 B2 JP6163931 B2 JP 6163931B2 JP 2013149565 A JP2013149565 A JP 2013149565A JP 2013149565 A JP2013149565 A JP 2013149565A JP 6163931 B2 JP6163931 B2 JP 6163931B2
Authority
JP
Japan
Prior art keywords
event
executed
time
processes
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2013149565A
Other languages
English (en)
Other versions
JP2015022475A (ja
Inventor
智洋 中村
智洋 中村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP2013149565A priority Critical patent/JP6163931B2/ja
Priority to US14/322,610 priority patent/US9471459B2/en
Publication of JP2015022475A publication Critical patent/JP2015022475A/ja
Application granted granted Critical
Publication of JP6163931B2 publication Critical patent/JP6163931B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/86—Event-based monitoring
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Mathematical Physics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)
  • Software Systems (AREA)

Description

本発明は情報取得プログラム、情報取得方法および情報取得装置に関する。
現在、クライアント装置とサーバ装置とを含む情報処理システムが利用されている。クライアント装置は、ユーザにより操作される。サーバ装置は、所定の業務に関する処理を実行する。クライアント装置は、所定の処理の実行をサーバ装置に依頼する。他のクライアント装置は当該処理の結果をサーバ装置から取得でき、当該結果を用いた別の処理の実行をサーバ装置に依頼し得る。例えば、当該情報処理システムを用いることで、組織内の複数のユーザが関与する一連の作業（例えば、受付、見積、決裁など）を円滑化し得る。
このような情報処理システムにおいて、業務に関する一連の処理の流れ（処理フロー）を可視化することが考えられている。例えば、ユーザにより解析の対象の範囲が決定されると、病院内システムにおける医療情報機器間の交信情報を収集し、解析することで、医療情報機器間における情報の受け渡しを示すワークフロー図を作成する提案がある。
特開２００８−３３７５４号公報
業務に関する情報を継続的に取得して、現状の業務を把握することが考えられる。例えば、業務を行いながらその実績を監視することで、処理フローの異常箇所やボトルネック箇所を抽出し、改善し得る。ところが、システム上で多くの業務が行われているほど、分析対象の情報量も増大し得る。このため、全ての業務に関する情報をリアルタイムに（または、比較的短い時間間隔で）監視し、分析しようとすると、情報を監視する処理負荷や、演算処理の負荷が増大し得る。
一方、比較的長い時間間隔（例えば、１日、１週間、１カ月など）で分析を行うとすると、改善箇所の迅速な提供を行えないという問題がある。例えば、あるタイミングまでに処理フローの一部分までの処理が完了していれば、当該一部分までの情報を取得できる。しかし、当該処理フローの残りの部分の取得は次回以降のタイミングまで待たれることになる。よって、当該処理フロー全体の実行状況を把握できるまでに遅延が生じてしまう。
１つの側面では、本発明は、処理の実行状況を効率的に把握できる情報取得プログラム、情報取得方法および情報取得装置を提供することを目的とする。
１つの態様では、コンピュータによって実行される情報取得プログラムが提供される。この情報取得プログラムは、コンピュータに、処理フローに属し順番に実行される３以上の複数の処理のうち２以上の実行済の処理それぞれが実行された各時刻を示す第１の情報を、複数の処理を実行する情報処理装置から取得し、複数の処理それぞれが過去に実行された時刻を示す第２の情報であって、記憶部に記憶された第２の情報に基づいて、複数の処理のうちの順番に実行される２つの処理の間の各時間間隔の和に対する時間間隔の比を２つの処理の組毎に計算し、２つの処理の組毎に比の平均を計算し、２以上の実行済の処理それぞれが実行された各時刻の時間間隔と、計算した比の平均とに基づいて、複数の処理のうち未実行の処理が実行済になるタイミングを予測し、予測されたタイミングで、未実行であった処理が実行されたか否かを示す第３の情報を情報処理装置から取得する、処理をコンピュータに実行させる。
また、１つの態様では、情報取得方法が提供される。この情報取得方法では、コンピュータが、処理フローに属し順番に実行される３以上の複数の処理のうち２以上の実行済の処理それぞれが実行された各時刻を示す第１の情報を、複数の処理を実行する情報処理装置から取得し、複数の処理それぞれが過去に実行された時刻を示す第２の情報であって、記憶部に記憶された第２の情報に基づいて、複数の処理のうちの順番に実行される２つの処理の間の各時間間隔の和に対する時間間隔の比を２つの処理の組毎に計算し、２つの処理の組毎に比の平均を計算し、２以上の実行済の処理それぞれが実行された各時刻の時間間隔と、計算した比の平均とに基づいて、複数の処理のうち未実行の処理が実行済になるタイミングを予測し、予測されたタイミングで、未実行であった処理が実行されたか否かを示す第３の情報を情報処理装置から取得する。
また、１つの態様では、情報取得装置が提供される。この情報取得装置は、記憶部と演算部とを有する。演算部は、処理フローに属し順番に実行される３以上の複数の処理のうち２以上の実行済の処理それぞれが実行された各時刻を示す第１の情報を、複数の処理を実行する情報処理装置から取得し、複数の処理それぞれが過去に実行された時刻を示す第２の情報であって、記憶部に記憶された第２の情報に基づいて、複数の処理のうちの順番に実行される２つの処理の間の各時間間隔の和に対する時間間隔の比を２つの処理の組毎に計算し、２つの処理の組毎に比の平均を計算し、２以上の実行済の処理それぞれが実行された各時刻の時間間隔と、計算した比の平均とに基づいて、複数の処理のうち未実行の処理が実行済になるタイミングを予測し、予測されたタイミングで、未実行であった処理が実行されたか否かを示す第３の情報を情報処理装置から取得する。
１つの側面では、処理の実行状況を効率的に把握できる。
第１の実施の形態の情報取得装置を示す図である。 第２の実施の形態の情報処理システムを示す図である。 監視サーバのハードウェア例を示す図である。 監視サーバの機能例を示す図である。 ログテーブルの例を示す図である。 イベントテーブルの例を示す図である。 フロー種別テーブルの例を示す図である。 プロセス管理テーブルの例を示す図である。 基準パラメータテーブルの例を示す図である。 イベント間隔管理テーブルの例を示す図である。 イベント間隔比評価テーブルの例を示す図である。 業務発生間隔管理テーブルの例を示す図である。 業務発生間隔評価テーブルの例を示す図である。 例外プロセステーブルの例を示す図である。 収集時刻テーブルの例を示す図である。 定期収集の例を示す図である。 ピンポイント収集の例を示す図である。 ログ収集の例を示すフローチャートである。 定期収集処理の例を示すフローチャートである。 イベント間隔比の定常性評価の例を示すフローチャートである。 業務発生間隔の定常性評価の例を示すフローチャートである。 ピンポイント収集の実行判定の例を示すフローチャートである。 ピンポイント収集処理の例を示すフローチャートである。 ピンポイント収集の具体例を示す図である。 複数のプロセスに対する定期収集の例を示す図である。
以下、本実施の形態を図面を参照して説明する。
［第１の実施の形態］
図１は、第１の実施の形態の情報取得装置を示す図である。情報取得装置１は、業務に関する一連の処理の流れ（処理フロー）の実行状況を示す情報を取得する装置である。例えば、情報取得装置１は、取得した情報を用いて、業務を監視したり分析したりする。業務に関する処理は、情報取得装置１上で実行されるものでもよいし、情報取得装置１とネットワークを介して接続された他の装置上で実行されるものでもよい。例えば、情報取得装置１は、他の装置が出力する処理のログを取得して業務の監視や分析を行ってもよい。
情報取得装置１は、記憶部１ａおよび演算部１ｂを有する。記憶部１ａは、ＲＡＭ（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＝０．０１を時間（分）に換算してσを求めると、σ＝（１／０．１５８８）×０．０１×６０分＝３．７７８分である。よって、２σは７分程度である。
このため、イベント“Ｅ１４”のピンポイント収集タイミングＴｙ＝τ＋２σは１６時１３分となる。また、境界時刻τ−２σは１５時５９分となる。分析部１３０は、時刻Ｔｙのログ収集により、イベント“Ｅ１４”の発生を検出できれば、定期収集で取得済のプロセス“１０１”の他のイベントに対してイベント“Ｅ１４”を直ちに補完できる（図２４（Ａ）の例）。
一方、分析部１３０は、時刻Ｔｙにおいて、イベント“Ｅ１４”の発生を検出できなければ、定常的に行われている業務が未実施である旨を出力部１４０により警告させる（図２４（Ｂ）の例）。なお、前述のように、時刻Ｔｙのログ収集により、イベント“Ｅ１４”の発生を検出できたとしても、発生タイミングが境界時刻１５時５９分よりも前であれば、業務の定常性を損なっている旨を出力部１４０により警告させる。
図２５は、複数のプロセスに対する定期収集の例を示す図である。第２の実施の形態の情報処理システムでは、業務サーバ２００により複数の業務処理が行われている。このため、複数のフロー種別のプロセス（業務フロー）が並行して進行する。このため、あるタイミングで定期収集を行うとしても、そのタイミングにおいて各プロセスの全てのイベントが完了している可能性は低い。
例えば、フロー種別“Ｆ１”、“Ｆ２”、“Ｆ３”のプロセスが並行して進行する場合に、業務サーバ２００が出力するログを定期収集タイミングＴ１０１で確認したとしても、各プロセスについて検出されるイベントの発生状況は次のようになり得る。
監視サーバ１００は、フロー種別“Ｆ１”のプロセス“１０１”について、イベント“Ｅ１１”、“Ｅ１２”、“Ｅ１３”が発生していることを検出する。また、フロー種別“Ｆ２”のプロセス“１０２”について、イベント“Ｅ２１”、“Ｅ２２”、“Ｅ２３”が発生していることを検出する。更に、フロー種別“Ｆ３”のプロセス“１０３”について、イベント“Ｅ３１”が発生していることを検出する。
この場合、タイミングＴ１０１の時点において、プロセス“１０１”のイベント“Ｅ１４”が未発生である。プロセス“１０２”は全てのイベントが発生済である。プロセス“１０３”ではイベント“Ｅ３２”、“Ｅ３３”が未発生である。
そこで、監視サーバ１００は、プロセス“１０１”、“１０３”が一定の条件を満たす場合に、未発生のイベントのログをピンポイント収集する。第２の実施の形態の例では、プロセス“１０１”のイベント“Ｅ１４”はピンポイント収集の対象となる。このため、次の定期収集タイミングＴ１０２よりも早いタイミングで、プロセス“１０１”の実行状況を把握できる。すなわち、プロセス“１０１”の実行状況を迅速に把握できる。また、プロセス“１０１”の実行状況に応じた警告も迅速に行える。
他方、プロセス“１０３”のイベント“Ｅ３２”、“Ｅ３３”はピンポイント収集の対象とならない。プロセス“１０３”は、発生済のイベントがイベント“Ｅ３１”の１つのみだからである。このため、プロセス“１０３”の残りのイベント“Ｅ３２”、“Ｅ３３”の取得は、次の定期収集タイミングＴ１０２に行われる。なお、図２２のステップＳ５４の判定を行う場合には、フロー種別“Ｆ３”のプロセスはピンポイント収集の対象とならない（ステップＳ５４の判定はイベント数が４以上のプロセスに対して行えるものだからである）。一方、前述のように、図２２のステップＳ５４の判定を省略してもよい。この場合、ある定期収集のタイミングでイベント“Ｅ３１”、“Ｅ３２”が発生していれば、イベント“Ｅ３３”のピンポイント収集を行えることになる。
定期収集タイミングＴ１０２でも同様にして業務サーバ２００が出力するログを参照して、各プロセスのイベントの発生状況が取得される。例えば、監視サーバ１００はフロー種別“Ｆ１”のプロセス“２０１”について、イベント“Ｅ１１”、“Ｅ１２”が発生していることを検出する。また、フロー種別“Ｆ２”のプロセス“１５２”について、イベント“Ｅ２１”、“Ｅ２２”、“Ｅ２３”が発生していることを検出する。また、フロー種別“Ｆ３”のプロセス“１０３”について、イベント“Ｅ３２”、“Ｅ３３”が発生していることを検出する。更に、フロー種別“Ｆ３”のプロセス“２０３”について、イベント“Ｅ３１”が発生していることを検出する。
監視サーバ１００は、定期収集タイミングＴ１０２の後も同様にして、プロセス“２０１”のイベント“Ｅ１３”、“Ｅ１４”のログのピンポイント収集を行い得る（ただし、図２２のステップＳ５４の判定を行わない場合）。
以上のように、監視サーバ１００によれば、処理の実行状況を効率的に取得できる。ここで、システムが出力するログを分析して業務フローの実行状況を把握するために、業務サーバ２００が出力するログを定期的に収集することが考えられる。しかし、上記のように定期収集を行うタイミングによっては、業務フローに含まれるイベントのログを全て収集することができない場合がある。すると、業務フローを組み立てられないために、業務の分析が遅延し得る。
これに対して、定期収集の周期を短くすることも考えられる。しかし、ログを収集・分析する頻度が増大すると、監視サーバ１００の負荷が増大し得る。また、未発生分のイベントのログを定期収集時点から継続して監視し続けることも考えられる。しかし、この場合も常時ログの監視を行うことになり、監視サーバ１００の負荷が増大し得る。
そこで、監視サーバ１００は、定期収集タイミングで未発生であるイベントの実行状況を、過去の実績から予測されたタイミングで取得する。したがって、次の定期収集タイミングまで待つよりも早く、未発生のイベントの実行状況を把握できる。このため、例えば、未発生のイベントに係る作業が行われていないなどの異常があれば、ユーザに早期に警告し得る。例えば、当該作業が次の定期収集タイミングまで放置されてしまうことの防止を図れる。
また、ピンポイント収集では、対象とするイベントに限定して実行状況を取得し、ピンポイント収集のタイミングでは着目するイベント、プロセスおよびフロー種別に絞って分析を行える。このため、他の業務も一緒に分析する場合に比べて、監視サーバ１００の分析処理の負荷の増大を抑制できる。
特に、発生した一連のイベントを分断することなくプロセスを構成できるので、業務の定常性の判定精度を向上できる。また、ピンポイント収集において、予測された時刻付近に対象のイベントが発生しなかった場合、または、許容される範囲外で当該イベントが発生した場合は、次の定期収集を待つよりも早く、定常性を逸脱したプロセスがある旨を警告できる。
このように、未発生のイベントの発生状況を取得するための処理負荷の増大を抑制しながら、未発生のイベントの発生タイミングに合わせて、当該イベントの発生状況を迅速に確認できる。すなわち、未完了であるイベントの処理の実行状況も効率的に把握できる。その結果、定常的に行われている業務において、その定常性から逸脱した業務を即座に分析し、ボトルネックとなっている作業を把握して、業務改善を促進できる。
なお、第１の実施の形態の情報処理は、演算部１ｂにプログラムを実行させることで実現できる。また、第２の実施の形態の情報処理は、プロセッサ１０１にプログラムを実行させることで実現できる。プログラムは、コンピュータ読み取り可能な記録媒体（例えば、光ディスク１３、メモリ装置１４およびメモリカード１６など）に記録できる。
例えば、プログラムを記録した記録媒体を配布することで、プログラムを流通させることができる。また、プログラムを他のコンピュータに格納しておき、ネットワーク経由でプログラムを配布してもよい。コンピュータは、例えば、記録媒体に記録されたプログラムまたは他のコンピュータから受信したプログラムを、ＲＡＭ１０２やＨＤＤ１０３などの記憶装置に格納し（インストールし）、当該記憶装置からプログラムを読み込んで実行してもよい。
１ 情報取得装置
１ａ 記憶部
１ｂ 演算部

Claims (11)

  1. 処理フローに属し順番に実行される３以上の複数の処理のうち２以上の実行済の処理それぞれが実行された各時刻を示す第１の情報を、前記複数の処理を実行する情報処理装置から取得し、
    前記複数の処理それぞれが過去に実行された時刻を示す第２の情報であって、記憶部に記憶された前記第２の情報に基づいて、前記複数の処理のうちの順番に実行される２つの処理の間の各時間間隔の和に対する時間間隔の比を前記２つの処理の組毎に計算し、前記２つの処理の組毎に前記比の平均を計算し、
    前記２以上の実行済の処理それぞれが実行された各時刻の時間間隔と、計算した前記比の平均とに基づいて、前記複数の処理のうち未実行の処理が実行済になるタイミングを予測し、
    予測された前記タイミングで、前記未実行であった処理が実行されたか否かを示す第３の情報を前記情報処理装置から取得する、
    処理をコンピュータに実行させる情報取得プログラム。
  2. 前記タイミングは、前記未実行の処理の実行が完了すると予測されたタイミングである、請求項１記載の情報取得プログラム。
  3. 前記タイミングでは前記未実行の処理に限定して前記第３の情報を取得する、請求項１または２記載の情報取得プログラム。
  4. 前記タイミングで前記未実行の処理が実行されていないことを検出すると、警告を行う、請求項１乃至３の何れか１項に記載の情報取得プログラム。
  5. 前記タイミングは、前記未実行の処理の実行が完了すると予測されたタイミングよりも後のタイミングである、請求項１記載の情報取得プログラム。
  6. 前記第２の情報で示される前記複数の処理それぞれが実行された各時刻の時間間隔の比に基づいて、前記第３の情報を前記タイミングで個別に取得するか否かを決定する、請求項１記載の情報取得プログラム。
  7. 前記複数の処理は順番に実行される４以上の処理であり、
    前記第１の情報に基づいて、実行済である３以上の処理それぞれが実行された各時刻の時間間隔の比を取得し、当該時間間隔の比と前記第２の情報で示される前記複数の処理それぞれが実行された各時刻の時間間隔の比の平均とに基づいて、前記第３の情報を前記予測されたタイミングで個別に取得するか否かを決定する、
    請求項１または６記載の情報取得プログラム。
  8. 前記複数の処理のうちの最初の処理が複数回実行された各時刻の時間間隔に基づいて、前記第３の情報を前記タイミングで個別に取得するか否かを決定する、請求項１、６、７の何れか１項に記載の情報取得プログラム。
  9. 前記第１の情報の取得は、所定周期で発生する複数のタイミングのうちの１つのタイミングで行われるものである、請求項１乃至８の何れか１項に記載の情報取得プログラム。
  10. コンピュータが、
    処理フローに属し順番に実行される３以上の複数の処理のうち２以上の実行済の処理それぞれが実行された各時刻を示す第１の情報を、前記複数の処理を実行する情報処理装置から取得し、
    前記複数の処理それぞれが過去に実行された時刻を示す第２の情報であって、記憶部に記憶された前記第２の情報に基づいて、前記複数の処理のうちの順番に実行される２つの処理の間の各時間間隔の和に対する時間間隔の比を前記２つの処理の組毎に計算し、前記２つの処理の組毎に前記比の平均を計算し、
    前記２以上の実行済の処理それぞれが実行された各時刻の時間間隔と、計算した前記比の平均とに基づいて、前記複数の処理のうち未実行の処理が実行済になるタイミングを予測し、
    予測された前記タイミングで、前記未実行であった処理が実行されたか否かを示す第３の情報を前記情報処理装置から取得する、
    情報取得方法。
  11. 記憶部と、
    処理フローに属し順番に実行される３以上の複数の処理のうち２以上の実行済の処理それぞれが実行された各時刻を示す第１の情報を、前記複数の処理を実行する情報処理装置から取得し、前記複数の処理それぞれが過去に実行された時刻を示す第２の情報であって、前記記憶部に記憶された前記第２の情報に基づいて、前記複数の処理のうちの順番に実行される２つの処理の間の各時間間隔の和に対する時間間隔の比を前記２つの処理の組毎に計算し、前記２つの処理の組毎に前記比の平均を計算し、前記２以上の実行済の処理それぞれが実行された各時刻の時間間隔と、計算した前記比の平均とに基づいて、前記複数の処理のうち未実行の処理が実行済になるタイミングを予測し、予測された前記タイミングで、前記未実行であった処理が実行されたか否かを示す第３の情報を前記情報処理装置から取得する、演算部と、
    を有する情報取得装置。
JP2013149565A 2013-07-18 2013-07-18 情報取得プログラム、情報取得方法および情報取得装置 Expired - Fee Related JP6163931B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2013149565A JP6163931B2 (ja) 2013-07-18 2013-07-18 情報取得プログラム、情報取得方法および情報取得装置
US14/322,610 US9471459B2 (en) 2013-07-18 2014-07-02 Information acquisition method and information acquisition apparatus

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013149565A JP6163931B2 (ja) 2013-07-18 2013-07-18 情報取得プログラム、情報取得方法および情報取得装置

Publications (2)

Publication Number Publication Date
JP2015022475A JP2015022475A (ja) 2015-02-02
JP6163931B2 true JP6163931B2 (ja) 2017-07-19

Family

ID=52344700

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013149565A Expired - Fee Related JP6163931B2 (ja) 2013-07-18 2013-07-18 情報取得プログラム、情報取得方法および情報取得装置

Country Status (2)

Country Link
US (1) US9471459B2 (ja)
JP (1) JP6163931B2 (ja)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9489031B2 (en) * 2014-03-10 2016-11-08 Apple Inc. Method to reduce acoustic noise induced by processor performance state changes in response to periodic application workloads
US9886699B2 (en) * 2014-04-08 2018-02-06 International Business Machines Corporation Performance based approval in CMS workflow process
US10296402B2 (en) * 2015-12-17 2019-05-21 Entit Software Llc Scheduling jobs
JP6827296B2 (ja) * 2016-11-01 2021-02-10 日本電信電話株式会社 データ通信方法
US20190026663A1 (en) * 2017-07-20 2019-01-24 Ca, Inc. Inferring time estimates in workflow tracking systems
US10416692B2 (en) 2017-09-19 2019-09-17 Apple Inc. Method and apparatus for reducing capacitor-induced noise
JP7302308B2 (ja) * 2019-06-07 2023-07-04 富士フイルムビジネスイノベーション株式会社 情報処理装置およびプログラム
CN110990144B (zh) * 2019-12-17 2022-11-08 深圳市晨北科技有限公司 一种任务确定方法及相关设备

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4791570A (en) * 1985-05-02 1988-12-13 Eaton-Kenway, Inc. Guide wire communication system and method
JPH11138147A (ja) 1997-11-10 1999-05-25 Hitachi Ltd データ管理装置
JP3959516B2 (ja) * 2001-08-06 2007-08-15 インターナショナル・ビジネス・マシーンズ・コーポレーション ネットワークシステム、ｃｐｕ資源プロバイダ、クライアント装置、処理サービスの提供方法、およびプログラム
JP2004005205A (ja) * 2002-05-31 2004-01-08 Ufit Co Ltd ジョブ進捗監視システム
JP2006171883A (ja) 2004-12-13 2006-06-29 Canon Inc 知識収集・格納・表示システム
JP2006268509A (ja) * 2005-03-24 2006-10-05 Nomura Research Institute Ltd ジョブ設定装置およびジョブ設定方法
JP4670455B2 (ja) 2005-04-22 2011-04-13 オムロン株式会社 工程異常検知システム
JP4864583B2 (ja) 2006-07-31 2012-02-01 株式会社東芝 病院内ワークフロー解析システム及び病院内ワークフロー解析プログラム
US20090100430A1 (en) * 2007-10-15 2009-04-16 Marco Valentin Method and system for a task automation tool
JP5024451B2 (ja) 2008-07-11 2012-09-12 富士通株式会社 業務フロー分析プログラム、方法及び装置
US8019858B2 (en) * 2008-09-09 2011-09-13 International Business Machines Corporation System and method for utilizing system lag to send facts to an end user
JP5463885B2 (ja) * 2009-12-07 2014-04-09 富士通株式会社 バッチジョブ処理時間推定プログラム、方法及び装置
JP5942509B2 (ja) * 2012-03-19 2016-06-29 日本電気株式会社 バッチ処理システム
US9152467B2 (en) * 2013-01-18 2015-10-06 Nec Laboratories America, Inc. Method for simultaneous scheduling of processes and offloading computation on many-core coprocessors

Also Published As

Publication number Publication date
US9471459B2 (en) 2016-10-18
US20150026699A1 (en) 2015-01-22
JP2015022475A (ja) 2015-02-02

Similar Documents

Publication Publication Date Title
JP6163931B2 (ja) 情報取得プログラム、情報取得方法および情報取得装置
US10868744B2 (en) Influence range identification method and influence range identification apparatus
US10171335B2 (en) Analysis of site speed performance anomalies caused by server-side issues
US10832181B2 (en) Management of business process key performance indicators
US20160378583A1 (en) Management computer and method for evaluating performance threshold value
US9257150B2 (en) Techniques for analyzing operations of one or more restaurants
EP3346205B1 (en) Inspection management system and inspection management method
JP2010526352A (ja) 統計的な分析を利用した性能障害管理システム及びその方法
JP2004171249A (ja) データベースのバックアップ実行判断方法
JP2006024017A (ja) コンピュータ資源のキャパシティを予測するためのシステム、方法およびプログラム
JP5634599B2 (ja) データ処理システム、データ処理方法、及び、プログラム
US20180121856A1 (en) Factor-based processing of performance metrics
JP5827425B1 (ja) 予兆診断システム及び予兆診断方法
US20130346950A1 (en) Usability testing
US20130232192A1 (en) Operations task management system and method
US7120648B2 (en) System and method for predicting execution time of a database utility command
US9262731B1 (en) Service ticket analysis using an analytics device
JPWO2012029500A1 (ja) 運用管理装置、運用管理方法、及びプログラム
JP6802122B2 (ja) 原因推定方法およびプログラム
US20140207504A1 (en) System and method of calculating task efforts and applying the results for resource planning
JP2004348640A (ja) ネットワーク管理システム及びネットワーク管理方法
JP2015064723A (ja) ジョブ管理システム
JP2009043188A (ja) 運用管理サポートシステム、プログラム
JP2009134535A (ja) ソフトウェア開発支援装置、ソフトウェア開発支援方法及びソフトウェア開発支援プログラム
US20190266548A1 (en) Project Progress Prediction Device and Project Progress Prediction System

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20160405

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170217

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170228

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170428

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20170523

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20170605

R150 Certificate of patent or registration of utility model

Ref document number: 6163931

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees