JP4865511B2 - サービス管理装置 - Google Patents

Description

本発明は、情報システムのサービスデスクにおける業務の工程を管理する技術に関する。

近年、企業における情報システムの利用は必須となっている。顧客である企業からの問い合わせやクレーム（「インシデント」ともいう）に対応するために、通常、システム運用会社はサービスデスクを設置している。サービスデスクは顧客の窓口としての役割を担うため、サービスデスクのオペレータには迅速かつ的確な対応が要求される。

サービスデスクの業務を円滑に遂行するため、インシデント管理ツールを導入することが多い。例えば、特許文献１には、問い合わせのあった内容をインシデント管理し、各問い合わせに答えるために必要なＱＡ集をナレッジ情報として格納し、顧客対応の結果インシデントを蓄積して管理し、その対応履歴から定期的にレポートを作成するナレッジシステムが開示されている。このようなツールを用いれば、各オペレータが管理しているインシデント数を容易に管理することができる。
特開２００５−１１１４０号公報

しかしながら、上記のような従来技術では、インシデントの重要度によらずあらゆるインシデントが一件としてカウントされるため、いずれのインシデントを優先的に処理すべきかを判断することが困難である。また、実際の運用では、インシデントは開発部などの他部門に伝達されてそこでの対応が必要になる場合も多いが、従来技術ではインシデントと他部門との対応関係を直ちに把握することができない。

本発明はこうした状況に鑑みてなされたものであり、その目的は、インシデントの重要度を考慮した上でサービスデスクにおける業務の工程を管理する技術を提供することにある。

本発明の一実施形態は、サービス管理装置に関する。この装置は、所定のサービスを提供するシステムに対する顧客からのインシデントを受け取ったオペレータによってインシデント毎に作成される、インシデントに関するデータを含むインシデントチケットを管理するインシデント管理部と、インシデントチケットのうちオペレータでは対応できないと判断されたインシデントに関するインシデントチケットと関連付けされる、システムの開発者が対応すべき問題に関するデータを含む問題チケットを管理する問題管理部と、問題チケットのうち、問題の解決のためにシステムのメンテナンスを必要とする問題チケットと関連付けされる、システムの運用担当者が実施すべき変更に関するデータを含む変更チケットを管理する変更管理部と、を備える。インシデント管理部は、オペレータによるインシデント処理の優先順位を決定するための指標であるインシデントインパクトを算出するインシデントインパクト算出部を備える。問題管理部は、開発者による問題の処理の優先順位を決定するための指標である問題インパクトを算出する問題インパクト算出部を備える。変更管理部は、運用担当者による変更の処理の優先順位を決定するための指標である変更インパクトを算出する変更インパクト算出部を備える。インシデントインパクトまたは問題インパクトが変更されると、インシデントチケット、問題チケットおよび変更チケットの関連付けに応じて問題インパクトまたは変更インパクトが修正される。

「インシデント」とは、オペレータが受け付けをする顧客から寄せられた問い合わせ、相談、要求、意見、クレーム等を総称したものをいう。
この態様によると、インシデント、問題、変更といったサービスデスクにおける各工程について処理の優先順位の指標となるインパクトを算出するので、効率のよい作業が実現する。また各工程が他の工程と関連付けされているため、ひとつの工程についてインパクトを変更すれば、他の工程におけるインパクトが自動的に修正される。

以上の構成要素の任意の組合せ、本発明を方法、装置、システム、記録媒体、コンピュータプログラムにより表現したものもまた、本発明の態様として有効である。

本発明によれば、インシデントの重要度を考慮した上でサービスデスクにおける業務の工程を管理することができる。

本発明の一実施形態は、情報システムのサービスデスク（または、ヘルプデスク）における業務を管理するサービス管理装置である。以下、図面を参照して詳細に説明する。

図１は、本実施形態に係るサービス管理装置１００を含むシステム１０の全体構成図である。システム１０は、顧客に所定のサービスを提供する顧客システム２０に関して顧客から寄せられる多数の問い合わせ、相談、要求、意見、クレーム等（以下、これらを総称して「インシデント」という）に対処するためのシステムである。サービスデスク端末１２は、顧客からのインシデントを最初に電話、電子メール、ファックス等を介して受け取るサービスオペレータが操作する端末である。開発者端末１４は、顧客システム２０を構成するサーバやサーバで動作するプログラムの開発を担当する開発者が操作する端末である。運用担当者端末１６は、顧客システム２０におけるプログラムの導入、更新等を含むメンテナンス業務を担当する運用担当者が操作する端末である。マネージャ端末１８は、システム１０を利用したサービスデスク全体の業務を統括するマネージャが操作する端末である。サービスデスク端末１２、開発者端末１４、運用担当者端末１６およびマネージャ端末１８は、ＬＡＮ（Local Area Network）等のネットワーク２２を介してサービス管理装置１００と接続される。

