特許 6794829 集約支援装置、集約支援方法及び集約支援プログラム

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

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

(11)【特許番号】6794829

(24)【登録日】2020年11月16日

(45)【発行日】2020年12月2日

(54)【発明の名称】集約支援装置、集約支援方法及び集約支援プログラム

(51)【国際特許分類】

   G06F 9/48 20060101AFI20201119BHJP

   G06F 9/50 20060101ALI20201119BHJP

   G06F 9/455 20060101ALI20201119BHJP

【ＦＩ】

   G06F9/48 300A

   G06F9/50 150C

   G06F9/455 150

【請求項の数】8

【全頁数】24

(21)【出願番号】特願2016-256786(P2016-256786)

(22)【出願日】2016年12月28日

(65)【公開番号】特開2018-109836(P2018-109836A)

(43)【公開日】2018年7月12日

【審査請求日】2019年9月10日

(73)【特許権者】

【識別番号】000005223

【氏名又は名称】富士通株式会社

(74)【代理人】

【識別番号】110002147

【氏名又は名称】特許業務法人酒井国際特許事務所

(72)【発明者】

【氏名】海老根 直人

(72)【発明者】

【氏名】高石 明伸

(72)【発明者】

【氏名】北山 亨

(72)【発明者】

【氏名】森 敏嗣

(72)【発明者】

【氏名】吉川 大貴

(72)【発明者】

【氏名】酒井 和行

(72)【発明者】

【氏名】岡田 正太郎

【審査官】 清木 泰

(56)【参考文献】

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

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

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

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

【文献】 辻部晃久，貝原俊也，藤井信忠，野中洋一，分散協調手法を用いた装置メンテナンススケジューリングに関する研究，計測自動制御学会論文集，日本，公益社団法人計測自動制御学会，２０１０年１１月３０日，Vol.46，No.11，pp.651〜658

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

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

Ｇ０６Ｆ１５／１６ −１５／１７７

Ｇ０６Ｑ１０／００ −１０／１０

Ｇ０６Ｑ３０／００ −３０／０８

Ｇ０６Ｑ５０／００ −５０／２０

Ｇ０６Ｑ５０／２６ −９９／００

Ｇ１６Ｚ９９／００

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

【請求項1】

コンピュータに、
指定された複数の業務システムそれぞれに対応する複数の運用フローに含まれる操作の内容に基づき、各運用フローの種別を特定し、
特定した種別と、各運用フローの開始時刻及び終了時刻に基づき、前記複数の業務システムの動作状態と、各動作状態の期間及び変更可能期間とを特定し、
前記変更可能期間の範囲で前記動作状態について前記期間の変更を行うことにより、前記複数の業務システム間で同時に取り得ない動作状態が生じない前記複数の業務システムの組合せを生成できるか否かを判定し、
前記組合せが生成できると判定した場合に、前記組合せと各業務システムの動作状態の変更後の期間とを出力する
処理を実行させることを特徴とする集約支援プログラム。

【請求項2】

前記コンピュータに、
第１業務システムの第１バッチ処理が作成したバッチ結果を第２業務システムの第２バッチ処理が利用する状況を特定する処理をさらに実行させ、
前記状況を特定した場合に、前記第１バッチ処理の完了前に前記第２バッチ処理が起動されることが生じないように前記変更可能期間を特定する処理を実行させるためのものであることを特徴とする請求項１に記載の集約支援プログラム。

【請求項3】

前記コンピュータに、
前記第１バッチ処理の運用フローからファイルの送信先のＩＰアドレスと該ファイルの識別子を抽出し、抽出したＩＰアドレスに対応する業務システムを特定し、特定した業務システムの運用フローに前記識別子が含まれる場合に、前記第１バッチ処理が作成したバッチ結果を前記第２バッチ処理が利用する状況として特定する処理を実行させるためのものであることを特徴とする請求項２に記載の集約支援プログラム。

【請求項4】

前記種別を特定する処理は、
運用フローに含まれる操作にメンテナンスの終了とサービスの提供を示す操作がある場合に該運用フローをサービス提供フローと特定し、
運用フローに含まれる操作にサービスの停止を示す操作がある場合に該運用フローをサービス停止フローと特定し、
運用フロー実行前の状態がサービス停止状態であり、運用フローに含まれる操作にバッチ処理の起動を示す操作がある場合に該運用フローをバッチ処理フローと特定し、
運用フロー実行前の状態がサービス停止状態であり、運用フローに含まれる操作にメンテナンス作業を示す操作がある場合に該運用フローをメンテナンスフローと特定することを特徴とする請求項１、２又は３に記載の集約支援プログラム。

【請求項5】

前記コンピュータに、
前記サービス提供フローの起動時刻から次のサービス停止フローの終了時刻までをサービス提供状態として業務システムの動作状態を特定し、
前記バッチ処理フローの起動時刻から終了時刻までをバッチ処理状態として業務システムの動作状態を特定し、
前記メンテナンスフローの起動時刻から終了時刻までをメンテナンス状態として業務システムの動作状態を特定し、
前記サービス提供状態、前記バッチ処理状態、前記メンテナンス状態のいずれの状態でもない時間帯をサービス停止状態として業務システムの動作状態を特定する処理を実行させるためのものであることを特徴とする請求項４に記載の集約支援プログラム。

【請求項6】

前記判定する処理は、メンテナンス状態とサービス提供状態、及び、メンテナンス状態とバッチ処理状態を同時に取り得ない状態として前記複数の業務システムの組合せを生成できるか否かを判定することを特徴とする請求項５に記載の集約支援プログラム。

【請求項7】

コンピュータが、
指定された複数の業務システムそれぞれに対応する複数の運用フローに含まれる操作の内容に基づき、各運用フローの種別を特定し、
特定した種別と、各運用フローの開始時刻及び終了時刻に基づき、前記複数の業務システムの動作状態と、各動作状態の期間及び変更可能期間とを特定し、
前記変更可能期間の範囲で前記動作状態について前記期間の変更を行うことにより、前記複数の業務システム間で同時に取り得ない動作状態が生じない前記複数の業務システムの組合せを生成できるか否かを判定し、
前記組合せが生成できると判定した場合に、前記組合せと各業務システムの動作状態の変更後の期間とを出力する
処理を実行することを特徴とする集約支援方法。

