(57)【要約】  本発明は、業務プロセスに適用されるアプリケーションプログラムおよびパラメータのうち、業務パフォーマンスの変動原因を分析する。  分析システムは、業務プロセス５に適用されるアプリケーションプログラムおよびパラメータに関するアプリケーション設定情報６を取得するアプリケーション設定情報取得部１２と、業務パフォーマンスを示す業務パフォーマンス情報を取得する業務パフォーマンス取得部１１と、アプリケーション設定情報と業務パフォーマンス情報に基づいて、業務パフォーマンスの変動原因と推定されるアプリケーション設定情報を原因候補として検出する原因検出部１３と、原因候補のアプリケーション設定情報による変動原因への影響度を計算する影響度計算部１４と、を備える。
2017199319.tif 000002
【特許請求の範囲】
【請求項１】
業務プロセスにおける業務パフォーマンスの変動原因を分析する業務パフォーマンス変動原因分析システムであって、
業務プロセスに適用されるアプリケーションプログラムおよびパラメータに関する一つ以上のアプリケーション設定情報を取得するアプリケーション設定情報取得部と、
前記業務プロセスの業務パフォーマンスを示す一つ以上の業務パフォーマンス情報を取得する業務パフォーマンス取得部と、
前記アプリケーション設定情報と前記業務パフォーマンス情報に基づいて、前記アプリケーション設定情報のうち前記業務パフォーマンスの変動原因と推定されるアプリケーション設定情報を原因候補のアプリケーション設定情報として検出する原因検出部と、
前記原因候補のアプリケーション設定情報による前記変動原因への影響度を計算する影響度計算部と、
を備える業務パフォーマンス変動原因分析システム。
【請求項２】
前記原因候補のアプリケーション設定情報と前記影響度とを対応付けた原因リスト情報を提供する原因リスト情報提供部をさらに備える請求項１に記載の業務パフォーマンス変動原因分析システム。
【請求項３】
前記原因検出部は、前記アプリケーション設定情報のうち、前記業務パフォーマンス情報に基づいて設定される所定の判定期間に実行されたアプリケーション設定情報を、前記原因候補のアプリケーション設定情報として検出する、
請求項２に記載の業務パフォーマンス変動原因分析システム。
【請求項４】
前記原因検出部は、前記アプリケーション設定情報のうち、前記所定の判定期間内で複数回実行されたアプリケーション設定情報を、前記原因候補のアプリケーション設定情報として検出する、
請求項３に記載の業務パフォーマンス変動原因分析システム。
【請求項５】
前記原因検出部は、前記アプリケーション設定情報のうち、前記所定の判定期間内で周期的に実行されたアプリケーション設定情報を、前記原因候補のアプリケーション設定情報として検出する、
請求項４に記載の業務パフォーマンス変動原因分析システム。
【請求項６】
前記原因検出部は、前記業務パフォーマンス情報の変化傾向が反転した反転時点よりも所定の遡及時間だけ前の時点を前記所定の判定期間の開始時点とし、前記アプリケーション設定情報のうち、前記開始時点以降に実行されたアプリケーション設定情報を、前記原因候補のアプリケーション設定情報として検出する、
請求項５に記載の業務パフォーマンス変動原因分析システム。
【請求項７】
前記原因検出部は、前記業務パフォーマンス情報が予め設定される閾値を越えた領域に入った場合であって、かつ、前記反転時点よりも前記所定の遡及時間だけ前の時点を前記開始時点として設定する、
請求項６に記載の業務パフォーマンス変動原因分析システム。
【請求項８】
前記影響度計算部は、前記業務パフォーマンス情報の変化傾向が前記反転時点以降も連続して維持されている期間、前記影響度を計算し直して修正する、
請求項７に記載の業務パフォーマンス変動原因分析システム。
【請求項９】
前記原因検出部は、前記アプリケーションプログラムに、継承関係にある親ブランチのアプリケーションプログラムと子ブランチのアプリケーションプログラムとが存在する場合、前記子ブランチのアプリケーションプログラムの実行を前記親ブランチのアプリケーションプログラムの実行として取り扱う、
請求項６〜８のいずれか一項に記載の業務パフォーマンス変動原因分析システム。
【請求項１０】
前記所定の遡及時間は、前記業務プロセスの属する業種別に予め設定される、
請求項６〜８のいずれか一項に記載の業務パフォーマンス変動原因分析システム。
【請求項１１】
前記所定の遡及時間は、前記業務プロセスが複数の拠点で実行される場合において、各拠点ごとに予め設定される、
請求項６〜８のいずれか一項に記載の業務パフォーマンス変動原因分析システム。
【請求項１２】
業務プロセスにおける業務パフォーマンスの変動原因をコンピュータを用いて分析する方法であって、
前記コンピュータは、
業務プロセスに適用されるアプリケーションプログラムおよびパラメータに関する一つ以上のアプリケーション設定情報を取得するステップと、
前記業務プロセスの業務パフォーマンスを示す一つ以上の業務パフォーマンス情報を取得するステップと、
前記アプリケーション設定情報と前記業務パフォーマンス情報に基づいて、前記アプリケーション設定情報のうち前記業務パフォーマンスの変動原因と推定されるアプリケーション設定情報を原因候補のアプリケーション設定情報として検出するステップと、
前記原因候補のアプリケーション設定情報による前記変動原因への影響度を計算するステップと、
を実行する業務パフォーマンス変動原因分析方法。
【請求項１３】
前記影響度を計算するステップの後に、前記原因候補のアプリケーション設定情報と前記影響度とを対応付けた原因リスト情報を提供するステップを実行する、
請求項１２に記載の業務パフォーマンス変動原因分析方法。
【請求項１４】
前記原因候補のアプリケーション設定情報を検出するステップは、前記アプリケーション設定情報のうち、前記業務パフォーマンス情報に基づいて設定される所定の判定期間に実行されたアプリケーション設定情報を、前記原因候補のアプリケーション設定情報として検出する、
請求項１３に記載の業務パフォーマンス変動原因分析方法。
【請求項１５】
コンピュータを、業務プロセスにおける業務パフォーマンスの変動原因を分析する業務パフォーマンス変動原因分析システムとして機能させるためのコンピュータプログラムであって、
前記コンピュータに、
業務プロセスに適用されるアプリケーションプログラムおよびパラメータに関する一つ以上のアプリケーション設定情報を取得するアプリケーション設定情報取得機能と、
前記業務プロセスの業務パフォーマンスを示す一つ以上の業務パフォーマンス情報を取得する業務パフォーマンス取得機能と、
前記アプリケーション設定情報と前記業務パフォーマンス情報に基づいて、前記アプリケーション設定情報のうち前記業務パフォーマンスの変動原因と推定されるアプリケーション設定情報を原因候補のアプリケーション設定情報として検出する原因検出機能と、
前記原因候補のアプリケーション設定情報による前記変動原因への影響度を計算する影響度計算機能と、
を実現させるためのコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、業務パフォーマンス変動原因分析システムおよび分析方法に関する。
【背景技術】
【０００２】
製造や販売などの様々な業務プロセスにおいて、その業務パフォーマンスを改善するために、業務アプリケーションを変更したり、業務アプリケーションのパラメータを変更したりする。例えば、製造現場では、製品の歩留まりや消費電力等を改善するために、設定温度や温度勾配、設定圧力や加圧時間などの条件を変化させる。また例えば、電子商取引サイトでは、成約率等を高めるために、顧客の嗜好や興味にあわせてウェブページに表示する広告を変化させたりする。【０００３】
業務アプリケーションおよびそのパラメータの組合せが固定されており、その組合せの数が少ない場合は、業務アプリケーションの実行順序の影響を分析して業務指標の低下原因を探ることもできる（特許文献１，２）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００８−１１７１２７号公報
【特許文献２】特開２０１２−０８９１１３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
従来技術では、業務パフォーマンスとの因果関係の不明なアプリケーションが複数存在し、それらアプリケーションの取り得るパラメータの値も複数存在する状況下において、業務パフォーマンスに影響を与えるアプリケーションおよびそのパラメータを特定するのは難しい。特に、アプリケーションの実行時期やパラメータの設定変更時期と、業務パフォーマンスの変動時期とが重なっている場合、どのアプリケーションおよびパラメータの組合せが業務パフォーマンスに影響したのかを特定するのは困難である。【０００６】
従来技術は、業務効率低下の原因となった処理順序などを特定できるが、原因となった処理を特定することができない。アプリケーションおよびパラメータの組合せ数は膨大であるため、原因を特定するためにとても長い時間を必要とする。【０００７】
本発明は上述の課題に鑑みてなされたもので、その目的は、業務プロセスに適用されるアプリケーションプログラムおよびパラメータのうち、どのアプリケーションプログラムとパラメータが業務パフォーマンスの変動原因であるかを分析できるようにした業務パフォーマンス変動原因分析システムおよび分析方法を提供することにある。
【課題を解決するための手段】
【０００８】
上記課題を解決すべく、本発明に従う業務パフォーマンス変動原因分析システムは、業務プロセスにおける業務パフォーマンスの変動原因を分析する業務パフォーマンス変動原因分析システムであって、業務プロセスに適用されるアプリケーションプログラムおよびパラメータに関する一つ以上のアプリケーション設定情報を取得するアプリケーション設定情報取得部と、業務プロセスの業務パフォーマンスを示す一つ以上の業務パフォーマンス情報を取得する業務パフォーマンス取得部と、アプリケーション設定情報と業務パフォーマンス情報に基づいて、アプリケーション設定情報のうち業務パフォーマンスの変動原因と推定されるアプリケーション設定情報を原因候補のアプリケーション設定情報として検出する原因検出部と、原因候補のアプリケーション設定情報による変動原因への影響度を計算する影響度計算部と、を備える。
【発明の効果】
【０００９】
本発明によれば、どのアプリケーションとパラメータが業務パフォーマンスの変動原因であるかを分析することができる。
【図面の簡単な説明】
【００１０】
【図１】本実施形態の全体概要を示す説明図。
【図２】業務パフォーマンス変動原因分析システムのハードウェア構成図。
【図３】原因特定計算機の記憶内容を示す説明図。
【図４】パフォーマンス監視計算機の記憶内容を示す説明図。
【図５】業務計算機の記憶内容を示す説明図。
【図６】端末の記憶内容を示す説明図。
【図７】業務アプリケーションおよびパラメータの組合せと業務パフォーマンスの関係を分析する様子を示す機能ブロック図。
【図８】業務アプリケーションおよびパラメータを収集し、その実行に周期性があるか抽出する処理のフローチャート。
【図９】業務アプリケーションおよびパラメータの組合せの実行履歴を管理するテーブルの構成図。
【図１０】業務パフォーマンスの変動原因を分析する処理のフローチャート。
【図１１】業務アプリケーションおよびパラメータの実行履歴と業務パフォーマンスの変動履歴との関係を示す説明図。
【図１２】業務パフォーマンスの履歴を管理するテーブルの構成図。
【図１３】業務パフォーマンスに設定する閾値とその閾値を越えた時刻を管理するテーブルの構成図。
【図１４】原因候補リストを管理するテーブルの構成図。
【図１５】寄与度の計算に使用するテーブルの構成図。
【図１６】原因リストを管理するテーブルの構成図。
【図１７】第２実施例に係り、業務アプリケーションのバージョンアップを管理する様子を示す説明図。
【図１８】アプリケーションのバージョンを考慮して周期性を抽出する処理のフローチャート。
【図１９】第３実施例に係り、複数の拠点間を跨がる業務プロセスに適用する場合の説明図。
【図２０】業種別および拠点別に判定時間の始期となる遡及時間を管理するテーブルの構成図。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて、本発明の実施の形態を説明する。以下に述べるように、本実施形態では、例えば、不特定多数の業務アプリケーションおよびパラメータの組合せの中で、業務パフォーマンスの変動原因となったものを特定する。業務パフォーマンスの変動は、改善と悪化に大別できる。本実施形態は、改善と悪化のいずれにも適用できる。
【００１２】
本実施形態のシステムを業務パフォーマンスの改善原因となった業務アプリケーションおよびパラメータの特定に使用すれば、後日、業務パフォーマンスの改善に役立てることができる。これに対し、本実施形態のシステムを業務パフォーマンスの悪化原因となった業務アプリケーションおよびパラメータの特定に使用すれば、悪化原因を未然に取り除いて品質の安定化等を図ることができる。以下、業務パフォーマンスをパフォーマンスと、業務アプリケーションをアプリケーションと、呼ぶことがある。ここでのアプリケーションとは、アプリケーションプログラムである。
【００１３】
例えば、自動車や鉄道車両、航空機、電動機、発電機、家庭電化製品、電子機器、建設機械などの各種製品の製造プロセスでは、複数のアプリケーションを定期的にまたは不定期に実行する。それらアプリケーションのパラメータが異なると、パフォーマンスへの影響もそれぞれ異なることが多い。さらに、アプリケーションが頻繁に変更されることもあり、その場合は、パフォーマンスに与える影響も日々刻々と変化する。
【００１４】
工場の機器制御のアプリケーションを例に挙げて説明する。工場では、部屋ごとの空調装置の温度を制御したり、機器ごとの回転数や圧力を制御したりする。さらに、工場では、数千以上のアプリケーションが適切なタイミングで実行されることで、工場内の機器の正常稼動を維持している。
【００１５】
工場で使用されるアプリケーション群は、通常、バグ修正などのため年に１回程度更新する。しかし、今後、機器の高機能化やネットワーク接続環境の向上に伴い、アプリケーションの更新頻度は増加すると考えられる。
【００１６】
さらに、例えば、外気温に合わせて空調装置の設定温度を制御する場合などのように、アプリケーションに指定するパラメータも、そのときの環境に合わせて変化するのが通常である。
【００１７】
このような状況において、工場で生産した製品の品質が改善または悪化した際に、その原因がどのアプリケーションとどのパラメータとの組合せであるか特定するためには、組合せ爆発を収束させ、変動原因と考えられる少数の組合せに絞り込む必要がある。
【００１８】
そこで、本実施形態では、時刻に応じて変動する業務パフォーマンスを収集し、時刻に応じて変更されるアプリケーションおよびパラメータの履歴を収集して、業務パフォーマンスの改善の原因となるアプリケーションおよびパラメータの変更を特定する。本実施形態では、収集した業務パフォーマンスの値から、以下の工程を実施する。すなわち、パフォーマンスの改善の時刻を特定する工程と、収集したアプリケーション・パラメータ履歴の時刻を用いて、周期性の有無と周期性の開始時刻とを取得する工程と、周期性開始時刻と改善開始時刻とに基づき業務パフォーマンス改善の原因を特定する工程と、特定した原因リストに対して寄与度を増減させる工程とを実行する。
【００１９】
図１は、本実施形態に係る業務パフォーマンス変動原因分析システムの全体概要を示す説明図である。図１は、本発明の理解および実施に必要な範囲で、実施形態の構成例を示しており、本発明の範囲を図１に示す構成例に限定する意図はない。以下に説明する機能は、ソフトウェアとして実現することもできるし、ソフトウェアとハードウェアの組合せから実現することもできる。
【００２０】
本システムは、例えば、原因分析部１と、パフォーマンス監視部２と、アプリケーション監視部３と、端末４を含む。
【００２１】
原因分析部１は、アプリケーション（アプリケーションプログラム）およびそのパラメータの組合せのうち、業務プロセスのパフォーマンスの変動原因となったアプリケーションおよびパラメータの組合せを検出する。
【００２２】
パフォーマンス監視部２は、業務プロセスのパフォーマンスを監視しており、その監視結果を原因分析部１へ送る。アプリケーション監視部３は、業務プロセス５に適用されるアプリケーションとそのパラメータの組合せ６を監視しており、その監視結果を原因分析部１へ送る。図中では、アプリケーションを「ＡＰ」と、パラメータを「ＰＭ」と、略記する場合がある。また、アプリケーションおよびパラメータの組合せを、アプリケーション・パラメータ、ＡＰ・ＰＭ、アプリケーション設定情報と表記する場合がある。
【００２３】
ここで、同一のアプリケーションであってもパラメータが異なれば、異なる組合せ６となる。例えば「ＡＰ１，ＰＭ１」と「ＡＰ１，ＰＭ２」とは、同一アプリケーション「ＡＰ１」であるが、そのパラメータが「ＰＭ１」と「ＰＭ２」とで異なるため、別々の組合せ６として検出される。ただし、アプリケーションのバージョンが異なる場合でも、後述のように、実質的に同一のアプリケーションであるとみなされる場合もある。
【００２４】
システム管理者などのユーザは、端末４を用いて原因分析部１へアクセスすることで、原因分析部１から原因リストを取得して表示する。原因リストとは、パフォーマンスの変動原因となったアプリケーション・パラメータの組合せ６を記載した情報である。さらに、ユーザは、端末４を介して原因分析部１に対し、原因分析に使用する設定値（閾値等）を入力する。
【００２５】
原因分析部１は、例えば、パフォーマンス情報取得部１１と、アプリケーション設定情報取得部１２と、パフォーマンス変動原因分析部１３と、寄与度計算部１４と、原因リスト記憶部１５と、原因リスト提供部１６と、アプリケーションバージョン管理部１７とを備える。
【００２６】
パフォーマンス情報取得部１１は、「業務パフォーマンス取得部」の例であり、パフォーマンス管理部２から業務パフォーマンスの情報を取得し、記憶する。アプリケーション設定情報取得部１２は、アプリケーション監視部３から、アプリケーションとパラメータの組合せ６についての情報を取得し、記憶する。
【００２７】
パフォーマンス変動原因分析部１３は、パフォーマンス情報取得部１１が記憶するパフォーマンス情報とアプリケーション設定情報取得部１２が記憶するアプリケーション設定情報（アプリケーション・パラメータの組合せ）とに基づいて、パフォーマンスの変動原因であると推定されるアプリケーション設定情報を検出する。パフォーマンスの変動原因であると検出されるアプリケーション設定情報は、原因候補のアプリケーション設定情報と呼ぶことができる。以下では、パフォーマンスの変動原因をパフォーマンス値の変動原因と表現することもある。
【００２８】
パフォーマンス変動原因分析部１３は、後述のように、パフォーマンス履歴の変化に基づいて設定される所定の判定期間に実行されたアプリケーション設定情報を、原因候補のアプリケーション設定情報として抽出する。パフォーマンスが変動するよりも前の所定の判定期間内に実施されたアプリケーション設定情報（アプリケーションおよびパラメータの組合せ）は、そのパフォーマンス変動の原因である可能性が高いためである。
【００２９】
さらに、パフォーマンス変動原因分析部１３は、所定の判定期間内に複数回実行されたアプリケーション設定情報を、原因候補のアプリケーション設定情報として抽出することもできる。詳しくは、パフォーマンス変動原因分析部１３は、所定の判定期間内に周期的に実行されたアプリケーション設定情報を原因候補のアプリケーション設定情報として検出する。
【００３０】
寄与度計算部１４は、「影響度計算部」の例であり、原因候補のアプリケーション設定情報によるパフォーマンスへの寄与度（影響度）を算出する。原因候補のアプリケーション設定情報は、その寄与度と対応付けられて原因リスト記憶部１５へ記憶される。寄与度計算部１４は、パフォーマンス変動の傾向が維持されている期間、寄与度を繰り返し計算し直すことができる。原因候補のアプリケーション設定情報の寄与度を繰り返し計算することで、寄与度の精度が向上する。
【００３１】
原因リスト提供部１６は、端末４からの要求に応じて、原因リスト記憶部１５に記憶された原因リストを検索し、その検索結果を端末４へ返す。原因リスト提供部１６は、例えば、業務パフォーマンスのサービス管理を提供するポータルサイトとして構成することもできる。原因リスト提供部１６は、原因リストを電子メールに記載して、あるいは原因リストを電子メールに添付して、端末４へ送信することもできる。
【００３２】
アプリケーションバージョン管理部１７は、アプリケーションのバージョンの履歴を管理する。アプリケーションバージョン管理部１７は、例えば、いわゆるマイナーチェンジのようなバージョン変更があった場合、バージョン変更前のアプリケーションとバージョン変更後のアプリケーションとを実質的に同一のアプリケーションであると扱うことができる。これにより、定期的に実行されるアプリケーションが途中でバージョンアップした場合でも、パフォーマンス変動原因分析部１３は、そのバージョンアップしたアプリケーションが定期的に実行されていると認識することができる。
【００３３】
このように構成される本実施例によれば、業務プロセスのパフォーマンスに変動が生じた場合に、その変動原因である可能性のあるアプリケーション設定情報を抽出し、抽出したアプリケーション設定情報のパフォーマンス変動原因に対する寄与度を計算することができる。したがって、業務プロセスのシステム管理者等のユーザは、抽出されたアプリケーション設定情報と寄与度とに基づいて、パフォーマンスが変動した原因を短時間で分析することができ、使い勝手が向上する。
【００３４】
本実施形態によれば、業務プロセスのパフォーマンスが変動した場合に、その変動原因となる可能性の高いアプリケーション設定情報を短時間で特定できる。このため、その実績のあるアプリケーション設定情報を業務プロセスへ適用することで、業務プロセスのパフォーマンスを短時間で変化させることもできる。この結果、業務プロセスの管理作業を効率よく行うことができ、使い勝手が向上する。
【００３５】
さらに、本実施形態によれば、業務プロセスのパフォーマンスに関するデータとアプリケーション設定情報との関連性を効率的に分析できるため、アプリケーションの開発作業を短縮することもできる。
【実施例１】
【００３６】
図２は、業務パフォーマンス変動原因分析システムのハードウェア構成図である。本システムは、例えば、製造組立システム等の制御システムに適用することができる。本システムの対象となる制御システムでは、不特定かつ多数のアプリケーションが種々のパラメータに設定されて実行される。本実施例の業務パフォーマンス変動原因分析システムは、アプリケーションとパラメータの組み合わせの中から、業務パフォーマンスの変動原因となった組合せを抽出し、変動原因に対する寄与度を算出してユーザへ提供する。なお、以下では、変動として「改善」を例に挙げて説明する。これに限らず、変動として「悪化」に適用することもできる。また、本実施例の業務パフォーマンス変動原因分析システムは、制御システム以外の情報システムにも適用可能である。【００３７】
業務パフォーマンス変動原因分析システムは、例えば、複数の計算機を連携させることで構成することができる。本実施例に係る業務パフォーマンス変動原因分析システムは、例えば、原因分析計算機１１０、パフォーマンス監視計算機１２０、業務計算機１３０、端末１４０を通信ネットワークＣＮ１で接続することで構成されている。【００３８】
原因分析計算機１１０は「原因分析部」の例であり、図１で述べた原因分析部１に対応する。原因分析計算機１１０は、例えば、ＣＰＵ（Central Processing Unit）１１１、メモリ１１２、補助記憶装置（図中ＨＤＤ）、通信装置１１４（図中「通信１１４」と略記）を備える。原因分析計算機１１０は、拠点の業務プロセス５を制御する各業務計算機１３０からアプリケーションおよびパラメータに関する情報（アプリケーション設定情報）を取得する。さらに原因分析計算機１１０は、パフォーマンス監視計算機１２０から拠点における業務プロセス５のパフォーマンスの値を取得する。そして、原因分析計算機１１０は、アプリケーションおよびパラメータの組合せの履歴とパフォーマンスの履歴等とから、パフォーマンス変動の原因を分析し、原因リストを出力する。この処理を原因分析処理と呼ぶ。【００３９】
原因分析計算機１１０の補助記憶装置１１３には、オペレーティングシステム、コンピュータプログラム、ライブラリなどが記憶されている。ＣＰＵ１１１は、補助記憶装置１１３に記憶されたコンピュータプログラム等をメモリ１１２に読み出して実行する。これにより、原因分析計算機１１０は、所定の機能を実現する。原因分析計算機１１０の記憶内容は、図３で後述する。【００４０】
パフォーマンス監視計算機１２０は、業務プロセスにおけるパフォーマンスを監視し、その監視結果を原因分析計算機１１０へ送る計算機である。パフォーマンス監視計算機１２０は、図１で述べたパフォーマンス監視部２に対応する。パフォーマンス監視計算機１２０も、例えばＣＰＵ１２１、メモリ１２２、補助記憶装置１２３、通信装置１２４（図中「通信１２４」と略記）を備えている。パフォーマンス監視計算機１２０の記憶内容は、図４で後述する。【００４１】
パフォーマンス監視計算機１２０には、業務プロセスのパフォーマンスを測定ないし検出するための測定器５１０が通信ネットワークＣＮ２を介して接続されている。測定器５１０には、例えば、製品の外観を検査する外観検査装置、カラーセンサ、画像センサ、電圧計、電流計、抵抗計、温度計、ＰＨ計、圧力計、重量計、膜厚計などがある。作業員が品質を検査し、その合否を決定する場合、作業員による合否の判定結果を通知するための手動スイッチなども測定器５１０の一種として用いることができる。【００４２】
業務計算機１３０は、業務プロセス５の少なくとも一部を担当する計算機である。業務計算機１３０は、図１で述べたアプリケーション監視部３に対応する。業務計算機１３０も、例えばＣＰＵ１３１、メモリ１３２、補助記憶装置１３３、通信装置１３４（図中「通信１３４」と略記）を備えている。業務計算機１３０の記憶内容は図５で後述する。【００４３】
業務計算機１３０は、通信ネットワークＣＮ２を介して被制御機器５２０に接続されている。被制御機器５２０には、例えば、電動モータ、発電機、油圧モータ、油圧シリンダ、空圧シリンダ、制御弁、ヒータ、冷凍機、空調装置、ソレノイド、ポンプ、送風機、コンベアなどがある。業務計算機１３０は、アプリケーションＰ３０（図５参照）を実行し、業務プロセス５のうちの担当箇所を制御する。業務計算機１３０は、アプリケーションＰ３０の実行履歴（実行時期、パラメータ等）をアプリケーション・パラメータ監視部Ｐ３１により監視し、その監視結果を原因分析計算機１１０へ送信する。【００４４】
端末１４０は、図１の端末４に対応する。端末１４０も、例えばＣＰＵ１４１、メモリ１４２、補助記憶装置１４３、通信装置１４４（図中「通信１４４」と略記）を備える。ユーザは、端末１４０を介して、原因分析計算機１１０に対して原因分析処理で使用する設定値（閾値など）を入力することができる。さらに、ユーザは、原因分析計算機１１０から取得した原因リストを端末１４０の画面に表示させたりする。端末１４０は、例えばデスクトップ型パーソナルコンピュータ、ノート型またはタブレット型のパーソナルコンピュータ、携帯電話、携帯情報端末のように構成してもよい。【００４５】
端末１４０は、ユーザとの間で情報を交換するためのユーザインターフェース装置を備える。ユーザインターフェース装置には、ユーザが原因分析計算機１１０等へ情報を入力するための情報入力装置と、原因分析計算機１１０からの情報等をユーザに提示するための情報出力装置とがある。情報入力装置には、例えば、キーボード、マウス、タッチパネル、音声指示装置等がある。情報出力装置には、例えば、ディスプレイ、音声合成装置、プリンタ等がある。【００４６】
図２に示すハードウェア構成は一つの例示であって、本発明は図２に示す構成例に限定されない。例えば、複数の計算機で実現する機能を一つの計算機で実現してもよいし、一つの計算機で実現する機能を複数の計算機に分けて実現してもよい。例えば、パフォーマンス監視計算機１２０と原因分析計算機１１０とを一つの計算機で実現してもよいし、パフォーマンス監視計算機１２０と業務計算機１３０のいずれかとを一つの計算機で実現してもよい。業務計算機１３０のいずれか一つと原因分析計算機１１０を一つの計算機で実現してもよい。【００４７】
図２では、パフォーマンス監視計算機１２０を１台だけ設置する場合を示すが、複数のパフォーマンス監視計算機１２０を設置し、各パフォーマンス監視計算機１２０を原因分析計算機１１０に接続してもよい。【００４８】
通信ネットワークＣＮ２は、パフォーマンス監視用ネットワークと、制御用ネットワークとに分けてもよい。通信ネットワークＣＮ１と通信ネットワークＣＮ２とを共通ネットワークとして構成してもよい。【００４９】
原因分析計算機１１０にユーザインターフェース部を設け、ユーザはそのユーザインターフェース部を用いて原因分析計算機１１０と情報交換してもよい。端末１４０を原因分析計算機１１０に直接接続する構成でもよい。【００５０】
図３は、原因分析計算機１１０の記憶内容を示す。原因分析計算機１１０の補助記憶装置１１３またはメモリ１１２には、コンピュータプログラムＰ１０〜Ｐ１６と、リストやテーブル等の管理情報Ｔ１０〜Ｔ１５とが記憶されている。図３〜図６では、オペレーティングシステムなどのコンピュータプログラムは図示を省略している。【００５１】
コンピュータプログラムには、パフォーマンス情報取得部Ｐ１０、アプリケーション・パラメータ取得部Ｐ１１、パフォーマンス変動原因分析部Ｐ１２、寄与度計算部Ｐ１３、周期性抽出部Ｐ１４、原因リスト提供部Ｐ１５がある。【００５２】
管理情報には、アプリケーション・パラメータ履歴Ｔ１０、パフォーマンス履歴Ｔ１１、原因候補リストＴ１２、原因リストＴ１３、閾値・閾値超過情報Ｔ１４、評価テーブルＴ１５がある。これら管理情報の詳細は後述する。先にコンピュータプログラムの概要を説明する。【００５３】
パフォーマンス情報取得部Ｐ１０は、図１のパフォーマンス情報取得部１１に対応している。パフォーマンス情報取得部Ｐ１０は、パフォーマンス監視計算機１２０からパフォーマンス情報を取得して、パフォーマンス履歴Ｔ１１へ記憶する。【００５４】
アプリケーション・パラメータ取得部Ｐ１１は、図１のアプリケーション設定情報取得部１２に対応する。アプリケーション・パラメータ取得部Ｐ１１は、「アプリケーション設定情報」としてのアプリケーションおよびパラメータの組合せを、各業務計算機１３０から取得する。【００５５】
パフォーマンス変動原因分析部Ｐ１２は、図１のパフォーマンス変動原因分析部１３に対応する。パフォーマンス変動原因分析部Ｐ１２は、パフォーマンス情報とアプリケーション・パラメータの組合せについての情報（アプリケーション・パラメータ情報、ＡＰ・ＰＭと略記する場合がある）とに基づいて、パフォーマンスの変動原因となったと推定されるアプリケーション・パラメータ情報（原因候補のアプリケーション・パラメータ情報）を抽出する。【００５６】
寄与度計算部Ｐ１３は、図１の寄与度計算部１４に対応する。寄与度計算部Ｐ１３は、原因候補として抽出されたアプリケーション・パラメータ情報について、その情報がパフォーマンス変動に影響した度合である寄与度を算出する。寄与度は、そのアプリケーション・パラメータ情報が業務プロセスのパフォーマンス変動に影響を与えた確率の高さ、可能性、と言い換えることもできる。【００５７】
周期性抽出部Ｐ１４は、パフォーマンス変動原因分析部Ｐ１２により使用される機能であり、所定の判定期間内に実施されたアプリケーション・パラメータ情報について、周期性があるか否かを判定する。周期性のあるアプリケーション・パラメータ情報とは、周期的に実施されるアプリケーション・パラメータ情報という意味である。周期性抽出部Ｐ１４は、周期性があると判定した場合、周期性の開始時刻も検出する。【００５８】
原因リスト提供部Ｐ１５は、図１の原因リスト提供部１６に対応する。原因リスト提供部Ｐ１６は、端末４からの要求に応じて、パフォーマンスの変動原因として検出されたアプリケーション・パラメータ情報と寄与度を含む原因リストを端末４へ送信する。【００５９】
アプリケーションバージョン管理部Ｐ１６は、図１のアプリケーションバージョン管理部１７に対応する。アプリケーションバージョン管理部Ｐ１６は、アプリケーションのバージョンアップ情報を取得すると、アプリケーションのバージョンツリーを生成し、バージョンアップ前のアプリケーションとバージョンアップ後のアプリケーションとの相違がどの程度であるか管理する。【００６０】
図４は、パフォーマンス監視計算機１２０の記憶内容を示す。パフォーマンス監視計算機１２０の補助記憶装置１２３またはメモリ１２２には、コンピュータプログラムとしてのパフォーマンス監視部Ｐ２０が記憶されている。パフォーマンス監視部Ｐ２０は、測定器５１０からの信号や情報を定期的にまたは不定期に取得することで、業務プロセス５のパフォーマンスを監視する。【００６１】
図５は、業務計算機１３０の記憶内容を示す。業務計算機１３０の補助記憶装置１３３またはメモリ１３２には、コンピュータプログラムとして、アプリケーションプログラムＰ３０およびアプリケーション・パラメータ監視部Ｐ３１が記憶されている。【００６２】
アプリケーションプログラムＰ３０は、例えば、温度制御、圧力制御、流量制御、回転数制御、電圧制御、電流制御、速度制御などの所定の制御処理を実行するコンピュータプログラムである。アプリケーション・パラメータ監視部Ｐ３１は、詳しくは図１のアプリケーション監視部３に対応しており、アプリケーションプログラムＰ３０の実行を監視して原因分析計算機１１０へ送るコンピュータプログラムである。【００６３】
図６は、端末１４０の記憶内容を示す。端末１４０の補助記憶装置１４３またはメモリ１４２には、コンピュータプログラムとして、閾値入力部Ｐ４０および原因リスト表示部Ｐ４１が記憶されている。【００６４】
閾値入力部Ｐ４０は、パフォーマンスに対する閾値を原因分析計算機１１０へ入力して設定させるためのコンピュータプログラムである。閾値の意義については、図１１で後述する。原因リスト表示部Ｐ４１は、原因分析計算機１１０から原因リストを取得し、ディスプレイに表示させるコンピュータプログラムである。ユーザは、表示された原因リストに対して、キーボードやマウスなどで操作することもできる。【００６５】
図７は、パフォーマンスの変動原因を検出する処理を模式的に示す説明図である。各業務計算機１３０のアプリケーション・パラメータ監視部Ｐ３１は、実行したアプリケーションとパラメータの情報を原因分析計算機１１０へ送信する。原因分析計算機１１０のアプリケーション・パラメータ取得部Ｐ１１は、アプリケーション・パラメータ情報を取得すると、アプリケーション・パラメータ履歴Ｔ１０へ記憶させる。周期性抽出部Ｐ１４は、アプリケーション・パラメータ履歴Ｔ１０に記憶された情報を分析することで、周期性の有無や周期性の開始時刻を検出する。【００６６】
パフォーマンス監視計算機１２０のパフォーマンス監視部Ｐ２０は、業務プロセスのパフォーマンスを監視し、その監視結果を原因分析計算機１１０へ送る。原因分析計算機１１０のパフォーマンス情報取得部Ｐ１０は、パフォーマンス監視部Ｐ２０からパフォーマンス情報を受領すると、パフォーマンス履歴Ｔ１１へ記憶させる。【００６７】
パフォーマンス変動原因分析部Ｐ１２は、パフォーマンス履歴Ｔ１１に記憶されたパフォーマンス情報と、アプリケーション・パラメータ履歴Ｔ１０に記憶されたアプリケーション・パラメータ情報とに基づいて、パフォーマンスが変動した原因となる原因候補のアプリケーション・パラメータ情報を抽出する。この抽出の際に、変動原因分析部Ｐ１２は、周期性抽出部Ｐ１４やアプリケーションバージョン管理部Ｐ１６を利用できる。変動原因の候補となるアプリケーション・パラメータ情報の抽出方法については後述する。【００６８】
寄与度計算部Ｐ１３は、原因候補のアプリケーション・パラメータ情報について、パフォーマンス変動原因に対する寄与度を算出する。原因候補のアプリケーション・パラメータ情報に寄与度を対応付けた情報は、原因リストＴ１３に記憶される。【００６９】
原因リスト提供部Ｐ１５は、端末１４０の原因リスト表示部Ｐ４１からの要求に応じて、原因リストＴ１３の記憶内容の少なくとも一部を原因リスト表示部Ｐ４１へ送る。【００７０】
端末１４０の閾値入力部Ｐ４０は、所定の判定期間を設定するために使用する閾値を原因分析計算機１１０に入力し、閾値・閾値超過情報Ｔ１４へ記憶させる。所定の判定期間とは、パフォーマンスの変動原因となった可能性のあるアプリケーション・パラメータ情報を抽出するための期間である。【００７１】
図８は、アプリケーション・パラメータ情報を取得する処理と、周期性を抽出する処理とを示すフローチャートである。本処理は、アプリケーション・パラメータ取得部Ｐ１１および周期性抽出部Ｐ１４により周期的に実行される。【００７２】
アプリケーション・パラメータ取得部Ｐ１１は、アプリケーション・パラメータ監視部Ｐ３１からアプリケーション・パラメータ情報を取得する（Ｓ１０）。アプリケーション・パラメータ取得部Ｐ１１は、受領したアプリケーション・パラメータ情報をアプリケーション・パラメータ履歴Ｔ１０へ記憶する（Ｓ１１）。アプリケーション・パラメータ情報は、アプリケーション名、パラメータ名、パラメータ値などを含む。アプリケーション・パラメータ情報をアプリケーション・パラメータ履歴Ｔ１０へ記憶する際に、同一のアプリケーション名・パラメータ名・パラメータ値を持つ行が既に存在する場合、同一のアプリケーション・パラメータ情報とみなして、同一の履歴キーを用いて、履歴Ｔ１０へ追加する。【００７３】
周期性抽出部Ｐ１４は、アプリケーション・パラメータ履歴Ｔ１０から、同一アプリケーション・パラメータ情報についての過去の実行時刻を取得する（Ｓ１２）。周期性抽出部Ｐ１４は、ステップＳ１１で履歴Ｔ１０に登録されたアプリケーション・パラメータ情報に周期性があるか判断する（Ｓ１３）。【００７４】
周期性抽出部Ｐ１４は、周期性ありと判定すると（Ｓ１３：ＹＥＳ）、周期性の開始時刻と周期性に関する情報とを原因リストＴ１３へ記憶する（Ｓ１４）。【００７５】
図９は、アプリケーション・パラメータ履歴Ｔ１０の構成を示す。アプリケーション・パラメータ履歴Ｔ１０は、例えば、履歴キーＣ１００、アプリケーション名Ｃ１０１、パラメータ名Ｃ１０２、パラメータ値Ｃ１０３、周期性Ｃ１０４、周期性開始時刻Ｃ１０５、実行時刻Ｃ１０６、環境Ｃ１０７を対応付けて管理する。【００７６】
履歴キーＣ１００は、各行を一意に区別するための情報である。アプリケーション名Ｃ１０１は、アプリケーションを特定する名称である。パラメータ名Ｃ１０２は、アプリケーションに設定されるパラメータを特定する名称である。パラメータ値Ｃ１０３は、パラメータの設定値である。【００７７】
周期性Ｃ１０４は、アプリケーション・パラメータ情報が周期的に実行されているかを示すフラグである。周期性開始時刻Ｃ１０５は、周期性が開始された時刻である。実行時刻Ｃ１０６は、アプリケーションの実行時刻である。環境Ｃ１０７は、アプリケーションの実行された環境を示す。ここでは、環境Ｃ１０７に、アプリケーションの実行された拠点を特定する情報を記憶する。【００７８】
周期性抽出について説明する。図９に示すように、周期性抽出部Ｐ１４は、実行時刻が「１２／０１ １５：３０」「１２／０１ １８：３０」「１２／０１ ２１：３０」という３つの時刻情報を持つ履歴キー「空調＃Ａ１」について、実行時刻の間隔が３時間であることを抽出する。周期性抽出部Ｐ１４は、ステップＳ１４において、周期性開始時刻Ｃ１０５に一番初めの実行時刻である「１２／０１ １５：３０」を記録し、周期性Ｃ１０４に「あり（３ｈ）」と記録する。周期性が認められない場合は、「なし」と記録する。周期性の検出には、一般的な計算方法として、フーリエ変換などが利用できる。【００７９】
図１０を用いて、パフォーマンスの変動原因を分析する処理を説明する。原因分析計算機１１０は、パフォーマンス情報の取得から原因リスト更新までの一連の処理を継続的に実行する。【００８０】
パフォーマンス情報取得部Ｐ１０は、受信したＫＰＩ名やパフォーマンス値に基づいて、パフォーマンス履歴Ｔ１１を更新する（Ｓ２０）。さらに、パフォーマンス変動原因分析部Ｐ１２は、ＫＰＩ名およびパフォーマンス値を取得する（Ｓ２０）。例えば、パフォーマンス履歴Ｔ１１には、ＫＰＩ名が「ダウンタイム」、パフォーマンス値が「８％」、時刻が「１２／０１ １８：００」というデータが記憶される。【００８１】
パフォーマンス変動原因分析部Ｐ１２は、ＫＰＩ名に対応する閾値を閾値・閾値超過情報Ｔ１４から取得し、取得した閾値とステップＳ２０で記憶したパフォーマンス値とを比較する（Ｓ２１）。パフォーマンス変動原因分析部Ｐ１２は、閾値を超過した後において、パフォーマンスの改善が連続していることを示す改善中フラグＣ１４２（図１３参照）に記録する値（ＹＥＳ、またはＮＯ）を計算する。【００８２】
例えば、パフォーマンス変動原因分析部Ｐ１２は、「パフォーマンス値が閾値を超えて悪化しているか、もしくは前回の閾値を超えて悪化した時」から、連続してパフォーマンス値が改善している場合に「ＹＥＳ」と判定し、それ以外は「ＮＯ」と判定する。【００８３】
ここで、図１２のパフォーマンス履歴Ｔ１１を参照する。パフォーマンス履歴Ｔ１１は、例えば、ＫＰＩ（Key Performance Indicators）名Ｃ１１０、リードタイムＣ１１１、改善方向Ｃ１１２、時刻Ｃ１１３、パフォーマンス値Ｃ１１４を管理する。【００８４】
ＫＰＩ名Ｃ１１０は、パフォーマンスの指標となるＫＰＩを特定する。ＫＰＩには、例えば、工程の製造停止時間を示す「ダウンタイム」、製品に占める不良品の割合である「不良率」などがある。改善方向Ｃ１１２は、パフォーマンス変動が改善方向であると判定する場合の条件を示す。改善方向Ｃ１１２に「減少」が設定されている場合、パフォーマンス値が減少すると、パフォーマンスが改善していると判断される。例えば、ダウンタイムなどのネガティブなＫＰＩは、パフォーマンス値が低いほど改善傾向にある。時刻Ｃ１１３は、パフォーマンス値Ｃ１１４を取得した時刻である。【００８５】
例えば図１２のパフォーマンス履歴Ｔ１１では、取得時刻が「１２／０１ １２：００」の場合に、閾値の「１０％」を超えるパフォーマンス値「１３％」を測定している。ここでは、パフォーマンス値に対する改善方向Ｃ１１２には「減少」が設定されているため、パフォーマンス値の少ないほうが業務パフォーマンスが良いことを意味する。【００８６】
時刻「１２／０１ １２：００」におけるパフォーマンス値「１３％」は、閾値「１０％」よりも多いため、悪化をしている状況である。そこで、ステップＳ２２のフラグ計算では「ＮＯ」と判断される。【００８７】
時刻「１２／０１ １５：００」におけるパフォーマンス値は「１０％」であり、閾値「１０％」を超えて悪化してはいない。今回取得したパフォーマンス値「１０％」は、前回の取得時刻「１２／０１ １２：００」でのパフォーマンス値「１３％」に比べると改善しているため、ステップＳ２２でのフラグ計算では「ＹＥＳ」と判定される。【００８８】
図１０に戻る。パフォーマンス変動原因分析部Ｐ１２は、閾値を超過した後において改善傾向が続いていることを示す改善中フラグの計算を終えると（Ｓ２２）、その改善中フラグの値が「ＹＥＳ」であるか判定する（Ｓ２３）。改善中フラグの値が「ＹＥＳ」ではない場合（Ｓ２３：ＮＯ）、本処理は終了する。本実施例では、パフォーマンスが改善傾向を示しているときに、所定の判定期間内に実施されたアプリケーション・パラメータ情報を、そのパフォーマンス改善の原因として推定するため、パフォーマンスが改善していない場合（Ｓ２３：ＮＯ）、処理は終了する。【００８９】
改善中フラグの値が「ＹＥＳ」である場合（Ｓ２３：ＹＥＳ）、パフォーマンス変動原因分析部Ｐ１２は、閾値・閾値超過情報Ｔ１４から改善開始時刻Ｃ１４３を取得する（Ｓ２４）。改善開始時刻Ｃ１４３の値が「Ｎｏｎｅ」に設定されている場合、現在時刻を改善開始時刻として記録する（Ｓ２４）。【００９０】
パフォーマンス変動原因分析部Ｐ１２は、アプリケーション・パラメータ履歴Ｔ１０から周期性Ｃ１０４を取得し、周期性Ｃ１０４の値が「あり」の場合はその行を全て抽出し、抽出した全ての行を周期性開始時刻Ｃ１０５の値でソートする（Ｓ２５）。【００９１】
パフォーマンス変動原因分析部Ｐ１２は、改善開始時刻Ｃ１４３からリードタイムＣ１１１だけ遡った時刻を判定期間の始期とし、周期性が認められるアプリケーション・パラメータ情報の中から、判定期間の始期よりも後に実施されたアプリケーション・パラメータ情報を全て抽出する（Ｓ２６）。【００９２】
最後に、パフォーマンス変動原因分析部Ｐ１２は、ステップＳ２６で抽出したアプリケーション・パラメータ情報のリストを原因候補リストとして、寄与度計算部Ｐ１３へ渡す（Ｓ２７）。【００９３】
図１１は、アプリケーション・パラメータ情報の実施時期とパフォーマンスの変動との関係を示す。図１１では、例えば「ＡＰ１１，ＰＭ１１」「ＡＰ２１，ＰＭ２１」のように、同一または異なるアプリケーションが、同一または異なるパラメータに設定されて実行されている。【００９４】
図１１中に示す太い折れ線は、パフォーマンスの変化を示す。ここでは、パフォーマンス値が高いほど、パフォーマンスは改善傾向にあるものとする。【００９５】
時刻Ｔ０からパフォーマンス値が次第に減少しており、時刻Ｔ１で閾値Ｔｈを超えて悪化したとする。その後も、パフォーマンス値は減少し続けるが、時刻Ｔ３で反転する。つまり、時刻Ｔ３において、パフォーマンス値が上昇し始め、改善方向へ向かう。時刻Ｔ４でパフォーマンス値の改善が停止したとする。【００９６】
本実施例では、パフォーマンス値が閾値Ｔｈを超えて悪化した時刻Ｔ１以降において、パフォーマンス値の変化傾向が反転した時刻Ｔ３よりも所定のリードタイムだけ遡った時刻Ｔ２を、判定期間の開始時刻とする。リードタイムＣ１１１は、「所定の遡及時間」に対応する。図１１では、リードタイムを「ＬＴ」と略記する。閾値Ｔｈを超えて悪化する時刻Ｔ１以降の時間領域は、「閾値を越えた領域」に対応する。改善傾向が終了した時刻を、判定期間の終了時刻とする。【００９７】
パフォーマンス値が改善傾向を示す期間（Ｔ４−Ｔ３）にリードタイムＬＴを加えた判定期間（Ｔ４−Ｔ２）内に実行されたアプリケーション・パラメータ情報「ＡＰ１１，ＰＭ１２」「ＡＰ２１，ＰＭ２２」「ＡＰ３１，ＰＭ３１」「ＡＰ３１，ＰＭ３２」は、パフォーマンス値の改善に役立った可能性がある。【００９８】
ここで、アプリケーション・パラメータ情報「ＡＰ１１，ＰＭ１２」「ＡＰ２１，ＰＭ２２」「ＡＰ３１，ＰＭ３１」は、判定期間内で複数回実行されている。アプリケーション・パラメータ情報「ＡＰ１１，ＰＭ１２」は、Ｄ３，Ｄ４，Ｄ５に示すように、判定期間内に周期的に３回実行されている。アプリケーション・パラメータ情報「ＡＰ２１，ＰＭ２２」は、Ｄ７，Ｄ８に示すように判定期間内に周期的に２回実施されている。アプリケーション・パラメータ情報「ＡＰ３１，ＰＭ３１」は、Ｄ１０，Ｄ１１に示すように、判定期間内に周期的に２回実行されている。【００９９】
これらの判定期間内に周期的に実行されているアプリケーション・パラメータ情報は、パフォーマンス値の改善に寄与した可能性が高いと考えることができる。さらに、周期的に実行されたアプリケーション・パラメータ情報のうち、最初に実行されたアプリケーション・パラメータ情報の方が、後に実行されるアプリケーション・パラメータ情報よりもパフォーマンス値の改善に寄与した可能性が高いと考えられる。図１１の例では、Ｄ３の方がＤ４やＤ５に比べて、パフォーマンス値の改善に寄与した可能性が高い。同じく、Ｄ７の方がＤ８に比べて、パフォーマンス値の改善に寄与した可能性が高い。【０１００】
一方、アプリケーション・パラメータ情報「ＡＰ３１，ＰＭ３２」は、判定期間の終わり頃に一回だけ実行されている（Ｄ１４）。この場合、Ｄ１４での実行は、パフォーマンス値の改善に寄与しているとは考えにくい。【０１０１】
このようにして、本実施例の寄与度計算部Ｐ１３は、図１５で後述する評価テーブルＴ１５を用いて、判定期間内に実施された原因候補のアプリケーション・パラメータ情報について、寄与度を計算する。寄与度計算部Ｐ１３は、原因候補のアプリケーション・パラメータ情報について、繰り返し寄与度を計算し続け、加算していく。従って、判定期間終了後に、最も寄与度の大きいアプリケーション・パラメータ情報を、パフォーマンス値の改善に最も貢献したアプリケーション・パラメータ情報であると判断できる。【０１０２】
図１３を用いて、閾値・閾値超過情報Ｔ１４を説明する。閾値・閾値超過情報Ｔ１４は、例えば、主キーとなるＫＰＩ名Ｃ１４０と、それに対応する閾値Ｃ１４１と、改善中フラグＣ１４２と、改善開始時刻Ｃ１４３と、更新時刻Ｃ１４４を保持する。【０１０３】
改善開始時刻Ｃ１０４は、図１１の例で言えば、パフォーマンス値が閾値Ｔｈを超過した時刻Ｔ１以降において、パフォーマンス値の変化方向が改善方向へ反転した時刻Ｔ３である。【０１０４】
図１３に示す例では、「ダウンタイム」というＫＰＩ名で示されるパフォーマンス値に対して、２段階の閾値「１０％」「１５％」がユーザによって指定されている。第１段階の閾値「１０％」に対する改善中フラグの値は「ＹＥＳ」であり、改善開始時刻は「１２／０１ １２：００」、更新時刻は「１２／０１ １８：００」である。従って、「ダウンタイム」のパフォーマンス値が閾値「１０％」を超えて悪化した後において改善が始まった時刻は「１２／０１ １２：００」である。その改善開始時刻「１２／０１ １２：００」から最新の更新時刻「１２／０１ １８：００」まで、パフォーマンス値が改善中の状態を保ち続けている。この改善中を継続する状態は、アプリケーション・パラメータの組を検索する処理で使用される。【０１０５】
次に、寄与度計算部Ｐ１３の計算方法について、図１４〜図１６を用いて説明する。寄与度計算部Ｐ１３は、パフォーマンス変動原因分析部Ｐ１２から原因候補リストＴ１２を取得し、原因候補のアプリケーション・パラメータ情報のそれぞれについて寄与度を計算する。【０１０６】
図１４は、原因候補リストＴ１２を示す。原因候補リストＴ１２は、例えば、順序Ｃ１２０、ＫＰＩ名Ｃ１２１、履歴キーＣ１２２、周期性開始時刻Ｃ１２３を保持する。周期性開始時刻Ｃ１２３は、アプリケーション・パラメータ情報の周期的な実行が開始された時刻である。原因候補リストＴ１２の各行は、原因候補として抽出されたアプリケーション・パラメータ情報の履歴が、時刻の早い順でソートされている。【０１０７】
図１５は、寄与度の計算に使用する評価テーブルＴ１５を示す。評価テーブルＴ１５は、例えば原因候補リストＴ１２における順序Ｃ１５０と、寄与度の増分Ｃ１５１を対応付けて保持する。【０１０８】
評価テーブルＴ１５では、原因候補リストＴ１２での順序が若いほど、寄与度の増分は大きくなるように設定されている。【０１０９】
寄与度計算部Ｐ１３は、原因候補リストＴ１２において順序が「＃１」である履歴キー「空調＃Ａ１」を持つアプリケーション・パラメータ情報について、その寄与度を「１０」と計算する。この計算結果に基づき、寄与度計算部Ｐ１３は、原因リストＴ１３を更新する。計算された寄与度は、原因リストＴ１３の寄与度Ｃ１３３に格納される。【０１１０】
図１６は、原因リストＴ１３を示す。原因リストＴ１３は、例えば、ＫＰＩ名Ｃ１３０、履歴キーＣ１３１、更新時刻Ｃ１３２、寄与度Ｃ１３３を対応付けて保持する。【０１１１】
ここで、原因候補リストＴ１２での順序が「＃１」である履歴キー「空調＃Ａ１」に着目すると、原因リストＴ１３の寄与度Ｃ１３３には「０．５」が格納されている。寄与度計算部Ｐ１３は、上述した寄与度計算結果「１０」を、寄与度「０．５」に加算する。これにより、寄与度Ｃ１３３の値は「０．５」から「１０．５」へ更新される。寄与度計算部Ｐ１３は、原因リストＴ１３の各行の更新時刻Ｃ１３３を現在時刻に更新する。【０１１２】
このように構成される本実施例によれば、アプリケーション・パラメータ情報とパフォーマンス情報とに基づいて、パフォーマンスの変動原因となった原因候補のアプリケーション・パラメータ情報を抽出し、原因候補のアプリケーション・パラメータ情報によるパフォーマンス変動への寄与度を算出することができる。従って、本実施例によれば、寄与度の高いアプリケーション・パラメータ情報を、パフォーマンス変動に寄与する可能性の高いアプリケーション・パラメータ情報であると判定できる。【０１１３】
本実施例では、原因候補のアプリケーション・パラメータ情報に寄与度を対応付けた原因リストＴ１３を端末４に表示させることができる。従って、ユーザは、例えばパフォーマンス値が悪化している場合や、パフォーマンス値を改善したい場合などに、パフォーマンス値の改善効果を見込めるアプリケーション・パラメータ情報を見つけ出して、業務プロセスへ適用することができる。本実施例では、多数のアプリケーション・パラメータ情報の中からパフォーマンス値の改善実績のあるものを検出して業務プロセスへ適用できるため、経験の浅いユーザであっても業務プロセスを管理することができる。【０１１４】
本実施例では、パフォーマンス値の変化傾向が反転した時刻からリードタイムだけ遡った時刻を開始時刻とする判定期間内において、アプリケーション・パラメータ情報の実施頻度を検出し、寄与度を計算する。従って、パフォーマンス値の改善に寄与した可能性の高いアプリケーション・パラメータ情報を抽出することができる。【０１１５】
本実施例では、所定の判定期間内で複数回実行されたアプリケーション・パラメータ情報、時に周期的に実行されたアプリケーション・パラメータ情報を原因候補のアプリケーション・パラメータ情報として抽出する。従って、パフォーマンス値の改善に寄与した可能性の高いアプリケーション・パラメータ情報を検出でき、信頼性および使い勝手がさらに向上する。【０１１６】
本実施例では、所定の判定期間内に複数回実行されたアプリケーション・パラメータ情報のうち、時間的に早く実行されたアプリケーション・パラメータ情報ほど高い寄与度となるように計算する。これにより、パフォーマンス値の改善に寄与した可能性の高いアプリケーション・パラメータ情報を、より一層高い信頼性をもって検出できる。【０１１７】
本実施例では、判定期間内に実行されたアプリケーション・パラメータ情報のみを原因候補のアプリケーション・パラメータ情報として抽出する。これにより本実施例では、業務プロセスで実施される多数のアプリケーション・パラメータ情報をフィルタリングして、いわゆる組合せ爆発を抑制でき、比較的短時間でパフォーマンス値の改善に寄与するアプリケーション・パラメータ情報を特定できる。【０１１８】
本実施例では、原因候補のアプリケーション・パラメータ情報の寄与度を繰り返し計算し直して更新するため、寄与度の信頼性を高めることができ、パフォーマンス値の改善に寄与したアプリケーション・パラメータ情報の特定精度を向上できる。【０１１９】
なお、寄与度計算部Ｐ１３は、周期性開始時刻からの経過時間を考慮して、寄与度を計算してもよい。例えば、周期性開始時刻からの経過時間が長くなるほど、寄与度を低下させることもできる。【０１２０】
さらに、寄与度計算部Ｐ１３は、判定期間内だけでなく判定期間の経過後においても実施されるアプリケーション・パラメータ情報がある場合、そのアプリケーション・パラメータ情報の寄与度を低下させることもできる。【０１２１】
なお、アプリケーション・パラメータ履歴Ｔ１０は、アプリケーション名Ｃ１０１の中に、バージョン名も含んで記録してもよい。アプリケーション・パラメータ履歴Ｔ１０に、バージョン名ごとの履歴キーを追加することで、どのバージョンがパフォーマンス改善の原因であるかを特定することができる。
【実施例２】
【０１２２】
図１７，図１８を用いて第２実施例を説明する。本実施例を含む以下の各実施例は、第１実施例の変形例に該当するため、第１実施例との相違を中心に説明する。本実施例では、アプリケーションのバージョンの相違まで考慮して、パフォーマンス変動の原因を分析する。【０１２３】
例えば、アプリケーションに微小な変更が頻発し、バージョンが高い頻度で新しくなる場合には、周期性の抽出が難しくなると考えられる。バージョンの異なるアプリケーションを別のアプリケーションであると認識するため、実質的に同一とみなしてもよいアプリケーションが同一のパラメータで周期的に実行されたにもかかわらず、その事実を検知できない可能性がある。【０１２４】
具体的には、アプリケーションが１日に１回変更される場合を想定する。アプリケーション・パラメータ情報を１日に１回取得するごとにアプリケーションのバージョンが毎回変わってしまうと、アプリケーション・パラメータ情報をアプリケーション・パラメータ履歴Ｔ１０に格納する際に、同一の履歴キーに紐付けることができない。従って、第１実施例では、複数のアプリケーション・パラメータ情報間での周期性を抽出することができない。【０１２５】
そこで、本実施例では、アプリケーションバージョン管理部Ｐ１６は、アプリケーションのバージョン管理情報Ｔ１６を用い、バージョンの変更前と変更後とでアプリケーションが継承関係にあるか否かを判断する。パフォーマンス変動原因分析部Ｐ１２は、アプリケーションのバージョンが変更前と変更後とで継承関係にあるならば、同一アプリケーションの実行とみなして、アプリケーション・パラメータ情報の周期性を抽出する。【０１２６】
図１７は、アプリケーションのバージョン変更とバージョン管理情報Ｔ１６の関係を示す説明図である。【０１２７】
図１７（ａ）に示すように、アプリケーションは、そのソースコードを継続して改変するごとに、新しいバージョンとしてソースコードを保存できる。図１７には、５つのバージョン「＃１１００」「＃１１０１」「＃１１０２」「＃１１０３」「＃１１０４」が時間順に作成されたことが示されている。【０１２８】
ソースコードをバージョンと関係付けて保存する技術としては、例えば、アプリケーションのバージョン管理システム（ＶＣＳ：Version Control System）を利用できる。ＶＣＳの実装としては、ＧｉｔやＣＶＳ（Concurrent Versions System）などが挙げられる。【０１２９】
図１７（ｂ）は、バージョン管理情報Ｔ１６の構成を模式的に示す。バージョン管理情報Ｔ１６は、変更後のバージョンが変更元のバージョンから継承されるという関係の連なりを保持する。【０１３０】
具体的に図１７では、バージョン「＃１１０１」はバージョン「＃１１００」を継承している。バージョン「＃１１０２」とバージョン「＃１１０３」とは、バージョン「＃１１０１」をそれぞれ継承している。バージョン「＃１１０２」とバージョン「＃１１０３」とは相互に関係はないが、それぞれ同一のバージョン「＃１１０１」のソースコードを改変したものであることが分かる。【０１３１】
バージョン「＃１１０４」はバージョン「＃１１０３」を継承している。バージョンの継承関係が表すソースコードの変更は、ソースコード全体の大きさに比べて微小である場合、アプリケーションのほぼ同一機能が実行されたと考えてよい。従って、本実施例では、継承後のバージョン（変更後バージョン）が実行された履歴を、継承前のバージョン（変更元バージョン）が実行されたと考えて、周期性を抽出できるようにしている。【０１３２】
すなわち、図１７の例では、時系列順に「＃１１００」、「＃１１０１」、「＃１１０２」、「＃１１０３」、「＃１１０４」のバージョンを実行しているが、本実施例では、「＃１１０１」の実行時刻として抽出するのは、「＃１１０１」自身の実行時刻のみならず、「＃１１０１」を継承する「＃１１０２」、「＃１１０３」、「＃１１０４」の実行時刻も含む。このようにアプリケーションのバージョンを考慮して周期性を抽出する処理を、本実施例では、アプリケーションバージョン考慮型の周期性抽出処理と呼ぶ。【０１３３】
図１８のフローチャートを用いて、アプリケーションバージョン考慮型の周期性抽出処理を説明する。本処理は、図８で述べたステップＳ１１の後であって、かつステップＳ１２の前に、実行される。すなわち、本実施例では、図８のステップＳ１１とステップＳ１２の間に、図１８で述べるステップＳ１１０〜Ｓ１１４が追加される。【０１３４】
本実施例の周期性抽出部Ｐ１４は、アプリケーションバージョン管理部Ｐ１６からバージョン管理情報Ｔ１６を取得する（Ｓ１１０）。バージョン管理情報Ｔ１６は、図１７（ｂ）で述べたように、アプリケーションバージョンの継承関係のグラフに相当する情報を保持している。バージョン管理情報Ｔ１６を参照することで、アプリケーションのバージョン間での継承関係を把握することができる。【０１３５】
周期性抽出部Ｐ１４は、図８のステップＳ１０で取得したアプリケーション・パラメータ情報に含まれているアプリケーション名の中からバージョン名を取得し、親ブランチが存在するか判定する（Ｓ１１１）。【０１３６】
つまり、アプリケーションのバージョン名でバージョン管理情報Ｔ１６を検索することで、ステップＳ１０で取得したアプリケーション名が、他のバージョンのアプリケーションからブランチしたものであるか判定する（Ｓ１１１）。【０１３７】
次に、周期性抽出部Ｐ１４は、親ブランチのアプリケーションについて、アプリケーション・パラメータ履歴Ｔ１１を検索し（Ｓ１１２）、親ブランチに周期性があるか判定する（Ｓ１１３）。【０１３８】
図１７（ｂ）の例で説明すると、バージョン「＃１１０２」のブランチ元は、バージョン「＃１１０１」と「＃１１００」の２つである。そこで、周期性抽出部Ｐ１４は、アプリケーション・パラメータ履歴Ｔ１１にブランチ元「＃１１０１」「＃１１００」に相当する履歴キーが存在するか検索し、ブランチ元のアプリケーションが存在する場合は該当する行を全て抽出する。周期性抽出部Ｐ１４は、抽出した行の周期性フラグＣ１０４に「あり」が設定されているか確認する。【０１３９】
周期性抽出部Ｐ１４は、親ブランチのバージョンのアプリケーションに周期性がないと判定すると（Ｓ１１３：ＮＯ）、本処理を終了し、図８のステップＳ１２へ移る。周期性抽出部Ｐ１４は、親ブランチのバージョンのアプリケーションに周期性があると判定すると（Ｓ１１３：ＹＥＳ）、ブランチ元のバージョンのアプリケーションに対して、実行時刻Ｃ１０６を追加する（Ｓ１１４）。これにより、ブランチ元（親ブランチ）のバージョンのアプリケーションには、ブランチ先（子ブランチ）のバージョンのアプリケーションの実行も追加されるため、ブランチ元のバージョンのアプリケーションの周期性有無や実行頻度を第１実施例よりも正確に検出することができる。【０１４０】
このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、バージョンの継承を考慮して、アプリケーション・パラメータ情報に周期性があるか判定できる。このため、本実施例は、バージョン変更の頻度の大きいアプリケーションを用いるシステムに適用する場合でも、高い信頼性をもってパフォーマンスの変動原因を分析することができる。
【実施例３】
【０１４１】
図１９を用いて第３実施例を説明する。本実施例では、寄与度計算に影響するリードタイムの値が、本発明の適用先システムの業種および拠点によって異なる場合でも、対応できるようにした。これにより本実施例では、多様な業種の業務プロセスや、複数の拠点にまたがる業務プロセスに対して、業務パフォーマンスの変動原因を分析できる。【０１４２】
図１９は、複数の拠点ＳＡ，ＳＢ，ＳＣをまたがって製品を製造する製造システムの全体図である。各地に分散配置された各拠点ＳＡ〜ＳＣは、それぞれ基本的に図２で述べた構成１１０〜１４０と同一の構成を備える。図２で使用した符号に各拠点を区別するアルファベットを添えて、表示する。ここでは、業務プロセスを製造プロセスと呼ぶ。【０１４３】
拠点ＳＡの製造プロセス５Ａは、製品（仕掛品）７Ａを製造する。製品７Ａは、拠点ＳＢへ輸送される。拠点ＳＢの製造プロセス５Ｂは、製品７Ａに追加加工して製品７Ｂを製造する。製品７Ｂは、拠点ＳＣへ輸送される。拠点ＳＣの製造プロセス５Ｃは、製品７Ｂに仕上げ加工し、完成品７Ｃを製造する。製品７Ｃは、顧客に向けて発送される。【０１４４】
製品の受け渡しに際して、その製品に関する管理情報も拠点間で受け渡される。即ち、拠点ＳＡから拠点ＳＢへ製品７Ａを渡す場合、製品７Ａに関する管理情報ＴＡも、拠点ＳＡの原因分析計算機１１０Ａから拠点ＳＢの原因分析計算機１１０Ｂへ渡される。拠点ＳＢから拠点ＳＣへ製品７Ｂを渡す場合、製品７Ｂに関する管理情報ＴＢも、拠点ＳＢの原因分析計算機１１０Ｂから拠点ＳＣの原因分析計算機１１０Ｃへ渡される。【０１４５】
拠点間を結ぶ通信ネットワークを用いて管理情報を受け渡してもよいし、フラッシュメモリデバイス等の記録媒体に管理情報を格納して受け渡してもよい。その記録媒体は、製品と別に輸送されてもよいし、製品の内部または表面に設けられてもよい。【０１４６】
製品の製造プロセスが複数の拠点にまたがる場合、パフォーマンスの変動に影響のあるアプリケーション・パラメータを分析するのは難しい。拠点ごとにアプリケーションの種類やパラメータが変更され、リードタイムも拠点毎に異なるためである。拠点の特性（その拠点での製造内容やその拠点の環境等）や、拠点間の移動に要する時間、移動方法等により、アプリケーション・パラメータ情報がパフォーマンスに影響を与えるまでの時間が異なる。【０１４７】
一方、拠点が一つの場合でも、業種が異なればリードタイムも異なる。例えば電子機器を組立製造する場合と、化学薬品を製造する場合とでは、リードタイムが相違する。電子部品の実装作業と化学薬品の混合作業との相違のように、それぞれのプロセスの性質が異なるためである。【０１４８】
なお、拠点ＳＡから拠点ＳＢへ、拠点ＳＢから拠点ＳＣへと製品を直列的に輸送して完成させる場合を述べたが、拠点ＳＡで製造した部品と拠点ＳＢで製造した部品とを拠点ＳＣにそれぞれ輸送し、拠点ＳＣで最終組立を行う場合も、本実施例を適用できる。【０１４９】
そこで、本実施例では、業種別、かつ拠点別のリードタイムを管理する業種別拠点別リードタイム情報Ｔ１７を用意する。そして、本実施例では、業種別、拠点別のリードタイムを用いて、アプリケーション・パラメータ情報がパフォーマンスの変動に影響する寄与度を計算する。【０１５０】
図２０は、業種別拠点別リードタイム情報Ｔ１７を示す。このリードタイム情報Ｔ１７は、例えば、ＫＰＩ名Ｃ１７０、業種Ｃ１７１、品目Ｃ１７２、拠点Ｃ１７３、リードタイムＣ１７４を対応付けて保持する。このリードタイム情報Ｔ１７を参照することで、ＫＰＩ名、業種名、品目名および拠点名といった環境情報に対応するリードタイムを取得して、寄与度を計算することができる。【０１５１】
製造業の場合、製造品目ごとに個別にリードタイムを格納できる。例えば、製造品目が電子機器の組立製造である場合のリードタイムには、例えば、在庫滞留時間を含む組み立てラインの総時間を設定できる。製造品目が化学薬品である場合のリードタイムは、例えば、薬品醸成期間と保存期間との加算時間を設定することができる。【０１５２】
業種別拠点別リードタイム情報Ｔ１７は、アプリケーション・パラメータ変更が実行される拠点Ｃ１７３ごとにリードタイムＣ１７４を保持できる。例えば、電子製品を構成する複数種類の部品のそれぞれが異なる拠点で製造される場合、それぞれの拠点のリードタイムとして、その拠点で滞留する時間と、その拠点から最終組立工程拠点までの部品搬送に要する期間とを設定できる。【０１５３】
本実施例は、アプリケーション・パラメータ履歴Ｔ１０に記載されたアプリケーション・パラメータ情報の中から原因候補のアプリケーション・パラメータ情報を抽出する処理の中に、本実施例のための追加処理を含めることで実現する。【０１５４】
追加処理とは、具体的には、
（追加処理１）ステップＳ２０で、業種と拠点を識別する情報を取得する処理と、
（追加処理２）ステップＳ２６で、業種別拠点別リードタイム情報Ｔ１７からリードタイムを取得するリードタイム取得処理である。【０１５５】
追加処理１のために、パフォーマンス監視部Ｐ２０は、パフォーマンス情報に業種情報、品目情報、拠点情報を付加して、パフォーマンス取得部Ｐ１０へ送信する。同様に、アプリケーション・パラメータ監視部Ｐ３１も、アプリケーション・パラメータ情報に業種情報、品目情報、拠点情報を付加して、アプリケーション・パラメータ取得部Ｐ１１へ送信する。【０１５６】
業種情報、品目情報、拠点情報の付加されたパフォーマンス情報は、パフォーマンス履歴Ｔ１１へ格納される。業種情報、品目情報、拠点情報の付加されたアプリケーション・パラメータ情報は、アプリケーション・パラメータ履歴Ｔ１０へ格納される。付加された業種情報、品目情報、拠点情報は、後の追加処理２で利用することができる。これに代えて、業種情報、品目情報、および拠点情報は、アプリケーション・パラメータ履歴Ｔ１０の環境情報Ｃ１０７の中に含めてもよい。【０１５７】
追加処理２では、追加処理１で取得した業種情報、品目情報および拠点情報とともにＫＰＩ名を照合することで、業種別拠点別リードタイム情報Ｔ１７からリードタイム値を取得する。【０１５８】
このように構成される本実施例も第１実施例と同様の作用効果を奏する。さらに本実施例では、業種別にリードタイムを設定するため、異なる業種についてパフォーマンスの変動原因となったアプリケーション・パラメータ情報を分析することができ、使い勝手が向上する。【０１５９】
さらに、本実施例では、複数拠点に業務プロセスが分散する場合でも、拠点別にリードタイムを設定するため、最終拠点でのパフォーマンス変動の原因となったアプリケーション・パラメータ情報を分析することができる。本実施例は、第１実施例または第２実施例のいずれとも結合させることができる。【０１６０】
なお、本発明は、上述した実施形態に限定されない。当業者であれば、本発明の範囲内で、種々の追加や変更等を行うことができる。実施形態で述べた技術的特徴は、特許請求の範囲に明示した組合せ以外に組み合わせることができる。【０１６１】
本実施例では、製造プロセスに適用する場合を例に挙げたが、これに限らず、例えば電子商取引プロセス、広告配信プロセスなどの他の業務プロセスにも適用できる。
【符号の説明】
【０１６２】
１：原因分析部、２：パフォーマンス監視部、３：アプリケーション監視部、４：端末、５：業務プロセス、６：アプリケーション・パラメータ情報（アプリケーション設定情報）、１１：パフォーマンス情報取得部、１２：アプリケーション設定情報取得部、１３：パフォーマンス変動原因分析部、１４：寄与度計算部、１６：原因リスト提供部、１０：原因分析計算機、１２０：パフォーマンス監視計算機、１３０：業務計算機、１４０：端末
【図１】
2017199319.tif 000003
【図２】
2017199319.tif 000004
【図３】
2017199319.tif 000005
【図４】
2017199319.tif 000006
【図５】
2017199319.tif 000007
【図６】
2017199319.tif 000008
【図７】
2017199319.tif 000009
【図８】
2017199319.tif 000010
【図９】
2017199319.tif 000011
【図１０】
2017199319.tif 000012
【図１１】
2017199319.tif 000013
【図１２】
2017199319.tif 000014
【図１３】
2017199319.tif 000015
【図１４】
2017199319.tif 000016
【図１５】
2017199319.tif 000017
【図１６】
2017199319.tif 000018
【図１７】
2017199319.tif 000019
【図１８】
2017199319.tif 000020
【図１９】
2017199319.tif 000021
【図２０】
2017199319.tif 000022
【国際調査報告】
2017199319.tif 000023
2017199319.tif 000024