JP2007199844A - 部品需要予測プログラム、部品需要予測方法、及びこの方法を実行するシステム - Google Patents

Abstract

【課題】稼動機器に組み込まれている部品の需要を精密に予測する。
【解決手段】稼動機器の稼動情報及び部品の交換履歴情報を受け付け、受け付けた情報に基づいて、部品の稼動量に関する、連続する複数の単位稼動量区間（稼動区間）毎の稼動台数を求める。そして、過去の稼動区間毎の稼動台数実績に基づいて、表２５０１に示すように、稼動区間毎に、未来の単位期間（カレンダ区間）毎（t,ｔ+1,ｔ+2,…）の部品の稼動台数を予測し、稼動区間毎で且つカレンダ区間毎の部品の稼動台数と、予め記憶されている稼動区間毎の交換率とを用いて、全稼動区間おける前記部品の交換台数を、各カレンダ区間毎に求め、これを予測需要量とする。
【選択図】図２５

Description

本発明は、自動車や航空機等の稼動機器に組み込まれる部品の需要を予測する部品需要予測プログラム、部品需要予測方法、及びこの方法を実行するシステムに関する。

自動車や航空機などの稼動機器を長期間品質維持していくためには、製品出荷後の点検/修理/部品交換などの継続的なメンテナンスが重要である。さらに、メンテナンスはできる限り短い時間で作業完了させ、稼動機器の動作不能時間を低減させることも望まれている。メンテナンス会社やメンテナンス部門は、それを目指して様々な改善施策を実施している。

部品交換において稼動機器の余分な動作不能時間を発生させないようにするためには、部品在庫を必要な時に、適切な場所に、必要な数を準備しておかねばならない。

そこで、常に変動する部品の需要を高精度に予測する技術と予測誤差分を適切に設定する技術が必要となる。

上述の需要を予測する技術としては、例えば、特許文献１，２に記載の技術が知られている。これらの特許文献１，２に記載の需要予測技術は、出荷実績（あるいは販売/受注実績）を活用した移動平均法などの方式を利用した技術である。

また、上述の予測誤差設定/更新に関する技術としては、例えば、特許文献３〜５に記載の技術が知られている。

特許第３６２８５５０号 特開２００４−２３４４７０号 特開２００４−７０６１２号 特開２００４−１０２３６７号 特願２００４−３０８７７４号

上述の各特許文献に記載の技術は、いずれも需要をできる限り精密に予測するための技術であるが、部品を管理する者にとっては、より精密に部品の需要を予測し、部品の在庫を管理したいという強い要望がある。特に、サービス部品の点数が増加している一方で、部品在庫を可能な限り少なくしてコスト削減を図ろうとする傾向が強くなっている昨今では、先の要望が日に日に大きくなる可能性が高い。

そこで、本発明の目的は、より精密に部品の在庫を予測することができる部品需要予測プログラム、部品需要予測法、及びこの方法を実現するためのシステムを提供することである。

上記課題を解決するために、本発明では、
稼動機器の稼動情報及び部品の交換履歴情報を受け付け、
受け付けた情報に基づいて、前記部品の稼動量に関する、連続する複数の単位稼動量区間毎の稼動台数を求め、
過去に求めた前記複数の単位稼動量区間毎の稼動台数実績に基づいて、該複数の単位稼動量区間毎に、連続する複数の単位期間毎の前記部品の稼動台数を予測し、
前記複数の単位稼動量区間毎で且つ前記複数の単位期間毎に予測した前記部品の稼動台数と、予め記憶されている前記複数の単位稼動量区間毎の交換率とを用いて、前記複数の単位稼動量区間を合わせた全稼動量区間おける前記部品の交換台数を、前記複数の単位期間毎に求める。

本発明によれば、部品の寿命特性（交換率）や稼動特性を反映させて、部品の需要を予測しているので、予測精度が高まり、例えば、ピーク需要も事前に把握できるようになる。この結果、不必要な部品在庫を減らすことができ、コスト削減を図ることができる上に、ピーク需要にも適切に対応することができるようになる。

以下、本発明に係る部品在庫管理システムの一実施形態について説明する。

「実施形態の適用モデル」
本実施形態の部品在庫管理システムの適用対象として想定しているサプライチェーンモデルについて、図１を用いて説明する。

サービス部品などのアイテムは、サプライヤα１から倉庫β1を経由して、整備場などの保守拠点γ１，γ２，…に供給される。サプライヤα１から倉庫β１に供給するアイテムの数量は、自動車や航空機等の稼動機器から収集される稼動データや、倉庫β１の在庫データなどを用いて、在庫補充計算を実施して求められる。倉庫β１から保守拠点γ１、γ２にアイテムが供給されるのは、稼動機器で故障が発生したときや、計画的な部品交換計画による交換作業を実施するときである。

「部品在庫管理システムの全体構成」
本実施形態の部品在庫管理システムの構成について、図２を用いて説明する。

この部品在庫管理システムは、計画情報、実績情報や各種パラメータなどを管理し、在庫補充管理を実現するシステムである。部品在庫管理システムは、保守拠点γ１，γ２，…などの配置される保守拠点側端末１と、倉庫β１などに配置される倉庫側端末２と、部品の管理センタ等に配置される在庫管理端末３と、部品の製造工場等のサプライヤα１等に配置されるサプライヤ側端末４とを有している。各端末１〜４は、それぞれネットワーク５に接続されており、各端末１〜４相互は、ネットワーク５を介して、各種データ等を送受信できる。

各端末１〜４は、図７に示すように、いずれもコンピュータで、キーボードやマウス等の入力装置３２と、ディスプレイ等の出力装置３３と、補助記憶装置３４と需要予測プログラム等の各種プログラムを実行する演算装置３１と、を有する。演算装置３１は中央演算処理装置（以下、ＣＰＵ）３１Ａと、主記憶装置３１Ｂと、インタフェース３１Ｃと、を備えている。この演算装置３１は、入力装置３２、出力装置33および補助記憶装置34とインタフェース３１Ｃを介して接続されている。

本実施形態では、需要予測プログラム等の各種プログラムの実行結果は、主記憶装置３１Ｂに確保された記憶領域に記憶される。各種プログラムは、補助記憶装置３４に予め記憶され、その後、主記憶装置31Bに読み込まれ、ＣＰＵ３１Ａにより実行される。このＣＰＵ３１Ａによる各種プログラムの実行により、後述の各種機能が実現する。

なお、本実施形態では、部品在庫管理システムを構成する各端末が汎用情報処理装置とソフトウェアで実現される場合を例にとって説明するが、例えば、ハードワイヤードロジックを含むハードウェアや、このようなハードウェアと、予めプログラムされた汎用情報処理装置により実現してもよい。

また、本実施形態では、在庫管理システムを分散処理するシステムとして説明するが、本発明はこれに限定されるものではない。本発明は他の情報処理システムに組み込まれてそれらの一部として機能するように構成することも考えられる。また、それぞれの端末機能の一部を組み換えたり、小分けにしたり、まとめたりして実現してもよい。

