JP2020017005A - 保守管理プログラム、保守管理方法、及び情報処理装置 - Google Patents

Abstract

【課題】一実施形態は、保守依頼の優先度を評価する。【解決手段】一実施形態に係る保守管理プログラムは、システムに対して過去に実施された保守作業の複数の案件のなかから、システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、類似案件の優先度を評価し、類似案件に関する情報を、評価した優先度とともに表示するための表示情報を出力する、処理をコンピュータに実行させる。【選択図】図６

Description

本発明は、保守管理プログラム、保守管理方法、及び情報処理装置に関する。

近年、様々なシステムで保守契約が結ばれている。保守契約とは、例えば、保守対象のシステムに対するハードウェアやソフトウェアのメンテナンス、障害対応などのサービスを提供する契約であってよい。例えば、保守契約は、プリンタ、複合機、エレベータ、アプリケーションなどの運用で交わされている。保守契約を結ぶと、顧客は、例えば、契約対象の製品に関する問い合わせを行って対応を受けたり、製品に故障や不具合が発生した場合に、専門の修理担当者を呼んで対応を受けたりなどのサービスを受けることができる。

特開２０１１−７６１６１号公報 特開２０１１−１０３０３０号公報 特開２０１７−４５０７９号公報 特開２００７−１９９８０９号公報

保守契約において、顧客の製品に故障や不具合が発生した場合、対応を依頼する保守依頼を受ける。複数の保守依頼の対応時期が重なった場合、正しく優先順位を決めることができれば、顧客の業務に与える影響を小さく抑えながら複数の保守依頼に対応することができる。しかしながら、こうした優先順位付けの判断は、難しいことがあり、経験や知識を有する限定されたユーザが行っている。
１つの側面では、本発明は、保守依頼に対する優先度を評価することのできる技術を提供することを目的とする。

本発明の一つの態様の保守管理プログラムは、システムに対して過去に実施された保守作業の複数の案件のなかから、システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、類似案件の優先度を評価し、類似案件に関する情報を、評価した優先度とともに表示するための表示情報を出力する、処理をコンピュータに実行させる。

保守依頼の優先度を評価することが可能になる。

例示的な保守システムを示す図である。 例示的な保守作業の流れを説明する図である。 類似する案件の情報を取得する流れを示す表示画面を例示する図である。 実施形態に係る保守サーバのブロック構成を例示する図である。 実施形態に係る保守作業の流れを説明する図である。 実施形態に係る類似する案件の情報を取得する流れを示す表示画面を例示する図である。 案件の分類を例示する図である。 実施形態に係る閾値情報を例示する図である。 稼働不安定期の発生頻度と優先度の関係を表す不安定期優先度情報と稼働安定期の発生頻度と優先度の関係を表す安定期優先度情報とを例示する図である。 実施形態に係る案件情報を例示する図である。 実施形態に係る類似案件の検索と優先度の設定を実行する処理の動作フローを例示する図である。 例示的な優先度の設定例を示す図である。 実施形態に係る保守サーバを実現するためのコンピュータのハードウェア構成を例示する図である。

以下、図面を参照しながら、本発明のいくつかの実施形態について詳細に説明する。なお、複数の図面において対応する要素には同一の符号を付す。

図１は、例示的な保守システム１００を示す図である。図１の例では、保守システム１００は、例えば、保守サーバ１０１、顧客システム管理装置１０２、及び端末１０３を含み、これらはネットワーク１０５を介して接続されている。顧客システム管理装置１０２は、例えば、顧客に導入され保守契約が結ばれた様々なシステムを管理する装置である。例えば、顧客システム管理装置１０２は、管理対象のシステムに生じた異常を検知したり、システムの稼働のログを取ったりしてよい。また、顧客システム管理装置１０２は、例えば、保守契約を結ぶ顧客ごとに設置されてよく、更には、同じ顧客であっても拠点ごとに設置されてよい。保守サーバ１０１は、例えば、顧客のシステムで過去に発生した問題や、その問題に対して保守契約により提供した保守サービスの内容などに関する情報を保持してよい。なお、保守管理対象の顧客のシステムは、例えば、サーバや製造実行システム、品質管理のためのアプリケーションなどであってよい。端末１０３は、例えば、保守サーバ１０１を管理する管理者、保守依頼を受け付けるオペレータ、及び保守作業を担当する作業員などの保守サーバ１０１を利用するユーザが使用する端末であってよい。例えば、ユーザは、端末１０３を操作して、保守サーバ１０１や顧客システム管理装置１０２から保守依頼のあった顧客のシステムについての情報を取得し、端末１０３と接続された表示装置１１０の表示画面に情報を表示してよい。

図２は、例示的な保守作業の流れを説明する図である。例えば、保守サーバ１０１が提供するウェブページのフォームなどを介してユーザが入力した情報を受信し、保守サーバ１０１が保守依頼を受け付けたとする（Ｓ２０１）。なお、保守依頼の受け付けは、これに限定されるものではなく、例えば、メールや電話などその他の手法で受け付けられてもよい。この場合、例えば、メールや電話などで保守依頼を受け付けたオペレータは、端末１０３などを用いて保守依頼で受け付けた内容を保守サーバ１０１に入力してよい。

保守サーバ１０１は、保守依頼を受け付けると、受け付けた保守依頼を識別するための案件識別子を割り振る（Ｓ２０２）。

続いて、保守サーバ１０１の管理者は、保守依頼で受け付けた保守対象のシステムで発生した事象に関する情報を基に、過去事例の中から類似する案件を検索する（Ｓ２０３）。

