特開 2025-14166 予測保守システム、及び、予測保守方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2025014166

(43)【公開日】2025-01-30

(54)【発明の名称】予測保守システム、及び、予測保守方法

(51)【国際特許分類】

   G06Q 10/20 20230101AFI20250123BHJP

   G06Q 20/18 20120101ALI20250123BHJP

【ＦＩ】

G06Q10/20

G06Q20/18

【審査請求】未請求

【請求項の数】6

【出願形態】ＯＬ

(21)【出願番号】P 2023116457

(22)【出願日】2023-07-18

(71)【出願人】

【識別番号】504373093

【氏名又は名称】日立チャネルソリューションズ株式会社

(74)【代理人】

【識別番号】110000350

【氏名又は名称】ポレール弁理士法人

(72)【発明者】

【氏名】石黒 潤

【テーマコード（参考）】

5L020

5L049

5L055

【Ｆターム（参考）】

5L020AA39

5L049CC15

5L055AA39

(57)【要約】

【課題】 障害が発生すると予測された時期に合わせて保守部品の入手を可能とし、いったん確保した保守部品がその後に不要になった際も有効活用する。
【解決手段】 自動取引装置の故障予測を行い、故障が予測された自動取引装置の保守部品につき、その地域の保守拠点に在庫が存在する場合は、その保守部品をその保守拠点にて確保する在庫部品確保処理と、故障が予測された自動取引装置の保守部品につき、その地域の保守拠点に在庫がなく他の保守拠点で使用しない在庫が存在する場合は、他の保守拠点に在庫する保守部品を、その地域の保守拠点に故障予測の期日に入手できるように融通する拠点間融通処理と、故障が予測された自動取引装置の保守部品につき、いずれの地域の保守拠点にも在庫がない場合は、故障予測の期日に入手できるように不足分を発注する発注予約処理とを行うことを特徴とする予測保守システムとした。
【選択図】 図２

【特許請求の範囲】

【請求項1】

自動取引装置の故障予測を行う故障予測装置と、
複数の地域毎に設けられその地域に設置された前記自動取引装置の保守を行う保守拠点に対して、故障復旧に必要な部品を事前に用意する保守部品管理発注装置と、
を有する、予測保守システムであって、
前記保守部品管理発注装置は、
前記故障が予測された自動取引装置の保守部品につき、その地域の前記保守拠点に在庫が存在する場合は、その保守部品をその保守拠点にて確保する在庫部品確保処理と、
前記故障が予測された自動取引装置の保守部品につき、その地域の前記保守拠点に在庫がなく他の保守拠点で使用しない在庫が存在する場合は、前記他の保守拠点に在庫する保守部品を、前記その地域の保守拠点に前記故障予測の期日に入手できるように融通する拠点間融通処理と、
前記故障が予測された自動取引装置の保守部品につき、いずれの地域の前記保守拠点にも在庫がない場合は、前記故障予測の期日に入手できるように不足分を発注する発注予約処理と、
を行うことを特徴とする、予測保守システム。

【請求項2】

請求項１に記載の予測保守システムであって、
前記保守部品管理発注装置は、
前記故障が予測された自動取引装置毎に、故障の発生予測日と予測障害種別と予測復旧処理と必要部品・個数と手配状況を管理するＡＴＭ障害予測管理テーブルと、
前記保守拠点毎の保守部品の在庫が記録された在庫テーブルと、
を有することを特徴とする、予測保守システム。

【請求項3】

請求項２に記載の予測保守システムであって、
前記保守部品毎にその発注納期と拠点間融通納期が記録された部品マスターテーブルを有し、
前記拠点間融通処理、及び、前記発注予約処理は、前記部品マスターテーブルを参照し、前記故障が予測された自動取引装置の故障予測日から逆算して指示することを特徴とする、予測保守システム。

【請求項4】

請求項３に記載の予測保守システムであって、
前記拠点間融通処理は、前記故障が予測された自動取引装置の保守部品が、その地域の保守拠点に在庫せず他の複数の保守拠点で使用しない在庫が存在する場合は、在庫数が最大の保守拠点、又はその保守部品の将来の使用可能性が低い保守拠点、またはその他に同時に融通する保守部品がある保守拠点のいずれかから融通することを特徴とする、予測保守システム。

【請求項5】

請求項４に記載の予測保守システムであって、
前記保守部品管理発注装置は、前記保守拠点毎にその保管倉庫の空き容量が記録された拠点テーブルを有し、
前記部品マスターテーブルは、各部品の梱包サイズが記録されており、
前記拠点間融通処理、及び、前記発注予約処理は、準備する前記保守部品の梱包サイズが前記保管倉庫の空容量未満の場合は、直ちに指示することを特徴とする、予測保守システム。

【請求項6】

自動取引装置の故障予測を行い、複数の地域毎に設けられその地域に設置された前記自動取引装置の保守を行う保守拠点に対して、故障復旧に必要な部品を事前に用意する予測保守方法であって、
前記故障が予測された自動取引装置の保守部品につき、その地域の前記保守拠点に在庫が存在する場合は、その保守部品をその保守拠点にて確保し、
前記故障が予測された自動取引装置の保守部品につき、その地域の前記保守拠点に在庫がなく他の保守拠点で使用しない在庫が存在する場合は、前記他の保守拠点に在庫する保守部品を、前記その地域の保守拠点に前記故障予測の期日に入手できるように融通し、
前記故障が予測された自動取引装置の保守部品につき、いずれの地域の前記保守拠点にも在庫がない場合は、前記故障予測の期日に入手できるように不足分を発注することを特徴とする、予測保守方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、自動取引装置等の市中の各所で稼働している装置の予測保守に関する。

【背景技術】

【0002】

現金の入出金や各種取引を行う自動取引装置（ＡＴＭ）は、市中の各所に配置されて稼働しており、社会インフラの一つとして重要な役割を果たしている。したがって、このような装置に何らかの不具合が生じた場合には、迅速に対処してその機能の停止を、極力、抑えることが重要である。