次に、在庫管理システムを構成する各端末１〜４の機能構成、及び各端末１〜４が保持するデータについて、図３〜図６及び図８〜図18用いて説明する。

「保守端末側拠点の構成及び保持データ内容」
本実施形態の保守拠点側端末１は、図３に示すように、各種プログラムを実行する演算部１１０と、各種データが記憶される記憶部１２０と、各種データの入出力を行う入出力部１３０と、ネットワーク5に接続するためのネットワークＩＦ部１４０と、を有する。

演算部１１０は、稼動データの入出力や記憶部１２０への登録等を行う稼動データ管理部１１１と、稼動機器６及びこれを構成する各部品毎の個体情報を含むアイテムデータの入出力や記憶部１２０へのアイテムデータの登録を行うアイテムデータ管理部１１２と、を有する。演算部１１０の各機能部１１１，１１２は、いずれも、前述したように、ＣＰＵ３１Ａが各種プログラムを実行することで機能する。これらの機能部１１１，１１２の動作の詳細については、処理フローの説明の中で順を追って説明する。

入出力部１３０は、稼動機器６やこの稼動機器６に組み込まれているサービス部品７の記憶部（例えばＲＦＩＤタグ等）から情報を読み出すリーダ（例えばＲＦＩＤタグリーダ）およびキーボード、ディスプレイ、ＣＤ-ＲＯＭドライブ等の周辺装置と情報の入出力を行なう。

記憶部１２０は、稼動機器６の稼動データが記憶される稼動データ記憶部１２１と、前述のアイテムデータが記憶されるアイテムデータ記憶部１２２と、を有する。

稼動データ記憶部１２１には、稼動機器６に取り付けられた走行メータ等の計測機器によって測定された走行時間や起動回数などの稼動データが記憶される。具体的に、稼動データ記憶部１２１には、図８に示すように、稼動機器６を管理している拠点情報を登録するフィールド１２１１と、稼動機器６の個体情報を登録するフィールド１２１２と、走行時間や起動回数などの稼動情報を登録するフィールド１２１３と、を有する。

アイテムデータ記憶部１２２には、稼動機器６に関する個体情報やこの稼動機器６に組み込まれている各部品の個体情報が記憶される。具体的に、アイテムデータ記憶部１２２は、図９に示すように、稼動機器６を管理している拠点情報を登録するフィールド１２２１と、稼動機器６の個体情報を登録するフィールド１２２２と、稼動機器６が稼動を開始した日時を登録するフィールド１２２３と、稼動機器に組み込まれたサービス部品７の製品番号を登録するフィールド１２２４と、サービス部品７の個体情報を登録するフィールド１２２５と、を有する。なお、同図では、保守拠点γ１において、個体番号が「ｋ0001」の稼動機器６が管理されており、その稼動開始日が「2003/01/28」で、この稼動機器6を構成する部品の種類（パーツ番号）として「A01」「A02」「A03」…があり、これらの部品のそれぞれの個体番号が「ｐ0112」「ｐ0212」「ｐ0311」であること示している。

「倉庫側端末の構成及び保持データ内容」
本実施形態の倉庫側端末２は、図４に示すように、各種プログラムを実行する演算部２１０と、各種データが記憶される記憶部２２０と、キーボードやディスプレイ等の周辺装置と各種データの入出力を行なう入出力部２３０と、ネットワーク5に接続するためのネットワークＩＦ部２４０と、を有する。

演算部２１０は、在庫データの入出力や記憶部２２０への登録等を行う在庫データ管理部２１１を有する。演算部２１０の機能部２１１は、前述したように、ＣＰＵ３１Ａが各種プログラムを実行することで機能する。この機能部２１１の動作タイミングについては後述する。

記憶部２２０は、在庫データが記憶される在庫データ記憶部２２１を有する。在庫データ記憶部２２１は、図１０に示すように、サービス部品７を管理している拠点情報を登録するフィールド２２１１と、サービス部品７のパーツ番号を登録するフィールド２２１２と、在庫数量を登録するフィールド２２１３と、を有する。

「在庫管理端末の構成及び保持データの内容」
本実施形態の在庫管理端末（需要予測装置）３は、図５に示すように、需要予測プログラムを含む各種プログラムを実行する演算部３１０と、各種データが記憶される記憶部３２０と、キーボードやディスプレイ等の周辺装置と情報の入出力を行なう入出力部３３０と、ネットワーク5に接続するためのネットワークＩＦ部３４０と、を有する。

演算部３１０は、部品交換履歴データを生成する交換履歴生成部３１１と、計画立案タイミングになると保守拠点側端末１等から必要なデータを受け取る計画立案管理部３１２と、部品の未来の稼動台数を求める稼動台数生成部３１３と、部品の需要を予測するアイテム需要予測部３１４と、部品の総所要量（予測需要量＋予測誤差）を求めるアイテム所要量生成部３１５と、部品在庫の補充量を求める在庫補充量生成部３１６と、予測需要量の精度を評価する予測精度評価部３１７と、を有する。この演算部３１０の各機能部３１１，３１２，３１３，３１４，３１５，３１６，３１７も、前述したように、ＣＰＵ３１Ａが各種プログラムを実行することで機能する。これら各機能部３１１，…の動作の詳細については、処理フローの説明の中で順を追って説明する。

記憶部３２０は、各部品毎の交換履歴等が記憶されるアイテム交換履歴データ記憶部３２１と、計画立案時点毎の稼動機器６の稼動量の伸び数等が記憶される稼動伸び数データ記憶部３２２と、部品毎の稼動区間毎における交換率等が記憶されるアイテム交換率マスタデータ記憶部３２３と、部品の予測需要量と共にその予測誤差が記憶されるアイテム所要量データ記憶部３２４と、部品の在庫補充量が記憶される在庫補充データ記憶部３２５と、部品の予測需要量と実績需要と予測誤差とが記憶されるアイテム予測誤差記憶部３２６と、部品の調達リードタイムが記憶されるリードタイムマスタデータ記憶部３２７と、予測誤差とこの予測誤差を求めるために必要な値が記憶される予測誤差マスタデータ記憶部３２８と、を有する。

アイテム交換履歴データ記憶部３２１は、図１１に示すように、稼動機器６を管理している拠点情報を登録するフィールド３２１１と、稼動機器６の個体情報を登録するフィールド３２１２と、稼動機器６に組み込まれたサービス部品７の製品番号（製品の種類）を登録するフィールド３２１３と、サービス部品７の個体情報を登録するフィールド３２１４と、サービス部品７を交換した日時を登録するフィールド３２１５と、サービス部品７のステータスを登録するフィールド３２１６と、サービス部品７の稼動データを登録するフィールド３２１７と、を有する。ステータスフィールド３２１６に登録されるステータスの種類としては、予防交換であることを示す“予防”、故障交換であることを示す“故障”、稼動中であることを示す“稼動中”等がある。

