JP2018173793A - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Abstract

【課題】保守部品の在庫が十分でない場合であっても、保守対象製品の状況に応じて早期にメンテナンスサービスのスケジュール設定を可能とする。【解決手段】処理部は、製品の障害情報を基にメンテナンス作業の対象製品を特定し、メンテナンス作業の対象製品が有する部品の障害の発生を予測する。そして、処理部は、前記障害の発生が予測された部品に対して発生が予測された障害に応じてメンテナンス作業の優先度を決定し、障害の発生が予測された部品の入手可能時期と優先度とに応じて、上記特定された対象製品のメンテナンス作業のスケジュールを調整する。【選択図】図５

Description

本発明は、保守対象製品の在庫数量を調整する情報処理装置、情報処理方法およびプログラムに関する。

コンピュータ、サーバ、その他の情報システム製品等（以下、保守対象製品ともいう）のメンテナンスサービスでは、保守対象製品のフィールド品質、例えば、障害発生件数が監視される。そして、障害発生件数について、ＡＦＲ（Annual Failure Rate）の目標値
および異常値が設定される。そして、ＡＦＲの異常値を超過した保守対象製品に対し、フィールドＥＣ（Engineering Change）と呼ばれるメンテナンスサービスが実施される。ＥＣは、一例では、障害の原因となる部品を交換する作業である。

コンピュータ等の保守対象製品のメンテナンスサービスでは、ＡＦＲの異常値を超過した保守対象製品に対して、今後の障害発生件数、発生率が予測され、保守部品倉庫在庫数から、メンテナンスで使用される保守部品不足が見込まれる場合、保守部品の追加製作で在庫が確保される。

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

ところで、複数の保守対象製品が複数の顧客先に納入されている場合に、すべての納入先については保守部品を十分に確保できず、保守部品不足が見込まれる場合がある。上記従来の技術では、保守部品不足が見込まれる場合、保守部品の追加製作で保守部品が確保されるのを待って、全納入先についてメンテナンスサービスのスケジュールが設定される。しかしながら、メンテナンスの優先度は、納入された情報処理装置ごと、あるいは納入先の顧客ごとに異なる。また、保守部品の在庫状況によっては、一部の納入先の保守対象製品について先行してメンテナンスの実施が可能な場合もあり得る。

一側面では、本発明の目的は、保守部品の在庫が十分でない場合であっても、保守対象製品の状況に応じて早期にメンテナンスサービスのスケジュール設定が可能とすることである。

開示の技術の一側面は、次の情報処理装置によって例示される。本情報処理装置は、処理部を備える。本処理部は、製品の障害情報を基にメンテナンス作業の対象製品を特定し、前記メンテナンス作業の対象製品が有する部品の障害の発生を予測する。そして、本処理部は、前記障害の発生が予測された部品に対して前記発生が予測された障害に応じてメンテナンス作業の優先度を決定し、前記障害の発生が予測された部品の入手可能時期と前記優先度とに応じて前記特定された対象製品のメンテナンス作業のスケジュールを調整する。

本情報処理装置によれば、保守部品の在庫が十分でない場合であっても、保守対象製品
の状況に応じて早期にメンテナンスサービスのスケジュール設定が可能となる。

比較例に係る情報システムの構成を例示する図である。 比較例におけるメンテナンスサービス管理処理を例示する図である。 比較例におけるメンテナンスサービス管理処理を例示する図である。 比較例におけるメンテナンスサービス管理処理を例示する図である。 一実施形態に係る情報システムの構成を例示する図である。 コンピュータの構成を例示する図である。 出荷情報テーブルのデータ例である。 障害情報テーブルのデータ例である。 保守部品在庫管理テーブルのデータ例である。 障害発生予測テーブルのデータ例である。 顧客納入情報管理テーブルのデータ例である。 Data Table 1のデータ例である。 Data Table 2のデータ例である。 Data Table 3のデータ例である。 ＥＣ支援システムがList AからList Cまでを作成する処理を例示する図である。 ＥＣ支援システムがList DからList Eまでを作成する処理を例示する図である。 一実施形態の処理を例示するフローチャートである。 一実施形態の処理を例示するフローチャートである。 一実施形態の処理を例示するフローチャートである。 一実施形態の処理を例示するフローチャートである。

以下、図面を参照して、一実施形態に係る保守部品を管理する情報システムについて説明する。以下の実施形態の構成は例示であり、本情報システムは実施形態の構成には限定されない。
＜比較例＞

図１に、比較例に係る情報システムの構成を例示する。比較例の情報システムは、保守対象製品に対するメンテナンスサービスを支援し、管理する。ここで、保守対象製品は、納入先に納入され、稼働しているコンピュータ、サーバ等、メンテナンスの対象となっている製品をいう。

本情報システムのうち、障害情報システム５９０は、顧客に納入された製品の障害発生率に対しＡＦＲ（Annual Failure Rate）の目標値および異常値の設定を受け付け、毎月
の品質状況を監視する。すなわち、障害情報システム５９０は、顧客先（フィールドともいう）で稼働している製品のＡＦＲが目標値を達成していること、異常値に達していないことを監視する。

また、出荷情報システム５６０、障害情報システム５９０、および障害発生予測システム５４０は、ＡＦＲが上記異常値を超過した装置に対する原因の調査を支援する。例えば、障害発生予測システム５４０は、障害原因となっている部品の、今後の障害発生予測（稼動時間、出荷数に対する残存数・残存率）を算出し、ＣＥ(Customer Engineer)等に提
供する。

保守部品在庫管理システム５２０は、保守対象製品内の各部品（部品をユニットともい
う）について保守部品倉庫からの払出し数を監視する。顧客納入情報管理システム５３０は、顧客への納入情報を基にフィールドＥＣと呼ばれるメンテナンスサービスを支援する。

ところで、障害発生予測システム５４０から提供される障害発生予測および保守部品在庫管理システム５２０から提供される保守部品の倉庫在庫数から、交換対象の保守部品の不足が見込まれる場合、保守部品が追加製作される。すなわち、比較例の処理では、障害情報システム５９０がある製品の異常、つまり、ある製品がＡＦＲの目標値を超える異常を検知した場合、当該製品がメンテナンスサービスの対象となる。この場合、稼働中の当該製品のすべてについて保守部品を確保したうえで、メンテナンス作業のスケジュールが組まれ、メンテナンス作業が実施される。

図１の情報システムは、生産管理部門（工務部門ともいう）、製造部門（工場ともいう）、サポート部門、営業部門、ＣＥ（Customer Engineering）部門、開発部門、品質保証部門に設けられる各システムをネットワークで接続したものである。生産管理部門には、保守部品在庫管理システム５２０および顧客納入情報管理システム５３０が設けられる。製造部門には出荷情報システム５６０および修理情報システム５７０が設けられる。サポート部門には、障害情報システム５９０が設けられる。営業部門またはＣＥ部門には、保守情報システム５８０が設けられる。開発部門あるいは品質保証部門には、障害発生予測システム５４０が設けられる。以下、各部門のシステムを説明する。
（１）生産管理部門に設けられる保守部品在庫管理システム５２０および顧客納入情報管理システム５３０

保守部品在庫管理システム５２０は、ＣＥが顧客にて修理を行う際に払い出される保守部品在庫数を管理する。保守部品在庫管理システム５２０は、保守部品の在庫量を監視し、在庫量が規定の条件を充足するように、在庫量を調整する。保守部品在庫管理システム５２０は、保守部品在庫管理テーブルＣを記憶手段に有する。保守部品在庫管理テーブルＣは、保守部品ごとの在庫に関連する情報を記録する。保守部品在庫管理テーブルＣは、ユニット名（部品名）、在庫数、追加製作数、払い出し可能日、ベンダー修理依頼数（発注数）、修理の納期等を含む。

