特許 5932887 業務処理システム、業務処理能力の監視システムおよび監視方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5932887

(24)【登録日】2016年5月13日

(45)【発行日】2016年6月8日

(54)【発明の名称】業務処理システム、業務処理能力の監視システムおよび監視方法

(51)【国際特許分類】

   G06F 11/34 20060101AFI20160526BHJP

【ＦＩ】

   G06F11/34 S

【請求項の数】7

【全頁数】12

(21)【出願番号】特願2014-108406(P2014-108406)

(22)【出願日】2014年5月26日

(65)【公開番号】特開2015-225399(P2015-225399A)

(43)【公開日】2015年12月14日

【審査請求日】2014年5月26日

(73)【特許権者】

【識別番号】501440684

【氏名又は名称】ソフトバンク株式会社

(74)【代理人】

【識別番号】100079108

【弁理士】

【氏名又は名称】稲葉 良幸

(74)【代理人】

【識別番号】100109346

【弁理士】

【氏名又は名称】大貫 敏史

(74)【代理人】

【識別番号】100117189

【弁理士】

【氏名又は名称】江口 昭彦

(74)【代理人】

【識別番号】100134120

【弁理士】

【氏名又は名称】内藤 和彦

(72)【発明者】

【氏名】戸次 啓介

(72)【発明者】

【氏名】遠藤 正貴

(72)【発明者】

【氏名】佐藤 浩樹

(72)【発明者】

【氏名】依田 卓也

【審査官】 多賀 実

(56)【参考文献】

【文献】 特開２００７−１４８４６９（ＪＰ，Ａ）

【文献】 特開２００２−３５１８５２（ＪＰ，Ａ）

【文献】 国際公開第２０１１／１０５００１（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ ９／４６− ９／５４

Ｇ０６Ｆ１１／２８−１１／３６

(57)【特許請求の範囲】

【請求項1】

複数の部門が機能の異なる複数の業務システムを相互利用して顧客サービスを行う場合の業務処理能力を監視する監視システムであって、
各業務システムの現状のリソースを測定するリソース測定部と、
特定の業務システムについて投入すべき業務量を受け付ける受付部と、
前記特定の業務システムへ前記業務量が投入されたことに伴って業務量が増加することになる関連する１以上の業務システムにおける業務量を予測し、前記特定の業務システムへ前記業務量を投入した場合の各業務システムにおける業務量を累積して予測業務量を計算する自動計算部と、
前記リソース測定部により測定された現状のリソース測定値と前記予測業務量とに基づいて、現状業務量との比率により想定されるリソース使用量を見積計算するリソース見積計算部と、
前記リソース見積計算部によるリソース見積計算の結果が閾値を超えるか否かを判定する判定部と、
を有し、
前記判定部は、前記リソース見積計算部によるリソース見積計算の結果が閾値を超える場合は、警告表示することを特徴とする業務処理能力の監視システム。

【請求項2】

前記リソース見積計算部によるリソース見積計算の結果を加工した画像を生成する加工画像生成部をさらに有し、
前記リソース見積計算部は、異なる時間に前記リソース使用量を見積計算して複数の前記リソース使用量を取得し、
前記加工画像生成部は、過去に見積計算された前記リソース使用量と今回見積計算された前記リソース使用量とを比較して、その比較結果、および、当該比較に基づきシステム劣化が発生しているか否かを示す判定結果を示す画像を生成することを特徴とする請求項１に記載の業務処理能力の監視システム。

【請求項3】

前記加工表示部は、前記判定部による判定結果をグラフ化または表化した画像を生成することを特徴とする請求項２に記載の業務処理能力の監視システム。

【請求項4】

複数の部門が機能の異なる複数の業務システムを相互利用して顧客サービスを行う業務処理システムであって、
機能の異なる複数の業務システムと、
前記業務システムからアクセスログを取得するログ収集サーバと、
前記ログ収集サーバが取得したログをビッグデータに集約する集約サーバと、
前記集約サーバから取得したログを集計分析する集計分析サーバと、
前記業務システムに接続され、前記集計分析サーバの集計分析結果を画像表示する画像表示部と、を備え、
前記集計分析サーバは、請求項１乃至３のいずれか１項に記載の監視システムとして機能することを特徴とする業務処理システム。

【請求項5】

