(57)【要約】  【課題】従来の運用管理通知支援技術では、障害への対処レベルを考慮した動的な対処要員配置が行えず、対処要員の勤務実態に合わせた的確な連絡ができず、非対処要員の協力を得る連絡方法がとれていない、という課題があった。  【解決手段】運用管理者向け通知情報および関連環境情報に基づいて、対処の重要度および緊急度の指標である対処レベルを決定する対処レベル決定手段と、前記対処レベルおよび対処要員情報に基づいて対処要員を選定する対処要員選定手段と、対処要員毎に、その要員属性情報に基づいて通知メディアを選定する通知メディア選定手段と、前記選定された通知メディアを用いて対処要員向け通知情報を生成する対処要員向け通知情報生成手段と、前記対処要員向け通知情報を前記通知メディアで前記選定された対処要員に通知する通知手段と、を有することにより、これら課題が解決される。【選択図】図１
2005276068.tif 000002
【特許請求の範囲】
【請求項１】
運用中の情報システムを監視して運用管理者向け通知情報を発生する運用管理機能部を有する前記情報システムから、前記運用管理者向け通知情報を取得してこれを適切な対処要員に伝える運用管理通知支援システムであって、
前記運用管理者向け通知情報および関連環境情報に基づいて、対処の重要度および緊急度の指標である対処レベルを決定する対処レベル決定手段と、
前記運用管理者向け通知情報および前記対処レベルおよび対処要員情報に基づいて対処要員を選定する対処要員選定手段と、
前記対処要員選定手段が選定した１以上の複数の対処要員毎に、前記運用管理者向け通知情報および前記選定された対処要員の要員属性情報に基づいて通知メディアを選定する通知メディア選定手段と、
前記選定された通知メディアを用いて前記選定された対処要員に通知するための対処要員向け通知情報を生成する対処要員向け通知情報生成手段と、
前記対処要員向け通知情報を前記通知メディアで前記選定された対処要員に通知する通知手段と、
を有することを特徴とする運用管理通知支援システム。
【請求項２】
前記関連環境情報として前記情報システムに係る業務サービス別スケジュール別重要度情報を含み、前記対処レベル決定手段は前記業務サービス別スケジュール別重要度情報を用いて対処レベルを決定することを特徴とする請求項１記載の運用管理通知支援システム。
【請求項３】
前記関連環境情報として社会事象、経済事象、天候のそれぞれ単独、又は２以上の複数の事象の影響を含む前記情報システムに係る動的考慮情報を含み、前記対処レベル決定手段は前記動的考慮情報を用いて対処レベルを決定することを特徴とする請求項１乃至２記載の運用管理通知支援システム。
【請求項４】
前記対処要員選定手段は前記対処要員の勤務情報を用いて適切な対処要員を選定することを特徴とする請求項１乃至３記載の運用管理通知支援システム。
【請求項５】
前記通知メディア選定手段は前記対処要員の勤務情報を用いて適切な通知メディアを選定することを特徴とする請求項１乃至４記載の運用管理通知支援システム。
【請求項６】
前記通知メディアとして、前記対処要員に係る施設内への館内放送を含むことを特徴とする請求項１乃至５記載の運用管理通知支援システム。
【請求項７】
前記通知手段は、通知された前記対処要員が着手したことをメール、或いは運用管理通知支援システムに接続された入力装置からの通知を受けたら通知解除し、所定時間後に通知が無い場合は他の対処要員にも知らせることを特徴とする請求項１乃至６記載の運用管理通知支援システム。
【請求項８】
運用中の情報システムを監視して運用管理者向け通知情報を発生する運用管理機能部を有する前記情報システムから、前記運用管理者向け通知情報を取得してこれを適切な対処要員に伝える運用管理通知支援方法であって、
前記運用管理者向け通知情報および関連環境情報に基づいて、対処の重要度および緊急度の指標である対処レベルを決定する対処レベル決定段階と、
前記運用管理者向け通知情報および前記対処レベルおよび対処要員情報に基づいて対処要員を選定する対処要員選定段階と、
前記対処要員選定手段が選定した１以上の複数の対処要員毎に、前記対処要員向け通知情報および前記選定された対処要員の要員属性情報に基づいて通知メディアを選定する通知メディア選定段階と、
前記選定された通知メディアを用いて前記選定された対処要員に通知するための対処要員向け通知情報を生成する対処要員向け通知情報生成段階と、
前記対処要員向け通知情報を前記通知メディアで前記選定された対処要員に通知する通知段階と、
を有することを特徴とする運用管理通知支援方法。
【請求項９】
運用中の情報システムを監視して運用管理者向け通知情報を発生する運用管理機能部を有する前記情報システムから、前記運用管理者向け通知情報を取得してこれを適切な対処要員に伝える情報処理をコンピュータに行わせる運用管理通知支援プログラムであって、
前記運用管理者向け通知情報および関連環境情報に基づいて、対処の重要度および緊急度の指標である対処レベルを決定する対処レベル決定段階と、
前記運用管理者向け通知情報および前記対処レベルおよび対処要員情報に基づいて対処要員を選定する対処要員選定段階と、
前記対処要員選定手段が選定した１以上の複数の対処要員毎に、前記対処要員向け通知情報および前記選定された対処要員の要員属性情報に基づいて通知メディアを選定する通知メディア選定段階と、
前記選定された通知メディアを用いて前記選定された対処要員に通知するための対処要員向け通知情報を生成する対処要員向け通知情報生成段階と、
前記対処要員向け通知情報を前記通知メディアで前記選定された対処要員に通知する通知段階と、
をコンピュータに実行させることを特徴とする運用管理通知支援プログラム。
【請求項１０】
運用中の情報システムを監視して運用管理者向け通知情報を発生する運用管理機能部を有する前記情報システムから、前記運用管理者向け通知情報を取得してこれを適切な対処要員に伝える情報処理をコンピュータに行わせる運用管理通知支援プログラムを記録したコンピュータ読み取り可能な記録媒体であって、
前記運用管理者向け通知情報および関連環境情報に基づいて、対処の重要度および緊急度の指標である対処レベルを決定する対処レベル決定段階と、
前記運用管理者向け通知情報および前記対処レベルおよび対処要員情報に基づいて対処要員を選定する対処要員選定段階と、
前記対処要員選定手段が選定した１以上の複数の対処要員毎に、前記対処要員向け通知情報および前記選定された対処要員の要員属性情報に基づいて通知メディアを選定する通知メディア選定段階と、
前記選定された通知メディアを用いて前記選定された対処要員に通知するための対処要員向け通知情報を生成する対処要員向け通知情報生成段階と、
前記対処要員向け通知情報を前記通知メディアで前記選定された対処要員に通知する通知段階と、
をコンピュータに実行させることを特徴とする運用管理通知支援プログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報システムの運用管理技術に関するものであり、特に、情報システムの異常時に運用管理者が適切な対処要員を迅速に選定し通知する運用管理通知支援技術に関するものである。
【背景技術】
【０００２】
あらゆる産業や個人生活のＩＴ化がますます進展しつつある現在、情報システムの運用管理の重要性もますます高まっている。情報システムの運用中に発生するハード／ソフトの障害は公知の運用管理システムによって検知され、運用管理者に伝えられるので、運用管理者はそれを対処する対処要員に迅速に通知する必要がある。しかし、情報システムの巨大化に伴い、その障害種類も多く、対処要員のスキル種類も多様になり、従来のように運用管理者が連絡先をその都度考えて連絡するのではダウン時間の増大が避けられず、ビジネスの根幹を担うような情報システムの場合は、その損害と影響とは非常に深刻なものがある。
【０００３】
このため、公知の運用管理システムとその対処要員への通知システムとを接続する運用管理通知支援システムが考えられてきた。例えば、下記特許文献１に示す『携帯端末を利用した保守情報通知方法』では、ネットワークの運用管理システム（本文献ではネットワーク管理システムＮＭＳ）の提示する障害の種類に応じて、あらかじめ設定された通知先の携帯端末に、電話、電子メールといった通知メディアによって自動通報する運用管理通知支援システム（本文献では保守情報提供サーバ）技術が開示されている。また、下記特許文献２の『障害通知システム』では、業務処理を行う情報システム上の業務の異常終了を検知する運用管理システム（本文献では監視用コンピュータシステム）からの業務障害通知を、あらかじめ設定されたポケットベル、電子メール、インターネット接続端末等の各種通知メディアで対処要員に通知する運用管理通知支援システム（本文献では業務障害通知部）が開示されている。
【特許文献１】特開２００２−０３３７３１号公報
【特許文献２】特開２００１−１６００２９号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上記特許文献に示される情報システムの運用管理および障害対処は、当該情報システムを所有する企業が自社で雇用する情報システム部門内の対処要員でまかなわれる体制が念頭に置かれているように見受けられる。そのような情報システムにおいては連絡すべき対処要員の種類および人数は比較的限られており、上記特許文献のように通知先（対処要員）はあらかじめ想定される障害に対して前もって静的に定めておくことができ、その範囲で、上記文献の技術の有効性が理解される。
【０００５】
しかしながら、上記背景技術に述べたＩＴの進展に伴い、企業内情報システムは巨大化かつ複雑化してきており、少なからぬ企業において、自社が自分のビジネスの本業に用いる情報システムの設計や運用をみずから行うよりも、外部にアウトソーシングする方がより経営合理的であると考えるに至った。そしてそのアウトソーシング需要に応えることを一つのビジネス（アウトソーシング事業）とするアウトソーシング事業者が出現するようになってきた。このようなアウトソーシング事業者では、顧客情報システムの運用管理が事業そのものであり、多種顧客システムに対して多数の対処要員を抱えている。このように、多数の対処要員が多種の情報システムの対処に当たるような場合では、上記従来技術の運用管理通知支援方法では次のような問題点が明らかとなる。
【０００６】
・  システム運用を請け負うアウトソーシングビジネスにおいて、障害に対処する対処要員は重要であり、常に多数の要員が待機している。常に復旧時間を最短にするために大勢の対処要員を障害復旧に割り当てて派遣することは理想であるが、すべての障害にそのように手厚い対処を行うほどに対処要員を豊富に抱えることはアウトソーシングビジネスの採算上困難である。そもそも、運用管理対象の情報システムは、その規模やサービス内容、アウトソーシング事業者と顧客とのサービスレベル契約（ＳＬＡ）等はまちまちである。顧客システムのダウンが顧客に与える損害額（ひいてはペナルティ支払額）が異なるケースもあるし、ある種のシステムでは障害発生の時間帯や障害時点の天候によって、ダウンの影響範囲が左右される。よって個々の障害発生に対して、そのダウン時間の与える影響（損害）は異なるので、個々の障害に必要な対処レベル（重要度、緊急度など）を見定めて、動的に適正な対処要員の派遣を図ることが合理的である。上記のように個々の障害に対して、その対処レベルに影響する環境条件が存在するが、本明細書ではこれを関連環境情報と呼ぶことにする。上記特許文献１，２のように、あらかじめ静的に対処要員を定めるシステムでは、このような関連環境情報を考慮することができないので、このような動的な対処要員配置の必要性が満たされていない。
【０００７】
・  対処要員は本拠地（例えばインターネットデータセンタ）に待機するばかりでなく、スケジュールを決めて顧客オフィスや顧客システムサイトに常駐したりして、待機中にシステム開発等の別の業務を受け持つことも多い。従来技術では、このように対処要員の連絡先が一定でない時に連絡が的確になされないことが懸念される。
【０００８】
・  従来技術では単に対処要員個人への通知にとどまり、非対処要員の協力を得ることができない。特に急を要する障害の場合には、非対処要員の協力も得られるような通知方法が望まれる。
【課題を解決するための手段】
【０００９】
従来の運用管理通知支援技術では、障害への対処レベルを考慮した動的な対処要員配置が行えない、という前記課題は、図1および図２に示す如く、運用中の情報システムISを監視して運用管理者向け通知情報OM-infを発生する運用管理機能部OMFを有する前記情報システムISから、前記運用管理者向け通知情報OM-infを取得してこれを適切な対処要員APに伝える運用管理通知支援システムであって、前記運用管理者向け通知情報OM-infおよび関連環境情報(例1：業務サービス別スケジュール別重要度情報)(例2：天候などの動的考慮情報)C-infに基づいて、対処の重要度および緊急度の指標である対処レベルA-levelを決定する対処レベル決定手段1と、前記運用管理者向け通知情報OM-infおよび前記対処レベルA-levelおよび対処レベル要員決定ロジック(対処要員情報)221に基づいて対処要員APを選定する対処要員選定手段2と、前記対処要員選定手段2が選定した1以上の複数の対処要員AP毎に、前記運用管理者向け通知情報OM-infおよび前記選定された対処要員APの要員属性情報Pp-infに基づいて通知メディアCMedを選定する通知メディア選定手段3と、前記選定された通知メディア(id=CMed1,..,CMedn)を用いて前記選定された対処要員(id=APx,…,APy)に通知するための対処要員向け通知情報AP-infを生成する対処要員向け通知情報生成手段4と、前記対処要員向け通知情報AP-infを前記通知メディアCMedで前記選定された対処要員(id=APx,…,APy)に通知する通知手段5と、を有することを特徴とする運用管理通知支援システムによって解決される。
【００１０】
すなわち、本発明の運用管理通知支援システムでは、対処レベル決定手段1が個々の障害通知を受けるつど、関連環境情報(例1：業務サービス別スケジュール別重要度情報)(例2：天候などの動的考慮情報)C-infを参照して、動的に当該障害への対処レベルA-levelを決定して、これをもとに対処要員選定手段2が対処要員APの人数や人選を動的に行うので、障害への対処レベルを考慮した動的な対処要員配置が行える。
【００１１】
また、従来の運用管理通知支援技術では対処要員の勤務実態に合わせた的確な連絡ができない、という前記課題は、図7および図8に示す如く、更に、前記対処要員選定手段2が前記対処要員APの勤務情報（勤務実績・予定データW-data）を用いて適切な対処要員APを選定する運用管理通知支援システムによって解決される。また、図13および図14に示す如く、更に、前記通知メディア選定手段3が前記対処要員の勤務情報(勤務実績・予定データW-data)を用いて適切な通知メディア(id=CMed1,..,CMedn)を選定する運用管理通知支援システムによって解決される。
【００１２】
すなわち、本発明の対処要員選定手段2は対処要員APの勤務情報（勤務実績・予定データW-data）を用いて適切な対処要員APを選定し、通知メディア選定手段3は対処要員APの勤務情報（勤務実績・予定データW-data）を用いて適切な通知メディア(id=CMed1,..,CMedn)を選定するので、対処要員の勤務実態に合わせた的確な選定、通知を行うことが出来る。
【００１３】
また、従来の運用管理通知支援技術では非対処要員の協力を得る連絡方法がとれていない、という前記課題は、図１に示す如く、更に、前記通知メディア(id=CMed1,..,CMedn)として、前記対処要員(id=APx,…,APy)に係る施設内への館内放送を含む運用管理通知支援システムによって解決される。
【００１４】
すなわち、施設内への館内放送によって、選定された対処要員(id=APx,…,APy)が呼び出されていることは当該施設内の非対処要員にも知らされ、非対処要員の協力を得る連絡方法となり、さらに連絡が徹底され迅速な通知がなされ得る。
【発明の効果】
【００１５】
本発明の運用管理通知支援システムによれば、関連環境情報を参照して動的に当該障害への対処レベルを決定して、これをもとに対処要員の人数や人選を動的に行うので、障害への対処レベルを考慮した動的な対処要員配置が行える、という効果がある。また、対処要員の勤務実績・予定データを用いて、対処要員の勤務場所に適切な通知メディアを用いて通知するので、対処要員の勤務実態に合わせた的確な選定、通知を行うことが出来る、という効果がある。また、通知メディアとして、対処要員に係る施設内への館内放送を含むことにより、非対処要員の協力を得る連絡方法が可能である、という効果がある。
【発明を実施するための最良の形態】
【００１６】
本発明の運用管理通知支援システムの実施例を図１〜図19により説明する。なお、本発明におけるコンピュータ処理は、当該コンピュータの主記憶装置上に展開されたコンピュータプログラムにより実行されるが、このコンピュータプログラムの提供形態は、当該コンピュータに接続された補助記憶装置をはじめ、ＣＤ−ＲＯＭ等の可搬型記憶装置やネットワーク接続された他のコンピュータの主記憶装置及び補助記憶装置等の各記録媒体に格納されて提供されるもので、このコンピュータプログラムの実行に際しては、当該コンピュータの主記憶装置上にローディングされ実行されるものである。
【実施例１】
【００１７】
図１に本発明の運用管理通知支援システムの第１の実施例を示す。本実施例の運用管理通知支援システムは、外部情報システムISから運用管理者向け通知情報OM-infを受け、かつ外部から関連環境情報(例1：業務サービス別スケジュール別重要度情報)(例2：天候などの動的考慮情報)C-infを受け、かつ外部の要員勤怠管理システムから勤務実績・予定データW-dataおよび要員属性情報Pp-infを受ける。そして外部の通知システムに対して通知メディアID(CMed-id)および対処要員向け通知情報AP-infを出力し、これによって通知システムが選択された通知メディア(id=CMed1,..,CMedn)を通じて選択された対処要員(id=APx,…,APy)への通知を行う。
【００１８】
本実施例では、運用管理通知支援システムは図1のごとく、対処レベル決定手段1、対処要員選定手段2、通知メディア選定手段3、対処要員向け通知情報生成手段4、および通知手段5を内蔵する。また対処レベル決定手段1は対処レベル因子ルールベース121を内蔵する。対処要員選定手段2は要員決定ロジック(対処要員情報)221を内蔵する。対処要員向け通知情報生成手段4はメッセージマスタMes-Mを内蔵する。これらの動作について図２のフローを追って以下に説明する。
【００１９】
まず図２のステップS201において運用管理通知支援システムは運用管理者向け通知情報OM-infを受信しバッファに保存する。この運用管理者向け通知情報OM-infは情報システムISの運用管理機能部OMFが一般に運用管理者向けに発する通知情報であって、そのデータ構造の一例を図16に示す。
【００２０】
図16に示すように、代表的な通知情報は情報システムISの障害発生を知らせるものである。このような情報には一般に障害発生日時情報（図では「日時」項目）、障害を検知したハード/ソフトコンポーネントを識別する障害ハード/ソフトｉｄ（図では「エラーｉｄ」項目）、およびその時点で動作していたソフトを識別する障害ソフトｉｄ（図では「プログラムｉｄ」項目）が含まれている。（なおソフトコンポーネントのエラーｉｄとプログラムｉｄの両者には歴然とした違いはあるが、対処要員選定上はその違いを無視して同一カテゴリとして両者を取り扱えるため、本実施例では両者をともに障害ソフトｉｄと呼ぶ。）
上記に説明した運用管理者向け通知情報OM-infは通常、発生のつどに運用管理機能部OMF内のディスプレイその他に表示され、運用管理者に通知するものであるが、同時に監視記録として運用管理機能部OMFのエラーログファイルに出力される。図2のステップS201では新たな障害発生のつど運用管理通知支援システムがこれを受信するのであるが、市販パッケージの運用管理機能部OMFでリアルタイム外部出力インタフェースを持たないものの場合でも、このようなエラーログファイルを頻回に受け渡しして更新をチェックすることで運用管理通知支援システムはリアルタイムに近くこれらの障害を知らせる運用管理者向け通知情報OM-infを受信することができる。
【００２１】
次いで、図2のステップS202に移り、運用管理通知支援システム内の対処レベル決定手段１は当該運用管理者向け通知情報OM-inf中の必要項目（主として障害ハード／ソフトidおよび障害発生日時）および関連環境情報(例1：業務サービス別スケジュール別重要度情報)(例2：天候などの動的考慮情報)C-infに基づいて対処レベルA-levelを算出する。このステップを説明するために、図3の対処レベル決定手段1の内部構成例を参照する。
【００２２】
図3に示すごとく、対処レベル決定手段1は業務サービス判定部11および対処レベル算出エンジン12から成り、業務サービス判定部11は業務サービスマスタ111を内蔵し、対処レベル算出エンジン12は対処レベル因子ルールベース121を内蔵する。この構成の対処レベル決定手段1の動作について、図4の動作フローによって詳細に説明する。
【００２３】
まず図4のステップS401で対処レベル決定手段1の業務サービス判定部11は当該運用管理者向け通知情報OM-inf中の障害ハードidおよび障害ソフトidをキーとして業務サービスマスタ111を検索し、対応する業務サービスを特定し、そのサービス重要度およびサービススケジュールを取得する。ここに業務サービスマスタ111とは当該情報システムIS上で実行する諸業務サービスについての属性情報データベースであって、そのデータ構造は図5に示すように、サービス種類、サービス重要度、使用ハード装置id、使用ソフトid、サービススケジュール等を持つものである。また、本実施例ではその他に「動的考慮事項」なる属性を備えた。ステップS401では、この業務サービスマスタ111の「使用ハード装置id」項目、「使用ソフトid」項目の値（リスト形式の要素値）に当該運用管理者向け通知情報OM-inf中の「障害ハードid」および「障害ソフトid」が含まれているような業務サービスを検索し、そのサービス（複数ある場合はそのすべてを対象として）のサービス重要度およびサービススケジュールを取得するのである。例えば図5に例示するレコードでは、サービス重要度は値"AA"であり、サービススケジュールは「通常営業時間帯＝“03：00〜24：00”，データベース更新＝“00：00〜03：00”，定期保守＝“毎月第1水曜日19：00〜24：00”」の値をとる。
【００２４】
次にステップS402で、対処レベル算出エンジン12は業務サービス判定部11が取得したサービス重要度を対処レベル因子ルールベース121に与えて対処レベル因子（重要度）への寄与を算出する。ここに、対処レベル算出エンジン12が内蔵する対処レベル因子ルールベース121とは図6のようなデータ構造で、対処レベルA-levelを算出するための因子に関するルールを羅列したものである。図6の実施例では対処レベル因子は重要度および緊急度であり、これらに関する諸ルールが与えられている。ステップS402では図6のルールｊ「if サービス重要度="AA" then 重要度=重要度+1」のように業務サービス判定部11が出力するサービス重要度の値が重要度因子に寄与するルールを実行する。この例ではすべてのサービスidに対して、そのサービス重要度項目の値が"AA"であるならば、当該対処レベル因子（重要度）を１加算することを示している。ここでは変数「重要度」は整数値で、その値が大きいほど高い重要度を意味するものと設定されている。
【００２５】
次にステップS403で、対処レベル算出エンジン12は運用管理者向け通知情報OM-inf中の障害発生日時および業務サービス判定部11が取得したサービスidおよびサービススケジュールを対処レベル因子ルールベース121に与えて、その対処レベル因子（緊急度）への寄与を算出する。これは図6のルールｋ，ｌ，ｍにその一例が示されているのでこれによって説明する。
【００２６】
これらのルールはいずれもサービスid=S12345なる業務サービスに発生した障害についてのルールであって、ルールｋでは障害発生日（event-day）が第1水曜日であり、障害発生時（event-time）が"19:00"より大なるときは変数「緊急度」が１減算される。すなわち緊急度が下げられる。ルールlでは、逆に、そうでない時には変数「緊急度」が１加算され緊急度が上げられる。ルールmは「動的考慮事項」項目のルール化であって、障害発生時（event-time）が最繁時間帯のときに変数「緊急度」がさらに１加算され緊急度が上げられる。本実施例では業務サービスマスタ111の「動的考慮事項」項目値は最繁時間帯として外部より業務サービスマスタ111に登録更新されるものとしたが、他の実施例では、運用管理機能部OMFが当該サービスid=S12345の利用者アクセス頻度をリアルタイムに定期的に捕らえて、これを運用管理者向け通知情報OM-inf上に項目として与え、対処レベル算出エンジン12がこれを利用するように、対処レベル因子ルールベース121にルールを与えることも可能である。
【００２７】
次にステップS404で対処レベル算出エンジン12は他の動的考慮事項として、例えば図6のルールｎ，ｏを実行する。このルールを実行すると、運用管理者入力画面が表示され、運用管理者に動的考慮事項パラメータdynamic-parameter値の入力を促す。運用管理者は例えば現在の天候情報に基づき、この値を入力すると、これに基づき変数「緊急度」を変化させる。なお、他の実施例では、動的考慮事項パラメータdynamic-parameter値を運用管理者に入力させるのではなく、対処レベル算出エンジン12にインターネット上の天候情報サービスに自動アクセスさせてdynamic-parameter値を自動計算させることも可能である。また、天候以外にも動的考慮情報として、社会的な事象、経済的な事象等による当該運用システムの異常時の対処の重要度レベル等の影響を含む前記情報システムに係る動的考慮情報とすることも可能である。
【００２８】
次にステップS405で、対処レベル算出エンジン12はすべての外部入力に対する対処レベル因子ルールベース121のルールを適用させ終えると、最終的な対処レベルA-levelを算出する。図6の例では対処レベル因子である重要度および緊急度の最終値に対してルールｚによって対処レベルA-levelを重要度*0.2+緊急度*0.8の整数部（最大５まで）で求めている。
【００２９】
図2に戻って、以上説明したように、図2のステップS202で対処レベルA-levelが算出されたのを受け、対処要員選定手段2はステップS203において、前ステップで得られた運用管理者向け通知情報OM-inf、前ステップで得られた対処レベルA-level、外部の要員勤怠管理システムから得られる要員属性情報Pp-infおよび勤務実績・予定データW-dataに基づいて、今回対処に当たるべき適切な対処要員APを選定し、その対処要員ID（AP-id）を出力する。このステップについては、図7の対処要員選定手段2の内部構成例および図8の対処要員選定手段2の動作フローに基づいて以下に説明する。
【００３０】
対処要員選定手段2はまず図8のステップS801で図7の必要要員種別判定部21を起動し、運用管理者向け通知情報OM-infの示す障害ハードid,障害ソフトidをキーとして守備範囲マスタSkill-Mを検索して、必要な要員種別kindを決定する。ここに守備範囲マスタSkill-Mは必要要員種別判定部21が内蔵するもので、障害ハード/ソフトidごとにどのような守備範囲をもつ対処要員APが必要かを登録したマスタである。図9にその一例を示すごとく、守備範囲マスタSkill-Mは個々の障害ハード/ソフトidごとに対処要員APの属性である要員種別kindのとる値を指定するので、これによって当該運用管理者向け通知情報OM-infに対応する対処要員APのもつべき要員種別kindが判定される。
【００３１】
次に図8のステップS802で、図7の要員種別毎必要人数判定部22は前ステップで得られた要員種別kindおよび対処レベルA-levelをもとに要員決定ロジック(対処要員情報)221を参照して必要な要員種別kindごとの人数を決定し、種別と人数のタプル（種別人数タプル）K-Nを作成する。一般に複数個のタプルが得られる。ここで用いられる要員決定ロジック(対処要員情報)221の構造例を図10に示す。本実施例では要員決定ロジック(対処要員情報)221は対処レベルA-level値のレンジと要員種別kind値のレンジで作るマトリックスで必要とする要員の人数を決めている。
【００３２】
次に図8のステップS803で、図7の対処要員選定部23は全部の種別人数タプルK-Nについて対処要員ID(AP-id)を選定したか、を判定し、全部の処理が終わるまで以下のステップS804,805を繰り返す。
【００３３】
ステップS804では、対処要員選定部23は次の種別人数タプルK-Nを取り出し、以下の手順で候補となる対処要員ID(AP-id)を抽出する。（１）取り出した種別人数タプルK-N中の要員種別kindと運用管理者向け通知情報OM-inf中の障害ハード/ソフトidを検索キーとする。（２）図12に構造を示す外部の要員マスタAP-Mに設定された要員属性情報Pp-inf中に前記検索キーを含む対処要員ID(AP-id)のレコードを対処要員候補として抽出する。ここに、要員マスタAP-Mはすべての対処要員APについてその要員属性情報Pp-infを登録管理するもので、本実施例では図1に示すように、外部の要員勤怠管理システムで維持されており、そのデータ構造例は図12に示される。図のごとく、各対処要員APの要員種別kindおよび連絡先が要員属性情報Pp-infとして取られている。要員種別kindはカテゴリコードおよび対象機器/ソフトidの組み合わせであり、カテゴリコードとは当該対処要員APの得意分野カテゴリを登録するコードで、図12に併せて例示するコード表のように意味づけられている。また、当該対処要員APの得意分野対象機器/ソフトは要員属性情報Pp-inf中の対象機器/ソフトidとしてとられている。図12に例示するように、これらの得意分野は通常複数個あるので、複数個要素からなるリスト形式で登録されている。そこで前記手順（２）では前記（１）で設定した検索キーがこのカテゴリコードリストおよび対象機器/ソフトidリストに含まれるような対処要員ID(AP-id)レコードを要員マスタAP-Mから抽出する。
【００３４】
ついでステップS805で、対処要員選定部23は抽出された対処要員候補ID(AP-id)について要員勤怠データベースW-db中の勤務実績・予定データW-dataを障害発生日時と照合し、休暇中でない出動可能者を抽出し、さらにこれらの抽出された候補者について、その累計出動回数の昇順にソートし、種別人数タプルK-Nが指定する人数分を選定する。ここに、要員勤怠データベースW-dbとは外部の要員勤怠管理システムが管理するデータベースで、各対処要員APの勤務実績・予定データW-dataを登録する。図11に要員勤怠データベースW-dbのデータ構造例を示すごとく、出動の実績、出勤の実績、勤務日、勤務時間、勤務地の予定データが各月度単位で格納されている。
【００３５】
図2に戻ると、以上によって図2のステップS203に記す対処要員選定手段2の動作を説明した。次に、図2のステップS204の動作を説明する。ステップS204では、通知メディア選定手段3は前ステップで得られた対処要員ID(AP-id)の属性情報である要員属性情報Pp-infおよび勤務実績・予定データW-dataを外部から取り込み、運用管理者向け通知情報OM-inf中の障害発生日時と対比して適切な通知メディアCmedを選定し、その通知メディアID(Cmed-id)を出力する。この部分の詳細を説明するために、図13に本実施例の通知メディア選定手段3の構成例を示し、図14にその動作フローを示し、これに基づいて以下に説明する。
【００３６】
図13の通知メディア選定手段3の連絡先決定部31は図14のステップS1401で、前ステップで得られた対処要員ID(AP-id)に対する外部の要員勤怠管理システムから得られる要員属性情報Pp-infおよび勤務実績・予定データW-dataと運用管理者向け通知情報OM-inf中の障害発生日時とを照合して、当該対処要員APの現在勤務地を取得する。次いで、ステップS1402で、メディア選択部32は前ステップで得られた現在勤務地を、内蔵するメディア登録表Med-table（図13参照）と照合して、適切な連絡先項目名（メディア種類およびアドレス種類）を取得する。次にステップS1403において、メディア選択部32は当該対処要員APの要員マスタAP-M上の要員属性情報Pp-infを参照し、その連絡先項目の中から、前ステップで得られた連絡先項目名の通知メディアIDCmed-idおよびその対処要員AP固有のアドレスを取得する。
【００３７】
図2にかえって、運用管理通知支援システムの対処要員向け通知情報生成手段4はステップS205において、前ステップで得られた対処要員ID(AP-id)および通知メディアID(Cmed-id) とその固有アドレスに基づいて、運用管理者向け通知情報OM-infを対処要員向け通知情報AP-infに変換する。このメッセージ組み立ては図15に例示するメッセージマスタMes-Mを参照して行われる。すなわち、メッセージマスタMes-Mには各通知メディアID(Cmed-id)ごとにタイトル名や本文を形成する可変文節および固定文節が準備されているので、対処要員向け通知情報生成手段4はこの可変文節に対処要員APの氏名や障害のｉｄなどをリンクし、各文節のつながりを選択設定してして各通知メディアID(Cmed-id)にふさわしい対処要員向け通知情報AP-infを作成する。このように可変文節を含むテキスト文字列でタイトル名や本文を与える技術は電話、ＦＡＸ、電子メールの場合は例えば文献特開平９−１３６２６６号公報などで公知のものであり、前記特許文献１，２においても使用されている。また、通知メディアが館内放送の場合のこのような技術も、駅構内の旅客案内等で公知のものであるので（例えば文献特開平０２−０３３１９８号公報で示される）、ここではその詳細の説明を省略する。
【００３８】
最後に運用管理通知支援システムは図2のステップS206において、内蔵する通知手段5を起動し、前ステップで得られた通知メディアID(Cmed-id)およびこれに対応する対処要員向け通知情報AP-infを外部の通知システムに送出する。ここに外部の通知システムは図1に例示するように、E-mail、固定電話・移動電話・ページャ、FAX、館内放送などの通知メディアに所期の通知動作を行わせるもので、前述の特開平９−１３６２６６号および特開平０２−０３３１９８号に示されるサーバ機能を併せ持つものである。
【実施例２】
【００３９】
図１７は本発明の第2実施例の運用管理通知支援システムの構成例である。また、図１８には本発明の第2実施例の運用管理通知支援システムの動作フロー図を示し、図19には本発明の第2実施例の運用管理通知支援システムの各種データ構造例を示した。
【００４０】
図17においては、「運用管理ソフト(SystemWalkerなど) 」と記される部分が第1実施例の運用管理機能部OMFに相当し、「警告調整システム」と記された部分が本発明の運用管理通知支援システムに相当する。また、図19(a)における「運用管理ソフトウェアからの発生メッセージ」が実施例１の運用管理者向け通知情報OM-infに相当する。
【００４１】
図18のルーチン「エラー情報の取得」において、運用管理通知支援システムは前記運用管理ソフトウェアよりエラーメッセージを抽出して、図示しない障害管理テーブルを作成する。次にルーチン「業務内容、時間帯、在席勤務者等を検討」では当該障害の対処レベルである優先度、緊急度を判断する（下記[1],[8]参照）。この判断では業務、プログラム要素、日時要素、その他が考慮される。そして対処レベルを確定すると対処要員の必要技術(種別）、および必要人数を決定する（下記[2],[3]参照）。次に対応要員を検索し（下記[4]参照）、必要人数の確保ができた場合は通知方法の選択(図19 (e)対応要員データベースを使用)を行う（下記[5]参照）。必要人数の確保ができなかった場合は、システムはマネージャへの連絡アラームを出し、マネージャの調整に委ねる。
【００４２】
次にルーチン「出力メッセージ組立て」では、まずエラーメッセージをメッセージ
変換テーブルで変換する。次にパラーメータに該当項目をセットする。次に通知予定者の緊急度に応じた方法に変換する。
【００４３】
次にルーチン「通知」では、まず既定の通知レベルで通知する（下記[6]参照）。その後一定時間のウェイトを行い、その間に解除メールを受信したならば通知解除を行い、障害管理テーブルに完了を設定するが、解除メールの受信がなければ再度既定の通知レベルで通知するステップに戻り、通知を繰り返す（下記[7]参照）。また、通知された担当者が着手したことをメール或いは運用管理通知支援システムに直接に、或いはネットワーク等で接続された装置（ＰＣ等）で通知してきたら通知解除をし、或いは対処要員が直接又は、対処要員からの電話等で対処開始通知を受けた当該システム要員が代行入力し、他の者にも場合により知らせる。そして、一定時間着手しない場合は、通知レベルを上げる。また、他の実施例では、次の担当者を決定して通知するようにしても良い。
【００４４】
以上の動作を図19の例に基づいて具体的に説明する。まず、図19の(a)運用管理ソフトウェアからの発生メッセージを、変換して図19(b)入力メッセージデータベースとする。以下にはこのデータベース上のerr001のメッセージについて、その通知までを追う。
【００４５】
[1]図19 (c)のサービス時間帯データベースより10:10にprg001で発生より緊急度は１となる。(本実施例では緊急度１が最も高く、値が増すほど緊急度が低い、としている。)
[2]図19（ｄ）稼動プログラムデータベースよりprg001なので種別についてシステム（ハードA）と判る。
【００４６】
[3]図19 (a)運用管理ソフトウェアからの発生メッセージの関係ファイル、装置名等より装置名はDB0011と判る。
【００４７】
[4]対応要員については図19 (f)対応要員決定テーブル優先度１、緊急度１なので４人と判る。  
【００４８】
[5]図19 (e)対応要員データベースを検索し、se001,se002他2名の合計4名を抽出する。
【００４９】
[6]図19 (g)メッセージ変換テーブルより入力メッセージはファイル入出力エラーでエラーIDがF01なので、通知メッセージは、『”管理番号”、”###”殿      ”$$$”の”%%%”においてファイル入出力エラーが”&&&”で発生しています。至急対処をお願いします。』が採用される。最初の１名は、は当日の1番より、”管理番号”＝0001、名前”###”はse001より、”ハード強”となり、$$$は入力メッセージDBの時間、サーバ名より、“2/20  10：10にサーバWWW2”となり、%%%はプログラム名より変換した種別なので、システム（ハート゛A)、&&&は関係ファイル、装置名等よりDB0011が挿入される。
【００５０】
[7]通知方法については図19 (e)対応要員データベースの緊急度１よりｓｅ００１は館内放送（３階北側）、ｓｅ００２も館内放送（３階北側）、・・・、となる。     よって、『0001  ハード強殿、2月20日10時10分にサーバWWW2のシステム（ハードＡ）においてファイル入出力エラーがDB0011で発生しています。至急対処をお願いします。』とメッセージを３階北側へ館内放送で自動音声放送を行う。予備として設定により、同じ文章をメールアドレスｓｅ００１＠ｈａｒｄ．Ｃｏｍに送信しても良い。
【００５１】
[8]また、天候が雪でA業務他でリスト出力関係業務でエラーが起きた時、関係するプログラム範囲では上記処理において緊急度を１上げるように(即ち変数「緊急度」の値を１減算するように)、考慮するようにしても良い。例えば、
if 業務＝A業務 and 業務プログラム＝リスト出力関係業務プログラム and 障害ソフトid＝or(pｒg003、prg004、prg006) then緊急度＝緊急度-1.
などと記述する。
【産業上の利用可能性】
【００５２】
本発明の運用管理通知支援システムは、多数保守要員で多数情報システムを保守する場合に、迅速かつ適切に対処要員を派遣できるので、特にアウトソーシング事業者のような大規模保守体制の事業に好適なシステムである。
【図面の簡単な説明】
【００５３】
【図１】本発明の第1実施例の運用管理通知支援システムの構成例
【図２】第1実施例の運用管理通知支援システムの動作フロー図
【図３】本発明の第1実施例の対処レベル決定手段の構成例
【図４】第1実施例の対処レベル決定手段１の動作フロー図
【図５】業務サービスマスタ111のデータ構造例
【図６】対処レベル因子ルールベース121のデータ構造例
【図７】本発明の第1実施例の対処要員選定手段の構成例
【図８】第1実施例の対処要員選定手段2の動作フロー図
【図９】守備範囲マスタSkill-Mのデータ構造例
【図１０】要員決定ロジック(対処要員情報)221の構造例
【図１１】要員勤怠データベースW-dbのデータ構造例
【図１２】要員マスタAP-Mのデータ構造例
【図１３】本発明の第1実施例の通知メディア選定手段の構成例
【図１４】第1実施例の通知メディア選定手段3の動作フロー図
【図１５】メッセージマスタMes-Mのデータ構造例
【図１６】運用管理者向け通知情報OM-infのデータ構造例
【図１７】第2実施例の運用管理通知支援システムのシステム構成図
【図１８】第2実施例の運用管理通知支援システムの動作フロー図
【図１９】第2実施例の運用管理通知支援システムの各種データ構造例
【符号の説明】
【００５４】
1  対処レベル決定手段
2  対処要員選定手段
3  通知メディア選定手段
4  対処要員向け通知情報生成手段
5  通知手段
11  業務サービス判定部
111  業務サービスマスタ
12  対処レベル算出エンジン
121  対処レベル因子ルールベース
21  必要要員種別判定部
22  要員種別毎必要人数判定部
・  要員決定ロジック
・  対処要員選定部
・  連絡先決定部
・  メディア選択部
AP  対処要員
AP-inf  対処要員向け通知情報
C-inf  関連環境情報
OM-inf  運用管理者向け通知情報
AP  対処要員
A-level  対処レベル
AP-id  対処要員ID
Skill-M  守備範囲マスタ
Pp-inf  要員属性情報
Cmed-id  通知メディアID
AP-M  要員マスタ
W-data  勤務実績・予定データ
W-db  要員勤怠データベース
Mes-M  メッセージマスタ
【図１】
2005276068.tif 000003
【図２】
2005276068.tif 000004
【図３】
2005276068.tif 000005
【図４】
2005276068.tif 000006
【図５】
2005276068.tif 000007
【図６】
2005276068.tif 000008
【図７】
2005276068.tif 000009
【図８】
2005276068.tif 000010
【図９】
2005276068.tif 000011
【図１０】
2005276068.tif 000012
【図１１】
2005276068.tif 000013
【図１２】
2005276068.tif 000014
【図１３】
2005276068.tif 000015
【図１４】
2005276068.tif 000016
【図１５】
2005276068.tif 000017
【図１６】
2005276068.tif 000018
【図１７】
2005276068.tif 000019
【図１８】
2005276068.tif 000020
【図１９】
2005276068.tif 000021