JP7040270B2 - 在庫管理装置、在庫管理方法、およびプログラム - Google Patents

Description

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

情報処理装置、情報システム等（以下、装置あるいは製品ともいう）のハードウェアの保守では部品の交換が行われることがある。以下、情報システムのハードウェアの保守で用いられる部品を保守部品と呼ぶことにする。保守部品は、ハードウェアの保守終息迄の期間（例えば、５から７年等の間）安定して供給されることが望ましい。

従来、保守部品は、製品の出荷前に全国の保守部品倉庫に配備され、製品出荷後は保守部品在庫状況が定期的に監視される。保守部品の管理者を支援する在庫管理システムは、保守部品の配備数を記録し、配備数の見直しを行い、必要数量を充足するための不足分の算出等を実施していた。すなわち、保守部品の在庫管理では、在庫管理システムは、保守部品保有数に関係する項目（部品の払出し数、在庫数等）およびフィールドでの保守部品の稼働数の実績値などの情報を収集し、各項目の数量を基に保守部品毎に追加手配をするか否かの判断を支援していた。

例えば、在庫管理システムは、保守サービス中の製品を対象に、部品毎に保守部品保有数等の監視項目を確認し、確認結果に応じて保守部品を追加手配するための情報を管理者に提供していた。一方で、在庫管理システムは、保守部品のフィールドでの稼働状況と、保守作業で交換された故障部品の数から、各部品の障害発生率を算出し、管理者の追加手配を支援していた。

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

ところで、従来の保守部品の在庫管理システムでは、保守部品保有数に関係する項目やフィールドの稼働数など、旧モデルでの実績値を基に保守部品の追加手配数を決定していたため、障害発生の状況、原因、発生率の時系列特性等によっては、異常の検出迄に時間を要する場合が有り、その間の急な保守部品の払出し増加に対応出来ず保守部品が枯渇するおそれがあった。

例えば、フィールドでロット障害が発生した保守部品については、枯渇するおそれがあった。ここで、ロット障害は、それぞれの部品において、ロットと呼ばれる１まとまりの製造単位量で製造された製造物間で共通の要因で発生する障害をいう。また、ロット障害以外の問題としては、例えば、稼働期間が影響する偶発故障期間における障害について障害原因が判明すると、稼働期間等の情報を基に障害の発生予測が実施され、保守部品の追加手配数が決定されていた。しかし、障害原因が判明する迄の時間が長期化すると、保守部品の枯渇に至るおそれが生じていた。

本発明の一側面は、上記のような問題を改善し、保守部品の在庫数を可能な限り常時適正値に調整できるようにする。

開示の技術の一側面は、以下の処理を実行する処理部を含む在庫管理装置によって例示される。本処理部は、情報システムを構成する保守対象製品に搭載されたそれぞれの部品が１まとまりの製造単位数量で製造されたことを含む製造情報別に集計された前記部品の障害についての第１の障害発生率と、前記保守対象製品または前記保守対象製品に搭載された部品の稼働期間別に集計された前記部品の障害についての第２の障害発生率との少なくとも一方の障害発生率を算出し、前記算出された障害発生率が所定条件を充足したときに前記部品の必要数量を予測し、前記必要数量を充足するように前記部品の在庫数量の調整を指示し、前記部品の障害情報を取得し、前記情報システムのファームウェアの更新に関連する情報が前記障害情報に含まれている場合に、前記ファームウェアを更新した情報システムが稼働する地域を特定し、前記特定された地域に供給される在庫数量の調整を指示する。

本在庫管理装置によれば、保守部品の在庫数を適正値に調整することができる。

比較例に係る情報システムを例示する図である。 実施形態の情報システムの構成図である。 コンピュータの構成を例示する図である。 保守部品管理情報テーブルのデータ例である。 納入情報テーブルのデータ例である。 障害発生テーブルのデータ例である。 障害対応情報テーブルのデータ例である。 機歴情報テーブルと障害品情報テーブルのデータ例である。 ファームダウンロード情報テーブルのデータ例である。 部品出荷日情報の集計表を例示する図である。 障害発生日情報を例示する図である。 ワイブル解析を用いたある部品の残存数と、障害発生数の予測値である。 累積ハザードをグラフで例示したものである。 残存数および障害発生数（予測値）をグラフで例示したものである。 一実施形態の情報システムによる在庫調整処理を例示するフローチャートである。 稼働期間要因検出部の処理を例示するフローチャートである。 ファーム障害確認処理を例示するフローチャートである。 部品追加処理を例示するフローチャートである。 他の実施形態の情報システムの構成図である。 障害対応情報テーブルのデータ例である。 他の実施形態の情報システムによる在庫調整処理を例示するフローチャートである。 他の実施形態の稼働期間要因検出部の処理を例示するフローチャートである。 他の実施形態の部品追加処理を例示するフローチャートである。 他の実施形態の予防交換部品の追加判断処理を例示するフローチャートである。

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

＜比較例＞
図１に、比較例に係る情報システムを例示する。比較例の情報システムは、製品の納入先に納入された製品保守のための保守部品の在庫管理を支援する。この情報システムは、製造業者の複数部門に設けられたシステムと、各地の部品倉庫の情報処理装置（省略）と、顧客あるいはＳｙｓｔｅｍ Ｅｎｇｉｎｅｅｒ（ＳＥ）の情報処理装置とをネットワークで接続したものである。

工務部門には、保守部品管理システム５２０および受注管理システム５３０が設けられる。開発部門あるいは品質保証部門には、Ｗｅｂシステム５４０が設けられる。工場には、出荷情報システム５６０および修理情報システム５７０が設けられる。Ｃuｓｔｏｍｅｒ Ｅｎｇｉｎｅｅｒ（ＣＥ）部門には障害対応管理システム５８０が設けられる。サポート部門には障害発生管理システム５９０が設けられる。

工務部門に設けられる保守部品管理システム５２０は、保守部品の在庫数量を監視し、在庫数量が規定の条件を充足するように、在庫数量を調整する指示を発する。保守部品管理システム５２０は、部品追加判断部５２１と保守部品管理情報テーブル５２２を有している。保守部品管理情報テーブル５２２は、保守部品払出し情報、在庫情報、および保守部品管理基準を含む。保守部品管理システム５２０は、ＣＥ部門から保守部品の発注を受けると、保守部品管理情報テーブル５２２を更新するとともに、発注された部品のＣＥ部門への発送（払い出しともいう）を指示する。

部品追加判断部５２１は、定期的または所定のイベント、例えば、部品の払出し等をトリガにして、在庫調整処理を実行する。在庫調整処理では、部品追加判断部５２１は、部品ごとの在庫の必要数量を判定し、不足する部品について、必要数量の部品が充足するため追加手配するように工務部門のスタッフに指示を発する。指示はスタッフの端末等の情報処理装置に表示される。

工務部門に設けられる受注管理システム５３０は、サーバ、コンピュータ、その他の製品、およびこれら製品に使用される部品の受注と納入を管理する。受注管理システム５３０は、受付処理部５３１と、納入情報テーブル５３２を有している。受付処理部５３１は、製品あるいは製品に搭載される部品の発注情報を顧客あるいはＳＥの情報処理装置から受け付ける。受付処理部５３１は、受け付けた発注情報を基に、納入情報テーブル５３２のレコードを作成し、製品あるいは部品の納入先、製品（装置）あるいは部品の名称等を記録する。また、製品（装置）あるいは部品の納入後、納入日、納入台数等を納入情報テーブル５３２の該当するレコードに記録する。

開発部門または品質保証部門に設けられるＷｅｂシステム５４０は、顧客あるいはＳＥに対して、製品あるいは部品のファームウェアをダウンロードするサービスを提供する。また、Ｗｅｂシステム５４０は、ファームダウンロード情報５４１を有している。Ｗｅｂシステム５４０は、ファームダウンロード情報５４１に、ダウンロードされたファームウェアの履歴等、ダウンロード先等、ファームウェアに関連する情報を記録する。

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

工場に設けられる修理情報システム５７０は、修理のために工場に返却された保守部品（ユニット）の故障の有無の判定結果、および故障の内容等を管理する。修理情報システム５７０は、障害品情報テーブル５７１を記憶手段に有している。障害品情報テーブル５７１は、故障部品情報、回収品ロット情報、診断・修理結果情報等を含む。

サポート部門に設けられる障害発生管理システム５９０は、障害発生情報テーブル５９１を記憶手段に有している。障害発生情報テーブル５９１は、顧客情報、障害発生日情報、および障害内容を含む。また、障害発生管理システム５９０は、フィールドでのＣＥ作業に基づく障害対応情報テーブル５８１および、工場作業に基づく障害品情報テーブル５７１から、下記障害発生率を算出するための式の分子を抽出する。そして、障害発生管理システム５９０は、納入情報テーブル５３２から得られる納入数を分母として部品の障害発生率を算出する。障害発生率は、
障害発生率＝（単位期間内の部品の障害件数／保守対象製品の単位期間内の延べ稼働台数）＊（１２／単位期間）×１００（件／（百台・年））；
で計算される。障害発生情報テーブル５９１は、障害事例（インシデントともいう）別に、障害の内容を記録する。

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

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

ＣＥ部門に設けられる障害対応管理システム５８０は、障害対応に伴う障害発生日、顧客情報、装置番号、交換ユニット（交換部品）等を管理する。障害対応管理システム５８０が障害対応情報テーブル５８１を記憶手段に有している。したがって、上記工場での調査あるいは修理の結果に基づく、顧客先でのＣＥ作業が実施され、ＣＥ作業完了後、障害対応情報テーブル５８１にＣＥ作業の結果が保存される。

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

