JP6142881B2 - 不具合通知システム、不具合通知方法、不具合通知装置、不具合通知プログラム及び記録媒体 - Google Patents

Description

本発明は、不具合通知システム、不具合通知装置及び不具合通知プログラムに関する。

製品を販売する業務において、製品に不具合が発生した場合の対応は製品や企業に対する信頼性を維持する上で重要な業務である。そのような業務の支援のため、商品やサービス等に対する改善要求が寄せられた場合に、迅速かつ的確に要求に対応するためのシステムが提案されている（例えば、特許文献１参照）。

製品に発生する不具合は、規則性のない突発的なものや、共通する原因に基づいて発生する多発的なものがある。そして、共通する原因に基づいて発生する不具合については、可能な限り早期に原因を突き止めて対応する必要がある。特許文献１に開示された技術は、寄せられた要望に対する対応の迅速、的確性を意図しており、発生した不具合の原因の追究に効果の得られるものではない。

例えば、製品に用いられている部品毎の不具合の発生頻度の解析や、製品や部品のロット毎の不具合の発生頻度の解析等、不具合の発生状況を様々な視点で解析することにより、共通する原因に基づいて発生する不具合を突き止めることが可能である。しかしながら、取り扱っている製品や部品が膨大な量となると、上述したような解析において対象となる情報量が膨大なものとなり、それらの情報を定期的に解析する処理が非現実的な処理となってしまう。

本発明は、このような課題を解決するためになされたものであり、製品やそれを構成する部品についての不具合の発生傾向を掴むためのデータ解析を効率的に行うことを目的とする。

上記課題を解決するために、本発明の一態様は、 出荷された製品について発生した不具合に関する情報である不具合情報に基づいて不具合の傾向を分析して通知を行う不具合通知システムであって、前記不具合情報を蓄積管理している不具合情報管理部から、新たに発生した不具合に関する不具合情報を取得して記憶媒体に記憶させる不具合情報取得部と、前記不具合情報取得部により取得され前記記憶媒体に新規に記憶される前記不具合情報を、６ヶ月あるいは約６ヶ月である保存期間で前記記憶媒体に保存する不具合情報削除部と、前記記憶媒体に保存されている前記不具合情報に基づき、前記保存期間の期間内に、同一の製品あるいは部品に係る不具合の発生回数が、２あるいは約２以上であるか否かを判断する解析対象判断部と、前記解析対象判断部により、前記保存期間における前記不具合の発生回数が、２あるいは約２以上発生していると判断された製品あるいは部品があった場合に、当該製品あるいは部品を対象に、前記不具合情報管理部において管理されている前記不具合情報に基づき複数の解析方法により解析して得られる複数の解析結果を取得する解析結果取得部と、前記複数の解析結果について夫々設定された閾値と前記複数の解析結果とを夫々比較する閾値判断部と、前記解析結果と前記閾値との比較結果に基づき、前記閾値を超えた前記解析結果に関する通知先に対して通知を行う通知処理部と、を含むことを特徴とする。

本発明によれば、製品やそれを構成する部品についての不具合の発生傾向を掴むためのデータ解析を効率的に行うことができる。

本発明の実施形態に係るシステムの運用形態を示す図である。 本発明の実施形態に係る情報処理装置のハードウェア構成を示すブロック図である。 本発明の実施形態に係るデータ解析サーバの機能構成を示すブロック図である。 本発明の実施形態に係る苦情データＤＢ及びキーレコードＤＢの内容例を示す図である。 本発明の実施形態に係る解析処理の内容を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る解析結果の表示例を示す図である。 本発明の実施形態に係る閾値設定画面の例を示す図である。 本発明の実施形態に係る不良部品一覧画面の例を示す図である。 本発明の実施形態に係るシステムの動作を示すシーケンス図である。 本発明の実施形態に係る出荷データの例を示す図である。 本発明の実施形態に係るデータ解析動作を示すフローチャートである。 本発明の実施形態に係る解析対象の判断動作を示すフローチャートである。 本発明の実施形態に係る閾値超過通知の内容を示す図である。 本発明の実施形態に係る通知先データを示す図である。 本発明の実施形態に係る通知先データを示す図である。 本発明の実施形態に係る部品構成データを示す図である。 本発明の実施形態に係る解析結果のデータの例を示す図である。

以下、図面を参照して、本発明の実施形態について説明する。本実施形態においては、製品に発生した不具合に基づいて寄せられる苦情のデータを解析し、今後発生する可能性のある苦情を予測して早期に警告を発するシステムについて説明する。換言すると、本実施形態に係るシステムは、製品などの不具合を通知する不具合通知システムである。そのようなシステムにおいて、解析するべきデータ量を可能な限り低減すると共に、警告の精度を向上することが本実施形態に係る要旨の１つである。

図１は、本実施形態に係る品質情報システムの運用形態を示す図である。図１に示すように、本実施形態に係るシステムは、データ解析サーバ１、苦情データサーバ２、出荷データサーバ３及び複数の担当者端末４ａ、４ｂを含む。

データ解析サーバ１は、本実施形態の要旨に係る機能を実現するサーバであり、出荷データサーバ３及び苦情データサーバ２に夫々蓄積される情報に基づき、製品やそれに用いられている部品についての不具合の発生傾向を把握するための情報解析を行う。そして、同一原因に基づく多発的な不具合の発生が認められた場合に、その原因に応じた通知先に不具合発生の通知を行う。その際に、実際の不具合の発生状況に基づいて解析対象の情報を絞り込むことが本実施形態に係る要旨の１つである。即ち、データ解析サーバ１が不具合通知装置措定機能し、そのような機能を実現するためのプログラムが不具合通知プログラムである。

