(57)【特許請求の範囲】
【請求項１】
情報処理システムを対象としてインシデント管理運用業務を行うためのインシデント管理運用システムであって、
前記インシデント管理運用業務は、前記情報処理システムで発生する障害を含むインシデントの解決及び対処のためのワークフローを含み、当該ワークフローは１つ以上のステップで構成され、各々のステップの作業は担当部署のユーザにより行われ、
前記インシデントのワークフローのステップの作業に関する改善依頼の情報を前記担当部署またはユーザに対して自動的に送信してフォローを図るフォロー機能を有するフォローシステムを有し、
上記フォロー対象とするステップは、解決時間が許容時間を越えるインシデントのステップ、及び、作業の開始から終了までの所要時間が最長のステップとし、
前記フォローシステムのフォロー機能は、インシデント情報と、前記ステップの所要時間の情報を含むインシデント処理履歴情報と、インシデントの発生元情報と、前記許容時間の情報を含むサービス情報と、前記ステップ、担当部署、及び連絡先の情報を含むステップ担当情報と、前記ステップ及び担当部署ごとに定義される前記改善依頼の情報を作成するための定義情報を含む依頼定義情報と、を用いて、前記フォロー対象ステップを決定し、前記改善依頼の情報を作成すること、を特徴とするインシデント管理運用システム。
【請求項２】
請求項１記載のインシデント管理運用システムにおいて、
前記フォローシステムは、前記フォロー対象となる１つ以上のステップについての情報を、所要時間の長い順に優先順として一覧表示する画面を、前記担当部署またはユーザの端末に提供する、一覧表示機能を有し、
前記フォローシステムの一覧表示機能は、前記インシデント情報と、前記ステップの所要時間の情報を含むインシデント処理履歴情報と、前記インシデントの発生元情報と、前記許容時間の情報を含むサービス情報と、前記ステップ、担当部署、及び連絡先の情報を含むステップ担当情報と、前記ステップ及び担当部署ごとに定義される前記改善依頼の情報を作成するための定義情報を含む依頼定義情報と、を用いて、前記フォロー対象ステップを決定し、前記一覧表示する画面を作成すること、を特徴とするインシデント管理運用システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システムのインシデント管理運用業務を行うためのインシデント管理運用システムの技術に関する。特に、インシデント管理運用業務における障害復旧作業時間の短縮を図る技術に関する。
【背景技術】
【０００２】
データセンタでは、お客様（顧客）から情報システム（顧客システム）を預かり、障害対応を含めた運用サービスを提供する、インシデント管理運用業務が存在する。運用サービスの提供者は、顧客システムで発生するインシデントを監視し、インシデントが発生した場合、サービスを迅速に復旧し、顧客業務への影響を最低限に止めなければならない。
【０００３】
発生したインシデントからサービスを早急に回復する仕組みに関する先行技術例として、特開２０１１−７６１６１号公報（特許文献１）などに記載のインシデント管理システムを適用する方法が考えられる。特許文献１では、発生したインシデントのメッセージ等から適用可能な過去事例（過去に発生したインシデントの対処と手順）を検索して提示し、適切かつ迅速な復旧作業を可能にするものである。
【０００４】
この仕組みで全インシデントに過去事例を適用して目標時間内にサービス復旧できれば良いが、実際には手順が疎かでサービスデスクでの復旧作業が困難であったり、システム設計部署に解決を依頼して復旧が遅れたりする場合がある。
【０００５】
このようなインシデント解決の遅延を減らすためには、遅延原因部署が復旧作業内容を精査・改善して、復旧時間を短縮するプロセスが不可欠である。
【０００６】
しかしながら、前述の技術を含む従来技術では、インシデント解決時間分析とフォローの仕組みを持たない。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２０１１−７６１６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述のように、従来技術の課題として、インシデント解決時間分析とフォローの仕組みを持たない点がある。復旧作業などのインシデント解決の遅延、及び改善不足などの問題がある。
【０００９】
そこで、本発明の主な目的は、従来技術を利用したインシデント解決時間短縮の課題を解決し、例えば復旧の遅延原因となった部署やユーザに復旧作業内容の改善を促すことで復旧時間を短縮すること等を実現できる技術を提供することである。
【課題を解決するための手段】
【００１０】
上記目的を達成するため、本発明のうち代表的な形態は、情報処理システム（顧客システム、データセンタ等）を対象としてインシデント管理運用業務を行うための情報処理システム（インシデント管理運用システム）等であって、以下に示す構成を有することを特徴とする。
【００１１】
本システムでは、特に、発生したインシデント情報、インシデント処理履歴、及びサービス停止許容時間の定義情報、フォロー対象別（ステップ別、部署別）の連絡先及び連絡内容（フォロー内容）の定義情報、などのデータ情報を用いて、解決の所要時間が大きいインシデントやそのステップ（作業）などを対象として、対応する担当部署やユーザに対して当該作業の改善依頼情報（フォロー情報）をメール等で自動的に作成して送信するフォロー機能（対応する復旧作業改善依頼自動送信方法等）、並びに、上記改善依頼情報を送信する対象（フォロー対象）となる１つ以上のステップ（作業）についての情報を、対処の優先順に一覧情報を表示する画面を作成して提供する一覧表示機能（対応する改善対象作業対処優先順一覧表示方法等）などを有する。上記フォロー対象は、例えば、１つのインシデントの解決に関わった複数のステップのうち、所要時間が最長のステップ、及び対応する担当部署などとして決定する。
【００１２】
本インシデント管理運用システムは、例えば、インシデントの作業のステップに関する改善依頼の情報を担当部署またはユーザ等に対して自動的に送信してフォローを図るフォロー機能を有するフォローシステムを有する。上記フォロー対象（候補）とするステップは、例えば、解決時間が許容時間を越えるインシデントのステップ、あるいは、作業の開始から終了までの所要時間が最長のステップとして決定する。また、フォローシステムは、フォロー対象（候補）となる１つ以上のステップについての情報を、所要時間の長い順に優先順として一覧表示する画面を、担当部署またはユーザ等の端末に提供する、一覧表示機能を有する。
【発明の効果】
【００１３】
本発明のうち代表的な形態によれば、従来技術を利用したインシデント解決時間短縮の課題を解決し、例えば復旧の遅延原因となった部署やユーザに復旧作業内容の改善を促すことで復旧時間を短縮すること等を実現できる。
【図面の簡単な説明】
【００１４】
【図１】本発明の一実施の形態のシステム（インシデント管理運用システム）を含んでなるシステム全体構成例を示す図である。
【図２】インシデント管理のワークフローの例を示す図である。
【図３】インシデント情報のテーブル例を示す図である。
【図４】インシデント処理履歴情報のテーブル例を示す図である。
【図５】発生元情報のテーブル例を示す図である。
【図６】サービス情報のテーブル例を示す図である。
【図７】ステップ担当情報のテーブル例を示す図である。
【図８】依頼定義情報のテーブル例を示す図である。
【図９】フォロー機能による作業改善依頼自動送信処理のフローを示す図である。
【図１０】一覧表示機能による改善対象ステップ一覧画面の例を示す図である。
【図１１】補足として、発生元、インシデント、ワークフロー（ステップ）、担当部署、担当者、等の対応関係について示す図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００１６】
本実施の形態のシステム（インシデント管理運用システム）は、図１のようなシステム全体構成において、監視センタ５（インシデント管理システム１０、フォローシステム３０、運用端末６等）及びデータセンタ１側の障害監視装置３等を含んで構成され、インシデント管理運用業務（復旧作業支援等）における復旧作業改善依頼自動送信機能（フォロー機能）、及び対処優先順作業一覧表示機能（一覧表示機能）を有する。フォロー機能としては、インシデント（例えば監視対象機器２の障害）の対処（復旧作業など）に関して、フォローシステム３０から該当ユーザＵ（インシデント管理者や復旧作業関係者など）の運用端末６（連絡先）へ、復旧作業改善依頼のメール（情報）を自動的に送信することにより、該当ユーザＵの復旧作業改善による復旧作業時間短縮を図る。それと共に、一覧表示機能としては、該当ユーザＵの運用端末６の表示画面において復旧作業の一覧情報を対処の優先順で表示し、該当ユーザＵが確認できることにより、復旧作業時間短縮を図る。
【００１７】
［システム構成］
図１において、本実施の形態のシステム（インシデント管理運用システム）を含んで成るシステム全体構成例を示している。本システムは、インシデント管理運用業務に係わる情報処理システムである。図１で、システム全体は、データセンタ１と監視センタ５が通信回線４で接続された構成である。
【００１８】
データセンタ１は、監視対象システムであり、複数の監視対象機器２と、それらに接続される障害監視装置３とを有する。監視対象機器２は、サービス処理を提供するサーバ装置等である。障害監視装置３は、監視対象機器２の状態を監視して障害などを検知し障害情報（監視情報）を出力する。
【００１９】
監視センタ５は、運用端末６と、インシデント管理システム１０と、過去事例ＤＢ１２と、インシデントＤＢ２０と、復旧作業改善フォローシステム３０と、フォロー情報ＤＢ４０と、を有する。
【００２０】
インシデント管理システム１０は、障害情報入力部１１を有する。障害情報入力部１１は、データセンタ１の障害監視装置３から通信回線４を介して障害情報（監視情報）を入力し、過去事例ＤＢ１２に格納したり、インシデント情報をインシデントＤＢ２０（インシデント情報２１）に格納する処理などを行う。その他、インシデント管理システム１０は、インシデント管理者などのユーザＵ（運用端末６）に対してインシデントＤＢ２０の情報を画面で提供する処理などを行う。
【００２１】
過去事例ＤＢ１２は、データセンタ１（監視対象機器２）での障害情報の過去事例が格納されているデータベースである。
【００２２】
インシデントＤＢ２０は、インシデント情報２１（例：図３）、インシデント処理履歴情報２２（例：図４）、発生元情報２３（例：図５）、サービス情報２４（例：図６）、等の情報（テーブル）を格納・管理しているデータベースである。
【００２３】
フォローシステム（復旧作業改善フォローシステム）３０は、インシデントＤＢ２０及びフォロー情報ＤＢ４０のデータ情報を用いて、インシデントに関する復旧作業等のステップ（後述の最長ステップ）に係わるフォロー対象となる部署及びユーザＵ（連絡先）へ改善依頼メール５０（フォローメール）を自動的に送信する処理を行う。また関連して、フォローシステム３０は、該当ユーザＵ（運用端末６）に対し、改善対象となる復旧作業等のステップの一覧画面（後述、図１０）を表示（提供）する処理を行う。
【００２４】
フォロー情報ＤＢ４０は、ステップ担当情報４１（例：図７）、依頼定義情報４２（例：図８）、等の情報（テーブル）を格納・管理している。
【００２５】
データセンタ１の障害監視装置３は、監視対象機器２で発生した障害を自動的に収集し、通信回線４経由でインシデント管理システム１０に送信する。インシデント管理システム１０の障害情報入力部１１から当該障害情報を受信し、当該障害情報を過去事例ＤＢ１２に照合し、適用可能な過去事例を判定する。そして、インシデント管理システム１０（障害情報入力部１１）は、判定済みの障害情報をインシデントとして、インシデントＤＢ２０のインシデント情報２１のテーブルに格納する。
【００２６】
ユーザＵは、運用端末６を使用してインシデント管理運用業務を行う人であり、インシデント管理者、復旧作業関係者などであり、例えばサービスデスクのオペレータや、設計者などがいる。ユーザＵは、運用端末６でインシデント（インシデント管理システム１０が管理しているインシデント情報）を参照する。ユーザＵは、インシデント管理のワークフロー（例：図２）に従い、ワークフロー上のステップに応じた作業を実施し、インシデントを解決し、サービス（データセンタ１の監視対象機器２で提供するサービス）を復旧させる。そして、ワークフロー上の各ステップの開始時刻と終了時刻、担当部署などの情報が、インシデント処理履歴情報２２に記録される。ワークフロー（ステップ）等の対応関係については図１１にも示している。
【００２７】
フォローシステム３０は、例えば毎月１度、フォロー処理（詳しくは後述、図９）を実行する。このフォロー処理では、インシデント情報２１のテーブルから前月のインシデントを取得し、インシデント処理履歴情報２２のテーブルからインシデント処理履歴情報を取得し、インシデント毎にインシデント解決時間（Ｔａ）を算出する。この処理では、インシデントの発生元をキーに発生元情報２３とサービス情報２４を突き合わせ、サービス停止許容時間（Ｔｂ）を取得する。上記インシデント解決時間（Ｔａ）がサービス停止許容時間（Ｔｂ）を超過する場合、当該インシデントの解決の過程で経由した複数のステップのうちの所要時間が最長ステップをフォロー対象（改善対象）として取得する。そのフォロー対象ステップに関係付けられる担当部署とステップ名をキーにフォロー情報ＤＢ４０内のステップ担当情報４１のテーブルからフォロー先となる連絡先（メールアドレス）と依頼定義ＩＤを取得する。取得した依頼定義ＩＤが示すレコードを依頼定義情報４２のテーブルから取得し、当該レコードに記載の件名と本文の定義情報を用いて作成した改善依頼メール５０を当該フォロー先メールアドレスへ送信する。フォローシステム３０は、上記フォローを実行したインシデントについて、改善対象ステップを記録する（２１，２２等に反映）。そして、フォローシステム３０（一覧表示機能）は、上記データ情報を用いて、ユーザＵ（運用端末６）に提供する改善対象ステップ一覧画面（図１０）を作成する。改善対象ステップを処理所要時間の降順で一覧表示する。ユーザＵは運用端末６で画面を参照し、改善対象ステップなどを確認可能であり、改善実施に応じて情報を反映する。
【００２８】
なお本実施の形態では、例えばインシデント管理システム１０とフォローシステム３０とが独立・分離された構成を示しているが、これらを１つに統合した形態とすることもできるし、各機能（処理部）を各システムへ分離した形態とすることもできる。
【００２９】
インシデント管理システム１０及びフォローシステム３０などの各システム・各処理部は、サーバ装置（プロセッサ、メモリ、ディスク、入力装置、出力装置、通信インタフェース装置、及びバスなどを備える構成）などのソフトウェアプログラム処理などを用いて実装できる。例えば運用端末６はＷｅｂブラウザやメールクライアントのソフトウェアを備え、インシデント管理システム１０及びフォローシステム３０などが提供するＷｅｂページ画面を表示したりメールを受信して表示することができる。
【００３０】
［インシデント管理のワークフロー］
図２は、インシデント管理のワークフローの一例を示す（ｓ１等は処理ステップ）。障害のインシデントに関し、復旧開始後、（ｓ１）ワークフロー上の第１のステップとして、担当部署をサービスデスクとして一次解決を行うステップがある。（ｓ２）インシデント解決の場合（Ｙ）は終了する。（ｓ３）ワークフロー上の第２のステップとして、設計部署（設計者）による原因調査のステップがある。（ｓ４）ワークフロー上の第３のステップとして、設計部署（設計者）による対策のステップがある。本ワークフローに示すように、前述の過去事例に合致しサービスデスクだけで解決できる場合、一次解決のステップ（ｓ１）のみで当該インシデントを解決可能である。しかし、サービスデスクのみでは解決に至らない場合（ｓ２−Ｎ）、該当サービス（障害状態の監視対象機器２で提供するサービス）を開発した設計部署（設計者）において、インシデントの原因調査のステップ（ｓ３）を実施した後、当該インシデントの対策のステップ（ｓ４）を実施する。
【００３１】
［補足］
図１１は、補足として、発生元（ホスト、サービス等）、インシデント、ワークフロー（ステップ）、担当部署、担当者（ユーザＵ）、等の対応関係について示している。インシデントの発生元、ホスト、サービス等は、データセンタ１、監視対象機器２などに関係付けられる。インシデントは、ワークフローと関係付けられる。ワークフローは、１つ以上のステップ（例えば＃１〜＃Ｎ）と関係付けられる。ステップは例えば前述（図２）の一次解決、原因調査、対策などがある。各ステップは、担当部署や担当者（ユーザＵ）と関係付けられる。部署はサービスデスクや各設計部署などがあり、担当者は前述のサービスデスクのオペレータや、監視対象機器２（そのソフトウェア等）の設計者などがあり、それぞれ、連絡先（メールアドレス等）がある。各ステップは所要時間（開始時刻から終了時刻まで）がある。例えば最長の時間を要したステップが改善対象ステップとなる。
【００３２】
［インシデント情報］
図３は、図１のインシデントＤＢ２０に存在するインシデント情報２１のテーブル例を示す。本テーブルでは、インシデントＩＤ、発生元、発生時刻、メッセージ、ステータス、合致事例、フォロー有無、改善タスクＩＤ、改善実施、等の項目を有する。インシデントＩＤは、インシデントを一意に識別するための情報である。発生元は、ホストの識別情報などである。メッセージは、障害情報のメッセージ等である。ステータスは、インシデント解決の状況を示すステータス情報であり、値として完了，対策中などがある。合致事例は前述の過去事例ＤＢ１２の参照による合致の事例を示す。フォロー有無は、フォローシステム３０によるフォロー（復旧作業改善依頼）の有無を示す。改善タスクＩＤは、改善タスクの識別情報である（２２のタスクＩＤと対応）。改善実施は、改善の実施のステータスであり、値として済／未などがある。
【００３３】
［インシデント処理履歴情報］
図４は、図１のインシデントＤＢ２０に存在するインシデント処理履歴情報２２のテーブル例を示す。本テーブルでは、タスクＩＤ、インシデントＩＤ、ステップ名、担当部署、開始時刻、終了時刻、等の項目を有する。タスクＩＤは、タスク（インシデント処理履歴）を一意に識別する情報である。ステップ名は、タスク処理したステップ名である。担当部署は、当該タスク（ステップ等）の担当部署名（サービスデスクや設計Ａ，Ｂ，Ｃなど）である。開始時刻及び終了時刻は、当該タスク（ステップ等）の開始時刻及び終了時刻である。
【００３４】
［発生元情報］
図５は、図１のインシデントＤＢ２０に存在する発生元情報２３のテーブル例を示す。本テーブルでは、発生元ＩＤ、発生元名、サービスＩＤ、等の項目を有する。発生元ＩＤは、発生元（前記ホスト等）を一意に識別する情報である。発生元名は、前記ホスト等の名である。サービスＩＤは、発生元のホストが提供するサービスの識別情報である。
【００３５】
［サービス情報］
図６は、図１のインシデントＤＢ２０に存在するサービス情報２４のテーブル例を示す。本テーブルでは、サービスＩＤ、サービス停止許容時間、等の項目を有する。サービスＩＤは、２３のサービスＩＤと同じである。サービス停止許容時間は、当該サービスにおける停止状態（障害状態など）の許容時間を示す。
【００３６】
例えば、インシデント管理システム１０は、インシデントの発生元情報２３と、発生元（ホスト等）が提供するサービス情報２４とを定義しておき、インシデントの発生の度にインシデント情報２１をインシデントＤＢ２０に保存する。ユーザＵ（関係者等）は、運用端末６から、インシデント管理システム１０の提供する画面で上記インシデントの内容を確認し、インシデント管理システム１０が提供するワークフローに従い、インシデント解決までのステップ（作業等）を処理（実施）する。
【００３７】
［ステップ担当情報］
図７は、図１のフォロー情報ＤＢ４０に存在するステップ担当情報４１のテーブル例を示す。本テーブルでは、ステップ名、担当部署、メールアドレス、依頼定義ＩＤ、等の項目を有する。ステップ名は、フォロー対象（候補）となるステップ名である。担当部署は、当該ステップの担当部署を示す。メールアドレスは、フォロー先となるメールアドレス情報である。即ち、当該ステップの担当部署の担当者（ユーザＵ）へ送信するフォローメール５０の送信先に用いるメールアドレスである。依頼定義ＩＤは、フォローメール５０に記載する件名と本文を含む依頼定義情報の識別情報である（４２と対応）。
【００３８】
［依頼定義情報］
図８は、図１のフォロー情報ＤＢ４０に存在する依頼定義情報４２のテーブル例を示す。本テーブルでは、依頼定義ＩＤ、合致事例有無、件名、本文、等の項目を有する。依頼定義ＩＤは、依頼定義情報のレコードを一意に識別する情報である。合致事例有無は、フォロー対象のインシデントの合致事例の有無を示す（２１と対応）。件名、及び本文は、フォローメール５０に記載するための件名と本文の情報である。図示のように、例えば、ステップや合致事例有無の違いに応じて、件名として、「一次解決作業見直し依頼」「対策手順不適  見直し依頼」「対策確立依頼」などがある。
【００３９】
上記ステップ担当情報４１及び依頼定義情報４２は、ステップ別、及び部署別に定義したフォロー内容情報を含んでいる。フォローシステム３０（その管理者等）は、ステップを担当する部署毎の連絡先（メールアドレス）をステップ担当情報４１に定義しておき、フォローメール（５０）の件名と本文の定義情報を依頼定義情報４２として定義しておく。
【００４０】
［復旧作業改善依頼自動送信処理］
図９のフローは、フォローシステム３０（フォロー機能）により実行する、復旧作業改善依頼自動送信処理の一具体例を示す。Ｓ１０１等は処理ステップを示す。
【００４１】
（Ｓ１０１）  フォローシステム３０は、月１回などのタイミングで、インシデントＤＢ２０のインシデント情報２１（図３）から、前月に発生したインシデントの情報を取得（読み込み）する。
【００４２】
（Ｓ１０２）  ３０は、上記取得したインシデントの数だけ、インシデント毎に、Ｓ１０２〜Ｓ１１５の間の処理を繰り返す。
【００４３】
（Ｓ１０３）  ３０は、完了しているステータス（図３）のインシデントかどうかを判定し、完了していない場合（Ｓ１０３−Ｎ）は、次のインシデントを処理する。
【００４４】
（Ｓ１０４）  ３０は、インシデントＩＤ（図３）をキーに、インシデント処理履歴情報２２（図４）を取得（読み込み）する。
【００４５】
（Ｓ１０５）  ３０は、インシデント解決時間（Ｔａ）を算出（取得）する。即ち、Ｓ１０４で取得した各処理履歴（レコード）における所要時間（［終了時刻］−［開始時刻］）の総和を、Ｔａとして算出する。
【００４６】
（Ｓ１０６）  ３０は、発生元情報２３（図５）、サービス情報２４（図６）を参照して、インシデントの発生元が提供するサービスのサービス停止許容時間（Ｔｂ）を取得する。つまり、インシデントの発生元をキーに発生元情報２３を検索してサービスＩＤを取得し、当該サービスＩＤでサービス情報２４を検索してサービス停止許容時間（Ｔｂ）を取得する。
【００４７】
（Ｓ１０７）  ３０は、上記インシデント解決時間（Ｔａ）がサービス停止許容時間（Ｔｂ）を超過しているかどうか（Ｔａ＞Ｔｂ）を判定する。超過していない場合（Ｎ）は、次のインシデントの処理に移る。
【００４８】
（Ｓ１０８）  ３０は、上記取得したインシデント処理履歴の数だけ、インシデント処理履歴ごとに、Ｓ１０８〜Ｓ１１０でＳ１０９の処理を繰り返す。
【００４９】
（Ｓ１０９）  ３０は、作業時間が最大のステップ（図１１）を取得してフォロー対象ステップとする。即ち、所要時間（［終了時刻］−［開始時刻］）が最長のステップを取得する。
【００５０】
（Ｓ１１１）  ３０は、上記フォロー対象ステップのステップ名と担当部署の情報（図４）をもとに、ステップ担当情報４１（図７）を検索して、フォロー対象（作業改善依頼対象）に対するフォローメール５０のためのメールアドレス及び依頼定義ＩＤの情報を取得する。
【００５１】
（Ｓ１１２）  ３０は、Ｓ１１１で取得した依頼定義ＩＤをもとに依頼定義情報４２からレコード（依頼定義情報）を取得する。
【００５２】
（Ｓ１１３）  ３０は、Ｓ１１１で取得したメールアドレス、Ｓ１１２で取得した依頼定義情報における件名と本文の情報によって、フォローメール（作業改善依頼メール）５０を作成して送信する。
【００５３】
（Ｓ１１４）  ３０は、上記フォローを実施したインシデントについて、インシデント情報２１のテーブル（図３）のフォロー有無、改善タスクＩＤの項目に情報（あり、タスクＩＤ）を記録して更新する。改善タスクＩＤには、フォロー対象ステップとなったインシデント処理履歴（２２）のレコードのタスクＩＤを記録する。
【００５４】
（Ｓ１１５）  Ｓ１０１で取得したインシデントの数だけ上記処理を繰り返したら処理を終了する。
【００５５】
［画面］
図１０は、本システム（フォローシステム３０）の一覧表示機能によりユーザＵ（運用端末６）に対して提供される、改善対象ステップ一覧画面の一例である。本画面では、上述した処理及び各データ情報に基づき、フォローシステム３０が改善対象としてフォローしたステップに関する一覧情報を表示する。特に、複数のステップ（対応するインシデント、タスク）における処理所要時間が長いものから降順に、処理優先順（対策優先度の順）として表示する。前述（図９）のように、解決時間（Ｔａ）が許容時間（Ｔｂ）を超えたインシデントのワークフローのステップのうちの最長ステップに対応する情報が、本一覧の一番上に表示されることになる。前記フォロー内容情報（４１，４２）を利用して、複数の対象ステップを対処優先順に一覧表示する。
【００５６】
図１０中のテーブルでは、前述のデータ情報に基づき、例えば、インシデントＩＤ、ステップ名、担当部署、開始時刻、終了時刻、処理所要時間、改善実施、などの項目を表示している。また集計対象月の情報や、「実施済みに変更」ボタンなどを有する。
【００５７】
フォロー機能によるフォローを受けてユーザＵにより改善を実施したステップについては、例えば「実施済みに変更」ボタンによって、ステータスを“未”から“済”（改善済み）に変更する。例えば、インシデント管理者などのユーザＵは、本画面の一覧の上部、優先度の高いものから順に見て確認し、例えばステータスが“未”のものについては改善検討部署（設計者などのユーザＵ）に対して作業状況等を確認することができる。同様に、設計者などのユーザＵは、本画面で改善すべきステップ（作業等）を確認することができる。また本画面からインシデント情報２１などの各データ情報の表示画面へ遷移して確認することもできる。
【００５８】
［効果等］
以上説明したように、本実施の形態のシステムでは、フォローシステム３０等により、発生したインシデント情報（２１）、インシデント処理履歴（２２）、及びサービス停止許容時間の定義（２４）などの情報を用いて、例えばインシデントごとに最多の時間を費やしたステップの担当部署・関係者（ユーザＵ）に対して改善依頼情報（５０）を自動送信するフォロー機能、並びに改善対象ステップ（作業）を対処の優先順に一覧形式で表示しユーザＵにより確認・操作可能とする機能を提供する。本システムでは、フォロー対象別に連絡先と連絡内容を定義しておき（２３，２４）、発生したインシデントの解決までの処理履歴を保存し（２２）、これらのデータ情報に基づき、解決時間（Ｔａ）がサービス停止許容時間（Ｔｂ）を超過したインシデントの最多の時間を費やしたステップをフォロー対象として決定し、当該ステップの担当部署（ユーザＵ）に対して改善依頼情報（５０）を自動送信する処理などを行う。
【００５９】
これにより、例えばサービス復旧の遅延原因となった部署・関係者（ユーザＵ）に復旧作業内容の改善を促してフォローすることで、サービス復旧時間を短縮すること等を実現できる。インシデント解決の遅延を減らすために、遅延原因部署が復旧作業内容を精査・改善して復旧時間を短縮するプロセスを有する。本システムの機能（インシデント解決時間分析とフォローの仕組み）により、当該プロセスへ作用し、当該プロセスを効率化することができる。
【００６０】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【００６１】
本発明は、データセンタ等を対象とした監視センタ、アウトソーシングサービスにおけるインシデント管理運用システム、障害対応業務支援システムなどに利用可能である。
【符号の説明】
【００６２】
１…データセンタ、２…監視対象機器、３…障害監視装置、４…通信回線、５…監視センタ、６…運用端末、１０…インシデント管理システム、１１…障害情報入力部、１２…過去事例ＤＢ、２０…インシデントＤＢ、２１…インシデント情報、２２…インシデント処理履歴情報、２３…発生元情報、２４…サービス情報、３０…復旧作業改善フォローシステム、４０…フォロー情報ＤＢ、４１…ステップ担当情報、４２…依頼定義情報、５０…改善依頼メール。
【図１】
0005596663.tif 000002
【図２】
0005596663.tif 000003
【図３】
0005596663.tif 000004
【図４】
0005596663.tif 000005
【図５】
0005596663.tif 000006
【図６】
0005596663.tif 000007
【図７】
0005596663.tif 000008
【図８】
0005596663.tif 000009
【図９】
0005596663.tif 000010
【図１０】
0005596663.tif 000011
【図１１】
0005596663.tif 000012