(57)【要約】【課題】インシデントを処理すべき担当者を、迅速かつ的確に決定したい。【解決手段】インシデント受付部１１１は、ユーザからの問い合わせ、サービス要求または運用管理ツールによる障害検出を、インシデントとして受け付ける。チケット保持部１２０は、インシデントごとに起票された電子的なチケットを保持する。担当者決定部１１２は、インシデント受付部１１１により受け付けたインシデントに対応すべき担当者を決定する。担当者決定部１１２は、チケット保持部１２０に保持されるチケットのうち、受け付けたインシデントと類似するインシデントを記録したチケットを特定し、そのチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定する。インシデントは、ツリー構造に分類して管理される。【選択図】図１
2011118685.tif 000002
【特許請求の範囲】
【請求項１】
システムサポート業務を支援するための業務支援装置であって、
ユーザからの問い合わせ、サービス要求または運用管理ツールによる障害検出を、インシデントとして受け付けるインシデント受付部と、
インシデントごとに起票された電子的なチケットを保持するチケット保持部と、
前記インシデント受付部により受け付けたインシデントに対応すべき担当者を決定する担当者決定部と、を備え、
前記担当者決定部は、前記チケット保持部に保持されるチケットのうち、受け付けたインシデントと類似するインシデントを記録したチケットを特定し、そのチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定することを特徴とする業務支援装置。
【請求項２】
インシデントは、ツリー構造に分類して管理され、
前記担当者決定部は、前記チケット保持部に保持されるチケットのうち、受け付けたインシデントの分類と、一致または最も近似する分類のインシデントを記録したチケットを特定し、そのチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定することを特徴とする請求項１に記載の業務支援装置。
【請求項３】
インシデントを管理するツリー構造を形成する各階層のスコアを記述したテーブルをさらに備え、
前記スコアは、上位階層の分類から下位階層の分類にいくにしたがって、高く設定され、
前記担当者決定部は、前記チケット保持部に保持されるチケットに記録されたインシデントの分類と、受け付けたインシデントの分類とを階層ごとに比較し、分類が一致した階層のスコアを合計した合計スコアをチケットごとに算出し、合計スコアが最も高いチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定することを特徴とする請求項２に記載の業務支援装置。
【請求項４】
前記担当者決定部は、受け付けたインシデントの分類と、一致または最も近似する分類のインシデントが複数存在する場合、最も近日に対応が完了したインシデントを優先することを特徴とする請求項２または３に記載の業務支援装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サービスデスク業務を支援するための業務支援装置に関する。
【背景技術】
【０００２】
ＩＴインフラが幅広いユーザ層に活用されるようになってきているなか、ＩＴサービスマネジメントがこれまで以上に重要になってきている。それに伴い、ＩＴサービスマネジメントを実行する上での業務プロセスの効率化が求められている。ＩＴサービスマネジメント・運用規則に関して、英国商務局（ＯＧＣ:Office of Government Commerce）はＩＴＩＬ（Information Technology Infrastructure Library）（登録商標）と呼ばれるベストプラクティス集を公表している。
【０００３】
ＩＴＩＬの中核の一つにサービスサポートがある。サービスサポートは日常的なシステム運用およびユーザサポートに関して記載されたもので、一つの機能と五つのプロセスからなる。機能としては、ユーザからの問い合わせ窓口となるサービスデスク、プロセスとしてはインシデント管理、問題管理、変更管理、リリース管理および構成管理が規定されている。
【０００４】
サービスデスク業務では、ユーザからどのような問い合わせがあったのか、それに対してどのように対応したのか、機能的／階層的エスカレーションは必要だったのか、その問い合わせは処理が終わってクローズしたのか、といった様々なことを記録することによりノウハウを蓄積していく。そのようなサービスデスク業務を支援するため、ユーザからの問い合わせをインシデントチケットとして蓄積していくシステムが実用化されている（たとえば、特許文献１、２参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−１２９９７３号公報
【特許文献２】特開２００５−０１１１４０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
サービスデスクには、多数の問い合わせやサービス要求が寄せられる。また、サービスデスクには、運用管理ツールからシステム障害検出も寄せられる。多数の問い合わせやサービス要求、およびシステム障害（以下、これらを総称してインシデントという）に対応するため、多数のオペレータや保守管理者（以下、これらを総称して担当者という）が動員される。これまで、サービスデスクで受け付けられたインシデントに対する担当者の割り当ては、部課長などの管理者が行うことが一般的であった。
【０００７】
このような状況下、受け付けられたインシデントに対して最適な担当者が割り当てられないことがあった。また、受け付けられたインシデントに対する担当者の割り当てが、なかなか決まらないことがあった。これらは、管理者の認識不足、判断のバラツキ、多忙など、管理者の能力不足やキャパシティオーバーに起因する。
【０００８】
本発明はこうした状況に鑑みなされたものであり、その目的は、インシデントを処理すべき担当者を、迅速かつ的確に決定する技術を提供することにある。
【課題を解決するための手段】
【０００９】
本発明のある態様の業務支援装置は、システムサポート業務を支援するための業務支援装置であって、ユーザからの問い合わせ、サービス要求または運用管理ツールによる障害検出を、インシデントとして受け付けるインシデント受付部と、インシデントごとに起票された電子的なチケットを保持するチケット保持部と、インシデント受付部により受け付けたインシデントに対応すべき担当者を決定する担当者決定部と、を備える。担当者決定部は、チケット保持部に保持されるチケットのうち、受け付けたインシデントと類似するインシデントを記録したチケットを特定し、そのチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定する。
【００１０】
なお、以上の構成要素の任意の組み合わせ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。
【発明の効果】
【００１１】
本発明によれば、インシデントを処理すべき担当者を、迅速かつ的確に決定することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態に係る業務支援システムの構成を示す図である。
【図２】チケット保持部に蓄積されるチケットのフォーマット例を示す図である（その１）。
【図３】チケット保持部に蓄積されるチケットのフォーマット例を示す図である（その２）。
【図４】インシデントをツリー構造に分類して管理する場合の一例を示す図である。
【図５】分類テーブルの一例を示す図である。
【図６】担当者決定処理の具体例１を説明するための図である。
【図７】担当者決定処理の具体例２を説明するための図である。
【図８】本発明の実施の形態に係る業務支援装置による、担当者決定処理の流れを示すフローチャートである。
【発明を実施するための形態】
【００１３】
図１は、本発明の実施の形態に係る業務支援システム５００の構成を示す図である。業務支援システム５００は、システムサポート業務を支援するべく、サービスデスクに設置される。業務支援システム５００は、業務支援装置１００およびコンソール端末装置２００を備える。業務支援装置１００は、少なくとも一台のサーバで構成することができる。たとえば、ウェブサーバおよびデータベースサーバで構成することができる。コンソール端末装置２００は、ＰＣで構成することができる。コンソール端末装置２００は、複数設置されることが可能である。図１では、一つの業務支援装置１００と複数のコンソール端末装置２００Ａ、Ｂ・・・とが、イントラネットなどの内部ネットワークにより接続され、サーバ／クライアントシステムを構成している。
【００１４】
業務支援装置１００は、制御部１１０、チケット保持部１２０および分類テーブル１３０、通信部１４０を備える。制御部１１０は、インシデント受付部１１１および担当者決定部１１２を含む。コンソール端末装置２００は、通信部２１０、制御部２２０、表示部２３０および操作部２４０を備える。
【００１５】
業務支援装置１００およびコンソール端末装置２００のそれぞれの構成は、ハードウェア的には、任意のコンピュータのＣＰＵ、メモリ、その他のＬＳＩで実現でき、ソフトウェア的にはメモリにロードされたプログラムなどによって実現されるが、ここではそれらの連携によって実現される機能ブロックを描いている。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組み合わせによっていろいろな形で実現できることは、当業者には理解されるところである。
【００１６】
インシデント受付部１１１は、ユーザからの問い合わせ、サービス要求または運用管理ツールによる障害検出を、インシデントとして受け付ける。チケット保持部１２０は、インシデントごとに起票された電子的なチケットを保持する。チケットに起票されたインシデントは、ツリー構造に分類して管理されてもよい。この管理例の詳細は後述する。
【００１７】
ユーザからの問い合わせ、サービス要求は、電話、ＦＡＸ、ハガキ、封書、電子メール、ウェブサイト内の入力フォームなどを介して、サービスデスクに寄せられる。サービスデスクのオペレータは、それらを介して寄せられた、問い合わせ内容およびサービス要求内容をコンソール端末装置２００の操作部２４０から打ち込み、上記チケットを起票する。なお、当該チケットのフォーマット例は後述する。
【００１８】
また、ウェブサイト内の入力フォームを通じて、問い合わせ情報、サービス要求情報が送信されてくる場合および運用管理ツールから障害検出情報が送信されてくる場合、上記フォーマット内の少なくとも一部の項目に、それらの内容が自動的に入力されてもよい。
【００１９】
担当者決定部１１２は、インシデント受付部１１１により受け付けたインシデントに対応すべき担当者を決定する。その際、担当者決定部１１２は、チケット保持部１２０に保持されるチケットのうち、受け付けたインシデントと類似するインシデントを記録したチケットを特定し、そのチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定する。この担当者決定の具体例は後述する。
【００２０】
分類テーブル１３０は、チケットに起票されたインシデントがツリー構造に分類して管理される場合に設けられる。その場合、分類テーブル１３０は、インシデントを管理するツリー構造を形成する各階層のスコアを記述する。分類テーブル１３０の具体例は後述する。通信部１４０は、コンソール端末装置２００の通信部２１０、図示しないユーザ端末の通信部、または図示しない管理運用ツールの通信部との間で、情報を送受信する。
【００２１】
コンソール端末装置２００の通信部２１０は、業務支援装置１００の通信部１４０または他のコンソール端末装置２００の通信部２１０との間で、情報を送受信する。制御部２２０は、コンソール端末装置２００全体を統括的に制御する。表示部２３０は、画面を表示する。本実施の形態では、主に、上記チケットの管理画面を表示する。操作部２４０は、オペレータまたは担当者の操作を受け付け、制御部２２０に伝達する。
【００２２】
図２は、チケット保持部１２０に蓄積されるチケットのフォーマット例を示す図である（その１）。図３は、チケット保持部１２０に蓄積されるチケットのフォーマット例を示す図である（その２）。チケット６００は、インシデントごとに起票される。図２、３に示すフォーマットでは、チケット６００は、基本情報６１０、分類情報６２０、経過情報６３０、起票日６４１およびクローズ日６４２を含む。
【００２３】
基本情報６１０は、項目として、ＩＤ６１１、ステータス６１２、システム名６１３、タイトル６１４、報告内容６１５、対応期限日６１６ａ、対応期限時刻６１６ｂ、発生環境６１７および手順書番号６１８を含む。ＩＤ６１１には、日単位で受付順にシリアルナンバーが割り当てられてもよい。ステータス６１２には、対応者が割り当てられる前は受付済が、対応者が割り当てられた後は割当済が入力される。
【００２４】
分類情報６２０は、項目として、原因区分６２１、難易度６２２、緊急度６２３、優先度６２４、システム６２５、ＯＳ６２６、ＯＳのバージョン６２７、アプリケーション６２８およびキーワード６２９を含む。原因区分６２１には、インシデントの発生原因が入力される。たとえば、「不具合」、「問い合わせ」、「作業依頼」などと入力される。難易度６２２には、インシデント解決の難易度が入力される。緊急度６２３には、客観的要因（たとえば、顧客業務に対する影響度）にもとづき決定される緊急度が入力される。優先度６２４は、客観的要因にビジネス的観点（たとえば、保守契約レベル、顧客ランク）が加味されて決定される優先度が入力される。たとえば、難易度６２２、緊急度６２３および優先度６２４には、「高」、「中」、「低」などが入力される。
【００２５】
システム６２５、ＯＳ６２６、ＯＳのバージョン６２７およびアプリケーション６２８は、インシデントを分類するための項目である。ここでは、インシデントを４階層で分類する例を描いているが、３階層未満で分類してもよいし、５階層以上で分類してもよい。たとえば、アプリケーションのバージョンを追加して５階層で分類してもよい。
【００２６】
経過情報６３０は、起票されたインシデントに対して、顧客への対応、復旧作業、会議など、何らかのアクションがとられるたびに生成される。経過情報６３０は、項目として、タイトル６３１、対応日６３２、対応時刻６３３、対応者６３４、対応先６３５、チャネル６３６、内容６３７および添付ファイル６３８を含む。チャネル６３６には、一つの経過が形成される要因となったチャネルが入力される。たとえば、電話、ＦＡＸ、メールおよび会議などが記載される。内容６３７には、顧客への対応内容、復旧作業内容、会議の決定事項などが入力される。それらの内容に関連する文書ファイルや図面ファイルなどが存在する場合、添付ファイル６３８に添付することができる。
【００２７】
起票日６４１には、チケットが起票された日付が入力される。クローズ日６４２には、当該チケットに管理されるインシデントに対する対応が終了した日付が入力される。
【００２８】
これらの項目は、基本的に、ユーザからの問い合わせ内容、社内マニュアル、サービスデスク管理者の指示などにもとづき、オペレータにより手入力される。なお、一部の項目について、システム的に自動入力されるよう設計してもよい。
【００２９】
図４は、インシデントをツリー構造に分類して管理する場合の一例を示す図である。図４では、４階層に分類して管理する例を描いている。第１分類がシステムの分類であり、第２分類がＯＳの分類であり、第３分類がＯＳのバージョンの分類であり、および第４分類がアプリケーションの分類である。
【００３０】
図４では、第１分類は、「サーバ」１０００、「メインフレーム」２０００、・・・を含む。第２分類は、「Ｗｉｎｄｏｗｓ」（登録商標、以下省略）１１００、「Ｌｉｎｕｘ」（登録商標、以下省略）１２００、・・・を含む。第３分類は、「ＸＰ」（「Ｗｉｎｄｏｗｓ  ＸＰ」登録商標、以下省略）１１１０、「Ｖｉｓｔａ」（「Ｗｉｎｄｏｗｓ  Ｖｉｓｔａ」登録商標、以下省略）１１２０、「ＲｅｄＨａｔ」（登録商標、以下省略）１２１０、「ＳＵＳＥ」（登録商標、以下省略）１２２０、・・・を含む。第４分類は、「Ｏｆｆｉｃｅ」（登録商標、以下省略）１１１１、１１２１、「ＩＥ（Ｉｎｔｅｒｎｅｔ  Ｅｘｐｌｏｒｅｒ）」（登録商標、以下省略）１１１２、１１２２、・・・を含む。
【００３１】
担当者決定部１１２は、チケット保持部１２０に保持されるチケットのうち、受け付けた新規インシデントの分類と、一致または最も近似する分類の過去インシデントを記録したチケットを特定し、そのチケットに記録された過去インシデントに対応した担当者を、当該新規インシデントの担当者に決定する。図２〜図４に示した例では、インシデントの分類は、分類情報６２０のシステム６２５、ＯＳ６２６、バージョン６２７およびアプリケーション６２８により特定することができる。たとえば、新規インシデントの４つの分類と、すべて一致する分類を持つ過去インシデントが存在する場合、その過去インシデントに対応した担当者を、当該新規インシデントの担当者に決定する。
【００３２】
図５は、分類テーブル１３０の一例を示す図である。当該分類テーブル１３０は、項目として、分類１３１およびスコア値１３２を含む。担当者決定部１１２は、分類テーブル１３０を参照して、分類をスコア値に変換することができる。
【００３３】
図５では、図４に示した４つの分類を前提としたテーブルを描いている。当該テーブルでは、第１分類が１．００、第２分類が２．００、第３分類が３．００および第４分類が４．００と設定されている。このように、スコア値は、上位階層の分類から下位階層の分類にいくにしたがって、高く設定されている。
【００３４】
担当者決定部１１２は、チケット保持部１２０に保持されるチケットに記録されたインシデントの分類と、受け付けたインシデントの分類とを階層ごとに比較し、分類が一致した階層のスコアを合計した合計スコアをチケットごとに算出し、合計スコアが最も高いチケットに記録されたインシデントに対応した担当者を、受け付けたインシデントの担当者に決定する。以下、この担当者決定処理の具体例を示す。
【００３５】
図６は、担当者決定処理の具体例１を説明するための図である。具体例１では、受け付けた新規インシデントの分類は、「サーバ」−「Ｗｉｎｄｏｗｓ」−「ＸＰ」−「Ｏｆｆｉｃｅ」である。過去インシデントＡの分類は、「サーバ」−「Ｗｉｎｄｏｗｓ」−「ＸＰ」−「ＩＥ」である。両者を比較すると、「サーバ」−「Ｗｉｎｄｏｗｓ」−「ＸＰ」が一致する。それらの分類のスコアは、１．００、２．００、３．００であるから、合計スコアは６．００となる。
【００３６】
過去インシデントＢの分類は、「サーバ」−「Ｗｉｎｄｏｗｓ」−「Ｖｉｓｔａ」−「Ｏｆｆｉｃｅ」である。同様に計算すると、合計スコアは７．００となる。以下、この合計スコアをすべての過去インシデントについて算出し、合計スコアが最も高い過去インシデントを特定する。その過去インシデント（図６では、インシデントＢ）は、上記新規インシデントと最も類似するものと推定できる。したがって、当該過去インシデントの担当者（図６では、鈴木）を、当該新規インシデントの担当者に決定する。
【００３７】
図７は、担当者決定処理の具体例２を説明するための図である。具体例２は、具体例１に、合計スコアが同じインシデントが複数存在する場合の処理を追加したものである。具体例２では、過去インシデントＣの分類も、過去インシデントＢと同様に、「サーバ」−「Ｗｉｎｄｏｗｓ」−「Ｖｉｓｔａ」−「Ｏｆｆｉｃｅ」である。この場合、クローズ日が最近の過去インシデントを選択する。ここでは、過去インシデントＣのほうがクローズ日が最近であるため、その担当者（図６では、高橋）を、当該新規インシデントの担当者に決定する。このように、担当者決定部１１２は、受け付けたインシデントの分類と、一致または最も近似する分類のインシデントが複数存在する場合、最も近日に対応が完了したインシデントを優先する。
【００３８】
図８は、本発明の実施の形態に係る業務支援装置１００による、担当者決定処理の流れを示すフローチャートである。まず、インシデント受付部１１１がインシデントを受け付けた場合（Ｓ７００のＹ）、そのインシデントのチケットが起票され、担当者決定部１１２は、そのチケットから、新規インシデントの全階層の分類を抽出する（Ｓ７０１）。
【００３９】
つぎに、変数ｉが初期値設定される（Ｓ７０２）。担当者決定部１１２は、新規インシデントの分類と、過去インシデント（ｉ）の分類とを階層ごとに比較し、一致する分類を特定する（Ｓ７０３）。担当者決定部１１２は、一致する分類を、分類テーブル１３０を参照してスコア値に変換し（Ｓ７０４）、変換したスコア値を合計する（Ｓ７０５）。
【００４０】
つぎに、変数ｉがインクリメントされる（Ｓ７０６）。このステップＳ７０３〜Ｓ７０６までの処理が、変数ｉが過去インシデント数を超えない間（Ｓ７０７のＮ）、繰り返される。変数ｉが過去インシデント数を超えると（Ｓ７０７のＹ）、担当者決定部１１２は、算出した合計スコアが最も高い過去インシデントを特定し、その過去インシデントの担当者を、上記新規インシデントの担当者に決定する（Ｓ７０８）。
【００４１】
以上説明したように本実施の形態によれば、新規インシデントの担当者に、過去に最も類似するインシデントを処理した担当者を自動的に割り当てることにより、新規インシデントの担当者を、迅速かつ的確に決定することができる。すなわち、人為的に担当者を決定する場合に発生しやすい、判断の遅れやバラツキを抑制することができる。また、分類をツリー構造で定義することにより、インシデント間の類似度をより正確に判定することができる。
【００４２】
また、分類の一致に対して、階層ごとに異なる重み付けを与えることにより、インシデント間の類似度をより正確に判定することができる。たとえば、図６に示した例では、システムの一致よりＯＳの一致を、ＯＳの一致よりアプリケーションの一致を、より重視することにより、類似度判定をより実体に近づけることができる。すなわち、ＯＳが一致していてもアプリケーションが異なる場合、担当者の経験値が活かされる度合いは小さいが、ＯＳが異なっていてもアプリケーションが一致している場合、担当者の経験値が活かせる度合いは大きいという、経験則を反映させることができる。
【００４３】
また、上記合計スコアが最大値の過去インシデントが複数存在する場合、クローズ日が直近の過去インシデントの担当者を優先することにより、そのインシデントに対する記憶が新しい担当者を選定することができる。
【００４４】
以上、本発明をいくつかの実施の形態をもとに説明した。これらの実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。
【００４５】
たとえば、上記具体例２では、上記合計スコアが最大値の過去インシデントが複数存在する場合に、クローズ日が直近の過去インシデントの担当者を優先する処理を説明した。この点、担当者決定部１１２は、上記合計スコアの最大値から、所定の設定範囲内（たとえば、１．００未満）に存在する過去インシデントをすべて抽出し、それら過去インシデントのうち、クローズ日が直近の過去インシデントの担当者を優先してもよい。
【００４６】
また、担当者決定部１１２は、上記合計スコアが高い順に、所定の設定数（たとえば、５）の過去インシデントを抽出し、それら過去インシデントのうち、クローズ日が直近の過去インシデントの担当者を優先してもよい。なお、これら二つの変形例をアンド条件で用いてもよい。
【００４７】
また、担当者決定部１１２は、上述したいずれかの手法により、複数の過去インシデントを抽出した後、それら過去インシデントの各担当者の業務混雑度に応じて、新規インシデントの担当者を決定してもよい。たとえば、業務混雑度が最も低い担当者に決定してもよい。これによれば、上述した効果に加えて、サービスデスクに所属する担当者の業務量を平準化することができる。
【００４８】
また、担当者決定部１１２は、上述したいずれかの手法により、複数の過去インシデントを抽出した後、それら過去インシデントの各担当者の業務混雑度およびそれら過去インシデントのクローズ日に応じて、新規インシデントの担当者を決定してもよい。この場合、業務混雑度とクローズ日までの日数をそれぞれスコアに変換するテーブルを設け、それらの合計スコアを算出すればよい。担当者決定部１１２は、当該合計スコアを参照して、新規インシデントの担当者を決定する。
【００４９】
また、上記合計スコアが最大値の過去インシデントが複数存在する場合に、担当者決定部１１２は、所定期間内における、当該合計スコアが最大値の過去インシデントを最も多く担当した担当者を優先してもよい。この場合、経験の多い担当者を選定することができる。
【符号の説明】
【００５０】
１００  業務支援装置、  １１０  制御部、  １１１  インシデント受付部、  １１２  担当者決定部、  １２０  チケット保持部、  １３０  分類テーブル、  １４０  通信部、  ２００  コンソール端末装置、  ２１０  通信部、  ２２０  制御部、  ２３０  表示部、  ２４０  操作部、  ５００  業務支援システム。
【図１】
2011118685.tif 000003
【図２】
2011118685.tif 000004
【図３】
2011118685.tif 000005
【図４】
2011118685.tif 000006
【図５】
2011118685.tif 000007
【図６】
2011118685.tif 000008
【図７】
2011118685.tif 000009
【図８】
2011118685.tif 000010