【請求項8】

指定された複数の業務システムそれぞれに対応する複数の運用フローに含まれる操作の内容に基づき、各運用フローの種別を特定する第１特定部と、
前記第１特定部により特定された種別と、各運用フローの開始時刻及び終了時刻に基づき、前記複数の業務システムの動作状態と、各動作状態の期間及び変更可能期間とを特定する第２特定部と、
前記変更可能期間の範囲で前記動作状態について前記期間の変更を行うことにより、前記複数の業務システム間で同時に取り得ない動作状態が生じない前記複数の業務システムの組合せを生成できるか否かを判定する判定部と、
前記判定部により前記組合せが生成できると判定された場合に、前記組合せと各業務システムの動作状態の変更後の期間とを出力する出力部と
を有することを特徴とする集約支援装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、集約支援装置、集約支援方法及び集約支援プログラムに関する。

【背景技術】

【0002】

データセンターでは、ＴＣＯ（Total Cost of Ownership）の削減のため、仮想化技術を用いて設備の集約が進められてきた。物理サーバで運用されていた業務システムを、仮想サーバに移行することで、物理サーバ数の削減、ハードウェアの運用・保守費用の削減が実現されてきた。

【0003】

近年、さらなるＴＣＯの削減が求められており、仮想サーバ台数を削減することにより仮想サーバ毎にかかる運用・保守費用の削減を目指す動きがある。データセンターでは、稼働する業務システム毎に、あるいは必要があればサーバ種別（Ｗｅｂサーバ、ＤＢ（DataBase）サーバ、パッチサーバ）毎に仮想サーバが用意されるため、仮想サーバの台数が増加する。そこで、業務システムの特徴（サービス時間、メンテナンス時間、バッチ処理時間、処理の繁忙・閑散）を考慮し、１つの仮想サーバに複数の業務システムを集約していこうとする流れがある。

【0004】

図２３は、複数の業務システムの集約を説明するための図である。図２３に示すように、「損益管理システム」、「ＱＡ管理システム」及び「購買システム」の３つの業務システムがそれぞれ異なる仮想サーバ１１を利用すると３台の仮想サーバ１１が必要になる。一方、「損益管理システム」、「ＱＡ管理システム」及び「購買システム」の３つの業務システムを１台の仮想サーバ１１に集約することで、仮想サーバの台数を減らすことができる。

【0005】

なお、マルチベンダシステムの障害を通報されたプライマリ保守者端末が、障害に関連する保守会社システムに障害解決処理の指示を行い、障害の発生状況及び解決状況に関する報告文書を作成して発信することで、システム管理者の手間を削減する技術がある。

【0006】

また、コンピュータシステム利用における運用資源情報を利用環境管理情報テーブルで一元的に管理することで、コンピュータシステムの利用及び運用条件の関連性を明確にし、コンピュータシステム運用管理における信頼性及び操作性を向上する技術がある。

【0007】

また、ネットワークを構成する機能部位をエレメントとする構成図上に、障害発生に応じて選択されたエレメントの障害範囲にあるエレメントのリンクによる経路を影響範囲として表示することで、ネットワーク運用管理の負担を軽減する技術がある。

【0008】

また、検査事象から想定される故障事象をＴｒｅｅ展開した故障連関展開に基づいて計算された故障復旧予想コストと故障現象を防止するための予防保全コストを比較して保守管理時期・方法を判定することで、最適な保守管理時期を客観的に決定する技術がある。

【先行技術文献】

【特許文献】

【0009】

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

【特許文献2】特開平５−３３４２５１号公報

【特許文献3】特開２００８−３１２０２３号公報

【特許文献4】特開２００３−３０３０１４号公報

【発明の概要】

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

【0010】

業務システムでは、継続したサービス提供のため、運用操作が実施される。図２４は、業務システムに対する運用操作の例を示す図である。図２４に示すように、「損益管理システム」では、例えば、「０：００」に起動され「４：００」に終了する「損益集計処理」に関する運用操作が実施される。また、「ＱＡ管理システム」では、例えば、「０：００」から「０：３０」まで「仮想サーバを停止」するための運用操作が行われる。

【0011】

運用操作には、ＯＳ（Operating System）に対する再起動操作やパッチ適用など、同一仮想サーバに集約された他の業務システムの動作に影響を与える操作が存在する。そのため、複数の業務システムを１つの仮想サーバに集約する際には、集約対象となる業務システムそれぞれに実施される運用操作を、他の業務システムに影響を与えない時間に変更する必要がある。

【0012】

例えば、図２４に示した運用が実施されている「損益管理システム」と「ＱＡ管理システム」の集約を検討する場合、「ＱＡ管理システム」の「仮想サーバを停止」と「損益管理システム」の「損益集計処理」が同じ時間帯に行われているため、運用操作時間の変更が必要になる。

【0013】

しかしながら、業務システムに対する運用操作は、業務システムが提供するサービスを継続するために行われているものであり、運用管理者は、運用操作の時間の変更後も問題なくサービスの提供を行えるか確認した上で変更を行う必要がある。そのため、仮想サーバへの集約のための運用操作の変更には、業務システムに対する運用操作の意味の理解のため、人手に依る場合、例えば、１ヵ月といった期間の作業が必要となる。

【0014】

本発明は、１つの側面では、複数の業務システムの集約を支援することを目的とする。

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

【0015】

１つの態様では、集約支援装置は、第１特定部と、第２特定部と、判定部と、出力部とを有する。第１特定部は、指定された複数の業務システムそれぞれに対応する複数の運用フローに含まれる操作の内容に基づき、各運用フローの種別を特定する。第２特定部は、第１特定部により特定された種別と、各運用フローの開始時刻及び終了時刻に基づき、複数の業務システムの動作状態と、各動作状態の期間及び変更可能期間とを特定する。判定部は、変更可能期間の範囲で動作状態について期間の変更を行うことにより、複数の業務システム間で同時に取り得ない動作状態が生じない複数の業務システムの組合せを生成できるか否かを判定する。出力部は、判定部により組合せが生成できると判定された場合に、組合せと各業務システムの動作状態の変更後の期間とを出力する。