【0003】

また、将来の起こりうる不具合や故障に備えて、保守用の部品を予め用意しておくことによって、不具合等の発生時に迅速に対応が可能となる。従来、この種の発明としては、例えば特開２０１８－１７３７９３号公報（特許文献１）に記載のものがあった。

【0004】

特許文献１には、製品の障害情報を基にメンテナンス作業の対象製品を特定し、前記メンテナンス作業の対象製品が有する部品の障害の発生を予測し、前記障害の発生が予測された部品に対して前記発生が予測された障害に応じてメンテナンス作業の優先度を決定し、前記障害の発生が予測された部品の入手可能時期と前記優先度とに応じて前記特定された対象製品のメンテナンス作業のスケジュールを調整する処理部を備える情報処理装置が記載されている。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】特開２０１８－１７３７９３号公報

【発明の概要】

【発明が解決しようとする課題】

【0006】

ＡＩによる予測技術を用いて、稼働中の装置の現状の稼働情報に基づいて将来の発生しうる異常や故障、及びその時期などを予測し、事前のそのための保守部品を確保しておくことによって、異常発生時には迅速に対処が可能となる。

【0007】

近年はＡＩ等による予測技術の精度が上がってきてはいるものの、保守用部品を事前に確実に確保するためには、より安全側で障害予測を行う必要がある。そのため、そのような安全側での障害予測に基づいて保守部品を確保しておくと、実際には障害がおこらず、確保した部品が不要となることも予想される。

【0008】

特に、直近の予測だけでなく、長期的（数か月先）な予測については、直近の予測に比べて予測精度は下がるため、実際には障害がおこらないケースも増えてくる可能性がある。このような長期予測で障害発生を予測して保守部品を発注したものの、その後の予測で障害発生無しと修正されたような場合は、その保守部品の発注自体をキャンセルしたいケースもある。
また、設置されたＡＴＭの保守作業等を管轄する保守拠点では、保守部品を保管する必要があるが、必ずしも保管スペースが十分にあるわけではないので、長期間にわたって保守部品を保管するのは避けたいという事情もある。
したがって、できるだけ障害が発生すると予測された時期に合わせて保守部品を入手できるようにすることが望ましい。また、上述のように障害予測をより安全側で実施すると、実際には障害がおこらず、確保した部品が不要となるケースが増えてくることも予想されるため、確保した部品については有効活用できることが望ましい。

【課題を解決するための手段】

【0009】

上述した課題を解決するため本発明は、自動取引装置の故障予測を行う故障予測装置と、複数の地域毎に設けられその地域に設置された自動取引装置の保守を行う保守拠点に対して、故障復旧に必要な部品を事前に用意する保守部品管理発注装置と、を有し、保守部品管理発注装置は、故障が予測された自動取引装置の保守部品につき、その地域の保守拠点に在庫が存在する場合は、その保守部品をその保守拠点にて確保する在庫部品確保処理と、故障が予測された自動取引装置の保守部品につき、その地域の保守拠点に在庫がなく他の保守拠点で使用しない在庫が存在する場合は、他の保守拠点に在庫する保守部品を、その地域の保守拠点に故障予測の期日に入手できるように融通する拠点間融通処理と、故障が予測された自動取引装置の保守部品につき、いずれの地域の保守拠点にも在庫がない場合は、故障予測の期日に入手できるように不足分を発注する発注予約処理とを行うことを特徴とする予測保守システムとした。

【発明の効果】

【0010】

障害が発生すると予測された時期に合わせて保守部品の入手が可能である。また、いったん確保した保守部品がその後に不要になった際も有効活用ができる。

【図面の簡単な説明】

【0011】

【図1】本発明の実施例における保守管理体制を示す図である。

【図2】本発明の実施例における予測保守システム１０の全体構成を示す図である。

【図3】本発明の実施例における障害予測装置２００の構成を示す図である。

【図4】本発明の実施例における動作ログデータの内容を示す図である。

【図5】本発明の実施例における障害・保守記録のデータの内容を示す図である。

【図6】本発明の実施例における保守部品管理発注装置３００の構成を示す図である。

【図7】本発明の実施例における障害予測管理テーブル３０１の内容を示す図である。

【図8】本発明の実施例におけるＡＴＭマスターテーブル３０２の内容を示す図である。

【図9】本発明の実施例における部品マスターテーブル３０３の内容を示す図である。

【図10】本発明の実施例における在庫管理テーブル３０４の内容を示す図である。

【図11】本発明の実施例における発注テーブル３０５の内容を示す図である。

【図12】本発明の実施例における部品確保テーブル３０６の内容を示す図である。

【図13】本発明の実施例における予測保守システムの全体処理を示すフローチャートである。

【図14】本発明の実施例における在庫部品確保処理の詳細を示すフローチャートである。

【図15】本発明の実施例における拠点間融通処理の詳細を示すフローチャートである。

【図16】本発明の実施例における発注予約処理の詳細を示すフローチャートである。

【図17】本発明の実施例における各種テーブル内容の推移を説明するための図である。

【図18】本発明の実施例における各種テーブル内容の推移を説明するための図である。

【図19】本発明の実施例における各種テーブル内容の推移を説明するための図である。

【図20】本発明の他の実施例における保守部品管理発注装置３００Ａの構成を示す図である。

【図21】本発明の他の実施例における拠点管理テーブル３０７の内容を示す図である。

【図22】本発明の他の実施例における部品マスターテーブル３０３Ａの内容を示す図である。

【図23】本発明の他の実施例における拠点間融通処理の詳細を示すフローチャートである。

【図24】本発明の他の実施例における発注予約処理の詳細を示すフローチャートである。

【発明を実施するための形態】

【0012】

以下、本発明を実施するための形態について、適宜図を参照して詳細に説明する。なお、各図面を通して、同等の構成要素には同一の符号を付してあるが、図面の構成や記載の都合上、同等の構成要素に異なる符号を付したものもある。

【0013】