複数の部門が機能の異なる複数の業務システムを相互利用して顧客サービスを行う場合の業務処理能力を監視する監視方法であって、
各業務システムの現状のリソースを測定する手順と、
特定の業務システムについて投入すべき業務量を受け付ける手順と、
前記特定の業務システムへ前記業務量が投入されたことに伴って業務量が増加することになる関連する１以上の業務システムにおける業務量を予測し、前記特定の業務システムへ前記業務量を投入した場合の各業務システムにおける業務量を累積して予測業務量を計算する手順と、
前記リソースを測定する手順により測定された現状のリソース測定値と前記予測業務量とに基づいて、現状業務量との比率により想定されるリソース使用量を見積計算する手順と、
前記リソース見積計算の結果が予め設定した閾値を超えるか否かを判定する手順と、
を有し、
前記リソース見積計算の結果を判定する手順は、リソース見積計算の結果が閾値を超える場合は、警告表示することを特徴とする業務処理能力の監視方法。

【請求項6】

前記リソース見積計算の結果を加工した画像を生成する手順をさらに有し、
前記リソース使用量を見積計算する手順は、異なる時間に前記リソース使用量を見積計算して複数の前記リソース使用量を取得し、
前記加工した画像を生成する手順は、過去に見積計算された前記リソース使用量と今回見積計算された前記リソース使用量とを比較して、その比較結果、および、当該比較に基づきシステム劣化が発生しているか否かを示す判定結果を表示することを特徴とする請求項５に記載の業務処理能力の監視方法。

【請求項7】

前記加工した画像を生成する手順は、リソース見積計算の判定結果をグラフ化または表化した画像を生成することを特徴とする請求項６に記載の業務処理能力の監視方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、複数の部門が複数の機能の異なるサーバシステムを相互利用して顧客サービスを行う当該業務処理システムに関し、特に、業務量に対する処理能力を監視する為の監視方法および機能に関するものである。

【背景技術】

【0002】

携帯電話会社の顧客サービスは、ショップ（店舗）、オンライン（Ｗｅｂショップ）、ＦＡＸ、および法人依頼の各部門が対応している。すなわち、各部門に対応するように、ショップシステム、オンラインシステム、ＦＡＸシステム、法人システムおよび顧客システムのフロントシステムが構築される。各フロントシステムは、毎月、携帯電話の新規契約や機種変更などに対応するための顧客サービスを受け付けている。

【0003】

各フロントシステムから投入された業務の処理には、ポイントシステムや割賦債権システム等の関連する他の基幹系システムが必要となる。したがって、各フロントシステムの業務処理には、必要となる他のシステムが関連付けられている。

【0004】

業務処理に際して、現在のリソースで処理可能か、業務量が処理能力を超えてオーバーフローしないかを見積もる必要がある。しかし、従来、複数のシステムの業務量を統括的に監視するシステムはなかった。そのため、各フロントシステムでは、当該フロントシステムの業務量に基づいて、処理能力のオーバーフローの有無を判定していた。

【0005】

業務処理能力の監視システムに関連する技術としては、例えば、業務処理システムで処理すべき追加業務要件を受け付けて、この業務要件を処理した際に、性能を予測するシステムが開示されている（特許文献１参照）。

【先行技術文献】

【特許文献】

【0006】

【特許文献1】特許公開２００８−１２９８７８号公報

【発明の概要】

【発明が解決しようとする課題】

【0007】

従来の携帯電話会社における業務処理システムでは、現在のリソース状況を計測したり、単独システムにおける処理能力のシミュレーションをしたりすることが行われてきた。しかし、実際には、単独で完結しているシステムは数少なく、色々なシステムと関連付けられて影響を及ぼしあいながらシステムが構築されている。

【0008】

したがって、複数のフロントシステムに異なる業務が投入された場合は、関連付けの多いシステムにおいて、複数の業務量が重なることになる。複数の業務量が重なる結果、フロントシステムにおいて処理可能と判定された業務量であっても、処理能力がオーバーフローすることがあった。多くのフロントシステムから利用される下位のシステムほど、業務量の累積は大きく、リソースのキャパシティを超える虞があった。

【0009】

特許文献１の性能予測システムは、業務要件に対して、各サーバ群で必要とされる処理性能を定量的に予測する。しかし、複数の部門が機能の異なる複数のサーバシステムを相互利用して顧客サービスを行う場合には、特許文献１の性能予測システムを用いて、累積する業務量に対する処理能力を予測することは困難であった。