図３は、類似する案件の情報を取得する流れを示す表示画面を例示する図である。図３の案件一覧画面３１１は、例えば、保守サーバ１０１が生成した過去に行われた保守作業の案件の一覧を示す表示画面である。そして、例えば、案件一覧画面３１１から類似案件テキスト検索フィールドに、検索文字列「在庫」を入力して検索を行った結果が、検索結果画面３１２に例示されており、案件名「在庫アンマッチ」のエントリが見つかっている。例えば、検索結果画面３１２からユーザがエントリを選択するなどしてエントリを開くと、案件に対する一品一葉画面３１３が表示される。

そのため、保守作業を実行する作業者は、例えば、保守依頼で受け付けた事象と類似する類似案件を検索して、その一品一葉画面３１３の内容を参照することで、保守依頼のあった事象に関連する情報を参考にして、保守作業を行うことができる（Ｓ２０４）。

ところで、例えば、対応時期が重なった複数の保守依頼を受け付けることがある。その様な場合に、複数の保守依頼のそれぞれで発生した事象が顧客の業務に与える影響や、対応の緊急性を判断することができれば、複数の保守依頼に対して優先順位を付けることができる。その結果、優先順位に従って、顧客の業務に与える影響を小さく抑えながら複数の保守依頼に対応することができる。

しかしながら、例えば、一品一葉画面３１３などから類似案件の情報を見たとしても、保守対象となるシステムに関しての知識と経験が不足しているユーザでは、受け付けた事象の業務への影響度や対応の緊急度を正しく判断することが難しいことがある。そのため、こうした保守依頼に対する優先順位付けなどの判断は、十分な経験を積んだ限られた人員が行っている。こうした属人化された判断は、業務のボトルネックとなり得、また、引継ぎが難しく、人員の補填が難しいなど様々なリスクとなり得るため、解消することが望ましい。そのため、例えば、保守依頼に対する優先度を評価することのできる技術の提供が望まれている。

そこで、以下で述べる実施形態では、保守サーバ１０１は、保守依頼に対し、過去に類似案件に対して実行した保守作業の密度（以下、作業密度と呼ぶことがある）に基づいて、保守依頼のあった事象に優先度を設定する。作業密度は、例えば、案件に対してどれだけ過密に作業が行われたのかを示す指標であってよい。以下、実施形態を更に詳細に説明する。

図４は、実施形態に係る保守サーバ１０１のブロック構成を例示する図である。保守サーバ１０１は、例えば、制御部４０１、記憶部４０２、及び通信部４０３を含んでいる。制御部４０１は、例えば、評価部４１１、及び出力部４１２などとして動作してよい。保守サーバ１０１の記憶部４０２は、例えば、後述する閾値情報８００、不安定期優先度情報９０１、安定期優先度情報９０２、及び案件情報１０００などの情報を記憶している。通信部４０３は、例えば、制御部４０１の指示に従って、顧客システム管理装置１０２や端末１０３と通信してよい。これらの各部の詳細及び記憶部４０２に格納されている情報の詳細については後述する。

図５は、実施形態に係る保守作業の流れを説明する図である。例えば、保守サーバ１０１の制御部４０１が、顧客システム管理装置１０２などから保守依頼を受け付けたとする（Ｓ５０１）。すると、保守サーバ１０１の制御部４０１は、受け付けた保守依頼の案件（以下、依頼案件と呼ぶことがある）を識別するための案件識別子を発行し、受け付けた保守依頼の案件に割り振る（Ｓ５０２）。

続いて、保守サーバ１０１の制御部４０１は、保守依頼で受け付けた案件の情報を基にユーザから入力された情報に基づいて、過去事例の中から類似する案件を検索し、見つかった類似案件の優先度を評価する（Ｓ５０３）。例えば、図６には、案件一覧画面６１１が示されており、類似案件テキスト検索フィールドに、ユーザが検索文字列「在庫」を入力して検索を行った結果が、検索結果画面６１２に示されており、案件名：在庫アンマッチを有する類似案件が見つかっている。そして、実施形態では、制御部４０１は、検索結果画面６１２に例示するように、エントリに含まれる情報から案件に優先度を付し、得られた優先度を案件の情報とともに表示している。

続いて、制御部４０１は、類似案件の優先度に基づいて、保守依頼を受けた案件の優先度を決定する。例えば、制御部４０１は、見つかった類似案件のうちで最も多かった優先度を、保守依頼を受けた案件の優先度として用いてもよい（Ｓ５０４）。

続いて、制御部４０１は、例えば、複数の保守依頼を受けた場合などに対応時期が重なっている複数の案件に対し、優先度に基づいて優先順位をつけて、作業の順序を決定する（Ｓ５０５）。

その後、制御部４０１は、例えば、優先順位の高い案件に対する一品一葉画面６１３を端末１０３の表示装置に表示させるなどを実行し、ユーザは一品一葉画面６１３を参照して、保守作業を実行する（Ｓ５０６）。

以上で述べたように、実施形態によれば、保守依頼のあった案件の優先度を決定することができるため、優先順位付けを行うことができ、効率的な作業の実行が可能である。

以下では、保守依頼のあった案件に対する優先度の決定について詳細を述べる。保守依頼のあった案件に対する優先度を決定するために、顧客のシステムに発生した事象が顧客の業務に与える影響度と、求められる作業の緊急度とを考慮することが考えられる。例えば、顧客のシステムに与える影響が大きい事象が発生した案件は、顧客のシステムに与える影響が小さな事象が発生した案件よりも優先的に作業することが望ましい。また、例えば、顧客への納品までの期間が短い案件は、顧客への納品に余裕の或る案件よりも優先的に作業することが望ましい。

図７は、案件の分類を例示する図である。図７（ａ）には、横軸に作業の緊急度をとり、縦軸に顧客の業務への影響度をとって区分けされた、領域１、領域２、領域３、領域４の４つの領域が示されている。

図７（ａ）において領域１は、業務への影響度が高く、且つ、納期も短いため、優先度が高い。領域１に当てはまる保守作業としては、例えば、業務停止、サーバダウン、経理の〆直前での在庫のアンマッチなどの事象が挙げられる。