稼動伸び数データ記憶部３２２は、図１２に示すように、稼動機器６を管理している拠点情報を登録するフィールド３２２１と、稼動機器６の個体情報を登録するフィールド３２２２と、走行時間や起動回数などの稼動データ種別を登録するフィールド３２２３と、データを取得した時点（計画立案時点）を登録するフィールド３２２４と、取得した稼動データを登録するフィールド３２２５と、今回取得した稼動量から前回の計画立案時点における稼動量を差し引いた値（稼動伸び数）を登録するフィールド３２２６と、を有する。ここで、稼動伸び数フィールド３２２６に登録される稼動伸び数について、具体的に説明する。例えば、計画立案時点t-1のときの稼動伸び数は、この計画立案時点t-1のときの稼動量（＝1525）から、前回の計画立案時点t-2のときの稼動量（＝1343）を引いた値（182）である。

アイテム交換率マスタデータ記憶部３２３は、図１３に示すように、稼動機器６に組み込まれたサービス部品７の製品番号を登録するフィールド３２３１と、走行時間や起動回数などの稼動データ種別を登録するフィールド３２３２と、サービス部品７の予防交換が必要になるタイミングを示す情報（寿命稼動量）を登録するフィールド３２３３と、サービス部品の寿命稼動量を等間隔に区切って得られた複数の単位稼動量区間のうちのどの区間に相当するかをしめす稼動区間を登録するフィールド３２３４と、その区間毎の交換率を登録するフィールド３２３５と、を有する。

ここで、稼動区間及び交換率について説明する。図１３に示すように部品“A01”で予防交換が必要になる稼動量、つまり寿命稼動量が起動回数500回であるとする。この場合、この起動回数500回を２５等分した各区間がここでの単位稼動量区間（稼動区間）である。また、稼動区間“20”とは、起動回数が0〜20回（＝500/25）の区間であることを示す。交換率は、過去の部品交換実績から統計的手法により求める。例えば、部品“A01”に関して、稼動区間“20”での交換実績を蓄積しておき、（同区間での部品の交換量）／（同区間での部品量）で、各稼動区間毎の交換率を求める。この交換率については、後述の計画立案前に予め求めておく。

ここで、交換率の性質について、図２５中のグラフ２５０２を用いて説明する。なお、同グラフ２５０２の縦軸は実際の部品交換率、横軸は稼動量である起動回数を示している。

部品は、稼動開始当初、故障が多い。一般に、このような故障を初期故障と呼んでいる。このため、起動回数が少ない時点では、比較的交換率が高くなる。この初期故障の時期を過ぎると、故障が少なくなり、交換率は低下し、低い交換率でしばらくの間維持される。しかしながら、ある時点からは、部品の磨耗により再び故障が多くなる。このため、この変化時点からは、交換率が次第に高まってくる。このような交換率の変化曲線を一般的にバスタブカーブと呼んでいる。また、この変化時点の稼動量を、部品等の需要を予測する場合の寿命稼動量、又は単に寿命と呼んでいる。

以上のような交換率の変化の過程で、この変化時点以降、つまり寿命以降を予防対応の領域と呼ばれ、この領域に至った部品は、故障していなくても、定期点検時等に予防交換される。また、この変化時点より以前の領域は事後対応の領域と呼ばれる。この領域では、実際に部品が故障して、初めて部品交換される。

本実施形態では、図２５中の表２５０１に示すように、パーツ番号“A01”の部品に関しては、寿命が500であるから、稼動区間“500”までの全区間が事後対応の領域区間となり、稼動区間“500”より先の全区間が予防対応の領域区間となる。

アイテム所要量データ記憶部３２４は、図１４に示すように、稼動機器６に組み込まれているサービス部品７の製品番号を登録するフィールド３２４１と、未来のカレンダ区間を登録するフィールド３２４２と、故障などの事後対応で必要となる予測需要量を登録するフィールド３２４３と、計画的な交換で必要となる、つまり予防対応で必要となる予測需要量を登録するフィールド３２４４と、カレンダ区間毎の予測誤差を登録するフィールド３２４５と、総所要量（＝事後対応の予測需要量＋予防対応の予測需要量＋予測誤差）を登録するフィールド３２４６と、計画を立案した日時（需要予測日時）を登録するフィールド３２４７と、を有する。

在庫補充データ記憶部３２５は、図１５に示すように、稼動機器６に組み込まれるサービス部品７の製品番号を登録するフィールド３２５１と、計画を立案した日時を登録するフィールド３２５２と、注文先を登録するフィールド３２５３と、入庫日あるいは入庫予定日を登録するフィールド３２５４と、在庫補充量を登録するフィールド３２５５と、その補充すべき部品のステータス（納入済み、注文済み、計画済みなど）を登録するフィールド３２５６と、を有する。

アイテム予測誤差記憶部３２６は、図１６に示すように、稼動機器６に組み込まれたサービス部品７の製品番号を登録するフィールド３２６１と、需要予測したカレンダ区間を登録するフィールド３２６２と、カレンダ区間毎の予測需要量（＝事後対応の予測需要量＋予防対応の予測需要量）を登録するフィールド３２６３と、予測需要量に対応したカレンダ区間における実績需要量を登録するフィールド３２６４と、予測需要量と実績需要量の差である誤差の実績を登録するフィールド３２６５と、予測誤差を評価した日時を登録するフィールド３２６６と、を有する。

リードタイムマスタデータ記憶部３２７は、図１７に示すように、稼動機器６に組み込まれるサービス部品７の供給元の情報を登録するフィールド３２７１と、供給先の情報を登録するフィールド３２７２と、稼動機器６に組み込まれるサービス部品７の製品番号を登録するフィールド３２７３と、部品の調達リードタイムを登録するフィールド３２７４と、を有する。

予測誤差マスタデータ記憶部３２８には、予測誤差の特性値（平均値やバラツキ）が記憶される。具体的に、この予測誤差マスタデータ記憶部３２８は、稼動機器６に組み込まれたサービス部品７の製品番号を登録するフィールド３２８１と、需要予測したカレンダ区間を登録するフィールド３２８２と、カレンダ区間毎の予測誤差の平均値を登録するフィールド３２８３と、カレンダ区間毎の予測誤差のバラツキを登録するフィールド３２８４と、予測誤差として見積るために用いる安全係数を登録するフィールド３２８５と、予測誤差を補正するか否かを登録するフィールド３２８６と、予測誤差を登録するフィールド３２８７と、を有する。

「サプライ側端末の構成及び保持データの内容」
本実施形態のサプライヤ側端末４は、図６に示すように、各種プログラムを実行する演算部４１０と、各種データが記憶される記憶部４２０と、キーボードやディスプレイ等の周辺装置と情報の入出力を行なう入出力部４３０と、ネットワーク5に接続するためのネットワークＩＦ部４４０と、を有する。