保守部品在庫管理システム５２０は、定期的または所定のイベント（例えば、部品の払出し等）をトリガにして、在庫調整処理を実行する。在庫調整処理では、保守部品在庫管理システム５２０は、保守部品ごとの在庫の不足数量を判定し、不足する保守部品について、不足数量の部品を追加手配する指示を発行する。このような追加手配の結果、追加製作数および払い出し可能日が更新される。

顧客納入情報管理システム５３０は、サーバ、コンピュータ、その他の製品、およびこれら製品に使用される部品の受注と納入を管理する。顧客納入情報管理システム５３０は、顧客納入情報管理テーブルＥを有している。顧客納入情報管理テーブルＥは、顧客への納入情報（顧客名、納入日、納入台数、装置番号）を格納する。

生産管理部門のスタッフの端末は、製品あるいは製品に搭載される部品の発注情報を顧客あるいはＳＥの端末から受け付ける。生産管理部門のスタッフの端末は、受け付けた発注情報を基に、顧客納入情報管理テーブルＥのレコードを作成し、製品あるいは部品の納入先、製品（装置）あるいは部品の名称等を記録する。また、生産管理部門のスタッフの端末は、製品の納入後、納入日、納入台数等を顧客納入情報管理テーブルＥの該当するレコードに記録する。また、生産管理部門のスタッフの端末は、受け付けた発注情報を基に、保守部品在庫管理テーブルＣの追加製作数、払い出し可能日等を更新する。
（２）製造部門（工場ともいう）に設けられる出荷情報システム５６０および修理情報シ
ステム５７０

出荷情報システム５６０は、出荷情報テーブルＡを記憶手段に有している。出荷情報テーブルＡは、製造部門から出荷した製品の個体を特定する情報（装置番号、出荷日、装置のユニット情報）を記憶する。また、例えば、出荷情報テーブルＡ（機歴情報ともいう）は、コンピュータ、サーバ等の製品の出荷日、およびその後の部品交換等の機歴を管理する。出荷情報テーブルＡは、装置番号、ユニット情報、出荷部品（装置に含まれる構成部品）、出荷日、出荷日を含む。なお、本実施形態で出荷日とは、製造部門（工場）から倉庫等への出荷を意味し、顧客への納品とは限らない。

修理情報システム５７０は、修理ために製造部門に返却された保守部品（ユニット）の故障の有無の判定結果、および故障の内容等を管理する。修理情報システム５７０が管理する情報は、障害品情報とも呼ばれる。

製造部門のスタッフの端末は、生産管理部門のスタッフの端末から、部品の発注を受ける。発注にしたがって部品が製造されると、製造部門のスタッフの端末は、保守対象製品の出荷情報テーブルＡ（機歴）を更新する。その後、製造された部品は、顧客先あるいはＳＥに送付される。

障害発生時には、製造部門のスタッフの端末は、サポート部門での一次障害分析に基づく障害レポートを受け付ける。製造部門では、スタッフによる二次障害調査が実施される。二次障害調査の結果、開発部門あるいは品質保証部門による調査が必要となった場合、製造部門のスタッフの端末は、開発部門あるいは品質保証部門のスタッフの端末に障害調査を依頼する。製造部門のスタッフの端末は、開発部門あるいは品質保証部門のスタッフの端末から、障害調査報告を受けると、修理情報システム５７０に障害品情報として保存する。

また、製造部門のスタッフの端末は、ベンダーの情報システムに修理依頼を送信する。ベンダーの情報システムは、修理依頼を受けると、製造部門のスタッフの端末に納品予定日を連絡する。製造部門のスタッフの端末は、納品予定日を生産管理部門のスタッフの端末に通知する。生産管理部門のスタッフの端末は、納品予定日を保守部品在庫管理システム５２０の保守部品在庫管理テーブルＣに登録する。

そして、ベンダーでは部品の修理が実施される。修理された部品は、納品予定日ごとに製造部門に返却され、ベンダーの情報システムは、修理完了報告を製造部門のスタッフの端末に送信する。製造部門のスタッフの端末は、修理完了報告を修理情報システム５７０に保存する。そして、調査および修理が完了すると、製造部門のスタッフの端末は、調査レポートあるいは修理結果レポートをサポート部門に発行する。
（３）サポート部門に設けられる障害情報システム５９０

障害情報システム５９０は、障害情報テーブルＢを記憶手段に有している。障害情報システム５９０は、ＣＥ作業によるフィールド障害情報（障害発生日、顧客情報、装置番号、交換ユニット）および、工場作業による交換部品の修理情報（故障有無判定、故障内容）から、下記障害発生率を算出するための式の分子を抽出する。そして、障害情報システム５９０は、出荷情報テーブルＡから得られる出荷数を分母として部品の障害発生率を算出する。
障害発生率＝（期間内の部品の障害件数／保守対象製品の期間内の延べ稼働台数）＊１２×１００（件／（百台・年））；
で計算される。

障害情報テーブルＢは、障害事例（インシデントともいう）別に、障害の内容を記録する。障害情報テーブルＢは、ＡＦＲ管理値、ユニット名、障害発生日、障害数量等を含む。

障害が発生すると、例えば、顧客あるいはＳＥの端末からサポート部門のスタッフの端末に障害が通知される。サポート部門では、一次分析が行われ、ＣＥによる部品交換の要否が判断される。部品交換が不要な場合、例えば、電話対応でサポートが実施され、障害情報システム５９０の障害情報テーブルＢに対応結果が保存される。

部品交換が必要な場合、営業部門あるいはＣＥ部門へ手配が通知される。そして、ＣＥ部門から保守部品の生産管理部門への発注、製造部門への二次障害分析の依頼、修理の依頼等が実施される。製造部門での二次障害分析、あるいは、修理が完了すると、調査レポートあるいは修理レポートが製造部門からサポート部門に送付される。サポート部門では、スタッフが調査レポートあるいは修理レポートを基に顧客に報告するとともに、障害情報テーブルＢに、調査あるいは修理の結果が反映される。
（４）営業部門またはＣＥ部門に設けられる保守情報システム５８０

保守情報システム５８０は、障害対応に伴う障害発生日、顧客情報、装置番号、交換ユニット等を管理する。保守情報システム５８０が管理する情報は、障害対応情報と呼ばれる。

障害発生により保守部品が必要な場合、営業部門またはＣＥ部門のスタッフの端末は、サポート部門のスタッフの端末から保守部品の手配を受ける。営業部門またはＣＥ部門のスタッフの端末は手配を受けると、生産管理部門のスタッフの端末に保守部品を発注する。生産管理部門から保守部品が届くと、ＣＥ部門のスタッフは、顧客先の製品での交換作業を実施する。交換作業後、営業部門またはＣＥ部門のスタッフの端末は保守情報システム５８０に作業結果を入力する。また、ＣＥ部門のスタッフの端末は、製造部門のスタッフの端末に障害レポートを発行する。また、障害が発生した部品の調査あるいは修理が必要な場合、ＣＥ部門から製造部門に部品が返却される。
（５）開発部門あるいは品質保証部門に設けられる障害発生予測システム５４０

障害発生予測システム５４０は、出荷情報テーブルＡと障害情報テーブルＢより抽出される保守対象製品および部品の障害発生率から、今後の障害発生状況（今後の障害発生率、障害発生までの稼動時間、出荷数に対する部品の残存数・残存率）を予測する。障害発生予測システム５４０は、障害発生予測テーブルＤを有する。障害発生予測テーブルＤは、顧客に納入された製品ごとに、ＡＦＲ管理値、障害発生予測日、メンテナンスの作業日と完了日、今後のＡＦＲ予測値、および今後の予測稼働期間等を格納する。

以下、図２から図４により、比較例の情報システムのおけるメンテナンスサービス管理処理を例示する。図２は、障害発生予測システム５４０の処理を例示するフローチャートである。