【0010】

本発明は、上記の事情に鑑みて創案されたものであり、複数の部門が機能の異なる複数のシステムを相互利用して顧客サービスを行う業務処理システム、当該業務処理システムにおいて、複数のシステムの業務処理能力に基づいてシミュレーションを行って適正な業務量を分配することができる監視システムおよび監視方法の提供を目的の一つとする。

【課題を解決するための手段】

【0011】

上記目的を達成するために、本発明に係る業務処理能力の監視システムは、複数の部門が機能の異なる複数の業務システムを相互利用して顧客サービスを行う場合の業務処理能力を監視する監視システムであって、各業務システムの現状のリソースを測定するリソース測定部と、特定の業務システムについて投入すべき業務量を受け付ける受付部と、上記特定の業務システムへ前記業務量が投入されたことに伴って業務量が増加することになる関連する１以上の業務システムにおける業務量を予測し、上記特定の業務システムへ前記業務量を投入した場合の各業務システムにおける業務量を累積して予測業務量を計算する自動計算部と、上記リソース測定部により測定された現状のリソース測定値と上記予測業務量とに基づいて、現状業務量との比率により想定されるリソース使用量を見積計算するリソース見積計算部と、上記リソース見積計算部によるリソース見積計算の結果が閾値を超えるか否かを判定する判定部と、を有し、上記判定部は、前記リソース見積計算部によるリソース見積計算の結果が閾値を超える場合は、警告表示することを特徴とする。
また、上記業務処理能力の監視システムにおいて、上記リソース見積計算部によるリソース見積計算の結果を加工した画像を生成する加工画像生成部をさらに有し、上記リソース見積計算部は、異なる時間に前記リソース使用量を見積計算して複数の前記リソース使用量を取得し、上記加工画像生成部は、過去に見積計算された上記リソース使用量と今回見積計算された上記リソース使用量とを比較して、その比較結果、および、当該比較に基づきシステム劣化が発生しているか否かを示す判定結果を示す画像を生成することが好ましい。

【0012】

上記業務処理能力の監視システムにおいて、上記加工画像生成部は、上記判定部による判定結果をグラフ化または表化した画像を生成することが好ましい。

【0013】

また、本発明に係る業務処理システムは、複数の部門が機能の異なる複数の業務システムを相互利用して顧客サービスを行う業務処理システムであって、機能の異なる複数の業務システムと、上記業務システムからアクセスログを取得するログ収集サーバと、上記ログ収集サーバが取得したログをビッグデータに集約する集約サーバと、上記集約サーバから取得したログを集計分析する集計分析サーバと、上記業務システムに接続され、前記集計分析サーバの集計分析結果を画像表示する画像表示部とを備え、上記集計分析サーバは、上記のいずれかの監視システムとして機能することを特徴とする。

【0014】

さらに、本発明に係る業務処理能力の監視方法は、複数の部門が機能の異なる複数の業務システムを相互利用して顧客サービスを行う場合の業務処理能力を監視する監視方法であって、各業務システムの現状のリソースを測定する手順と、特定の業務システムについて投入すべき業務量を受け付ける手順と、上記特定の業務システムへ前記業務量が投入されたことに伴って業務量が増加することになる関連する１以上の業務システムにおける業務量を予測し、上記特定の業務システムへ前記業務量を投入した場合の各業務システムにおける業務量を累積して予測業務量を計算する手順と、上記リソースを測定する手順により測定された現状のリソース測定値と上記予測業務量とに基づいて、現状業務量との比率により想定されるリソース使用量を見積計算する手順と、上記リソース見積計算の結果が予め設定した閾値を超えるか否かを判定する手順と、を有し、上記リソース見積計算の結果を判定する手順は、リソース見積計算の結果が閾値を超える場合は、警告表示することを特徴とする。
また、上記業務処理能力の監視方法において、上記リソース見積計算の結果を加工した画像を生成する手順をさらに有し、上記リソース使用量を見積計算する手順は、異なる時間に前記リソース使用量を見積計算して複数の前記リソース使用量を取得し、上記加工した画像を生成する手順は、過去に見積計算された上記リソース使用量と今回見積計算された上記リソース使用量とを比較して、その比較結果、および、当該比較に基づきシステム劣化が発生しているか否かを示す判定結果を示す画像を生成することが好ましい。