苦情データサーバ２は、製品に対して寄せられた苦情のデータが逐次蓄積される苦情データＤＢを運用するサーバである。苦情データＤＢの情報が、製品について発生した不具合に関する不具合情報であり、苦情データサーバ２の苦情データＤＢが不具合情報を管理している不具合情報管理部である。出荷データサーバ３は、製品の出荷状況を示す出荷データが逐次蓄積されるサーバである。担当者端末４ａ、４ｂは、データ解析サーバ１による解析の結果、今後発生する可能性のある苦情の警告通知を受ける担当者が操作する情報処理端末である。

ここで、本実施形態に係るデータ解析サーバ１、苦情データサーバ２、出荷データサーバ３及び担当者端末４ａ、４ｂ等の情報処理装置のハードウェア構成について図２を参照して説明する。図２に示すように、本実施形態に係る情報処理装置は、一般的なサーバやＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等と同様の構成を含む。即ち、本実施形態に係る情報処理装置は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２０、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３０、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）４０及びＩ／Ｆ５０がバス８０を介して接続されている。また、Ｉ／Ｆ５０にはＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）６０及び操作部７０が接続されている。

ＣＰＵ１０は演算手段であり、情報処理装置全体の動作を制御する。ＲＡＭ２０は、情報の高速な読み書きが可能な揮発性の記憶媒体であり、ＣＰＵ１０が情報を処理する際の作業領域として用いられる。ＲＯＭ３０は、読み出し専用の不揮発性記憶媒体であり、ファームウェア等のプログラムが格納されている。ＨＤＤ４０は、情報の読み書きが可能な不揮発性の記憶媒体であり、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）や各種の制御プログラム、アプリケーション・プログラム等が格納される。

Ｉ／Ｆ５０は、バス８０と各種のハードウェアやネットワーク等を接続し制御する。ＬＣＤ６０は、ユーザが情報処理装置の状態を確認するための視覚的ユーザインタフェースである。操作部７０は、キーボードやマウス等、ユーザが情報処理装置に情報を入力するためのユーザインタフェースである。尚、本実施形態に係るデータ解析サーバ１、苦情データサーバ２及び出荷データサーバ３は、ユーザが直接操作することの無いサーバとして運用されるため、ＬＣＤ６０や操作部７０等のユーザインタフェースは省略可能である。

このようなハードウェア構成において、ＲＯＭ３０に格納されたプログラムや、ＨＤＤ４０若しくは図示しない光学ディスク等の記憶媒体からＲＡＭ２０にロードされたプログラムに従ってＣＰＵ１０が演算を行うことにより、ソフトウェア制御部が構成される。このようにして構成されたソフトウェア制御部と、ハードウェアとの組み合わせによって、本実施形態に係るデータ解析サーバ１等の機能を実現する機能ブロックが構成される。

次に、本実施形態に係るデータ解析サーバ１の機能構成について図３のブロック図を参照して説明する。図３に示すように、本実施形態に係るデータ解析サーバ１は、データ解析コントローラ１００及びネットワークＩ／Ｆ１１０を含む。また、データ解析コントローラ１００は、情報取得部１０１、キーレコードＤＢ１０２、データ解析部１０３、解析結果ＤＢ１０４、閾値判断部１０５、アラート部１０６及び表示制御部１０７を含む。

情報取得部１０１は、データ解析サーバ１の動作において必要な情報をネットワークＩ／Ｆ１１０を介して取得する。データ解析サーバ１の動作において必要な情報は、例えば出荷データサーバ３に蓄積された出荷データや、苦情データサーバ２に蓄積された苦情データＤＢの情報である。

キーレコードＤＢ１０２は、情報取得部１０１が取得した情報のうち、苦情データＤＢの情報を記憶する。本実施形態においては、苦情データサーバ２に新規な苦情のデータが格納されてから６か月間、その苦情のデータがキーレコードＤＢ１０２に保存される。キーレコードＤＢ１０２に格納されたデータがトリガとなり、共通する原因に基づいて多発的に発生する不具合の傾向を掴むためのデータ解析が行われる。

図４は、キーレコードＤＢ１０２の内容を示す図である。上述した通り、キーレコードＤＢ１０２の内容は苦情データＤＢの内容がコピーされたものであるため、苦情データＤＢにも図４に示す内容と同様の情報が含まれる。図４に示すように、キーレコードＤＢ１０２は、“ＩＤ”、“登録日”、“製品シリーズ”、“製品名”、“保存期限”、“納入先”、“製造年月日”、“製品ロット”、“出荷日”、“発生日”、“発生状況”、“不具合内容”、“責任区分”、“部品名”、“現象”、“原因”、“部品ロット”、“メーカー名”の情報を含む。

“ＩＤ”は、夫々の苦情のレコードを識別する識別子である。“登録日”は、夫々のレコードがデータベースに登録された年月日である。“製品シリーズ”は、不具合の発生した製品が属するシリーズの名称である。“製品名”は、不具合の発生した製品の名称である。“保存期限”は、夫々のレコードがキーレコードＤＢ１０２に保存される期限を示す年月日である。

本実施形態に係るキーレコードＤＢ１０２に一度登録されたレコードが保存される期間が原則として６か月である。即ち、新たに苦情のデータが苦情データＤＢに登録されてキーレコードＤＢ１０２にコピーされると、そこから６か月間、そのレコードに係る製品等は上述したデータ解析の対象となる。この期間は、例えば担当者端末４ａ、４ｂを操作する担当者の手動操作によって変更可能であっても良い。

“納入先”は、不具合が発生した製品を納入した納入先、即ち客先を示す情報である。“製造年月日”は、不具合が発生した製品の製造年月日である。“製品ロット”は、不具合が発生した製品のロットを示す情報であり、一般的にはロットナンバーが用いられる。“出荷日”は、不具合が発生した製品が出荷された年月日である。“発生日”は、不具合が発生した日の年月日である。

“発生状況”は、夫々のレコードを登録するオペレータによって手動で入力される文字情報であり、発生した不具合が説明された情報である。“不具合内容”は、発生した不具合の内容に応じて、「不具合Ａ」、「不具合Ｂ」、「不具合Ｃ」のように選択される情報であり、不具合をカテゴリ分けするためのカテゴリを示す情報である。