【発明の効果】

【0016】

１つの側面では、本発明は、複数の業務システムの集約を支援することができる。

【図面の簡単な説明】

【0017】

【図1】図１は、実施例に係る運用管理システムの構成を示す図である。

【図2】図２は、業務システム情報の一例を示す図である。

【図3】図３は、運用フローの一例を示す図である。

【図4】図４は、運用操作部品情報の一例を示す図である。

【図5】図５は、運用フローグループ情報の一例を示す図である。

【図6】図６は、集約支援部の機能構成を示す図である。

【図7】図７は、グループ情報テーブルの一例を示す図である。

【図8】図８は、業務システムの状態の４つの分類を示す図である。

【図9】図９は、分類テーブルの一例を示す図である。

【図10】図１０は、バッチ処理結果を利用する業務システムに関する運用フローの分類結果の一例を示す図である。

【図11】図１１は、利用情報テーブルの一例を示す図である。

【図12】図１２は、変更可能区間テーブルの一例を示す図である。

【図13】図１３は、状態遷移スケジュールと変更可能区間を示す図である。

【図14】図１４は、集約可能な状態遷移スケジュールの表示画面の一例を示す図である。

【図15】図１５は、他の業務システムでバッチ処理が行えなくなる場合を示す図である。

【図16】図１６は、集約支援処理のフローを示すフローチャートである。

【図17】図１７は、ステップＳ１の処理のフローを示すフローチャートである。

【図18】図１８は、ステップＳ２の処理のフローを示すフローチャートである。

【図19】図１９は、ステップＳ３の処理のフローを示すフローチャートである。

【図20】図２０は、ステップＳ４の処理のフローを示すフローチャートである。

【図21】図２１は、ステップＳ５の処理のフローを示すフローチャートである。

【図22】図２２は、実施例に係る集約支援プログラムを実行するコンピュータのハードウェア構成を示す図である。

【図23】図２３は、複数の業務システムの集約を説明するための図である。

【図24】図２４は、業務システムに対する運用操作の例を示す図である。

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

【0018】

以下に、本願の開示する集約支援装置、集約支援方法及び集約支援プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。

【実施例】

【0019】

まず、実施例に係る運用管理システムの構成について説明する。図１は、実施例に係る運用管理システムの構成を示す図である。図１に示すように、実施例に係る運用管理システム１０は、運用管理装置１と複数の仮想サーバ１１とを有する。各仮想サーバ１１では業務システムが動作する。業務システムには、例えば、「損益管理システム」、「ＱＡ管理システム」、「人事情報システム」、「購買システム」等がある。これらの業務システムは、運用管理装置１による集約対象である。図１は、集約前の業務システムを示す。

【0020】

運用管理装置１は、業務システムの運用を管理する装置であり、運用情報記憶部２と、実行スケジュール記憶部３と、運用自動実行部４と、集約支援部５と、分析情報記憶部６と、状態遷移スケジュール記憶部７とを有する。なお、図１において、実線の矢印は運用操作を表し、点線の矢印はデータの読込みを表し、破線の矢印はデータの書込みを表す。

【0021】

運用情報記憶部２は、業務システム情報、運用フロー情報、運用操作部品情報、運用フローグループ情報を記憶する。業務システム情報は、業務システムが動作する仮想サーバ１１のＩＰ（Internet Protocol）アドレスに関する情報である。図２は、業務システム情報の一例を示す図である。図２に示すように、業務システム情報は、業務システム名とＩＰアドレスとを対応付ける。

【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】

振り分け先を業務システムのＷｅｂサーバに変更する処理の判断は運用フローが以下の何れかの処理を行っているかどうかで行われる。
（１）運用フローを構成する運用操作部品に「ファイルの文字列置換」が存在し、運用フローが、Ｗｅｂサーバの設定ファイルの記述を「メンテナンス状態」の表示から「サービス提供状態」に切り替えている。
（２）運用フローを構成する運用操作部品に「ＤＮＳ（Domain Name System）の切り替え」が存在する。そして、運用フローが、業務システムのドメイン名に紐付けられたＩＰアドレスを、メンテナンスサーバのＩＰアドレスから業務システムのＷｅｂサーバのＩＰアドレスに切り替えている。
（３）運用フローを構成する運用操作部品に「ロードバランサーの切り替え」が存在し、ロードバランサーに対するレスポンス設定を「メンテナンス状態」の表示から業務システムのＷｅｂサーバに切り替えている。

【0047】

分類部５１ｂは、運用フローで実施する処理に、Ｗｅｂサーバに対するアクセスの振り分け先を業務システムのＷｅｂサーバから変更する処理を含むものを「サービス停止フロー」と分類する。

【0048】

振り分け先を業務システムのＷｅｂサーバから変更する処理の判断は運用フローが以下の何れかの処理を行っているかどうかで行われる。
（１）運用フローを構成する運用操作部品に「ファイルの文字列置換」が存在し、運用フローが、Ｗｅｂサーバの設定ファイルの記述を「メンテナンス状態」の表示から「サービス停止状態」に切り替えている。
（２）運用フローを構成する運用操作部品に「ＤＮＳの切り替え」が存在し、運用フローが、業務システムのドメイン名に紐付けられたＩＰアドレスを、業務システムのＷｅｂサーバのＩＰアドレスからメンテナンスサーバのＩＰアドレスに切り替えている。
（３）運用フローを構成する運用操作部品に「ロードバランサーの切り替え」が存在し、運用フローが、ロードバランサーに対するレスポンス設定を業務システムのＷｅｂサーバから「メンテナンス状態」の表示に切り替えている。

【0049】

分類部５１ｂは、以下の両方に当てはまる場合、「バッチ処理フロー」と分類する。
（１）フロー実行前の状態が、「サービス停止状態」である。
（２）運用フローを構成する運用操作部品に「バッチを起動」が存在する。