まず、本発明の実施例における保守管理体制を図１を用いて説明する。図１において、地域（エリア）１００は、エリアＡ（１０１）とエリアＢ（１０２）とエリアＣ（１０３）とエリアＤ（１０４）とから構成されており、それぞれのエリア内には、銀行営業店や商業施設・店舗等に備えられた自動取引装置（ＡＴＭ）として、ＡＴＭ１２３（１１１）、ＡＴＭ３４５（１１２）、ＡＴＭ５６７（１１３）、ＡＴＭ７８９（１１４）が点在している。

【0014】

また、それらのＡＴＭの保守管理等を行うため、保守員等が常駐し保守用部品を保管する保守拠点が、それぞれのエリアに拠点Ａ（１２１）、拠点Ｂ（１２２）、拠点Ｃ（１２３）、拠点Ｄ（１２４）として存在している。

【0015】

さらに、それらの保守拠点を統括し、エリア１００内の保守の全体的な管理を行う保守センタ１３０が設置されている。本発明の予測保守システムは、各ＡＴＭや保守拠点から収集した情報を保守センタ１３０に設置されたコンピュータや記憶装置等を用いて演算処理することで実現される。なお、保守センタ１３０は、前述の各保守拠点がその機能・役割を兼ねる場合もある。

【実施例0016】

（１）全体構成
図２は本実施例の予測保守システム１０の全体構成を示すものであり、障害予測装置２００と保守部品管理発注装置３００とから構成されている。また、予測保守システム１０は保守センタ１３０内に設置されている。
まず、障害予測装置２００では、各ＡＴＭにおいてその動作及び内部状態の詳細が記録された情報（動作ログデータ）を収集する。また、各拠点における過去の障害情報やその復旧情報（いつ、どのような障害が発生し、どのような保守作業を行うことによって復旧することができたか等の情報）を障害予測装置２００へ入力して学習することによって、障害予測の機械学習モデルを構築する。

【0017】

次に、構築された機械学習モデルによって、新たに順次収集した各ＡＴＭの動作ログデータを用いて、各ＡＴＭにて今後起こりうる障害の予測と、その障害を復旧するための処置・必要保守部品の予測を行い、それらを障害予測データとして保守部品管理発注装置３００へ入力する。
そして、保守部品管理発注装置３００では、取得した障害予測データに基づき、各拠点に対して保有している保守部品の確保指令や、各拠点間での保守部品の融通指令、保守部品ベンダーへの新規発注指令を行うための情報処理を行い、適切なタイミングでそれらを実行する。
（２）障害予測装置
図３に障害予測装置２００の構成を示す。本障害予測装置２００はＡＴＭ動作ログ記憶部２０１とＡＴＭ障害・保守記録記憶部２０２と学習モデル構築部２０３と障害予測処理部２０４とから構成されている。

【0018】

ＡＴＭ動作ログ記憶部２０１は、各エリアに設置されたＡＴＭ２１０から、日々の動作状況に関するデータ（動作ログデータ）を収集して記憶する。図４はこの動作ログデータの例であり、ＡＴＭ２１０を識別するＡＴＭＩＤ４００と、その動作イベントの発生日時４１０と、その動作に係るＡＴＭ２１０の操作種別４２０と、その際の障害検知の有無４３０と、障害内容４４０と、その際にＡＴＭ２１０から出力される複数のエラーコードに対するその有無４５０と、その際のＡＴＭ２１０内部の各種センサが検知した値４６０と、を有している。

【0019】

ＡＴＭ障害・保守記録記憶部２０２は、各ＡＴＭ２１０において過去に発生した障害の内容や、その際にどのような保守作業を行ったか、また、どのような保守部品を使用したかといった保守記録２２０を記憶する。

【0020】

図５はこの障害・保守記録のデータの例であり、ＡＴＭ２１０を識別するＡＴＭＩＤ５００と、障害の発生日時５１０と、その障害の内容５２０と、その際の復旧作業内容５３０と、その際に使用した保守部品の種別と個数５４０と、有している。

【0021】

学習モデル構築部２０３は、上述のＡＴＭ動作ログ記憶部２０１とＡＴＭ障害・保守記録記憶部２０２に記憶されたデータを学習用データとして使用し、機械学習モデルを構築する。すなわち、ＡＴＭ２１０の動作ログデータに基づき、将来、いつどのような障害が発生しうるか、また、その障害発生時にはどのような保守作業を行うべきか、どのような保守部品がどの程度の数量、必要となるか等を予測する機械学習モデルを構築する。

【0022】

構築された機械学習モデルは、障害予測処理部２０４へ記憶される。なおこの機械学習モデルの構築は、定期的に行ってモデルを更新していくようにしてもよいし、予測性能の劣化が認められた際に行うようにしてもよい。

【0023】

障害予測処理部２０４では、上述したＡＴＭ２１０の動作ログデータを受信し、機械学習モデルにて障害予測を行い、障害予測データとして保守部品管理発注装置３００へ出力する。
（３）保守部品管理発注装置
図６に保守部品管理発注装置３００の構成を示す。保守部品管理発注装置３００は、障害予測管理テーブル３０１と、ＡＴＭマスターテーブル３０２と、部品マスターテーブル３０３と、在庫管理テーブル３０４と、発注テーブル３０５と、部品確保テーブル３０６と、演算処理部３２０と、から構成されている。なお、上述の各構成は、同一のコンピュータにて実現してもよいし、各テーブルを別の記憶装置にて実現してもよい。

【0024】

図７は障害予測管理テーブル３０１の一例であって、障害予測装置２００から受信した障害予測データを記憶するものである。予測障害ＩＤ３０１１は、予測した複数の障害を識別する情報である。ＡＴＭＩＤ３０１２は、その障害が予測されたＡＴＭ２１０を識別する情報である。発生予測３０１３は、その予測した障害の発生日（発生予想日）である。なお、本障害予測管理テーブル３０１は、この発生予測３０１３の早い順にソートされている。

【0025】