【0015】

上記業務処理能力の監視方法において、上記加工した画像を生成する手順は、リソース見積計算の判定結果をグラフ化または表化した画像を生成することが好ましい。

【発明の効果】

【0016】

本発明によれば、現状のリソース測定値と自動計算した予測業務量とに基づいて、現状業務量との比率により想定されるリソース使用量を見積計算し、リソース見積計算の結果が閾値を超えるか否かを判定し、当該リソース見積計算の結果が閾値を超える場合は、警告表示するので、複数の業務システムの業務処理能力に基づいてシミュレーションを行って適正な業務量を分配することができる。

【図面の簡単な説明】

【0017】

【図1】本実施形態に係る業務処理システムの全体構成図である。

【図2】本実施形態に係る業務処理能力の監視システムの構成図である。

【図3】本実施形態に係る業務処理能力の監視方法のフローチャートである。

【図4】本実施形態における業務量計算の説明に供する図である。

【図5】本実施形態における分析結果のグラフ化した表示の説明に供する図である。

【図6】本実施形態における分析結果の表化した表示の説明に供する図である。

【図7】本実施形態における処理能力の判定の説明に供する図である。

【発明を実施するための形態】

【0018】

以下に本発明の実施の形態を説明する。以下の図面の記載において、同一又は類似の部分には同一又は類似の符号で表している。但し、図面は模式的なものである。したがって、具体的な寸法等は以下の説明を照らし合わせて判断するべきものである。また、図面相互間においても互いの寸法の関係や比率が異なる部分が含まれていることは勿論である。
〔業務処理システムおよび監視システムの構成〕

【0019】

まず、図１および図２を参照して、本実施形態に係る業務処理システム１、および業務処理能力の監視システム１００の構成について説明する。図１は本実施形態に係る業務処理システムの全体構成図である。

【0020】

図１に示すように、本実施形態に係る業務処理能力の監視システム１００は、複数の部門が機能の異なる複数のサーバシステムを相互利用して顧客サービスを行う業務処理システム１の監視ツールとして構築される。

【0021】

当該業務処理システム１は、複数の業務システム（１１〜１８）、ログ収集サーバ２０、集約サーバ３０、監視システム（集計分析サーバ）１００、および画像表示部４０を備える。

【0022】

業務システムには、フロントシステム、および当該フロントシステムと関連付けられた基幹系システムがある。フロントシステムとしては、例えば、ショップシステム１１、オンラインシステム１２、ＦＡＸシステム１３、法人システム１４および顧客システム１７が挙げられる。基幹系システムとしては、例えば、ポイントシステム１５、割賦債権システム１６および交換機投入システム１８が挙げられる。フロントシステムおよび基幹系システムは、インフラの変化や社会情勢等に応じて適宜設定され、例示の業務システムに限定されない。

【0023】

ログ収集サーバ２０は、各業務システム１１〜１８からのアクセスログを取得し、集約サーバ３０が保存するビッグデータへ渡す機能を有する。ログ収集サーバ２０が取得するログには、業務量等の入力情報や、メモリ、セッション数、スレッド等の現行の監視項目が含まれている。

【0024】

集約サーバ３０は、ログ収集サーバ２０から取得したログをビッグデータに集約する機能を有する。また、集約サーバ３０は、取得したログを集計分析サーバ１００へ受け渡す機能を有する。

【0025】

監視システム１００は、集約サーバ３０が取得したログを集計分析する集計分析サーバとして機能する。監視システム（集計分析サーバ）１００は、業務量計算、出力情報およびリソース計算を行う。業務量計算は、入力情報（業務量）から出力情報を計算する。出力情報は、他の業務システムへの入力情報となる。リソース計算は、業務量の変化に対するリソースを求める。また、監視システム１００は、集計分析結果を画像表示用に加工し、フロントシステムの画像表示部４０に表示する。

【0026】

次に、図２を参照して、本実施形態に係る業務処理能力の監視システム１００について更に詳しく説明する。図２は本実施形態に係る業務処理能力の監視システムの構成図である。

【0027】

図２に示すように、監視システム１００は、リソース測定部１１０、自動計算部１２０、リソース見積計算部１３０、判定部１４０および加工表示部１５０の構成要素からなる。