比較例の情報システムでは、所定の時期または所定のトリガ、例えば、営業部門またはＣＥ部門のスタッフの端末からの手配をトリガに、保守部品管理システム５２０が在庫調整処理を実行する。在庫調整処理では、部品追加判断部５２１は、部品ごとの在庫の必要数量を判定し、不足する部品について、必要数量の部品を充足するために追加手配する指示を発する。部品追加判断部５２１は、例えば、在庫数量が１回の手配での平均払出し数を上回るように追加手配数を決定する。また、部品追加判断部５２１は、在庫数量が事前に規定されている基準数量を上回るように追加手配数を決定する。さらに、部品追加判断部５２１は、在庫の変動量が顧客との保守契約で決定された基準値を上回る場合には、契約で規定された増加数量を基に追加手配数を決定する。そして、部品追加判断部５２１は、決定した追加数量を工場、ベンダ等に発注する指示を発行する。

比較例の保守部品在庫の管理方法では、保守部品管理システム５２０は、保守部品保有数に関係する項目やフィールドの稼働数など、実績値を元に保守部品の追加手配数を決定する。しかし、例えば、フィールドで保守部品のロット障害が発生すると、異常の検出迄の間に、障害が多発して保守部品が枯渇するおそれがある。また、保守部品管理システム５２０は、稼働期間が影響した偶発故障期間における多発障害についても、個別に稼働期間等の情報を集計しワイブル解析等による発生予測を実施する。しかし、多発障害の検出迄に時間を要した場合には、保守部品の枯渇に至るおそれもある。

そこで、以下の実施形態では、保守部品の枯渇の可能性を低減する保守部品の管理支援を実行する情報システムが説明される。

＜実施形態＞
本実施形態の情報システムは、ロットと呼ばれる部品の製造情報（サプライヤ、サプライヤ製造ロット、部品版数を含む）を利用し、ロットごとに障害発生率を監視し多発障害を検出する事で、ロット障害の発生を検知する。本情報システムは、ロット障害の発生を検知すると、保守部品が枯渇しない様、ロット障害に対応するための部品数を算出し、事前に追加手配するための指示をスタッフに発する。

また、本実施形態の情報システムは、製品毎の稼働期間情報（顧客納入日～障害発生日迄）を使い、障害発生率を監視し、バスタブ曲線（故障率曲線）で偶発故障期間における多発障害を検出する。ここで、偶発故障期間とは、初期故障の段階以降で、かつ、摩耗故障の段階に至らない時期をいう。本実施形態の情報システムは、偶発故障期間における多発障害を検出すると、保守部品が枯渇しない様、障害に対応するための部品数を算出し、事前に追加手配するための指示をスタッフに発する。より具体的には、本情報システムは、製品（あるいは部品）の顧客への「納入日」と「障害発生日」から稼働期間を算出し、期間毎の障害発生率をリアルタイムで監視することにより偶発故障期間内の稼働期間要因での障害を検出する。そして、本情報システムは、ワイブル解析における障害発生予測を実施することにより、保守終息期間内の市場での残存数から必要な保守部品数量を割り出し、保守部品の補充をスタッフに指示する。これらの指示は、例えば、情報システムに接続されたスタッフの端末に発せられる。

また、本実施形態の情報システムは、上記追加手配が必要となった場合において、ダウンロード情報を監視する事により「ファームアップ」による障害要因を検出可能とする。本実施形態の情報システムは、「ファームアップ」による障害要因を検出する事で、実際にダウンロードされた「顧客の数」と顧客の所在する「地域」から障害に対応するための部品数の手配の指示を発する。このような処理によって、本情報システムは、製造業者における適正数量の保守部品の配備を可能とし、本来不要な手配が回避出来る。

本情報システムは比較例の情報システムに加えて、『ロット情報』と『稼働期間』のデータを取り入れ、保守部品の数量を監視することにより、ロット障害や稼働期間要因による障害発生の早期検出を行う。その結果、本情報システムは、ワイブル解析等による既存の残存数算出から枯渇前に必要な数量の保守部品を精度よく補給することを可能とする。なお、納入日としては、製品に搭載された各部品の納入日からの期間で障害発生率を算出する正確な経過期間要因の障害発生率が取得できる。ただし、保守期間が所定限度、例えば、数年間の場合には、製品全体の部品のうち、部品交換が実施される割合が低いことが想定される。そのような場合には、納入日として、製品の納入日を用いたとしても、ある程度の精度で、概算の障害発生率が部品ごとに把握される。この場合に、交換された部品ついては、障害発生率の精度は低下するが、ある程度の割合（あるいは大半）の部品については精度よく保守部品の必要数量が計算される。

図２は、本実施形態の情報システムの構成図である。本情報システムは、製品の納入先に納入された製品保守のための保守部品の在庫管理を支援する。本情報システムも、比較例と同様、製造業者の複数部門に設けられたシステムと、各地の部品倉庫の情報処理装置（省略）と、顧客あるいはＳＥの情報処理装置とをネットワークで接続したものである。

工務部門には、保守部品管理システム２０および受注管理システム３０が設けられる。保守部品管理システム２０および受注管理システム３０の構成および作用は、比較例の保守部品管理システム５２０および受注管理システム５３０の構成および作用と同様である。保守部品管理システム２０は、部品追加判断部２１と保守部品管理情報テーブル２２を有する。受注管理システム３０は、受付処理部３１および納入情報テーブル３２を有する。

工場には、出荷情報システム６０および修理情報システム７０が設けられる。出荷情報システム６０および修理情報システム７０の構成および作用は比較例の出荷情報システム５６０および修理情報システム５７０の構成および作用と同様である。出荷情報システム６０は、機歴情報テーブル６１を記憶手段に有する。修理情報システム７０は、障害品情報テーブル７１を記憶手段に有する。

ＣＥ部門には障害対応管理システム８０が設けられる。障害対応管理システム８０の構成および作用は、比較例の障害対応管理システム５８０の構成および作用と同様である。障害対応管理システム８０は、障害対応情報テーブル８１を記憶手段に有する。

サポート部門には障害発生管理システム９０が設けられる。障害発生管理システム９０の構成および作用は、比較例の障害発生管理システム５９０の構成および作用と同様である。障害発生管理システム９０は、障害発生情報テーブル９１を記憶手段に有する。

開発部門あるいは品質保証部門には、Ｗｅｂシステム４０、ロット障害検出部５１および稼働期間要因検出部５２が設けられる。Ｗｅｂシステム４０の構成および作用は、比較例のＷｅｂシステム５４０の構成および作用と同様である。Ｗｅｂシステム４０はファームダウンロード情報テーブル４１を有する。

本実施形態の情報システムでは、比較例での保守部品の在庫を監視する処理に加えて、ロット障害検出部５１および稼働期間要因検出部５２による処理が追加される。すなわち、本実施形態の情報システムは、（Ａ）製造ロット別障害発生率及び（Ｂ）装置毎（または部品ごと）の稼働期間別障害発生率を計算する。計算は、例えば、１月で例示される単位期間ごとに実施される。ただし、障害発生率を計算する単位期間は１月に限定される訳ではない。そして、本実施形態の情報システムは、上記いずれかの障害発生率が基準値を超えた場合は、速やかにワイブル解析による障害発生予測を実施して、急な保守部品払出しの増加に備える。

＜＜ロット障害検出部５１の処理＞＞
（１）各部品には製造時期、ロット番号等が表示され、画像読取り装置で読取り可能とするか、または、製造時期（例えば、製造年月日）、シリアル番号等が電気的に読み取り可能に付与される。電気的に読み取り可能とするために、各部品にＩＣタグが付されてもよい。本情報システムは、スタッフの操作にしたがって、例えば、回収された障害部品から部品の製造時期、シリアル番号等を画像センサによる読取り手段または電気的読取り手段により読み取る。そして、本情報システムは、製造時期、ロット番号、またはシリアル番号等から各部品の製造ロットを特定する。

ここで、製造ロットとは、それぞれの部品が複数個の１まとまりを製造単位量として製造されたときの当該製造された複数個の部品を特定する情報ということができる。すでに述べたように製造ロットによって特定される情報には、サプライヤ、サプライヤの製造ロット、部品の版数等の情報も含まれる。つまり、製造ロットが特定されると、サプライヤ、サプライヤの製造ロット、部品の版数等も特定される。製造ロットが同一の複数の部品は、部品版数が同一であり、製造条件、製造時の環境等が同一である可能性が高い。したがって、部品の版数、製造条件、製造時の環境等に起因する障害は、製造ロットが同一の複数の部品に共通して発生する可能性がある。製造ロット、あるいは製造ロットを表す情報は、製造情報の一例である。

（２）本情報システムは、部品の製造時に、ロット毎に製造数を管理する。また、本情報システムは、部品の出荷数を製品に組み込まれてフィールドで稼働する部品数と、保守部品向けに出荷される部品数とに分けて管理する。

（３）本情報システムでは、各部品には、対象部品の故障率や過去の類似製品の実績値などから障害発生率の基準値が設定される。尚、基準値については定期的な見直し補正による再設定が実施される。