“責任区分”は、発生した不具合の原因が自社組織の「内部」にあるのか「外部」にあるのかを示す情報である。“部品名”は、発生した不具合の原因となった部品の名称である。“現象”は、不具合の内容が確認され、その結果が「現象Ａ」、「現象Ｂ」、「現象Ｃ」のようにカテゴリ分けされて登録された情報である。“原因”は、不具合の内容が確認された結果、その原因が文字情報によって入力された情報である。

“部品ロット”は、不具合の原因となった部品のロットを示す情報である。“メーカー名”は、不具合の原因となった部品を供給しているメーカーの名称である。このように、本実施形態に係るキーレコードＤＢ１０２においては、製品に不具合が発生して寄せられた苦情毎に、情報が登録されている。

図４に示す情報のうち、“ＩＤ”から“不具合内容”までの項目は、苦情データサーバ２において苦情データＤＢにレコードが生成された際に入力される情報である。他方、“責任区分”から“メーカー名”までの情報は、登録されたレコードについての苦情対応が行われ、原因となった部品や現象が判明した後に追加で入力される情報である。

従って、“責任区分”から“メーカー名”までの情報は、キーレコードＤＢ１０２の情報が苦情データＤＢの情報に基づいて定期的に更新されることにより、苦情データＤＢにおいて情報が登録された後にキーレコードＤＢ１０２に登録される。

データ解析部１０３は、キーレコードＤＢ１０２に登録されているレコードにおいて対象となっている製品や部品について、ネットワークＩ／Ｆ１１０を介して苦情データＤＢから元のデータを取得して不具合の発生傾向の解析を行う。データ解析部１０３は、キーレコードＤＢ１０２に登録されているレコードのうち、同一の製品または部品を対象とするレコードが所定数以上ある場合に、その製品や部品についての解析を行う。本実施形態に係る所定数は“２”である。

データ解析部１０３によるデータ解析によって生成された解析結果の情報は解析結果ＤＢ１０４に格納される。このように、データ解析部１０３は、苦情データＤＢに格納されている全苦情データに基づいて不具合の発生傾向を解析する機能を有する。その際、キーレコードＤＢ１０２に登録されている情報に基づき、膨大な量の製品や部品のうち、どの製品、部品についての解析を行うか決定する。即ち、データ解析部１０３による、キーレコードＤＢ１０２に登録されている情報に基づいた解析対象の判断処理が本実施形態に係る要旨である。

図５は、データ解析部１０３によって行われるデータ解析方法の一覧を示す図である。“出荷数−不良数 製品毎解析”は、データ解析の対象となった製品夫々について、出荷数及び不良数を計算する解析処理である。図６は、“出荷数−不良数 製品毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“出荷数−不良数 製品毎解析”の解析処理により、図６に示すようなグラフを表示するための情報を生成して解析結果ＤＢ１０４に記憶させる。

“出荷数−不良率 製品毎解析”は、データ解析の対象となった製品夫々について、出荷数に対する不良数の割合である不良率を計算する解析処理である。図７は、“出荷数−不良率 製品毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“出荷数−不良率 製品毎解析”の解析処理により、図７に示すようなグラフを表示するための情報を生成して解析結果ＤＢ１０４に記憶させる。

“不良数 製造年月毎解析”は、データ解析の対象となった製品、部品夫々について、製造年月毎の不良数を計算する解析処理である。ここでいう不良数とは、苦情データＤＢに登録されているレコード数である。図８は、ある一つの製品若しくは部品について、“不良数 製造年月毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“不良数 製造年月毎解析”の解析処理により、図８に示すようなグラフを表示するための情報を夫々の製品、部品毎に生成して解析結果ＤＢ１０４に記憶させる。

“不良数 発生年月毎解析”は、データ解析の対象となった製品、部品夫々について、不具合の発生年月毎の不良数を計算する解析処理である。図９は、ある一つの製品若しくは部品について、“不良数 発生年月毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“不良数 発生年月毎解析”の解析処理により、図９に示すようなグラフを表示するための情報を夫々の製品、部品毎に生成して解析結果ＤＢ１０４に記憶させる。

“不良数 製品ロット毎解析”は、データ解析の対象となった製品夫々について、製品ロット毎の不良数を計算する解析処理である。図１０は、“不良数 製品ロット毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“不良率 製品ロット毎解析”の解析処理により、図１０に示すようなグラフを表示するための情報を製品毎に生成して解析結果ＤＢ１０４に記憶させる。

“不良数 部品ロット毎解析”は、データ解析の対象となった部品夫々について、部品ロット毎の不良数を計算する解析処理である。図１１は、“不良数 部品ロット毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“不良数 部品ロット毎解析”の解析処理により、図１１に示すようなグラフを表示するための情報を部品毎に生成して解析結果ＤＢ１０４に記憶させる。

“不良数 部品毎解析”は、データ解析の対象となった部品毎に、不良数を計算する解析処理である。図１２は、“不良数 部品毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“不良数 部品毎解析”の解析処理により、図１２に示すようなグラフを表示するための情報を生成して解析結果ＤＢ１０４に記憶させる。

“出荷数−不良数 客先毎解析”は、データ解析の対象となった製品について、客先毎の出荷数及び不良数を計算する解析処理である。ここでいう客先とは、図４に示す“納入先”である。図１３は、“出荷数−不良数 客先毎解析”の解析結果に基づいて表示されるグラフを示す図である。即ち、データ解析部１０３は、“出荷数−不良数 客先毎解析”の解析処理により、図１３に示すようなグラフを表示するための情報を生成して解析結果ＤＢ１０４に記憶させる。

