(57)【要約】【課題】物品不具合の重要度に応じた不具合処理を行うことにより、不具合発生や不具合処理費用の極小化を図る。【解決手段】海外物品物流における不具合処理を分析する装置であって、不具合の発生情報を随時取り込みながら、輸送中や未開梱の物品における不具合個数を推定し、不具合の発生した物品の単価や修理費と不具合発生予測数を乗算して得られる不具合処理金額等の不具合規模により発生した不具合の重要度を判定し、所定以上の重要度の不具合であれば、不具合情報取得から不具合対策完了までの標準時間を短縮することで、不具合処理費用の極小化を図る。さらに、開梱側拠点では、不具合情報取得から不具合対策完了までの在庫推移を予測することによって、物品を補充する際に物流コストが極小となるように輸送手段を選択する。【選択図】図１
2005128752.tif 000002
【特許請求の範囲】
【請求項１】
物品の固有情報と物品に発生した不具合の不具合情報とを含む物品情報を取得する物品情報取得部と、
過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶する標準時間記憶部と、
出荷した物品において不具合が発生したときに、既に開梱された当該物品の不具合数と正常数とを取得する不具合数取得部と、
前記不具合数取得部において取得した当該物品の不具合数と正常数とから不具合発生率を求めるとともに、当該物品の未開梱又は輸送中の数量を把握することによって、当該物品全体での不具合規模を算出する不具合規模分析部と、
前記不具合規模分析部が算出した当該物品全体の不具合規模に基づいて、当該物品に発生した不具合が重要度としてあらかじめ決定された所定のしきい値を超えたときに、前記標準時間を所定の比率で時間短縮する重要不具合対策部と、
を備えることを特徴とする不具合処理分析装置。
【請求項２】
請求項１に記載の不具合処理分析装置において、
前記時間短縮された標準時間に基づいて、当該物品の不具合発生当日から不具合対策完了目標日までの正常品の在庫推移を算出し、欠品の発生が予測されたときに当該物品の予想在庫数量に基づいて最も輸送コストが最小化されるように補充する物品の輸送手段を選択する物品補充発注部を備えることを特徴とする不具合処理分析装置。
【請求項３】
工程内で扱った物品に不具合が発生したとき、不具合情報の取得から対策完了までに要する工程ごとの標準時間の管理を、コンピュータで行う場合に用いる不具合処理分析方法であって、
前記物品の固有情報と物品に発生した不具合情報とを含む物品情報を記憶部に記憶するステップと、
過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶した記憶部を検索して、対応する標準時間を抽出するステップと、
出荷した物品において不具合が発生したときに、既に開梱された当該物品の不具合数と正常数とを記憶した記憶部を検索して、不具合が発生した当該物品の不具合数と正常数とを取得するステップと、
前記取得した当該物品の不具合数と正常数とから不具合発生率を求めるとともに、当該物品の未開梱又は輸送中の数量を記憶した記憶部を検索することによって、当該物品全体での不具合規模を算出するステップと、
前記算出した当該物品全体の不具合規模に基づいて、当該物品に発生した不具合が重要度としてあらかじめ決定された所定のしきい値を超えたときに、前記標準時間を所定の比率で時間短縮するステップと、
を含む処理を実行することを特徴とする不具合処理分析方法。
【請求項４】
請求項３に記載の不具合処理分析方法において、
前記時間短縮された標準時間に基づいて、当該物品の不具合発生当日から不具合対策完了目標日までの正常品の在庫推移を算出し、欠品の発生が予測されたときに当該物品の予想在庫数量に基づいて最も輸送コストが最小化されるように補充する物品の輸送手段を選択するステップをさらに実行することを特徴とする不具合処理分析方法。
【請求項５】
工程内で扱った物品に不具合が発生したとき、不具合情報の取得から対策完了までに要する工程ごとの標準時間を管理する不具合処理分析プログラムであって、
コンピュータに、
前記物品の固有情報と物品に発生した不具合情報とを含む物品情報を記憶部に記憶するステップと、
過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶した記憶部を検索して、対応する標準時間を抽出するステップと、
出荷した物品において不具合が発生したときに、既に開梱された当該物品の不具合数と正常数とを記憶した記憶部を検索して、不具合が発生した当該物品の不具合数と正常数とを取得するステップと、
前記取得した当該物品の不具合数と正常数とから不具合発生率を求めるとともに、当該物品の未開梱又は輸送中の数量を記憶した記憶部を検索することによって、当該物品全体での不具合規模を算出するステップと、
前記算出した当該物品全体の不具合規模に基づいて、当該物品に発生した不具合が重要度としてあらかじめ決定された所定のしきい値を超えたときに、前記標準時間を所定の比率で時間短縮するステップと、
を含む処理を実行させることを特徴とする不具合処理分析プログラム。
【請求項６】
請求項５に記載の不具合処理分析プログラムにおいて、
コンピュータに、
前記時間短縮された標準時間に基づいて、当該物品の不具合発生当日から不具合対策完了目標日までの正常品の在庫推移を算出し、欠品の発生が予測されたときに当該物品の予想在庫数量に基づいて最も輸送コストが最小化されるように補充する物品の輸送手段を選択するステップをさらに実行させることを特徴とする不具合処理分析プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、不具合処理分析装置、不具合処理分析方法および不具合処理分析プログラムに関し、特に、物品に発生した不具合の情報を入手・解析し、不具合対策を実施し、費用精算を行うという一連の不具合処理についてコンピュータを用いて行う装置、方法およびプログラムの改良に関するものである。
【背景技術】
【０００２】
従来、顧客に納入した製品に不具合が発生した場合には、以下のような対応を行っていた。すなわち、
（１）顧客からの不具合情報を入手した品質保証等の窓口部門は、その不具合情報を基に一箇所あるいは複数箇所の不具合発生原因と予想される工程（明細書中で示す「工程」とは、例えば、部門、工場、会社等をいう）に対して不具合情報を送付するとともに、不具合の原因調査、対策実施を依頼する。
（２）不具合情報を受け取った工程は、顧客や窓口部門と情報交換をしながら不具合原因を調査して、対策を実施する。
（３）不具合原因に対する対策が完了すると、不具合を発生させた工程は発生原因や不具合範囲、対策状況等をまとめた報告書を窓口部門に報告する。
（４）窓口部門は、不具合を発生させた工程からの報告書をもとに顧客に対して不具合の説明を行う。
（５）その後、経理部門を通じて不具合処理に要した費用を精算する。
というものである。
【０００３】
以上のような不具合対応に関する情報の交換は、電話やＦＡＸ等を用いて行われるのが通常であり、非常に効率の悪いものであった。
【０００４】
そこで、インターネットに接続された複数の端末から情報を収集して不具合内容の分析を行う方法及びシステムに関する技術が創案されている。例えば、下記特許文献１には、物流過程で生ずる自動車等の損傷の発生状況をインターネットを介して入手し、その発生原因を迅速かつ的確に分析する発明が開示されている。かかる発明によれば、損傷位置情報や他の損傷情報（例えば損傷の種類や程度など）、輸送時の物流属性情報を蓄積することにより、視覚的により高い精度での把握が重要になる物流工程における損傷状況、損傷位置などの発生傾向や特徴の分析が、迅速かつ的確にできるようになる。
【０００５】
しかしながら、現実の物品物流において、下記特許文献１に記載の発明が特に重要視して採用している視覚的な情報では、物品不具合の分析を行う上では不十分であった。例えば、自動車部品において不具合が発生する原因には、視覚的に発見できる表面きずやカケ、錆等だけではなく、内部欠陥や歪み等、実際に製品に組み込んで初めて発見されるものもある。このような不具合は、製品からの異音発生や、製品が正常に稼働しない等の現象によって初めて明らかになるものである。
【０００６】
また、不具合の発生を最小限で抑えるには、不具合の早期発見・早期対策が重要である。これまで、不具合が発生した場合には、不具合発生の原因となった工程がその不具合処理費用を負担しなければならないため、その他の工程（例えば、窓口部門、検査部門等。さらに、物品納入先である顧客も含めた不具合対策に関係する全ての工程）は当事者意識が低くなってしまうのが通常であった。そのため、顧客からは十分な情報が得られない、検査部門では検査の遅延が発生する等の事態が発生し、さらに不具合物品が流出してしまうという問題が発生していた。
【０００７】
そこで、発明者らは上記問題に鑑みて新たな発明を創案し、「特願２００３−５２７６８号」なる出願を行った（以下、「先願発明」と記す）。この先願発明に記載の発明は、不具合が発生した場合における十分な情報の伝達と迅速な対応が実施でき、さらに、不具合対応に関係する全ての工程に当事者意識を持たせることによって、不具合品及び不具合処理費用の極小化を図ることができるというものである。具体的には、不具合情報取得から不具合対策を完了するまでに要した時間を工程ごとに算出し、責任割合に応じた不具合処理のための分担費用を算出する。この算出結果によって責任の所在の明確化を図ることができるので、各工程に当事者意識を持たせ、結果として不具合品及び不具合処理費用の極小化を図ることを可能としたのである。
【０００８】
【特許文献１】特開２００２−４６８２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
ところで、上記先願発明に記載された発明によって、不具合処理作業は大きく改善されたが、産業界における物流コストや管理コストの削減要請から、出願人は、不具合品及び不具合処理費用のさらなる極小化を図る必要にせまられた。
【００１０】
そこで、発明者は、不具合処理の作業内容について調査・分析することにより、以下の知見を得た。すなわち、出荷から開梱まで数週間から数ヶ月かかるような海外物流においては、連続的な物品不具合が開梱時に発見された場合、未開梱の物品や輸送中の物品も含めて長期間にわたって不具合品を出荷し続けていた恐れがある。このような場合に、海外工場では、物品在庫の枯渇によって生産をストップしなければならない事態が想定されるため、仮に不具合物品が発生した場合には、早急に不具合規模を特定して物品の追加発注を行わなければならないことになる。
【００１１】
しかしながら、これまでの不具合処理作業では、通常、不具合を発生させた工程は不具合情報を受理した順に不具合対策を行っていた。不具合発生工程による不具合対策は、あらかじめ設定された標準時間内に遅延なく実施するよう努力されるが、これまで複数不具合が発生した際の不具合の規模や重要度を示す指標がなかったことから、よりコストのかかる不具合に対して優先して対策を行うことができず、真の不具合処理費用の極小化が図られていなかった。また、海外工場側では、不具合規模の特定ができないため、航空機等の高額な輸送手段を用いて必要以上の物品を追加発注するという事態も発生し、余分なコストを発生させていた。
【００１２】
そこで本発明は、不具合が発生した場合に、その不具合の重要度や緊急度等を明確にし、不具合着手の優先順位等の情報を各工程に提供することによって、不具合発生や不具合処理費用の極小化を図るものである。
【００１３】
また、本発明は、海外工場等の物品を開梱する工程において、不具合物品発生情報と物品の消費計画とを対比させて物品の欠品時期を予測し、追加発注の物品個数と輸送手段の選択を最適化することができるので、さらなるコスト削減を実現することが可能である。
【課題を解決するための手段】
【００１４】
本発明に係る不具合処理分析装置は、物品の固有情報と物品に発生した不具合の不具合情報とを含む物品情報を取得する物品情報取得部と、過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶する標準時間記憶部と、出荷した物品において不具合が発生したときに、既に開梱された当該物品の不具合数と正常数とを取得する不具合数取得部と、前記不具合数取得部において取得した当該物品の不具合数と正常数とから不具合発生率を求めるとともに、当該物品の未開梱又は輸送中の数量を把握することによって、当該物品全体での不具合規模を算出する不具合規模分析部と、前記不具合規模分析部が算出した当該物品全体の不具合規模に基づいて、当該物品に発生した不具合が重要度としてあらかじめ決定された所定のしきい値を超えたときに、前記標準時間を所定の比率で時間短縮する重要不具合対策部と、を備えることを特徴とする。
【００１５】
また、本発明に係る不具合処理分析装置は、前記時間短縮された標準時間に基づいて、当該物品の不具合発生当日から不具合対策完了目標日までの正常品の在庫推移を算出し、欠品の発生が予測されたときに当該物品の予想在庫数量に基づいて最も輸送コストが最小化されるように補充する物品の輸送手段を選択する物品補充発注部を備えることを特徴とする。
【００１６】
本発明に係る不具合処理分析方法は、工程内で扱った物品に不具合が発生したとき、不具合情報の取得から対策完了までに要する工程ごとの標準時間の管理を、コンピュータで行う場合に用いる方法であって、前記物品の固有情報と物品に発生した不具合情報とを含む物品情報を記憶部に記憶するステップと、過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶した記憶部を検索して、対応する標準時間を抽出するステップと、出荷した物品において不具合が発生したときに、既に開梱された当該物品の不具合数と正常数とを記憶した記憶部を検索して、不具合が発生した当該物品の不具合数と正常数とを取得するステップと、前記取得した当該物品の不具合数と正常数とから不具合発生率を求めるとともに、当該物品の未開梱又は輸送中の数量を記憶した記憶部を検索することによって、当該物品全体での不具合規模を算出するステップと、前記算出した当該物品全体の不具合規模に基づいて、当該物品に発生した不具合が重要度としてあらかじめ決定された所定のしきい値を超えたときに、前記標準時間を所定の比率で時間短縮するステップと、を含む処理を実行することを特徴とする。
【００１７】
また、本発明に係る不具合処理分析方法は、前記時間短縮された標準時間に基づいて、当該物品の不具合発生当日から不具合対策完了目標日までの正常品の在庫推移を算出し、欠品の発生が予測されたときに当該物品の予想在庫数量に基づいて最も輸送コストが最小化されるように補充する物品の輸送手段を選択するステップをさらに実行することを特徴とする。
【００１８】
本発明に係る不具合処理分析プログラムは、工程内で扱った物品に不具合が発生したとき、不具合情報の取得から対策完了までに要する工程ごとの標準時間を管理するプログラムであって、コンピュータに、前記物品の固有情報と物品に発生した不具合情報とを含む物品情報を記憶部に記憶するステップと、過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶した記憶部を検索して、対応する標準時間を抽出するステップと、出荷した物品において不具合が発生したときに、既に開梱された当該物品の不具合数と正常数とを記憶した記憶部を検索して、不具合が発生した当該物品の不具合数と正常数とを取得するステップと、前記取得した当該物品の不具合数と正常数とから不具合発生率を求めるとともに、当該物品の未開梱又は輸送中の数量を記憶した記憶部を検索することによって、当該物品全体での不具合規模を算出するステップと、前記算出した当該物品全体の不具合規模に基づいて、当該物品に発生した不具合が重要度としてあらかじめ決定された所定のしきい値を超えたときに、前記標準時間を所定の比率で時間短縮するステップと、を含む処理を実行させることを特徴とする。
【００１９】
また、本発明に係る不具合処理分析プログラムは、コンピュータに、前記時間短縮された標準時間に基づいて、当該物品の不具合発生当日から不具合対策完了目標日までの正常品の在庫推移を算出し、欠品の発生が予測されたときに当該物品の予想在庫数量に基づいて最も輸送コストが最小化されるように補充する物品の輸送手段を選択するステップをさらに実行させることを特徴とする。
【発明の効果】
【００２０】
本発明によれば、不具合発生や不具合処理費用の極小化を図ることができる。
【発明を実施するための最良の形態】
【００２１】
以下、図面を用いて、本発明の好適な実施形態について説明する。本実施形態では、不具合が発生した物品として車両を組み立てるための部品を例示して説明を行っている。
【００２２】
図１は、本実施形態に係る不具合処理分析装置１０における一実施例を示したブロック構成図である。本実施形態における不具合処理分析装置１０は、知的データベース２０、部品仕入先情報データベース２００、品質不具合情報データベース３００、報告遅延標準テーブル６００、経理データベース７００、出荷実績情報データベース８００、不具合価格データベース９００、重要度判断テーブル１０００を有している。また、不具合処理分析装置１０は、データ通信網５０を介して開梱拠点側端末１００、部品製造メーカ側端末４００、品質管理課端末５００と通信を行う。
【００２３】
知的データベース２０は、本実施形態に係る不具合処理分析装置１０の中心的な役割を果たすホストコンピュータであり、各工程との情報の授受を行っているものである。各工程との情報の授受については、その内容や時間等が全て知的データベース２０に記憶されることになる。
【００２４】
開梱拠点側端末１００は、開梱拠点に設置されている端末であり、データ通信網５０を介して知的データベース２０に接続している。この開梱拠点側端末１００は、自らの場所を表すユーザＩＤを有している。したがって、知的データベース２０からユーザＩＤを指定すると、このユーザＩＤに該当する開梱拠点側端末１００から部品の不具合情報を取得することが可能となる。開梱拠点側端末１００には、不具合管理番号、出荷オーダ、部品品番、梱包工場、不具合分類コード、不具合内容、画像データ、音声データ等の情報が部品の不具合情報として登録されている。なお、これらの部品不具合情報は、開梱拠点側端末１００が有する汎用のワープロソフトあるいはＷＥＢ画面上に入力することが可能である。したがって、画像データや音声データ等のデジタルデータについても添付ファイルとして電気通信回線を通じた情報の送信が可能となっている。
【００２５】
部品仕入先情報データベース２００は、過去に発生した部品の不具合情報や過去に不具合を発生させた部品仕入先、部品製造元等の工程に関する情報が登録されている。したがって、知的データベース２０から部品品番、不具合内容をキー項目として部品仕入先情報データベース２００を検索すると、過去に発生した同一又は類似不具合に関する不具合情報とその原因となった部品仕入先、部品製造元等の工程が参照可能となる。ここで、類似不具合とは、例えば、部品品番が部品の種類を表している場合には部品品番の一部が一致するものを類似であるとしても良いし、部品品番が同じでありかつ不具合内容が似ているものを類似としても良い。
【００２６】
品質不具合情報データベース３００は、部品の仕入先情報が登録されているものである。この品質不具合情報データベース３００は、過去に同一の不具合が発生していることが明らかな場合に、その原因となった工程を検索するために用いられるものである。この場合は、知的データベース２０から部品品番をキー項目として品質不具合情報データベース３００を検索し、部品仕入先情報を取得することができる。
【００２７】
部品製造メーカ側端末４００及び品質管理課端末５００は、部品を製造供給している工程に設置されている端末であり、データ通信網５０を介して知的データベース２０に接続している。これらの端末４００，５００は、不具合発生から対策完了報告までの情報通信を知的データベース２０や開梱拠点側端末１００との間で行うことができる。
【００２８】
報告遅延標準テーブル６００は、過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を記憶する装置である。この標準時間は、各工程で非常に細かく設定することが可能であり、例えば、生産工場での不具合原因調査時間や品質検査部門での調査時間等が設定されている。この標準時間は、生産状況や工程人員配置の変動等によって適宜変更可能となっており、過去の実績によって自動的に補正したり、見直し期間を規定して常に適正な時間を設定することが可能となっている。
【００２９】
経理データベース７００は、不具合を発見して損害が発生した開梱拠点側の現地事業体から請求される不具合処理費用を受け付けるとともに、現地事業体に対して不具合処理費用を精算する役目を担っている。不具合処理費用については、開梱側拠点における手直し費用、追加送付部品代金、スクラップ費用、輸送費その他の諸費用等が細かく登録されている。
【００３０】
出荷実績情報データベース８００は、現在までに出荷された部品の出荷実績が記憶されている装置である。この出荷実績情報データベース８００は、部品製造メーカ側端末４００や品質管理課端末５００等からも知的データベース２０を経由して検索可能となっており、例えば、不具合の発生した部品の出荷状況等の情報を部品製造メーカや部品製造工場の窓口部門等で取得することが可能である。また、出荷実績情報には、現時点での出荷部品の状況が含まれており、開梱拠点に在庫として存在しているか否か、あるいは輸送中であるか等の位置情報や、開梱・未開梱等の状態情報を得ることができる。
【００３１】
不具合価格データベース９００は、部品ごとの部品単価や部品を手直ししたり廃却したりする際に発生する費用が記憶されている装置である。この不具合価格データベース９００を参照することによって、不具合が発生した際の損失コストを算出することができる。
【００３２】
各部品においては、部品の要求品質の厳しさに応じて分類された管理グループと、重要度判断のしきい値となる金額と、連続して発生した不具合であるか否かを判断するための連続性判定最低個数とが決められている。重要度判断テーブル１０００は、これらのデータが記憶されている装置である。なお、管理グループの設定は、例えば、エンジンなどの機能部品に対しては最も厳しいグループを設定する等の方法を採用すればよい。
【００３３】
次に、本実施形態における不具合処理分析装置の処理について、図２、図３及び図４に示したフローチャートを用いて具体的に説明する。なお、図２におけるＡは、図３におけるＡに繋がっており、図３におけるＢは、図４におけるＢに繋がっている。すなわち、図２〜図４で本実施形態の一連の処理フローを示している。
【００３４】
物品情報取得部（ステップ１００）
本実施形態では、まず、開梱拠点側端末１００からユーザＩＤごとの部品の固有情報と部品に発生した不具合の不具合情報とを含む部品情報を取得する（ステップ１００）。部品不具合が発生した場合には、開梱拠点側端末１００に現地事業体の担当者によって部品不具合情報が入力されることになる。この部品不具合情報には、出荷オーダ、部品品番、梱包工場、不具合分類コード、不具合内容、画像データ、音声データ等の情報が含まれている。なお、これらの部品不具合情報は、開梱拠点側端末１００が有する汎用のワープロソフトあるいはＷＥＢ画面上に入力することが可能である。したがって、画像データや音声データ等のデジタルデータについても添付ファイルとして電気通信回線を通じた情報の送信が可能となっている。現地事業体の担当者は、部品不具合情報を入力すると知的データベース２０に対してこの情報を送信する。部品不具合情報を取得した知的データベース２０では、ユーザＩＤをキー項目としてこの部品不具合情報を参照することが可能となる。
【００３５】
対策記録部（ステップ１１０〜ステップ２１０）
知的データベース２０では、開梱拠点側端末１００から部品不具合情報を取得すると、この部品不具合情報に対して不具合管理番号、受付時間を付与した上で知的データベース２０に記憶させることになる（ステップ１１０）。
【００３６】
その後、知的データベース２０において同一分類の不具合情報が存在するかを検索する（ステップ１２０）。同一分類の不具合情報が存在する場合には、部品品番をキー項目として品質不具合情報データベース３００を検索し、部品仕入先情報を基に不具合部品を発生させた可能性のある工程を決定する（ステップ１３５）。一方、同一分類の不具合情報が存在しない場合には、部品品番、不具合内容をキー項目として部品仕入先情報データベース２００を検索して過去の類似不具合及び過去の部品仕入先情報を取得し、この工程を不具合部品が発生した可能性のある工程として決定する（ステップ１３０）。なお、過去に類似不具合が全くなかった場合には、対象部品の製造に関わった工程全てを対象とすることになる。
【００３７】
このように不具合原因を発生した可能性があると決定された工程は、知的データベース２０から部品不具合情報を送信されることになる（ステップ１４０）。また、知的データベース２０は、部品不具合情報を送信した日時を記憶する（ステップ１５０）。
【００３８】
続いて、部品不具合情報を受け取った工程は、原因調査のために不具合部品の現品送付及び／又は追加情報が必要であると判断すると（ステップ１６０）、データ通信網５０を介して現品送付及び／又は追加情報の送付依頼を知的データベース２０に対して送信することになる（ステップ１７０）。現品送付及び／又は追加情報の送付依頼を受けた知的データベース２０は、開梱拠点側端末１００に対して現品送付及び／又は追加情報の送付依頼を行う。この際には、送付依頼を行った日付を記憶しておく（ステップ１８０）。開梱拠点側の現地事業体から現品送付及び／又は追加情報の送付を受領すると、知的データベース２０はその日付を記憶するとともに（ステップ１９０）、現品送付及び／又は追加情報の送付を依頼した工程に対して現品及び／又は追加情報を送付する。現品及び／又は追加情報を受領した工程は、データ通信網５０を介して知的データベース２０に受領日を記憶させる（ステップ２００）。
【００３９】
このような情報の遣り取りを経て、原因を発見し対策を実施した工程は、部品不具合調査結果を報告することになる。この場合は、工程側の端末４００，５００からユーザＩＤ、不具合分類コードを大項目として、原因解析結果、解析所要時間、不具合報告書、現地報告者の入力レベル等を知的データベース２０に対して送信することになる（ステップ２１０）。この情報を取得した知的データベース２０は、これまで記憶してきた各工程において不具合情報を取得してからその不具合の対策完了までに要した実時間を基にして、部品不具合の責任割合を算出する（ステップ２１０）。
【００４０】
標準時間記憶部（ステップ２２０）
次に、過去に発生した同一又は類似の不具合に基づいて得られる、不具合情報の取得から対策完了までに要する工程ごとの標準時間を取得する（ステップ２２０）。この標準時間の取得には、これまで不具合対策に関わった工程ごとの標準時間が登録された報告遅延標準テーブル６００を検索する。報告遅延標準テーブル６００には、例えば、生産工場での不具合原因調査時間や品質検査部門での調査時間等が設定されている。
【００４１】
不具合数取得部（ステップ２３０）
開梱拠点ではコンテナ到着順に日々生産に必要な部品を開梱しているが、不具合部品が発見されると、開梱拠点では、開梱拠点側端末１００に対して当日の部品不具合数、部品正常数、出荷オーダ等を不具合管理番号ごとに登録する（ステップ２３０）。なお、開梱拠点側端末１００に入力された当日の部品不具合数、部品正常数、出荷オーダ等の情報は、品質不具合情報データベース３００に記憶され、前日以前の情報に加算されることになる。
【００４２】
不具合規模分析部（ステップ２４０〜ステップ２９０）
不具合を発生させた工程では、部品製造メーカ側端末４００や品質管理課端末５００等から知的データベース２０を経由して品質不具合情報データベース３００を参照し、前日以前の部品不具合数、部品正常数等を取得する（ステップ２４０）。さらに、部品製造メーカ側端末４００や品質管理課端末５００等から知的データベース２０を経由して出荷実績情報データベース８００を参照し、未開梱の部品や輸送中の部品の個数を取得する（ステップ２５０）。この情報の取得は、開梱された出荷オーダと当日までに出荷された出荷オーダとの差から求めることができ、未開梱・輸送中の部品数や部品全体の出荷数量を取得することが可能である。
【００４３】
次に、上記で求めた情報から部品不具合率を計算し（ステップ２６０）、未開梱・輸送中の部品不具合予測数、および部品正常予測数を計算する（ステップ２７０）。なお、部品不具合率は、開梱された出荷オーダにおける部品不具合数の割合から求めることができる。そして、かかる部品不具合率を未開梱・輸送中の部品数に掛け合わせることによって未開梱・輸送中の部品不具合予測数、および部品正常予測数を計算することができる。さらに、これらの結果と、不具合価格データベース９００を参照して求めた部品の不具合単価等を乗ずることにより、不具合予測費用を算出することができる（ステップ２８０）。
【００４４】
一方、ステップ２３０およびステップ２４０で得られた当日および前日以前の不具合部品個数を加えることによって不具合個数実績を計算し（ステップ２７５）、さらに、不具合実績費用を算出する（ステップ２８５）。不具合実績費用は、実績があればその実績値を採用し、現時点で実績値がない場合は不具合価格データベース９００を参照して部品の不具合単価等を取得し、不具合個数実績と不具合単価等を乗ずることによって求めた値を採用しても良い。
【００４５】
以上の処理ステップによって得られた不具合予測費用と不具合実績費用を加えることにより、不具合費用予想総額を算出する（ステップ２９０）。
【００４６】
重要不具合対策部（ステップ３００〜ステップ３０５）
続いて、不具合規模分析部で算出した不具合費用予想総額に基づいて、この部品不具合が重要度の高いものであるか否かを判定する（ステップ３００）。かかる判定は、重要度判断テーブル１０００を参照することによって行う。
【００４７】
重要度判断テーブル１０００には、部品の要求品質の厳しさに応じて分類された管理グループと、重要度判断のしきい値となる金額と、連続して発生した不具合であるか否かを判断するための連続性判定最低個数とが記憶されている。なお、これら管理グループ、金額、連続性判定最低個数は、部品ごとにあらかじめ決定されたものである。
【００４８】
例えば、エンジンなどの機能部品は異音や振動等の品質にかかわる不具合分類コードを厳しいしきい値金額としたり、内装部品は汚れ等の不具合分類コードを厳しいしきい値金額としたりすることによって、部品ごとに重要度の重み付けを変更することが好適である。また、重要部品や高価な部品については、連続性判定最低個数を少なく設定することによって、小さな不具合規模でも重要な問題と位置付けすることが可能である。
【００４９】
なお、日々の不具合の発生状況によっては、最初は重要度が通常ランクであるが、ある日から重要ランクに重要度が昇格する場合が発生し得る。また、逆に重要度が降格する場合も考えられるが、本実施形態では、各工程の関係者に混乱を与える恐れがあるため、重要度ランクを落とさないこととしている。ただし、本発明は、この方法に限定されるものではない。
【００５０】
以上の判定ステップの結果、知的データベース２０が今回発生した部品の不具合を重要不具合と判定すると、報告遅延テーブル６００を参照して得られる対策完了までの標準所要時間が所定の割合で短縮される（ステップ３０５）。例えば、当初の標準所要時間が１０日間であった場合に、一律３０％の時間短縮が実施されることによって、所要時間７日間となることとしても良い。不具合の発生した部品の重要度ランクが昇格し標準所要時間が短縮されると、知的データベース２０は、各工程の担当者や管理部門のマネージャー等に自動でメールを送信し、対策完了までの目標時間が短縮された旨を連絡する。
【００５１】
なお、連続的な不具合は対策を完了するまで不具合が発生し続けるので、当日から短縮された対策完了予定日までに発生するであろう不具合部品の数量を予測し、その数量を加味して時間短縮の割合を決定することも好適である。また、重要度ランクについては、複数ランク設定することが可能である。
【００５２】
部品補充発注部（ステップ３１０〜ステップ３３５）
開梱拠点側では、不具合の発生した部品は基本的に廃却することになるため、代替部品を補充するために追加発注することになる。ここで、海外物流では、運賃の安い船便を用いると発注から１ヶ月乃至数ヶ月間の輸送機関が必要となるため、生産に影響が発生する恐れが生ずる場合がある。このような場合には、輸送期間が短く数日で追加部品を補充することができる航空便を利用することになるのであるが、この場合には船便に対して約１０倍もの運賃が必要となってしまう。
【００５３】
そこで、本処理ステップに係る部品補充発注部では、不具合部品の補充に必要となるコストを最低限に抑制するための処理を行う。
【００５４】
開梱拠点側端末１００では、知的データベース２０を参照することによって、既に不具合個数実績、部品不具合予測数を取得している。また、当日以降から対策完了予定日までの間に発生するであろう不具合部品の数量は予測できるので、開梱拠点側端末１００では、追加発注すべき部品数量を求めることが可能である。
【００５５】
一方、同様にして、開梱済の正常部品数と未開梱・輸送中の部品の正常予測数、対策完了予定日までの正常部品の使用予定数量を求めることも可能である。
【００５６】
以上求めた結果から、当日以降の生産計画より求まる部品の消費予測数量と正常品の使用可能状況、つまり部品の入手予測から正常品の在庫の推移を対策目標日まで推測する（ステップ３１０）。そして、所定の基準から部品の在庫数量が下回らない場合には欠品が発生しないと判断して、追加の発注部品を全数船便で手配することになる（ステップ３２０，ステップ３３０）。逆に、所定の基準から部品の在庫数量が下回る場合には、航空便が必要であると判断して航空便を手配する（ステップ３２０，ステップ３３５）。ただし、航空便での発注は最小限に抑制するべきであるため、例えば、発注単位が「箱」である場合には、１箱から順に船便より航空便に振り替えて上記欠品判断のための計算（ステップ３２０）を、部品の在庫数量が所定の基準から下回らないという結果が出るまで繰り返し行う。このようにすることによって、不具合対策にかかるコストを最小限に抑制することが可能となるのである。
【００５７】
拡大費用算出部（ステップ３４０〜ステップ３７０）
不具合原因の調査と対策が完了すると、開梱側拠点の現地事業体から不具合処理費用の請求が経理データベース７００に対して行われる（ステップ３４０）。不具合処理費用の請求を受けた経理データベース７００は、部品発送費や出荷拠点側の費用を含む不具合処理費用を精算することになる（ステップ３５０）。その後、今回の不具合が連続的な不具合であるか、突発的な不具合であるかを判定する（ステップ３６０）。この判定は、これまで知的データベース２０が取得した部品の不具合情報と不具合原因工程の不具合報告書を基に行われる。連続的な発生であったか、それとも突発的な発生であったかどうかの検証方法としては、不具合発生回数を判定条件にすることができる。例えば、一定期間内で一度も発生したことのない不具合は突発的な発生と判断することができる。この場合は突発的な異常として処理され、不具合処理費用の分担は実施されないことになる。一方、同上の一定期間内に複数回以上もしくは連続的に発生した不具合については慢性的な不具合であると判断され、不具合処理費用の分担が検討されることになる。
【００５８】
発生した不具合が連続的であると判定されると、対策遅延によって拡大した不具合に基づいて増加した不具合処理費用が拡大費用として算出される（ステップ３７０）。
【００５９】
責任割合分析部（ステップ３８０〜ステップ３９５）
続いて、工程ごとで要した実時間とその工程に対応する標準時間とに基づいて、対策遅延によって拡大した不具合に対する工程ごとの責任割合を分析する。まず、工程ごとに要した実時間からその工程に対応する標準時間を差し引くことによって、工程ごとの遅延時間を算出する（ステップ３８０）。この算出結果に対して調整が必要であるかどうかを判断し（ステップ３９０）、調整が必要な場合は個別事情に合わせて調整を実施する（ステップ３９５）。この個別事情とは、例えば、台風による水害など自然災害等を考慮するなど、予め条件設定をしておくことが可能である。
【００６０】
このような処理を行うことによって、工程ごとの対策遅延による責任割合を明確にすることができる。例えば、開梱拠点側現地事業体の責任割合が１０％、原因工程の責任割合が１５％、品質検査工程の責任割合が５％、という具合に表現される。
【００６１】
分担費用算出部（ステップ４００）
最後に、前述した責任割合分析部（ステップ３８０〜ステップ３９５）において分析した責任割合と拡大費用算出部（ステップ３４０〜ステップ３７０）において算出した不具合処理費用に基づいて工程ごとの分担費用を算出し、各工程に対して分担費用を請求する（ステップ４００）。
【００６２】
なお、以上の処理は、不具合部品の発見から不具合解析までにかかった時間のうち、開梱拠点側の現地事業体責任分、受付側責任分、不具合発生側責任分を不具合の項目ごとに分類し、それぞれ不具合の項目ごとに輸送機関等を考慮した標準時間という一定の報告遅延許容枠を設け、その許容枠を超えた部分に対して不具合発生から対策完了までに標準時間を超えたことによって余分にかかった不具合費用を、遅延した工程ごとに負担するよう責任割合を重み付け計算するものである。本実施形態に係る不具合処理分析装置及び方法を採用することによって、責任の所在の明確化を図ることができるので、各工程に当事者意識が芽生え、結果として不具合品及び不具合処理費用の極小化を図ることが可能となるのである。
【００６３】
また、本実施形態では、物品情報取得部、対策記録部、標準時間記憶部、不具合数取得部、不具合規模分析部、重要不具合対策部、部品補充発注部、拡大費用算出部、責任割合分析部、分担費用算出部という個別の記憶部を知的データベース２０内に設けた場合を例示しているが、同一の記憶部を設けて同じ働きをさせることも可能である。また、本実施形態に係る不具合処理分析方法については、バードウエアと協働したものであっても、ソフトウエアとして実現されるものであっても良いことはいうまでもない。
【００６４】
以上のように、本実施形態によれば、日々不具合が発生した部品の数量を入手し、その内容について不具合対策を実施する工程に対して「金額」等の指標で提示することによって、不具合による損失コストを可視化し、不具合に対する発生防止や早期解決への意識付けが行われる。また、重要不具合については不具合対策の完了目標日を短縮するので、不具合処理費用の極小化を図ることが可能となる。さらに、不具合が発生した部品の補充については、在庫推移を予測して、最小の物流コストとなるように輸送手段を選択することができるので、不具合処理費用の極小化を図ることが可能となる。
【図面の簡単な説明】
【００６５】
【図１】本実施形態に係る不具合処理分析装置における一実施例を示したブロック構成図である。
【図２】本実施形態に係る不具合処理分析装置の処理を示すフローチャートである。
【図３】本実施形態に係る不具合処理分析装置の処理を示すフローチャートである。
【図４】本実施形態に係る不具合処理分析装置の処理を示すフローチャートである。
【符号の説明】
【００６６】
１０  不具合処理分析装置、２０  知的データベース、５０  データ通信網、１００  開梱拠点側端末、２００  部品仕入先情報データベース、３００  品質不具合情報データベース、４００  部品製造メーカ側端末、５００  品質管理課端末、６００  報告遅延標準テーブル、７００  経理データベース、８００  出荷実績情報データベース、９００  不具合価格データベース、１０００  重要度判断テーブル。
【図１】
2005128752.tif 000003
【図２】
2005128752.tif 000004
【図３】
2005128752.tif 000005
【図４】
2005128752.tif 000006