また、領域４は、業務への影響度が小さく、且つ、納期も余裕があるため、優先度が低い。領域４に当てはまる保守作業としては、例えば、保守対応マニュアルの作成などが挙げられる。

領域２は、納期は急がないが業務への影響が大きく、領域３は、業務への影響が小さいが納期は急ぎであり、優先度はどちらも、領域１よりは低いが領域４よりは高く、領域２と領域３は優先度を中としている。領域２に当てはまる保守作業としては、例えば、システムの改造や、バージョンアップなどの作業が挙げられる。また、領域３に当てはまる保守作業としては、例えば、製品固体の実績結果抜け、ハンディターミナル誤操作、出荷数調査依頼などが挙げられる。

以上で述べた様に、案件の優先度を案件で発生した事象が業務に与える影響度と、求められる作業の緊急度とから分類し、優先順位をつけることができる。

ここで、緊急度を計る指標として、例えば、リードタイムを用いることができる。リードタイムは、例えば、依頼があってから納品までの期間を示す。そのため、リードタイムが短い場合、緊急の案件であったと推定することができ、一方、リードタイムが長い場合、納期に余裕のある案件であったと推定することができる。

また、影響度を計る指標として、例えば、工数を用いることができる。工数は、例えば、作業量を表す値である。工数は、例えば、時間×人数で表現される。例えば、工数が４０時間であれば、一人で作業すると４０時間かかる作業量であることを示す。工数が大きいことは作業量が多いことを表し、システムに大きな変更が加えられることが推定される。即ち、工数が大きい場合、顧客の業務への影響が大きい事象が発生した案件であると推定することができる。一方、工数が少ない場合、直ぐに完了する作業であり、顧客の業務への影響が小さい事象が発生した案件であると推定することができる。

図７（ｂ）は、以上の観点から図７（ａ）をリードタイムと工数とを用いた軸に置き換えて表現した図である。領域１は、工数が大きく業務への影響度が高いのに、リードタイムも短く過密に作業をして納期に間に合わせなければならない案件であり、優先度が高い。

一方、領域４は、工数が小さく、直ぐに対処できる事象が発生した案件であり、業務への影響度が小さいことが推定され、且つ、リードタイムの長く、納期にも余裕のある案件であることが推定され、優先度は低い。

領域２は、納期に余裕があるが作業量が大きく、領域３は、作業量が少ないが納期が短い案件であり、優先度はどちらも、領域１よりは低いが領域４よりは高くなり、ここでは優先度を中とする。

ここで、領域１に当てはまる案件は、例えば、工数／リードタイムの値に対して閾値を設定することで抽出することができる。例えば、領域１の案件では、工数が大きく、一方、リードタイムは短いため、工数／リードタイムは大きな値となる。なお、工数／リードタイムは、例えば、作業の密度を表している。例えば、工数が４０時間で、リードタイムが８時間であったとする。この場合、一人で８時間作業したとしても工数８時間で、作業完了にかかる工数４０時間には届かず、リードタイム内には作業が終わらない。４０÷８＝５人なので、少なくとも５人以上の人員を割いて、１人で作業する場合の５倍の作業密度で作業を行って納期に間に合わせたことになる。この様に、例えば、工数／リードタイムが、１よりも大な値を有する場合、１人よりも多い複数人の人員を割いて作業が行われたことを表している。そして、例えば、工数／リードタイムが第１の閾値よりも高ければ、作業密度が高いことを表すように第１の閾値を設定することで、図７の領域１に含まれる案件を抽出することができる。領域１に含まれる案件を抽出するための閾値としては、例えば、１．０よりも大きな値が用いられてよく、２〜５の範囲の値であってよく、一例では、３であってよい。

また、領域４に当てはまる案件は、例えば、工数／リードタイムをとった場合、工数が小さく、リードタイムが大きいため、小さな値となる。例えば、工数が１時間で、リードタイムが１０時間であったとする。この場合、１÷１０＝０．１で、工数に対して納期に余裕があり、直ぐに着手しなくても他の保守作業を手掛けてからでも間に合い、１人でリードタイム内に作業を終わらせることが可能である。即ち、工数／リードタイムが、例えば、１よりも小さな値を有する場合、１人でも時間に余裕を持って作業に当たれる可能性が高いことを表している。そして、例えば、工数／リードタイムが第２の閾値よりも低ければ作業密度が低いことを表すように第２の閾値を設定することで、図７の領域４に含まれる案件を抽出することができる。領域４に含まれる案件を抽出するための閾値としては、例えば、１．０よりも小さな値が用いられてよく、０．０１〜０．５の範囲の値であってよく、一例では、０．１であってよい。

一方で、領域２に当てはまる案件は、工数が多いがリードタイムも長く、領域３に当てはまる案件は、工数が少ないがリードタイムも短く、従って、これらの領域２と領域３では、工数／リードタイムは類似した値をとる。領域２又は領域３に含まれる案件は、例えば、第１の閾値以下で、第２の閾値以上の工数／リードタイムの値を有する案件として、抽出することができる。

以上で述べた様に、工数／リードタイムの値に対して、第１の閾値と第２の閾値を設定することで、過去に保守作業を実行した工数とリードタイムが明らかな案件に対して優先度を、以下のように設定することができる。
優先度：高（第１の優先度） 工数／リードタイムが第１の閾値よりも大きい
優先度：中（第２の優先度） 工数／リードタイムが第１の閾値以下で第２の閾値以上
優先度：低（第３の優先度） 工数／リードタイムが第２の閾値未満