【0050】

分類部５１ｂは、以下の両方に当てはまる場合、「メンテナンスフロー」と分類する。
（１）フロー実行前の状態が、「サービス停止状態」である。
（２）運用フローを構成する部品に「ＯＳの修正パッチ適用」、「ミドルウェアの修正パッチ適用」、「仮想サーバを再起動」又は「仮想サーバを停止」が存在する。

【0051】

分類部５１ｂは、運用フローの分類結果を分析情報記憶部６の分類テーブルに登録する。図９は、分類テーブルの一例を示す図である。図９に示すように、分類テーブルは、図７に示したグループ情報テーブルに運用フローの分類が追加されたテーブルである。例えば、図４に示したように、運用フロー「損益収益処理」は、運用操作部品に「バッチを起動」が存在するので、「サービス停止状態」で実行されると、「バッチ処理フロー」に分類される。

【0052】

利用状況特定部５２は、バッチ処理フローに分類された運用フローのバッチ処理結果が他の運用フローにおいて利用される場合を以下の手順で特定する。
（１）利用状況特定部５２は、バッチ処理フローにおいて、運用操作部品「ファイルを転送」の情報を運用操作部品情報から抽出する。運用操作部品「ファイルを転送」の情報が存在しない場合は、利用状況特定部５２は、処理を終了する。
（２）利用状況特定部５２は、「ファイルを転送」の送信先ＩＰアドレスを運用操作部品情報から取得する。例えば、図４に示したバッチ処理フロー「損益収益処理」の運用操作部品情報から、ファイルの送信先ＩＰアドレスとして「１９２．１６８．０．３」が取得される。

【0053】

（３）利用状況特定部５２は、送信先ＩＰアドレスに対応する業務システムを業務システム情報から抽出する。例えば、ファイルの送信先ＩＰアドレスとして取得された「１９２．１６８．０．３」に対応する業務システムは、図２に示したように、「購買システム」である。
（４）利用状況特定部５２は、（３）で抽出した業務システムの運用フローのグループを取得し、取得した運用フローを分類する。図１０は、バッチ処理結果を利用する業務システムに関する運用フローの分類結果の一例を示す図である。図１０に示すように、「購買システム」に関する運用フローには、「経理処理」、「購買システム起動」等があり、「経理処理」が「バッチ処理フロー」に分類されている。ただし、この例では、「経理処理」のバッチ処理結果を利用する業務システムはない。

【0054】

（５）利用状況特定部５２は、（４）で取得した運用フローに含まれるバッチ処理フローにおいて、送信ファイル名を含む運用フローを抽出する。送信ファイル名を含む運用フローが存在しない場合は、利用状況特定部５２は、処理を終了する。
（６）利用状況特定部５２は、（３）で抽出した業務システムを分析情報記憶部６の利用情報テーブルの利用業務システム名に登録し、（５）で抽出した運用フローを利用情報テーブルの利用フロー名に登録する。

【0055】

図１１は、利用情報テーブルの一例を示す図である。図１１に示すように、利用情報テーブルは、業務システム名と、運用フロー名と、分類と、利用業務システム名と、利用フロー名とを対応付ける。利用業務システム名は、バッチ処理結果を利用する業務システムの名前である。利用フロー名は、バッチ処理結果を利用するバッチ処理フローの名前である。図１１では、「損益集計処理」のバッチ処理結果を利用する「購買システム」の「経理処理」が登録されている。
（７）利用状況特定部５２は、利用フローについても同様に（１）からの特定処理を実施する。図１０に示したように、「経理処理」のバッチ処理結果を利用する業務システムはないので、「損益集計処理」を先頭とするバッチ処理結果の利用の連鎖は、「損益集計処理」−「経理処理」で途切れる。

【0056】

スケジュール特定部５３は、運用フローの分類結果と運用フローの起動時刻及び終了時刻とに基づいて、業務システムの状態遷移スケジュールを特定する。そして、スケジュール特定部５３は、時間帯の変更が可能な「サービス停止状態」、「バッチ処理状態」及び「メンテナンス状態」について、時間帯の変更可能区間を特定する。

【0057】

具体的には、スケジュール特定部５３は、運用日付毎に以下の手順で業務システムの状態遷移スケジュールを特定する。
（１）スケジュール特定部５３は、「サービス提供フロー」の起動時刻から次の「サービス停止フロー」の終了時刻までを「サービス提供状態」とする。
（２）スケジュール特定部５３は、「バッチ処理フロー」の起動時刻から終了時刻までを「バッチ処理状態」とする。
（３）スケジュール特定部５３は、「メンテナンスフロー」の起動時刻から終了時刻までを「メンテナンス状態」とする。
（４）スケジュール特定部５３は、（１）〜（３）に当てはまらない時間を「サービス停止状態」とする。

【0058】

そして、スケジュール特定部５３は、以下の手順で時間帯の変更可能区間を特定する。
（１）スケジュール特定部５３は、時間帯の変更が可能な状態の前に、他に時間帯の変更が可能な状態への遷移が存在しない場合、「サービス提供状態」の終了時刻を時間帯の変更が可能な状態の開始可能時刻とする。また、スケジュール特定部５３は、時間帯の変更が可能な状態の前に、他に時間帯の変更が可能な状態への遷移が存在する場合、その全てを、最も早い時間に実行した場合の終了時刻を、時間帯の変更が可能な状態の開始可能時刻とする。
（２）スケジュール特定部５３は、時間帯の変更が可能な状態の後ろに、他に時間帯の変更が可能な状態への遷移が存在しない場合、「サービス提供状態」の開始時刻を時間帯の変更が可能な状態の終了可能時刻とする。また、スケジュール特定部５３は、時間帯の変更が可能な状態の後ろに、他に時間帯の変更が可能な状態への遷移が存在する場合、その全てを最も遅い時間に実行した場合の開始時刻を、時間帯の変更が可能な状態の終了可能時刻とする。

【0059】