（４）フィールドで障害が発生し、保守作業で交換された部品（被疑故障部品）は工場に回収され、診断処理が実施され、故障が確認される。本情報システムは、故障の確認結果の入力を受け付け、製造ロット別に故障数を管理する。なお、診断処理で合格した部品は故障部品数から除外される。すなわち、本情報システムは、保守部品在庫数の定期的な監視とともに、各部品の製造ロット別障害発生率を以下の式で算出し、基準値と比較する。

ロット別障害発生率＝（単位期間内の部品のロット別の障害件数／保守対象製品の期間内の延べ稼働台数）×（１２／単位期間）×１００（件／（百台・年））；ただし、単位期間を当該部品の全稼働期間とすることで、全期間に渡るロット別障害発生率を集計してもよい。

なお、対象製品（または部品）が納入（または部位品交換）から間も無い場合は、初期出荷期間として状況監視とし、直ちに、保守部品の追加手配はされない。このため、本情報システムは、製品出荷後所定期間経過まで、あるいは、部品交換後所定期間経過まで、部品の障害が入力されても、部品の障害を上記ロット別障害発生率の算出対象から除外する。

本情報システムは、ロット別障害発生率が設定した基準値を超えたロットについては、本情報システムが監視期間を１月として障害発生率を計算している場合には、監視強化のため、半月,週や日単位での監視期間での計算に切換える。そして、基準値超えが所定期
間継続した場合に、ロット障害と判断し、通常のワイブル解析による残存数の算出に基づく保守部品に加えて、処理割合の保守部品を追加手配の指示、つまり、早期に保守部品を補充するための指示を発する。ここで、所定期間の継続は、例えば、２ヶ月以上継続したか否か等で判断される。ただし、所定期間継続したか否かを判断する所定期間の長さは、変更して設定することが可能である。

＜＜稼働期間要因検出部５２の処理＞＞
稼働期間要因検出部５２は、稼働期間の経過に対して障害発生率が急激に増加する障害発生率の立ち上がり時点を早期に検出できるようにする。このため、稼働期間要因検出部５２は、発生した障害を障害が発生した製品（または部品）の稼働期間別に集計し、障害発生率を求める。一方、稼働期間要因検出部５２は、稼働期間に対して障害発生率の適否を判定するための基準値を有している。そして、稼働期間要因検出部５２は、それぞれの稼働期間における障害発生率がそれぞれの稼働期間における基準値を超える場合に、ワイブル解析等により残存数を算出し、必要な保守部品を早期に手配可能とする。

（１）稼働期間は、製品または部品の顧客納入日から障害発生日迄の期間とし、「日/週/半期/年」等の単位期間での集計分析を可能とする。集計分析する期間の単位等の条件は、スタッフの入力により自在に設定可能とする。ここで、顧客納入日は、部品が搭載された製品の納入日、または、部品交換の日である。製品の納入日を用いるか、部品交換日を用いるかは、情報システムに要求される障害発生率あるいは必要部品数量の精度、製品の保守期間、稼働期間情報収集のための手間等を考慮して選択される。

（２）稼働期間要因検出部５２による監視処理の対象部品（以下、監視部品）には、監視部品の障害発生率や過去の類似製品の実績値などから障害発生率の基準値が設定される。尚、基準値については定期的な見直し補正により再設定が実施される。

（３）保守作業で交換された監視部品（被疑故障部品ともいう）は工場に回収され、診断処理が実施され、故障が確認される。本情報システムは、故障の確認結果の入力を受け付け、故障数を管理する。なお、診断処理で合格した部品は故障部品数から除外される。

（４）本情報システムは、各部品の障害を稼働期間別に集計し、稼働期間別に障害発生率（以下、稼働期間別障害発生率）を算出し、基準値と比較する。ただし、稼働期間別障害発生率を基準値と比較する代わりに、稼働期間別障害発生率の単位期間に対する増分値が基準増分値を超えるか否かで、稼働期間要因による障害を検出するようにしてもよい。例えば、情報システムは、Ｍヶ月の稼働期間における稼働期間別障害発生率からＭ＋１月の稼働期間における稼働期間別障害発生率の増分値が基準増分値を超えるか否かを判定すればよい。
稼働期間別障害発生率＝（単位期間内の部品の稼働期間別の障害件数／保守対象製品の単位期間内の延べ稼働台数）×（１２／単位期間）×１００（件／（百台・年））；ここで、単位期間は例えば、１ヶ月である。

例えば、単位期間を１ヶ月とすると、ある部品に発生した障害は、１ヶ月ごとに区切られた稼働期間（１月、２月、・・・、Ｎ月）ごとに集計される。そして、各稼働期間（１月、２月、・・・、Ｎ月）において上記稼働期間別障害発生率が算出され、基準値と比較される。また、稼働期間別障害発生率の増分値が基準増分値と比較される。なお、対象製品（または部品）が納入（または部位品交換）から間も無い場合は、初期故障期間として状況監視とする。このため、本情報システムは、製品出荷後所定期間経過まで、あるいは、部品交換後所定期間経過まで、部品の障害が入力されても、上記稼働期間別障害発生率の算出対象から除外する。より具体的には、本情報システムは、部品の障害が入力されると出荷開始から上記稼働期間別障害発生率を算出するので、製品出荷後所定期間経過まで（例えば１ヶ月）、算出された稼働期間別障害発生率を判定から除外する。

図３に、保守部品管理システム２０、受注管理システム３０、Ｗｅｂシステム４０、品質監視システム５０、出荷情報システム６０、修理情報システム７０、障害対応管理システム８０、障害発生管理システム９０として使用可能なコンピュータ１の構成を例示する。コンピュータ１はＣＰＵ１１と、主記憶部１２と、インターフェース（Ｉ／Ｆ）を通じて接続される外部機器を有し、プログラムにより情報処理を実行する。コンピュータ１は管理装置の一例である。外部機器としては、外部記憶部１３、表示部１４、操作部１５、および通信部１６を例示できる。

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

また、コンピュータ１は、表示部１４、操作部１５、通信部１６を有する。表示部１４は、例えば、液晶ディスプレイ、エレクトロルミネッセンスパネル等である。操作部１５は、例えば、キーボード、ポインティングデバイス等である。本実施形態では、ポインティングデバイスとしてマウスが例示される。通信部１６は、ネットワーク上の他のコンピュータ等とデータを授受する。以上の構成により、コンピュータ１のＣＰＵ１１は、主記憶部１２に実行可能に展開されたコンピュータプログラムにより、在庫管理方法を実行し、在庫管理装置として機能する。

＜データ例＞
図４は、工務部門の保守部品管理システム２０が有する保守部品管理情報テーブル２２のデータ例である。保守部品管理情報テーブル２２は、ＣＥが顧客にて修理を行う際に払い出される保守部品在庫数を管理する。保守部品管理情報テーブル２２は、保守部品管理情報（払出し情報）と、保守部品在庫情報（在庫情報）を含む。払出し情報は、（１）処理年月、（２）処理年月時分秒、（３）装置名、（４）仕様、（５）品名、（６）数量、（７）修理指定フラグを含む。このうち、（１）処理年月、（２）処理年月時分秒は、それぞれ払出し時期であり、ＹＹＹＹＭＭ（年月）形式、あるいは、ＹＹＹＹＭＭＤＤＨＨＭＭＳＳ（年月日時分秒）の形式で表される。（３）装置名は、部品が搭載される装置の名称であり、（４）仕様は払出した部品の仕様であり、例えば、部品の図番である。また、（５）品名は仕様に対する部品の品名である。（６）数量は払い出された数量であり、（７）修理指定は、１：修理対象であることの指定、０：消耗品であり、交換部品であることの指定である。保守部品在庫情報は、在庫情報（１）仕様、（２）品名、（３）在庫数を含む。保守部品在庫情報は、仕様と品名で特定される部品の在庫数が記録される。

図５は、工務部門の受注管理システム３０が有する納入情報テーブル３２のデータ例である。納入情報テーブル３２は、顧客に納入された装置を特定する情報（装置名、装置号機、納入日、納入台数）を格納する。納入情報テーブル３２は、納入情報１（納入明細情報）と、納入情報２（納入状況情報）を含む。納入情報１（納入明細情報）は、納入情報（１）ユーザ名、納入日情報（納入年月）、納入情報（２）納入台数を含む。ユーザ名は納入先の顧客名（法人名、団体名、機関名等）である。納入日情報（納入年月）はＹＹＹＹＭＭＤＤ（年月日）で表される。

納入情報２（納入状況情報）は、納入情報（３）装置名、（４）装置号機、および保守契約情報（保守形態）を含む。装置名は、納入した装置の型名であり、装置号機は、号機を示す型名ごとの通し番号であり、保守契約情報（保守形態）は、保守契約の形態を特定するコードである。

図６は、サポート部門の障害発生管理システム９０が有する障害発生情報テーブル９１のデータ例である。障害発生情報テーブル９１は、障害発生日情報（１）発生年月、（２）発生日時、障害内容（現象名）、顧客情報（顧客名）、装置情報（１）装置名、（２）装置号機を有する。障害発生日情報（１）発生年月、（２）発生日時は、それぞれＹＹＹＹＭＭ（年月）、ＤＤＨＨＭＭ（日時分）で表される障害発生の年月日時分情報である。障害内容（現象名）は障害の現象を特定する名称であり障害のコードを説明する用語である。顧客情報（顧客名）は、障害が発生した製品の顧客の名称である。装置名は、障害が
発生した装置の型名である。装置号機は、障害が発生した装置の号機、つまり、装置の型名が付与された装置の通し番号である。