【0028】

リソース測定部１１０は、各業務システムのリソースを測定する要素である（図１参照）。リソースの測定は、ＣＰＵの使用率、メモリ消費量、セュション数およびスレッドに基づいて行う。

【0029】

自動計算部１２０は、フロントシステムに試したい業務量を入力した場合に、関連付けされた業務システムの業務量を自動的に累積して計算する要素である。自動計算部１２０には、自動計算を行うための計算式が設定される。特に自動計算部１２０は、フロントシステムに複数の業務が投入された場合、それに関連付けて各業務システムで発生することになる業務の業務量を全て積算し、各業務システムで発生しうる合計された予測業務量を出力するようになっている。

【0030】

リソース見積計算部１３０は、リソース測定部１１０により測定された現状のリソース測定値と、自動計算部１２０により自動計算された予測業務量に基づいて、現状業務量との比率により想定されるリソース使用量を見積計算する要素である。

【0031】

判定部１４０は、リソース見積計算の結果を閾値と比較して、当該見積計算の結果が閾値を超えるか否かを判定する要素である。閾値は、リソースのキャパシティ等に基づいて、予め設定される。

【0032】

加工表示部１５０は、リソース見積計算部１３０によって求められたリソース見積計算結果をグラフ化もしくは表化して、画像表示部４０に表示する要素である。図１および図２を参照して、画像表示部４０は、各フロントシステムに備えられている。画像表示部４０としては、例えば、液晶表示装置やＬＥＤ表示装置、ＣＲＴ等の画像表示装置が挙げられる。画像表示部４０には、本実施形態に係る監視システム１００によるリソース見積計算の結果がグラフ化もしくは表化されて画像表示される。また、画像表示部４０に表示されたグラフもしくは表には、リソース見積計算の結果が閾値を超えた場合の警告が表示される。すなわち、画像表示部４０において、リソースの予測値を監視することになる。
〔業務処理システムおよび監視システムの作用〕

【0033】

次に、図１から図６を参照して、本実施形態に係る業務処理システム１および業務処理能力の監視システム１００の作用とともに、本実施形態に係る業務処理能力の監視方法について説明する。

【0034】

図１に示すように、本実施形態に係る業務処理システム１において、ログ収集サーバ２０は、各業務システム１１〜１８からのアクセスログを取得し、集約サーバ３０が保存するビッグデータへ渡す。集約サーバ３０は、ログ収集サーバ２０から取得したログをビッグデータに集約する。集約サーバ３０は、取得したログを集計分析サーバ１００へ受け渡す。

【0035】

集計分析サーバとしての監視システム１００は、本実施形態に係る業務処理能力の監視方法により、集約サーバ３０が取得したログを集計分析する。本実施形態に係る業務処理能力の監視方法は、各業務システムの現状のリソースを測定する手順、各業務システムの業務量を自動で計算する手順、想定されるリソース使用量を見積計算する手順、リソース見積計算の結果が閾値を超えるか否かを判定する手順、およびリソース見積計算の結果をグラフ化して表示する手順を有する。

【0036】

図３は本実施形態に係る業務処理能力の監視方法のフローチャートである。図２および図３に示すように、本実施形態に係る業務処理能力の監視方法は、まず、監視システム（集計分析サーバ）１００が、集約サーバ１１０からフロントシステムのログを取得する（ステップ１；以下、「Ｓ１」のように表示する）。

【0037】

監視システム１００のリソース測定部１１０は、フロントシステムのログを取得すると、関連付けされた個々の業務システムの現状の業務量に対するリソースを測定する（Ｓ２）。リソースの測定は、ＣＰＵの使用率、メモリ消費量、セュション数およびスレッドに基づいて行う。

【0038】

次に、上位のフロントシステムの業務量を予測したい数値に置き換えると、監視システム１００の自動計算部１２０は、関連付けられた下位のシステムの業務量を自動計算する（Ｓ３）。図２に示すように、例えば、ショップシステムに予測したい業務量（新規：３万件、機種変更：２万件）が入力されると、関連付けられた下位のＦＡＸシステムの業務量（９万件）、ｎシステム（７万件）を順次自動計算する。

【0039】