端末１２〜１８、およびサービス管理装置１００は、プログラムにしたがって各種処理を実行するプロセッサと、一時的にデータやプログラムを記憶するメモリと、サーバの再起動があっても記録内容が失われないハードディスクドライブ、ＤＶＤドライブなどの記憶装置と、ネットワークに接続し各種の入出力処理を実行するネットワークインタフェースと、これらを相互接続するバス、キーボードやマウスなどの入力装置、ディスプレイなどの出力装置を有する。

サービスデスクにおいて管理する業務は、インシデント管理、問題管理、変更管理の三つのプロセスに分けられる。

サービスオペレータは、顧客からインシデントを受けると、サービスデスク端末１２を使用してインシデントの内容を所定のフォーマットで入力する。以下、本明細書において、フォーマットを通じて入力される情報を「チケット」と呼ぶことにする。チケットは、サービス管理装置１００で管理される。

サービスオペレータは、オペレータのレベルではインシデントに対する回答を出せないと判断した場合は、そのインシデントの解決を開発者に任せる必要がある。開発者が担当する業務のことを、本実施形態では「問題」と呼ぶ。インシデントは顧客単位で管理されるのに対し、問題は、実際の問題の具体的な内容毎に管理される。例えば、三つの顧客からそれぞれ「サービスが利用できない」というインシデントが発せられたとき、インシデントは三つとなるが、問題については、「アプリケーションプログラムＡが起動しない」というひとつの問題に集約される。サービスオペレータまたは開発者は、問題の内容と集約されたインシデントを識別するためのＩＤとを情報として含む問題チケットを作成し、サービス管理装置１００に登録する。

開発者は、修正したプログラムを顧客システム２０で実行するなどのメンテナンスをしないと問題を解決できないと判断した場合は、そのプログラムの実行を運用担当者に依頼する。運用担当者のする作業の単位を、本実施形態では「変更」と呼ぶ。変更は、メンテナンスするプログラムの単位で管理される。例えば、問題として「アプリケーションプログラムＡが正常に起動しない」「アプリケーションプログラムＡが正常に終了しない」というものがあり、開発者がアプリケーションプログラムＡの更新が必要と判断した場合、これら二つの問題は、「アプリケーションプログラムＡの変更」というひとつの変更に集約される。開発者または運用担当者は、「変更」の内容と集約された問題を識別するためのＩＤとを情報として含む変更チケットを作成し、サービス管理装置１００に登録する。

図２は、本実施形態における「インシデント」「問題」「変更」の間の相互のつながりを概念的に説明する図である。インシデントの段階では、顧客からの連絡に対応して多数のチケット２４が作成される。それらのうち一部はサービスオペレータが解決し、一部は開発者の関与を必要とする。後者のチケットは、図２中に矢印で示すように、複数の問題チケットと関連付けされる。サービスオペレータが解決するインシデントチケットは、問題チケットとは関連付けされない。同様に、運用担当者の関与を必要とする問題チケットは、図２中に矢印で示すように、変更チケットと関連付けされる。

このように、本実施形態では、サービスオペレータが作成するインシデントチケットが、開発者の関与する問題チケット、運用担当者の関与する変更チケットと相互に関連付けされている点に特徴のひとつがある。これによって、サービスデスクにおけるインシデント管理、問題管理、変更管理の三つのプロセスの連関性を考慮した管理が可能になる。

図３は、サービス管理装置１００のうち、本実施形態に関与する部分の構成を示す。これらの構成は、ハードウェア的には、プロセッサ、メモリ、バス等で実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは、当業者には理解されるところである。

サービス管理装置１００は、インシデントチケットを管理するインシデント管理部１１０、問題チケットを管理する問題管理部１２０、変更チケットを管理する変更管理部１３０を備える。

インシデント管理部１１０は、顧客から発せられたインシデントに対する回答が速やかになされるように、インシデントを管理する。問題管理部１２０は、オペレータのレベルでは対応不可能なインシデントに関連付けられた問題を管理する。問題が解決されることで、関連するインシデントも解決されることになる。変更管理部１３０は、問題の解決に必要となるプログラムの変更を管理する。プログラムの変更がなされると、問題、インシデントが解決される。また、同種のインシデントおよび問題の発生が防止される。