障害発生予測システム５４０は、顧客に納入されたコンピュータ、サーバ等の保守対象製品について障害発生情報を収集している（Ｃ１）。障害発生情報は、例えば、製造部門に返却された部品で実際に故障したものの数と使用期間、ＣＥ部門から報告された消耗品の交換数量と使用期間等である。障害発生予測システム５４０は、例えば、ネットワークを通じて、あるいは、開発部門の端末、品質保証部門の端末から障害発生情報の入力を受け付ける。そして、障害発生情報の入力を契機に、障害発生予測システム５４０は、障害発生情報に含まれる部品を搭載したコンピュータ、サーバ等製品の障害発生予測値を算出する。製品の障害発生予測値は、個々の部品の障害発生予測値ではなく、１つの製品に搭
載されたすべての部品の実際の障害を基に、当該製品、つまり装置全体で発生すると想定される障害発生予測値である。このような製品の障害発生予測値は、実際の障害発生の状況を日々蓄積することで製品ごとに経験的に算出される。そして、障害発生予測システム５４０は、障害発生予測値がＡＦＲの管理値を越えているか否かを判定する（Ｃ２）。

障害発生予測値がＡＦＲの管理値を越えていない場合、障害発生予測システム５４０は、Ｃ１の処理に戻る。一方、障害発生予測値（以下、ＡＦＲ予測値という）がＡＦＲの管理値を越えている場合、障害発生予測システム５４０は、開発部門の端末あるいは品質保証部門の端末に異常を通知する（Ｃ３）。

すると、障害発生予測システム５４０は、開発部門の端末あるいは品質保証部門の端末から担当者の操作を受け付け、詳細調査処理を開始する（Ｃ４）。まず、障害発生予測システム５４０は、異常が通知された製品に搭載されている全部品について、ＡＦＲ予測値がＡＦＲ管理値を越える部品を異常ユニットとして特定する（Ｃ５）。

そして、異常ユニットが搭載された製品のすべてについて、搭載された部品数を集計し、今後の障害部品数を算出する。なお、複数の製品について、同数の部品が搭載されている場合には、製品に搭載された部品の数と部品が搭載された製品の数を乗算すればよい。

次に、障害発生予測システム５４０は、異常ユニットについて、今後の障害発生数が保守部品在庫数を越えるか否かを判定する（Ｃ７）。異常ユニットについて、今後の障害発生数が保守部品在庫数を越える場合、障害発生予測システム５４０は、処理をＡ２（図３のＣ１０）に進める。一方、今後の障害発生数が保守部品在庫数を越えない場合、障害発生予測システム５４０は、処理をＡ１（図４のＣ３０）に進める。

図３は、今後の障害発生数が保守部品在庫数を越える場合の処理を例示するフローチャートである。この処理では、障害発生予測システム５４０は、保守部品の不足分を製造するための発注を生産管理部門の保守部品在庫管理システム５２０に依頼する（Ｃ１０）。

保守部品在庫管理システム５２０は、障害発生予測システム５４０からの依頼を受けると、保守部品の不足分の製造を製造部門の出荷情報システム５６０に発注する（Ｃ１１）。製造部門の出荷情報システム５６０は、受注を受け付け（Ｃ１２）、納品スケジュールを保守部品在庫管理システム５２０に送信する（Ｃ１３）。保守部品在庫管理システム５２０は、受信した納品スケジュールを基に、追加作成分の納品スケジュールを保存し、保守部品在庫管理テーブルＣを更新する（Ｃ１４）。

受注により、製造部門では、保守部品が製造され（Ｃ１５）、生産管理部門宛に出荷され（Ｃ１６）、出荷数等の出荷状況が記録される。そして、製造部門では、出荷数が受注数となるまで、製造が継続される（Ｃ２２）。そして、出荷数が受注数となると製造が完了する（Ｃ２３）。

一方、生産管理部門は、製造された保守部品を受け付け（Ｃ１７）、部品を各地の部品倉庫に入庫する（Ｃ１８）。このとき、保守部品在庫管理システム５２０は、保守部品在庫管理テーブルＣの在庫情報を更新する（Ｃ１９）。さらに、保守部品在庫管理システム５２０は、納品状況を障害発生予測システム５４０に報告する（Ｃ２０）。

障害発生予測システム５４０は、納品状況の報告を基に、異常ユニットについて今後の障害発生数が保守部品在庫数に追加製作数を加えた数を越えるか否かを判定する（Ｃ２１）。すなわち、障害発生予測システム５４０は、まだ保守部品が不足しているか否かを判定する。保守部品が不足している場合、障害発生予測システム５４０は、処理をＡ２１に
戻し、保守部品のさらなる入荷を待つ。一方、保守部品が不足しない場合、障害発生予測システム５４０は、処理をＡ１（図４のＣ３０）に進める。なお、以上のＣ１からＣ２２までの処理は、すべての異常ユニットに対して実行される。

図４は、保守部品が不足していない場合の情報システムの処理を例示するフローチャートである。障害発生予測システム５４０は、すべての異常ユニットについて保守部品が不足していない場合、ＥＣレポートを営業部門またはＣＥ部門の保守情報システム５８０に発行する（Ｃ３０）。

保守情報システム５８０は、ＥＣレポートを受けると、端末から担当者の操作を受け付け、ＥＣ作業日、すなわち、メンテナンス作業日を顧客あるいはＳＥとの間で調整する（Ｃ３１）。そして、保守情報システム５８０は、メンテナンス作業日の調整結果を受け付ける（Ｃ３２）。さらに、ＣＥ部門は、生産管理部門から保守部品を取り寄せ（Ｃ３３）、調整されたスケジュールにしたがって、ＣＥを派遣する（Ｃ３４）。ＣＥが顧客先でメンテナンス作業を実施後、保守情報システム５８０は、ＥＣ作業情報の更新を受け付け（Ｃ３５）、ＥＣ作業完了報告を障害発生予測システム５４０に送付する（Ｃ３６）。

障害発生予測システム５４０は、ＥＣ作業完了報告を受けると、ＥＣ作業がすべて完了したか否かを判定する（Ｃ３７）。未完のＥＣ作業がある場合には、障害発生予測システム５４０は、次の完了報告を待つ。一方、ＣＥ部門でのＥＣ作業がすべて完了した場合、障害発生予測システム５４０は、ＥＣ作業のメンテナンス管理処理を終了する（Ｃ３８）。

以上のように、比較例では、保守部品が不足していないことを前提にメンテナンス作業のスケジュールが調整され、ＣＥの派遣日程が調整され、メンテナンス作業が実施される。このため、比較例の処理では、優先度の高いメンテナンス対象の製品が稼働していても、優先度にしたがって柔軟にメンテナンス作業のスケジュールを設定することが困難となっている。比較例の処理では、どの保守対象の製品を優先してメンテナンスすればよいか、あるいは、ある部品不足していてもメンテナンスが可能な製品はあるか、という判断のための仕組みがない。

すなわち、比較例のＥＣ対応では、対応に必要な原資（保守部品等）を確保したうえで、ＣＥに対し、保守対象の製品すべてにＥＣを指示していた。しかし、比較例の処理では、ＣＥの判断で作業日等の調整を行っていたため、本来優先すべき顧客の作業が後回しになる可能性があり、効率が悪く顧客満足度の低下を招いていた。

また、ユニット保守部品が不足する場合、保守部品の追加製作により原資を確保した上でＥＣが実施されるため、ＥＣ開始まで時間を要する問題があった。そこで、以下の実施形態では、統計的手法により得られるフィールド障害の発生予測値と顧客への保守対象装置納入時の情報が組み合わせて利用される。すなわち、実施形態の情報システムは、少数個の保守部品原資を元に効率的なフィールドＥＣ、すなわち、メンテナンスサービスを可能とする、優先顧客リストをシステム上で自動生成する。そして、実施形態の情報システムは、複数の製品が稼働している場合に、客観的に製品のメンテナンスの優先度を特定し、部品が不足した状態であっても、メンテナンスの実施が可能な保守対象の製品ついて、優先度順にメンテナンスサービスの実施を支援する。
＜実施形態＞