閾値判断部１０５は、解析結果ＤＢ１０４に記憶された解析結果の情報に基づき、不具合の発生状況がアラートを発するべき状況であるか否かを判断する。そのため、閾値判断部１０５は、図６〜図１３に示すような解析結果の情報に対して設定された閾値の情報を記憶しており、解析結果の値と対応する閾値とを比較することにより、アラートの要否を判断する。

例えば、“出荷数−不良数 製品毎解析”の解析結果の場合、図６に示すように表示される解析結果の値のうち、折れ線グラフで示される不良数の値に対して閾値が設定される。そして、閾値判断部１０５は、不良数の値が、それに対応して設定された閾値よりも大きい場合に、アラートが必要であると判断する。

閾値判断に基づいてアラートが必要であると判断した閾値判断部１０５は、アラート部１０６に対してアラート通知を行い、アラート部１０６にアラート処理を実行させる。アラート部１０６は、閾値判断部１０５から取得したアラート通知に基づき、ネットワークＩ／Ｆ１１０を介してアラート処理を行う通知処理部である。

表示制御部１０７は、担当者端末４ａ、４ｂ等のオペレータによって操作される情報処理端末からのデータ解析サーバ１に対するウェブアクセスに応じて、情報処理端末に表示させるための表示情報を送信して応答する。例えば、閾値判断部１０５において設定される上述した閾値は、データ解析サーバ１に対するウェブアクセスによって外部のオペレータにより実行される。その際、表示制御部１０７は、図１４に示すような閾値設定画面を表示するための情報をウェブアクセスに応じて送信する。

図１４に示すように、本実施形態に係る閾値設定画面においては、図５において説明した夫々の解析方法毎の閾値の設定値や、夫々のデータ解析方法の有効／無効の設定値等がオペレータによって入力される。図１４に示す閾値設定画面においてオペレータにより情報が入力されて確定操作が行われると、設定された閾値の情報や、有効／無効の設定値が、オペレータが操作している情報処理端末からデータ解析サーバ１に対して送信される。これにより、表示制御部１０７を介して閾値判断部１０５に情報が入力され、閾値判断部１０５が記憶している各データ解析方法の閾値の設定値や、有効／無効の設定値が更新される。

また、図１５は、表示制御部１０７によって表示情報が提供される画面のうち、キーレコードＤＢ１０２に記憶されているレコードに基づいて表示される不良部品一覧画面を示す図である。不良部品一覧画面においては、図１５に示すように、キーレコードＤＢ１０２に記憶されているレコードが“製品名”及び“部品名”の組み合わせ毎に集計され、その件数が“過去発生件数”として表示される。

“過去発生件数”のフィールド値はリンクとなっており、夫々のフィールド値がクリックされると、そのフィールドが属するレコードにおいて集計対象となっているキーレコードＤＢ１０２に記憶されたレコードの一覧画面が表示される。その一覧画面において表示されるのは、図４に示すようなキーレコードＤＢ１０２に登録されているレコードの一覧画面である。

その場合、フィールド値がクリックされることにより、オペレータが操作する端末は、クリックされたフィールド値が属するレコードにおいて集計対象となっている製品及び部品を示す情報をデータ解析サーバ１に対して送信することにより一覧表示の要求を行う。データ解析サーバ１においては、表示制御部１０７がその要求に関する情報を受け取り、キーレコードＤＢ１０２から該当するレコードを抽出して要求元の端末に送信することにより応答する。

また、不良部品一覧画面においては、図１５に示すように、夫々の集計結果に対して“分析表示”と示された分析表示ボタンが表示されている。この分析表示ボタンがクリックされた場合、対応する集計結果において集計対象となっている製品及び部品についての図６〜図１３に示すような解析結果の画面が表示される。

その場合、分析表示ボタンがクリックされることにより、オペレータが操作する端末は、クリックされたフィールド値が属するレコードにおいて集計対象となっている製品及び部品を示す情報をデータ解析サーバ１に対して送信することにより分析表示の要求を行う。データ解析サーバ１においては、表示制御部１０７がその要求に関する情報を受け取り、解析結果ＤＢ１０４から該当する解析結果の情報を抽出して要求元の端末に送信することにより応答する。

次に、本実施形態に係るシステムの動作について説明する。図１６は、本実施形態に係るシステムにおいて、定期的に実行される処理（以降、「バッチ処理」とする）の動作を示すシーケンス図である。図１６に示すバッチ処理は、例えば深夜の時間帯において定められたタイミングで毎日実行される。このような時間帯であれば、苦情データサーバ２や出荷データサーバ３の負荷が一般的に低いため、本実施形態に係るシステムに関する処理が通常のサーバ運用に支障をきたすことを防ぐことが出来る。

図１６に示すように、まずはデータ解析サーバ１が出荷データサーバ３に対して出荷データを要求する（Ｓ１６０１）。出荷データサーバ３は、データ解析サーバ１からの要求に応じて出荷データをデータ解析サーバ１に送信する（Ｓ１６０２）。図１７は、Ｓ１６０２において送信される出荷データの一例を示す図である。

図１７に示すように、本実施形態に係る出荷データは、“製品名”、“出荷先”、“出荷日”、“出荷数”の情報が関連付けられた情報である。Ｓ１６０２において、出荷データサーバ３は、前回データ解析サーバ１に対して出荷データを送信してから新たに蓄積された出荷データを抽出して送信する。

図１７に示すような出荷データを出荷データサーバ３から取得したデータ解析サーバ１は、取得した出荷データを苦情データサーバ２に送信して登録する（Ｓ１６０３）。これにより、苦情データサーバ２に最新の出荷データが登録され、図６、図７に示すような出荷数のデータ解析が可能となる。

出荷データの登録を行うと、次にデータ解析サーバ１は、苦情データサーバ２に対して、苦情データＤＢに新規に登録されたレコードや更新されたレコードを要求する（Ｓ１６０４）。新規・更新レコードの要求に応じて、苦情データサーバ２は、最後にデータ解析サーバ１に苦情データＤＢの情報を送信してから新たに追加されたレコードや更新されたレコードをデータ解析サーバ１に送信する（Ｓ１６０５）。