サービスオペレータは、顧客からインシデントを受け取ると、サービスデスク端末１２を使用してサービス管理装置１００にアクセスする。入力受付部１０２は、インシデントチケット作成用の入力フォーマットをサービスデスク端末１２に提供する。サービスオペレータがフォーマットに所定の項目を入力して送信すると、入力受付部１０２がそれを受け取り、インシデント保持部１１２にインシデントチケットとして保持する。インシデントチケットは、テーブルで管理される。インシデントインパクト算出部１１４は、新しいインシデントが登録される毎に、または定期的に、または外部からの指示に応じて、そのインシデントの処理の優先順位を決定する指標となるインシデントインパクトを算出する。インシデントインパクトを算出するために、本実施形態では、顧客の重要度、システムの重要度、インシデントの対応期限の三つの要素を考慮する。

インシデントインパクト算出部１１４は、インシデント保持部１１２から、インシデントを連絡した顧客、対象となるシステム、およびインシデントの対応期限を取得する。インシデント重要度保持部１１６には、顧客、システム、対応期限毎に、予め設定された重要度が保持されている。インシデントインパクト算出部１１４は、顧客、システム、インシデントの条件にしたがって、インシデント重要度保持部１１６を参照して顧客重要度、システム重要度、およびインシデント緊急度を決定する。そして、インシデントインパクト算出部１１４は、次式にしたがってインシデントインパクトを算出する。
（式１）
（インシデントインパクト）＝（顧客重要度）×（システム重要度）×（インシデント緊急度）

算出されたインシデントインパクトは、表示出力部１０８によってサービスデスク端末１２に提供され、ディスプレイに表示される。サービスオペレータは、インシデントインパクトの数値の高い順にインシデントを解決するよう試みる。

図４は、顧客重要度の一例を示すテーブル１５０である。顧客重要度とは、そのインシデントを発した顧客の重要性に対応する指標であり、顧客である企業とシステム提供者との間の契約内容や顧客企業との取引額などを考慮して予め設定しておく。テーブル１５０では、条件１５２に、「会社が定めた重要顧客」「２４時間保守サービス契約」「通常保守サービス契約」の条件があり、それに対応して顧客重要度１５４が定められている。インシデントインパクト算出部１１４は、インシデント保持部１１２から顧客名を取得すると、図示しないデータベースを参照してその顧客が上記の条件のいずれに該当するかを決定し、対応する顧客重要度を取得する。

図５は、システム重要度の一例を示すテーブル１６０である。システム重要度とは、インシデントの対象となっているシステムの重要性に対応する指標であり、システムが業務に与える影響などを考慮して予め設定しておく。テーブル１６０では、条件１６２に、「基幹システム」「情報システム」「その他システム」の条件があり、それに対応してシステム重要度１６４が定められている。インシデントインパクト算出部１１４は、インシデント保持部１１２からシステム名を取得すると、図示しないデータベースを参照してそのシステムが上記の条件のいずれに該当するかを決定し、対応するシステム重要度を取得する。

図６は、インシデント緊急度の一例を示すテーブル１７０である。インシデント緊急度は、オペレータが入力するか、または顧客が指定するインシデントの対応期限までの時間による重み付けであり、予め設定しておく。テーブル１７０では、条件１７２に、「対応期限まで６時間未満」「対応期限まで一日未満」「対応期限まで一日以上」の条件があり、それに対応してインシデント緊急度１７４が定められている。インシデントインパクト算出部１１４は、インシデント保持部１１２から対応期限を取得すると、テーブル１７０の条件のいずれに該当するかを決定し、対応するインシデント緊急度を取得する。

図３に戻り、オペレータ負荷算出部１１８は、インシデントインパクト算出部１１４で算出されたインシデントインパクトを使用して、サービスオペレータ毎の負荷を算出する。オペレータ負荷は、次式で算出される。
（式２）
（オペレータ負荷）＝Σ（インシデントインパクト）
ここで、Σは、各オペレータの担当するインシデントについて算出されたインシデントインパクトを加算することを意味する。算出されたオペレータ負荷は、表示出力部１０８によってマネージャ端末１８に提供され、ディスプレイに表示される。マネージャは、各オペレータのオペレータ負荷を参照し、負荷の大きいオペレータが担当するインシデントを他のオペレータに担当替えするといった配慮をすることができる。

サービスオペレータは、オペレータでは対応できないインシデントと判断した場合、インシデントチケットを既存の問題チケットと関連付けする。既存の問題チケットと関連付けできないインシデントがある場合は、開発者に新しい問題チケットを作成するように要請する。

開発者は、開発者端末１４を使用してサービス管理装置１００にアクセスする。すると、入力受付部１０２は、問題チケット作成用の入力フォーマットを開発者端末１４に提供する。開発者がフォーマットに所定の項目を入力して送信すると、入力受付部１０２がそれを受け取り、問題保持部１２２に問題チケットとして保持する。