別の記載をすると、例えば、保守作業のリードタイムよりも工数の方が所定の比率を超えて大きい場合、類似案件に優先度：高（第１の優先度）が設定されてよい。一方、リードタイムよりも工数の方が所定の比率を超えて大きくはない場合、類似案件に優先度：高（第１の優先度）よりも低い優先度：中（第２の優先度）が設定されてよい。また、保守作業のリードタイムよりも工数の方が所定の比率を下回って小さい場合、類似案件に優先度：低（第３の優先度）が設定されてよい。リードタイムよりも工数の方が所定の比率を下回って小さくはない場合に、類似案件に優先度：低（第３の優先度）よりも高い優先度：中（第２の優先度）が設定されてよい。

図８は、以上の実施形態に係る閾値情報８００を例示する図である。閾値情報８００には、例えば、以上で述べた優先度ごとに定められた閾値による範囲が登録されている。例えば、記憶部４０２には、閾値情報８００などの第１の閾値及び第２の閾値を示す情報が記憶されていてよい。

なお、優先度：中の案件は、更に、案件と対応する事象の発生頻度に基づいて、より細かく優先度が決定されてもよい。以下では、発生頻度に基づく優先度の決定を説明する。

（発生頻度に基づく優先度の決定）
図７の領域２又は領域３に含まれる優先度：中の案件を更に、案件と対応する事象の発生頻度に基づいて分類し、優先度を設定することが考えられる。なお、類似事象の発生頻度に基づいて優先度を設定する場合、システムが稼働状態に応じて異なる優先度を設定してよい。

例えば、システムの稼働が不安定で、様々な事象が頻繁に発生している状況がある。以下、様々な事象が頻繁に発生している状況を稼働不安定期と呼ぶことがある。稼働不安定期の例としては、システムを導入したばかりの稼働初期、システムに改造などの変更を施した後、システムの一部を交換した後などが挙げられる。このような、様々なエラーが発生する稼働が不安定な時期には、発生頻度の高い事象から解決していった方が、事象の発生数を効率的に減らすことができる。そのため、稼働不安定期では、発生頻度の高い事象に、発生頻度の低い事象よりも高い優先度を設定してよい。

一方、システムの稼働を開始してからある程度のエラーを解消すると、システムが安定して稼働し始める。なお、システムが安定して稼働している状況を稼働安定期と呼ぶことがある。システムが稼働安定期にある場合、発生頻度の高い事象については、対応が頻繁に行われて事例の蓄積が十分にあり、不測の事態が発生して対応に手間取ったりする可能性は低い。一方、発生頻度が低い事象は、まだ対応した経験が浅く、対応に時間がかかる可能性もある。そのため、稼働安定期では、発生頻度の高い事象に、発生頻度の低い事象よりも低い優先度を設定してよい。

図９は、以上で述べた、稼働不安定期の発生頻度と優先度の関係を表す不安定期優先度情報９０１と、稼働安定期の発生頻度と優先度の関係を表す安定期優先度情報９０２とを例示する図である。稼働不安定期の状態は様々な事象が頻繁に発生している状況にあるため、不安定期優先度情報９０１では、例として、週単位の短い期間での発生回数を用いて発生頻度としている。そして、例えば、図９の不安定期優先度情報９０１では、発生頻度が週あたりに所定値（例えば、３より多い）を超えており、多い場合に、優先度：中の高を設定している。一方、発生頻度が週あたりに所定値以下（例えば、３以下）で少ない場合に、優先度：中の低を設定している。なお、中の高は、中の低よりも優先度が高い。

一方、稼働安定期にはシステムは安定して稼働しており、事象の発生回数も稼働不安定期と比較して少ない状況にあるため、不安定期優先度情報９０１では、例として、年単位の長い期間での発生回数を用いて発生頻度としている。そして、例えば、図９の安定期優先度情報９０２では、発生頻度が年あたりに所定値以下（例えば、５以下）で少ない場合に、優先度：中の高を設定している。一方、図９の安定期優先度情報９０２では、発生頻度が年あたりに所定値（例えば、５よりも多い）を超えており、多い場合に、優先度：中の低を設定している。

以上で述べた様に、制御部４０１は、工数及びリードタイムと、発生頻度から過去の案件に優先度を決定することが可能である。そのため、実施形態では過去の事例を記憶する案件情報１０００は、工数、リードタイム、及び発生頻度を特定するための情報を含んでいる。

図１０は、実施形態に係る案件情報１０００を例示する図である。案件情報１０００には、例えば、或るシステムにおいて過去に実施した保守作業に関する情報を含むエントリが登録されている。図１０の例では、案件情報１０００のエントリは、案件名、案件識別子、発生日、事象、及び対応状況を含む。また更に、図１０の例では、案件情報１０００のエントリは、優先度の評価に用いる工数、リードタイム、及び案件識別キーなどの情報を含んでよい。

案件名は、例えば、エントリと対応する保守依頼のあった案件に対して設定された名称である。案件識別子は、例えば、エントリと対応する保守依頼を識別するために割り当てた識別子である。発生日は、例えば、エントリと対応する保守依頼を受け付けた日時である。事象は、例えば、エントリと対応する保守依頼で受け付けたシステムに起きた事象を示す情報である。対応状況は、例えば、エントリと対応する保守依頼に対して実施した保守作業の内容が登録されていてよい。

また、工数は、例えば、エントリと対応する保守依頼の保守作業でかかった工数である。リードタイムは、例えば、エントリと対応する保守依頼を受けてから保守作業を完了して納品を終えるまでの期間である。案件識別キーは、例えば、エントリと対応する保守依頼で発生した事象の分類を示す情報であり、類似する事象には同じ識別子が割り当てられてよい。案件識別キーは、例えば、エントリと対応する保守依頼においてシステムに発生した事象を、その原因や事象の特徴などに基づいて分類して得られる各分類群に付した識別情報である。案件識別キーは、例えば、保守作業を実施したユーザが、エントリと対応する保守依頼においてシステムに発生した事象を分類することで設定されてよい。

例えば、保守サーバ１０１の記憶部４０２には以上の情報を含む案件情報１０００が記憶されていてよい。