苦情データサーバ２から新規・更新レコードを受信したデータ解析サーバ１においては、情報取得部１０１がその情報を取得し、キーレコードＤＢ１０２に登録する（Ｓ１６０６）。この際、新規レコードは新規レコードとして、更新レコードは、既存のレコードを更新するように登録する。このような処理により、情報取得部１０１が不具合情報取得部として機能する。

新規・更新レコードの登録が完了すると、データ解析部１０３がキーレコードＤＢ１０２に記憶されている情報に基づいて、図５に示すようなデータの解析処理を行う（Ｓ１６０７）。これにより、図６〜図１３において説明したような各種の解析結果の情報が解析結果ＤＢ１０４に記憶される。Ｓ１６０７の処理の詳細については後述する。

データ解析処理が完了すると、閾値判断部１０５が解析結果ＤＢ１０４に記憶された解析結果の情報に基づいて閾値判断を行い、アラート部１０６がその判断結果に基づいてアラート処理を行う（Ｓ１６０８）。その後、データ解析部１０３は、キーレコードＤＢ１０２に記憶されているレコードの削除処理を行う（Ｓ１６０９）。

Ｓ１６０９において、データ解析部１０３は、図４において説明した“保存期限”に基づいて削除処理を行う。即ち、夫々のレコードにおける“保存期限”の値が、Ｓ１６０９の処理を実行している当時の年月日に到達していれば、そのレコードを削除する。即ち、Ｓ１６０９においてはデータ解析部１０３が不具合情報削除部として機能する。このような処理により、本実施形態に係るシステムのバッチ処理が完了する。

次に、Ｓ１６０７における解析処理及びＳ１６０８におけるアラート処理について、図１８を参照して詳細に説明する。図１８に示すように、データ解析部１０３はキーレコードＤＢ１０２に登録されているレコードのうち、図１６のＳ１６０６において登録された新規レコード若しくは更新レコードを１つ選択する（Ｓ１８０１）。そして、選択したレコードが解析対象であるか否かを判断する（Ｓ１８０２）。

ここで、Ｓ１８０２における判断処理について図１９を参照して説明する。図１９を示すように、データ解析部１０３は、Ｓ１８０１にて選択したレコードと“製品名”、“部品名”の少なくともいずれかが一致する他のレコードを検索する（Ｓ１９０１）。Ｓ１９０１の検索の結果、“製品名”、“部品名”の少なくともいずれかが一致する他のレコードがあった場合（Ｓ１９０２／ＹＥＳ）、データ解析部１０３は、選択中のレコードの“製品名”若しくは“部品名”が解析対象であると判断する。

このようにして判断されたレコードが解析対象情報であり、データ解析部１０３は、このような解析対象情報に関する情報として、“製品名”若しくは“部品名”が解析対象情報と一致する過去のレコードを取得する。

尚、Ｓ１９０３において解析対象として判断されるのは、Ｓ１９０２において“製品名”が一致する他のレコードが抽出された場合には、“製品名”であり、Ｓ１９０２において“部品名”が一致する他のレコードが抽出された場合には、“部品名”である。また、“製品名”、“部品名”のいずれについても一致する他のレコードが抽出された場合には、“製品名”、“部品名”の両方が解析対象として判断される。他方、Ｓ１９０１の検索の結果一致する他のレコードが抽出されなかった場合（Ｓ１９０２／ＮＯ）、データ解析部１０３は、選択中のレコードは非解析対象であると判断する（Ｓ１９０４）。

このように、本実施形態に係るデータ解析部１０３は、同一の“製品名”若しくは“部品名”についてのレコードが、キーレコードＤＢ１０２に２つ以上記憶されている場合に、その“製品名”若しくは“部品名”を解析対象として判断する。このような処理により、単発的に発生した不具合を解析対象から除外することが出来る。尚、この時の“２つ”という条件は一例であり、３つ以上、即ち、同一対象についての複数の苦情データがキーレコードＤＢ１０２に記憶されていれば良い。

また、毎回のバッチ処理においてデータ解析が行われ、その結果が解析結果ＤＢ１０４に格納されている。そのため、解析処理を行って新たな解析結果を得る必要があるのは、新規レコード若しくは更新レコードが解析対象として含まれる場合のみである。Ｓ１８０１においては、新規レコード若しくは更新レコードのみを対象としており、これにより、新規レコード若しくは更新レコードが解析対象として含まれる場合のみを、解析対象とすることが出来る。

選択中のレコードが解析対象であると判断した場合（Ｓ１８０２／ＹＥＳ）、データ解析部１０３は、苦情データサーバ２の苦情データＤＢから、解析対象となる製品、若しくは部品についての過去のレコードを取得する（Ｓ１８０３）。Ｓ１８０３において取得される過去データのキーは、図１９において説明した動作によって定まる。

即ち、“製品名”が一致する他のレコードが抽出された場合、上述したように解析対象は“製品名”であるため、Ｓ１８０３においてデータ解析部１０３は、対象となる“製品名”についての過去のレコードを取得する。他方、“部品名”が一致する他のレコードが抽出された場合、上述したように解析対象は“部品名”であるため、Ｓ１８０３においてデータ解析部１０３は、対象となる“部品名”についての過去のレコードを取得する。

また、上述したように“製品名”、“部品名”の両方が解析対象である場合、Ｓ１８０３においてデータ解析部１０３は、対象となる“製品名”、“部品名”についての過去のレコードを取得する。このようにして解析対象となる過去のレコードを取得すると、データ解析部１０３は、図６〜図１３において説明したような解析結果を得るためのデータ解析を実行する（Ｓ１８０４）。