問題インパクト算出部１２４は、新しい問題が登録される毎に、または定期的に、または外部からの指示に応じて、各問題について問題の処理の優先順位を決定する指標となる問題インパクトを算出する。問題インパクト算出部１２４は、問題保持部１２２から問題の対応期限を取得する。問題重要度保持部１２６には、対応期限毎に予め設定された問題緊急度が保持されている。また、問題インパクト算出部１２４は、その問題に関連付けられるインシデントについて決定された顧客重要度とシステム重要度とをインシデントインパクト算出部１１４から取得する。そして、次式にしたがって、問題インパクトを算出する。
（式３）
（問題インパクト）＝Σ（インシデント影響度）×（問題緊急度）
＝Σ｛（顧客重要度）×（システム重要度）｝×（問題緊急度）
ここで、記号Σは、問題に関連付けされたすべてのインシデントについての計算結果を加算することを意味している。

算出された問題インパクトは、表示出力部１０８によって開発者端末１４に提供され、ディスプレイに表示される。開発者は、問題インパクトの数値の高い順に問題を解決するよう試みる。

問題を解決することで、インシデントも解決することになるため、問題の対処の優先順位を決定するためには、解決できるインシデントの数と、それぞれのインシデントの重要度とを加味する必要がある。そこで、上記式３では、「インシデント影響度」として顧客重要度およびシステム重要度を使用し、さらに問題に関連付けされたインシデントについての結果を加算している。これによって、解決できるインシデント数の多い問題、および重要度の高いインシデントを解決する問題から優先的に対応することが可能になる。

図７は、問題緊急度の一例を示すテーブル１８０である。問題緊急度は、オペレータまたは開発者が入力する問題の対応期限までの時間による重み付けであり、予め設定しておく。テーブル１８０では、条件１８２に、「対応期限まで一ヶ月未満」「対応期限まで三ヶ月未満」「対応期限まで三ヶ月以上」の条件があり、それに対応して問題緊急度１８４が定められている。問題インパクト算出部１２４は、問題保持部１２２から対応期限を取得すると、テーブル１８０の条件のいずれに該当するかを決定し、対応する問題緊急度１８４を取得する。

図３に戻り、開発者負荷算出部１２８は、問題インパクト算出部１２４で算出された問題インパクトを使用して、開発者毎の負荷を算出する。開発者負荷は、次式で算出される。
（式４）
（開発者負荷）＝Σ（問題インパクト）
ここで、Σは、各開発者の担当する問題について算出された問題インパクトを合計することを意味する。算出された開発者負荷は、表示出力部１０８によってマネージャ端末１８に提供され、ディスプレイに表示される。マネージャは、各開発者の開発者負荷を参照し、負荷の大きい開発者が担当する問題を、他の開発者に担当替えするといった配慮をすることができる。

開発者は、プログラムの変更や追加等をしなければ問題を解決できないと判断した場合、問題チケットを既存の変更チケットと関連付けする。既存の変更チケットと関連付けできない問題がある場合は、運用担当者に新しい変更チケットを作成するように依頼する。

運用担当者は、運用担当者端末１６を使用してサービス管理装置１００にアクセスする。すると、入力受付部１０２は、変更チケット作成用の入力フォーマットを運用担当者端末１６に提供する。運用担当者がフォーマットに所定の項目を入力して送信すると、入力受付部１０２がそれを受け取り、変更保持部１３２に変更チケットとして保持する。

変更インパクト算出部１３４は、新しい変更が登録されるか、定期的に、または外部からの指示に応じて、各変更について変更の処理の優先順位を決定する指標となる変更インパクトを算出する。変更インパクト算出部１３４は、変更に関連付けされた問題について算出された問題影響度を問題インパクト算出部１２４から取得する。そして、次式にしたがって、変更インパクトを算出する。
（式５）
（変更インパクト）＝Σ（問題影響度）×（変更難易度）
ここで、記号Σは、変更に関連付けされたすべての問題についての計算結果を加算することを意味している。
なお、問題影響度は、各問題に対して関連付けされたインシデントのインシデント影響度の加算値である。
（式６）
（問題影響度）＝Σ（インシデント影響度）

算出された変更インパクトは、表示出力部１０８によって運用担当者端末１６に提供され、ディスプレイに表示される。運用担当者は、変更インパクトの数値の高い順に、変更の作業を実施するよう試みる。