図７は、ＣＥ部門の障害対応管理システム８０が有する障害対応情報テーブル８１のデータ例である。障害対応情報テーブル８１は、装置のメンテナンス作業、障害対策結果を記録するテーブルである。障害対応情報テーブル８１は、現地対応日情報（１）システム現地調査（現調）年月、（２）システム現地調査（現調）日、障害対応情報（１）装置名、（２）装置号機、（３）現象コメント１、（４）原因コメント１、（５）処置コメント１、（６）部品名、（７）保守部品仕様、（８）保守部品数量を含む。すなわち、障害対応情報テーブル８１は、障害が発生した装置を装置名と装置号機で特定可能とする。そして、障害対応情報テーブル８１は、障害が発生した装置について、現地作業の年月日、作業対象の装置名、障害の現象、原因、処置等を保持する。また、障害対応情報テーブル８１は、障害が発生した装置について、処置のときに修理または交換した部品、部品の仕様（例えば図番）、部品の数量を保持する。

図８は、工場の出荷情報システム６０が有する機歴情報テーブル６１、および工場の修理情報システム７０が有する障害品情報テーブル７１のデータ例である。機歴情報テーブル６１は出荷明細情報とも呼ばれ、出荷された装置の機歴（装置名、装置号機、装置構成情報、出荷日、部品名）を記録する。機歴情報テーブル６１は、出荷日情報（出荷日）、装置名、装置号機、装置構成情報（１）ユニット区分、（２）ユニット名称、（３）ユニットシリアル、（４）ユニット号機、（５）ベンダＩＤ、ロット情報（１）サブシステムＩＤ、（２）サブシステムベンダＩＤを含む。出荷日情報（出荷日）は、製品の出荷日である。装置名と装置号機によって、機歴情報で対象とする装置（製品）が特定される。装置構成情報（１）ユニット区分、（２）ユニット名称、（３）ユニットシリアル、（４）ユニット号機（５）ベンダＩＤは、それぞれ製品に搭載された部品を分類した略称、部品名称、部品のシリアル番号、および部品の当該製品における号機を示す通し番号である。図８は、機歴情報テーブル６１の一部品分のレコードを示す。したがって、１つの製品については、図８は、機歴情報テーブル６１のレコードが全部品の分だけ記録される。

障害品情報テーブル７１は、フィールド修理結果情報とも呼ばれ、ＣＥ(Customer Engineer)作業によるフィールド障害情報（障害発生日、顧客名、装置号機、交換ユニット）および、工場作業による交換ユニットの修理情報（故障有無判定、故障内容）が記録される。障害品情報テーブル７１は、故障部品情報（１）装置名、（２）保守部品名、（３）保守部品仕様、保守部品数量、診断・修理結果（１）実診断結果、（２）処理、（３）不良ユニット仕様、回収ロット情報（不良部品ロット番号）、故障部品情報（４）顧客名、（５）装置号機、修理年月日を含む。図８で、障害品情報テーブル７１は１回の修理に対応する１レコード分のデータ例である。

故障部品情報（１）装置名は、故障が発生した部品が搭載されていた装置の型名である。（２）保守部品名、（３）保守部品仕様、保守部品数量は、それぞれ修理された部品（保守部品）の名称、仕様、および、修理された保守部品の数量である。故障部品情報（１）装置名、（２）保守部品名、（３）保守部品仕様、保守部品数量、診断・修理結果（１）実診断結果、（２）処理、（３）不良ユニット仕様、回収品ロット情報（不良部品ロット番号）は、それぞれ、工場での実装診断での診断結果を示すコード、修理に処置を示すコード、障害原因となった不良部品の仕様を特定する情報、および不良部品のロットを特定する番号である。故障部品情報（４）顧客名は、故障が発生した装置の納入先の顧客名であり、（５）装置号機は障害が発生した装置の号機である。修理年月日は、部品が交換された日である。

図９は、ファームダウンロード情報テーブル４１のデータ例である。ファームダウンロード情報テーブル４１は、ファームウェアのダウンロードの記録である。ファームダウンロード情報テーブル４１は、ダウンロード年月、ダウンロード日、装置名称、仕様、ユーザ名、地域、ファーム版数、適用台数、ダウンロード理由を記録する。ダウンロード年月、ダウンロード日は、ファームウェアがダウンロードされた年月と日である。装置名称は、ダウンロードしたファームウェアを適用する装置の型名である。仕様は、ダウンロードしたファームウェアを適用する装置の図番である。ユーザ名は、ファームウェアをダウンロードした顧客名である。地域は、ダウンロードしたファームウェアが適用される装置の納入先の地域であり、例えば、都道府県名である。ファーム版数はファームウェアのバージョン情報である。適用台数は、ダウンロードしたファームウェアを適用する装置の台数である。ダウンロード理由は、障害発生、定期保守等のダウンロードの理由を示す情報である。

図１０は、部品出荷日情報の集計表を例示する。部品出荷日情報の集計表は、機歴情報テーブル６１から各部品の月別出荷情報を集計するための表である。部品出荷日情報の集計表の各行は、それぞれ部品（ユニット）に対応する。部品出荷集計表の各行は、ユニット名称のフィールドと、各出荷月を示すフィールドを有する。したって、部品出荷集計表の各エントリには、各部品の月ごとの出荷数量が記録される。また、総計のフィールドには、各部品の出荷開始から現在までの総計の出荷数量が記録される。

図１１は、障害発生日情報を例示する。障害発生日情報は、出荷された装置のある部品の出荷日と障害発生日との関係を示す。この場合の部品の出荷日は、正確には、部品の納入日または交換日である。しかしながら、部品の交換割合が所定限度以下の低い製品については、製品の出荷日をもって部品の出荷日としてもよい。各行は、１つの障害発生に対応している。各行は、行番号（＃）、出荷日、障害発生日、経過日、経過月を有する。経過日と経過月は、出荷日から障害発生日までの期間を日数と月数で表したものである。

図１２は、ワイブル解析を用いたある部品の残存数と、障害発生数の予測値である。この例では、図１２の各行は、出荷日からの月数を示し、残存数は、各月における稼働数であり、障害発生数（予測値）は、各月における障害発生数数である。障害発生数は、例えば、月数１のとき、残存数２０１６に対して、０．７件であるが、月数６０のとき、残存数１２１６５に対して、６．３件となる。

図１３は、累積ハザードをグラフで例示したものである。累積ハザードは瞬間故障率を表し、グラフで、横軸は時間（稼働期間、例えば、月数）であり、縦軸はハザード値である。グラフ中の各ドットの１つ１つが故障した部品の障害発生状況から求められる瞬間故障率に対応する。また、このハザード値から、部品の残存数が算出される。

図１４は、図１２で例示した残存数および障害発生数（予測値）をグラフで例示したものである。図１４で横軸が時間（月数）であり、縦軸が残存数および障害発生数（予測値）である。また、実線が残存数であり、点線が障害発生予測数である。

ワイブル解析は、障害情報（例えば、部品の故障までの稼働期間）を入力として、障害発生の確率密度分布（ワイブル分布）を求める手段を提供する。ワイブル分布は、正規分布とは異なり、障害発生数（確率密度）が中心（ピーク）に対して非対象な分布を付与できる。したがって、ワイブル分布を用いることで、障害発生率が中心（ピーク）に対して非対称な故障の確率密度を求めることができる。故障確率密度を累積したものが累積ハザードとなる。したがって、障害発生数の累積データを入力することで、故障確率密度であるワイブル分布を近似的に求めるコンピュータプログラムが提供されている。ワイブル分布を求めることで、部品の稼働期間に対する将来の障害発生数（予測値）を求めることができる。ただし、予測は、実際の障害発生数と乖離する場合があるため、本情報システムは時間の経過とともに再計算し、修正する手順をとる。

＜処理フロー＞
図１５は、本実施形態の情報システムによる在庫調整処理を例示するフローチャートである。図１５から図１８の処理は、情報システムが、所定の監視期間ごとに繰り返し実行する。この場合の監視期間に限定はない。例えば、毎日、毎週、毎月、２ヶ月ごと、数ヶ月ごと等の期間で図１５から図１８の処理が実行されればよい。したがって、図１５から図１８の処理は、保守対象製品に搭載された部品のうち、第１の障害発生率および第２の障害発生率の少なくとも一方の障害発生率を所定期間ごとに繰り返し算出することの一例である。この処理では、まず、保守部品管理システム２０が、対象部品は保守サービス中であるか否かを判定する（Ｓ１）。対象部品が保守サービス中でない場合、保守部品管理システム２０は、保守部品廃棄を指示し（Ｓ２）、処理をＳ１に戻し、次の対象部品について処理を実行する。

一方、対象部品が保守サービス中である場合、保守部品管理システム２０は、品質監視システム５０を起動する。すると、品質監視システム５０は、ロット障害検出部５１により、処理部の一例として、Ｓ３以下の処理を実行する。すなわち、品質監視システム５０は、対象部品の機歴情報（出荷日情報、ロット情報等）を工場の出荷情報システム６０に要求する（Ｓ３）。そして、品質監視システム５０は、機歴情報テーブル６１から当該対象部品の機歴情報（出荷日情報、ロット情報等）を取得する。なお、品質監視システム５０は、Ｓ３の処理とともに、修理情報システム７０に障害品情報（部品の修理年月日、部品交換の日）を要求して、取得してもよい。