演算部４１０は、アイテム所要量データの入出力や記憶部４２０への登録等を行うアイテム所要量データ管理部４１１を有する。演算部４１０の機能部４１１は、前述したように、ＣＰＵ３１Ａが各種プログラムを実行することで機能する。この機能部４１１の動作タイミングについては後述する。

記憶部４２０は、アイテム所要量データ記憶部４２１を有する。このアイテム所要量データ記憶部４２１には、図１４を用いて、前述した在庫管理端末３のアイテム所要量データ記憶部３２４に記憶されているデータと同等のデータが記憶される。したがって、このアイテム所要量データ記憶部４２１の記憶内容の説明については省略する。

「在庫管理システムの全体処理流れ」
本実施形態の在庫管理システムでの処理は、大きく三つに分類できる。

図１９に示すように、まず一つ目の処理は、故障や事故などの事後対応や計画的な予防対応でサービス部品７の交換時に行われる処理で、保守拠点側端末１と在庫管理端末３の間で分散処理される（S1910、S1920）。

二つ目の処理は、需要予測や在庫補充計画などの計画を立案する時に行われる処理で、保守拠点側端末１と在庫管理端末３の間の処理（S1930、S1950）と、倉庫側端末２と在庫管理端末３との間の処理（S1940、S1950）と、在庫管理端末３とサプライヤ側端末４との間の処理（S1950,1970）とがあり、それぞれ分散処理される。

三つ目の処理は、予測精度を評価する時に行われる処理で、在庫補充管理端末３の中で内部処理される（S1980）。

なお、以上の処理の内容は後述する。特に、交換時の処理（S1910,S1920）と、計画立案時の処理（S1950）と、予測精度評価時の処理（S1980）に関しては、フローチャートを用いて詳細に説明する。

「部品交換時の処理」
部品交換時の保守拠点側端末１の処理（Ｓ1910）について、図２０に示すフローチャートに従って説明する。

まず、保守拠点側端末１の入出力部１３０が、稼動機器６に設けられている計器等から、この稼動機器６の稼動データを読み込む（Ｓ１９１１）。稼動データの種類として、走行（又は飛行）時間、走行（又は飛行）距離、起動回数があり、これら全てを対応計器から読み込む。この際、稼動機器６の個体番号も同時に読み込む。保守拠点側端末１の稼動データ管理部１１１は、読み込まれた稼動機器６の個体番号及びその稼動データを稼動データ記憶部１２１（図８）に登録する（Ｓ１９１２）。なお、稼動データ記憶部１２１の拠点情報を登録するフィールド１２１１には、保守側拠点端末１が置かれている保守拠点の拠点情報が予め登録されている。

次に、保守拠点側端末１の入出力部１３０が、稼動機器６に既に組み込まれている部品７の記憶部から、又は稼動機器６にこれから組み込む部品７の記憶部から設けられている計器等から、当該部品７の部品番号及び個体番号（アイテムデータ）を読み込む（Ｓ１９１３）。部品７の記憶部としては、前述したように、ＲＦＩＤタグと呼ばれている無線タグ等があり、このような記憶部からデータを読み込む場合、ＲＦＩＤタグリーダを用いることになる。この保守拠点γ１で稼動機器６を最初に扱う場合には、稼動機器６に既に組み込まれている全部品のアイテムデータを読み込むと共に、これから稼動機器６に組み込む部品のアイテムデータも読み込む。また、この保守拠点γ１で稼動機器６を既に一度以上扱っている場合には、これから稼動機器６に組み込む部品のアイテムデータを読み込む。これらのアイテムデータの読み込みの際、入出力部１３０は、稼動機器６の個体番号及び部品７の稼動開始日（交換日）、さらに、部品７のステータスも、オペレータ等から受け付ける。保守拠点側端末１のアイテムデータ管理部１１２は、読み込まれた部品７のアイテムデータ、この部品７が属する稼動機器６の個体番号、この部品７の稼動開始日をアイテムデータ記憶部１２２（図９）に登録する（Ｓ１９１４）。

稼動データ及びアイテムデータが登録されると、入出力部１３０を介したオペレータ等の指示により、稼動データ管理部１１１は稼動データ記憶部１２１から登録データを読み込み、アイテムデータ管理部１１２はアイテムデータ記憶部１２２から登録データを読み込み、これらの登録データをネットワークＩＦ部１４０を介して、在庫管理端末３へ転送する（Ｓ１９１５）。

以上で、部品交換時の保守拠点側端末１の処理が終了する。なお、保守拠点端末γ１では、データの読み込み及び転送後に、稼動機器６への部品７の組み込み作業が行われる。

次に、部品交換時の在庫管理端末３の処理（Ｓ1920）について、図２１に示すフローチャートに従って説明する。

在庫管理端末３のネットワークＩＦ部２４０が、保守拠点側端末１から稼動機器６の稼動データ及び部品７のアイテムデータを受信すると（Ｓ１９２１）、在庫管理端末３の交換履歴生成部３１１は、アイテム交換履歴データを生成し（Ｓ１９２２）、これをアイテム交換履歴データ記憶部３２１に登録する（Ｓ１９２３）。

アイテム交換履歴データとしては、図１１を用いて前述したように、保守拠点の情報、稼動機器の個体番号、パーツ番号、パーツ個体番号、交換日時（稼動開始日）、ステータス、部品の稼動量があるが、これらのデータのち、部品７の稼動量を除くデータに関しては、保守拠点側端末１から転送されてきたデータのままでアイテム交換履歴データ記憶部３２１の対応フィールドに登録される。一方、稼動量は、保守拠点端末１から稼動機器６の稼動量として転送されてくるため、これを部品７の稼動量に変換してから、アイテム交換履歴データ記憶部３２１の対応フィールドに登録される。

ここで、稼動データの変換方法について簡単に説明する。

仮に、個体番号が“ｋ0001”の稼動機器に関して、この稼動機器の稼動開始日から現時点に至る途中で、部品“A01”が予防対応で交換され、当初の個体番号“ｐ0111”が部品交換により、個体番号“ｐ0112”になったとする。この場合、この部品“A01”の交換時点では、図１１に示すように、アイテム交換履歴データ記憶部３２１の稼動機器個体番号フィールド３２１２には“ｋ0001”が登録され、パーツ番号フィールド３２１３には“A01”が登録され、交換日時フィールド３２１５には“2005/01/28”が登録され、ステータスフィールド３２１６には“予防”が登録され、部品の稼動データフィールド３２１７には稼動機器の稼動量である“510”がそのまま登録される。

これに対して、一回目の部品交換時以降では、図１１のボックス１１０内に示すように、稼動機器の稼動量（同図で〔〕で示す）と部品の稼動量とは一致しなくなるため、稼動量の変換処理が必要になる。そこで、現時点までの稼動機器の稼動量〔＝７４６〕から、最新の部品交換時までの稼動機器の稼動量〔＝５１０〕を引いて、部品の稼動量〔＝２３６〕を求める。