図８は、変更難易度の一例を示すテーブル１９０である。変更難易度は、プログラムの変更のために顧客システムを停止する時間による重み付けであり、予め設定しておく。テーブル１９０では、条件１９２に、「システムを停止せずに変更できる」「システムの停止は１時間以内である」「システムの停止が１時間以上必要」の条件があり、それに対応して変更難易度１９４が定められている。変更インパクト算出部１３４は、変更保持部１３２からシステム停止時間を取得すると、テーブル１９０の条件のいずれに該当するかを決定し、対応する変更難易度１９４を取得する。

図３に戻り、エスカレーション管理部１０４は、サービスオペレータによって既存の問題チケットと関連付けされたインシデントチケットがある場合、そのインシデントチケットを特定するためのＩＤを取得して、問題保持部１２２の対応する問題チケットにＩＤを追加する。また、エスカレーション管理部１０４は、開発者によって既存の変更チケットと関連付けされた問題チケットがある場合、その問題チケットを特定するためのＩＤを取得して、変更保持部１３２の対応する変更チケットにＩＤを追加する。

続いて、インシデント、問題、変更の各チケットと入力フォーマットとを参照して、本実施形態におけるサービス管理方法を具体的に説明する。

図９は、インシデント管理部１１０における処理のフローチャートである。サービスオペレータが顧客からインシデントを受け付け、インシデントのチケットを作成すると（Ｓ２０）、インシデントチケットがインシデント保持部１１２に格納される（Ｓ２２）。インシデントインパクト算出部１１４は、インシデントに関する顧客重要度、システム重要度、インシデント緊急度を決定し、上述の式にしたがってインシデントインパクトを算出する（Ｓ２４）。オペレータ負荷算出部１１８は、インシデントインパクトを使用してオペレータ毎にオペレータ負荷を算出する（Ｓ２６）。

図１０は、インシデントチケットを作成するためのフォーマット３０の一例を示す。このフォーマットは、例えば、ＨＴＭＬファイルの形式でサービスデスク端末１２に送られ、サービスデスク端末１２で動作するブラウザによってディスプレイに表示される。

インシデントＩＤ３１は、インシデント管理部１１０によってインシデントチケットに自動的に割り当てられる通し番号である。ステータス欄３２には、当該インシデントについて、新規、対応中、保留中、解決済みといったステータスを入力する。タイトル欄３３には、インシデントの内容を表すタイトルを入力する。対応期限日欄３４および対応期限時刻欄３５には、インシデントの対応期限日、対応期限時刻をそれぞれを入力する。オペレータ欄３６には、当該インシデントを担当するオペレータ名を入力する。顧客欄３７には、インシデントを発した顧客名を入力する。対象システム欄３８には、インシデントの発生原因と考えられるシステム名を入力する。内容欄３９には、インシデントの具体的な内容を入力する。経過欄４０には、インシデントに対してオペレータが実施した調査、作業、回答の過程を入力する。

問題チケット欄４１は、オペレータがインシデントに対応できないと判断したときに、インシデントチケットを既存の問題チケットと関連付けるときに使用する。問題チケット欄４１の右端をクリックすると、既存の問題チケットのタイトルの一覧が表示されるので、オペレータは、一覧のなかからインシデントと関連付けできる問題のタイトルを選択する。
あるいは、インシデントチケットと関連付けできそうな問題チケットをキーワード検索できるように構成してもよい。入力受付部１０２は、フォーマット３０の一部に、問題チケットを検索するためのキーワード入力欄を表示する。オペレータが適当なキーワードを入力して検索ボタンをクリックすると、入力受付部１０２は、問題保持部１２２に保持されている問題チケットのタイトルを検索して、入力されたキーワードが含まれるタイトルを取得する。そして、入力受付部１０２は、検索した問題チケットのタイトルを一覧表示する。オペレータは、一覧のなかからインシデントチケットと関連付けできる問題チケットのタイトルを選択する。
さらに、インシデントチケットのタイトルをキーとして、既存の問題チケットに関連付けされている他のインシデントチケットのタイトルを検索できるように構成してもよい。現在作成中のインシデントチケットと同様のタイトルを持つ他のインシデントチケットが見つかった場合は、同一の問題チケットに関連付けする。

図１１（ａ）は、インシデント保持部１１２に格納されるインシデントチケットのテーブル２００の一例を示す。このテーブルには、図１０のフォーマット３０に入力された項目のすべてが格納されるが、図１１（ａ）ではそのうちの一部のみを示している。