以下、図５から図２０を参照して、一実施形態に係る情報システムを説明する。本情報システムは、以下に例示する各部門の情報処理装置に構築されるそれぞれのシステムが連携して製品のメンテナンスを支援する情報処理方法を実行する。各情報処理装置には、そ
れぞれ情報処理装置には、この情報処理方法を実行させるためのプログラムが搭載される。
（構成）

図５に、本実施形態に係る情報システムの構成を例示する。本実施形態の情報システムも、比較例と同様、生産管理部門（工務部門ともいう）、製造部門（工場ともいう）、サポート部門、営業部門、ＣＥ部門、開発部門、品質保証部門に設けられる各システムをネットワークで接続したものである。生産管理部門には、保守部品在庫管理システム２０および顧客納入情報管理システム３０が設けられる。保守部品在庫管理システム２０は、保守部品在庫管理テーブルＣを記憶手段に記憶し、顧客納入情報管理システム３０は、顧客納入情報管理テーブルＥを記憶手段に記憶する。保守部品在庫管理システム２０および顧客納入情報管理システム３０の構成および作用は、比較例の保守部品在庫管理システム５２０および顧客納入情報管理システム５３０の構成および作用と同様であるので、その説明を省略する。

製造部門には出荷情報システム６０および修理情報システム７０が設けられる。出荷情報システム６０は、出荷情報テーブルＡを記憶手段に記憶する。出荷情報システム６０および修理情報システム７０の構成および作用は比較例の出荷情報システム５６０および修理情報システム５７０と同様であるので、その説明を省略する。

営業部門またはＣＥ部門には、保守情報システム８０が設けられる。サポート部門には、障害情報システム９０が設けられる。障害情報システム９０は、障害情報テーブルＢを記憶手段に記憶する。保守情報システム８０および障害情報システム９０の構成および作用は、比較例の保守情報システム５８０および障害情報システム５９０と同様であるので、その説明を省略する。

開発部門あるいは品質保証部門には、障害発生予測システム４０およびＥＣ支援システム５０が設けられる。障害発生予測システム４０は、障害発生予測テーブルＤを記憶手段に保持する。障害発生予測システム４０の構成および作用は、比較例の障害発生予測システム５４０と同様であるので、その説明を省略する。

ＥＣ支援システム５０は、ＥＣを実施する顧客の優先リストを自動生成し、保守部品の在庫数量および追加発注分の納入予定日を反映して、優先リストの順に保守部品を充当し、ＥＣ可能日を設定し、ＥＣを効率的に支援する。より具体的には、ＥＣ支援システム５０は、以下の手順を実行する。

ＥＣ支援システム５０は、顧客納入情報管理システム３０、障害発生予測システム４０および出荷情報システム６０と連携し、顧客に納入された製品の情報を収集する。収集された製品の情報は、顧客名、納入日、納入数、障害発生日、部品構成等を含む。収集された製品の情報は、Data table 1に保存される。ＥＣ支援システム５０は、障害情報システム９０および障害発生予測システム４０から各部品のＡＦＲ管理値、各部品の今後の障害発生の予測情報、稼働期間情報等を取得し、Data table 2に保存する。

さらに、ＥＣ支援システム５０は、障害発生予測システム４０から得られる今後の障害発生率と保守部品在庫管理システム２０から得られる在庫数から、在庫不足分の発注処理を実行する。そして、ＥＣ支援システム５０は発注処理の実行により、部品の納入予定日（払い出し可能時期）および納入数量の情報を受信する。そして、ＥＣ支援システム５０は、保守部品在庫管理システム２０から得られる保守部品在庫の在庫数、追加製作数、払い出し可能時期等の情報をData table 3に保存する。

そして、ＥＣ支援システム５０は、顧客納入情報管理システム３０より得られる納入済み製品の納入日情報と障害発生予測システム４０より得られる障害に至るまでの稼動時間から障害発生予測日を算出した一次リスト（LIST Aと呼ぶ）を生成する。

次に、ＥＣ支援システム５０は、LIST Aに対し、障害発生予測システム４０から得られる故障タイプにより、出荷日の優先度を決定し、LIST Bを生成する。さらに、ＥＣ支援システム５０は、LIST Bに対し、納入数の多い顧客を優先し、LIST Cを生成する。

次に、ＥＣ支援システム５０は、LIST Cに対し、ＥＣ可能日を付与し、LIST Dを生成する。そして、ＥＣ支援システム５０は、顧客との調整結果を反映したLIST Eを生成し、ＥＣ可能日順にソーティングし、ＥＣを管理する。以降、ＥＣ完了ごとにLIST Dを更新する。さらに、ＥＣ支援システム５０は、保守部品納入日が決定する毎に、ＥＣ完了までLIST
DからLIST Eを自動で更新し、ＥＣを管理する。

図６に、コンピュータ１の構成を例示する。コンピュータ１は、保守部品在庫管理システム２０、顧客納入情報管理システム３０、障害発生予測システム４０、ＥＣ支援システム５０、出荷情報システム６０、修理情報システム７０、保守情報システム８０、障害情報システム９０として使用可能である。また、コンピュータ１は、各部門の端末等を例示しているともいえる。コンピュータ１はＣＰＵ１１と、主記憶部１２と、インターフェース（Ｉ／Ｆ）を通じて接続される外部機器を有し、プログラムにより情報処理を実行する。コンピュータ１は情報処理装置の一例である。外部機器としては、外部記憶部１３、表示部１４、操作部１５、および通信部１６を例示できる。

ＣＰＵ１１は、主記憶部１２に実行可能に展開されたコンピュータプログラムを実行し、コンピュータ１の機能を提供する。主記憶部１２は、ＣＰＵ１１が実行するコンピュータプログラム、ＣＰＵ１１が処理するデータ等を記憶する。主記憶部１２は、Dynamic Random Access Memory（ＤＲＡＭ）、Static Random Access Memory（ＳＲＡＭ）、Read Only Memory（ＲＯＭ）等である。さらに、外部記憶部１３は、例えば、主記憶部１２を補
助する記憶装置として使用され、ＣＰＵ１１が実行するコンピュータプログラム、ＣＰＵ１１が処理するデータ等を記憶する。外部記憶部１３は、ハードディスクドライブ、Solid State Disk（ＳＳＤ）等である。さらに、コンピュータ１には、着脱可能記憶媒体の駆動装置を設けてもよい。着脱可能記憶媒体は、例えば、ブルーレイディスク、Digital Versatile Disk（ＤＶＤ）、Compact Disc（ＣＤ）、フラッシュメモリカード等である。

また、コンピュータ１は、表示部１４、操作部１５、通信部１６を有する。表示部１４は、例えば、液晶ディスプレイ、エレクトロルミネッセンスパネル等である。操作部１５は、例えば、キーボード、ポインティングデバイス等である。本実施形態では、ポインティングデバイスとしてマウスが例示される。通信部１６は、ネットワーク上の他のコンピュータ等とデータを授受する
＜データ例＞

図７は、出荷情報テーブルＡのデータ例である。出荷情報テーブルＡは、受注番号、出荷日、装置品名、装置番号、出荷数、ユニット情報の各フィールドを含む。受注番号は、製品の受注案件を識別する情報である。受注番号は、出荷情報テーブルＡにおいてレコート（表の行）を一意に特定する情報でもある。出荷日は、受注された製品が製造部門から出荷された日である。ただし、出荷先は、顧客先とは限られず、倉庫等の場合もあり得る。装置品名は、受注および出荷の対象である製品の品名である。装置番号は、装置に付与される通し番号（シリアル番号）である。出荷数は、受注番号で特定される受注に対応して出荷日に出荷された製品の台数である。出荷台数が複数の場合、装置番号のフィールドには、出荷台数分の装置番号が列挙される。ただし、出荷台数分の装置番号のうち、先頭
の装置番号が出荷番号のフィールドに記録されるようにしてもよい。ユニット情報は、構成情報とも呼ばれ、受注および出荷対象の製品に搭載される部品の一覧である。部品としては、例えば、ＣＰＵ（Central Processing Unit）、ＨＤＤ（Hard Disk Drive）、ＤＩＭＭ（Dual Inline Memory Module）等を例示できる。