また、ここでは、稼動量として、前述したように、走行時間、走行距離、起動回数を扱っているが、これらのうち、稼動機器の稼動量から部品の稼動量への変換の際、この部品の寿命に最も影響を与えるものを用いる。

以上で、部品交換時の在庫管理端末３の処理が終了する。

「計画立案時の処理」
計画立案時の在庫管理端末３の処理（S１９５０）について、図２２に示すフローチャートに従って説明する。

在庫管理端末３の計画立案管理部３１２が計画立案タイミングになったか否かを判断し（Ｓ１９５１）、計画立案タイミングになっていれば、保守拠点側端末１を起動させて、この保守拠点端末１に対して稼動データの転送を要求する（Ｓ１９５２）。この要求に対して、保守拠点側端末１は、部品交換時の処理（Ｓ１９１０）の処理と基本的に同様の処理（Ｓ１９３０（図１９））を行う。但し、このときの処理（Ｓ１９３０）では、図２０に示す稼動データ読込・登録・転送処理（Ｓ１９１１，１９１２，１９１５）は実行されるものの、図２０のアイテムデータ読込・登録処理（Ｓ１９１３，１９１４）が省略される。これは、稼動データに関しては最新のデータが必要であるのに対して、部品のアイテムデータは部品交換時に既に読み込まれているからである。

計画立案管理部３１２は、保守拠点端末１から稼動データを受信すると、交換履歴生成部３１１を呼び出して、図２１に示す交換時の在庫管理端末の処理（Ｓ１９２０）と同様に、この稼動データからアイテム交換履歴データを作成させ、これをアイテム交換履歴データ記憶部３２１（図１１）に登録させる（Ｓ１９５４）。

そして、計画立案管理部３１２は、転送されてきた稼動機器の稼動量を、稼動伸び数データ記憶部３２２（図１２）の稼動データのフィールド３２２５に登録し、この登録した稼動機器の稼動量から、前回の計画立案時に登録した稼動機器の稼動量を引いて、稼動伸び数を求め、これを稼動伸び数のフィールド３２２６に登録する（Ｓ１９５５）。ところで、この実施形態では、一定期間毎に計画立案タイミングになるので、稼動伸び数のフィールド３２２６に登録される稼動伸び数は、一定期間（単位期間、ここでは一週間）毎の稼動伸び数を示すことになる。

次に、計画立案管理部３１２は、倉庫側端末２を起動させ、この倉庫側端末２に対して在庫データの転送を要求する（Ｓ１９５６）。この要求に対して、倉庫側端末２の在庫管理部２１１は、在庫データ記憶部２２１（図１０）から在庫データを読み出して、これを在庫管理端末３へ転送する（Ｓ１９５７（図１９））。在庫管理端末３の計画立案部３１２は、倉庫側端末２から在庫データを受信すると（Ｓ１９５７）、これを在庫補充生成部３１６に渡し、これを一時的に保持させておく。

計画立案管理部３１２は、その後、アイテム交換履歴データ記憶部３２１（図１１）に登録されている部品の実績需要量とアイテム所要量データ記憶部３２４（図１４）に登録されている過去の予測需要量（事後対応予測需要量＋予防対応予測需要量）とを用いて、誤差実績を生成し、アイテム予測誤差データ記憶部３２６（図１６）の誤差実績のフィールド３２６５に登録する。

ここで、誤差実績の生成処理について、図２４を用いて説明する。同図は、各時点での予測需要量を示している。同図において、横方向のデータ列は、同一計画立案時の需要予測データ列で、１０週分の予測需要量の集まりとなっている。また、縦方向のデータ列は、同一週に関する各計画立案時の需要予測データ列である。例えば、下から二番目の横方向のデータ列は、現時点から一週前の計画立案時の需要予測データ列で、下から六番目の横方向のデータ列は、現時点から五週前の計画立案時の需要予測データ列である。

現時点で生成するのは、一週前に求めた予測需要量に対する誤差である。このため、一週前に求めた予測需要量“155”から、一週前から現時点までの実績需要量“157”を引いた値“-2”を誤差実績とする。この値“-2”が、前述したように、アイテム予測誤差データ記憶部３２６（図１６）の誤差実績フィールド３２６５に登録される。また、この誤差実績“-2”のほか、同じ予測誤差評価日（2005/04/01）の各誤差実績も同様に登録される。

計画立案管理部３１２は、誤差実績を生成・登録すると（Ｓ１９５９）、稼動台数生成部３１３を呼び出し、カレンダ区間ｔでの部品の稼働台数を生成させる（Ｓ１９６０）。稼動台数生成部３１３は、図２５中の表２５０１に示すように、現時点から例えば一週後までのカレンダ区間ｔの部品の稼動台数を各稼動区間毎に求める。稼動区間（＝単位稼動量区間）とは、前述したように、予防交換が必要になる稼動量、つまり寿命稼動量を複数等分した各区間である。各部品の稼動量（起動回数）は、アイテム交換履歴データ記憶部３２１の起動データフィールド３２１７（図１１）に登録されているため、同一パーツ番号でステータスが“稼動中”の複数の部品に関して、どの部品がどの稼動区間に対応するかを調べることで、各稼動区間毎の部品の稼動台数が求められる。

稼動台数生成部３１３は、次に、稼動伸び数データ記憶部３２２（図１２）の稼動伸び数フィールド３２２６に登録されている稼動伸び数を用いて、カレンダ区間ｔ＋1以降の各カレンダ区間の稼動量（起動回数）を移動平均法などの手法で求めてから（Ｓ１９６１）、カレンダ区間ｔ＋1以降の各カレンダ区間の稼動量（起動回数）がどの稼動区間に対応するかを調べて、図２５中の表２５０１に示すように、カレンダ区間ｔ＋1以降の各カレンダ区間での各稼動区間毎の部品の稼動台数を求める（Ｓ１９６２）。

稼動台数生成部３１３は、各カレンダ区間での各稼動区間毎の部品の予測稼動台数を求めると、アイテム需要予測部３１４を呼び出し、各カレンダ区間での部品の需要量（台数）を予測させる（Ｓ１９６３）。アイテム需要予測部３１４は、アイテム交換率マスタデータ記憶部３２３（図１３）の区間交換率フィールド３２３５に登録されている区間交換率を用いて、各カレンダ区間での予測需要量を求める。

具体的には、例えば、カレンダ区間ｔでの部品の予測需要量を求める場合、図２５中の表２５０１に示すように、各稼動区間（20,40,…,500,…,1000）の区間交換率がそれぞれ10,８,…,２,…,100とし、各稼動区間（20,40,…,500,…,1000）の予測需要量である稼動台数がそれぞれ360,252,…,100,…,2とすると、以下の式に示すように、各稼動区間毎に区間交換率と対応予測需要量とを掛け合わせ、各稼動区間の値を合計すると、カレンダ区間ｔでの部品の予測需要量となる。