インシデントＩＤ列２０２は、インシデントＩＤを示す。インシデントインパクト列２０４は、インシデントインパクト算出部１１４によって算出されたインシデントインパクトである。オペレータ列２０６は、オペレータの名称を示す。関連する問題ＩＤ列２０８は、図１０の問題チケット欄４１によってオペレータによって当該インシデントチケットと関連付けされた問題チケットがある場合、その問題チケットに割り振られた問題ＩＤを示す。エスカレーション管理部１０４は、問題チケット欄４１で関連付けされた問題チケットを問題保持部１２２から検索し、その問題チケットに付与された問題ＩＤを取得する。そして、取得した問題ＩＤを、インシデントＩＤと対応させて問題ＩＤ列２０８に記録する。

図１１（ｂ）は、オペレータ負荷算出部１１８によって算出されるオペレータ負荷の一例を示す。図１１（ａ）に示した、オペレータが担当するインシデントインパクトをオペレータ毎に加算することで、オペレータ負荷２１４が算出される。

テーブル２００、２１０は、表示出力部１０８によって、サービスデスク端末１２やマネージャ端末１８に出力される。サービスオペレータは、テーブル２００インシデントインパクトを参照することで、優先順位の高いインシデントを一目で判断できる。また、マネージャは、テーブル２１０のオペレータ負荷を参照することで、負荷の大きいオペレータを容易に把握することができる。

図１２は、問題管理部１２０における処理のフローチャートである。開発者が新たに問題チケットを作成するか、またはサービスオペレータがインシデントチケットを問題チケットに関連付けする（Ｓ３０）。作成された問題チケットは、問題保持部１２２に格納される（Ｓ３２）。関連付けされた場合は、対応する問題チケットのデータに関連付けされたインシデントチケットのインシデントＩＤが追加される。問題インパクト算出部１２４は、インシデント影響度、問題緊急度を決定し、上述の式にしたがって問題インパクトを算出する（Ｓ３４）。開発者負荷算出部１２８は、問題インパクトを使用して開発者毎に開発者負荷を算出する（Ｓ３６）。

図１３は、問題チケットを作成するためのフォーマット５０の一例を示す。このフォーマットは、例えば、ＨＴＭＬファイルの形式で開発者端末１４に送られ、開発者端末１４で動作するブラウザによってディスプレイに表示される。

問題ＩＤ５１は、問題管理部１２０によって問題チケットに自動的に割り当てられる通し番号である。ステータス欄５２には、当該問題について、新規、対応中、保留中、解決済みといったステータスを入力する。タイトル欄５３には、問題の内容を表すタイトルを入力する。対応期限日欄５４には、問題の対応期限日を入力する。開発者欄５５には、当該問題を担当する開発者名を入力する。内容欄５６には、問題の具体的な内容を入力する。経過欄５７には、問題に対して開発者が実施した調査、作業、回答の過程を入力する。

変更チケット欄５８は、開発者がプログラムの変更なしに問題に対応できないと判断したときに、問題チケットを既存の変更チケットと関連付けるときに使用する。変更チケット欄５８の右端をクリックすると、既存の変更チケットの変更対象であるプログラム名の一覧が表示されるので、開発者は、一覧のなかから問題と関連付けるプログラム名を選択する。
あるいは、問題チケットと関連付けできそうな変更チケットをキーワード検索できるように構成してもよい。入力受付部１０２は、フォーマット５０の一部に、変更チケットを検索するためのキーワード入力欄を表示する。オペレータが適当なキーワードを入力して検索ボタンをクリックすると、入力受付部１０２は、変更保持部１３２に保持されている変更チケットのタイトルを検索して、入力されたキーワードが含まれるタイトルを取得する。そして、入力受付部１０２は、検索した変更チケットのタイトルを一覧表示する。オペレータは、一覧のなかから問題チケットと関連付けできる変更チケットのタイトルを選択する。
さらに、問題チケットのタイトルをキーとして、既存の変更チケットに関連付けされている他の問題チケットのタイトルを検索できるように構成してもよい。現在作成中の問題チケットと同様のタイトルを持つ他の問題チケットが見つかった場合は、同一の変更チケットに関連付けする。

図１４（ａ）は、問題保持部１２２に格納される問題チケットのテーブル２２０の一例を示す。このテーブル２２０には、図１３のフォーマット５０に入力された項目のすべてが格納されるが、図１４（ａ）ではそのうちの一部のみを示している。