予測障害３０１４は、予測された障害の内容である。予測復旧処理３０１５は、その障害を復旧するための処理内容を予測した結果である。必要部品３０１６、必要個数３０１７は、それぞれ予測復旧処理３０１５で必要となる部品、及びその個数である。

【0026】

手配状況３０１８は、必要部品３０１６と必要個数３０１７がその拠点において確保されているか否か、確保されていない場合は発注の手配ができているか否かなどの状況を示すものであり、障害予測管理テーブル３０１を作成した初期状態では、基本的には全て「未」となっている。

【0027】

図８はＡＴＭマスターテーブル３０２の一例を示すものであって、ＡＴＭ２１０を識別するＡＴＭＩＤ３０２１、そのＡＴＭ２１０が設置されている店舗等を示す設置場所３０２２、そのＡＴＭ２１０の保守管理等を行う管轄拠点番号３０２３とその拠点名３０２４と、を有している。

【0028】

図９は部品マスターテーブル３０３の一例を示すものであって、保守部品を識別する部品ＩＤ３０３１とその部品名３０３２、その部品の単価３０３３、その部品を新規に発注した場合に入手するまでに要するリードタイムを示す標準納期３０３４、その部品を他の拠点から融通するために梱包や発送時間など含めて必要となる期間を示す拠点間配送納期３０３５と、を有している。

【0029】

図１０は在庫管理テーブル３０４の一例を示すものであって、拠点番号３０４１とその拠点名３０４２おいて保有在庫のある部品番号３０４３（図９の部品ＩＤ３０３１に対応）とその部品名３０４４、その在庫個数３０４５、その拠点におけるその部品の使用頻度３０４６を有する。使用頻度３０４６とは、過去の保守作業等において、その拠点において使用した頻度の大小を示すものであって、「大」とあるものは、今後も使用される可能性が高いことを示す。

【0030】

図１１は発注テーブル３０５の一例を示すものであって、発注番号３０５１、発注部品の識別番号３０５２（図９の部品ＩＤ３０３１に対応）と発注個数３０５３、発注を行う予定日３０５４、その部品が納入される予定納期３０５５、納品先である拠点を示す保管先倉庫３０５６と拠点間で保守部品を融通する場合の融通元となる拠点を示す保管元倉庫３０５７（これらの値は、図８の管轄拠点３０２３に相当する）、保守部品の購入金金額でもある発注金額３０５８、備考欄３０５９を有する。

【0031】

図１２は部品確保テーブル３０６の一例を示すものであって、対象となる拠点３０６１とその拠点名３０６２、その拠点で確保すべき部品の部品番号（識別ＩＤ）３０６３とその部品名３０６４及びその個数である確保数３０６５、そしてその確保した部品の使用用途３０６６（図７の予測障害ＩＤ３０１１に対応する）を有する。
（４）処理フロー
図１３は本実施例における予測保守システムの全体処理フローであり、主に障害予測装置２００による障害予測処理（ステップＳ１３１０）と、保守部品管理発注装置３００による保守部品管理発注処理（ステップＳ１３２０）とから構成されている。
（４－１）障害予測処理（ステップＳ１３１０）
障害予測装置２００は、前述のように各ＡＴＭ２１０からの動作ログデータ（図４）と各拠点における障害復旧データ（図５）を用いて、予測モデルを作成・更新する（ステップＳ１３１１）。予測モデルの更新は、例えば、１カ月に１回といったように定期的に実施してもよいし、別途の手段等で予測モデルの性能劣化を検知した際に実施するようにしてもよい。

【0032】

次に、作成した予測モデルを用いて、所定のタイミングで障害予測を行い、障害予測データ（図７に相当）を作成する（ステップＳ１３１２）。障害予測データの作成は、毎日実施してもよいし、１週間に１回といったように所定の間隔を空けて実施してもよいが、頻度が高いほど予測に使用する動作ログデータの蓄積量が多くなるため、予測の精度が向上する可能性がある。
（４－２）保守部品管理発注処理（ステップＳ１３２０）
保守部品管理発注装置３００は、障害予測データ（図７）と各拠点の部品在庫情報（図１０）等に基づき、各拠点における在庫部品の確保処理を行う（ステップＳ１３２１）。次に、同じく障害予測データと部品在庫情報（図１０）等に基づき、各拠点間での在庫部品の融通予約処理を行う（ステップＳ１３２２）。そして、上述のいずれの処理においても準備できる見込みのない部品についての発注予約処理を行う（ステップＳ１３２３）。

【0033】

さらに、以上の処理によって作成（更新）された発注テーブル（図１１）に基づき、発注予定日３０５４になるとその発注（融通）内容を処理する（ステップＳ１３２４）。なお、この発注処理は、保守センタ１３０の係員等が目視で発注テーブルの内容を参照し、発注（融通）の手配を行うようにしてもよい。

【0034】

次に、上述した在庫部品確保処理（ステップＳ１３２１）と拠点間融通処理（ステップＳ１３２２）と発注予約処理（ステップＳ１３２３）の各処理につき、別のフローチャートを用いて詳細に説明する。
（４－２－１）在庫部品確保処理（ステップＳ１３２１）
図１４は在庫部品確保処理の詳細を示すフローチャートである。図７に示す障害予測管理テーブル３０１における予測障害ＩＤ（３０１１）を「ｉ」とし、初期値として「ｉ＝１」を設定する（ステップＳ１４０１）。そして、予測障害ＩＤ（３０１１）が「１」の予測障害につき、その手配状況３０１８を確認し、手配ができていない状況（未、ＸＸ個不足）であるかを確認する（ステップＳ１４０２）。

【0035】

手配ができていれば（ステップＳ１４０２でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１４０３）、次の予測障害ＩＤについて同様の処理を行う。

【0036】

手配ができていない状況であれば（ステップＳ１４０２でＹＥＳ）、その予測障害に係るＡＴＭＩＤ（３０１２）の所在する拠点を図８に示すＡＴＭマスターテーブル３０２から認識し、さらに必要部品３０１６と必要個数３０１７がその拠点に在庫するか、図１０に示す在庫管理テーブル３０４を参照して確認する（ステップＳ１４０４）。