また、スケジュール特定部５３は、「バッチ処理フロー」に分類された運用フローのバッチ処理結果が他の運用フローにおいて利用される場合には、他の運用フローにおけるバッチ処理の時間帯に基づいて、時間帯の変更可能区間を特定する。

【0060】

そして、スケジュール特定部５３は、「バッチ処理状態」及び「メンテナンス状態」について、分析情報記憶部６の変更可能区間テーブルに開始可能時刻と終了可能時刻を登録する。図１２は、変更可能区間テーブルの一例を示す図であり、図１３は、状態遷移スケジュールと変更可能区間を示す図である。

【0061】

図１２に示すように、変更可能区間テーブルは、「バッチ処理状態」及び「メンテナンス状態」について、開始時刻と、終了時刻と、開始可能時刻と、終了可能時刻と、利用システム名と、利用フロー名とを対応付ける。

【0062】

例えば、図１２及び図１３に示すように、「損益管理システム」の「メンテナンス状態」は、現在の開始時刻は「２０：３０」であるが、「２０：０５」から開始可能である。また、「損益管理システム」の「メンテナンス状態」は、現在の終了時刻は「２３：３０」であるが、「０：２５」までに終了すればよい。

【0063】

ここで、「損益管理システム」のバッチ処理は、「購買システム」のバッチ処理との関係で、「０４：２５」までに終了する必要があるため、「０：２５」までに開始する必要がある。したがって、「損益管理システム」の「メンテナンス状態」は、「０：２５」までに終了する必要がある。

【0064】

集約部５４は、業務システムの状態遷移スケジュールと変更可能区間に基づいて、集約候補として指定された複数の業務システムの集約が可能か否かを判定し、集約が可能である場合に、集約可能な業務システムの状態遷移スケジュールを画面に表示する。集約部５４は、判定部５４ａと出力部５４ｂとを有する。

【0065】

判定部５４ａは、以下の手順で、集約候補として指定された複数の業務システムの集約が可能か否かを判定し、集約が可能である場合に、集約可能な業務システムの状態遷移スケジュールを作成する。
（１）判定部５４ａは、集約候補として指定された業務システムの１つを選択し、集約候補グループとする。

【0066】

（２）判定部５４ａは、集約候補グループに含まれていない業務システムＡと、集約候補グループに含まれる業務システムの状態遷移スケジュールを比較し、以下のいずれかに該当する場合に業務システムＡを集約候補グループに追加する。
(ア)全ての業務システムの状態について「メンテナンス状態」と「バッチ処理状態」、及び、「メンテナンス状態」と「サービス提供状態」との時間帯が重複しない。
(イ)ある業務システムが「メンテナンス状態」となる時間帯について、その「メンテナンス状態」の時間帯を変更することにより、「メンテナンス状態」と「バッチ処理状態」」、及び、「メンテナンス状態」と「サービス提供状態」の時間帯が重複しない。
(ウ)他の業務システムの状態の時間帯を変更することで、「メンテナンス状態」と「バッチ処理状態」、及び、「メンテナンス状態」と「サービス提供状態」が重複しない。

【0067】

（３）判定部５４ａは、全ての集約候補の組み合わせについて（１）及び（２）を実施する。そして、判定部５４ａは、複数の集約候補が属する集約候補グループがある場合には、集約が可能であると判定し、複数の集約候補の状態遷移スケジュールを状態遷移スケジュール記憶部７に格納する。一方、複数の集約候補が属する集約候補グループがない場合には、判定部５４ａは、集約が可能でないと判定する。

【0068】

出力部５４ｂは、全ての集約候補グループについて、集約可能な状態遷移スケジュールを画面に表示する。図１４は、集約可能な状態遷移スケジュールの表示画面の一例を示す図である。図１３と比較すると、図１４では、「ＱＡ管理システム」の「メンテナンス状態」の開始時刻を「０：００」から「２０：０５」に変更することで「損益管理システム」の「バッチ処理状態」と「ＱＡ管理システム」の「メンテナンス状態」の重複が解消されている。

【0069】

図１５は、他の業務システムでバッチ処理が行えなくなる場合を示す図である。図１４と比較すると、図１５では、「人事情報システム」が集約候補として追加されている。「人事情報システム」は、図１２に示したように、「５：５５」から「０：０５」まで「サービス提供状態」であるので、「損益管理システム」及び「ＱＡ管理システム」の「メンテナンス状態」の開始時刻は「０：０５」に変更され、終了時刻は「３：０５」に変更される。しかしながら、この場合、「損益管理システム」のバッチ処理結果を「購買システム」が利用できない。したがって、判定部５４ａは、「損益管理システム」、「ＱＡ管理システム」、「人事情報システム」及び「購買システム」の集約は可能でないと判定する。

【0070】

次に、集約支援処理のフローについて説明する。図１６は、集約支援処理のフローを示すフローチャートである。図１６に示すように、集約支援部５は、集約候補として指定された業務システムの運用を行う運用フローのグループを取得し（ステップＳ１）、取得したグループに含まれる運用フローを分類する（ステップＳ２）。

【0071】

そして、集約支援部５は、バッチ処理フローに分類した運用フローの結果の他の運用フローにおける利用状況を特定し（ステップＳ３）、分類した運用フローの実行スケジュールから、業務システムの状態遷移スケジュールを作成する（ステップＳ４）。そして、集約支援部５は、バッチ処理結果の利用状況と、業務システムの時間帯毎の動作状態から集約可能な運用を表示する（ステップＳ５）。

【0072】

このように、集約支援部５は、バッチ処理結果の利用状況と、業務システムの時間帯毎の動作状態から集約可能な運用を表示することで、複数の業務システムの集約を支援することができる。

【0073】

図１７は、ステップＳ１の処理のフローを示すフローチャートである。図１７に示すように、取得部５１ａは、運用フローグループ情報から業務システムに対応する運用フローのグループを選択する（ステップＳ１１）。そして、取得部５１ａは、選択したグループ内の全ての運用フローについて起動時刻、終了時刻及び起動パターンの情報を取得する（ステップＳ１２）。

【0074】