次に、品質監視システム５０は、障害発生管理システム９０に障害発生情報を要求する（Ｓ４）。そして、品質監視システム５０は、障害発生情報テーブル９１から当該対象部品の障害発生日を取得する。ただし、品質監視システム５０は、障害対応管理システム８０に、障害情報を要求し、障害対応情報テーブル８１から、当該部品の障害を特定する情報（現象、原因、処置）を取得するようにしてもよい。Ｓ４の処理は、部品の障害情報を取得することの一例である。

そして、品質監視システム５０は、機歴情報の出荷日情報、ロット情報、および障害発生日から、ロット障害発生日情報を作成し、保存する（Ｓ５）。ロット障害発生情報は、図１１の障害発生日情報をロット毎に、区分したものであり、各ロットで分類された部品の出荷日、障害発生日、経過日、経過月を収集したものである。

次に、品質監視システム５０は、ロット毎の障害発生率を算出する（Ｓ６）。ロット毎の障害発生率は、上述のように、ロット別障害発生率＝（単位期間内の部品のロット別の障害件数／保守対象製品の期間内の延べ稼働台数）×（１２／単位期間）×１００（件／（百台・年））；で算出される。ここで、単位期間を月とすると、品質監視システム５０は、Ｓ４の処理で今月分の障害発生日を取得し、上記式でロット別障害発生率を算出すればよい。各部品の稼働期間を単位期間で区切る場合には、品質監視システム５０は、それぞれの区切られた単位期間ごとに上記ロット別障害発生率を算出すればよい。ただし、品質監視システム５０は、各部品の稼働期間全期間の障害を集計してロット別障害発生率を算出してもよい。この場合に、単位期間は各部品の稼働期間の全期間となる。ロット別障害発生率は、保守対象製品に搭載されたそれぞれの部品が１まとまりの製造単位数量で製造されたことを含む製造情報別に集計された前記部品の障害についての第１の障害発生率の一例である。Ｓ３－Ｓ６の処理は、第１の障害発生率を算出することの一例である。

そして、品質監視システム５０は、当該対象部品のロット別障害発生率が基準障害発生率を超えるか否かを判定する（Ｓ７）。なお、ロット別障害発生率が稼働期間を単位期間に区切って算出されている場合には、品質監視システム５０は各単位期間についてＳ７の判定を行えばよい。また、ロット別障害発生率が部品の稼働期間全期間の障害を集計して算出されている場合には、品質監視システム５０はＳ７の判定を１回実行されればよい。

Ｓ７でＮＯの場合には、品質監視システム５０は、処理をＡ２に続く図１６のＳ２０に進める。一方、Ｓ７でＹＥＳの場合には、品質監視システム５０は、対象部品が出荷後所定期間内の初期段階にあるか否かを判定する（Ｓ８）。Ｓ７でＹＥＳとなる場合、すなわち、当該対象部品のロット別障害発生率が基準障害発生率を超える場合は、算出された障害発生率が所定条件を充足したときの一例である。Ｓ７でＹＥＳとなる対象部品、すなわち、ロット別障害発生率が基準障害発生率を超える部品は、第１の障害発生率が基準値を超える部品の一例である。

Ｓ８でＮＯの場合、品質監視システム５０は、処理をＡ２に続く図１６のＳ２０に進める。一方、Ｓ８でＹＥＳの場合には、品質監視システム５０は、ロット別障害発生率が連続して基準障害発生率を超えたか否かを判定する（Ｓ９）。ロット別障害発生率が連続して基準障害発生率を超えたとは、情報システムが図１５から図１８の処理を所定の監視期間ごとに繰り返し実行する場合に、複数回継続してロット別障害発生率が基準障害発生率を超えたことをいう。例えば、監視期間が１月の場合には、２ヶ月連続してロット別障害発生率が基準障害発生率を超えた場合が例示される。

Ｓ９でＮＯの場合、品質監視システム５０は、処理をＡ２に続く図１６のＳ２０に進める。一方、Ｓ９でＹＥＳの場合には、品質監視システム５０は、対象部品の追加手配数として、ロット別障害発生率が基準障害発生率を超えたロットに含まれる部品数の所定割合（図では３０％）に設定する（Ｓ１０）。ただし、この所定割合が３０％に限定される訳ではない。また、この場合に、ロット別障害発生率が基準障害発生率を超えたロットにワイブル解析を実行し、ワイブル解析から算出される部品の払出し予測数に対して、所定割合（例えば、３０％）を増分するようにしてもよい。ワイブル解析によって、製品あるいは部品の稼働期間にとともに遷移する部品の必要数量が算出される。Ｓ９でＹＥＳの場合、すなわち、ロット別障害発生率が連続して基準障害発生率を超える部品は、第１の障害発生率が複数回連続して所定条件を充足した部品の一例である。Ｓ７－Ｓ１０の処理は、算出された障害発生率が所定条件を充足したときに、部品の必要数量を予測することの一例である。

次に、品質監視システム５０は、ファーム障害確認処理を実行する（Ｓ１１）。さらに、品質監視システム５０は、ロット障害部品判断結果を保守部品管理システム２０に返信する（Ｓ１２）。その結果、処理は、Ａ１に続く図１８の保守部品管理システム２０による処理に進む。その後、品質監視システム５０は、処理を終了し、保守部品管理システム２０からの次の対象部品についての指示を待つ。Ｓ１０、Ｓ１２の処理は、必要数量を充足するように部品の在庫数量の調整を指示することの一例である。Ｓ１０、Ｓ１２の処理は、部品の在庫数量の調整を指示することの一例でもある。Ｓ１０、Ｓ１２の処理によって、通常のワイブル解析から得られる部品の必要数量に対して、Ｓ１０で設定された所定割合分だけ多く、部品の必要数量の手配が指示される。

図１６は、品質監視システム５０による稼働期間要因検出部５２の処理を例示するフローチャートである。この処理では、品質監視システム５０は、障害発生管理システム９０に障害発生情報を要求する（Ｓ２０）。すると、障害発生管理システム９０は、障害発生情報テーブル９１から対象部品の障害発生日を読み出し、品質監視システム５０に返信する（Ｓ２１）。ただし、品質監視システム５０は、障害対応管理システム８０に、障害対応情報を要求し、障害対応情報テーブル８１から、当該部品の障害を特定する情報（現象、原因、処置）を取得するようにしてもよい。Ｓ２０の処理は、部品の障害情報を取得することの一例である。

次に、品質監視システム５０は、受注管理システム３０に対象部品を搭載した製品の納入日情報を要求する（Ｓ２３）。すると、受注管理システム３０は、納入情報テーブル３
２から対象製品（装置）の納入日を読み出し、品質監視システム５０に返信する（Ｓ２４）。次に、品質監視システム５０は、Ｓ２１で受信した対象製品（装置）の障害情報とＳ２４で受信した納入日を稼働期間要因分析データベースに保存する（Ｓ２５）。

ただし、品質監視システム５０は、工場の修理情報システム７０に部品の修理年月日を要求し、修理情報システム７０から部品交換日である修理年月日を取得してもよい。例えば、保守対象期間が数年間の場合には、部品が交換される可能性が低く、製品（装置）の納入日を部品の納入日と見なして、部品の障害発生率を概算できる。一方、部品の納入日を用いると、部品の障害発生率が精度よく計算可能である。しかし、部品の納入日を用いて部品の障害発生率を算出する場合には、部品交換日を個々に厳格に管理することが求められ、情報システムの管理処理の負荷が大きくなる。したがって、情報システムに求められる障害発生率の精度に応じて、製品（装置）の納入日または個々の部品の納入日のいずれかを基に、部品の障害発生率を算出すればよい。

次に、品質監視システム５０は、稼働期間要因分析データベースに保存された対象部品の納入日および障害発生日から稼働期間を算出し、稼働期間別の障害情報を作成する（Ｓ２６）。稼働期間別の障害情報は、図１１の障害発生日情報を稼働期間毎に、区分したものであり、各稼働期間で分類された部品の出荷日、障害発生日、経過日、経過月を収集したものである。稼働期間は、例えば、週単位、月単位、あるいは年単位等の所定の長さの期間で記述される。

そして、品質監視システム５０は、各稼働期間別での障害発生率を算出する（Ｓ２７）。すなわち、品質監視システム５０は、各稼働期間（例えば、毎週／毎月／毎年等の単位で特定される稼働期間）別に発生した各部品の障害発生数を集計し、障害発生率を算出する。Ｓ２７の処理で算出される各稼働期間での障害発生率は、保守対象製品または前記保守対象製品に搭載された部品の稼働期間別に集計された前記部品の障害についての第２の障害発生率の一例である。Ｓ２０－２７の処理は、第２の障害発生率を取得することの一例である。

次に、品質監視システム５０は、稼働期間毎の障害発生率に障害の傾向があるか否かを判定する（Ｓ２８）。Ｓ２８の判定は、例えばＳ２７で算出された稼働期間別の障害発生率が、基準障害発生率を超えるか否かの判定である。また、Ｓ２８の判定は、Ｓ２７で算出された稼働期間別の障害発生率の稼働期間の増加に対する増分値が基準増分値を超える場合である。この場合の基準値は各部品についての過去の障害発生数の傾向から、稼働期間毎に経験的、実験的に設定される。また、基準増分値も、各部品についての過去の障害発生数の傾向から経験的、実験的に設定される。Ｓ２８でＹＥＳの場合、すなわち、稼働期間毎の障害発生率に障害の傾向がある場合は、取得された障害発生率が所定条件を充足したときの一例である。Ｓ２８でＹＥＳとなる部品は、第２の障害発生率が基準値を超える部品の一例である。Ｓ２８でＹＥＳとなる部品は、保守対象製品に搭載された部品のうち、稼働期間の増加に対する第２の障害発生率の増分値が基準増分値を超える部品の一例でもある。