【0037】

在庫があれば（ステップＳ１４０５でＹＥＳ）、その拠点でその部品を確保すべく、部品確保テーブル（図１２）にその内容を記録し（ステップＳ１４０６）、障害予測管理テーブル３０１の手配状況３０１８と在庫管理テーブル３０４の在庫数３０４５を更新する。在庫がなければ（ステップＳ１４０５でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１４０３）、次の予測障害ＩＤについて同様の処理を行う。

【0038】

そして、全ての予測障害ＩＤについて上述の処理が完了したかを確認し、完了していなければ（ステップＳ１４０８でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１４０３）、次の予測障害ＩＤについて同様の処理を行う。完了していれば（ステップＳ１４０８でＹＥＳ）、部品確保テーブル（図１２）に記録された内容に従い、各拠点に対してその部品の確保を指令する（ステップＳ１４０９）。
（４－２－２）拠点間融通処理（ステップＳ１３２２）
図１５は拠点間融通処理の詳細を示すフローチャートである。図１４のフローと同様に、予測障害ＩＤ（３０１１）を「ｉ」とし、初期値として「ｉ＝１」を設定する（ステップＳ１５０１）。そして、予測障害ＩＤ（３０１１）が「１」の予測障害につき、その手配状況３０１８を確認し、手配ができていない状況（未、ＸＸ個不足）であるかを確認する（ステップＳ１５０２）。

【0039】

手配ができていれば（ステップＳ１５０２でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１５０３）、次の予測障害ＩＤについて同様の処理を行う。

【0040】

手配ができていない状況であれば（ステップＳ１５０２でＹＥＳ）、その予測障害に係るＡＴＭＩＤ（３０１２）の所在する拠点を図８に示すＡＴＭマスターテーブル３０２から認識し、さらに必要部品３０１６と必要個数３０１７が他の拠点に在庫するか、図１０に示す在庫管理テーブル３０４を参照して確認する（ステップＳ１５０４）。在庫がなければ（ステップＳ１５０５でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１５０３）、次の予測障害ＩＤについて同様の処理を行う。

【0041】

在庫があれば（ステップＳ１５０５でＹＥＳ）、さらに他の複数の拠点において在庫があるかを確認し、複数拠点に在庫があれば（ステップＳ１５０６でＹＥＳ）、その複数の拠点のうちのどこから融通させるか、融通元を決定する（ステップＳ１５０７）。

【0042】

ここで、融通元の決定にあたっては、以下のような判定基準を用いる。すなわち、（１）同一部品の在庫数が大きい方の拠点から融通する、（２）その部品の過去の使用頻度が大のフラグ（図１０の在庫管理テーブル３０４における使用頻度３０４６）があれば、その拠点からは融通しない（将来も使用可能性が高いため）、（３）その他にも同時に融通できる部品がある拠点から融通する。なお、これらの判定基準は適宜、組み合わせたり、優先順位を設定して適用することができる。また、発注テーブル３０５の予定納期３０５５と発注数３０５３、障害予測管理テーブル３０１の発生予測日３０１３とを比較し、予測日以前に部品の在庫数が増えることを考慮しても良い。

【0043】

融通元が決定された後、もしくは、１か所の拠点のみに在庫があれば（ステップＳ１５０６でＮＯ）、図９に示す部品マスターテーブル３０３の拠点間配送納期３０３５を参照し、障害予測管理テーブル３０１の障害発生予測日３０１３に融通部品が到着するように逆算して発注（配送手配）日を決定し、図１１の発注テーブル３０５に記録（もしくは更新）する（ステップＳ１５０８）。また、上記の処理に従って、障害予測管理テーブル３０１の手配状況３０１８と在庫管理テーブル３０４の在庫数３０４５を更新する（ステップＳ１５０９）。

【0044】

そして、全ての予測障害ＩＤについて上述の処理が完了したかを確認し、完了していなければ（ステップＳ１５１０でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１５０３）、次の予測障害ＩＤについて同様の処理を行う。完了していれば（ステップＳ１５１０でＹＥＳ）、拠点間融通予約処理は終了する。
（４－２－３）発注予約処理（ステップＳ１３２３）
図１６は発注予約処理の詳細を示すフローチャートである。図１４のフローと同様に、予測障害ＩＤ（３０１１）を「ｉ」とし、初期値として「ｉ＝１」を設定する（ステップＳ１６０１）。そして、予測障害ＩＤ（３０１１）が「１」の予測障害につき、その手配状況３０１８を確認し、手配ができていない状況（未、ＸＸ個不足）であるかを確認する（ステップＳ１６０２）。

【0045】

手配ができていれば（ステップＳ１６０２でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１６０３）、次の予測障害ＩＤについて同様の処理を行う。

【0046】

手配ができていない状況であれば（ステップＳ１６０２でＹＥＳ）、その予測障害に係るＡＴＭＩＤ（３０１２）の所在する拠点を図８に示すＡＴＭマスターテーブル３０２から認識し、さらに必要部品３０１６と必要個数３０１７を確認し、図９に示す部品マスターテーブル３０３の標準納期３０３４を参照し、障害予測管理テーブル３０１の障害発生予測日３０１３に融通部品が到着するように逆算して発注日を決定し、図１１の発注テーブル３０５に記録（もしくは更新）する（ステップＳ１６０４）。また、上記の処理に従って、障害予測管理テーブル３０１の手配状況３０１８を更新する（ステップＳ１６０５）。

【0047】

そして、全ての予測障害ＩＤについて上述の処理が完了したかを確認し、完了していなければ（ステップＳ１６０６でＮＯ）、「ｉ」に「１」を加算し（ステップＳ１６０３）、次の予測障害ＩＤについて同様の処理を行う。完了していれば（ステップＳ１６０６でＹＥＳ）、発注予約処理は終了する。

【0048】