Ｓ１８０４におけるデータ解析処理も、上述した解析対象に基づいて実行される。“製品名”が解析対象である場合、データ解析部１０３は、図６、図７、図８、図９、図１０に示す解析結果を得るためのデータ解析を行う。他方、“部品名”が解析対象である場合、データ解析部１０３は、図９、図１１、図１２、図１３に示す解析結果を得るためのデータ解析を行う。また、“製品名”、“部品名”の両方が解析対象である場合、図６〜図１３全ての解析結果を得るためのデータ解析を行う。

データ解析を完了したデータ解析部１０３は、解析結果を解析結果ＤＢ１０４に格納する（Ｓ１８０５）。即ち、データ解析部１０３が、解析結果の情報を取得して記憶媒体に記憶させる解析結果取得部として機能する。他方、Ｓ１８０２の判断の結果、解析対象ではなかった場合（Ｓ１８０２／ＮＯ）、Ｓ１８０３〜Ｓ１８０５の処理を省略する。

データ解析部１０３は、Ｓ１８０１からの処理を、全ての新規レコード若しくは更新レコードについて完了するまで繰り返す（Ｓ１８０６／ＮＯ）。そして、データ解析部１０３が、全ての新規レコード若しくは更新レコードについて完了すると（Ｓ１８０６／ＹＥＳ）、閾値判断部１０５が、更新された解析結果について閾値判断処理を行う（Ｓ１８０７）。

Ｓ１８０７において、閾値判断部１０５は、図１４に示すような画面において夫々設定された閾値と、図６〜図１３に示すような解析結果とを比較する。例えば、“出荷数−不良数 製品毎解析”の場合、図６に示すような製品毎の不良数を夫々参照し、設定された閾値を超えている値の有無を確認する。

閾値判断の結果、閾値を超えている解析結果がある場合（Ｓ１８０８／ＹＥＳ）、閾値判断部１０５は、閾値超過に関する情報をアラート部１０６に通知する。これにより、アラート部１０６がアラート処理を行う（Ｓ１８０９）。ここで、閾値判断部１０５がアラート部１０６に通知する閾値超過に関する情報について、図２０を参照して説明する。

図２０に示すように、閾値超過通知の情報は、“解析対象項目”、“解析対象”、“解析方法”、“閾値超過対象”の情報を含む。“解析対象項目”は、図１９の処理によって判定された解析対象が“製品名”であるか“部品名”であるかを示す情報であり、図２０の例においては“製品名”である。

“解析対象”は、図１９の処理によって判定された解析対象、即ち、図１９のＳ１９０２において一致レコードがあると判断された対象を示す情報であり、図２０の例においては、“製品１”である。“解析方法”は、図５に示す各種の解析方法のうち、閾値超過が判定された解析結果に係る解析方法を示す情報である。図２０の例においては、“不良数 製品ロット毎解析”である。

“閾値超過対象”は、閾値を超過した対象のパラメータを示す情報である。“不良数 製品ロット毎解析”の場合、解析結果は図１０に示すようなグラフが描画されるデータとなる。そして、夫々の製品ロット毎の不良数が閾値と比較される。図２０の例においては、そのような閾値判断の結果、“ロット１”の不良数が閾値を超えた場合を示している。

図２０に示すような閾値超過通知を受けたアラート部１０６は、Ｓ１８０９において、まず“解析対象”の情報に基づいてアラートの送信先を決定する。そのため、アラート部１０６は、図２１、図２２に示すような、“製品名”、“部品名”が“通知先アドレス”と関連付けられた情報を保持している。そして、“解析対象”の情報で指定されている“製品名”若しくは“部品名”に関連付けられた“通知先アドレス”を、アラートの送信先として決定する。

アラート部１０６は、このようにして決定した通知先に対して、図２０に示すようなアラート情報を送信する。これにより、“製品名”や“部品名”に関連付けられた担当者に対して、共通の原因により多発的に発生している可能性のある不具合が通知されることとなる。Ｓ１８０９の処理が完了した場合、または、閾値判断の結果、閾値を超過するパラメータがなかった場合（Ｓ１８０８／ＮＯ）、本実施形態に係るＳ１６０７の解析処理及びＳ１６０８のアラート処理が完了する。

Ｓ１８０７、Ｓ１８０８において、閾値を超えたパラメータが“部品名”を解析対象とした解析結果のパラメータである場合もある。そのような場合、夫々の解析方法に対する閾値の設定によっては、閾値を超えてアラート対象となるのが“部品名”のみであり、その部品が用いられた“製品名”はアラート対象とはならない場合がある。

また、複数の製品に用いられている部品がアラート対象となる場合、不具合の発生が複数の異なる製品に分散していると、製品を対象とした解析では、解析結果のパラメータが閾値を超えない場合もある。そのような場合、アラート対象となった“部品名”が用いられている“製品名”は、アラート対象とはならない。

しかしながら、製品を構成する部品の一覧の情報があれば、アラート対象となった“部品名”に基づいて“製品名”をアラート対象とすることも可能である。図２３は、そのような情報（以降、「部品構成情報」とする）の例を示す図である。図２３に示すように、本実施形態に係る部品構成情報においては、“部品名”と“適用製品”とが関連付けられている。

例えば図２３の例においては、「部品Ａ」が「製品Ａ」、「製品Ｂ」、「製品Ｃ」の３つの製品に関連付けられており、「部品Ａ」が「製品Ａ」、「製品Ｂ」、「製品Ｃ」の３つの製品に組み込まれていることが分かる。アラート部１０６は、図２０において説明した閾値超過通知により、“解析対象”として「部品Ａ」が指定された通知を受けた場合、図２３に示すテーブルを参照して、「製品Ａ」、「製品Ｂ」、「製品Ｃ」を抽出する。

そして、図２１において「部品Ａ」に関連付けられた“通知先アドレス”の他、図２２において「製品Ａ」、「製品Ｂ」、「製品Ｃ」に夫々関連付けられた“通知先アドレス”にもアラート処理を行う。これにより、未だ解析結果のパラメータが閾値を超えていない製品についても早期にアラートを発して迅速な対応を促すことが可能となる。