カレンダ区間ｔの予測需要量＝360×10％＋252×8％＋…＋100×2％＋…
＋2×100％
＝95
なお、本実施形態では、図２５中の表２５０３に示すように、事後対応の予測需要量（＝45）と予防対応の予測需要量（＝50）とを分けて求めている。このため、事後対応と予防対応の境界である稼動区間“500”を境として、稼動区間“500”までの全区間での区間交換率と対応予測需要量とを掛け合わせた値の合計値を事後対応の予測需要量（＝45）とし、それ以降の全区間での区間交換率と対応予測需要量とを掛け合わせた値の合計値を予防対応の予測需要量（＝50）としている。

アイテム需要予測部３１４は、予測需要量を求めると、アイテム所要量生成部３１５を呼び出し、この予測需要量に予測誤差を付加して総所要量を求めさせ、これをアイテム所要量データ記憶部３２４に登録させる（Ｓ１９６４）。具体的に、アイテム所要量生成部３１５は、各カレンダ区間毎の予測需要量に、予測誤差マスタデータ記憶部３２８（図１８）の予測誤差フィールド３２８７に登録されている各カレンダ区間毎の予測誤差を加えて、各カレンダ区間毎の総所要量を求め、これをアイテム所要量データ記憶部３２４（図１４）の総所要量フィールド３２４６に登録する。このとき、事後対応の予測需要量、予防対応の予測需要量、計画立案日も併せて登録する。

アイテム所領量生成部３１５は、部品の総所要量を登録すると、ネットワークＩＦ部３４０を介して、この部品の総所要量をサプライヤ側端末４へ転送する（S１９６６）。この総所要量のサプライヤ側端末４へ転送は、ここでは、この部品の発注前に行われるが、サプライヤでは、この総所要量に基づいて、この部品の製造準備及び製造を行うことができる。

以上のように、本実施形態では、個々の部品の稼動量の変化及び個々の部品の交換率に着目して予測需要を求めているので、この予測需要に予測誤差を加えた総所要量は、図２５中のグラフ２５０４に示すように、実際の需要に近くなり、言い換えると、需要の予測精度が高まり、ピーク需要も予測することができる。一方、従来技術のように、単なる移動平均法で予測需要を求めた場合、予測需要、予測誤差及び総所要量は、いずれも時間経過に対して変化がなく、ピーク需要を求めることができない。このように、単なる移動平均法で予測需要を求め、これに対する予測誤差を求めた場合、この予測誤差の分布は、図２５中のボックス２５０５内の破線で示すように、時間経過に対して変化がない。これに対して、本実施形態のように予測需要を求め、これに対する予測誤差を求めた場合、この予測誤差分布は、同ボックス２５０５内の実線で示すように、時間経過に伴い増加する。

アイテム所要量生成部３１５は、総所要量を転送すると（S１９６６）、在庫補充量生成部３１６を呼び出し、リードタイム期間での合計・総所領量を生成させる（S１９６６）。具体的に、在庫補充量生成部３１６は、各カレンダ区間の総所要量とリードタイムマスタデータ記憶部３２７のリードタイムフィールド３２７に登録されている調達リードタイムを用いて、リードタイム期間での合計・総所領量を求める。この実施形態で、リードタイム期間とは、図２７に示すように、計画リードタイム（＝1週＝１カレンダ区間）とリードタイムマスタデータ記憶部３２７に登録されている調達リードタイム（＝6週＝6カレンダ区間）と計画立案サイクル（1週＝1カレンダ区間間）を加えた合計8カレンダ区間である。そこで、8カレンダ区間分の総所要量を合計して、リードタイム期間での合計・総所要量を求めている。なお、本実施形態では、リードタイムマスタデータ記憶部３２７に調達リードタイムのみを登録しているが、これは、調達リードタイムは部品の供給元と供給先の距離や交通条件により変化するのに対して、計画リードタイムや計画立案サイクルは変化しないので、これらの値を固定値として在庫補充量生成部３１６が所持していればよいからである。もっとも、計画リードタイムや計画立案サイクルも、リードタイムマスタデータ記憶部３２７に登録しておいてもよいことは言うまでもない。

在庫補充量生成部３１６は、次に、予測誤差マスタデータ記憶部３２８のデータとリードタイムマスタデータ記憶部３２７のデータとを用いて、前述のリードタイム期間での予測誤差、つまり安全在庫を生成する。なお、安全在庫の算出式および算出方法については追って説明する。

続いて、在庫補充量生成部３１６は、リードタイム期間での合計・総所要量と、安全在庫と、ステップ１９５７で受信した在庫データと、在庫補充データ記憶部３２５に記憶されている“注文済み”の在庫補充量（注残量）とから、以下の式を用いて在庫補充量を生成し、これを在庫補充データ記憶部３２５の在庫補充量フィールド３２５５に登録する（S１９６８）。そして、ネットワークIF部３４０を介して、この在庫補充量を発注量としてサプライヤ側端末４へ転送する（S１９６９）。

在庫補充量＝（合計・総所要量＋安全在庫）−（在庫データ＋注残量）
サプライヤ側端末４のアイテム所要量データ管理部４１１は、この在庫補充量を受信すると、これを記憶部４２０に登録する（S１９７０（図１９））。

以上で、計画立案時点での処理が終了する。

「予測精度評価時の処理」
予測精度評価時の在庫管理端末３の処理（S１９８０）について、図２３に示すフローチャートに従って説明する。

在庫管理端末３の予測精度評価部３１７は、まず、アイテム予測誤差データ記憶部３２６のデータを用いて、予測誤差の平均値やバラツキなどの特性値を求め、これを予測誤差マスタデータ記憶部３２８に登録する（S１９８１）。アイテム予測誤差データ記憶部３２６には、同一パーツ番号の部位に関して、計画立案時点が異なるものの、各計画立案時点でのカレンダ区間ｔの予測誤差が複数登録されている。そこで、予測精度評価部３１７は、複数の予測誤差の平均値及びバラツキを求める。

続いて、予測精度評価部３１７は、各カレンダ区間毎の予測誤差バラツキに各カレンダ区間毎の安全係数を掛けて、各カレンダ区間毎の予測誤差を求める（S１９８２）。具体的には、図１８に示すように、カレンダ区間ｔ＋ｍに関しては、予測誤差のバラツキが「１２」で安全係数が「３」の場合、両者を掛け合わせた値「３６」を予測誤差とする。但し、この予測誤差は、最終的なものではないので、直ちにこの予測誤差を登録しない。

次に、予測精度評価部３１７は、オペレータ等により入力された、予測誤差マスタデータ記憶部３２８の補正要否フィールド３２８６を参照して、この予測誤差を補正するか否かを定める（S１９８３）。）補正要の場合、この予測誤差を補正する（S１９８４）。具体的には、図１８中のボックス１８０１に示すように、カレンダ区間ｔ＋ｍに関しては、先に求めた予測誤差「３６」から予測誤差平均「１０」を引いた値「２６」を新たな予測誤差とする。すなわち、ここでは、予測誤差平均を中心として、予測誤差が分布するように補正する。