問題ＩＤ列２２２は、問題ＩＤを示す。問題インパクト列２２４は、問題インパクト算出部１２４によって算出された問題インパクトである。開発者列２２６は、開発者の名称を示す。関連するインシデントＩＤ列２２８には、図１０の問題チケット欄４１において当該問題チケットに関連付けされたインシデントチケットのインシデントＩＤが示される。関連する変更ＩＤ列２３０は、図１３の変更チケット欄５８において開発者によって選択された変更がある場合、その変更チケットに割り振られた変更ＩＤを示す。エスカレーション管理部１０４は、問題ＩＤをキーとしてインシデント保持部１１２を検索し、当該問題ＩＤと関連付けて記憶されているインシデントＩＤを取得する。そして、取得したインシデントＩＤを、問題ＩＤと対応させてインシデントＩＤ列２２８に記録する。また、エスカレーション管理部１０４は、変更チケット欄５８で関連付けされた変更チケットを変更保持部１３２から検索し、その変更チケットに付与された変更ＩＤを取得する。そして、取得した変更ＩＤを、問題ＩＤと対応させて変更ＩＤ列２３０に記録する。

図１４（ｂ）は、開発者負荷算出部１２８によって計算される開発者負荷の一例を示す。図１４（ａ）に示した、開発者２２６の担当する問題の問題インパクトを開発者毎に加算することで、開発者負荷２４４が算出される。

テーブル２２０、２４０は、表示出力部１０８によって開発者端末１４やマネージャ端末１８に出力される。開発者は、テーブル２２０の問題インパクトを参照することで、優先順位の高い問題を一目で判断できる。また、マネージャは、テーブル２４０の開発者負荷を参照することで、負荷の大きい開発者を容易に把握することができる。

図１５は、変更チケットを作成するためのフォーマット６０の一例を示す。このフォーマットも、ＨＴＭＬファイルの形式で運用担当者端末１６に送られ、運用担当者端末１６で動作するブラウザによってディスプレイに表示される。

変更ＩＤ６１は、変更管理部１３０によって変更チケットに自動的に割り当てられる通し番号である。ステータス欄６２には、当該変更について、新規、対応中、保留中、変更済みといったステータスを入力する。変更対象欄６３には、変更すべきプログラム名を入力する。対応期限日欄６４には、変更作業の対応期限日を入力する。担当者欄６５には、変更作業を担当する運用担当者名を入力する。内容欄６６には、変更作業の具体的な内容を入力する。

図１６は、変更保持部１３２に格納される変更チケットのテーブル２５０の一例を示す。このテーブルには、図１５のフォーマット６０に入力された項目のすべてが格納されるが、図１６ではそのうちの一部のみを示している。

変更ＩＤ列２５２は、変更ＩＤを示す。変更インパクト列２５４は、変更インパクト算出部１３４によって算出される変更インパクトを示す。関連する問題ＩＤ列２５６は、図１３の変更チケット欄５８において、当該変更に関連付けされた問題チケットの問題ＩＤが示される。エスカレーション管理部１０４は、変更ＩＤをキーとして問題保持部１２２を検索し、当該変更ＩＤと関連付けて記憶されている問題ＩＤを取得する。そして、取得した問題ＩＤを、変更ＩＤと対応させて問題ＩＤ列２５６に記録する。

サービスデスクでは、一般に、オペレータレベルで直接回答できないインシデントを他部門である開発部門にエスカレーションすることが行われる。このとき、インシデントの管理と開発の管理とが別々に行われていると、サポートを連携的にできないという問題がある。しかしながら、本実施形態によれば、サービスデスクにおけるインシデントへの回答、問題の解決、変更作業といった一連の処理を一元的に管理することができる。

一般に、オペレータ、開発者、運用担当者は一人で多数のインシデント、問題、変更を担当しているため、すべてに対して同等に対応するのは困難である。本実施形態では、インシデント、問題、および変更の対処の優先順位を判断するための基準としてそれぞれのインパクトを算出する。サービスオペレータ、開発者、運用担当者は、インパクトの大きなものから優先的に対応するようにする。こうすることで、それぞれの作業効率が改善する。

本実施形態では、インシデント、問題、変更といった各工程が他の工程と関連付けされているため、ひとつの工程についてのデータを変更すれば、他の工程についてもデータが変更される。例えば、インシデントインパクトの値は、問題インパクト、変更インパクトの算出にも間接的に使用されているため、インシデントの対応期限などに変更があった場合は、問題インパクトや変更インパクトの値が再計算される。したがって、その問題や変更の優先順位が入れ替わることも起こりえる。問題インパクト、変更インパクトについて、値の大きいものから優先的に処理するようにすることで、インシデントインパクトが大きいインシデントが優先的に解決され、また、より多数のインシデントを解決に導く問題や変更がより優先的に処理される。

さらに、インパクトをオペレータや開発者毎に加算してオペレータや開発者の負荷を算出するようにしたので、マネージャは負荷のばらつきを定量的に判定することができる。

以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
請求項に記載の各構成要件が果たすべき機能は、本実施例において示された各機能ブロックの単体もしくはそれらの連係によって実現されることも当業者には理解されるところである。