Ｓ２８でＮＯの場合には、障害が稼働期間要因の障害ではなく、偶発障害と判断できるので、品質監視システム５０は、Ｓ３２の処理に進む。一方、Ｓ２８でＹＥＳの場合には、障害が稼働期間要因の障害があると判断できるので、品質監視システム５０は、保守が収束しているか否かを判定する（Ｓ２９）。保守が収束している場合とは、装置（または部品）の製造から所定の保守期間が経過した場合である。保守が収束している場合、品質監視システム５０は、追加手配がないことを保守部品管理システム２０に通知し（Ｓ３４）、処理を終了し、保守部品管理システム２０からの次の対象部品に対する指示を待つ。

一方、保守が収束していない場合、品質監視システム５０は、稼働期間別の障害発生率が連続して基準障害発生率を超えたか否かを判定する（Ｓ３０）。Ｓ３０でＮＯの場合、障害が稼働期間要因の障害ではなく、偶発障害の可能性があるので、品質監視システム５０は、Ｓ３２の処理に進む。一方、Ｓ３０でＹＥＳの場合、保守部品管理システム２０は、通常のワイブル分析から算出される手配数に所定の増加率（図では、１．５～２倍）を乗算して、払出し予測数を増加させた値とする（Ｓ３１）。そして、品質監視システム５０は、Ｓ３２に処理を進める。Ｓ３０でＹＥＳの場合、すなわち、稼働期間別の障害発生率が連続して基準障害発生率を超えた場合は、第１の障害発生率および第２の障害発生率との少なくとも一方の障害発生率が複数回連続して前記所定条件を充足した部品の一例である。

そして、品質監視システム５０は、ファーム障害確認処理を実行する（Ｓ３２）。さらに、品質監視システム５０は、稼働期間要因による部品追加判断結果を保守部品管理システム２０に返信する（Ｓ３３）。その結果、処理は、Ａ１に続く図１７の保守部品管理システム２０による処理に進む。その後、品質監視システム５０は、処理を終了し、保守部品管理システム２０からの次の対象部品についての指示を待つ。Ｓ３１、Ｓ３３の処理は、必要数量を充足するように部品の在庫数量の調整を指示することの一例である。Ｓ３１、Ｓ３３の処理は、在庫数量の調整を指示することの一例でもある。Ｓ３１、Ｓ３３の処理によって、通常のワイブル解析から得られる部品の必要数量に対して、Ｓ３１で乗算された増加率分だけ多く、部品の必要数量が指示される。

図１５および図１６の処理では、ロット障害検出部５１による図１５の処理でロット障害発生率が基準障害発生率を超えなかった場合に、稼働期間要因検出部５２による図１６の処理が実行された。ただし、先に稼働期間要因検出部５２による図１６の処理を実行し、稼働期間毎の障害発生率に障害の傾向がない場合に、ロット障害検出部５１による図１８の処理を実行するようにしてもよい。したがって、図１５の処理と図１６の処理の組み合わせは、第１の障害発生率および第２の障害発生率の少なくとも一方の障害発生率を算出することの一例であると言える。また、Ｓ２８－Ｓ３１の処理は、取得された障害発生率が所定条件を充足したときに、部品の必要数量を予測することの一例であると言える。

図１７は、ファーム障害確認処理を例示するフローチャートである。この処理では、品質監視システム５０は、Ｓ４またはＳ２１で取得した障害情報にファームウェア障害を示す情報があるか否かを判定する（Ｓ１０１）。Ｓ１０１でＹＥＳの場合、品質監視システム５０は、Ｗｅｂシステム４０に、当該ファームウェアのダウンロード情報の送信を依頼する（Ｓ１０２）。すると、Ｗｅｂシステム４０は、対象部品に関連するファームダウンロード情報を返信する（Ｓ１０３）。Ｓ１０１でＹＥＳの場合は、情報システムのファームウェアの更新に関連する情報が障害情報に含まれている場合の一例である。

品質監視システム５０は、ファームダウンロード情報を受信すると、当該ファームウェアをダウンロード済み顧客の地域の部品倉庫を特定する（Ｓ１０４）。Ｓ１０４の処理は、ファームウェアを更新した情報システムが稼働する地域を特定することの一例である。そして、品質監視システム５０は、特定した部品倉庫だけにさらに追加手配する指示を発する（Ｓ１０５）。追加手配数は、例えば、当該地域の部品倉庫が保守部品供給の対象とする装置数と、装置に搭載された対象部品数とに基づいて決定される。そして、品質監視システム５０は、ファーム障害判断処理を終了する。Ｓ１０５の処理は、特定された地域に供給される在庫数量の調整を指示することの一例である。

図１８は、品質監視システム５０からのロット障害部品追加判断結果の返信（Ｓ１２）または稼働期間要因による部品追加判断結果の返信（Ｓ３３）を受信した保守部品管理システム２０による部品追加処理を例示するフローチャートである。この処理では、保守部品管理システム２０は、受信した部品追加判断結果に、追加手配数の指定があるか否かを判定する（Ｓ４０）。

Ｓ４０で追加手配数の指定がある場合、保守部品管理システム２０は、Ｓ４０に処理を進める。一方、追加手配の指定がない場合、保守部品管理システム２０は、対象部品の在庫数が平均払出し数より少ないか否かを判定する（Ｓ４１）。対象部品の在庫数が平均払出し数より少ない場合、追加手配数を、追加手配数＝平均払出し数＋基準在庫数－在庫数；で算出し（Ｓ４２）、Ｓ４７の処理に進む。

一方、対象部品の在庫数が平均払出し数以上場合、保守部品管理システム２０は、在庫数が基準在庫数より少ないか否かを判定する（Ｓ４３）。在庫数が基準在庫数より少ない場合、保守部品管理システム２０は、追加手配数を、追加手配数＝基準在庫数－在庫数；で算出し（Ｓ４４）、Ｓ４７の処理に進む。

一方、在庫数が基準在庫数以上の場合、保守部品管理システム２０は、対象部品の変動量が保守契約で定めた基準値を超えるか否かを判定する（Ｓ４５）。対象部品の変動量が保守契約で定めた基準値を超える場合、保守部品管理システム２０は、追加手配数を、追加手配数＝保守契約で定めた増加分；とし（Ｓ４６）、Ｓ４７の処理に進む。そして、保守部品管理システム２０は、追加手配数の部品の手配の指示を発する（Ｓ４７）。すると、追加手配数の部品が工場に手配され、工場での部品の製造（Ｓ４８）、指定倉庫への送付（Ｓ５０）がなされ、指定部品倉庫に保守部品が補充される。保守部品管理システム２０は、Ｓ４７の処理の後、あるいは、Ｓ４５で変動量が契約で定めた基準値を超えていない場合、Ａ３に続く図１５のＳ１に処理を戻す。

＜実施形態の効果＞
比較例の障害発生率監視では、部品のロット不良が検出できない。一方、本情報システムは、特定の製造ロットの異常を早期に検出することが可能となり、部品不良が多発する前に部品を補充することで、保守部品枯渇問題の発生の可能性を低減することが可能となる。すなわち、本情報システムは、装置に搭載されたそれぞれの部品の製造時期、ロット番号、シリアル番号等から部品の製造ロットを特定する。製造ロットを特定することで、製造条件、製造時の環境等に起因する障害が発生する可能性のある部品群の特定が可能となり、部品在庫の適切な補充が可能となる。

また、本情報システムは、装置の納入日（交換された部品については部品交換日）と障害発生日とから部品の『稼働期間』を算出し、稼働期間別に部品の障害発生率を算出する。本情報システムは、稼働期間別の部品の障害発生率が基準障害発生率を超えるか否かを判定することで、稼働期間要因の障害の発生を早期に検知できる。また、本情報システムは、稼働期間別の部品の障害発生率の稼働期間の増加に対する増分値が基準増分値を超えるか否かを判定することで、稼働期間要因の障害の発生を早期に検知できる。その結果、稼働期間別に、早期にワイブル解析等による障害発生予測が可能となり、ロット不良と同様に不良が多発する前に部品を補充することで、保守部品枯渇の発生を回避することが可能となる。

また、本情報システムは、ワイブル解析から残存数を算出し、常時適正な保守部品在庫を可能とするため、枯渇だけで無く過剰な保守部品の管理も不要となる。合わせて、市場で稼働している同一モデルへの対策も早期に可能となり、顧客満足度の向上と保守部品の過剰な払出しによる、負のコスト削減につながる。

また、本情報システムは、障害発生を集計する単位期間について、複数期間連続して障害が基準値を超えた場合に、上記製造ロット別の障害発生率の異常、あるいは、稼働期間要因による障害発生率の異常に基づく部品在庫の追加補充を決定する。したがって、本情報システムは、障害発生率の正常と異常との判断を安定して実施し、部品在庫を適正に補充できる。

また、本情報システムは、ロット別の障害発生率および稼動期間別の障害発生率の少なくとも一方が基準値を超える事態が複数の監視期間連続して生じた場合にワイブル解析等に基づく在庫調整を指示する。本情報システムは、稼動期間別の障害発生率の稼働期間に対する増分値が基準増分値を超える事態が複数の監視期間連続して生じた場合にワイブル解析等に基づく在庫調整を指示する。したがって、本情報システムは、障害発生率の変動に過敏に応答するのではなく、安定して部品の在庫数量の調整を指示できる。