最後に、予測精度評価部３１７は、補正要の場合には補正後の予測誤差を、補正否の場合には補正していない予測誤差を予測誤差マスタデータ記憶部３２８の予測誤差フィールド３２８７に登録する（Ｓ１９８５）。

「本実施形態の需要予測の特徴」
ここで、本実施形態の需要予測の特徴について、図２６を用いて改めて説明する。

図２５中のグラフ２５０４を用いて前述したように、従来技術のように、単なる移動平均法で予測需要を求めた場合、予測需要は、いずれも時間経過に対して変化がなく、ピーク需要を求めることができない。一方、本実施形態では、個々の部品の稼動量の変化及び個々の部品の交換率に着目して予測需要を求めているので、予測精度が高く、ピーク需要も予測することができる。このように、本実施形態では、需要の予測精度が高まるため、この予測需要に対する誤差分布も、従来技術のように、単なる移動平均法で予測需要に対する誤差分布よりも小さくなる。このため、予測需要量と予測誤差の合計である総所要量は、従来技術よりも小さくなり、結果として、不必要な在庫を減らすことができる。

ところで、単なる移動平均法で予測需要を求めた場合、いずれのカレンダ区間でも、予測需要はａとなり、この予測需要の予測誤差はｃとなる。一方、本実施形態では、カレンダ区間ｔ＋ｍで、予測需要量がｂとなり、この予測需要の予測誤差は従来法の予測誤差ｃよりも小さいｄとなる。仮に、従来の移動平均法などの需要予測結果をベースに予測誤差ｃを求める一方で、本実施形態の方法で予測需要ｂを求め、両者を加えて総所要量（＝ｂ＋ｃ）を求めた場合、同図中のＸ部分が重複してしまい、総所要量が不必要に大きくなってしまう。これに対して、本実施形態では、このことを考慮して、予測誤差の誤差分布を想定しているので、その危険はない。

「安全在庫の算出式と算出手順」
安全在庫の算出式と算出手順について図２７を用いて説明する。

同図は、前述したように、計画リードタイムを1週、調達リードタイムを6週、計画立案サイクルを1週とした場合の例を示している。同図の当週の先頭を現時点で計画立案の開始日とする。計画立案の発行日は第1週の先頭となり、入庫完了日は第6週の終わりである。当週における予測需要量は、当週360、第1週から第5週は252、第6週は322、第7週は322となっている。なお、それぞれの週において実績需要が得られた段階で予測需要量と比較した予測誤差の分布をイメージしたものを中段の正規分布のグラフで示している。本実施形態では、週ごとに、第1週はσ0、第2週はσ1というように分散値σは異なる。計画範囲内（前述のリードタイム期間＝８週）の累積誤差分布は、図の下段に示すような分布２７０１となる。この各週の分散値が全て同じであると仮定した場合には、8週間の累積誤差分布、安全在庫はケース１に示すようになる。これは安全在庫の一般的な算出式である。また、各分散値が当週から第6週までは0で、第7週は0でないと仮定すると、累積誤差分布および安全在庫はケース2に示すようになる。これは、第6週まで需要が確定している場合の仮定である。各分散値が同じではなく、また0でもない場合には、累積誤差分布および安全在庫はケース3に示す式で求められる。ケース3の算出式は式が複雑になるが汎用性のある式で、ケース１やケース２を包含した式である。

安全在庫の具体的で汎用的な算出手順は、例えば次のようなものがある。
（手順１）実績需要と需要予測とを比較した予測誤差Zのサンプル数ｎを算出する。
（手順２）サンプルの標本平均を算出する。
（手順３）偏差平方和を算出する。
（手順４）標本分散を算出する。
（手順５）標本標準偏差を算出する。
（手順６）サンプル数が少ない場合には水増し係数を算出する。
（手順７）母標準偏差を算出する。
（手順８）安全係数を設定する。
（手順９）安全在庫を算出する。

なお、手順６で水増し係数を算出するのは、サンプル数が少ない場合は偏差平方和Sの方が母標準偏差σより値が小さくなる傾向が顕著となるためSでσを代用しない方がよいためである。また、手順８において、安全係数を1.65に設定した場合、欠品の確率は5％である。これは100回の計画のうち5くらい欠品が発生することを意味する。また、安全在庫は手順７で求めた母標準偏差と手順８で設定した安全係数を乗算することで求められる。この乗算式は図14のケース３で示した安全在庫の算出式と同等である。

本発明に係る一実施形態のサプライチェーンモデルを示す説明図である。 本発明に係る一実施形態の在庫管理システム構成を示す説明図である。 本発明に係る一実施形態の保守拠点側端末の機能構成図である。 本発明に係る一実施形態の倉庫側端末の機能構成図である。 本発明に係る一実施形態の在庫管理端末の機能構成図ある。 本発明に係る一実施形態のサプライヤ側端末の機能構成図である。 本発明に係る一実施形態の在庫管理システムにおける各端末のハードウェア構成図である。 本発明に係る一実施形態の稼動データ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態のアイテムデータ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態の在庫データ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態のアイテム交換履歴データ記憶部のデータ構造、及び部品の稼動量の求め方を示す説明図である。 本発明に係る一実施形態の稼動伸び数データ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態のアイテム交換率マスタデータ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態のアイテム所要量データ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態の在庫補充データ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態のアイテム予測誤差データ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態のリードタイムマスタデータ記憶部のデータ構造を示す説明図である。 本発明に係る一実施形態の予測誤差マスタデータ記憶部のデータ構造、及び予測誤差の補正方法を示す説明図である。 本発明に係る一実施形態の在庫補充管理システムの概略シーケンス図である。 本発明に係る一実施形態の部品交換時における保守拠点側端末の処理を示すフローチャートである。 本発明に係る一実施形態の部品交換時においける在庫管理端末の処理を示すフローチャートである 本発明に係る一実施形態の計画立案時における在庫管理端末の処理を示すフローチャートである。 本発明に係る一実施形態の予測精度評価時における在庫管理端末の処理を示すフローチャートである。 本発明に係る一実施形態における予測需要の誤差実績の求め方を示す説明図である。 交換率の特性、本発明に係る一実施形態における部品需要の予測方法、この予測方法での予測結果を示す説明図である。 本発明の需要予測と従来の需要予測との相違を示す説明図である。 本発明に係る一実施形態の安全在庫の求め方を示す説明図である。

符号の説明