なお、障害予測装置２００による障害予測処理（ステップＳ１３１０）を定期的に実施した結果、例えば、前回の予測処理とは異なる結果となって、予定していた保守部品が不要となった場合は、発注手配前であればその発注予約を取り消して、それに応じて各種テーブルも更新するようにすればよい。また、発注手配後であれば、その部品については将来の保守用の在庫として確保しておけばよい。
（５）保守部品管理発注処理の例
上述した処理フローに基づき、保守部品管理発注処理の事例につき、各テーブルの内容の推移を中心に説明する。ここで、障害予測装置２００にて障害予測処理が完了した時点（以下、初期状態と称する）で、障害予測管理テーブル３０１は図７に示す内容になっているものとする。ＡＴＭマスターテーブル３０２及び部品マスターテーブル３０３は、それぞれ図８及び図９に示す内容とする。在庫管理テーブル３０４は図１０に示す内容を初期状態とする。なお、図１１に示す発注テーブル、及び、図１２に示す部品確保テーブル３０６は、初期状態では全て空欄になっている。
（５－１）在庫部品確保処理
（５－１－１）予測障害ＩＤ＝１について
図７に示した障害予測管理テーブル３０１の予約障害ＩＤ（３０１１）が「１」について検討を行う。

【0049】

ＡＴＭＩＤ（３０１２）＝ＡＴＭ７８９の保守拠点は拠点Ｄであり、また、保守部品としては部品３が２個と、部品２が２４個必要であることがわかる。在庫管理テーブル３０４を参照すると、拠点Ｄにおいて部品３は在庫なし、部品２は４０個の在庫があることがわかる。よって、拠点Ｄにおいて部品２につき２４個を確保することを決定する。

【0050】

以上により、予約障害ＩＤ＝１に対応する部品２ついては確保できたので、テーブルの手配状況を「未」から「確保完」へ更新する。また、在庫管理テーブル３０４の拠点Ｄにおける部品２の在庫数を「４０」から「４０－２４＝１６」へ更新する。さらに、部品確保テーブル３０６に対して、拠点Ｄにおいて部品２を２４個確保するように更新する。
（５－１－２）予測障害ＩＤ＝２について
ＡＴＭ５６７の保守拠点は拠点Ｃであり、保守部品としては部品１が２個、部品２が３６個必要である。在庫管理テーブル３０４を参照すると、いずれの部品も拠点Ｃには在庫がなく、確保できないと判定される。また、障害予測管理テーブル３０１、在庫管理テーブル３０４、部品確保テーブル３０６はいずれも更新されない。
（５－１－３）予測障害ＩＤ＝３について
ＡＴＭ１２３の保守拠点は拠点Ａであり、予測復旧処理としては（１）モジュール交換と（２）基板交換が必要である。モジュール交換のためには、部品１が２個と、部品２が３６個必要であり、在庫管理テーブル３０４を参照すると、いずれの部品も拠点Ａに在庫が有るのでそれらを確保するように決定する。

【0051】

基板交換には部品４が４個と、部品２が４０個必要である。在庫管理テーブル３０４を参照すると、拠点Ａに部品４は在庫がなく、部品２は６５個の在庫があったが、上述の（１）モジュール交換用に３６個確保済みなので、６５－３６＝２９個の在庫となっている。したがって、必要個数４０個中、２９個を確保する。すなわち、１１個不足することになる。

【0052】

以上により、障害予測管理テーブル３０１については、モジュール交換用の部品１及び部品２はいずれも確保できたので、それぞれテーブルの手配状況を「未」から「確保完」へ更新する。また、基板交換用の部品４については確保できていないので、手配状況の更新はないが、部品２については必要個数４０個中、２９個確保して１１個不足するので、手配状況を「未」から「１１個不足」へ更新する。

【0053】