図８は、障害情報テーブルＢのデータ例である。障害情報テーブルＢは、インシデント番号、障害発生日、障害数量、障害装置名、障害ユニット名、ＡＦＲ（％）、ＡＦＲ（％）管理値を有している。インシデント番号は、障害情報テーブルＢにおいてレコート（表の行）を一意に特定する情報である。障害発生日は、当該障害が最初に発生した日である。障害数量は、当該障害が発生した製品の台数である。障害装置名は、当該障害が発生した製品の名称である。なお、障害数量が２以上の場合、障害装置名は、複数列挙される。ただし、障害数量が２以上の場合、１台の製品の名称を代表として障害装置名のフィールドに格納するようにしてもよい。障害ユニット名は、当該障害の原因となった故障した部品の名称である。ＡＦＲ（％）は、当該インシデントから算出される年間の故障数である。インシデントは、基本的に1件の事象発生で発行されることは無く、複数、同様な事象
が発生し、インシデントが発行される。そのため、一つのインシデントに対し、年間の故障率ＡＦＲを算出することができ、ユニット毎に持っているAFR管理値と比較することが
できる。ＡＦＲ（％）管理値は、ＡＦＲにより製品によるサービスの品質を判断するための基準値である。ＡＦＲの値がＡＦＲ（％）管理値を越える場合、製品の品質が低いと判断され、製品は、ＥＣ作業すなわちメンテナンスの対象となる。

図９は、保守部品在庫管理テーブルＣのデータ例である。保守部品在庫管理テーブルＣは、ユニット名、在庫数、追加製作数、追加製作分納期（払出し可能日）、ベンダー修理発注数、ベンダー修理納期の各フィールドを有している。ユニット名は、部品名称であり、保守部品在庫管理テーブルＣのレコード（行）を一意に識別する情報である。在庫数は、各地の倉庫に保管された部品の在庫総数である。追加製作数は、現在発注済みで製作中の部品の個数である。追加製作分納期（払出し可能日）は、製作中の部品の納期であり、製作中の部品の入荷日である。ベンダー修理発注数は、当該部品のうちベンダーで修理中の個数である。ベンダー修理納期は、修理中の部品の修理が完了し、返却される時期（納期）である。

図１０は、障害発生予測テーブルＤのデータ例である。障害発生予測テーブルＤは、顧客名、納入日、装置品名、装置番号、故障ユニット名、今後のＡＦＲ予測値、今後の予測稼働期間、故障形状ｍ値の各フィールドを有している。顧客名は、製品の納入先である。納入日は、製品の納入日である。納入日としては、製品の据え付け後、検収試験が完了した日が格納される。ただし、納入日として、製造部門からの出荷日を実際の納入日に代えて用いてもよい。また、製品に搭載された各部品（故障ユニット）が交換されている場合には、納入日として、部品の交換日を使用するようにしてもよい。部品の交換日を障害発生予測に用いることで、障害発生予測の精度を向上できる。部品の交換日は、機歴情報として、出荷情報システム６０に保持されている。

装置品名は、製品の品名であり、装置番号は、通し番号である。故障ユニット名は、故障予測の対象となっている部品の名称である。今後のＡＦＲ予測値は、現段階でのＡＦＲの予測値である。ＡＦＲの予測値は、障害情報テーブルＢのレコードが更新されたことを契機に、随時更新される。今後の予測稼働期間は、現段階での当該部品の稼働期間の予測値である。稼働期間の予測値は、障害情報テーブルＢのレコードが更新されたことを契機に、随時更新される。故障形状ｍ値は、ワイブル分析を行うと得られる、ワイブルパラメータの一つで、ｍの値で、故障の形態（初期（m＜1）、偶発（m＝1）、摩耗（m＞1））が判別できる。

なお、今後のＡＦＲ予測値および今後の予測稼働期間は、信頼性データをモデル化するためのワイブル分布等を用いた公知の手法により算出される。このような手法では、予測対象部品を搭載した装置の稼働期間（納品日あるいは部品交換日からの稼働日数）と、現時点で収集済みの当該部品の障害発生の状況（稼働期間と障害の発生率）等のデータが利用される。このようなデータを基に、所定のモデルにしたがって今後の信頼性データ（障害発生率、稼働期間等）が予測される。

図１１は、顧客納入情報管理テーブルＥのデータ例である。顧客納入情報管理テーブルＥは、顧客名、納入日、納入数、装置番号、保守系契約番号の各フィールドを有している。顧客名は、製品の納入先である。納入日は、製品の顧客先への納入日である。装置番号は通し番号（シリアル番号）である。納入数が２以上の場合、装置番号は複数列挙される。ただし、納入数が２以上の場合、装置番号のフィールドに先頭の装置番号を格納するようにしてもよい。保守契約番号は、保守契約の条件（契約書）を一意に特定する番号である。

図１２は、Data Table 1のデータ例である。上述のように、Data Table 1は、ＥＣ支援システム５０によって本情報システムのうちの顧客納入情報管理システム３０、障害発生予測システム４０および出荷情報システム６０より収集された情報を組み合わせたデータを有する。図のように、Data Table 1の各レコード（行）は、顧客納入情報管理システム３０より収集された顧客名、納入日、納入数を含む。

また、Data Table 1の各レコード（行）は、障害発生予測日、ＥＣ作業日（確定）、およびＥＣ作業完了のフィールドを含む。障害発生予測日、ＥＣ作業日（確定）、およびＥＣ作業完了のフィールドは、障害発生予測システム４０の障害発生予測テーブルＤから取得したものである。すなわち、障害発生予測テーブルＤの納入日に、今後の予測稼働期間を加算することで、障害発生予測日が計算される。したがって、すなわち、障害発生予測テーブルＤの納入日が最新の部品交換日の場合には、最新の部品交換日から想定される障害発生予測日が格納される。ただし、障害発生予測システム４０は、すでに障害が発生した部品に関しては、発生日を有している。また、障害発生予測システム４０は、ＥＣ作業日（確定した予定日）と、ＥＣ作業完了日のデータを有している。そこで、すでに障害が発生した部品に関しては、Data Table 1には、障害の発生日が格納される。また、Data Table 1には、障害発生予測システム４０から収集されたＥＣ作業日（確定した予定日）と、ＥＣ作業完了日が格納される。また、障害発生予測システム４０は、障害の発生日、ＥＣ作業日（確定した予定日）、ＥＣ作業完了日を障害発生予測システム４０の代わりに保守情報システム８０から収集するようにしてもよい。さらに、Data Table 1は、出荷情報システム６０から取得したユニット情報（構成情報）を含む。

図１３は、Data Table 2のデータ例である。上述のように、ＥＣ支援システム５０は、障害情報システム９０および障害発生予測システム４０から各部品のＡＦＲ（％）管理値、今後のＡＦＲ予測値（障害発生の予測情報）、予測稼働期間情報等を取得し、Data table 2に保存する。図のように、Data table 2は、障害情報システム９０から収集したユニット名およびＡＦＲ（％）管理値と、障害発生予測システム４０から収集した今後のＡＦＲ予測値、今後の予測稼働期間（月）、および故障タイプｍ値とを含む。なお、図１３のＨＤＤ２の行に例示したように、今後のＡＦＲ予測値がＡＦＲ（％）管理値を越える場合には、ＥＣ支援システム５０は、異常があると判断し、該当する部品をメンテナンス対象の部品とする。

図１４は、Data Table 3のデータ例である。上述のように、ＥＣ支援システム５０は、保守部品在庫管理システム２０から得られる情報をData table 3に保存する。図のように、Data table 3は、ユニット名、在庫数、追加製作数、追加製作分納期（払出し可能日）
、ベンダー修理依頼数、およびベンダー修理納期を有する。
＜処理フロー＞