そして、取得部５１ａは、取得した情報をグループ情報テーブルに書込み（ステップＳ１３）、全てのグループの情報を取得したか否かを判定する（ステップＳ１４）。そして、取得部５１ａは、情報を取得していないグループがある場合には、ステップＳ１１に戻り、情報を取得していないグループがない場合には、処理を終了する。

【0075】

図１８は、ステップＳ２の処理のフローを示すフローチャートである。図１８に示すように、分類部５１ｂは、運用フローを構成する運用操作部品に「ファイルの文字列置換」が存在し、Ｗｅｂサーバの設定ファイルの記述を「メンテナンス状態」の表示から「サービス提供状態」に切り替えているか否かを判定する（ステップＳ２１）。そして、分類部５１ｂは、ステップＳ２１の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「サービス提供フロー」を登録し（ステップＳ２２）、ステップＳ２ｄへ進む。

【0076】

一方、分類部５１ｂは、ステップＳ２１の判定結果が「Ｎｏ」である場合には、運用フローを構成する運用操作部品に「ＤＮＳの切り替え」が存在し、業務システムのドメイン名に紐付けられたＩＰアドレスを、メンテナンスサーバのＩＰアドレスから業務システムのＷｅｂサーバのＩＰアドレスに切り替えているか否かを判定する（ステップＳ２３）。そして、分類部５１ｂは、ステップＳ２３の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「サービス提供フロー」を登録し（ステップＳ２２）、ステップＳ２ｄへ進む。

【0077】

一方、分類部５１ｂは、ステップＳ２３の判定結果が「Ｎｏ」である場合には、運用フローを構成する運用操作部品に「ロードバランサーの切り替え」が存在し、ロードバランサーに対するレスポンス設定を「メンテナンス状態」の表示から業務システムのＷｅｂサーバに切り替えているか否かを判定する（ステップＳ２４）。そして、分類部５１ｂは、ステップＳ２４の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「サービス提供フロー」を登録し（ステップＳ２２）、ステップＳ２ｄへ進む。

【0078】

一方、分類部５１ｂは、ステップＳ２４の判定結果が「Ｎｏ」である場合には、運用フローを構成する運用操作部品に「ファイルの文字列置換」が存在し、Ｗｅｂサーバの設定ファイルの記述を「メンテナンス状態」の表示から「サービス提供状態」に切り替えているか否かを判定する（ステップＳ２５）。そして、分類部５１ｂは、ステップＳ２５の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「サービス停止フロー」を登録し（ステップＳ２６）、ステップＳ２ｄへ進む。

【0079】

一方、分類部５１ｂは、ステップＳ２５の判定結果が「Ｎｏ」である場合には、運用フローを構成する運用操作部品に「ＤＮＳの切り替え」が存在し、業務システムのドメイン名に紐付けられたＩＰアドレスを、メンテナンスサーバのＩＰアドレスから業務システムのＷｅｂサーバのＩＰアドレスに切り替えているか否かを判定する（ステップＳ２７）。そして、分類部５１ｂは、ステップＳ２７の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「サービス停止フロー」を登録し（ステップＳ２６）、ステップＳ２ｄへ進む。

【0080】

一方、分類部５１ｂは、ステップＳ２７の判定結果が「Ｎｏ」である場合には、運用フローを構成する運用操作部品に「ロードバランサーの切り替え」が存在し、ロードバランサーに対するレスポンス設定を「メンテナンス状態」の表示から業務システムのＷｅｂサーバに切り替えているか否かを判定する（ステップＳ２８）。そして、分類部５１ｂは、ステップＳ２８の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「サービス停止フロー」を登録し（ステップＳ２６）、ステップＳ２ｄへ進む。

【0081】

一方、分類部５１ｂは、ステップＳ２８の判定結果が「Ｎｏ」である場合には、運用フロー実行前の状態が「サービス停止状態」であり、運用フローを構成する運用操作部品に「バッチを起動」が存在するか否かを判定する（ステップＳ２９）。そして、分類部５１ｂは、ステップＳ２９の判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「バッチ処理フロー」を登録し（ステップＳ２ａ）、ステップＳ２ｄへ進む。

【0082】

一方、分類部５１ｂは、ステップＳ２９の判定結果が「Ｎｏ」である場合には、運用フロー実行前の状態が「サービス停止状態」であり、「ＯＳの修正パッチ適用」、「ミドルウェアの修正パッチ適用」、「仮想サーバを再起動」、「仮想サーバを停止」の何れかの運用操作部品が存在するか否かを判定する（ステップＳ２ｂ）。そして、分類部５１ｂは、ステップＳ２ｂの判定結果が「Ｙｅｓ」である場合には、分類テーブルの分類に「メンテナンスフロー」を登録する（ステップＳ２ｃ）。

【0083】

そして、分類部５１ｂは、全ての運用フローの判定を終了したか否かを判定し（ステップＳ２ｄ）、判定していない運用フローがある場合には、ステップＳ２１に戻り、全ての運用フローの判定を終了した場合には、処理を終了する。

【0084】

図１９は、ステップＳ３の処理のフローを示すフローチャートである。図１９に示すように、利用状況特定部５２は、運用フローから運用操作部品「ファイルを転送」の情報を抽出し（ステップＳ３１）、「ファイルを転送」の運用操作部品が存在するか否かを判定する（ステップＳ３２）。そして、「ファイルを転送」の運用操作部品が存在しない場合には、利用状況特定部５２は、処理を終了する。

【0085】

一方、「ファイルを転送」の運用操作部品が存在する場合には、利用状況特定部５２は、「ファイルを転送」の運用操作部品の実行パラメータよりファイルの送信先ＩＰアドレスと送信元ファイル名を取得する（ステップＳ３３）。そして、利用状況特定部５２は、送信先ＩＰアドレスに対応する業務システムを特定する（ステップＳ３４）。

【0086】

そして、利用状況特定部５２は、特定した業務システムのグループを特定し、ステップＳ２の処理を実行する（ステップＳ３５）。そして、利用状況特定部５２は、ステップＳ３３で取得した送信元ファイル名を含む運用フローを抽出し（ステップＳ３６）、運用フローが抽出されたか否かを判定する（ステップＳ３７）。そして、運用フローが抽出されなかった場合には、利用状況特定部５２は、処理を終了する。