続いて、類似案件の検索と優先度の設定する処理を説明する。図１１は、実施形態に係る類似案件の検索と優先度の設定を実行する処理の動作フローを例示する図である。例えば、保守サーバ１０１の制御部４０１は、ユーザの端末１０３から類似案件を検索するためのアクセスを受け付けると、図１１の動作フローを開始してよい。なお、図１１の動作フローは、例えば、図５のＳ５０３の処理と対応しており、制御部４０１は、図５の処理において、Ｓ５０３の処理の代わりに、図１１の動作フローを実行してよい。

Ｓ１１０１において制御部４０１は、ユーザの端末１０３から案件一覧の表示指示を受け付ける。例えば、ユーザは、端末１０３の表示画面に表示された案件一覧を表示するボタンを選択することで、端末１０３から保守サーバ１０１に、案件一覧の表示指示を送信してよい。

Ｓ１１０２において制御部４０１は、案件情報１０００を用いて案件の一覧の表示データを生成して端末１０３に送信し、端末１０３の表示画面に表示させる。案件の一覧の表示画面は、例えば、案件一覧画面６１１であってよい。

Ｓ１１０３において制御部４０１は、類似案件の検索指示を受け付ける。例えば、ユーザは、端末１０３の表示画面に表示された案件一覧の類似案件テキスト検索フィールドに検索する文字列を入力し、検索のボタンを選択することで、端末１０３から保守サーバ１０１に、検索指示を送信することできる。

Ｓ１１０４において制御部４０１は、案件情報１０００から検索指示で検索キーワードとして入力された文字列で識別される類似案件を検索する。例えば、制御部４０１は、検索キーワードとして入力された文字列を含むエントリを、案件情報１０００から検索してよい。なお、Ｓ１１０４で複数の類似案件が見つかった場合、続くＳ１１０５からＳ１１１８までの処理は、Ｓ１１０４で検索された類似案件ごとに実行されてよい。以下では、１つの類似案件に対する処理を例として説明する。

Ｓ１１０５において制御部４０１は、検索された類似案件で実施された保守作業の作業密度を算出する。例えば、制御部４０１は、検索された類似案件のエントリから工数とリードタイムの情報を取得し、作業密度を表す“工数／リードタイム”を算出する。

Ｓ１１０６において制御部４０１は、閾値情報８００を参照し、算出された工数／リードタイムが含まれる作業密度範囲と対応する優先度を特定する。そして、例えば、工数／リードタイムが第２の閾値未満で優先度“低（第３の優先度）”が特定された場合、フローはＳ１１０７に進む。Ｓ１１０７において、制御部４０１は、類似案件の優先度を“低（第３の優先度）”に設定し、フローはＳ１１１８に進む。

一方、Ｓ１１０６で特定した優先度が“中（第２の優先度）”である場合、フローはＳ１１０８に進む。Ｓ１１０８において制御部４０１は、保守依頼を受け付けたシステムが現在、稼働安定期にあるか否かを判定する。例えば、制御部４０１は、保守依頼を受け付けた日時の過去１週間に、保守依頼を受け付けたシステムについて受信した保守依頼の件数を算出する。制御部４０１は、例えば、案件情報１０００において発生日が現在より遡って１週間以内にあるエントリの数をカウントすることで件数を算出してよい。そして、制御部４０１は、得られた件数が所定の閾値以上の場合、稼働安定期ではないと判定し（Ｓ１１０８がＮｏ）、フローはＳ１１０９に進む。

Ｓ１１０９において制御部４０１は、検索された類似案件と類似する事象の直近の一週間あたりの発生回数を発生頻度として算出する。例えば、制御部４０１は、検索された類似案件の案件識別キーと同じ案件識別キーを有するエントリを、案件情報１０００の発生日が、過去一週間以内の案件のうちから特定し、その発生回数をカウントして発生頻度を求めてよい。

Ｓ１１１０において制御部４０１は、算出した発生回数と、稼働不安定期に対する不安定期優先度情報９０１に基づいて、優先度を判定する。例えば、図９（ａ）の不安定期優先度情報９０１を用いる場合、週当たりの発生回数が所定値（例えば、３回）以下であれば（Ｓ１１１０がＮｏ）、フローはＳ１１１１へと進み、優先度：中の低と判定する。一方、週当たりの発生回数が所定値（例えば、３回）より多ければ（Ｓ１１１０がＹｅｓ）、フローはＳ１１１２へと進み、制御部４０１は、優先度：中の高と判定する。

また、Ｓ１１０８において保守依頼を受け付けたシステムが現在、稼働安定期にある場合（Ｓ１１０８がＹｅｓ）、フローはＳ１１１３に進む。例えば、制御部４０１は、保守依頼を受け付けた日時から過去１週間に、保守依頼を受け付けたシステムについて受信した保守依頼の件数を算出する。制御部４０１は、例えば、発生日が現在より遡って１週間以内にあるエントリの数をカウントすることで件数を算出してよい。そして、制御部４０１は、得られた件数が所定の閾値よりも少ない場合、稼働安定期であると判定し（Ｓ１１０８がＹｅｓ）、フローはＳ１１１３に進む。

Ｓ１１１３において制御部４０１は、検索された類似案件と類似する事象の直近の一年間あたりの発生回数を発生頻度として算出する。例えば、制御部４０１は、検索された類似案件の案件識別キーと同じ案件識別キーを有するエントリを、案件情報１０００の発生日が、過去一年間以内の案件のうちから特定し、その発生回数をカウントして発生頻度を求めてよい。

Ｓ１１１４において制御部４０１は、算出した発生回数と、稼働安定期に対する安定期優先度情報９０２に基づいて、優先度を判定する。例えば、図９（ｂ）の安定期優先度情報９０２を用いる場合、年当たりの発生回数が所定値（例えば、５回）より多ければ（Ｓ１１１０がＹｅｓ）、フローはＳ１１１５へと進み、優先度：中の低と判定する。一方、週当たりの発生回数が所定値（例えば、５回）以下であれば（Ｓ１１１０がＮｏ）、フローはＳ１１１６へと進み、制御部４０１は、優先度：中の高と判定する。