図１５および図１６は、ＥＣ支援システム５０がList AからList Eまでを作成する処理を例示する図である。ＥＣ支援システム５０は、Data table 1を基に、顧客名、納入時期、納入数、障害発生予測日（または障害発生日）を含む一次リストであるLIST Aを生成する。

次に、ＥＣ支援システム５０は、LIST Aに対し、障害発生予測システム４０から得られる故障タイプにより、納入日による優先度を決定し、LIST Bを生成する。故障タイプには、初期故障型、摩耗故障型、および両者以外の故障型が想定される。図１５、図１６は、初期故障以外の処理例である。初期故障以外の場合には、LIST Aを納入時期の早い順に優先する顧客を決定するリスト（List B）を作成する。ただし、初期故障以外の場合には、納入時期に代えて、障害発生予測日が早い顧客を優先するようにしてもよい。

次に、ＥＣ支援システム５０は、LIST Bにおいて納入時期が同月内の顧客があれば、納入数の多い顧客を優先してリストを再生成し、LIST Cとする。さらに、ＥＣ支援システム５０は、LIST CにＥＣ対応可能日とＥＣ作業日（確定）のフィールドを付与し、LIST Dとする。そして、ＥＣ支援システム５０は、LIST Dにおいて優先顧客順に保守部品在庫（受納期分を含め）を割り当て、ＥＣ対応可能日を設定する。ＥＣ対応可能日は、ＥＣ対応が可能となる日付けである（図１６）。例えば、２０１５年９月２６日時点の保守部品在庫数５０台でＥＣ対応可能な顧客は、優先順位１位から３位の顧客となる。また、2015/10/30時点（受納期）の保守部品在庫数３０台を含めると、ＥＣ対応可能な顧客は、優先順位４位から６位の顧客となる。さらに、2015/11/5時点（受納期）の保守部品在庫数２０台
を含めるとＥＣ対応可能な顧客は、優先順位７位から９位の顧客となる。

次に、ＥＣ支援システム５０は、担当者の操作にしたがい、顧客との調整の結果得られるＥＣ作業日をLIST DのＥＣ作業日（確定）のフィールドに追加する。そして、ＥＣ支援システム５０は、LIST DにおいてEC作業日の日程が早い順にリストを再生成し、LIST Eとする。１つのＥＣ作業が完了すると、ベンダー修理が必要な場合には、ベンダー修理依頼がなされ、修理の受納期の日付を考慮してLIST Dから優先順位が再生成される。

図１７から図２０は、ＥＣ支援システム５０を含む本情報システムの処理を例示するフローチャートである。本情報システムが構築されるコンピュータ１のＣＰＵ１１は、処理部の一例である。なお、本情報システムは、複数のコンピュータ１が連携して情報処理を実行するものでよい。その場合には、連携する複数のコンピュータ１の複数のＣＰＵ１１が処理部となる。

この処理では、顧客に納入されたコンピュータ、サーバ等の製品について障害発生予測システム４０は、障害発生情報を収集している（Ｓ１）。そして、障害発生予測システム４０は、ある製品の障害発生予測値がＡＦＲの管理値を越えているか否かを判定する（Ｓ２）。Ｓ１、Ｓ２の処理は、比較例のＣ１、Ｃ２と同様である。すなわち、Ｓ１、Ｓ２により、障害発生予測システム４０は、コンピュータ、サーバ等の一の製品において、全部品での障害を集積した製品全体の障害発生予測値を算出する。このような製品の障害発生予測値は、実際の障害発生の状況を日々蓄積することで製品ごとに経験的に算出される。Ｓ１、Ｓ２の処理は、製品の障害情報を基にメンテナンス作業の対象製品を特定することの一例である。

今後の一の製品の障害発生予測値がＡＦＲ管理値を越えるものがない場合、ＥＣ支援システム５０は、Ｓ１の処理に戻る。一方、ある製品の障害発生予測値（今後のＡＦＲ予測
値）がＡＦＲ管理値を越えるものがある場合、障害発生予測システム４０は、ＥＣ支援システム５０に異常通知を送信する（Ｓ３）。Ｓ３の処理は、メンテナンス作業の対象製品の指定を受け付けることの一例である。異常通知には、障害発生予測値がＡＦＲ管理値を越える製品とその納入先の顧客が含まれる。すると、ＥＣ支援システム５０は、Ｓ３で受けた異常通知を基に、顧客納入情報管理システム３０の顧客納入情報管理テーブルＥから顧客名(a)、納入日(b)、装置納入数(c)を収集し、Data Table 1へ保存する（Ｓ４）。こ
こで、(a)から(c)等は、Data Table 1に記載した符号である。

次に、ＥＣ支援システム５０は、Ｓ３で受けた異常通知を基に、出荷情報システム６０の出荷情報テーブルＡから、異常通知の対象の製品のユニット情報(e)を収集し、Data Table 1へ保存する（Ｓ５）。ここで、(e)はData Table 1に記載した符号である。

次に、ＥＣ支援システム５０は、Ｓ５で収集したユニット情報(e)を基に、障害情報シ
ステム９０の障害情報テーブルＢから部品名(g)ごとのＡＦＲ管理値(h)を収集し、Data Table 2に保存する（Ｓ６）。ここで、(g)(h)は、Data Table 2の符号である。また、ＥＣ支援システム５０は、障害発生予測システム４０から、今後のＡＦＲ予測値を取得し、Data Table 2に保存する。そして、ＥＣ支援システム５０は、Table 2で、ＡＦＲ予測値が
ＡＦＲ管理値を越える部品を異常ユニットとして特定する（Ｓ７）。Ｓ７の処理は、メンテナンス作業の対象製品が有する部品の障害の発生を予測することの一例である。

そして、ＥＣ支援システム５０は、Data Table 1で、顧客毎の障害部品＝製品内の障害部品の部品数×製品の納入数を算出する（Ｓ８）。ただし、製品ごとに障害部品の部品数が異なる場合には、ＥＣ支援システム５０は、製品ごとに製品に搭載された障害部品の部品数を取得し、積算すればよい。

そして、ＥＣ支援システム５０は、顧客毎の障害部品数の合算値を算出し、今後の障害発生数(f)として Data Table 1へ保存する（Ｓ９）。ここで、(f)は、図１２のData Table 1のフィールドの符号である。次に、ＥＣ支援システム５０は、保守部品在庫管理シス
テム２０の保守部品在庫管理テーブルＣから保守部品のユニット名(k)毎の保守部品の在
庫数(l)、追加製作数(m)、追加製作分納期（払出し可能日）(n)を収集し、Data Table 3
へ保存する（Ｓ１０）。ここで、(k)から(n)は、図９の保守部品在庫管理テーブル、および図１３のData Table 3のフィールドの符号である。そして、ＥＣ支援システム５０は、Ｂ１の処理、すなわち、図１８のＳ２０に処理を進める。

そして、ＥＣ支援システム５０は、今後の障害発生数(f)が保守部品の在庫数(l)を越えるか否かを判定する（Ｓ２０）。今後の障害発生数(f)が保守部品の在庫数(l)を越える場合、ＥＣ支援システム５０は、保守部品の不足分の製造発注を保守部品在庫管理システム２０に依頼し、Ｓ３３の処理に進む。なお、今後の障害発生数(f)が保守部品の在庫数(l)を越えない場合、ＥＣ支援システム５０は、そのままＳ３３の処理に進む。なお、図１８でＳ２２からＳ３２の処理は、比較例のＣ１１からＣ１９の処理、およびＣ２１からＣ２２の処理と同様であるので、その説明を省略する。