【0087】

一方、運用フローが抽出された場合には、利用状況特定部５２は、抽出された運用フローを利用フローとして利用情報テーブルに登録し（ステップＳ３８）、ステップＳ３１に戻る。

【0088】

図２０は、ステップＳ４の処理のフローを示すフローチャートである。図２０に示すように、スケジュール特定部５３は、分類テーブルから運用フローの分類、起動時刻及び終了時刻の情報を抽出する（ステップＳ４１）。そして、スケジュール特定部５３は、「サービス提供フロー」の起動時刻から次の「サービス停止フロー」の終了時刻までを「サービス提供状態」と特定する（ステップＳ４２）。

【0089】

そして、スケジュール特定部５３は、「バッチ処理フロー」の起動時刻から終了時刻までを「バッチ処理状態」と特定し（ステップＳ４３）、「メンテナンスフロー」の起動時刻から終了時刻までを「メンテナンス状態」と特定する（ステップＳ４４）。そして、スケジュール特定部５３は、他の時間を「サービス停止状態」と特定する（ステップＳ４５）。

【0090】

そして、スケジュール特定部５３は、時間帯の変更が可能な状態の前に、他に時間帯の変更が可能な状態への遷移が存在しないか否かを判定する（ステップＳ４６）。そして、ステップＳ４６の判定結果が「Ｙｅｓ」である場合には、スケジュール特定部５３は、「サービス提供状態」の終了時刻を時間帯の変更が可能な状態の開始可能時刻とし、変更可能区間テーブルに登録する（ステップＳ４７）。一方、ステップＳ４６の判定結果が「Ｎｏ」である場合には、スケジュール特定部５３は、時間帯の変更が可能な全ての状態を最も早い時間に実行した場合の終了時刻を時間帯の変更が可能な状態の開始可能時刻とし、変更可能区間テーブルに登録する（ステップＳ４８）。なお、スケジュール特定部５３は、時間帯の変更が可能な状態の開始可能時刻を特定する場合に、バッチ処理結果の利用状況を制約として用いる。

【0091】

そして、スケジュール特定部５３は、時間帯の変更が可能な状態の後ろに、他に時間帯の変更が可能な状態への遷移が存在しないか否かを判定する（ステップＳ４９）。そして、ステップＳ４９の判定結果が「Ｙｅｓ」である場合には、スケジュール特定部５３は、「サービス提供状態」の開始時刻を時間帯の変更が可能な状態の終了可能時刻とし、変更可能区間テーブルに登録する（ステップＳ４ａ）。一方、ステップＳ４９の判定結果が「Ｎｏ」である場合には、スケジュール特定部５３は、時間帯の変更が可能な全ての状態を最も遅い時間に実行した場合の開始時刻を時間帯の変更が可能な状態の終了可能時刻とし、変更可能区間テーブルに登録する（ステップＳ４ｂ）。なお、スケジュール特定部５３は、時間帯の変更が可能な状態の終了可能時刻を特定する場合に、バッチ処理結果の利用状況を制約として用いる。

【0092】

そして、スケジュール特定部５３は、全ての運用日付で実施したか否かを判定し（ステップＳ４ｃ）、実施していない運用日付がある場合には、ステップＳ４１に戻り、全ての運用日付で実施した場合には、処理を終了する。

【0093】

図２１は、ステップＳ５の処理のフローを示すフローチャートである。図２１に示すように、集約部５４は、集約候補として指定された業務システムの１つを選択し、集約候補グループを作成する（ステップＳ５１）。そして、集約部５４は、集約候補グループに含まれていない業務システムＡと集約候補グループに含まれる業務システムの状態遷移スケジュールを比較する（ステップＳ５２）。

【0094】

そして、集約部５４は、業務システムＡと集約候補グループに含まれる業務システムのの状態について、「メンテナンス状態」と「バッチ処理状態」、及び、「メンテナンス状態」と「サービス提供状態」の時間帯が重複しないか否かを判定する（ステップＳ５３）。

【0095】

そして、集約部５４は、ステップＳ５３の判定結果が「Ｎｏ」である場合には、ある業務システムが「メンテナンス状態」となる時間帯について、その業務システムの「メンテナンス状態」の時間帯を変更することにより重複が解消するか否かを判定する（ステップＳ５４）。そして、集約部５４は、ステップＳ５４の判定結果が「Ｎｏ」である場合には、他の業務システムの状態の時間帯を変更することで、重複が解消するか否かを判定する（ステップＳ５５）。

【0096】

そして、集約部５４は、ステップＳ５５の判定結果が「Ｎｏ」である場合には、全ての集約候補の組合せで集約可否の判定を実施したか否かを判定し（ステップＳ５６）、集約可否の判定を行っていない組合せがある場合には、ステップＳ５１に戻る。一方、全ての集約候補の組合せで集約可否の判定を実施した場合には、集約部５４は、全ての集約候補グループについて、集約可能な状態遷移スケジュールを表示する（ステップＳ５７）。

【0097】

また、ステップＳ５３、ステップ５４及びステップ５５の判定結果が「Ｙｅｓ」である場合には、集約部５４は、業務システムＡを集約候補グループに追加し（ステップＳ５８）、ステップＳ５６に移動する。

【0098】

上述してきたように、実施例では、集約支援部５の分類部５１ｂが、指定された複数の業務システムそれぞれに対応する複数の運用フローに含まれる運用操作部品の内容に基づき、各運用フローを分類する。そして、スケジュール特定部５３が、運用フローの分類、起動時刻及び終了時刻に基づいて、業務システムの動作状態と各動作状態の期間及び変更可能期間を特定する。そして、判定部５４ａが、変更可能期間の範囲で動作状態の変更を行うことで、複数の業務システム間で同時に取り得ない動作状態が生じない複数の業務システムの組合せを生成できるか否かを判定する。そして、複数の業務システム間で同時に取り得ない動作状態が生じない複数の業務システムの組合せが生成される場合に、出力部５４ｂが、複数の業務システムの組合せと動作状態の変更後の期間とを表示する。したがって、集約支援部５は、複数の業務システムの集約を支援することができる。