また、Ｓ１１０６において工数／リードタイムが第１の閾値より大きく優先度“高（第１の優先度）”が特定された場合、フローはＳ１１１７に進む。Ｓ１１１７において、制御部４０１は、類似案件の優先度を“高（第１の優先度）”に設定し、フローはＳ１１１８に進む。

以上のＳ１１０５〜Ｓ１１１７までの処理により、検索された類似案件のそれぞれに優先度が決定される。そして、Ｓ１１１８において制御部４０１は、検索された類似案件に対する案件情報１０００のエントリの情報と、決定した優先度と用いて生成した表示情報を端末１０３に送信する。端末１０３は、例えば、受信した表示情報を表示装置に表示することで、例えば、図６に例示した検索結果画面６１２などの優先度を含む検索結果を表示する。

そして、Ｓ１１１９において制御部４０１は、検索結果画面６１２に表示した類似案件の選択を受け付ける。例えば、端末１０３において、表示された検索結果画面６１２のうちから類似案件を選択する入力がなされたことを示す通知を、保守サーバ１０１が受信すると、フローはＳ１１２０に進む。Ｓ１１２０において制御部４０１は、選択された案件に関する情報を表示するための表示情報を、端末１０３に送信し、本動作フローは終了する。端末１０３は、例えば、選択された案件に関する情報を表示するための表示情報を受信すると、その表示情報に基づいて、一品一葉画面６１３などを表示装置に表示してよい。

以上で述べた様に、図１１の動作フローによれば、制御部４０１は、類似案件に優先度の情報を付すことができる。そのため、類似案件を検索したユーザは、保守依頼を受けた案件の優先度を、検索された類似案件の優先度から推定することができる。

なお、制御部４０１は、例えば、Ｓ５０３の代わりに、上記の図１１の動作フローを実施した場合、Ｓ５０４において類似案件の優先度に基づいて、保守依頼を受け付けた案件に対して優先度を設定してよい。例えば、制御部４０１は、類似案件に対して決定された優先度のうち、最も多い優先度に、保守依頼を受け付けた案件の優先度を設定してよい。或いは、制御部４０１は、類似案件に対して決定された優先度のうち、最も高い優先度に、保守依頼を受け付けた案件の優先度を設定してよい。そして、続くＳ５０５において制御部４０１は、保守作業の実行対象として現在登録されている複数の案件を、優先度が高い方から低い方に順に並ぶように並べ替えて実行順序に優先順位を付ける。なお、同じ優先度を有する複数の案件があれば、それらの案件は任意の順序で並べられてよく、一例では、制御部４０１は、保守依頼を受け付けた日時の早い案件が先になるように優先順位を設定してよい。また、保守作業の実行対象となる複数の案件は、例えば、ユーザが保守依頼を受けて保守サーバ１０１に登録した保守作業が未完了の案件であってよい。Ｓ５０６では制御部４０１は、例えば、保守作業を担当するユーザの端末１０３に優先順位の最も高い案件の保守依頼を送信してよく、保守作業を担当するユーザは、端末１０３で受信された優先順位の最も高い案件についての保守作業を開始する。

図１２は、例示的な優先度の設定例を示す図である。図１２（ａ）には、ケース１からケース４の４つの事例が示されている。ケース１は、工数が４０時間で、リードタイムが８時間であり、作業密度（例えば、工数／リードタイム）は５であるため、閾値情報８００に基づいて、制御部４０１は、ケース１の案件を優先度：高と判定する。

一方、ケース４は、工数が４時間で、リードタイムが８０時間であり、作業密度（例えば、工数／リードタイム）は０．０５であるため、閾値情報８００に基づいて、制御部４０１は、ケース４の案件を優先度：低と判定する。

また、ケース２は、工数が２時間で、リードタイムが１０時間であり、作業密度（例えば、工数／リードタイム）は０．２であるため、閾値情報８００に基づいて、制御部４０１は、ケース２の案件を優先度：中と判定する。

ケース３についても、工数が２０時間で、リードタイムが４０時間であり、作業密度（例えば、工数／リードタイム）は０．５であるため、閾値情報８００に基づいて、制御部４０１は、ケース３の案件を優先度：中と判定する。

続いて、制御部４０１は、優先度：中と判定されたケース２及びケース３について、発生頻度に基づいて更に優先度を付す。図１２（ｂ）は、例えば、稼働不安定期における優先順位の設定を例示しており、ケース２では週当たりの発生頻度が３よりも多いため、制御部４０１は、不安定期優先度情報９０１に基づいて優先度：中の高と判定する。一方、ケース３は、例えば、週当たりの発生頻度が３以下であるため、制御部４０１は、不安定期優先度情報９０１に基づいて優先度：中の低と判定する。

また、図１２（ｃ）は、例えば、稼働安定期における優先順位の設定を例示しており、ケース２では年当たりの発生頻度が５よりも多いため、制御部４０１は、安定期優先度情報９０２に基づいて優先度：中の低と判定する。一方、ケース３は、例えば、年当たりの発生頻度が５以下であるため、制御部４０１は、安定期優先度情報９０２に基づいて優先度：中の高と判定する。以上で述べた様に、制御部４０１は、案件情報１０００に登録されたエントリに優先度を割り当てることができる。そのため、顧客の業務に与える影響を小さくする順序で保守作業を実施することができる。また、緊急度の低い案件であっても予定納期を素早く顧客に回答することが可能になり、顧客が次のアクションプランを計画し易くなる。なお、上記の例では優先度は、高＞中の高＞中の低＞低の順で実行順序が優先されてよい。