そして、ＥＣ支援システム５０は、障害発生予測システム４０の障害発生予測テーブルＤから今後の予測稼働期間(j)を収集し、Data Table 2へ保存する（Ｓ３３）。次に、Ｅ
Ｃ支援システム５０は、製品の納入日(b)に今後の予測稼働期間(j)を加えて障害発生予測日(d)としてData Table 1へ保存する（Ｓ３４）。なお、製造部門の出荷情報システム６
０は、各製品の機歴情報を有し、機歴情報には、各製品の部品交換の履歴が記録されている。したがって、ＥＣ支援システム５０は、出荷情報システム６０から機歴情報を取得し、Data Table 2の障害発生予測日(d)としては、製品の機歴に基づく、部品交換日（ＥＣ
作業日）に今後の予測稼働期間(j)を加えることで求めてもよい。また、障害発生予測シ
ステム４０が、障害発生予測テーブルＤの納入日に、部品交換日を格納しておいてもよい。そして、ＥＣ支援システム５０は、部品交換日（ＥＣ作業日）に今後の予測稼働期間(j)を加えることで障害発生予測日(d)を求めてもよい。

次に、ＥＣ支援システム５０は、障害発生部品が含まれるData Table 1の顧客名(a)、
製品の納入日(b)、納入数(c)、障害発生予測日(d)のみを抽出しLIST A を作成する（Ｓ３５）。さらに、ＥＣ支援システム５０は、Data Table 1の故障タイプ情報を収集する（Ｓ３６）。そして、ＥＣ支援システム５０は、Ｂ２の処理、すなわち、図１９のＳ４０の処理に進む。

ＥＣ支援システム５０は、故障タイプが初期故障型か否かを判定する（Ｓ４０）。故障タイプが初期故障型である場合、ＥＣ支援システム５０は、LIST Aを納入日の新しい順にソートし、LIST Bを作成する（Ｓ４２）。故障タイプが初期故障型でない場合、ＥＣ支援システム５０は、故障タイプが摩耗故障型か否かを判定する（Ｓ４１）。故障タイプが摩耗故障型である場合、ＥＣ支援システム５０は、LIST Aを納入日の古い順にソートし、LIST Bを作成する（Ｓ４３）。故障タイプが摩耗故障型でない場合、ＥＣ支援システム５０は、LIST Aを納入日の古い順にソート後、実際に障害が発生している顧客を最上位に移動し、LIST Bを作成する（Ｓ４４）。なお、Ｓ４３、Ｓ４４の処理では、LIST Aを納入日の古い順にソートする代わりに、障害発生予測日の早い順にソートしてもよい。Ｓ４０、Ｓ４１の処理は、発生が予測された障害の種類に応じて障害の発生が予測された部品の分類を実施することの一例である。Ｓ４２〜Ｓ４４の処理は、分類別に優先度を決定することの一例である。Ｓ４２〜Ｓ４４の処理は、障害の発生が予測された部品が搭載された対象製品の稼働期間に応じて優先度を決定することの一例である。また、Ｓ４３、Ｓ４４の処理において、LIST Aを納入日の古い順にソートする代わりに、障害発生予測日の早い順にソートすることは、障害の発生が予測された時期に応じて優先度を決定することの一例である。Ｓ４２の処理は、予測された障害の種類が初期故障である場合には障害の発生が予測された部品が搭載された対象製品の稼働期間が短いほど対象製品の優先度を高くすることの一例である。Ｓ４３，Ｓ４４の処理は、予測された障害の種類が初期故障でない場合には障害の発生が予測された部品が搭載された対象製品の稼働期間が長いほど対象製品の優先度を高くすることの一例である。

次に、ＥＣ支援システム５０は、LIST Bを納入時期の同月内に複数の顧客が含まれる場合、同月内で納入数量が多い順にソートしLIST Cを作成する（Ｓ４６）。Ｓ４０からＳ４６の処理は、障害の発生が予測された部品に対して発生が予測された障害に応じてメンテナンス作業の優先度を決定することの一例である。

次に、ＥＣ支援システム５０は、LIST CにＥＣ対応可能日のフィールドとＥＣ作業日（確定）にフィールドを付与し、LIST Dを作成する（Ｓ４７）。次に、ＥＣ支援システム５０は、保守部品在庫管理システム２０から保守部品在庫数(L)、追加製作数(m)、追加製作分納期(n)を収集し、Data Table 3に保存する（Ｓ４８）。Ｓ４８の処理は、対象製品の
納入先ごとに対象製品が有する障害の発生が予測された部品の対象製品に搭載された数量と入手可能時期を基に、障害の発生が予測された部品を交換するための交換部品が充足される時期を特定することの一例である。追加製作分納期は、入手可能時期の一例である。ただし、現時点で在庫がある場合には、現時点に部品の配送期間を加えた時期が入手可能時期の一例となる。

そして、ＥＣ支援システム５０は、ＥＣ未発行の製品の中で納品日が最も早い追加部品数をLIST Dの優先度の高い順に割り当てＥＣ対応可能日のフィールドに納期日を代入する（Ｓ４９）。そして、ＥＣ支援システム５０は、ＥＣ対応可能日順にLIST Dをソートする。

そして、ＥＣ支援システム５０は、ＥＣ未発行の製品について、最も早いＥＣ対応可能日の在庫数は揃ったか否かを判定する（Ｓ５０）。Ｓ５０の判定で在庫が揃っていない場合、Ｓ４６の処理に戻り、保守部品在庫管理システム２０において在庫量が更新されるのを待つ。一方、Ｓ５０の判定で在庫が揃っている場合、ＥＣ支援システム５０は、LIST D
の最も早いＥＣ対応可能日の顧客のみのＥＣレポートをＣＥ部門に発行する。このとき
、ＥＣ支援システム５０は、ＥＣ発行日には現在の日付を代入する（Ｓ５１）。Ｓ４８〜Ｓ５１の処理は、障害の発生が予測された部品の入手可能時期と優先度とに応じて、対象製品のメンテナンス作業のスケジュールを調整することの一例である。Ｓ５０，Ｓ５１の処理は、障害の種類ごとに、当該種類に分類された障害に対応するためのすべての交換部品の在庫が充足される時期以降に対象製品のメンテナンス作業のスケジュールを設定することの一例である。

ＣＥ部門は、ＥＣレポートの発行を受けると、Ｂ３以降の処理、すなわち、図２０のＳ６０からＳ６５の処理を実行する。ここで、Ｓ６０からＳ６３の処理は、比較例の図４のＳ３１からＣ３４の処理と同様であるので、その説明を省略する。ＣＥ部門は、顧客との間で、ＥＣ作業日を確定し、顧客先でＥＣ作業すなわちメンテナンスを実施し（Ｓ６４）、保守情報システム８０は、ＥＣ作業情報を更新する（Ｓ６５）。

一方、ＥＣ支援システム５０は、ＥＣ発行がすべて完了したか否かを判定する（図１９のＳ５２）。LIST Dに記載された製品のうち、ＥＣ発行が未完の製品が残っている場合、ＥＣ支援システム５０は、処理をＳ４６に戻す。LIST Dに記載された製品に対するＥＣ発行がすべて完了した場合、ＥＣ支援システム５０は、Ｂ４の処理、すなわち、図２０のＳ６６に進む。そして、ＥＣ支援システム５０は、保守情報システム８０からＥＣ作業調整結果として、ＥＣ作業の確定日を受信する（Ｓ６６）。そして、ＥＣ支援システム５０は、LIST EのＥＣ作業確定日の更新が必要か否かを判定する（Ｓ６７）。LIST Eは、図１６で説明した通り、ＥＣ作業確定日が設定されたリストである。図２０では、省略されているが、ここでは、一旦、顧客との間でＥＣ作業予定日が設定され、LIST Eが作成されていることを前提としている。

LIST EのＥＣ作業確定日の更新が必要な場合とは、顧客との調整の結果、ＥＣ対応可能日以降で、顧客の都合のよい日が再度決定された場合である。LIST EのＥＣ作業確定日の更新が必要な場合、ＥＣ支援システム５０は、LIST EのＥＣ作業確定日を更新する（Ｓ６８）。そして、ＥＣ支援システム５０は、保守情報システム８０からＥＣ作業情報を収集する（Ｓ６９）。そして、ＥＣ支援システム５０は、保守情報システム８０においてＥＣ作業はすべて完了したか否かを判定する（Ｓ７０）。保守情報システム８０においてＥＣ作業が未完の場合、ＥＣ支援システム５０は、Ｓ６６の処理に戻る。一方、保守情報システム８０ＥＣ作業がすべて完了した場合、ＥＣ支援システム５０も処理を終了する（Ｓ７１）。
＜実施形態の効果＞