【0099】

また、実施例では、利用状況特定部５２が、バッチ処理結果が他の業務システムのバッチ処理で利用されている状況を特定し、スケジュール特定部５３は、バッチ処理結果が他の業務システムのバッチ処理で利用できるように動作状態の変更可能期間を特定する。したがって、集約支援部５は、バッチ処理結果が他の業務システムのバッチ処理で利用できる集約案を表示することができる。

【0100】

また、実施例では、利用状況特定部５２は、バッチ処理フローの運用操作部品情報からバッチ処理結果を記憶するファイルの名前を特定し、バッチ処理結果の転送先の業務システムのバッチ処理フローの運用操作部品情報にファイルの名前が含まれるかを判定する。そして、利用状況特定部５２は、バッチ処理結果の送信先の業務システムのバッチ処理フローの運用操作部品情報にファイルの名前が含まれる場合に、バッチ処理結果が他の業務システムのバッチ処理で利用されていると判定する。したがって、利用状況特定部５２は、バッチ処理結果が他の業務システムのバッチ処理で利用されている状況を正確に特定することができる。

【0101】

また、実施例では、分類部５１ｂは、運用フローに含まれる運用操作部品にメンテナンスの終了とサービスの起動を示す操作がある場合に当該運用フローを「サービス提供フロー」と特定する。また、分類部５１ｂは、運用フローに含まれる運用操作部品にメンテナンスの終了とサービスの停止を示す操作がある場合に当該運用フローを「サービス停止フロー」と特定する。また、分類部５１ｂは、運用フロー実行前の状態が「サービス停止状態」であり、運用フローに含まれる運用操作部品にバッチ処理の起動を示す操作がある場合に当該運用フローを「バッチ処理フロー」と特定する。また、分類部５１ｂは、運用フロー実行前の状態が「サービス停止状態」であり、運用フローに含まれる運用操作部品にメンテナンス作業を示す操作がある場合に当該運用フローを「メンテナンスフロー」と特定する。したがって、分類部５１ｂは、正確に運用フローを分類することができる。

【0102】

また、実施例では、スケジュール特定部５３は、運用フローの種別、起動時刻及び終了時刻に基づいて業務システムの動作状態を特定するので、業務システムの動作状態を正確に特定することができる。

【0103】

また、実施例では、判定部５４ａは、「メンテナンス状態」と「サービス提供状態」、及び、「メンテナンス状態」と「バッチ処理状態」を同時に取り得ない状態として集約が可能か否かを判定する。したがって、判定部５４ａは、集約によってメンテナンス中に処理が行われる状況が発生することを防ぐことができる。

【0104】

なお、実施例では、集約支援部５について説明したが、集約支援部５が有する構成をソフトウェアによって実現することで、同様の機能を有する集約支援プログラムを得ることができる。そこで、集約支援プログラムを実行するコンピュータについて説明する。

【0105】

図２２は、実施例に係る集約支援プログラムを実行するコンピュータのハードウェア構成を示す図である。図２２に示すように、コンピュータ８０は、メインメモリ８１と、ＣＰＵ（Central Processing Unit）８２と、ＬＡＮ（Local Area Network）インタフェース８３と、ＨＤＤ（Hard Disk Drive）８４とを有する。また、コンピュータ８０は、スーパーＩＯ（Input Output）８５と、ＤＶＩ（Digital Visual Interface）８６と、ＯＤＤ（Optical Disk Drive）８７とを有する。

【0106】

メインメモリ８１は、プログラムやプログラムの実行途中結果などを記憶するメモリである。ＣＰＵ８２は、メインメモリ８１からプログラムを読出して実行する中央処理装置である。ＣＰＵ８２は、メモリコントローラを有するチップセットを含む。

【0107】

ＬＡＮインタフェース８３は、コンピュータ８０をＬＡＮ経由で他のコンピュータに接続するためのインタフェースである。ＨＤＤ８４は、プログラムやデータを格納するディスク装置であり、スーパーＩＯ８５は、マウスやキーボードなどの入力装置を接続するためのインタフェースである。ＤＶＩ８６は、液晶表示装置を接続するインタフェースであり、ＯＤＤ８７は、ＤＶＤの読み書きを行う装置である。

【0108】

ＬＡＮインタフェース８３は、ＰＣＩエクスプレス（ＰＣＩｅ）によりＣＰＵ８２に接続され、ＨＤＤ８４及びＯＤＤ８７は、ＳＡＴＡ（Serial Advanced Technology Attachment）によりＣＰＵ８２に接続される。スーパーＩＯ８５は、ＬＰＣ（Low Pin Count）によりＣＰＵ８２に接続される。

【0109】

そして、コンピュータ８０において実行される集約支援プログラムは、ＤＶＤに記憶され、ＯＤＤ８７によってＤＶＤから読出されてコンピュータ８０にインストールされる。あるいは、集約支援プログラムは、ＬＡＮインタフェース８３を介して接続された他のコンピュータシステムのデータベースなどに記憶され、これらのデータベースから読出されてコンピュータ８０にインストールされる。そして、インストールされた集約支援プログラムは、ＨＤＤ８４に記憶され、メインメモリ８１に読出されてＣＰＵ８２によって実行される。

【符号の説明】

【0110】

１ 運用管理装置
２ 運用情報記憶部
３ 実行スケジュール記憶部
４ 運用自動実行部
５ 集約支援部
６ 分析情報記憶部
７ 状態遷移スケジュール記憶部
１０ 運用管理システム
１１ 仮想サーバ
５１ 種別特定部
５１ａ 取得部
５１ｂ 分類部
５２ 利用状況特定部
５３ スケジュール特定部
５４ 集約部
５４ａ 判定部
５４ｂ 出力部
８０ コンピュータ
８１ メインメモリ
８２ ＣＰＵ
８３ ＬＡＮインタフェース
８４ ＨＤＤ
８５ スーパーＩＯ
８６ ＤＶＩ
８７ ＯＤＤ

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】