また、本情報システムは、上記障害発生率の異常が検知されたときに、障害発生率の異常が検知された部品または部品が搭載された装置の障害を示す情報にファームウェアのアップデートに起因するファームウェア障害を示す情報が含まれるか否かを判定する。そして、本情報システムは、部品または部品が搭載された装置の障害を示す情報にファームウェア障害を示す情報が含まれている場合には、ファームウェアがアップデートされた装置が納入された地域を特定する。そして、本情報システムは、特定された地域に所在する部品倉庫の部品のさらなる補充の指示を発する。したがって、本情報システムは、ファームウェア障害に対して、ファームウェアがアップデートされた地域を対象に適正に部品の在庫を補充できる。

＜他の実施形態＞
上述の実施形態では、障害現象が再現して不良が１つの部品に特定されたケースのみを想定しており、発生する障害の中には、常時では障害現象の再現しない「間欠障害」や顧客の申告以降現象が確認出来無い（再現しない）「未再現障害」の対応については、考慮されていない。

フィールドでは必ずしも障害現象が再現するとは限らず、間欠障害や未再現障害の場合には不良部品が特定出来無いケースがある事から、担当ＣＥが、顧客を安心させる為、または、顧客自身が障害の再発予防として複数部品の交換（予防交換）を要望する事がある。他の実施形態では、この様な事例が各保守部品倉庫にて複数件発生した場合の保守部品の払い出しに、対処する。

図１９は、他の実施形態の情報システムの構成図である。他の実施形態の情報システムは、製品の納入先に納入された製品保守のための保守部品の在庫管理を支援する。他の実施形態の情報システムも、図２の情報システムと同様、製造業者の複数部門に設けられたシステムと、各地の部品倉庫の情報処理装置（省略）と、顧客あるいはＳＥの情報処理装置とをネットワークで接続したものである。

図１９において、図２の情報システムの構成要素と同様の構成および作用を有する構成要素には同じ参照符号を付与し、説明は省略する。

開発部門あるいは品質保証部門には、Ｗｅｂシステム４０および品質監視システム５０が設けられる。他の実施形態の品質監視システム５０には、ロット障害検出部５１、稼働期間要因検出部５２、および予防交換検出部５５が設けられる。品質監視システム５０は、ロット障害情報テーブル５３、および予防交換情報５６を記憶手段に有している。

ＣＥ部門には障害対応管理システム８０が設けられる。障害対応管理システム８０の構成および作用は、比較例の障害対応管理システム５８０の構成および作用と同様である。他の実施形態の障害対応管理システム８０は、障害対応情報テーブル８２を記憶手段に有している。

＜データ例＞
図２０は、他の実施形態のＣＥ部門の障害対応管理システム８０が有する障害対応情報テーブル８２のデータ例である。障害対応情報テーブル８２は、装置のメンテナンス作業、障害対策結果を記録するテーブルである。障害対応情報テーブル８２は、現地対応日情報（１）システム現地調査（現調）年月、（２）システム現地調査（現調）日、障害対応情報（１）装置名、（２）装置号機、（３）現象コメント１、（４）原因コメント１、（５）処置コメント１、（６）部品名、（７）保守部品仕様、（８）保守部品数量、地域情報を含む。すなわち、障害対応情報テーブル８２は、障害が発生した装置を装置名と装置号機で特定可能とする。そして、障害対応情報テーブル８２は、障害が発生した装置について、現地作業の年月日、作業対象の装置名、障害の現象、原因、処置等を保持する。また、障害対応情報テーブル８２は、障害が発生した装置について、処置のときに修理または交換した部品、部品の仕様（例えば図番）、部品の数量を保持する。障害対応情報テーブル８２は、図７の障害対応情報テーブル８１と比較して、さらに地域情報を含み、障害対応情報（５）処置コメント１に予防交換の有無が記述される。地域情報には、保守部品を取り寄せる場所（例えば、倉庫（地域）の場所や名称）が記述される。地域情報により、保守部品がどの倉庫（地域）から払い出されるのかが特定できる。保守部品の交換が予防交換であった場合、障害対応情報（５）処置コメント１に予防交換があったことを示す「予防交換有り」が記述される。それにより、障害に対する処置が予防交換であったか否かが分かる。尚、障害対応管理システム８０は、複数の障害対応情報テーブル８２を記憶し、発生した障害ごとに修理または交換した部品に対応する障害対応情報テーブル８２が対応付けられている。それにより、ある障害に対して修理または交換した部品が何種類あるか分かる。

＜処理フロー＞
図２１は、他の実施形態の情報システムによる在庫調整処理を例示するフローチャートである。図２１から図２４の処理は、情報システムが、所定の監視期間ごとに繰り返し実行する。この場合の監視期間に限定はない。例えば、毎日、毎週、毎月、２ヶ月ごと、数ヶ月ごと等の期間で図２１から図２４の処理が実行されればよい。したがって、図２１から図２４の処理は、保守対象製品に搭載された部品のうち、第１の障害発生率および第２の障害発生率の少なくとも一方の障害発生率を所定期間ごとに繰り返し算出することの一例である。

図２２は、品質監視システム５０による稼働期間要因検出部５２の処理を例示するフローチャートである。

図２１のステップＳ１～Ｓ１２および図２２のステップＳ２０～Ｓ３４それぞれの処理は、図１５のステップＳ１～Ｓ１２および図１６のステップＳ２０～Ｓ３４それぞれの処理と同様であるため説明は省略する。ただし、他の実施形態の情報処理システムは、障害対応情報テーブル８１の代わりに障害対応情報テーブル８２を用いて、処理を行う。

図２３は、品質監視システム５０からのロット障害部品追加判断結果の返信（Ｓ１２）または稼働期間要因による部品追加判断結果の返信（Ｓ３３）を受信した保守部品管理システム２０による部品追加処理を例示するフローチャートである。この処理では、保守部品管理システム２０は、受信した部品追加判断結果に、追加手配数の指定があるか否かを判定する（Ｓ４０）。

Ｓ４０で追加手配数の指定がある場合、保守部品管理システム２０は、部品追加判断結果を品質管理システム５０に送信し、Ｓ５２の処理に進む。一方、追加手配の指定がない場合、保守部品管理システム２０は、対象部品の在庫数が平均払出し数より少ないか否かを判定する（Ｓ４１）。対象部品の在庫数が平均払出し数より少ない場合、追加手配数を、追加手配数＝平均払出し数＋基準在庫数－在庫数；で算出する（Ｓ４２）。保守部品管理システム２０は、算出した追加手配数を部品追加判断結果に含めて品質管理システム５０に送信し、Ｓ５２の処理に進む。

一方、対象部品の在庫数が平均払出し数以上場合、保守部品管理システム２０は、在庫数が基準在庫数より少ないか否かを判定する（Ｓ４３）。在庫数が基準在庫数より少ない場合、保守部品管理システム２０は、追加手配数を、追加手配数＝基準在庫数－在庫数；で算出する（Ｓ４４）。保守部品管理システム２０は、算出した追加手配数を部品追加判断結果に含めて品質管理システム５０に送信し、Ｓ５２の処理に進む。

一方、在庫数が基準在庫数以上の場合、保守部品管理システム２０は、対象部品の変動量が保守契約で定めた基準値を超えるか否かを判定する（Ｓ４５）。対象部品の変動量が保守契約で定めた基準値を超える場合、保守部品管理システム２０は、追加手配数を、追加手配数＝保守契約で定めた増加分；とし（Ｓ４６）、Ｓ５２の処理に進む。

品質監視システム５０は、予防交換部品の追加判断処理を行い（Ｓ５２）、Ｓ４７の処理に進む。Ｓ５２では、品質監視システム５０は、追加判断の結果に基づいて、受信した部品追加判断結果に地域（倉庫）毎の予防交換部品の必要数を加えた新たな追加判断結果を保守部品管理システム２０に送付する。そして、保守部品管理システム２０は、品質監視システム５０から受信した新たな追加判断結果に基づいて、追加手配数の部品の手配の指示を発する（Ｓ４７）。すると、追加手配数の部品が工場に手配され、工場での部品の製造（Ｓ４８）、指定倉庫への送付（Ｓ５０）がなされ、指定部品倉庫に保守部品が補充される。保守部品管理システム２０は、Ｓ４７の処理の後、あるいは、Ｓ４５で変動量が契約で定めた基準値を超えていない場合、Ａ３に続く図２１のＳ１に処理を戻す。

図２４は、他の実施形態の品質監視システム５０による予防交換検出部５５の予防交換部品の追加判断処理（Ｓ５２）を例示するフローチャートである。この処理では、品質監視システム５０は、追加手配部品の追加手配数を含む部品追加判断結果を保守部品管理システム２０から受信する。品質監視システム５０は、障害対応管理システム８０に、追加手配部品に関する過去の障害対応情報（詳細には、追加手配部品とともに予防交換された部品の情報）を要求する（Ｓ１１１）。障害対応管理システム８０は、障害対応情報テーブル８２から追加手配部品に関する過去の障害対応情報を品質監視システム５０に返信する（Ｓ１１２）。そして、品質監視システム５０は、追加手配部品に関する過去の障害情報を取得する。例えば、追加手配部品が部品Ａである場合、品質監視システム５０は、障害対応管理システム８０に部品Ａとともに予防交換された部品の情報（障害対応情報）を要求する。障害対応管理システム８０は、障害対応情報テーブル８２から部品Ａとともに予防交換された部品の情報を障害対応情報として品質監視システム５０に返信する。障害対応情報は、予防交換された部品に対応する障害対応情報テーブル８２の情報全てを含んでも良いし、障害対応情報テーブル８２の情報の一部（例えば、障害対応情報（６）部品名、障害対応情報（８）保守部品数量、および地域情報など）でもよい。品質監視システム５０は、受信した追加手配部品に関する過去の障害対応情報（詳細には、追加手配部品とともに予防交換された部品の情報）を予防交換情報５６として記憶部に記憶する。