1…保守拠点側端末、2…倉庫側端末、3…在庫補充管理端末、4…サプライヤ側端末、5…ネットワーク、6…稼動機器、7…サービス部品、31…演算装置、32…入力装置、33…出力装置、34…補助記憶装置31A…中央演算処理装置（ＣＰＵ）、31B…主記憶装置、31C…インタフェース、110、210、310、410…各端末の演算部、120、220、320、420…各端末の記憶部、130、230、330、430…各端末の入出力部、140、240、340、440…各端末のネットワークIF部、311…交換履歴生成部、312…計画立案部、313…稼動台数生成部、314…アイテム需要予測部、315…アイテム所要量生成部、316…在庫補充生成部、317…予測精度評価部、321…アイテム交換履歴データ記憶部、322…稼動伸び数データ記憶部、323…アイテム交換率マスタデータ記憶部、324…アイテム所要量データ記憶部、325…在庫補充データ記憶部、326…アイテム予測誤差データ記憶部、327…リードタイムマスタデータ記憶部、328…予測誤差マスタデータ記憶部

Claims (7)

1. 稼動機器に組み込まれる部品の需要を予測する部品需要予測プログラムにおいて、
   前記稼動機器の稼動情報及び前記部品の交換履歴情報を受け付ける受付ステップと、
   前記受付ステップで受け付けた情報に基づいて、前記部品の稼動量に関する、連続する複数の単位稼動量区間毎の稼動台数を求める稼動台数生成ステップと、
   前記稼動台数生成ステップで求めた過去の前記複数の単位稼動量区間毎の稼動台数実績に基づいて、該複数の単位稼動量区間毎に、連続する複数の単位期間毎の前記部品の稼動台数を予測する稼動台数予測ステップと、
   前記稼動台数予測ステップで求めた前記複数の単位稼動量区間毎で且つ前記複数の単位期間毎の前記部品の稼動台数と、予め記憶されている前記複数の単位稼動量区間毎の交換率とを用いて、前記複数の単位稼動量区間を合わせた全稼動量区間おける前記部品の交換台数を、前記複数の単位期間毎に求める需要予測ステップと、
   前記需要予測ステップで求めた前記複数の単位期間毎の前記部品の交換台数を予測需要量として出力する出力ステップと、
   をコンピュータに実行させることを特徴とする部品需要予測プログラム。
2. 請求項１に記載の部品需要予測プログラムにおいて、
   前記需要予測ステップでは、連続する前記複数の単位稼動量区間を、予め定められている前記部品の交換が必要になる寿命稼動量を基準にして、該寿命稼動量より小さい単位稼動量区間の集まりである事後対応用区間と、該寿命稼動量以上大きい単位稼動量区間の集まりである予防対応区間とに分け、該事後対応用区間と該予防対応区間毎に、前記複数の単位期間毎の予測需要量を求め、
   前記出力ステップでは、前記事後対応用区間の前記複数の単位期間毎の予測需要量と前記予防対応区間の該複数の単位期間毎の予測需要量とを区別して出力する、
   ことを特徴とする部品需要予測プログラム。
3. 請求項１及び２のいずれか一項に記載の部品需要予測プログラムにおいて、
   前記需要予測ステップで求めた複数の単位期間毎の前記予測需要を記憶する予測需要記憶ステップと、
   前記受付ステップで受け付けた前記部品の交換履歴情報に基づく、過去の単位期間毎の該部品の実際の交換台数である実需要量と、前記予測需要記憶ステップで記憶した過去の単位期間毎の前記予測需要量とを用いて、該実需要量と該予測需要量との差である誤差を予測するために必要な誤差の特性値を求める誤差特性値算出ステップと、
   前記特性値を少なくとも用いて、前記需要予測ステップで求めた前記複数の単位期間毎の予測需要量に対する予測誤差を求める予測誤差生成ステップと、
   を前記コンピュータに実行させ、
   前記出力ステップでは、前記需要予測ステップで求めた前記複数の単位期間毎の予測需要量に対応させて、前記予測誤差生成ステップで求めた該複数の単位期間毎の予測誤差を出力する、又は、該予測需要量と該予測誤差とを合わせた複数の単位期間毎の総所要量を出力する、
   ことを特徴とする部品需要予測プログラム。
4. 請求項１から３のいずれか一項に記載の部品需要予測プログラムにおいて、
   前記出力ステップでは、前記需要予測ステップで求めた前記複数の単位期間毎の前記予測需要量のうち、前の単位期間の予測需要量に対して、予め定められた値以上の予測需要量の増加がある単位期間の予測需要量を、他の単位期間と区別して出力する、
   ことを特徴とする部品需要予測プログラム。
5. 稼動機器に組み込まれる部品の需要を予測する部品需要予測方法において、
   前記稼動機器の稼動情報及び前記部品の交換履歴情報を受け付ける受付工程と、
   前記受付工程で受け付けた情報に基づいて、前記部品の稼動量に関する、連続する複数の単位稼動量区間毎の稼動台数を求める稼動台数生成工程と、
   前記稼動台数生成工程で求めた過去の前記複数の単位稼動量区間毎の稼動台数実績に基づいて、該複数の単位稼動量区間毎に、連続する複数の単位期間毎の前記部品の稼動台数を予測する稼動台数予測工程と、
   前記稼動台数予測工程で求めた前記複数の単位稼動量区間毎で且つ前記複数の単位期間毎の前記部品の稼動台数と、予め記憶されている前記複数の単位稼動量区間毎の交換率とを用いて、前記複数の単位稼動量区間を合わせた全稼動量区間おける前記部品の交換台数を、前記複数の単位期間毎に求める需要予測工程と、
   前記需要予測工程で求めた前記複数の単位期間毎の前記部品の交換台数を予測需要量として出力する出力工程と、
   を含むことを特徴とする部品需要予測方法。
6. 稼動機器に組み込まれる部品の需要を予測する部品需要予測装置において、
   前記稼動機器の稼動情報及び前記部品の交換履歴情報を受け付ける入力手段と、
   前記入力手段で受け付けた情報に基づいて、前記部品の稼動量に関する、連続する複数の単位稼動量区間毎の稼動台数を求める稼動台数生成手段と、
   前記稼動台数生成手段で求めた過去の前記複数の単位稼動量区間毎の稼動台数実績に基づいて、該複数の単位稼動量区間毎に、連続する複数の単位期間毎の前記部品の稼動台数を予測する稼動台数予測手段と、
   前記稼動台数予測手段で求めた前記複数の単位稼動量区間毎で且つ前記複数の単位期間毎の前記部品の稼動台数と、予め記憶されている前記複数の単位稼動量区間毎の交換率とを用いて、前記複数の単位稼動量区間を合わせた全稼動量区間おける前記部品の交換台数を、前記複数の単位期間毎に求める需要予測手段と、
   前記需要予測手段で求めた前記複数の単位期間毎の前記部品の交換台数を予測需要量として出力する出力手段と、
   を備えていることを特徴とする部品需要予測装置。
7. 請求項６に記載の部品需要予測装置と、
   前記稼動機器の稼動情報及び前記部品の交換履歴情報を受け付けて、該稼動情報及び該交換履歴情報を前記部品予測装置の入力手段に入力する保守拠点側装置と、
   前記需要予測装置から前記部品の予測需要要を受け付ける部品供給側装置と、
   を備えていることを特徴とする部品在庫管理システム。
   

Images