以上において、実施形態を例示したが、実施形態はこれに限定されるものではない。例えば、上述の動作フローは例示であり、実施形態はこれに限定されるものではない。可能な場合には、動作フローは、処理の順番を変更して実行されてもよく、別に更なる処理を含んでもよく、又は、一部の処理が省略されてもよい。例えば、図１１の動作フローにおいて、優先度を中と判定したあとの発生頻度に基づくＳ１１０８〜Ｓ１１１６までの処理は実行されなくてもよく、優先度：中がそのまま案件の優先度として用いられてもよい。また、図１１の処理の後に、Ｓ５０４〜Ｓ５０６の処理が続けて実行されてもよいし、別の実施形態では実行されなくてもよい。

また、上述の図５の処理の流れは、ユーザからの入力を受け付けるなどして保守サーバ１０１が実行してもよいし、一部がユーザによって実行されてもよい。

また、上述の図１０の案件情報１０００には、１つのシステムで発生した事象についての保守依頼に関する情報が登録されているが、実施形態はこれに限定されるものではない。例えば、別の実施形態では、案件情報１０００には、異なる複数のシステムについての保守依頼に関する情報が含まれていてもよい。また、案件情報１０００には、複数の拠点に設置された同じシステムについての保守依頼に関する情報が含まれていてもよい。そして、１つのシステムで取得した作業密度や事象の発生頻度などの情報を、別のシステムでも流用できる場合には、複数のシステム全体を、１つのシステムとして上述の処理が実行されてもよい。この様な状況の例としては、例えば、複数のシステムの導入時期が同じであったり、複数のシステムが互いに連携していたりする場合などが挙げられる。

また、上述の実施形態では、発生頻度を求める期間として、１年や１週間の単位で求める例を示したが、実施形態はこれに限定されるものではなく、その他の所定の期間が用いられてもよい。

上述の実施形態において、例えば、図１１のＳ１１０５〜Ｓ１１１７までの処理では、制御部４０１は、評価部４１１として動作する。また、例えば、図１１のＳ１１１８の処理では、制御部４０１は、出力部４１２として動作する。

図１３は、実施形態に係る保守サーバ１０１を実現するための例えば、コンピュータなどの情報処理装置１３００のハードウェア構成を例示する図である。図１３の保守サーバ１０１を実現するための情報処理装置１３００のハードウェア構成は、例えば、プロセッサ１３０１、メモリ１３０２、記憶装置１３０３、読取装置１３０４、通信インタフェース１３０６、及び入出力インタフェース１３０７を備える。なお、プロセッサ１３０１、メモリ１３０２、記憶装置１３０３、読取装置１３０４、通信インタフェース１３０６、入出力インタフェース１３０７は、例えば、バス１３０８を介して互いに接続されている。

プロセッサ１３０１は、例えば、シングルプロセッサであっても、マルチプロセッサやマルチコアであってもよい。プロセッサ１３０１は、メモリ１３０２を利用して例えば上述の動作フローの手順を記述した保守管理プログラムなどのプログラムを実行することにより、上述した制御部４０１の一部または全部の機能を提供する。保守サーバ１０１のプロセッサ１３０１は、例えば、記憶装置１３０３に格納されているプログラムを読み出して実行することで、評価部４１１、及び出力部４１２として動作する。

メモリ１３０２は、例えば半導体メモリであり、ＲＡＭ領域及びＲＯＭ領域を含んでいてよい。記憶装置１３０３は、例えばハードディスク、フラッシュメモリ等の半導体メモリ、又は外部記憶装置である。なお、ＲＡＭは、Random Access Memoryの略称である。また、ＲＯＭは、Read Only Memoryの略称である。

読取装置１３０４は、プロセッサ１３０１の指示に従って着脱可能記憶媒体１３０５にアクセスする。着脱可能記憶媒体１３０５は、例えば、半導体デバイス（ＵＳＢメモリ等）、磁気的作用により情報が入出力される媒体（磁気ディスク等）、光学的作用により情報が入出力される媒体（ＣＤ−ＲＯＭ、ＤＶＤ等）などにより実現される。なお、ＵＳＢは、Universal Serial Busの略称である。ＣＤは、Compact Discの略称である。ＤＶＤは、Digital Versatile Diskの略称である。

上述の記憶部４０２は、例えばメモリ１３０２、記憶装置１３０３、及び着脱可能記憶媒体１３０５を含んでいる。保守サーバ１０１の記憶装置１３０３には、例えば、閾値情報８００、不安定期優先度情報９０１、安定期優先度情報９０２、案件情報１０００が格納されている。

通信インタフェース１３０６は、プロセッサ１３０１の指示に従ってネットワークを介してデータを送受信する。例えば、通信インタフェース１３０６は、プロセッサ１３０１の指示に従って、顧客システム管理装置１０２、端末１０３と通信してよい。入出力インタフェース１３０７は、例えば、入力装置及び出力装置との間のインタフェースであってよい。入力装置は、例えばユーザからの指示を受け付けるキーボードやマウスなどのデバイスである。出力装置は、例えばディスプレーなどの表示装置、及びスピーカなどの音声装置である。

実施形態に係る各プログラムは、例えば、下記の形態で保守サーバ１０１に提供される。
（１）記憶装置１３０３に予めインストールされている。
（２）着脱可能記憶媒体１３０５により提供される。
（３）プログラムサーバなどのサーバから提供される。

なお、図１３を参照して述べた保守サーバ１０１を実現するための情報処理装置１３００のハードウェア構成は、例示であり、実施形態はこれに限定されるものではない。例えば、上述の機能部の一部または全部の機能がＦＰＧＡ及びＳｏＣなどによるハードウェアとして実装されてもよい。なお、ＦＰＧＡは、Field Programmable Gate Arrayの略称である。ＳｏＣは、System-on-a-chipの略称である。