以上、説明したように、本実施形態に係るシステムにおいては、苦情データサーバ２の苦情データＤＢからキーレコードＤＢ１０２にコピーされたレコードについて不具合の発生傾向を解析し、解析結果に基づいてアラート処理を行う。換言すると、本実施形態においてデータ解析が行われる対象の製品や部品は、キーレコードＤＢ１０２に登録されたレコードにおいて“製品名”や“部品名”が指定されているものだけである。

そのため、何らかの傾向をもって発生している不具合、即ち、共通する原因に基づいて多発的に発生する不具合を、図１７に示すような出荷データに登録されている出荷された製品の全てについて不具合の発生傾向を解析することなく把握することが出来る。従って、本実施形態に係るシステムにおいては、製品やそれを構成する部品についての不具合の発生傾向を掴むためのデータ解析を効率的に行うことができる。

尚、上記実施形態においては、苦情データサーバ２の苦情データＤＢに登録されている全てのレコードを解析対象とする場合を例として説明した。しかしながら、苦情データＤＢにはあらゆる種類の不具合に関するレコードが登録され、その中には、解析対象とするべきではないレコードも含まれる。

図６〜図１３に示すような解析は、製品や部品が意図した通りに機能せずに発生した不具合のレコードのみを対象として行われるべきである。従って、製品寿命や部品寿命によって生じた不具合のレコードや、ユーザの操作ミスによって生じた不具合のレコード等、製品や部品若しくはそれらの組み立て工程など、生産者側が原因ではない不具合のレコードは除外するべきである。

従って、Ｓ１８０３において、データ解析部１０３は、解析対象とするべきレコードのみを取得することが好ましい。夫々のレコードが解析対象であるか否かは、図４に示す夫々の項目のうち、“不具合内容”、“原因”等に基づいて判断可能である。即ち、“不具合内容”、や“原因”の値として、上述した寿命や操作ミスであることを示す値が取り得る。そして、データ解析部１０３は、“不具合内容”、“原因”等の値が解析対象とするべきではない値であるレコードを除外して取得する。

尚、データ解析部１０３が除外するのではなく、苦情データサーバ２がデータ解析部１０３からＳ１８０３においてレコードの要求を受けた際に、解析対象とするべきではないレコードを除外して送信するようにしても良い。

また、上記実施形態においては、データ解析部１０３が苦情データサーバ２から図４に示すようなデータのレコードを取得した上で、図６〜図１３に示すような解析結果を得るためのデータ解析を行う場合を例として説明した。即ち、図６の解析結果の場合、データ解析部１０３が、苦情データサーバ２から取得した苦情データＤＢのデータに基づき、解析対象である製品毎に出荷数を合計する。また、解析対象である製品毎に、その製品が対象となっているレコード数をカウントする。

しかしながら、このようなデータの解析を苦情データサーバ２において実行しても良い。即ち、Ｓ１８０３において、データ解析部１０３は、苦情データサーバ２に対して過去レコードの取得を要求するのではなく、解析対象の製品名若しくは部品名を通知し、解析結果を要求する。そして、苦情データサーバ２においては、通知された製品名及び部品名に基づいて図６〜図１３に示すような解析結果を得るための解析処理を行い、その結果をデータ解析部１０３に対して返信する。これにより、Ｓ１８０４において、データ解析部１０３が解析結果を取得する。

図２４は、このような場合にデータ解析部１０３が取得する解析結果のうち、「製品Ａ」が解析対象である場合の、図６に示す解析結果のデータの例である。図２４に示すように、データ解析部１０３が取得する解析結果の情報には、“出荷数−不良数 製品毎解析”のような解析方法の情報、“製品名”、“出荷数”及び“不良数”の情報が含まれる。図２４に示すような情報が複数の製品について得られることにより、図６に示すグラフの描画が可能となる。

１ データ解析サーバ
２ 苦情データ
３ 出荷データ
４ａ、４ｂ 担当者端末
１０ ＣＰＵ
２０ ＲＡＭ
３０ ＲＯＭ
４０ ＨＤＤ
５０ Ｉ／Ｆ
６０ ＬＣＤ
７０ 操作部
８０ バス
１００ ショッピングサイトコントローラ
１０１ 情報取得部
１０２ キーレコードＤＢ
１０３ データ解析部
１０４ 解析結果ＤＢ
１０５ 閾値判断部
１０６ アラート部
１０７ 表示制御部
１１０ ネットワークＩ／Ｆ

特開２００２−３７３２７７号公報

Claims (10)

1. 出荷された製品について発生した不具合に関する情報である不具合情報に基づいて不具合の傾向を分析して通知を行う不具合通知システムであって、
   前記不具合情報を蓄積管理している不具合情報管理部から、新たに発生した不具合に関する不具合情報を取得して記憶媒体に記憶させる不具合情報取得部と、
   前記不具合情報取得部により取得され前記記憶媒体に新規に記憶される前記不具合情報を、６ヶ月あるいは約６ヶ月である保存期間で前記記憶媒体に保存する不具合情報削除部と、
   前記記憶媒体に保存されている前記不具合情報に基づき、前記保存期間の期間内に、同一の製品あるいは部品に係る不具合の発生回数が、２あるいは約２以上であるか否かを判断する解析対象判断部と、
   前記解析対象判断部により、前記保存期間における前記不具合の発生回数が、２あるいは約２以上発生していると判断された製品あるいは部品があった場合に、当該製品あるいは部品を対象に、前記不具合情報管理部において管理されている前記不具合情報に基づき複数の解析方法により解析して得られる複数の解析結果を取得する解析結果取得部と、
   前記複数の解析結果について夫々設定された閾値と前記複数の解析結果とを夫々比較する閾値判断部と、
   前記解析結果と前記閾値との比較結果に基づき、前記閾値を超えた前記解析結果に関する通知先に対して通知を行う通知処理部と、
   を含むことを特徴とする不具合通知システム。