図４は本実施形態における業務量計算の説明に供する図である。図４に示すように、例えば、ショップシステム１１に投入される業務１については、ショップシステム１１をフロントシステムとして、ＦＡＸシステム１３、ポイントシステム１５、割賦情報システム１６、顧客システム１７、交換機投入システム１８が関連付けられ、稼働対象となる。すなわち、ショップシステム１１で受け付けた業務１は、関連付けられた他の業務システム１３，１５，１６，１７、１８でも業務が発生し、それぞれに処理しなければならない。

【0040】

図４において、複数のフロントシステムに異なる業務が投入された場合は、それぞれの異なる業務がそれぞれ下位のシステムにおいても業務を発生させることになる。このため、関連付けがより多くなる下位のシステムになればなるほど、異なる業務において発生する複数の業務量が重なることになる。例えば、図４では、業務フローの下流に位置する交換機投入システム１８においては、業務１、業務２、業務３、業務４、および業務５のそれぞれのために発生する業務量が累積されることになる。

【0041】

例えば、ショップシステム１１への投入量が７万人の場合、過去の実績に基づいて、どのシステムにどの程度の負荷を投入するか（７万人のうちの何割を投入するか）を決定する。決定した投入量は、関連付けされたＦＡＸシステム１３、ポイントシステム１５、割賦債権システム１６、顧客システム１７、および交換機投入システム１８にも割り当てられる。

【0042】

次に、監視システム１００のリソース見積計算部１３０は、リソース測定部１１０により測定された各業務システムの現状のリソース測定値と、自動計算部１２０により自動計算された予測業務量に基づいて、現状業務量との比率により想定されるリソース使用量を見積計算する（Ｓ４）。具体的に自動計算部１２０は、業務システムごとに、投入された複数の業務に対応して発生する業務量を積算する。図４の例では、例えば交換機投入システム１８について、業務１〜業務５までのそれぞれで発生する業務量を合計する。そしてリソース見積計算部１３０は、業務システムごとに測定されたリソース測定値に基づいて、予測業務量を投入することにより想定されるリソース使用量を見積もる。図４の例では、例えば交換機投入システム１８について測定されたリソース測定値に基づいて、業務１〜業務５の累積業務量によって、交換機投入システム１８のリソースがどの程度使用されるのかを見積もる。

【0043】

そして、監視システム１００の判定部１４０は、リソース見積計算部１３０により求められたリソース見積計算の結果が予め設定した閾値を超えるか否かを判定する（Ｓ５）。リソース見積計算結果が閾値を超えた場合は（Ｓ５／ＹＥＳ）、警告する（Ｓ６）。リソース見積計算結果が閾値以下である場合は（Ｓ５／ＮＯ）、現状のリソースで処理能力を有する旨を表示する（Ｓ７）。図４の例では、例えば交換機投入システム１８について見積もられたリソース使用量が当該システムについて設定されていた閾値を超えた場合には、業務量がオーバーフローする可能性があるものと判断して、その旨の警告を発生することになる。

【0044】

監視システム１００の加工表示部１５０は、リソース見積計算結果をグラフ化もしくは表化して画像表示部４０に表示する（Ｓ８）。画像表示部４０のグラフもしくは表には、警告もしくは処理能力を有する旨が表示される。

【0045】

図２および図５を参照して、加工表示部１５０による分析結果のグラフ化した表示例について説明する。図５は本実施形態における分析結果のグラフ化した表示の説明に供する図である。

【0046】

図２に示すように、画像表示部４０への判定結果の表示例として、「○，×，△」等の記号で表示したり、円グラフ、棒グラフ、もしくは折れ線グラフ等のように、グラフ化して表示することが挙げられる。グラフ化表示する際、例えば、図５に示すように、処理能力の最大値（８０〜９０％）を閾値として表示し、シミュレーションした業務量を棒グラフ等で表示することが考えられる。

【0047】

図６を参照して、加工表示部１５０による分析結果の表化した表示例について説明する。図６は本実施形態における分析結果の表化した表示の説明に供する図である。

【0048】

