以下、図面を参照しながら、本発明のいくつかの実施形態について詳細に説明する。なお、複数の図面において対応する要素には同一の符号を付す。
図1は、例示的な保守システム100を示す図である。図1の例では、保守システム100は、例えば、保守サーバ101、顧客システム管理装置102、及び端末103を含み、これらはネットワーク105を介して接続されている。顧客システム管理装置102は、例えば、顧客に導入され保守契約が結ばれた様々なシステムを管理する装置である。例えば、顧客システム管理装置102は、管理対象のシステムに生じた異常を検知したり、システムの稼働のログを取ったりしてよい。また、顧客システム管理装置102は、例えば、保守契約を結ぶ顧客ごとに設置されてよく、更には、同じ顧客であっても拠点ごとに設置されてよい。保守サーバ101は、例えば、顧客のシステムで過去に発生した問題や、その問題に対して保守契約により提供した保守サービスの内容などに関する情報を保持してよい。なお、保守管理対象の顧客のシステムは、例えば、サーバや製造実行システム、品質管理のためのアプリケーションなどであってよい。端末103は、例えば、保守サーバ101を管理する管理者、保守依頼を受け付けるオペレータ、及び保守作業を担当する作業員などの保守サーバ101を利用するユーザが使用する端末であってよい。例えば、ユーザは、端末103を操作して、保守サーバ101や顧客システム管理装置102から保守依頼のあった顧客のシステムについての情報を取得し、端末103と接続された表示装置110の表示画面に情報を表示してよい。
図2は、例示的な保守作業の流れを説明する図である。例えば、保守サーバ101が提供するウェブページのフォームなどを介してユーザが入力した情報を受信し、保守サーバ101が保守依頼を受け付けたとする(S201)。なお、保守依頼の受け付けは、これに限定されるものではなく、例えば、メールや電話などその他の手法で受け付けられてもよい。この場合、例えば、メールや電話などで保守依頼を受け付けたオペレータは、端末103などを用いて保守依頼で受け付けた内容を保守サーバ101に入力してよい。
保守サーバ101は、保守依頼を受け付けると、受け付けた保守依頼を識別するための案件識別子を割り振る(S202)。
続いて、保守サーバ101の管理者は、保守依頼で受け付けた保守対象のシステムで発生した事象に関する情報を基に、過去事例の中から類似する案件を検索する(S203)。
図3は、類似する案件の情報を取得する流れを示す表示画面を例示する図である。図3の案件一覧画面311は、例えば、保守サーバ101が生成した過去に行われた保守作業の案件の一覧を示す表示画面である。そして、例えば、案件一覧画面311から類似案件テキスト検索フィールドに、検索文字列「在庫」を入力して検索を行った結果が、検索結果画面312に例示されており、案件名「在庫アンマッチ」のエントリが見つかっている。例えば、検索結果画面312からユーザがエントリを選択するなどしてエントリを開くと、案件に対する一品一葉画面313が表示される。
そのため、保守作業を実行する作業者は、例えば、保守依頼で受け付けた事象と類似する類似案件を検索して、その一品一葉画面313の内容を参照することで、保守依頼のあった事象に関連する情報を参考にして、保守作業を行うことができる(S204)。
ところで、例えば、対応時期が重なった複数の保守依頼を受け付けることがある。その様な場合に、複数の保守依頼のそれぞれで発生した事象が顧客の業務に与える影響や、対応の緊急性を判断することができれば、複数の保守依頼に対して優先順位を付けることができる。その結果、優先順位に従って、顧客の業務に与える影響を小さく抑えながら複数の保守依頼に対応することができる。
しかしながら、例えば、一品一葉画面313などから類似案件の情報を見たとしても、保守対象となるシステムに関しての知識と経験が不足しているユーザでは、受け付けた事象の業務への影響度や対応の緊急度を正しく判断することが難しいことがある。そのため、こうした保守依頼に対する優先順位付けなどの判断は、十分な経験を積んだ限られた人員が行っている。こうした属人化された判断は、業務のボトルネックとなり得、また、引継ぎが難しく、人員の補填が難しいなど様々なリスクとなり得るため、解消することが望ましい。そのため、例えば、保守依頼に対する優先度を評価することのできる技術の提供が望まれている。
そこで、以下で述べる実施形態では、保守サーバ101は、保守依頼に対し、過去に類似案件に対して実行した保守作業の密度(以下、作業密度と呼ぶことがある)に基づいて、保守依頼のあった事象に優先度を設定する。作業密度は、例えば、案件に対してどれだけ過密に作業が行われたのかを示す指標であってよい。以下、実施形態を更に詳細に説明する。
図4は、実施形態に係る保守サーバ101のブロック構成を例示する図である。保守サーバ101は、例えば、制御部401、記憶部402、及び通信部403を含んでいる。制御部401は、例えば、評価部411、及び出力部412などとして動作してよい。保守サーバ101の記憶部402は、例えば、後述する閾値情報800、不安定期優先度情報901、安定期優先度情報902、及び案件情報1000などの情報を記憶している。通信部403は、例えば、制御部401の指示に従って、顧客システム管理装置102や端末103と通信してよい。これらの各部の詳細及び記憶部402に格納されている情報の詳細については後述する。
図5は、実施形態に係る保守作業の流れを説明する図である。例えば、保守サーバ101の制御部401が、顧客システム管理装置102などから保守依頼を受け付けたとする(S501)。すると、保守サーバ101の制御部401は、受け付けた保守依頼の案件(以下、依頼案件と呼ぶことがある)を識別するための案件識別子を発行し、受け付けた保守依頼の案件に割り振る(S502)。
続いて、保守サーバ101の制御部401は、保守依頼で受け付けた案件の情報を基にユーザから入力された情報に基づいて、過去事例の中から類似する案件を検索し、見つかった類似案件の優先度を評価する(S503)。例えば、図6には、案件一覧画面611が示されており、類似案件テキスト検索フィールドに、ユーザが検索文字列「在庫」を入力して検索を行った結果が、検索結果画面612に示されており、案件名:在庫アンマッチを有する類似案件が見つかっている。そして、実施形態では、制御部401は、検索結果画面612に例示するように、エントリに含まれる情報から案件に優先度を付し、得られた優先度を案件の情報とともに表示している。
続いて、制御部401は、類似案件の優先度に基づいて、保守依頼を受けた案件の優先度を決定する。例えば、制御部401は、見つかった類似案件のうちで最も多かった優先度を、保守依頼を受けた案件の優先度として用いてもよい(S504)。
続いて、制御部401は、例えば、複数の保守依頼を受けた場合などに対応時期が重なっている複数の案件に対し、優先度に基づいて優先順位をつけて、作業の順序を決定する(S505)。
その後、制御部401は、例えば、優先順位の高い案件に対する一品一葉画面613を端末103の表示装置に表示させるなどを実行し、ユーザは一品一葉画面613を参照して、保守作業を実行する(S506)。
以上で述べたように、実施形態によれば、保守依頼のあった案件の優先度を決定することができるため、優先順位付けを行うことができ、効率的な作業の実行が可能である。
以下では、保守依頼のあった案件に対する優先度の決定について詳細を述べる。保守依頼のあった案件に対する優先度を決定するために、顧客のシステムに発生した事象が顧客の業務に与える影響度と、求められる作業の緊急度とを考慮することが考えられる。例えば、顧客のシステムに与える影響が大きい事象が発生した案件は、顧客のシステムに与える影響が小さな事象が発生した案件よりも優先的に作業することが望ましい。また、例えば、顧客への納品までの期間が短い案件は、顧客への納品に余裕の或る案件よりも優先的に作業することが望ましい。
図7は、案件の分類を例示する図である。図7(a)には、横軸に作業の緊急度をとり、縦軸に顧客の業務への影響度をとって区分けされた、領域1、領域2、領域3、領域4の4つの領域が示されている。
図7(a)において領域1は、業務への影響度が高く、且つ、納期も短いため、優先度が高い。領域1に当てはまる保守作業としては、例えば、業務停止、サーバダウン、経理の〆直前での在庫のアンマッチなどの事象が挙げられる。
また、領域4は、業務への影響度が小さく、且つ、納期も余裕があるため、優先度が低い。領域4に当てはまる保守作業としては、例えば、保守対応マニュアルの作成などが挙げられる。
領域2は、納期は急がないが業務への影響が大きく、領域3は、業務への影響が小さいが納期は急ぎであり、優先度はどちらも、領域1よりは低いが領域4よりは高く、領域2と領域3は優先度を中としている。領域2に当てはまる保守作業としては、例えば、システムの改造や、バージョンアップなどの作業が挙げられる。また、領域3に当てはまる保守作業としては、例えば、製品固体の実績結果抜け、ハンディターミナル誤操作、出荷数調査依頼などが挙げられる。
以上で述べた様に、案件の優先度を案件で発生した事象が業務に与える影響度と、求められる作業の緊急度とから分類し、優先順位をつけることができる。
ここで、緊急度を計る指標として、例えば、リードタイムを用いることができる。リードタイムは、例えば、依頼があってから納品までの期間を示す。そのため、リードタイムが短い場合、緊急の案件であったと推定することができ、一方、リードタイムが長い場合、納期に余裕のある案件であったと推定することができる。
また、影響度を計る指標として、例えば、工数を用いることができる。工数は、例えば、作業量を表す値である。工数は、例えば、時間×人数で表現される。例えば、工数が40時間であれば、一人で作業すると40時間かかる作業量であることを示す。工数が大きいことは作業量が多いことを表し、システムに大きな変更が加えられることが推定される。即ち、工数が大きい場合、顧客の業務への影響が大きい事象が発生した案件であると推定することができる。一方、工数が少ない場合、直ぐに完了する作業であり、顧客の業務への影響が小さい事象が発生した案件であると推定することができる。
図7(b)は、以上の観点から図7(a)をリードタイムと工数とを用いた軸に置き換えて表現した図である。領域1は、工数が大きく業務への影響度が高いのに、リードタイムも短く過密に作業をして納期に間に合わせなければならない案件であり、優先度が高い。
一方、領域4は、工数が小さく、直ぐに対処できる事象が発生した案件であり、業務への影響度が小さいことが推定され、且つ、リードタイムの長く、納期にも余裕のある案件であることが推定され、優先度は低い。
領域2は、納期に余裕があるが作業量が大きく、領域3は、作業量が少ないが納期が短い案件であり、優先度はどちらも、領域1よりは低いが領域4よりは高くなり、ここでは優先度を中とする。
ここで、領域1に当てはまる案件は、例えば、工数/リードタイムの値に対して閾値を設定することで抽出することができる。例えば、領域1の案件では、工数が大きく、一方、リードタイムは短いため、工数/リードタイムは大きな値となる。なお、工数/リードタイムは、例えば、作業の密度を表している。例えば、工数が40時間で、リードタイムが8時間であったとする。この場合、一人で8時間作業したとしても工数8時間で、作業完了にかかる工数40時間には届かず、リードタイム内には作業が終わらない。40÷8=5人なので、少なくとも5人以上の人員を割いて、1人で作業する場合の5倍の作業密度で作業を行って納期に間に合わせたことになる。この様に、例えば、工数/リードタイムが、1よりも大な値を有する場合、1人よりも多い複数人の人員を割いて作業が行われたことを表している。そして、例えば、工数/リードタイムが第1の閾値よりも高ければ、作業密度が高いことを表すように第1の閾値を設定することで、図7の領域1に含まれる案件を抽出することができる。領域1に含まれる案件を抽出するための閾値としては、例えば、1.0よりも大きな値が用いられてよく、2~5の範囲の値であってよく、一例では、3であってよい。
また、領域4に当てはまる案件は、例えば、工数/リードタイムをとった場合、工数が小さく、リードタイムが大きいため、小さな値となる。例えば、工数が1時間で、リードタイムが10時間であったとする。この場合、1÷10=0.1で、工数に対して納期に余裕があり、直ぐに着手しなくても他の保守作業を手掛けてからでも間に合い、1人でリードタイム内に作業を終わらせることが可能である。即ち、工数/リードタイムが、例えば、1よりも小さな値を有する場合、1人でも時間に余裕を持って作業に当たれる可能性が高いことを表している。そして、例えば、工数/リードタイムが第2の閾値よりも低ければ作業密度が低いことを表すように第2の閾値を設定することで、図7の領域4に含まれる案件を抽出することができる。領域4に含まれる案件を抽出するための閾値としては、例えば、1.0よりも小さな値が用いられてよく、0.01~0.5の範囲の値であってよく、一例では、0.1であってよい。
一方で、領域2に当てはまる案件は、工数が多いがリードタイムも長く、領域3に当てはまる案件は、工数が少ないがリードタイムも短く、従って、これらの領域2と領域3では、工数/リードタイムは類似した値をとる。領域2又は領域3に含まれる案件は、例えば、第1の閾値以下で、第2の閾値以上の工数/リードタイムの値を有する案件として、抽出することができる。
以上で述べた様に、工数/リードタイムの値に対して、第1の閾値と第2の閾値を設定することで、過去に保守作業を実行した工数とリードタイムが明らかな案件に対して優先度を、以下のように設定することができる。
優先度:高(第1の優先度) 工数/リードタイムが第1の閾値よりも大きい
優先度:中(第2の優先度) 工数/リードタイムが第1の閾値以下で第2の閾値以上
優先度:低(第3の優先度) 工数/リードタイムが第2の閾値未満
別の記載をすると、例えば、保守作業のリードタイムよりも工数の方が所定の比率を超えて大きい場合、類似案件に優先度:高(第1の優先度)が設定されてよい。一方、リードタイムよりも工数の方が所定の比率を超えて大きくはない場合、類似案件に優先度:高(第1の優先度)よりも低い優先度:中(第2の優先度)が設定されてよい。また、保守作業のリードタイムよりも工数の方が所定の比率を下回って小さい場合、類似案件に優先度:低(第3の優先度)が設定されてよい。リードタイムよりも工数の方が所定の比率を下回って小さくはない場合に、類似案件に優先度:低(第3の優先度)よりも高い優先度:中(第2の優先度)が設定されてよい。
図8は、以上の実施形態に係る閾値情報800を例示する図である。閾値情報800には、例えば、以上で述べた優先度ごとに定められた閾値による範囲が登録されている。例えば、記憶部402には、閾値情報800などの第1の閾値及び第2の閾値を示す情報が記憶されていてよい。
なお、優先度:中の案件は、更に、案件と対応する事象の発生頻度に基づいて、より細かく優先度が決定されてもよい。以下では、発生頻度に基づく優先度の決定を説明する。
(発生頻度に基づく優先度の決定)
図7の領域2又は領域3に含まれる優先度:中の案件を更に、案件と対応する事象の発生頻度に基づいて分類し、優先度を設定することが考えられる。なお、類似事象の発生頻度に基づいて優先度を設定する場合、システムが稼働状態に応じて異なる優先度を設定してよい。
例えば、システムの稼働が不安定で、様々な事象が頻繁に発生している状況がある。以下、様々な事象が頻繁に発生している状況を稼働不安定期と呼ぶことがある。稼働不安定期の例としては、システムを導入したばかりの稼働初期、システムに改造などの変更を施した後、システムの一部を交換した後などが挙げられる。このような、様々なエラーが発生する稼働が不安定な時期には、発生頻度の高い事象から解決していった方が、事象の発生数を効率的に減らすことができる。そのため、稼働不安定期では、発生頻度の高い事象に、発生頻度の低い事象よりも高い優先度を設定してよい。
一方、システムの稼働を開始してからある程度のエラーを解消すると、システムが安定して稼働し始める。なお、システムが安定して稼働している状況を稼働安定期と呼ぶことがある。システムが稼働安定期にある場合、発生頻度の高い事象については、対応が頻繁に行われて事例の蓄積が十分にあり、不測の事態が発生して対応に手間取ったりする可能性は低い。一方、発生頻度が低い事象は、まだ対応した経験が浅く、対応に時間がかかる可能性もある。そのため、稼働安定期では、発生頻度の高い事象に、発生頻度の低い事象よりも低い優先度を設定してよい。
図9は、以上で述べた、稼働不安定期の発生頻度と優先度の関係を表す不安定期優先度情報901と、稼働安定期の発生頻度と優先度の関係を表す安定期優先度情報902とを例示する図である。稼働不安定期の状態は様々な事象が頻繁に発生している状況にあるため、不安定期優先度情報901では、例として、週単位の短い期間での発生回数を用いて発生頻度としている。そして、例えば、図9の不安定期優先度情報901では、発生頻度が週あたりに所定値(例えば、3より多い)を超えており、多い場合に、優先度:中の高を設定している。一方、発生頻度が週あたりに所定値以下(例えば、3以下)で少ない場合に、優先度:中の低を設定している。なお、中の高は、中の低よりも優先度が高い。
一方、稼働安定期にはシステムは安定して稼働しており、事象の発生回数も稼働不安定期と比較して少ない状況にあるため、不安定期優先度情報901では、例として、年単位の長い期間での発生回数を用いて発生頻度としている。そして、例えば、図9の安定期優先度情報902では、発生頻度が年あたりに所定値以下(例えば、5以下)で少ない場合に、優先度:中の高を設定している。一方、図9の安定期優先度情報902では、発生頻度が年あたりに所定値(例えば、5よりも多い)を超えており、多い場合に、優先度:中の低を設定している。
以上で述べた様に、制御部401は、工数及びリードタイムと、発生頻度から過去の案件に優先度を決定することが可能である。そのため、実施形態では過去の事例を記憶する案件情報1000は、工数、リードタイム、及び発生頻度を特定するための情報を含んでいる。
図10は、実施形態に係る案件情報1000を例示する図である。案件情報1000には、例えば、或るシステムにおいて過去に実施した保守作業に関する情報を含むエントリが登録されている。図10の例では、案件情報1000のエントリは、案件名、案件識別子、発生日、事象、及び対応状況を含む。また更に、図10の例では、案件情報1000のエントリは、優先度の評価に用いる工数、リードタイム、及び案件識別キーなどの情報を含んでよい。
案件名は、例えば、エントリと対応する保守依頼のあった案件に対して設定された名称である。案件識別子は、例えば、エントリと対応する保守依頼を識別するために割り当てた識別子である。発生日は、例えば、エントリと対応する保守依頼を受け付けた日時である。事象は、例えば、エントリと対応する保守依頼で受け付けたシステムに起きた事象を示す情報である。対応状況は、例えば、エントリと対応する保守依頼に対して実施した保守作業の内容が登録されていてよい。
また、工数は、例えば、エントリと対応する保守依頼の保守作業でかかった工数である。リードタイムは、例えば、エントリと対応する保守依頼を受けてから保守作業を完了して納品を終えるまでの期間である。案件識別キーは、例えば、エントリと対応する保守依頼で発生した事象の分類を示す情報であり、類似する事象には同じ識別子が割り当てられてよい。案件識別キーは、例えば、エントリと対応する保守依頼においてシステムに発生した事象を、その原因や事象の特徴などに基づいて分類して得られる各分類群に付した識別情報である。案件識別キーは、例えば、保守作業を実施したユーザが、エントリと対応する保守依頼においてシステムに発生した事象を分類することで設定されてよい。
例えば、保守サーバ101の記憶部402には以上の情報を含む案件情報1000が記憶されていてよい。
続いて、類似案件の検索と優先度の設定する処理を説明する。図11は、実施形態に係る類似案件の検索と優先度の設定を実行する処理の動作フローを例示する図である。例えば、保守サーバ101の制御部401は、ユーザの端末103から類似案件を検索するためのアクセスを受け付けると、図11の動作フローを開始してよい。なお、図11の動作フローは、例えば、図5のS503の処理と対応しており、制御部401は、図5の処理において、S503の処理の代わりに、図11の動作フローを実行してよい。
S1101において制御部401は、ユーザの端末103から案件一覧の表示指示を受け付ける。例えば、ユーザは、端末103の表示画面に表示された案件一覧を表示するボタンを選択することで、端末103から保守サーバ101に、案件一覧の表示指示を送信してよい。
S1102において制御部401は、案件情報1000を用いて案件の一覧の表示データを生成して端末103に送信し、端末103の表示画面に表示させる。案件の一覧の表示画面は、例えば、案件一覧画面611であってよい。
S1103において制御部401は、類似案件の検索指示を受け付ける。例えば、ユーザは、端末103の表示画面に表示された案件一覧の類似案件テキスト検索フィールドに検索する文字列を入力し、検索のボタンを選択することで、端末103から保守サーバ101に、検索指示を送信することできる。
S1104において制御部401は、案件情報1000から検索指示で検索キーワードとして入力された文字列で識別される類似案件を検索する。例えば、制御部401は、検索キーワードとして入力された文字列を含むエントリを、案件情報1000から検索してよい。なお、S1104で複数の類似案件が見つかった場合、続くS1105からS1118までの処理は、S1104で検索された類似案件ごとに実行されてよい。以下では、1つの類似案件に対する処理を例として説明する。
S1105において制御部401は、検索された類似案件で実施された保守作業の作業密度を算出する。例えば、制御部401は、検索された類似案件のエントリから工数とリードタイムの情報を取得し、作業密度を表す“工数/リードタイム”を算出する。
S1106において制御部401は、閾値情報800を参照し、算出された工数/リードタイムが含まれる作業密度範囲と対応する優先度を特定する。そして、例えば、工数/リードタイムが第2の閾値未満で優先度“低(第3の優先度)”が特定された場合、フローはS1107に進む。S1107において、制御部401は、類似案件の優先度を“低(第3の優先度)”に設定し、フローはS1118に進む。
一方、S1106で特定した優先度が“中(第2の優先度)”である場合、フローはS1108に進む。S1108において制御部401は、保守依頼を受け付けたシステムが現在、稼働安定期にあるか否かを判定する。例えば、制御部401は、保守依頼を受け付けた日時の過去1週間に、保守依頼を受け付けたシステムについて受信した保守依頼の件数を算出する。制御部401は、例えば、案件情報1000において発生日が現在より遡って1週間以内にあるエントリの数をカウントすることで件数を算出してよい。そして、制御部401は、得られた件数が所定の閾値以上の場合、稼働安定期ではないと判定し(S1108がNo)、フローはS1109に進む。
S1109において制御部401は、検索された類似案件と類似する事象の直近の一週間あたりの発生回数を発生頻度として算出する。例えば、制御部401は、検索された類似案件の案件識別キーと同じ案件識別キーを有するエントリを、案件情報1000の発生日が、過去一週間以内の案件のうちから特定し、その発生回数をカウントして発生頻度を求めてよい。
S1110において制御部401は、算出した発生回数と、稼働不安定期に対する不安定期優先度情報901に基づいて、優先度を判定する。例えば、図9(a)の不安定期優先度情報901を用いる場合、週当たりの発生回数が所定値(例えば、3回)以下であれば(S1110がNo)、フローはS1111へと進み、優先度:中の低と判定する。一方、週当たりの発生回数が所定値(例えば、3回)より多ければ(S1110がYes)、フローはS1112へと進み、制御部401は、優先度:中の高と判定する。
また、S1108において保守依頼を受け付けたシステムが現在、稼働安定期にある場合(S1108がYes)、フローはS1113に進む。例えば、制御部401は、保守依頼を受け付けた日時から過去1週間に、保守依頼を受け付けたシステムについて受信した保守依頼の件数を算出する。制御部401は、例えば、発生日が現在より遡って1週間以内にあるエントリの数をカウントすることで件数を算出してよい。そして、制御部401は、得られた件数が所定の閾値よりも少ない場合、稼働安定期であると判定し(S1108がYes)、フローはS1113に進む。
S1113において制御部401は、検索された類似案件と類似する事象の直近の一年間あたりの発生回数を発生頻度として算出する。例えば、制御部401は、検索された類似案件の案件識別キーと同じ案件識別キーを有するエントリを、案件情報1000の発生日が、過去一年間以内の案件のうちから特定し、その発生回数をカウントして発生頻度を求めてよい。
S1114において制御部401は、算出した発生回数と、稼働安定期に対する安定期優先度情報902に基づいて、優先度を判定する。例えば、図9(b)の安定期優先度情報902を用いる場合、年当たりの発生回数が所定値(例えば、5回)より多ければ(S1110がYes)、フローはS1115へと進み、優先度:中の低と判定する。一方、週当たりの発生回数が所定値(例えば、5回)以下であれば(S1110がNo)、フローはS1116へと進み、制御部401は、優先度:中の高と判定する。
また、S1106において工数/リードタイムが第1の閾値より大きく優先度“高(第1の優先度)”が特定された場合、フローはS1117に進む。S1117において、制御部401は、類似案件の優先度を“高(第1の優先度)”に設定し、フローはS1118に進む。
以上のS1105~S1117までの処理により、検索された類似案件のそれぞれに優先度が決定される。そして、S1118において制御部401は、検索された類似案件に対する案件情報1000のエントリの情報と、決定した優先度と用いて生成した表示情報を端末103に送信する。端末103は、例えば、受信した表示情報を表示装置に表示することで、例えば、図6に例示した検索結果画面612などの優先度を含む検索結果を表示する。
そして、S1119において制御部401は、検索結果画面612に表示した類似案件の選択を受け付ける。例えば、端末103において、表示された検索結果画面612のうちから類似案件を選択する入力がなされたことを示す通知を、保守サーバ101が受信すると、フローはS1120に進む。S1120において制御部401は、選択された案件に関する情報を表示するための表示情報を、端末103に送信し、本動作フローは終了する。端末103は、例えば、選択された案件に関する情報を表示するための表示情報を受信すると、その表示情報に基づいて、一品一葉画面613などを表示装置に表示してよい。
以上で述べた様に、図11の動作フローによれば、制御部401は、類似案件に優先度の情報を付すことができる。そのため、類似案件を検索したユーザは、保守依頼を受けた案件の優先度を、検索された類似案件の優先度から推定することができる。
なお、制御部401は、例えば、S503の代わりに、上記の図11の動作フローを実施した場合、S504において類似案件の優先度に基づいて、保守依頼を受け付けた案件に対して優先度を設定してよい。例えば、制御部401は、類似案件に対して決定された優先度のうち、最も多い優先度に、保守依頼を受け付けた案件の優先度を設定してよい。或いは、制御部401は、類似案件に対して決定された優先度のうち、最も高い優先度に、保守依頼を受け付けた案件の優先度を設定してよい。そして、続くS505において制御部401は、保守作業の実行対象として現在登録されている複数の案件を、優先度が高い方から低い方に順に並ぶように並べ替えて実行順序に優先順位を付ける。なお、同じ優先度を有する複数の案件があれば、それらの案件は任意の順序で並べられてよく、一例では、制御部401は、保守依頼を受け付けた日時の早い案件が先になるように優先順位を設定してよい。また、保守作業の実行対象となる複数の案件は、例えば、ユーザが保守依頼を受けて保守サーバ101に登録した保守作業が未完了の案件であってよい。S506では制御部401は、例えば、保守作業を担当するユーザの端末103に優先順位の最も高い案件の保守依頼を送信してよく、保守作業を担当するユーザは、端末103で受信された優先順位の最も高い案件についての保守作業を開始する。
図12は、例示的な優先度の設定例を示す図である。図12(a)には、ケース1からケース4の4つの事例が示されている。ケース1は、工数が40時間で、リードタイムが8時間であり、作業密度(例えば、工数/リードタイム)は5であるため、閾値情報800に基づいて、制御部401は、ケース1の案件を優先度:高と判定する。
一方、ケース4は、工数が4時間で、リードタイムが80時間であり、作業密度(例えば、工数/リードタイム)は0.05であるため、閾値情報800に基づいて、制御部401は、ケース4の案件を優先度:低と判定する。
また、ケース2は、工数が2時間で、リードタイムが10時間であり、作業密度(例えば、工数/リードタイム)は0.2であるため、閾値情報800に基づいて、制御部401は、ケース2の案件を優先度:中と判定する。
ケース3についても、工数が20時間で、リードタイムが40時間であり、作業密度(例えば、工数/リードタイム)は0.5であるため、閾値情報800に基づいて、制御部401は、ケース3の案件を優先度:中と判定する。
続いて、制御部401は、優先度:中と判定されたケース2及びケース3について、発生頻度に基づいて更に優先度を付す。図12(b)は、例えば、稼働不安定期における優先順位の設定を例示しており、ケース2では週当たりの発生頻度が3よりも多いため、制御部401は、不安定期優先度情報901に基づいて優先度:中の高と判定する。一方、ケース3は、例えば、週当たりの発生頻度が3以下であるため、制御部401は、不安定期優先度情報901に基づいて優先度:中の低と判定する。
また、図12(c)は、例えば、稼働安定期における優先順位の設定を例示しており、ケース2では年当たりの発生頻度が5よりも多いため、制御部401は、安定期優先度情報902に基づいて優先度:中の低と判定する。一方、ケース3は、例えば、年当たりの発生頻度が5以下であるため、制御部401は、安定期優先度情報902に基づいて優先度:中の高と判定する。以上で述べた様に、制御部401は、案件情報1000に登録されたエントリに優先度を割り当てることができる。そのため、顧客の業務に与える影響を小さくする順序で保守作業を実施することができる。また、緊急度の低い案件であっても予定納期を素早く顧客に回答することが可能になり、顧客が次のアクションプランを計画し易くなる。なお、上記の例では優先度は、高>中の高>中の低>低の順で実行順序が優先されてよい。
以上において、実施形態を例示したが、実施形態はこれに限定されるものではない。例えば、上述の動作フローは例示であり、実施形態はこれに限定されるものではない。可能な場合には、動作フローは、処理の順番を変更して実行されてもよく、別に更なる処理を含んでもよく、又は、一部の処理が省略されてもよい。例えば、図11の動作フローにおいて、優先度を中と判定したあとの発生頻度に基づくS1108~S1116までの処理は実行されなくてもよく、優先度:中がそのまま案件の優先度として用いられてもよい。また、図11の処理の後に、S504~S506の処理が続けて実行されてもよいし、別の実施形態では実行されなくてもよい。
また、上述の図5の処理の流れは、ユーザからの入力を受け付けるなどして保守サーバ101が実行してもよいし、一部がユーザによって実行されてもよい。
また、上述の図10の案件情報1000には、1つのシステムで発生した事象についての保守依頼に関する情報が登録されているが、実施形態はこれに限定されるものではない。例えば、別の実施形態では、案件情報1000には、異なる複数のシステムについての保守依頼に関する情報が含まれていてもよい。また、案件情報1000には、複数の拠点に設置された同じシステムについての保守依頼に関する情報が含まれていてもよい。そして、1つのシステムで取得した作業密度や事象の発生頻度などの情報を、別のシステムでも流用できる場合には、複数のシステム全体を、1つのシステムとして上述の処理が実行されてもよい。この様な状況の例としては、例えば、複数のシステムの導入時期が同じであったり、複数のシステムが互いに連携していたりする場合などが挙げられる。
また、上述の実施形態では、発生頻度を求める期間として、1年や1週間の単位で求める例を示したが、実施形態はこれに限定されるものではなく、その他の所定の期間が用いられてもよい。
上述の実施形態において、例えば、図11のS1105~S1117までの処理では、制御部401は、評価部411として動作する。また、例えば、図11のS1118の処理では、制御部401は、出力部412として動作する。
図13は、実施形態に係る保守サーバ101を実現するための例えば、コンピュータなどの情報処理装置1300のハードウェア構成を例示する図である。図13の保守サーバ101を実現するための情報処理装置1300のハードウェア構成は、例えば、プロセッサ1301、メモリ1302、記憶装置1303、読取装置1304、通信インタフェース1306、及び入出力インタフェース1307を備える。なお、プロセッサ1301、メモリ1302、記憶装置1303、読取装置1304、通信インタフェース1306、入出力インタフェース1307は、例えば、バス1308を介して互いに接続されている。
プロセッサ1301は、例えば、シングルプロセッサであっても、マルチプロセッサやマルチコアであってもよい。プロセッサ1301は、メモリ1302を利用して例えば上述の動作フローの手順を記述した保守管理プログラムなどのプログラムを実行することにより、上述した制御部401の一部または全部の機能を提供する。保守サーバ101のプロセッサ1301は、例えば、記憶装置1303に格納されているプログラムを読み出して実行することで、評価部411、及び出力部412として動作する。
メモリ1302は、例えば半導体メモリであり、RAM領域及びROM領域を含んでいてよい。記憶装置1303は、例えばハードディスク、フラッシュメモリ等の半導体メモリ、又は外部記憶装置である。なお、RAMは、Random Access Memoryの略称である。また、ROMは、Read Only Memoryの略称である。
読取装置1304は、プロセッサ1301の指示に従って着脱可能記憶媒体1305にアクセスする。着脱可能記憶媒体1305は、例えば、半導体デバイス(USBメモリ等)、磁気的作用により情報が入出力される媒体(磁気ディスク等)、光学的作用により情報が入出力される媒体(CD-ROM、DVD等)などにより実現される。なお、USBは、Universal Serial Busの略称である。CDは、Compact Discの略称である。DVDは、Digital Versatile Diskの略称である。
上述の記憶部402は、例えばメモリ1302、記憶装置1303、及び着脱可能記憶媒体1305を含んでいる。保守サーバ101の記憶装置1303には、例えば、閾値情報800、不安定期優先度情報901、安定期優先度情報902、案件情報1000が格納されている。
通信インタフェース1306は、プロセッサ1301の指示に従ってネットワークを介してデータを送受信する。例えば、通信インタフェース1306は、プロセッサ1301の指示に従って、顧客システム管理装置102、端末103と通信してよい。入出力インタフェース1307は、例えば、入力装置及び出力装置との間のインタフェースであってよい。入力装置は、例えばユーザからの指示を受け付けるキーボードやマウスなどのデバイスである。出力装置は、例えばディスプレーなどの表示装置、及びスピーカなどの音声装置である。
実施形態に係る各プログラムは、例えば、下記の形態で保守サーバ101に提供される。
(1)記憶装置1303に予めインストールされている。
(2)着脱可能記憶媒体1305により提供される。
(3)プログラムサーバなどのサーバから提供される。
なお、図13を参照して述べた保守サーバ101を実現するための情報処理装置1300のハードウェア構成は、例示であり、実施形態はこれに限定されるものではない。例えば、上述の機能部の一部または全部の機能がFPGA及びSoCなどによるハードウェアとして実装されてもよい。なお、FPGAは、Field Programmable Gate Arrayの略称である。SoCは、System-on-a-chipの略称である。
以上において、いくつかの実施形態が説明される。しかしながら、実施形態は上記の実施形態に限定されるものではなく、上述の実施形態の各種変形形態及び代替形態を包含するものとして理解されるべきである。例えば、各種実施形態は、その趣旨及び範囲を逸脱しない範囲で構成要素を変形して具体化できることが理解されよう。また、前述した実施形態に開示されている複数の構成要素を適宜組み合わせることにより、種々の実施形態が実施され得ることが理解されよう。更には、実施形態に示される全構成要素からいくつかの構成要素を削除して又は置換して、或いは実施形態に示される構成要素にいくつかの構成要素を追加して種々の実施形態が実施され得ることが当業者には理解されよう。
以上の実施形態に関し、更に以下の付記を開示する。
(付記1)
システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価し、
前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する、
処理をコンピュータに実行させる保守管理プログラム。
(付記2)
前記保守作業の作業密度を、前記保守作業の工数とリードタイムとに基づいて決定する処理を更に前記コンピュータに実行させる、付記1に記載の保守管理プログラム。
(付記3)
前記類似案件に対して過去に実施された前記保守作業の前記リードタイムよりも前記工数の方が所定の比率を超えて大きい場合、前記類似案件に第1の優先度を設定し、前記リードタイムよりも前記工数の方が所定の比率を超えて大きくはない場合、前記類似案件に前記第1の優先度よりも低い第2の優先度を設定する、付記2に記載の保守管理プログラム。
(付記4)
前記類似案件に対して過去に実施された前記保守作業の前記リードタイムよりも前記工数の方が所定の比率を下回って小さい場合、前記類似案件に第3の優先度を設定し、前記リードタイムよりも前記工数の方が所定の比率を下回って小さくはない場合に、前記類似案件に前記第3の優先度よりも高い前記第2の優先度を設定する、付記3に記載の保守管理プログラム。
(付記5)
前記システムからの保守依頼の発生頻度が所定の閾値を超える稼働不安定期において、前記第2の優先度を設定された前記類似案件と前記保守作業の分類が同じ分類に属する案件の発生頻度が所定値を超える場合よりも、前記発生頻度が前記所定値以下の場合の優先度を低く設定する、付記4に記載の保守管理プログラム。
(付記6)
前記システムに対する保守依頼の発生頻度が所定の閾値未満である稼働安定期において、前記第2の優先度を設定された前記類似案件と前記保守作業の分類が同じ分類に属する案件の発生頻度が所定値を超える場合よりも、前記発生頻度が前記所定値以下の場合の優先度を高く設定する、付記4に記載の保守管理プログラム。
(付記7)
前記類似案件の優先度に基づいて、前記依頼案件に優先度を設定し、
前記依頼案件と前記保守作業の対応時期が重なる別の案件と、前記依頼案件との間での作業の優先順位を、前記依頼案件に設定した優先度と、前記別の案件に設定されている優先度とに基づいて決定する、
処理を更に前記コンピュータに実行させる、付記1から6のいずれかに記載の保守管理プログラム。
(付記8)
コンピュータにより実行される保守管理方法であって、前記コンピュータが、
システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価し、
前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する、
ことを特徴とする保守管理方法。
(付記9)
システムに対して過去に実施された保守作業の複数の案件のなかから、前記システムに対する保守依頼で受け付けた依頼案件と類似している案件として特定された類似案件に対して過去に実施された保守作業の作業密度に基づいて、前記類似案件の優先度を評価する評価部と、
前記類似案件に関する情報を、評価した前記優先度とともに表示するための表示情報を出力する出力部と、
を含む、情報処理装置。