2. ネットワークを介して接続する第１の情報処理装置と第２の情報処理装置とを有し、
   前記不具合情報管理部は、前記第１の情報処理装置が有し、
   前記記憶媒体は、前記第２の情報処理装置が有する、
   請求項１記載の不具合通知システム。
3. 前記通知処理部は、前記閾値を超えた前記解析結果に係る部品に関する通知先に加えて、前記部品が用いられた製品に関する通知先に対して通知を行うことを特徴とする請求項１または２に記載の不具合通知システム。
4. 前記不具合情報は、不具合の種類を示す情報を含み、
   前記解析結果取得部は、前記不具合情報管理部において管理されている前記不具合情報のうち、前記不具合の種類を示す情報に基づいて選択された情報であって、且つ記憶された不具合に関する情報を、複数の解析方法により解析して得られる複数の解析結果を取得することを特徴とする請求項１乃至３のいずれか１項に記載の不具合通知システム。
5. 前記不具合情報は、不具合の内容あるいは原因を示す情報を含み、
   前記解析結果取得部は、前記不具合情報管理部において管理されている前記不具合情報のうち、意図した通りに機能せずに発生した不具合の情報であって、且つ記憶された不具合に関する情報を、複数の解析方法により解析して得られる複数の解析結果を取得することを特徴とする請求項１乃至４のいずれか１項に記載の不具合通知システム。
6. 前記不具合情報削除部は、
   前記記憶媒体に記憶された夫々の前記不具合情報について、設定された前記保存期間に到達した情報を削除することを特徴とする請求項１乃至５のいずれか１項に記載の不具合通知システム。
7. 出荷された製品について発生した不具合に関する情報である不具合情報に基づいて不具合の傾向を分析して通知を行う不具合通知システムにおける不具合通知方法であって、
   前記不具合通知システムは、前記不具合情報を蓄積管理している不具合情報管理部から、新たに発生した不具合に関する不具合情報を取得して記憶媒体に記憶させ、
   取得され前記記憶媒体に新規に記憶される前記不具合情報を、６ヶ月あるいは約６ヶ月である保存期間で前記記憶媒体に保存し、
   前記記憶媒体に保存されている前記不具合情報に基づき、前記保存期間の期間内に、同一の製品あるいは部品に係る不具合の発生回数が、２あるいは約２以上であるか否かを判断し、
   前記保存期間における前記不具合の発生回数が、２あるいは約２以上発生していると判断された製品あるいは部品があった場合に、当該製品あるいは部品を対象に、前記不具合情報管理部において管理されている前記不具合情報に基づき複数の解析方法により解析して得られる複数の解析結果を取得し、
   前記複数の解析結果について夫々設定された閾値と前記複数の解析結果とを夫々比較し、
   前記解析結果と前記閾値との比較結果に基づき、前記閾値を超えた前記解析結果に関する通知先に対して通知を行う、ことを特徴とする不具合通知方法。
8. 出荷された製品について発生した不具合に関する情報である不具合情報に基づいて不具合の傾向を分析して通知を行う不具合通知装置であって、
   前記不具合情報を蓄積管理している不具合情報管理部から、新たに発生した不具合に関する不具合情報を、ネットワークを介して取得し、記憶媒体に記憶させる不具合情報取得部と、
   前記不具合情報取得部により取得され前記記憶媒体に新規に記憶される前記不具合情報を、６ヶ月あるいは約６ヶ月である保存期間で前記記憶媒体に保存する不具合情報削除部と、
   前記記憶媒体に保存されている前記不具合情報に基づき、前記保存期間の期間内に、同一の製品あるいは部品に係る不具合の発生回数が、２あるいは約２以上発生しているか否かを判断する解析対象判断部と、
   前記解析対象判断部により前記保存期間における前記不具合の発生回数が、２あるいは約２以上発生していると判断された製品あるいは部品があった場合に、当該製品あるいは部品を対象に、前記不具合情報管理部において管理されている前記不具合情報に基づき複数の解析方法により解析して得られる複数の解析結果を取得する解析結果取得部と、
   前記複数の解析結果について夫々設定された閾値と前記複数の解析結果とを夫々比較する閾値判断部と、
   前記解析結果と前記閾値との比較結果に基づき、前記閾値を超えた前記解析結果に関する通知先に対して通知を行う通知処理部とを含むことを特徴とする不具合通知装置。
9. 出荷された製品について発生した不具合に関する情報である不具合情報に基づいて不具合の傾向を分析して通知を行う不具合通知プログラムであって、
   前記不具合情報を蓄積管理している不具合情報管理部から、新たに発生した不具合に関する不具合情報を取得して記憶媒体に記憶させるステップと、
   取得された前記記憶媒体に新規に記憶される前記不具合情報を、６ヶ月あるいは約６ヶ月である保存期間で前記記憶媒体に保存させるステップと、
   前記記憶媒体に保存されている前記不具合情報に基づき、前記保存期間内に、同一の製品あるいは部品に係る不具合の発生回数が、２あるいは約２以上発生しているか否かを判断するステップと、
   前記保存期間における前記不具合の発生回数が、２あるいは約２以上発生していると判断された製品あるいは部品があった場合に、当該製品あるいは部品を対象に、前記不具合情報管理部において管理されている前記不具合情報に基づき複数の解析方法により解析して得られる複数の解析結果を取得するステップと、
   前記複数の解析結果について夫々設定された閾値と前記複数の解析結果とを夫々比較するステップと、
   前記解析結果と前記閾値との比較結果に基づき、前記閾値を超えた前記解析結果に関する通知先に対して通知を行うステップとを情報処理装置に実行させることを特徴とする不具合通知プログラム。
10. 請求項９に記載されたプログラムが記録されたコンピュータ読み取り可能な記録媒体。