"情報処理システムを対象としてインシデント管理運用業務を行うためのインシデント管理運用システムであって、インシデントの作業のステップに関する改善依頼の情報を担当部署またはユーザに対して自動的に送信してフォローを図るフォロー機能を有するフォローシステムを有し、上記フォロー対象とするステップは、解決時間が許容時間を越えるインシデントのステップ、あるいは、作業の開始から終了までの所要時間が最長のステップとすること、を特徴とするインシデント管理運用システム。請求項1記載のインシデント管理運用システムにおいて、前記フォローシステムは、前記フォロー対象となる1つ以上のステップについての情報を、所要時間の長い順に優先順として一覧表示する画面を、前記担当部署またはユーザの端末に提供する、一覧表示機能を有すること、を特徴とするインシデント管理運用システム。請求項1記載のインシデント管理運用システムにおいて、前記フォローシステムのフォロー機能は、インシデント情報と、前記ステップの所要時間の情報を含むインシデント処理履歴情報と、インシデントの発生元情報と、前記許容時間の情報を含むサービス情報と、前記ステップ、担当部署、及び連絡先の情報を含むステップ担当情報と、前記ステップ及び担当部署ごとに定義される前記改善依頼の情報を作成するための定義情報を含む依頼定義情報と、を用いて、前記フォロー対象ステップを決定し、前記改善依頼の情報を作成すること、を特徴とするインシデント管理運用システム。請求項2記載のインシデント管理運用システムにおいて、前記フォローシステムの一覧表示機能は、インシデント情報と、前記ステップの所要時間の情報を含むインシデント処理履歴情報と、インシデントの発生元情報と、前記許容時間の情報を含むサービス情報と、前記ステップ、担当部署、及び連絡先の情報を含むステップ担当情報と、前記ステップ及び担当部署ごとに定義される前記改善依頼の情報を作成するための定義情報を含む依頼定義情報と、を用いて、前記フォロー対象ステップを決定し、前記一覧表示する画面を作成すること、を特徴とするインシデント管理運用システム。前述のように、従来技術の課題として、インシデント解決時間分析とフォローの仕組みを持たない点がある。復旧作業などのインシデント解決の遅延、及び改善不足などの問題がある。そこで、本発明の主な目的は、従来技術を利用したインシデント解決時間短縮の課題を解決し、例えば復旧の遅延原因となった部署やユーザに復旧作業内容の改善を促すことで復旧時間を短縮すること等を実現できる技術を提供することである。上記目的を達成するため、本発明のうち代表的な形態は、情報処理システム顧客システム、データセンタ等を対象としてインシデント管理運用業務を行うための情報処理システムインシデント管理運用システム等であって、以下に示す構成を有することを特徴とする。本システムでは、特に、発生したインシデント情報、インシデント処理履歴、及びサービス停止許容時間の定義情報、フォロー対象別ステップ別、部署別の連絡先及び連絡内容フォロー内容の定義情報、などのデータ情報を用いて、解決の所要時間が大きいインシデントやそのステップ作業などを対象として、対応する担当部署やユーザに対して当該作業の改善依頼情報フォロー情報をメール等で自動的に作成して送信するフォロー機能対応する復旧作業改善依頼自動送信方法等、並びに、上記改善依頼情報を送信する対象フォロー対象となる1つ以上のステップ作業についての情報を、対処の優先順に一覧情報を表示する画面を作成して提供する一覧表示機能対応する改善対象作業対処優先順一覧表示方法等などを有する。上記フォロー対象は、例えば、1つのインシデントの解決に関わった複数のステップのうち、所要時間が最長のステップ、及び対応する担当部署などとして決定する。本インシデント管理運用システムは、例えば、インシデントの作業のステップに関する改善依頼の情報を担当部署またはユーザ等に対して自動的に送信してフォローを図るフォロー機能を有するフォローシステムを有する。上記フォロー対象候補とするステップは、例えば、解決時間が許容時間を越えるインシデントのステップ、あるいは、作業の開始から終了までの所要時間が最長のステップとして決定する。また、フォローシステムは、フォロー対象候補となる1つ以上のステップについての情報を、所要時間の長い順に優先順として一覧表示する画面を、担当部署またはユーザ等の端末に提供する、一覧表示機能を有する。本発明のうち代表的な形態によれば、従来技術を利用したインシデント解決時間短縮の課題を解決し、例えば復旧の遅延原因となった部署やユーザに復旧作業内容の改善を促すことで復旧時間を短縮すること等を実現できる。以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。本実施の形態のシステムインシデント管理運用システムは、図1のようなシステム全体構成において、監視センタ5インシデント管理システム10、フォローシステム30、運用端末6等及びデータセンタ1側の障害監視装置3等を含んで構成され、インシデント管理運用業務復旧作業支援等における復旧作業改善依頼自動送信機能フォロー機能、及び対処優先順作業一覧表示機能一覧表示機能を有する。フォロー機能としては、インシデント例えば監視対象機器2の障害の対処復旧作業などに関して、フォローシステム30から該当ユーザUインシデント管理者や復旧作業関係者などの運用端末6連絡先へ、復旧作業改善依頼のメール情報を自動的に送信することにより、該当ユーザUの復旧作業改善による復旧作業時間短縮を図る。それと共に、一覧表示機能としては、該当ユーザUの運用端末6の表示画面において復旧作業の一覧情報を対処の優先順で表示し、該当ユーザUが確認できることにより、復旧作業時間短縮を図る。[システム構成]図1において、本実施の形態のシステムインシデント管理運用システムを含んで成るシステム全体構成例を示している。本システムは、インシデント管理運用業務に係わる情報処理システムである。図1で、システム全体は、データセンタ1と監視センタ5が通信回線4で接続された構成である。データセンタ1は、監視対象システムであり、複数の監視対象機器2と、それらに接続される障害監視装置3とを有する。監視対象機器2は、サービス処理を提供するサーバ装置等である。障害監視装置3は、監視対象機器2の状態を監視して障害などを検知し障害情報監視情報を出力する。監視センタ5は、運用端末6と、インシデント管理システム10と、過去事例DB12と、インシデントDB20と、復旧作業改善フォローシステム30と、フォロー情報DB40と、を有する。インシデント管理システム10は、障害情報入力部11を有する。障害情報入力部11は、データセンタ1の障害監視装置3から通信回線4を介して障害情報監視情報を入力し、過去事例DB12に格納したり、インシデント情報をインシデントDB20インシデント情報21に格納する処理などを行う。その他、インシデント管理システム10は、インシデント管理者などのユーザU運用端末6に対してインシデントDB20の情報を画面で提供する処理などを行う。過去事例DB12は、データセンタ1監視対象機器2での障害情報の過去事例が格納されているデータベースである。インシデントDB20は、インシデント情報21例:図3、インシデント処理履歴情報22例:図4、発生元情報23例:図5、サービス情報24例:図6、等の情報テーブルを格納管理しているデータベースである。フォローシステム復旧作業改善フォローシステム30は、インシデントDB20及びフォロー情報DB40のデータ情報を用いて、インシデントに関する復旧作業等のステップ後述の最長ステップに係わるフォロー対象となる部署及びユーザU連絡先へ改善依頼メール50フォローメールを自動的に送信する処理を行う。また関連して、フォローシステム30は、該当ユーザU運用端末6に対し、改善対象となる復旧作業等のステップの一覧画面後述、図10を表示提供する処理を行う。フォロー情報DB40は、ステップ担当情報41例:図7、依頼定義情報42例:図8、等の情報テーブルを格納管理している。データセンタ1の障害監視装置3は、監視対象機器2で発生した障害を自動的に収集し、通信回線4経由でインシデント管理システム10に送信する。インシデント管理システム10の障害情報入力部11から当該障害情報を受信し、当該障害情報を過去事例DB12に照合し、適用可能な過去事例を判定する。そして、インシデント管理システム10障害情報入力部11は、判定済みの障害情報をインシデントとして、インシデントDB20のインシデント情報21のテーブルに格納する。ユーザUは、運用端末6を使用してインシデント管理運用業務を行う人であり、インシデント管理者、復旧作業関係者などであり、例えばサービスデスクのオペレータや、設計者などがいる。ユーザUは、運用端末6でインシデントインシデント管理システム10が管理しているインシデント情報を参照する。ユーザUは、インシデント管理のワークフロー例:図2に従い、ワークフロー上のステップに応じた作業を実施し、インシデントを解決し、サービスデータセンタ1の監視対象機器2で提供するサービスを復旧させる。そして、ワークフロー上の各ステップの開始時刻と終了時刻、担当部署などの情報が、インシデント処理履歴情報22に記録される。ワークフローステップ等の対応関係については図11にも示している。フォローシステム30は、例えば毎月1度、フォロー処理詳しくは後述、図9を実行する。このフォロー処理では、インシデント情報21のテーブルから前月のインシデントを取得し、インシデント処理履歴情報22のテーブルからインシデント処理履歴情報を取得し、インシデント毎にインシデント解決時間Taを算出する。この処理では、インシデントの発生元をキーに発生元情報23とサービス情報24を突き合わせ、サービス停止許容時間Tbを取得する。上記インシデント解決時間Taがサービス停止許容時間Tbを超過する場合、当該インシデントの解決の過程で経由した複数のステップのうちの所要時間が最長ステップをフォロー対象改善対象として取得する。そのフォロー対象ステップに関係付けられる担当部署とステップ名をキーにフォロー情報DB40内のステップ担当情報41のテーブルからフォロー先となる連絡先メールアドレスと依頼定義IDを取得する。取得した依頼定義IDが示すレコードを依頼定義情報42のテーブルから取得し、当該レコードに記載の件名と本文の定義情報を用いて作成した改善依頼メール50を当該フォロー先メールアドレスへ送信する。フォローシステム30は、上記フォローを実行したインシデントについて、改善対象ステップを記録する21,22等に反映。そして、フォローシステム30一覧表示機能は、上記データ情報を用いて、ユーザU運用端末6に提供する改善対象ステップ一覧画面図10を作成する。改善対象ステップを処理所要時間の降順で一覧表示する。ユーザUは運用端末6で画面を参照し、改善対象ステップなどを確認可能であり、改善実施に応じて情報を反映する。なお本実施の形態では、例えばインシデント管理システム10とフォローシステム30とが独立分離された構成を示しているが、これらを1つに統合した形態とすることもできるし、各機能処理部を各システムへ分離した形態とすることもできる。インシデント管理システム10及びフォローシステム30などの各システム各処理部は、サーバ装置プロセッサ、メモリ、ディスク、入力装置、出力装置、通信インタフェース装置、及びバスなどを備える構成などのソフトウェアプログラム処理などを用いて実装できる。例えば運用端末6はWebブラウザやメールクライアントのソフトウェアを備え、インシデント管理システム10及びフォローシステム30などが提供するWebページ画面を表示したりメールを受信して表示することができる。[インシデント管理のワークフロー]図2は、インシデント管理のワークフローの一例を示すs1等は処理ステップ。障害のインシデントに関し、復旧開始後、s1ワークフロー上の第1のステップとして、担当部署をサービスデスクとして一次解決を行うステップがある。s2インシデント解決の場合Yは終了する。s3ワークフロー上の第2のステップとして、設計部署設計者による原因調査のステップがある。s4ワークフロー上の第3のステップとして、設計部署設計者による対策のステップがある。本ワークフローに示すように、前述の過去事例に合致しサービスデスクだけで解決できる場合、一次解決のステップs1のみで当該インシデントを解決可能である。しかし、サービスデスクのみでは解決に至らない場合s2-N、該当サービス障害状態の監視対象機器2で提供するサービスを開発した設計部署設計者において、インシデントの原因調査のステップs3を実施した後、当該インシデントの対策のステップs4を実施する。[補足]図11は、補足として、発生元ホスト、サービス等、インシデント、ワークフローステップ、担当部署、担当者ユーザU、等の対応関係について示している。インシデントの発生元、ホスト、サービス等は、データセンタ1、監視対象機器2などに関係付けられる。インシデントは、ワークフローと関係付けられる。ワークフローは、1つ以上のステップ例えば1~Nと関係付けられる。ステップは例えば前述図2の一次解決、原因調査、対策などがある。各ステップは、担当部署や担当者ユーザUと関係付けられる。部署はサービスデスクや各設計部署などがあり、担当者は前述のサービスデスクのオペレータや、監視対象機器2そのソフトウェア等の設計者などがあり、それぞれ、連絡先メールアドレス等がある。各ステップは所要時間開始時刻から終了時刻までがある。例えば最長の時間を要したステップが改善対象ステップとなる。[インシデント情報]図3は、図1のインシデントDB20に存在するインシデント情報21のテーブル例を示す。本テーブルでは、インシデントID、発生元、発生時刻、メッセージ、ステータス、合致事例、フォロー有無、改善タスクID、改善実施、等の項目を有する。インシデントIDは、インシデントを一意に識別するための情報である。発生元は、ホストの識別情報などである。メッセージは、障害情報のメッセージ等である。ステータスは、インシデント解決の状況を示すステータス情報であり、値として完了,対策中などがある。合致事例は前述の過去事例DB12の参照による合致の事例を示す。フォロー有無は、フォローシステム30によるフォロー復旧作業改善依頼の有無を示す。改善タスクIDは、改善タスクの識別情報である22のタスクIDと対応。改善実施は、改善の実施のステータスであり、値として済/未などがある。[インシデント処理履歴情報]図4は、図1のインシデントDB20に存在するインシデント処理履歴情報22のテーブル例を示す。本テーブルでは、タスクID、インシデントID、ステップ名、担当部署、開始時刻、終了時刻、等の項目を有する。タスクIDは、タスクインシデント処理履歴を一意に識別する情報である。ステップ名は、タスク処理したステップ名である。担当部署は、当該タスクステップ等の担当部署名サービスデスクや設計A,B,Cなどである。開始時刻及び終了時刻は、当該タスクステップ等の開始時刻及び終了時刻である。[発生元情報]図5は、図1のインシデントDB20に存在する発生元情報23のテーブル例を示す。本テーブルでは、発生元ID、発生元名、サービスID、等の項目を有する。発生元IDは、発生元前記ホスト等を一意に識別する情報である。発生元名は、前記ホスト等の名である。サービスIDは、発生元のホストが提供するサービスの識別情報である。[サービス情報]図6は、図1のインシデントDB20に存在するサービス情報24のテーブル例を示す。本テーブルでは、サービスID、サービス停止許容時間、等の項目を有する。サービスIDは、23のサービスIDと同じである。サービス停止許容時間は、当該サービスにおける停止状態障害状態などの許容時間を示す。例えば、インシデント管理システム10は、インシデントの発生元情報23と、発生元ホスト等が提供するサービス情報24とを定義しておき、インシデントの発生の度にインシデント情報21をインシデントDB20に保存する。ユーザU関係者等は、運用端末6から、インシデント管理システム10の提供する画面で上記インシデントの内容を確認し、インシデント管理システム10が提供するワークフローに従い、インシデント解決までのステップ作業等を処理実施する。[ステップ担当情報]図7は、図1のフォロー情報DB40に存在するステップ担当情報41のテーブル例を示す。本テーブルでは、ステップ名、担当部署、メールアドレス、依頼定義ID、等の項目を有する。ステップ名は、フォロー対象候補となるステップ名である。担当部署は、当該ステップの担当部署を示す。メールアドレスは、フォロー先となるメールアドレス情報である。即ち、当該ステップの担当部署の担当者ユーザUへ送信するフォローメール50の送信先に用いるメールアドレスである。依頼定義IDは、フォローメール50に記載する件名と本文を含む依頼定義情報の識別情報である42と対応。[依頼定義情報]図8は、図1のフォロー情報DB40に存在する依頼定義情報42のテーブル例を示す。本テーブルでは、依頼定義ID、合致事例有無、件名、本文、等の項目を有する。依頼定義IDは、依頼定義情報のレコードを一意に識別する情報である。合致事例有無は、フォロー対象のインシデントの合致事例の有無を示す21と対応。件名、及び本文は、フォローメール50に記載するための件名と本文の情報である。図示のように、例えば、ステップや合致事例有無の違いに応じて、件名として、一次解決作業見直し依頼対策手順不適見直し依頼対策確立依頼などがある。上記ステップ担当情報41及び依頼定義情報42は、ステップ別、及び部署別に定義したフォロー内容情報を含んでいる。フォローシステム30その管理者等は、ステップを担当する部署毎の連絡先メールアドレスをステップ担当情報41に定義しておき、フォローメール50の件名と本文の定義情報を依頼定義情報42として定義しておく。[復旧作業改善依頼自動送信処理]図9のフローは、フォローシステム30フォロー機能により実行する、復旧作業改善依頼自動送信処理の一具体例を示す。S101等は処理ステップを示す。S101フォローシステム30は、月1回などのタイミングで、インシデントDB20のインシデント情報21図3から、前月に発生したインシデントの情報を取得読み込みする。S10230は、上記取得したインシデントの数だけ、インシデント毎に、S102~S115の間の処理を繰り返す。S10330は、完了しているステータス図3のインシデントかどうかを判定し、完了していない場合S103-Nは、次のインシデントを処理する。S10430は、インシデントID図3をキーに、インシデント処理履歴情報22図4を取得読み込みする。S10530は、インシデント解決時間Taを算出取得する。即ち、S104で取得した各処理履歴レコードにおける所要時間[終了時刻]-[開始時刻]の総和を、Taとして算出する。S10630は、発生元情報23図5、サービス情報24図6を参照して、インシデントの発生元が提供するサービスのサービス停止許容時間Tbを取得する。つまり、インシデントの発生元をキーに発生元情報23を検索してサービスIDを取得し、当該サービスIDでサービス情報24を検索してサービス停止許容時間Tbを取得する。S10730は、上記インシデント解決時間Taがサービス停止許容時間Tbを超過しているかどうかTa>Tbを判定する。超過していない場合Nは、次のインシデントの処理に移る。S10830は、上記取得したインシデント処理履歴の数だけ、インシデント処理履歴ごとに、S108~S110でS109の処理を繰り返す。S10930は、作業時間が最大のステップ図11を取得してフォロー対象ステップとする。即ち、所要時間[終了時刻]-[開始時刻]が最長のステップを取得する。S11130は、上記フォロー対象ステップのステップ名と担当部署の情報図4をもとに、ステップ担当情報41図7を検索して、フォロー対象作業改善依頼対象に対するフォローメール50のためのメールアドレス及び依頼定義IDの情報を取得する。S11230は、S111で取得した依頼定義IDをもとに依頼定義情報42からレコード依頼定義情報を取得する。S11330は、S111で取得したメールアドレス、S112で取得した依頼定義情報における件名と本文の情報によって、フォローメール作業改善依頼メール50を作成して送信する。S11430は、上記フォローを実施したインシデントについて、インシデント情報21のテーブル図3のフォロー有無、改善タスクIDの項目に情報あり、タスクIDを記録して更新する。改善タスクIDには、フォロー対象ステップとなったインシデント処理履歴22のレコードのタスクIDを記録する。S115S101で取得したインシデントの数だけ上記処理を繰り返したら処理を終了する。[画面]図10は、本システムフォローシステム30の一覧表示機能によりユーザU運用端末6に対して提供される、改善対象ステップ一覧画面の一例である。本画面では、上述した処理及び各データ情報に基づき、フォローシステム30が改善対象としてフォローしたステップに関する一覧情報を表示する。特に、複数のステップ対応するインシデント、タスクにおける処理所要時間が長いものから降順に、処理優先順対策優先度の順として表示する。前述図9のように、解決時間Taが許容時間Tbを超えたインシデントのワークフローのステップのうちの最長ステップに対応する情報が、本一覧の一番上に表示されることになる。前記フォロー内容情報41,42を利用して、複数の対象ステップを対処優先順に一覧表示する。図10中のテーブルでは、前述のデータ情報に基づき、例えば、インシデントID、ステップ名、担当部署、開始時刻、終了時刻、処理所要時間、改善実施、などの項目を表示している。また集計対象月の情報や、実施済みに変更ボタンなどを有する。フォロー機能によるフォローを受けてユーザUにより改善を実施したステップについては、例えば実施済みに変更ボタンによって、ステータスを未から済改善済みに変更する。例えば、インシデント管理者などのユーザUは、本画面の一覧の上部、優先度の高いものから順に見て確認し、例えばステータスが未のものについては改善検討部署設計者などのユーザUに対して作業状況等を確認することができる。同様に、設計者などのユーザUは、本画面で改善すべきステップ作業等を確認することができる。また本画面からインシデント情報21などの各データ情報の表示画面へ遷移して確認することもできる。[効果等]以上説明したように、本実施の形態のシステムでは、フォローシステム30等により、発生したインシデント情報21、インシデント処理履歴22、及びサービス停止許容時間の定義24などの情報を用いて、例えばインシデントごとに最多の時間を費やしたステップの担当部署関係者ユーザUに対して改善依頼情報50を自動送信するフォロー機能、並びに改善対象ステップ作業を対処の優先順に一覧形式で表示しユーザUにより確認操作可能とする機能を提供する。本システムでは、フォロー対象別に連絡先と連絡内容を定義しておき23,24、発生したインシデントの解決までの処理履歴を保存し22、これらのデータ情報に基づき、解決時間Taがサービス停止許容時間Tbを超過したインシデントの最多の時間を費やしたステップをフォロー対象として決定し、当該ステップの担当部署ユーザUに対して改善依頼情報50を自動送信する処理などを行う。これにより、例えばサービス復旧の遅延原因となった部署関係者ユーザUに復旧作業内容の改善を促してフォローすることで、サービス復旧時間を短縮すること等を実現できる。インシデント解決の遅延を減らすために、遅延原因部署が復旧作業内容を精査改善して復旧時間を短縮するプロセスを有する。本システムの機能インシデント解決時間分析とフォローの仕組みにより、当該プロセスへ作用し、当該プロセスを効率化することができる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。"