以上において、いくつかの実施形態が説明される。しかしながら、実施形態は上記の実施形態に限定されるものではなく、上述の実施形態の各種変形形態及び代替形態を包含するものとして理解されるべきである。例えば、各種実施形態は、その趣旨及び範囲を逸脱しない範囲で構成要素を変形して具体化できることが理解されよう。また、前述した実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の実施形態が実施され得ることが理解されよう。更には、実施形態に示される全構成要素からいくつかの構成要素を削除して又は置換して、或いは実施形態に示される構成要素にいくつかの構成要素を追加して種々の実施形態が実施され得ることが当業者には理解されよう。

以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価し、
前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する、
処理をコンピュータに実行させる保守管理プログラム。
（付記２）
前記保守作業の作業密度を、前記保守作業の工数とリードタイムとに基づいて決定する処理を更に前記コンピュータに実行させる、付記１に記載の保守管理プログラム。
（付記３）
前記類似案件に対して過去に実施された前記保守作業の前記リードタイムよりも前記工数の方が所定の比率を超えて大きい場合、前記類似案件に第１の優先度を設定し、前記リードタイムよりも前記工数の方が所定の比率を超えて大きくはない場合、前記類似案件に前記第１の優先度よりも低い第２の優先度を設定する、付記２に記載の保守管理プログラム。
（付記４）
前記類似案件に対して過去に実施された前記保守作業の前記リードタイムよりも前記工数の方が所定の比率を下回って小さい場合、前記類似案件に第３の優先度を設定し、前記リードタイムよりも前記工数の方が所定の比率を下回って小さくはない場合に、前記類似案件に前記第３の優先度よりも高い前記第２の優先度を設定する、付記３に記載の保守管理プログラム。
（付記５）
前記システムからの保守依頼の発生頻度が所定の閾値を超える稼働不安定期において、前記第２の優先度を設定された前記類似案件と前記保守作業の分類が同じ分類に属する案件の発生頻度が所定値を超える場合よりも、前記発生頻度が前記所定値以下の場合の優先度を低く設定する、付記４に記載の保守管理プログラム。
（付記６）
前記システムに対する保守依頼の発生頻度が所定の閾値未満である稼働安定期において、前記第２の優先度を設定された前記類似案件と前記保守作業の分類が同じ分類に属する案件の発生頻度が所定値を超える場合よりも、前記発生頻度が前記所定値以下の場合の優先度を高く設定する、付記４に記載の保守管理プログラム。
（付記７）
前記類似案件の優先度に基づいて、前記依頼案件に優先度を設定し、
前記依頼案件と前記保守作業の対応時期が重なる別の案件と、前記依頼案件との間での作業の優先順位を、前記依頼案件に設定した優先度と、前記別の案件に設定されている優先度とに基づいて決定する、
処理を更に前記コンピュータに実行させる、付記１から６のいずれかに記載の保守管理プログラム。
（付記８）
コンピュータにより実行される保守管理方法であって、前記コンピュータが、
システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価し、
前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する、
ことを特徴とする保守管理方法。
（付記９）
システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価する評価部と、
前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する出力部と、
を含む、情報処理装置。

１００ 保守システム
１０１ 保守サーバ
１０２ 顧客システム管理装置
１０３ 端末
１０５ ネットワーク
１１０ 表示装置
４０１ 制御部
４０２ 記憶部
４０３ 通信部
４１１ 評価部
４１２ 出力部
６１１ 案件一覧画面
６１２ 検索結果画面
６１３ 一品一葉画面
１３００ 情報処理装置
１３０１ プロセッサ
１３０２ メモリ
１３０３ 記憶装置
１３０４ 読取装置
１３０５ 着脱可能記憶媒体
１３０６ 通信インタフェース
１３０７ 入出力インタフェース
１３０８ バス

Claims (8)

1. システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価し、
   前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する、
   処理をコンピュータに実行させる保守管理プログラム。
2. 前記保守作業の作業密度を、前記保守作業の工数とリードタイムとに基づいて決定する処理を更に前記コンピュータに実行させる、請求項１に記載の保守管理プログラム。
3. 前記類似案件に対して過去に実施された前記保守作業の前記リードタイムよりも前記工数の方が所定の比率を超えて大きい場合、前記類似案件に第１の優先度を設定し、前記リードタイムよりも前記工数の方が所定の比率を超えて大きくはない場合、前記類似案件に前記第１の優先度よりも低い第２の優先度を設定する、請求項２に記載の保守管理プログラム。
4. 前記類似案件に対して過去に実施された前記保守作業の前記リードタイムよりも前記工数の方が所定の比率を下回って小さい場合、前記類似案件に第３の優先度を設定し、前記リードタイムよりも前記工数の方が所定の比率を下回って小さくはない場合に、前記類似案件に前記第３の優先度よりも高い前記第２の優先度を設定する、請求項３に記載の保守管理プログラム。
5. 前記システムからの保守依頼の発生頻度が所定の閾値を超える稼働不安定期において、前記第２の優先度を設定された前記類似案件と前記保守作業の分類が同じ分類に属する案件の発生頻度が所定値を超える場合よりも、前記発生頻度が前記所定値以下の場合の優先度を低く設定する、請求項４に記載の保守管理プログラム。
6. 前記システムに対する保守依頼の発生頻度が所定の閾値未満である稼働安定期において、前記第２の優先度を設定された前記類似案件と前記保守作業の分類が同じ分類に属する案件の発生頻度が所定値を超える場合よりも、前記発生頻度が前記所定値以下の場合の優先度を高く設定する、請求項４に記載の保守管理プログラム。
7. コンピュータにより実行される保守管理方法であって、前記コンピュータが、
   システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価し、
   前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する、
   ことを特徴とする保守管理方法。
8. システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価する評価部と、
   前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する出力部と、
   を含む、情報処理装置。

Images