図６に示すように、画像表示部４０への判定結果の表示例として、リソース見積計算の判定結果を表化して表示することが挙げられる。図６の表において、第１列は業務システムのシステム名である。第２列のシミュレーション（目標値）は、閾値（目標値）に対する余裕度である。第３列のシミュレーション（前回比較）は、前回シミュレーションから変動が小さいか大きいかの変動に対する余裕度である。第４列は、シミュレーション（限界値）である。第５列の比較結果は、過去の業務量との比較から、システム劣化が発生しているか否かの判定である。具体的に、過去のシミュレーションと比較して、投入業務量に応じてＣＰＵ負荷量が変化しているかを判定する。図６の表の各欄において、白丸はＯＫ、ハイフンはシミュレーション対象外、怪しい場合は斜線丸、閾値を超えている場合は格子丸で表している。

【0049】

図７を参照して、図６の表における判定手法について説明する。図７は本実施形態における処理能力の判定の説明に供する図である。
図５に示すように、ある業務システムにおいて、４月の業務量が１００件で、ＣＰＵの使用率は１０％であった。また、５月の業務量が２００件で、ＣＰＵの使用率は２０％であった。これらに対して、７月の業務量は３００件で、ＣＰＵの使用率は１５％である。過去の実績に基づくと、業務量は３００件であるから、本来、ＣＰＵ使用率は３０％になるはずである。図７の７月のリソース使用量の場合は、パフォーマンスの性能に大きな変化があると判断して、斜線丸を表示する。

【0050】

すなわち、本実施形態に係る業務処理能力の監視システム１００は、リソース測定部１１０が測定した現状のリソース測定値と、自動計算部１２０が自動計算した予測業務量に基づいて、リソース見積計算部１３０が現状業務量との比率により想定されるリソース使用量を見積計算する。判定部１４０は、リソース見積計算部１３０によるリソース見積計算の結果が閾値を超えるか否かを判定し、当該リソース見積計算の結果が閾値を超える場合は、警告表示する。したがって、本実施形態に係る業務処理能力の監視システム１００によれば、複数の業務システムの業務量を統括的に監視することができる。

【0051】

商用環境では、リリース後にバースト試験や過負荷試験などを実施することは難しい。しかし、本実施形態に係る業務処理能力の監視システム１００では、大よその業務量限界値を見積もることができる。

【0052】

また、前回のシミュレーション結果と今回のシミュレーション結果との比較により、アプリケーション・リソース（ＣＰＵやメモリ等のリソース）によるパフォーマンス劣化を検知することができる。例えば、リソース食いのアプリケーションが経時的に増えると、パフォーマンスが劣化する。逆に、アプリケーション負荷が減ったり、システム構成の改善により処理能力が上がったら、パフォーマンスが向上する場合もある。

【0053】

さらに、ハードウェア構成の変更などによってリソース変更の可能性がある場合は、システム的に検知して確認を促すことができる。例えば、サーバを増設したにもかかわらず、ハードウェア構成の変更を反映させていない場合がある。ハードウェア構成の変更により処理能力が低下すると、前回のハードウェア構成変更前のシミュレーション結果とハードウェア構成変更後のシミュレーション結果とに基づいて、比較した値が所定値以上乖離しているとハードウェア構成について確認を促す仕組みを実装している。

【0054】

パフォーマンスが変化したりハードウェア構成が変更された場合に実測値が変わるので、シミュレーションの計算式も動的に変わることになる。シミュレーションの計算式によって見極めた予測値と実測値とのずれにより、システムの不具合を特定することができる。いずれにしても、本実施形態に係る監視システム１００に変更後のシステムの業務量を各業務システムの処理能力値としてタイムリーに反映する必要がある。
（その他の実施の形態）

【0055】

上記のように本発明を実施の形態によって記載したが、この開示の一部をなす記述及び図面はこの発明を限定するものであると理解するべきではない。この開示から当業者には様々な代替実施の形態、実施例及び運用技術が明らかになるはずである。

【0056】

例えば、自動計算部１２０による自動計算に限定されず、例えば、過去の事例に基づいて、ＦＡＸシステム２万人、ポイントシステム１万人のように、手動で入力しても構わない。このように、本発明はここでは記載していない様々な実施の形態等を包含するということを理解すべきである。

【符号の説明】

【0057】

１ 業務処理システム
１１〜１８ 業務システム
２０ ログ収集サーバ
３０ 集約サーバ
４０ 画像表示部
１００ 監視システム（集計分析サーバ）
１１０ リソース測定部
１２０ 自動計算部
１３０ リソース見積計算部
１４０ 判定部
１５０ 加工表示部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】