品質監視システム５０は、受信した障害対応情報に基づいて、追加手配部品とともに予防交換された部品（予防交換部品）の数を地域（倉庫）ごとに集計する（Ｓ１１３）。例えば、障害対応情報の地域情報には、「東京」、「大阪」などの予防交換部品を取り寄せる地域（倉庫）を示す情報が含まれている。例えば、部品Ａとともに予防交換された部品（予防交換部品）Ｂの数は、「東京」でａ個、「大阪」でｂ個のように地域ごとに算出される。尚、予防交換部品の種類が複数ある場合には、品質監視システム５０は、予防交換部品の種類それぞれについて、交換された予防交換部品の数を地域（倉庫）ごとに集計する。また、品質監視システム５０は、さらに障害情報ごとに交換された予防交換部品の数を集計してもよい。

品質監視システム５０は、地域ごとに予防交換割合を算出し、予防交換割合が基準値を超えた地域があるか判定する（Ｓ１１４）。ある地域の予防交換割合は、当該地域（倉庫）に最初に配備された予防交換部品の数に対するＳ１１３で集計された当該地域の交換された予防交換部品の数である。ある地域の交換された予防交換部品の数は、当該地域（倉庫）から払い出された予防交換部品の数に相当する。すなわち、ある地域の予防交換割合＝Ｓ１１３で集計された当該地域の交換された予防交換部品の数／当該地域（倉庫）に最初に配備された予防交換部品の数；で算出される。また、基準値は、予め設定された値（閾値）であり、任意に変更可能である。例えば、「東京」の倉庫に最初に配備されたある予防交換部品の数が１００であり、「東京」の交換された当該予防交換部品の数（すなわち、「東京」の倉庫から払い出された当該予防交換部品の数）が４０とすると、「東京」の当該予防交換部品の予防交換割合は、０．４（＝４０／１００）となる。

予防交換割合が基準値を超えた地域がない場合（Ｓ１１４：Ｎｏ）、処理はＳ１１５に進む。品質監視システム５０は、保守部品管理システム２０から受信した部品追加判断結果を保守部品管理システム２０に送付する（Ｓ１１５）。すなわち、品質監視システム５０は、保守部品管理システム２０から受信した部品追加判断結果をそのまま保守部品管理システム２０に返信する。

予防交換割合が基準値を超えた地域がある場合（Ｓ１１４：Ｙｅｓ）、処理はＳ１１６に進む。すなわち、ある地域の残りの予防交換部品の数（在庫数）が所定値を下回ると、処理はＳ１１６に進む。

品質監視システム５０は、地域（倉庫）ごとの予防交換部品の必要数を算出する（Ｓ１１６）。例えば、品質監視システム５０は、ある地域の予防交換部品の必要数を、ある地域の予防交換部品の必要数＝当該地域（倉庫）に最初に配備された予防交換部品の数－Ｓ１１３で集計された当該地域の交換された予防交換部品の数；で算出する。品質監視システム５０は、地域（倉庫）それぞれに対する予防交換部品の必要数を算出する。

品質監視システム５０は、保守部品管理システム２０から受信した部品追加判断結果に地域（倉庫）ごとの予防交換部品の必要数を加え、新たな追加判断結果を保守部品管理システム２０に送付する（Ｓ１１７）。そして、上述のように保守部品管理システム２０は、品質監視システム５０から受信した新たな追加判断結果に基づいて、追加手配数の部品（追加手配部品と予防交換部品を含む）の手配の指示を発する（Ｓ４７）。すると、追加手配数の部品が工場に手配され、工場での部品の製造（Ｓ４８）、指定倉庫への送付（Ｓ５０）がなされ、指定部品倉庫に保守部品が補充される。すなわち、Ｓ５０では、Ｓ１１６で算出された地域（倉庫）ごとの必要数の予防交換部品が、それぞれの地域（倉庫）に送付され、予防交換部品が補充される。

他の実施形態の情報システムは、追加手配部品だけでなく、追加手配部品とともに予防交換された予防交換部品の手配を行う。それにより、他の実施形態の情報システムは、上述の実施形態の情報システムの効果に加えて、予防交換部品を地域（倉庫）毎に必要数を補充することができる。

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

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

１１ ＣＰＵ
１２ 主記憶部
１３ 外部記憶装置
１４ 表示部
１６ 通信部
２０ 保守部品管理システム
２１ 部品追加判断部
２２ 保守部品管理情報テーブル
３０ 受注管理システム
３１ 受付処理部
３２ 納入情報テーブル
４０ Ｗｅｂシステム
４１ ファームダウンロード情報
５０ 品質監視システム
５１ ロット障害検出部
５２ 稼働期間要因検出部
５３ ロット障害情報テーブル
５４ 稼働期間情報
６０ 出荷情報システム
６１ 機歴情報
７０ 修理情報システム
７１ 障害品情報
８０ 障害対応管理システム
８１ 障害対応情報テーブル
８２ 障害対応情報テーブル
９０ 障害発生管理システム
９１ 障害発生情報テーブル

Claims (7)

1. 情報システムを構成する保守対象製品に搭載されたそれぞれの部品が１まとまりの製造単位数量で製造されたことを含む製造情報別に集計された前記部品の障害についての第１の障害発生率と、前記保守対象製品または前記保守対象製品に搭載された部品の稼働期間別に集計された前記部品の障害についての第２の障害発生率との少なくとも一方の障害発生率を算出し、
   前記算出された障害発生率が所定条件を充足したときに前記部品の必要数量を予測し、
   前記必要数量を充足するように前記部品の在庫数量の調整を指示し、
   前記部品の障害情報を取得し、
   前記情報システムのファームウェアの更新に関連する情報が前記障害情報に含まれている場合に、前記ファームウェアを更新した情報システムが稼働する地域を特定し、
   前記特定された地域に供給される在庫数量の調整を指示する
   処理部を備える在庫管理装置。
2. 前記処理部は、前記保守対象製品に搭載された部品のうち、前記第１の障害発生率および前記第２の障害発生率の少なくとも一方が基準値を超える部品の在庫数量の調整を指示する請求項１に記載の在庫管理装置。
3. 前記処理部は、前記保守対象製品に搭載された部品のうち、稼働期間の増加に対する前記第２の障害発生率の増分値が基準増分値を超える部品の在庫数量の調整を指示する請求項１に記載の在庫管理装置。
4. 前記処理部は、保守対象製品に搭載された部品のうち、前記第１の障害発生率および第２の障害発生率の少なくとも一方の障害発生率を所定期間ごとに繰り返し算出し、前記第１の障害発生率および第２の障害発生率の少なくとも一方の障害発生率が複数回連続して前記所定条件を充足した部品の在庫数量の調整を指示する請求項１に記載の在庫管理装置。
5. 前記処理部は、地域ごとに前記部品とともに予防交換された他の部品の数を集計し、前記集計した前記地域ごとの予防交換された前記他の部品の数と前記他の部品の数の集計を行った前記地域ごとの前記他の部品の在庫数量に基づいて、前記他の部品の数の集計を行った前記地域ごとの前記他の部品の必要数量を充足するように前記他の部品の数の集計を行った前記地域ごとの前記他の部品の在庫数量の調整を指示する請求項１または２に記載の在庫管理装置。
6. コンピュータが、
   情報システムを構成する保守対象製品に搭載されたそれぞれの部品が１まとまりの製造単位数量で製造されたことを含む製造情報別に集計された前記部品の障害についての第１の障害発生率と、前記保守対象製品または前記保守対象製品に搭載された部品の稼働期間別に集計された前記部品の障害についての第２の障害発生率との少なくとも一方の障害発生率を算出し、
   前記算出された障害発生率が所定条件を充足したときに前記部品の必要数量を予測し、
   前記必要数量を充足するように前記部品の在庫数量の調整を指示し、
   前記部品の障害情報を取得し、
   前記情報システムのファームウェアの更新に関連する情報が前記障害情報に含まれている場合に、前記ファームウェアを更新した情報システムが稼働する地域を特定し、
   前記特定された地域に供給される在庫数量の調整を指示する
   在庫管理方法。
7. コンピュータに、
   情報システムを構成する保守対象製品に搭載されたそれぞれの部品が１まとまりの製造単位数量で製造されたことを含む製造情報別に集計された前記部品の障害についての第１の障害発生率と、前記保守対象製品または前記保守対象製品に搭載された部品の稼働期間別に集計された前記部品の障害についての第２の障害発生率との少なくとも一方の障害発生率を算出し、
   前記算出された障害発生率が所定条件を充足したときに前記部品の必要数量を予測し、
   前記必要数量を充足するように前記部品の在庫数量の調整を指示し、
   前記部品の障害情報を取得し、
   前記情報システムのファームウェアの更新に関連する情報が前記障害情報に含まれている場合に、前記ファームウェアを更新した情報システムが稼働する地域を特定し、
   前記特定された地域に供給される在庫数量の調整を指示する
   ことを実行させるためのプログラム。

Images