また、在庫管理テーブル３０４の拠点Ａにおける部品１の在庫数を「３」から「１」へ、部品２の在庫数を「６５」から「０」へ更新する。さらに、部品確保テーブル３０６に対して、拠点Ａにおいて部品１を２個、部品２を３６個(モジュール交換用）、部品２を２９個（基板交換用）確保するように更新する。
（５－１－４）予測障害ＩＤ＝４について
ＡＴＭ７８９の保守拠点は拠点Ｄであり、保守用部品としては部品４が２個と、部品２が２０個必要である。在庫管理テーブル３０４を参照すると、拠点Ｄにおいて部品４は在庫なし、部品２は当初４０個在庫したものの上述の処理にて１６個の在庫となっている（４個不足）。

【0054】

したがって、拠点Ｄにおいて部品２につき１６個確保すると決定し、障害予測管理テーブル３０１の部品２の手配状況を「未」から「４個不足」へ更新する。また、在庫管理テーブル３０４の拠点Ｄにおける部品２の在庫数を「１６」から「０」へ更新するとともに、部品確保テーブル３０６の拠点Ｄにおいて部品２を１６個確保するように更新する。

【0055】

以上の部品確保処理が完了すると、障害予測管理テーブル３０１、在庫管理テーブル３０４、部品確保テーブル３０６は、図１７に示す障害予測管理テーブル３０１Ａ、在庫管理テーブル３０４Ａ、部品確保テーブル３０６Ａの内容へ更新される。
（５－２）拠点間融通処理
（５－２－１）予測障害ＩＤ＝１について
図１７に示す障害予測管理テーブル３０１Ａによれば、予測障害ＩＤ＝１では拠点４において部品３が２個、拠点４で確保できていないため、他の拠点から融通できないか検討する。在庫管理テーブル３０４Ａによれば、部品３は拠点１と拠点２のいずれにも必要個数の在庫があることがわかる。よって、どちらの拠点から融通させるかを検討する。

【0056】

ここで、拠点１では部品３の使用頻度が「大」となっているので、拠点１からの融通はしないこととし、拠点２から融通させることに決定する。そして、図９の部品マスターテーブル３０３の拠点間配送納期３０３５を参照し、納期として１０日要すること確認し、障害予測日（発生予測３０１３）の２０２３年１月１０日に到着するように、納期の１０日間を逆算した２０２２年１２月３１に配送を手配するように予約する。なお、発生予測日の当日でなく、余裕をみてその１日～１週間程度前に到着するように配送を手配するようにしてもよい。

【0057】

以上の処理に伴い、発注テーブル３０５に上述の発注予約内容を記録する。また、障害予測管理テーブル３０１Ａの部品３について、手配状況を「未」から「融通予約済み」へ更新する。さらに、在庫管理テーブル３０４Ａの拠点２の部品３の在庫数を「２」から「０」へ更新する。
（５－２－２）予測障害ＩＤ＝２について
障害予測管理テーブル３０１Ａによれば、予測障害ＩＤ＝２では拠点３において部品１が２個と、部品２が３６個必要であり、これらが他の拠点から融通できないか検討する。

【0058】

部品１については拠点１に１個在庫があるので、拠点１から１個のみ融通し（１個不足）、部品２は他拠点にも在庫がなく融通不可能と判断する。部品マスターテーブル３０３より、部品１の拠点間配送納期は7日と確認し、障害予測日（発生予測３０１３）の２０２３年２月１日に到着するように、納期の７日間を逆算した２０２３年１月２３日に配送を手配するように予約する。

【0059】

以上の処理に伴い、発注テーブル３０５に上述の発注予約内容を記録する。また、障害予測管理テーブル３０１の部品１について、手配状況を「未」から「１個不足」へ更新する。さらに、在庫管理テーブル３０４Ａの拠点１の部品１の在庫数を「１」から「０」へ更新する。
（５－２－３）予測障害ＩＤ＝３について
拠点１において入手の手配ができていない部品４を４個と、部品２を１１個、他拠点から融通できないか検討する。

【0060】

在庫管理テーブル３０４によれば、部品４は拠点３から融通可能であり、部品２は他のいずれの拠点にも在庫がなく融通不可能であると判断する。部品マスターテーブル３０３より、部品４の拠点間配送納期は５日と確認し、障害予測日（発生予測３０１３）の２０２３年２月２０日に到着するように、納期の５日間を逆算した２０２３年２月１５日に配送を手配するように予約する。

【0061】

以上の処理に伴い、発注テーブル３０５に上述の発注予約内容を記録する。また、障害予測管理テーブル３０１の部品４について、手配状況を「未」から「融通予約済」へ更新する。さらに、在庫管理テーブルの拠点３の部品４の在庫数を「４」から「０」へ更新する。
（５－２－４）予測障害ＩＤ＝４について
拠点４において入手の手配ができていない部品４を２個と、部品２を４個、他の拠点から融通できないか検討する。在庫管理テーブル３０４によれば、どちらの部品も、いずれの拠点にも在庫がなく融通不可能と判断する。

【0062】

以上の拠点間融通処理が完了すると、障害予測管理テーブル３０１Ａ、在庫管理テーブル３０４Ａは、図１８に示すように、障害予測管理テーブル３０１Ｂ、在庫管理テーブル３０４Ｂの内容へ更新される。また、発注テーブル３０５Ｂが作成される。
（５－３）発注予約処理
（５－３－１）予測障害ＩＤ＝２について
拠点３において入手の手配ができていない部品１を１個と、部品２を３６個発注する。発生予測日（２０２３年２月１日）から逆算し、部品マスターテーブル３０３の納期を参照して発注日を計算する。そして、部品１は２０２２年１２月２０日に発注し、部品２は２０２３年１月１日に発注するように予約を手配するよう決定する。

【0063】

以上により、障害予測管理テーブル３０１Ｂの部品１、２について、それぞれ手配状況を「未」から「発注予約済」へ更新する。また、発注テーブル３０５Ｂに、上記の部品１、２の発注予約を記録する。
（５－３－２）予測障害ＩＤ＝３について
同様にして、部品２を１１個発注する。発注予定日は２０２３年１月２０日とする。障害予測管理テーブル３０１Ｂの部品１について、手配状況を「１１個不足」から「発注予約済」へ更新する。発注テーブル３０５Ｂに、上述の部品１の発注予約を記録する。
（５－３－３）予測障害ＩＤ＝４について
同様にして、部品４を２個と、部品２を４個発注する。発注予定日はそれぞれ２０２３年１月１日及び２０２３年２月１日とする。障害予測管理テーブル３０１Ｂの部品４について、手配状況を「未」から「発注予約済」へ更新し、部品２ついて、手配状況を「４個不足」から「発注予約済」へ更新する。発注テーブル３０５Ｂに、上述の部品４及び部品２の発注予約を記録する。

【0064】

以上の拠点間融通処理が完了すると、障害予測管理テーブル３０１Ｂ、発注テーブル３０５Ｂは、図１９に示す障害予測管理テーブル３０１Ｃ、発注テーブル３０５Ｃの内容へ更新される。
（６）本実施例の効果
上述した本実施例によれば、障害予測装置２００によって障害発生の時期とその内容、及びそれを復旧するために必要となる保守部品と数量を予測し、保守部品管理発注装置によって保守部品が必要となる時期に合わせて保守部品が入手できるように発注のタイミングを調整し、保守拠点間で保守部品を融通し合うことができるため、適切な時期に滞りなく必要となる保守部品を各拠点にて入手することが可能となる。

【0065】

また、各拠点間で保守部品を融通し合うことによって、保守部品の在庫の有効活用が可能となる。さらに、各拠点において必要となる時期に入手できるように発注タイミングを調整するため、保守部品の保管スペースを不必要に圧迫することがなくなるといった効果が期待できる。

【実施例0066】

次に、本発明の第２の実施例について説明する。

【0067】

前述の第１実施例においては、保守部品の保管スペースを不必要に圧迫することがないよう、障害発生が予測される時期に合わせて保守部品が到着するように配送を手配していたが、障害発生予測日当日に到着するようにした場合、万が一、配送中のトラブル等によって保守部品の到着が遅れたり、保守部品の製造元の都合等によりリードタイムが予想外に延びた場合など、必要な時期に保守部品の入手が遅れ、保守作業自体が遅延する可能性もある。

【0068】

そこで本実施例では、各拠点における保守部品の保管スペースの空き容量が十分に確保されている場合は、直ちに発注処理を行い、前倒しで保守部品をその拠点で確保するようにしている。

【0069】

図２０は本発明の第２の実施例における保守部品管理発注装置３００Ａの構成を示す図である。図６に示した第１実施例における保守部品管理発注装置３００との相違点は、拠点管理テーブル３０７が追加されている点と、部品マスターテーブル３０３に部品の梱包サイズに関する情報が追加された点である。

【0070】

図２１に拠点管理テーブル３０７の例を示す。各拠点の拠点ＩＤ３０７１と、その拠点名３０７２と、使用予定の保守部品等を格納保管する倉庫の空きスペースを示す、倉庫空き容量３０７３を有している。また、倉庫空き容量３０７３は、倉庫の空き具合に応じて随時更新される。

【0071】

図２２に部品マスターテーブル３０３Ａの例を示す。図６の部品マスターテーブル３０３に対して、その部品を梱包した際の容量を示す梱包サイズ３０３６が追加されている。

【0072】

例えば、部品ＩＤ＝１のモジュールについて見ると、梱包サイズ３０３６は「２０」であり、拠点ＩＤ＝１の拠点Ａでは倉庫空き容量３０７３が「２５」であるため、モジュール部品は１個であれば倉庫に格納可能であるが、２個以上は格納不可能であることがわかる。

【0073】

図２３は本実施例における拠点間融通予約処理のフローを説明するフローチャートである。図１５に示した第１実施例における拠点間融通予約処理のフローとの相違点は、保管倉庫の空き容量に応じて処理を変えているステップＳ２３１８以降の処理であり、それ以前の処理（ステップＳ２３１１～Ｓ２３１７）については図１５と同一であるため、説明は省略する。

【0074】

図２３のステップＳ２３１８において、その拠点で融通される部品の種類と数量につき、図２２の部品マスターテーブル３０３Ａの梱包サイズ３０３６を参照し、保管に必要となるスペースを計算する。そして、その拠点の空きスペースを、図２１の拠点管理テーブル３０７の倉庫空き容量３０７３を参照して確認する。

【0075】

その結果、保管倉庫に空スペースがあると判定した場合（ステップＳ２３１８でＹＥＳ）は、発注タイミングの調整はせずに直ちに発注（配送）を手配する（ステップＳ２３１９）。そして、それに応じて拠点管理テーブル３０４の倉庫空き容量３０７３を更新し（ステップＳ２３２０）、障害予測管理テーブル３０１の手配状況３０１８も「未」から「融通手配済み」へ更新すると共に在庫管理テーブル３０４も更新する（ステップＳ２３２２）。

【0076】

保管倉庫に空スペースがないと判定した場合（ステップＳ２３１８でＮＯ）は、第１実施例（図５）のステップＳ１５０８、Ｓ１５０９と同様に、部品マスターテーブル３０３Ａの拠点間配送納期３０３５を参照し、障害予測日に到着するように発注（配送）を予約すべく、発注テーブル３０５Ｃを更新する（ステップＳ２３２１）。そして、それに応じて障害予測管理テーブル３０１と在庫管理テーブル３０４を更新する（ステップＳ２３２２）。

【0077】

そして、全ての予測障害ＩＤについて上述の処理が完了したかを確認し、完了していなければ（ステップＳ２３２４でＮＯ）、「ｉ」に「１」を加算し（ステップＳ２３１３）、次の予測障害ＩＤについて同様の処理を行う。完了していれば（ステップＳ２３２４でＹＥＳ）、拠点間融通予約処理は終了する。

【0078】

図２４は本実施例における発注予約処理のフローを説明するフローチャートである。図１６に示した第１実施例における発注予約処理のフローとの相違点は、保管倉庫の空き容量に応じて処理を変えているステップＳ２４１５以降の処理である。

【0079】

すなわち、図２４のステップＳ２４１５において、その拠点で融通される部品の種類と数量につき、図２２の部品マスターテーブル３０３Ａの梱包サイズ３０３６を参照し、保管に必要となるスペースを計算する。そして、その拠点の空きスペースを、図２１の拠点管理テーブル３０７の倉庫空き容量３０７３を参照して確認する。

【0080】

その結果、保管倉庫に空スペースがあると判定した場合（ステップＳ２４１５でＹＥＳ）は、発注タイミングの調整はせずに直ちに発注を手配する（ステップＳ２４１６）。そして、それに応じて拠点管理テーブル３０４の倉庫空き容量３０７３を更新し（ステップＳ２４１７）、障害予測管理テーブル３０１の手配状況３０１８も「未」から「発注手配済み」へ更新する（ステップＳ２４１９）。

【0081】

保管倉庫に空スペースがないと判定した場合（ステップＳ２４１５でＮＯ）は、第１実施例（図６）のステップＳ１６０４、Ｓ１６０５と同様に、部品マスターテーブル３０３Ａの標準納期３０３５を参照し、障害予測日に到着するように発注を予約すべく、発注テーブル３０５Ｃを更新する（ステップＳ２４１８）。そして、それに応じて障害予測管理テーブル３０１を更新する（ステップＳ２４１９）。

【0082】

そして、全ての予測障害ＩＤについて上述の処理が完了したかを確認し、完了していなければ（ステップＳ２４２０でＮＯ）、「ｉ」に「１」を加算し（ステップＳ２４１３）、次の予測障害ＩＤについて同様の処理を行う。完了していれば（ステップＳ２４２０でＹＥＳ）、発注予約処理は終了する。

【0083】

以上説明したように本実施例によれば、各拠点における保守部品の保管スペースの空き容量が十分に確保されている場合は、直ちに発注処理を行い、前倒しで保守部品をその拠点で確保するようにしているので、配送中のトラブル等によって保守部品の配送に想定外の時間を要したり、保守部品の製造元の都合等によりリードタイムが予想外に延びた場合などにおいても、必要な時期に保守部品を確実に入手することができる。