以上述べたように、本実施形態では、本情報システムの障害発生予測システム４０は、１つの製品全体での障害発生予測値がＡＦＲの管理値を越えているか否かにより、メンテナンス対象の製品を抽出する。そして、障害発生予測システム４０は、抽出したメンテナンス対象の製品をＥＣ支援システム５０に通知する。ＥＣ支援システム５０は、抽出されたメンテナンス対象の製品に搭載される部品のリストである構成情報を取得し、それぞれの部品の今後の障害発生予測値（ＡＦＲ予測値）がＡＦＲ管理値を越えるか否かを判定し、異常の発生する可能性のある部品を特定する。そして、ＥＣ支援システム５０は、発生が予測される障害のタイプ、部品を搭載した製品の稼働期間（または部品交換からの期間）、顧客への納入数等から、メンテナンス対象の製品の優先度を決定する。そして、優先
度とメンテナンス作業において交換される部品の納期（部品倉庫からの払出し可能日）とによって、当該製品のＥＣ対応可能日を決定する。したがって、本実施形態では、ＥＣ支援システム５０は、障害の発生が予測された部品の入手可能時期とメンテナンス作業の優先度とに応じて、適切にメンテナンスのスケジュールを設定できる。さらに、上記比較例のように、すべての製品に対するメンテナンスのための部品の在庫が揃うまで待つことなく、優先的にメンテナンスすることが望ましい製品別に、メンテナンスのための部品が充足された時点以降を当該製品のＥＣ対応可能日とすることができる。すなわち、複数の顧客先の複数製品については保守部品の在庫が不足している状態でも、優先度の高い製品について保守部品が揃っている場合には早期にメンテナンスを実施できる。その結果、顧客先で稼働中の製品について、優先度の高いメンテナンス作業を優先的に実施し、サービス品質、製品の稼働率を向上できる。

また、本実施形態では、ＥＣ支援システム５０は、発生が予測される障害を初期故障、摩耗故障、およびそれ以外のように種類を分類し、障害の発生が予測される製品のメンテナンスの優先度を決定する。したがって、障害の種類に応じた適切な優先度の設定が可能となる。

また、本実施形態では、ＥＣ支援システム５０は、初期故障については、製品の納入日の新しいものを優先し、初期故障以外の摩耗故障およびその他の故障については、製品の納入日の古いものを優先する。したがって、対象製品の稼働期間に応じた適切な優先度の設定が可能となる。また、初期故障では、納入日の新しいものを優先することで、効果的に初期故障を抑制できる。また、初期故障以外の摩耗故障等では、納入日の古いものを優先することで、効果的に摩耗故障および初期故障の時期を経過した段階での故障を抑制できる。

また、本実施形態では、ＥＣ支援システム５０は、前記障害の発生が予測された時期に応じて前記優先度を決定することもできるので、障害発生前にメンテナンス作業が実施され、障害の発生が抑制される可能性を高めることができる。
《コンピュータが読み取り可能な記録媒体》

コンピュータその他の機械、装置（以下、コンピュータ等）に上記いずれかの機能を実現させるプログラムをコンピュータ等が読み取り可能な記録媒体に記録することができる。そして、コンピュータ等に、この記録媒体のプログラムを読み込ませて実行させることにより、その機能を提供させることができる。

ここで、コンピュータ等が読み取り可能な記録媒体とは、データやプログラム等の情報を電気的、磁気的、光学的、機械的、または化学的作用によって蓄積し、コンピュータ等から読み取ることができる記録媒体をいう。このような記録媒体のうちコンピュータ等から取り外し可能なものとしては、例えばフレキシブルディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ／Ｗ、ＤＶＤ、ブルーレイディスク、ＤＡＴ、８ｍｍテープ、フラッシュメモリなどのメモリカード等がある。また、コンピュータ等に固定された記録媒体としてハードディスク、ＲＯＭ（リードオンリーメモリ）等がある。さらに、ＳＳＤ（Solid State Drive）は、コンピュータ等から取り外し可能な記録媒体としても、コンピュータ
等に固定された記録媒体としても利用可能である。

１１ ＣＰＵ
１２ 主記憶部
１３ 外部記憶部
１４ 表示部
１５ 操作部
１６ 通信部
２０ 保守部品在庫管理システム
３０ 顧客納入情報管理システム
４０ 障害発生予測システム
５０ ＥＣ支援システム
６０ 出荷情報システム
７０ 修理情報システム
８０ 保守情報システム
９０ 障害情報システム
Ａ 出荷情報テーブル
Ｂ 障害情報テーブル
Ｃ 保守部品在庫管理テーブル
Ｄ 障害発生予測テーブル
Ｅ 顧客納入情報管理テーブル

Claims (8)

1. 製品の障害情報を基にメンテナンス作業の対象製品を特定し、前記メンテナンス作業の対象製品が有する部品の障害の発生を予測し、前記障害の発生が予測された部品に対して前記発生が予測された障害に応じてメンテナンス作業の優先度を決定し、前記障害の発生が予測された部品の入手可能時期と前記優先度とに応じて前記特定された対象製品のメンテナンス作業のスケジュールを調整する処理部を備える情報処理装置。
2. 前記処理部は、前記発生が予測された障害の種類に応じて前記障害の発生が予測された部品の分類を実施し、前記分類別に前記優先度を決定する請求項１に記載の情報処理装置。
3. 前記処理部は、前記障害の発生が予測された部品が搭載された対象製品の稼働期間に応じて前記優先度を決定する請求項１に記載の情報処理装置。
4. 前記処理部は、前記障害の発生が予測された時期に応じて前記優先度を決定する請求項１に記載の情報処理装置。
5. 前記処理部は、前記予測された障害の種類が初期故障である場合には前記障害の発生が予測された部品が搭載された対象製品の稼働期間が短いほど前記対象製品の優先度を高くし、前記予測された障害の種類が初期故障でない場合には前記障害の発生が予測された部品が搭載された対象製品の稼働期間が長いほど前記対象製品の優先度を高くする請求項２から４のいずれか１項に記載の情報処理装置。
6. 前記処理部は、対象製品の納入先ごとに前記対象製品が有する前記障害の発生が予測された部品の前記対象製品に搭載された数量と前記入手可能時期を基に、前記障害の発生が予測された部品を交換するための交換部品が充足される時期を特定し、一の納入先に納入されている前記対象製品が有する前記障害の発生が予測された部品のうち、前記障害の種類ごとに、当該種類に分類された障害に対応するためのすべての交換部品の在庫が充足される時期以降に対象製品のメンテナンス作業のスケジュールを設定する請求項２から５のいずれか１項に記載の情報処理装置。
7. コンピュータが製品の障害情報を基にメンテナンス作業の対象製品を特定し、前記メンテナンス作業の対象製品が有する部品の障害の発生を予測し、前記障害の発生が予測された部品に対して前記発生が予測された障害に応じてメンテナンス作業の優先度を決定し、前記障害の発生が予測された部品の入手可能時期と前記優先度とに応じて前記特定された対象製品のメンテナンス作業のスケジュールを調整する情報処理方法。
8. コンピュータに、メンテナンス作業の対象製品の指定を受け付け、
   前記メンテナンス作業の対象製品が有する部品の障害の発生を予測し、前記障害の発生が予測された部品に対して前記発生が予測された障害に応じてメンテナンス作業の優先度を決定し、前記障害の発生が予測された部品の入手可能時期と前記優先度とに応じて前記特定された対象製品のメンテナンス作業のスケジュールを調整することを実行させるためのプログラム。

Images