ある人物が、インシデント、問題、変更のうち複数を担当しているケース、つまり、同一人がオペレータ、開発者、運用担当者を兼業しているケースも考えられる。そのような場合は、各人についてオペレータ負荷、開発者負荷、運用担当者負荷をそれぞれ算出した上で、それらを合計した負荷を算出するようにしてもよい。

本実施形態に係るサービス管理装置を含むシステムの全体構成図である。 本実施形態におけるインシデント、問題、変更の間のつながりを概念的に説明する図である。 サービス管理装置のうち本実施形態に関与する部分の構成を示す図である。 顧客重要度の一例を示すテーブルである。 システム重要度の一例を示すテーブルである。 インシデント緊急度の一例を示すテーブルである。 問題緊急度の一例を示すテーブルである。 変更難易度の一例を示すテーブルである。 インシデント管理部における処理のフローチャートである。 インシデントチケットを作成するためのフォーマットの一例を示す図である。 （ａ）はインシデント保持部に格納されるインシデントチケットのテーブルであり、（ｂ）はオペレータ負荷算出部によって算出されるオペレータ負荷のテーブルである。 問題管理部における処理のフローチャートである。 問題チケットを作成するためのフォーマットの一例を示す図である。 （ａ）は問題保持部に格納される問題チケットのテーブルであり、（ｂ）は開発者負荷算出部によって計算される開発者負荷のテーブルである。 変更チケットを作成するためのフォーマットの一例を示す図である。 変更保持部に格納される変更チケットのテーブルの一例を示す図である。

符号の説明

１２ サービスデスク端末、 １４ 開発者端末、 １６ 運用担当者端末、 １８ マネージャ端末、 ２０ 顧客システム、 １００ サービス管理装置、 １０２ 入力受付部、 １０４ エスカレーション管理部、 １０８ 表示出力部、 １１０ インシデント管理部、 １１２ インシデント保持部、 １１４ インシデントインパクト算出部、 １１６ インシデント重要度保持部、 １１８ オペレータ負荷算出部、 １２０ 問題管理部、 １２２ 問題保持部、 １２４ 問題インパクト算出部、 １２６ 問題重要度保持部、 １２８ 開発者負荷算出部、 １３０ 変更管理部、 １３２ 変更保持部、 １３４ 変更インパクト算出部。

Claims (3)

1. 所定のサービスを提供するシステムに対する顧客からのインシデントを受け取ったオペレータによってインシデント毎に作成される、インシデントに関するデータを含むインシデントチケットを保持するインシデント保持部と、
   前記インシデントチケットのうちオペレータでは対応できないと判断されたインシデントに関するインシデントチケットと関連付けされる、前記システムの開発者が対応すべき問題に関するデータを含む問題チケットを保持する問題保持部と、
   前記問題チケットのうち、問題の解決のために前記システムのメンテナンスを必要とする問題チケットと関連付けされる、前記システムの運用担当者が実施すべき変更に関するデータを含む変更チケットを保持する変更保持部と、
   インシデントチケットに含まれる項目毎に、インシデント処理の優先順位に与える影響に基づいて予め設定された重要度を保持するインシデント重要度保持部と、
   前記インシデント重要度保持部を参照してインシデントの項目についてそれぞれ重要度を求め、それら重要度を掛け合わせて、オペレータによるインシデント処理の優先順位を決定するための指標であるインシデントインパクトを算出するインシデントインパクト算出部と、
   前記インシデントインパクト算出部によりインシデントの項目について求められた重要度を掛け合わせたインシデント影響度を算出し、問題に関連付けされているインシデントについてインシデント影響度を加算したものを使用して、開発者による問題の処理の優先順位を決定するための指標である問題インパクトを算出する問題インパクト算出部と、
   変更に関連付けされている問題を同定し、同定した問題に関連付けされているインシデントのインシデント影響度をすべて加算した問題影響度を求め、同定した問題すべてについて問題影響度を加算したものを使用して、運用担当者による変更の処理の優先順位を決定するための指標である変更インパクトを算出する変更インパクトを算出する変更インパクト算出部と、
   を備えることを特徴とするサービス管理装置。
2. オペレータ毎にそのオペレータが処理を受け持つインシデントを対象として前記インシデントインパクト算出部によって算出されたインシデントインパクトを加算したオペレータ負荷を算出するオペレータ負荷算出部をさらに備えることを特徴とする請求項１に記載のサービス管理装置。
3. 開発者毎にその開発者が担当している問題を対象として前記問題インパクト算出部によって算出された問題インパクトを加算した開発者負荷を算出する開発者負荷算出部をさらに備えることを特徴とする請求項１または２に記載のサービス管理装置。

Images