JP2011209938A - 情報管理装置、情報管理方法及び情報管理プログラム - Google Patents

Abstract

【課題】クレーム対応業務で作成した情報を自動かつ適切に登録する。
【解決手段】算出部が、製品に関連して作成された１又は複数の情報（品目や文書ファイル）から複数の要素（時間的要素、人的要素、成果物要素）を抽出するとともに、当該抽出された要素から、前記製品の不具合の発生可能性を示す指標（ランク）をそれぞれ算出する（ステップ２０〜Ｓ６０）。そして、判定部は、各ランクから統合指標としての総合ランクを算出し、当該総合ランクに基づいて、製品に不具合が発生している可能性が高いか否かを判定し（ステップＳ７０）、その判定結果に基づいて、格納部が、要素を抽出した情報をクレーム対応業務に係る情報としてデータサーバに格納する（ステップＳ９０）。
【選択図】図１２

Description

本件は、情報管理装置、情報管理方法及び情報管理プログラムに関する。

近年、製品のライフサイクルの短縮化と、ユーザのニーズの多様化にともなって多品種の製品が大量に製造される傾向にある。また、ＣＡＤ（Computer Aided Design）やＣＡＥ（Computer Aided Engineering）等の普及により、コンピュータによって作成された設計図等のデータが企業内に大量に蓄積されるようになっている。

そこで、最近では、これらのデータを効率的に管理するとともに、必要なデータを迅速に検索することを目的としたＰＤＭ（Product Data Management）システムと呼ばれるシステムが提案されている。ＰＤＭシステムでは、製品の設計から生産に至るまでに生成される情報を一元的に管理することにより、トラブルの発生を防止するとともに、情報の再利用による設計の生産性の向上を図ることが可能となる（例えば、特許文献１参照）。

特開２００７−１６４８１７号公報

ＰＤＭシステムでは、ＣＡＤ等で設計図を作成する担当者がクレーム対応業務として作成した情報（データ）を、類似するクレームの処理において、再利用したい場合などがある。

しかしながら、現在のＰＤＭシステムでは、ＣＡＤ等で設計図を作成する担当者は、クレーム対応業務において作成した情報（データ）も、通常業務で作成した情報も、分別することなく、システムの記憶部に保存することが多い。また、企業内では、クレーム対応業務を終えた担当者に、クレーム対応業務中に有用と判断した情報をクレーム対応情報用の記憶部に移動させる（登録させる）作業を強いることもある。この場合、担当者の負担が大きくなるとともに、作業忘れが生じたり、主観的判断が介入したりする。これにより、有用な情報がクレーム対応情報用の記憶部に登録されないなど、適切な登録が行われない可能性がある。

そこで本件は上記の課題に鑑みてなされたものであり、製品の不具合に対応して作成した情報を適切に管理することが可能な情報管理装置、情報管理方法及び情報管理プログラムを提供することを目的とする。

本明細書に記載の情報管理装置は、製品に関連して作成された１又は複数の情報から複数の要素を抽出するとともに、当該抽出された前記複数の要素ごとに、前記製品の不具合の発生可能性を示す指標をそれぞれ算出する算出部と、前記それぞれ算出した前記指標のうち２以上の指標に基づいて、前記製品に不具合が発生している可能性が高いか否かを判定する判定部と、前記判定部において前記製品に不具合が発生している可能性が高いと判定された場合に、前記要素を抽出した情報を、抽出情報記憶部に格納する格納部と、を備える情報管理装置である。

本明細書に記載の情報管理方法は、コンピュータが、製品に関連して作成された１又は複数の情報から複数の要素を抽出するとともに、当該抽出された前記複数の要素ごとに、前記製品の不具合の発生可能性を示す指標をそれぞれ算出する工程と、前記それぞれ算出した前記指標のうち２以上の指標に基づいて、前記製品に不具合が発生している可能性が高いか否かを判定する判定する工程と、前記判定部において前記製品に不具合が発生している可能性が高いと判定された場合に、前記要素を抽出した情報を、抽出情報記憶部に格納する工程と、を実行する情報管理方法である。

本明細書に記載の情報管理プログラムは、コンピュータに、製品に関連して作成された１又は複数の情報から複数の要素を抽出するとともに、当該抽出された前記複数の要素ごとに、前記製品の不具合の発生可能性を示す指標をそれぞれ算出する工程と、前記それぞれ算出した前記指標のうち２以上の指標に基づいて、前記製品に不具合が発生している可能性が高いか否かを判定する判定する工程と、前記判定部において前記製品に不具合が発生している可能性が高いと判定された場合に、前記要素を抽出した情報を、抽出情報記憶部に格納する工程と、を実行させる情報管理プログラムである。

本明細書に記載の情報管理装置、情報管理方法及び情報管理プログラムは、製品の不具合に対応して作成した情報を適切に管理することができるという効果を奏する。

一実施形態に係るＰＤＭシステムのシステム構成を示す図である。 課題クレーム管理サーバのハードウェア構成を示す図である。 課題クレーム管理サーバの機能ブロック図である。 作成情報記憶部に記憶されているデータ（テーブル、マスタ）を示す図である。 検証対象待避テーブルＴ１を示す図である。 図６（ａ）は、時間的要素定常状態管理テーブルＴ２を示す図であり、図６（ｂ）は、人的要素定常状態管理テーブルＴ３を示す図である。 図７（ａ）は、成果物要素定常状態管理テーブルＴ４を示す図であり、図７（ｂ）は、課題クレーム判定対象テーブルＴ５を示す図である。 図８（ａ）は、課題クレーム判定基準管理テーブルＴ６を示す図であり、図８（ｂ）は、メールテーブルＴ７を示す図である。 図９（ａ）は、ユーザマスタＭ１を示す図であり、図９（ｂ）は、グループマスタＭ２を示す図である。 図１０（ａ）は、品目マスタＭ３を示す図であり、図１０（ｂ）は、文書マスタＭ４を示す図である。 図１１（ａ）は、構成マスタＭ５を示す図であり、図１１（ｂ）は、関連文書マスタＭ６を示す図である。 課題クレーム管理サーバにおけるクレーム対応作業の登録処理の全体の流れを示すフローチャートである。 図１２のステップＳ２０の具体的処理を示すフローチャートである。 図１４（ａ）は、品目承認件数履歴情報の一例を示すグラフであり、図１４（ｂ）は、文書承認件数履歴情報の一例を示すグラフである。 図１２のステップＳ３０の具体的処理を示すフローチャートである。 図１６（ａ）は、部品点数に対する編集時間の履歴情報の一例を示すグラフであり、図１６（ｂ）は、ファイルサイズに対する編集時間の履歴情報の一例を示すグラフである。 図１２のステップＳ４０の具体的処理を示すフローチャートである。 図１２のステップＳ５０の具体的処理を示すフローチャートである。 図１２のステップＳ６０の具体的処理を示すフローチャートである。 図１９のステップＳ６３を分かりやすく説明するための図である。 図１２のステップＳ７０の具体的処理を示すフローチャートである。 各要素のランクと実績重み付け係数とを示す表である。 定常状態の取得処理の一連の流れを示すフローチャートである。 図２３のステップＳ２００の具体的処理を示すフローチャートである。 図２３のステップＳ２１０の具体的処理を示すフローチャートである。 図２３のステップＳ２２０の具体的処理を示すフローチャートである。 図２３のステップＳ２３０の具体的処理を示すフローチャートである。

以下、情報管理装置、情報管理方法及び情報管理プログラムの一実施形態について、図１〜図２７に基づいて詳細に説明する。図１には、情報管理装置としての課題クレーム管理サーバ４０を備えるＰＤＭシステム１００のシステム構成が示されている。この図１に示すように、ＰＤＭシステム１００は、ＰＤＭユーザ端末１０と、ＰＤＭサーバ２０と、生産管理システム３０と、課題クレーム管理サーバ４０と、メールサーバ５０と、外部装置としてのデータサーバ６０と、を備える。ＰＤＭシステム１００を構成する各装置は、ＬＡＮ（Local Area Network）などのネットワーク７０により接続されており、各装置間におけるデータのやり取りは、ネットワーク７０を介して行われる。

ＰＤＭユーザ端末１０は、ＰＤＭシステム１００を利用するユーザが使用する端末であり、ユーザは、ＰＤＭユーザ端末１０上で、文書や図面のファイル（以下、文書ファイルと呼ぶ）などの製品に関する情報を作成したり、電子メールの送受信を行ったりする。また、ユーザは、通常業務として、現在開発中の製品（品目）に関連する文書ファイルを作成するが、製品の不具合に対する顧客等からのクレームがあった場合には、当該クレームに対応する業務として、文書ファイルを作成することもあるものとする。なお、ＰＤＭユーザ端末１０は、ネットワーク７０上に複数存在していても良いが、本実施形態では、説明の錯綜を避けるため、ＰＤＭユーザ端末１０がネットワーク７０上に１つのみ存在しているものとして説明する。

ＰＤＭサーバ２０は、ＰＤＭユーザ端末１０にて作成された文書ファイルなどの情報を格納し、格納した情報に関する種々データを、課題クレーム管理サーバ４０や、生産管理システム３０に対して送信する。

生産管理システム３０は、製品の調達計画や、生産計画を管理するものであり、当該管理情報を課題クレーム管理サーバ４０に送信する。

課題クレーム管理サーバ４０は、ＰＤＭサーバ２０、生産管理システム３０、及びメールサーバ５０から送信されてくるデータに基づいて、ＰＤＭユーザ端末１０にて作成された文書ファイルを、データサーバ６０に格納するか否かを判断する。そして、データサーバ６０に格納すると判断した場合に、文書ファイルをデータサーバ６０に格納する。なお、課題クレーム管理サーバ４０が、データサーバ６０に格納する文書ファイルは、製品の不具合に対するクレームに対応するための業務（クレーム対応業務）において作成された可能性の高い文書ファイル（以下「クレーム対応ファイル」と呼ぶ）である。なお、課題クレーム管理サーバ４０の詳細な構成及び処理内容等については、後述する。

メールサーバ５０は、ＰＤＭユーザ端末１０とネットワーク７０又はインターネット上の他の端末との間の電子メールの送受信を行うサーバである。メールサーバ５０では、電子メールに含まれる種々データを取得し、課題クレーム管理サーバ４０に対して送信する。

データサーバ６０は、課題クレーム管理サーバ４０にて、クレーム対応ファイルと判断された文書ファイルを格納する抽出情報記憶部を内部に有している。

図２には、課題クレーム管理サーバ４０のハードウェア構成が示されている。この図２に示すように、課題クレーム管理サーバ４０は、ＣＰＵ４１、ＲＯＭ４２、ＲＡＭ４３、入出力部４４、及びこれら各部間の通信を可能にするバス４５等を備えている。この課題クレーム管理サーバ４０においては、ＣＰＵ４１が、ＲＯＭ４２又はＲＡＭ４３に格納されているプログラム（情報管理プログラム）を実行することで、図３に示す機能を実現する。すなわち、課題クレーム管理サーバ４０では、プログラムを実行するＣＰＵ４１により、図３に示す、算出部８０と、判定部８２と、格納部８４と、定常状態取得部８６と、の機能が実現されている。また、ＲＡＭ４３により、作成情報記憶部８８としての機能が実現されている。

図３の算出部８０は、作成情報記憶部８８から１つの製品に関連して作成された１又は複数の情報（文書ファイルや電子メールなど１又は複数のアプリケーションによって作成されたファイル）から複数の要素（クレーム対応ファイルの可能性が高いか否かを判定するための要素）を抽出する。また、算出部８０は、抽出したそれぞれの要素から、製品の不具合の発生可能性を示す指標（ランク）を算出する。なお、本実施形態では、算出部８０が抽出する要素には、時間的要素、人的要素、成果物要素が含まれる。時間的要素は、作業が完了した時期、作業に費やした時間を含んでいる。これら時間的要素が、通常の業務（定常状態）と比べて乖離しているとき、すなわち異常なときには、その作業は、クレーム対応作業の可能性が高いと考えられる。人的要素は、電子メールに関する要素であり、電子メールのやり取り回数や、宛先件数等が、通常の業務（定常状態）と比べて異常なときには、その電子メールに記載されている作業は、クレーム対応作業の可能性が高いと考えられる。成果物要素は、品目ごとの成果物の種類であり、成果物の種類が、通常の業務（定常状態）と比べて異常なときには、その品目に対する作業、クレーム対応作業の可能性が高いと考えられる。

判定部８２は、算出部８０で算出された各指標（ランク）を統合した統合指標（判定値）を算出する。また、判定部８２は、統合指標に基づいて製品に不具合が発生している可能性が高いか否か、すなわち、作成された文書ファイルがクレーム対応ファイルの可能性が高いか否かを判定する。

格納部８４は、判定部８２において製品に不具合が発生していると判定された場合に、要素を抽出した情報をネットワーク７０を介してデータサーバ６０に送信して、データサーバ６０内の抽出情報記憶部に格納する。なお、ネットワーク７０は、図２の入出力部４４と接続されている。したがって、入出力部４４は、課題クレーム管理サーバ４０（格納部８４）と、抽出情報記憶部を有するデータサーバ６０とを接続する接続部と、して機能している。

作成情報記憶部８８は、例えば、製品の識別子（品番など）と、その製品に関連してＰＤＭユーザ端末１０において作成された情報と、を対応付けて記憶する。なお、作成情報記憶部８８は、製品に不具合が発生している可能性が高いか否かを判断するための各種データ（テーブルやマスタ）も有しているがこれら各種データの詳細については、後述する。

定常状態取得部８６は、ユーザの作成した文書ファイル等から要素を抽出して、算出部８０や判定部８２において用いられるデータ（テーブル）を作成する。

図４には、作成情報記憶部８８に記憶されているデータの一例が示されている。この図４に示すように、作成情報記憶部８８には、テーブル群９０Ｔと、マスタ群９０Ｍとが記憶されている。テーブル群９０Ｔには、検証対象待避テーブルＴ１と、時間的要素定常状態管理テーブルＴ２と、人的要素定常状態管理テーブルＴ３と、成果物要素定常状態管理テーブルＴ４と、メールテーブルＴ５と、課題クレーム判定基準管理テーブルＴ６と、課題クレーム判定対象テーブルＴ７とが含まれる。また、マスタ群９０Ｍには、ユーザマスタＭ１と、グループマスタＭ２と、品目マスタＭ３と、文書マスタＭ４と、構成マスタＭ５と、関連文書マスタＭ６と、が含まれる。

検証対象待避テーブルＴ１は、これから検証を行う必要のある、品目や文書ファイルを一覧として記憶するものであり、図５に示すように、検証対象のＮｏ.、検証対象の種類（品目又は文書）、検証対象が登録された日時、の各項目を含んでいる。

時間的要素定常状態管理テーブルＴ２は、検証対象の時間的要素の定常状態を格納するテーブルである。このテーブルは、前述した定常状態取得部８６により作成され、算出部８０にて使用される。図６（ａ）に示すように、時間的要素定常状態管理テーブルＴ２は、時間的要素の種類、当該種類に応じたキー、キーに対応する値の項目を含んでいる。キーと値との関係は、ＸＹ２次元のグラフにおいて、一方がＸ軸の要素であれば、他方がＹ軸の要素となる関係である。時間的要素の種類の項目には、品目が承認される日である「品目承認日」や、文書が承認される「承認日」、品目について編集した時間を示す「品目編集時間」、文書を編集した時間を示す「文書編集時間」などが入力される。キーには、日付や品目の構成部品の数、文書のサイズなどが入力される。値には、キーに対応する値（カウント数や、時間などであり、時間的要素の種類により異なる）が入力される。

人的要素定常状態管理テーブルＴ３は、検証対象の人的要素の定常状態を格納するテーブルである。このテーブルは、前述した定常状態取得部８６により作成され、算出部８０にて使用される。この人的要素定常状態管理テーブルＴ３は、過去において、タイトルや本文に、品目や文書ファイルの名前などが記載されていた電子メールの内容を格納しておくテーブルである。具体的には、人的要素定常状態管理テーブルＴ３は、図６（ｂ）に示すように、アイテムＮｏ.（品目や文書ファイルの名前など）、その記載された品目等の種類、電子メールの送受信日、宛先に記載されていた件数、宛先に含まれるグループ数、の項目を含んでいる。

成果物要素定常状態管理テーブルＴ４は、図７（ａ）に示すように、全品目に対して成果物としてどのようなものが作成されたかを保持するテーブルであり、定常状態取得部８６により作成され、算出部８０にて使用されるものである。この成果物要素定常状態管理テーブルＴ４には、作成された文書ファイルの種類（部品票や２Ｄ図面など）の項目と、種類ごとの作成ファイルの数（保持品目数）の項目とを含んでいる。

メールテーブルＴ５は、ＰＤＭユーザ端末１０から送信される電子メールの内容をメールサーバ５０から取得し、格納するテーブルである。このメールテーブルＴ５は、図７（ｂ）に示すように、電子メールの送信者、宛先、タイトル、本文、送信日時の項目を有している。

課題クレーム判定基準管理テーブルＴ６は、図８（ａ）に示すように、判定対象となる要素（時間的要素、人的要素、成果物要素のいずれか）と、要素ごとのランク付けの基準と、製品の不具合発生の可能性を示す指標（ランク（Ａ〜Ｄ））が定義されている。

課題クレーム判定対象テーブルＴ７は、算出部８０において、図８（ａ）のテーブルＴ６を用いてランク付けした結果を格納するテーブルである。この課題クレーム判定対象テーブルＴ７は、図８（ｂ）に示すように、検証対象Ｎｏ.、要素（時間的要素、人的要素、成果物要素のいずれか）、判定結果としての総合ランクを含んでいる。

ユーザマスタＭ１は、図９（ａ）に示すように、ユーザＩＤと、グループＩＤと、メールアドレスとを関連付けて記憶している。グループマスタＭ２は、図９（ｂ）に示すように、グループＩＤと、その名称とを関連付けて記憶している。これら２つのマスタＭ１，Ｍ２により、ユーザの属するグループ名を特定することができる。

品目マスタＭ３は、ユーザがＰＤＭユーザ端末１０にて行われた業務における品目の情報を格納するものであり、図１０（ａ）に示すように、品番と、版数と、ステータス（正式に承認されたものか、編集中のものかを示すステータス）と、作成日と、承認日と、その他属性と、を関連付けて記憶している。文書マスタＭ４は、ユーザが、ＰＤＭユーザ端末１０にて行われた業務における文書ファイルの情報を格納するものであり、図１０（ｂ）に示すように、文書名、版数、ステータス、作成日、承認日、その他属性、サイズ、を関連付けて記憶している。

構成マスタＭ５は、図１１（ａ）に示すように、品番と、その品番にぶら下がる下位品番とを記憶している。すなわち、この構成マスタＭ５では、例えば、製品と部品とが紐付けられる。関連文書マスタＭ６は、図１１（ｂ）に示すように、品番と、その品番にぶら下がる関連文書とを記憶している。すなわち、この関連文書マスタＭ６では、品目（品番）と、その品目に関連して作成した文書ファイルとが紐付けられる。

次に、課題クレーム管理サーバ４０による処理について、図１２〜図２７に基づいて詳細に説明する。まず、課題クレーム管理サーバ４０の算出部８０、判定部８２、格納部８４が実行するクレーム対応ファイルの登録処理について、図１２〜図２２に基づいて説明する。なお、この説明の前提として、図６（ａ）、図６（ｂ）、図７の各定常状態管理テーブルＴ２，Ｔ３，Ｔ４は、定常状態取得部８６により、既に作成されているものとする。なお、これらテーブルの作成方法については、後述する。

図１２には、課題クレーム管理サーバ４０におけるクレーム対応作業の登録処理の全体の流れがフローチャートにて示されている。この図１２では、まず、ステップＳ１０において、算出部８０が、図５の検証対象待避テーブルＴ１に基づいて、検証対象を抽出する。ここでは、例えば、最上段に位置する、登録日時が「２０１０/２/１ １２：２３」の検証対象Ｎｏ．「Ｐａｒｔ−００１」である品目が抽出される。

次いで、ステップＳ２０では、算出部８０が、時間的要素評価処理（承認日）を実行する。次いで、ステップＳ３０では、算出部８０が、時間的要素評価処理（編集時間）を実行する。次いで、ステップＳ４０では、算出部８０が、人的要素評価処理（メール件数）を実行する。次いで、ステップＳ５０では、算出部８０が、人的要素評価処理（宛先件数）を抽出する。次いで、ステップＳ６０では、算出部８０が、成果物要素評価処理を実行する。次いで、ステップＳ７０では、判定部８２が、ステップＳ２０〜Ｓ６０の処理結果に基づいて、課題クレーム判定処理を実行する。なお、ステップＳ２０〜Ｓ７０の具体的な処理については後述する。

次いで、ステップＳ８０では、判定部８２が、ステップＳ７０の判定処理の結果に基づいて、ステップＳ１０において抽出された検証対象が、蓄積対象か否か、すなわち、データサーバ６０に格納する必要があるものか否かを判断する。ここでの判断が肯定された場合には、ステップＳ９０に移行して、格納部８４が、検証対象を課題クレーム情報として、データサーバ６０に格納する。一方、ステップＳ８０の判断が否定された場合には、ステップＳ１００に移行して、算出部８０が、終了か否かを判断する。ここでの判断が肯定されるのは、例えば、図５の検証対象待避テーブルＴ１の検証対象が全て無くなった場合などである。ここでの判断が肯定された場合には、図１２の全処理が終了するが、否定された場合には、ステップＳ１０に戻る。

次に、ステップＳ２０〜Ｓ７０における詳細な処理内容について、図１３〜図２２に基づいて説明する。

（１）ステップＳ２０（時間的要素評価処理（承認日））について
図１３は、ステップＳ２０（時間的要素評価処理（承認日））の具体的な処理を示すフローチャートである。この図１３に示すように、まず、ステップＳ２１では、算出部８０が、検証対象（品目又は文書）の承認日を、品目マスタＭ３（図１０（ａ））又は文書マスタＭ４（図１０（ｂ））から、取得する。なお、ここでは、品目マスタＭ３から、承認日として３月３１日が取得されたものとする。

次いで、ステップＳ２２では、算出部８０が、時間的要素定常状態管理テーブルＴ２（図６（ａ））に基づいて、検証対象の承認日から最も近い定常状態の極大値を持つ日付を算出する。

なお、図６（ａ）のテーブルＴ２からは、一例として、図１４（ａ）のような、品目の承認日と品目の承認件数との関係を示すグラフ（品目承認件数履歴情報）を得ることができる。図１４（ａ）では、品目が承認される日は１年間のうちで、２つの時期に集中していることが分かる。このため、本例では、この２つの時期とは異なる時期に品目が承認された場合には、その承認された品目に関する作業は、クレーム対応の作業である可能性が高いと判定する。すなわち、グラフの極大値からの乖離度が得られれば、それに基づいて、クレーム対応の作業か否かを判定することができることになる。

そこで、ステップＳ２２では、極大値を持つ日付を、以下のようにして算出する。まず、(i)算出部８０は、テーブルＴ２から、日付ごとの承認件数の最大値Ｍを取得する。図１４（ａ）の場合には、例えば、３月１０日の値が取得される。次いで、(ii)算出部８０は、検証対象の承認日から最大値Ｍの７０％以上の承認件数を示す最も近い日付Ｄを取得する。そして、(iii)算出部８０は、日付Ｄから３０日以内で最も大きい承認件数を示す日付を極大値を有する日付として取得する。図１４（ａ）の場合には、極大値を有する日付として３月１０日が算出される。

なお、上記(ii)において最大値Ｍの７０％以上という条件を用いているのは、図１４（ａ）のデータとして十分な母数がある場合には、最大値Ｍの７０％以上であれば、ノイズの影響を低減できる可能性が高いためである。なお、７０％以上という数値は一例であって、ノイズの影響を低減できる可能性が高ければ、その他の値を用いることとしても良い。また、上記(iii)で３０日以内という条件を用いているのは、製造業の特性として、業務のスパンが３０日以内となる可能性は低いからである。ただし、３０日という数値は一例である。したがって、業務のスパンを考慮して、種々変更しても良い。

図１３に戻り、ステップＳ２３では、算出部８０が、検証対象が１番目に近い極大値及び２番目に近い極大値に挟まれる条件で、２番目に近い極大値を持つ日付を算出する。図１４（ａ）の場合、９月１８日近傍の日付が算出されることになる。

次いで、ステップＳ２４では、算出部８０が、２つの極大値を持つ日付の中間日からの乖離度に基づいて、製品の不具合の発生可能性を示す指標（ランク）を算出する。この場合、算出部８０は、図８（ａ）の課題クレーム判定基準管理テーブルＴ６を参照し、中間点から離れているほど、ランクとして、低い側（Ｅ側）のランクを算出する。すなわち、承認日が中間点から離れているほど、換言すれば、承認日が極大値を示す日付に近いほど、通常業務の可能性が高く、不具合対応の可能性が低いと判定されることになる。なお、図８（ａ）の百分率は、２つの極大値間の日数を１００としたときの、中間点と承認日との間の日数の割合を示している。

次いで、ステップＳ２５では、算出部８０が、検証対象に対する時間的要素（承認日）の評価を、図８（ｂ）に示す課題クレーム判定対象テーブルＴ７に登録する。以上の処理により、図１３の全処理が終了し、図１２のステップＳ３０に移行する。

なお、検証対象が品目でなく、文書である場合には、図１４（ｂ）のようなデータ（文書承認件数履歴情報）に基づいて、検証対象に対する時間的要素（承認日）の評価が行われることになる。

（２）ステップＳ３０（時間的要素評価処理（編集時間））について
図１５には、ステップＳ３０（時間的要素評価処理（編集時間））の具体的な処理がフローチャートにて示されている。この図１５に示すように、時間的要素評価処理（編集時間）では、まず、ステップＳ３１において、算出部８０が、検証対象の編集時間を取得する。ここでは、算出部８０は、品目マスタＭ３（図１０（ａ））又は文書マスタＭ４（図１０（ｂ））から、検証対象の承認日と作成日とを抽出し、それらの差分の日数を時間換算（２４時間を積算）したものを編集時間として取得する。

次いで、ステップＳ３２では、算出部８０が、検証対象に対する定常状態の近似関数を算出し、理論値に対する割合を算出する。ここで、算出部８０は、検証対象が品目の場合であれば、図６（ａ）の時間的要素定常状態管理テーブルＴ２から、例えば、部品点数（図６（ａ）では構成数と記載）に対する編集時間の相関関数を最小二乗法で求める。この最小二乗法の結果、図１６（ａ）に示すような、グラフ（編集時間履歴情報）を得ることができる。なお、図１６（ａ）のグラフでは、初版と、改版（第２版以降）とを別々のグラフとしている。ただし、本実施形態では、クレーム対応業務は、必ず改版であるため、以降では、改版のグラフを用いるものとする。

次いで、ステップＳ３３では、算出部８０が、算出した割合からランクを算出する。具体的には、算出部８０は、図８（ａ）の課題クレーム判定基準管理テーブルＴ６を参照して、編集時間が、改版のグラフに近いほど、クレーム対応の可能性を示す指標（ランク）として高い側（Ａ側）を算出し、改版のグラフから離れるほど、ランクとして低い側（Ｅ側）を算出する。

次いで、ステップＳ３４では、算出部８０が、検証対象に対する時間的要素（編集時間）の評価結果としてのランクを、図８（ｂ）に示す課題クレーム判定対象テーブルＴ７に登録する。以上により、ステップＳ３０の全ての処理を終了し、図１２のステップＳ４０に移行する。なお、上記のように検証対象が品目ではなく、文書であった場合には、図１６（ｂ）の編集時間履歴情報を用いて、ランクを算出することになる。すなわち、検証対象が文書であった場合には、ファイルサイズに対する編集時間の相関関係から、ランクを算出する。

（３）ステップＳ４０（人的要素評価処理（メール件数））について
図１７には、ステップＳ４０（人的要素評価処理（メール件数））の具体的な処理がフローチャートにて示されている。図１７の処理においては、まず、ステップＳ４１で、算出部８０が、検証対象のメールやり取り密度を算出する。このメールやり取り密度は、検証対象（品番や文書名）がタイトルや本文に記載されている電子メールを送信した回数（件数）を、メール送信期間で除した値とする。ここで、検証対象がタイトルや本文に記載されているメールの件数を抽出するためには、図７（ｂ）のメールテーブルＴ５が用いられる。また、メール送信期間としては、図７（ｂ）のメールテーブルＴ５から抽出されたメールの送信日時のうち、最終の日から最初の日を差し引いた期間とする。

次いで、ステップＳ４２では、算出部８０が、定常状態のメールやり取り密度を算出し、検証対象との割合を算出する。すなわち、算出部８０は、図６（ｂ）の人的要素定常状態管理テーブルＴ３から、各品目又は各文書のメールやり取り密度をそれぞれ算出し、それらの平均値を算出する。そして、算出部８０は、この平均値に対する、ステップＳ４１で算出されたメールやり取り密度の割合を算出する。

次いで、ステップＳ４３では、算出部８０が、算出した値からランクを算出する。具体的には、算出部８０は、図８（ａ）に示す課題クレーム判定基準管理テーブルＴ６の「人（メール件数）」部分からクレーム対応業務の可能性を示す指標（ランク）を算出する。例えば、実際のメールやり取り密度が、定常状態でのメールやり取り密度（平均値）よりも非常に多い（乖離度が大きい）場合（以下、「異常度が高い」ともいう）には、クレーム対応の可能性を示す指標（ランク）が高い側（Ａ側）となる。一方、メールのやり取り頻度が定常状態と近い（乖離度が小さい）ような場合（以下、「異常度が低い」ともいう）には、クレーム対応の可能性を示す指標（ランク）が低い側（Ｅ側）となる。すなわち、メールが頻繁にやり取りされる場合は、クレーム対応業務で作成されたものである可能性が高いと判断されることになる。このように判断するのは、クレーム対応業務においては、品目や文書に関連した人に対する問い合わせメールなどを頻繁にやり取りする可能性が高いからである。

次いで、ステップＳ４４では、算出部８０が、検証対象に対する人的要素（メール件数）の評価結果としてのランクを、図８（ｂ）の課題クレーム判定対象テーブルＴ７に登録する。以上により、ステップＳ４０の全ての処理を終了すると、図１２のステップＳ５０に移行する。

（４）ステップＳ５０（人的要素評価処理（宛先件数））について
図１８には、ステップＳ５０（人的要素評価処理（宛先件数））の具体的な処理がフローチャートにて示されている。この図１８の処理では、まずステップＳ５１で、算出部８０が、検証対象に関するメールの宛先平均件数、宛先に含まれるグループ数を算出する。この場合、算出部８０は、図７（ｂ）のメールテーブルＴ５を参照して、検証対象がタイトルや本文に含まれるメールを抽出するとともに、当該抽出されたメールの宛先の数を特定する。また、算出部８０は、抽出されたメールの宛先の数の平均値を算出するとともに、ユーザマスタＭ１（図９（ａ））、グループマスタ（図９（ｂ））を用いて、宛先に含まれるグループ数をそれぞれ抽出して平均値を算出する。

次いで、ステップＳ５２では、算出部８０が、定常状態におけるメール宛先平均件数、及び宛先に含まれるグループ数を、図６（ｂ）の人的要素定常状態管理テーブルＴ３の情報に基づいて算出する。そして、算出部８０は、ステップＳ５１で算出された検証対象のメール宛先平均件数、及び宛先に含まれる平均グループ数の、定常状態におけるメール宛先平均件数、及び宛先に含まれる平均グループ数をとの割合を算出する。

次いで、ステップＳ５３では、算出部８０が、ステップＳ５２で算出した値からクレーム対応の可能性を示す指標（ランク）を算出する。この場合、例えば、算出部８０は、図８（ａ）の「人（宛先件数）」部分からクレーム対応業務の可能性を示す指標（ランク）を算出する。例えば、実際の宛先件数が、定常状態での宛先件数（平均値）よりも非常に多い場合（異常度が高い場合）には、算出部８０は、クレーム対応の可能性を示す指標（ランク）として高い側（Ａ側）を算出する。一方、定常状態とあまり変わらない頻度でメールのやり取りがなされている場合には、算出部は、クレーム対応の可能性を示す指標（ランク）として低い側（Ｅ側）を算出する。すなわち、たくさんの人にメールを送信しているような場合には、クレーム対応の可能性が高いと判定されることになる。なお、図８（ａ）では、宛先件数についての判断基準のみが定義されているが、宛先に含まれるグループ数からランクを算出する場合には、グループ数についての判断基準も定義する必要がある。この場合、いずれか一方のランクを選択的に採用することとしても良いし、より高い側又は低い側のランクを採用することとしても良い。また、両方のランクの平均を本処理におけるランクとして採用することとしても良い。

次いで、ステップＳ５４では、算出部８０が、検証対象に対する人的要素（宛先件数）の評価結果としてのランクを、課題クレーム判定対象テーブルＴ７に登録する。以上により、図１８の全処理（ステップＳ５０）を終了し、図１２のステップＳ６０に移行する。

（５）ステップＳ６０（成果物要素評価処理）について
図１９には、ステップＳ６０（成果物要素評価処理）の具体的な処理がフローチャートにて示されている。この図１８では、まず、ステップＳ６１において、算出部８０が、検証対象が品目か否かを判断する。ここでの判断が否定された場合には、ステップＳ６０の処理（成果物要素評価処理）を行うことができないので、図１８の全処理を終了して、図１２のステップＳ７０に移行する。一方、ステップＳ６１の判断が肯定された場合には、算出部８０は、ステップＳ６２に移行する。

ステップＳ６２では、算出部８０が、品目に対する関連文書を取得する。具体的には、算出部８０は、図１１の関連文書マスタＭ６から、品目に対応する関連文書を取得する。次いで、ステップＳ６３では、算出部８０が、定常状態の成果物保持状態と検証対象の成果物保持状態の乖離値、すなわち、検証対象の成果物保持状態の異常度合を算出する。ここで、成果物保持状態とは、品目において各文書が作成される割合を意味する。例えば、図７（ａ）の成果物要素定常状態管理テーブルＴ４には、これまでに、各文書がどれだけ作成されたかが格納されている。ここで、通常業務の頻度とクレーム対応業務の頻度を比較すると、通常業務のほうが格段に多い。すなわち、テーブルＴ４に格納されている各文書の作成頻度は、通常業務における各文書の作成頻度と近似しているといえる。したがって、算出部８０は、定常状態で作成される割合（成果物保持割合Ｋ）を、図７（ａ）のテーブルＴ４から算出することができることになる。すなわち、ステップＳ６３では、算出部８０は、検証対象の品目に対して作成された各文書に関して、当該文書に対応する成果物保持割合Ｋを用いて個別乖離値（＝１−Ｋ）を求め、各文書の個別乖離値の合計値を、定常状態の成果物保持状態と検証対象の成果物保持状態の乖離値として算出することとする。

以上のように、各関連文書を作成したアプリケーションがメールソフトである場合と、他のアプリケーションである場合とでは、各関連文書から抽出する要素が異なる。つまり、各関連文書を作成したアプリケーションの種類に応じて、異なる要素で乖離値を算出することで、各関連文書における定常状態との乖離値が正確に算出できる。

図２０は、ステップＳ６３を分かりやすく説明するための図である。この図２０の定常平均の行では、Ｋの値が大きい文書に「○」、中程度の文書に「△」、小さい文書に「×」を付している。この場合において、品番Ａに関して図２０に示すような種類の文書が作成された場合（作成された文書に「○」印を付している）には、定常平均とほぼ一致しているので、定常状態の成果物保持状態と検証対象の成果物保持状態の乖離値は小さい値となる。一方、図２０の品番Ｂのように、定常平均で作成されている文書とは異なる文書が多く作成される場合、定常状態の成果物保持状態と検証対象の成果物保持状態の乖離値が大きい値となる。

次いで、図１９のステップＳ６４では、算出部８０が、算出した値からクレーム対応の可能性を示す指標（ランク）を算出する。ここでは、算出部８０は、図８（ａ）のテーブルＴ６の「成果物」の部分を参照して、ランクを算出する。ここで、乖離度が大きい場合（異常度合が高い場合）には、ランクが高い側（Ａ側）となり、乖離度が低い場合（異常度合が低い場合）には、ランクが低い側（Ｅ側）となる。すなわち、ステップＳ６４では、定常平均と同じような成果物が得られているときには、通常業務と判定されるような低いランクとなり、定常平均とは異なる成果物が多く得られているときには、クレーム対応業務と判定されるような高いランクとなる。

次のステップＳ６５では、算出部８０が、検証対象に対する成果物要素の評価を、図８（ｂ）の課題クレーム判定対象テーブルに登録する。以上のようにして、図１９の全処理（ステップＳ６０）が終了すると、図１２のステップＳ７０に移行する。

（６）ステップＳ７０（課題クレーム判定処理）について
図２１には、ステップＳ７０（課題クレーム判定処理）の具体的な処理がフローチャートにて示されている。この図２１では、ステップＳ７１において、判定部８２が、検証対象に対する各要素のランクを取得する。具体的には、判定部８２は、図２２に示すような各要素のランクを取得する。

次いで、ステップＳ７２では、判定部８２が、各要素のランクと各要素の実績重み付け係数とに基づいて、判定値（総合ランク）を算出する。具体的には、判定部８２は、Ａ＝５、Ｂ＝４、Ｃ＝３，Ｂ＝２，Ａ＝１などとランクを数値に置き換えて、当該数値と実績重み付け係数との積の合計値を算出する。そして、当該合計値を、合計値とランクとを関連付けたテーブルなどに基づいて、統合指標としての総合ランクに置き換えることとする。なお、実績重み付け係数は、ユーザが設定するものとする。ただし、これに限らず、実績重み付け係数は、判定部８２が適宜変更することとしても良い。また、判定部８２は、所定のルールに基づいて総合ランクを決定するとしてもよい。例えば、所定のルールとは、「各要素のランクの５０％以上がＡである場合は、総合ランクはＡ」や、「各要素のうち所定数以上が、Ｃ以上であれば、総合ランクはＣ」などである。

次いで、ステップＳ７３では、判定部８２が、総合判定の閾値と比較する。例えば、ランクＣを閾値とし、ステップＳ７２で算出されたランクとランクＣとを比較する。

その後は、図１２のステップＳ８０で、判定部８２が、ステップＳ７２において算出されたランクがランクＣより高い場合に、蓄積対象と判定する。そして、格納部８４は、ステップＳ９０において、検証対象（品目や文書）を、課題クレーム情報としてデータサーバ６０に登録する。

以上のように、本実施形態では、クレーム対応業務に係る品目や文書である可能性が高いものを、データサーバ６０に自動で登録することができる。したがって、ユーザは、登録された情報を見ることで、クレーム対応業務の情報を簡易に参照することが可能となる。

なお、上記においては、算出部８０が、時間的要素として２種類、人的要素として２種類、成果物要素として１種類の要素を抽出して、それぞれに対しランク付けを行う場合について説明した。しかしながら、これに限られるものではなく、算出部８０は、上記各要素のうちの少なくとも２つの要素を抽出してランク付けを行い、これらに基づいて統合指標としてのランクを算出するようにしても良い。

次に、図２３〜図２７に基づいて、本実施形態における定常状態の取得処理について詳細に説明する。なお、この処理では、図６（ａ）、図６（ｂ）、図７のテーブル（Ｔ２〜Ｔ４）の作成が行われる。

図２３には、本実施形態における定常状態の取得処理の一連の流れがフローチャートにて示されている。この図２３に示すように、まず、ステップＳ２００では、定常状態取得部８６が、時間的要素定常状態取得処理（承認日）を実行し、次いで、ステップＳ２１０では、定常状態取得部８６が、時間的要素定常状態取得処理（編集時間）を実行する。次いで、ステップＳ２２０では、定常状態取得部８６が、人的要素定常状態取得処理を実行し、更に、ステップＳ２３０では、定常状態取得部８６が、成果物要素定常状態取得処理を実行して、全処理を終了する。以下、各ステップについて具体的に説明する。

（Ａ）ステップＳ２００（時間的要素定常状態取得処理（承認日））について
図２４には、ステップＳ２００の具体的な処理の流れがフローチャートにて示されている。この図２４の処理では、まず、ステップＳ２０１において、定常状態取得部８６が、品目マスタＭ３の情報読込みを実行する。具体的には、図１０（ａ）の品目マスタＭ３のうちの１つの品番を読み込む。次いでステップＳ２０２では、定常状態取得部８６が、読み込んだ品目マスタＭ３の品番が承認済か否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２０４に移行する。一方、ここでの判断が肯定された場合、すなわち、読み込んだ品番が承認済みであった場合には、定常状態取得部８６は、ステップＳ２０３に移行し、図６（ａ）の時間的要素定常状態管理テーブルＴ２のキー（承認日付）ごとの値（カウンタ）を更新する。そして、ステップＳ２０４では、定常状態取得部８６が、品目マスタＭ３の情報読み込みが終了したか否かを判断する。ここでの判断が否定された場合、すなわち、まだ読み込むべき情報が品目マスタＭ３に残っている場合には、定常状態取得部８６は、ステップＳ２０１に戻り、その後、上記と同様の処理を繰り返す。一方、ステップＳ２０４の判断が肯定された場合には、定常状態取得部８６は、ステップＳ２０５に移行する。

ステップＳ２０５では、定常状態取得部８６が、文書マスタＭ４の情報読込みを実行する。具体的には、図１０（ｂ）の文書マスタＭ４のうちの１つの品番（文書番号）を読み込む。次いで、ステップＳ２０６では、定常状態取得部８６が、読み込んだ文書マスタＭ４の品番が承認済か否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２０８に移行する。一方、ここでの判断が肯定された場合、すなわち、読み込んだ品番が承認済みであった場合には、定常状態取得部８６は、ステップＳ２０７において、図６（ａ）の時間的要素定常状態管理テーブルＴ２のキー（承認日付）ごとの値（カウンタ）を更新する。そして、ステップＳ２０８では、定常状態取得部８６が、文書マスタＭ４の情報読み込みが終了したか否かを判断する。ここでの判断が否定された場合、すなわち、まだ読み込むべき情報が文書マスタＭ４に残っている場合には、定常状態取得部８６は、ステップＳ２０５に戻り、上記と同様の処理を繰り返す。一方、ステップＳ２０８の判断が肯定された場合には、定常状態取得部８６は、図２４の全処理を終了して、図２３のステップＳ２１０に移行する。

（Ｂ）ステップＳ２１０（時間的要素定常状態取得処理（編集時間））について
図２５には、ステップＳ２１０の具体的な処理の流れがフローチャートにて示されている。この図２５の処理では、まず、ステップＳ２１１において、定常状態取得部８６が、品目マスタＭ３の情報読込みを行う。次いで、ステップＳ２１２では、定常状態取得部８６が、初版以外で承認済か否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２１５に移行するが、ここでの判断が肯定された場合には、定常状態取得部８６は、ステップＳ２１３に移行する。

ステップＳ２１３では、定常状態取得部８６が、図１１（ａ）の構成マスタＭ５から、下位構成部品の数を取得する。品目「Ｐａｒｔ−００１」の場合であれば、定常状態取得部８６は、図１１（ａ）において、下位構成部品の数「３」を取得することができる。次いで、ステップＳ２１４では、定常状態取得部８６が、図６（ａ）の時間的要素定常状態管理テーブルＴ２のキー（部品数（構成数））と一致する行の、値の項目に編集時間を登録する。このようにして、ステップＳ２１４の処理が終了すると、定常状態取得部８６は、ステップＳ２１５に移行する。なお、値の項目に登録される編集時間は、品目マスタＭ３の承認日から作成日を差し引いて、時間に換算したものである。

ステップＳ２１５では、定常状態取得部８６が、品目マスタ情報読み込みが終了したか否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２１１に戻って、上記と同様の処理を繰り返すが、ステップＳ２１５の判断が肯定された場合には、定常状態取得部８６は、ステップＳ２１６に移行する。

ステップＳ２１６では、定常状態取得部８６が、文書マスタＭ４の情報読込みを行う。次いで、ステップＳ２１７では、定常状態取得部８６が、初版以外で承認済か否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２１９に移行するが、ここでの判断が肯定された場合には、定常状態取得部８６は、ステップＳ２１８に移行する。

ステップＳ２１８では、定常状態取得部８６が、図６（ａ）の時間的要素定常状態管理テーブルＴ２のキーの項目にファイルサイズを登録するとともに、値の項目に編集時間を登録する。このようにして、ステップＳ２１８が終了すると、定常状態取得部８６は、ステップＳ２１９に移行する。なお、値の項目に登録される編集時間は、文書マスタＭ４の承認日から作成日を差し引いて、時間に換算したものである。

ステップＳ２１９では、定常状態取得部８６が、文書マスタＭ４の情報の読み込みが終了したか否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２１６に戻って、上記と同様の処理を繰り返すが、ステップＳ２１９の判断が肯定された場合には、図２５の全処理（ステップＳ２１０）を終了して、図２３のステップＳ２２０に移行する。

（Ｃ）ステップＳ２２０（人的要素定常状態取得処理）について
図２６には、ステップＳ２２０の具体的な処理の流れがフローチャートにて示されている。この図２６の処理では、まず、ステップＳ２２１において、定常状態取得部８６が、メール情報をメールテーブルＴ５（図７（ｂ））から読込む。なお、メールテーブルＴ５に代えて、メールサーバ５０から直接メール情報を読み込んでも良い。

次いで、ステップＳ２２２では、定常状態取得部８６が、メールの内容（タイトル及び本文）に品目（品番）又は文書名が含まれているかを確認する。次いで、ステップＳ２２３では、定常状態取得部８６が、メールの内容に品目（品番）又は文書名が含まれていたかを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２２５に移行するが、ここでの判断が肯定された場合には、定常状態取得部８６は、ステップＳ２２４に移行する。

ステップＳ２２４に移行した場合、定常状態取得部８６は、図６（ｂ）の人的要素定常状態管理テーブルＴ３において、品目番号、文書番号に対してメールの情報を格納する。ここで、メールの情報には、図６（ｂ）に示すように、送受信日、宛先件数、及び宛先に含まれるグループ数、が含まれている。なお、グループ数は、宛先と、ユーザマスタ（図９（ａ））及び／又はグループマスタ（図９（ｂ））と、から特定されるグループの数である。その後、定常状態取得部８６は、ステップＳ２２５に移行する。

ステップＳ２２５では、定常状態取得部８６が、メール情報読み込みが終了したか否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２２１に戻って、上記と同様の処理を繰り返すが、ステップＳ２２５の判断が肯定された場合には、図２６の全処理（ステップＳ２２０）を終了して、図２３のステップＳ２３０に移行する。

（Ｄ）ステップＳ２３０（成果物要素定常状態取得処理）について
図２７には、ステップＳ２３０の具体的な処理の流れがフローチャートにて示されている。この図２７に示すように、まず、ステップＳ２３１では、定常状態取得部８６が、品目マスタＭ３の情報を読込む。次いで、ステップＳ２３２では、定常状態取得部８６が、読み込んだ情報（品番）が、承認済であるか否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２３５に移行し、肯定された場合には、定常状態取得部８６は、ステップＳ２３３に移行する。

ステップＳ２３３では、定常状態取得部８６が、関連文書マスタＭ６（図１１（ｂ））のうち、ステップＳ２３１で読み込んだ品番に対応する関連文書の情報を読込む。そして、ステップＳ２３４では、定常状態取得部８６が、図７（ａ）の成果物要素定常状態管理テーブルＴ４のうち、関連文書の種類に対する所有件数を登録（カウント）する。その後は、定常状態取得部８６は、ステップＳ２３５に移行する。

ステップＳ２３５では、定常状態取得部８６が、品目マスタＭ３の情報の読み込みが終了したか否かを判断する。ここでの判断が否定された場合には、定常状態取得部８６は、ステップＳ２３１に戻って、上記と同様の処理を繰り返すが、ステップＳ２３５の判断が肯定された場合には、定常状態取得部８６は、図２７の全処理（ステップＳ２３０）を終了するとともに、図２３の全処理を終了する。

なお、図２３の処理は、品目や文書が作成される毎、又は所定時間経過するごとに実行される。すなわち、図６（ａ）、図６（ｂ）、図７の各テーブルは、所定間隔で、更新されることになる。

以上、詳細に説明したように、本実施形態によると、算出部８０が、製品に関連して作成された１又は複数の情報（品目や文書ファイル）から複数の要素（時間的要素、人的要素、成果物要素）を抽出するとともに、当該抽出された要素から、前記製品の不具合の発生可能性を示す指標（ランク）をそれぞれ算出する。そして、判定部８２は、複数のランクに基づいて、製品に不具合が発生している可能性が高いか否かを判定し、その判定結果に基づいて、格納部８４が、要素を抽出した情報をクレーム対応業務に係る情報としてデータサーバ６０に格納する。これにより、本実施形態では、複数のランクから製品の不具合の発生可能性を判定するので、適切に不具合の発生の可能性を判定することができる。また、当該判定結果に基づいて、クレーム対応業務で作成された可能性の高い情報をデータサーバ６０に自動で格納することから、ユーザに登録作業等を強いることなく、クレーム対応業務で作成された情報を適切に格納することが可能である。また、本実施形態では、クレーム対応業務で作成された情報が、適切に格納されているので、後で、ユーザがクレームに対応する業務を行う際に、以前にクレーム対応業務で作成された情報を簡易に参照することが可能となる。

また、本実施形態によると、各要素から算出されたランクと各ランクの実績重み付け係数とを用いて統合指標としての総合ランクを算出する。したがって、本実施形態では、単に各要素のランクのみを用いて総合ランクを演算する場合と比べて、適切に総合ランクを算出することが可能である。

また、本実施形態によると、格納部８４は、外部のデータサーバ６０と接続されており、格納部８４は、データサーバ６０に情報を格納することとしているので、課題クレーム管理サーバ４０における負荷を低減することができる。

また、本実施形態によると、時間的要素、人的要素、成果物要素という、種々異なる要素のランクを組み合わせて総合ランクを算出する。したがって、本実施形態では、判定部８２は、様々な視点から算出されるランクに基づいて、クレーム対応業務の可能性が高いか否かの判定を行うことができる。これにより、データサーバ６０に登録される情報の信頼度を向上することが可能である。

また、本実施形態によると、定常状態のデータからの異常度（乖離度）に基づいて、クレーム対応業務の可能性が高いか否かを判定するので、通常業務における業務の反復性、共通性を考慮した、適切な判定を行うことが可能である。

なお、上記実施形態では、各定常状態管理テーブルＴ２、Ｔ３，Ｔ４を、新たな情報を用いて随時更新する場合について説明した。しかしながら、これに限られるものではなく、ある程度の期間でテーブルＴ２〜Ｔ４を作成した後は、更新をしなくても良い。また、新たな情報を用いてテーブルＴ２〜Ｔ４を更新する場合に、最も古い情報を削除するようにしても良い。また、上記実施形態では、クレーム対応業務に関する情報か否かにかかわらず、テーブルＴ２〜Ｔ４の更新に用いることとしたが、これに限らず、クレーム対応業務である可能性が高いと判定された場合には、その情報をテーブルＴ２〜Ｔ４の作成に用いなくても良い。

なお、上記実施形態では、時間的要因として、承認日、編集時間に着目し、人的要因として、電子メールへの品番や文書名の記載回数、宛先件数などに着目することとしたが、これに限らず、その他の時間的要因、人的要因に着目しても良い。

なお、本実施形態における課題クレーム管理サーバ４０の処理機能は、コンピュータによって実現することができる。その場合、課題クレーム管理サーバ４０が有すべき機能の処理内容を記述したプログラムが提供される。そのプログラムをコンピュータで実行することにより、上記処理機能がコンピュータ上で実現される。処理内容を記述したプログラムは、コンピュータで読み取り可能な記録媒体に記録しておくことができる。プログラムを流通させる場合には、例えば、そのプログラムが記録されたＤＶＤ（Digital Versatile Disc）、ＣＤ−ＲＯＭ（Compact Disc Read Only Memory）などの可搬型記録媒体の形態で販売される。また、プログラムをサーバコンピュータの記憶装置に格納しておき、ネットワークを介して、サーバコンピュータから他のコンピュータにそのプログラムを転送することもできる。

プログラムを実行するコンピュータは、例えば、可搬型記録媒体に記録されたプログラムもしくはサーバコンピュータから転送されたプログラムを、自己の記憶装置に格納する。そして、コンピュータは、自己の記憶装置からプログラムを読み取り、プログラムに従った処理を実行する。なお、コンピュータは、可搬型記録媒体から直接プログラムを読み取り、そのプログラムに従った処理を実行することもできる。また、コンピュータは、サーバコンピュータからプログラムが転送されるごとに、逐次、受け取ったプログラムに従った処理を実行することもできる。

上述した実施形態は本発明の好適な実施の例である。但し、これに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形実施可能である。

４０ 課題クレーム管理サーバ（情報管理装置）
４４ 入出力部（接続部）
６０ データサーバ（外部装置）
８０ 算出部
８２ 判定部
８４ 格納部

Claims (11)

1. 製品に関連して作成された１又は複数の情報から複数の要素を抽出するとともに、当該抽出された前記複数の要素ごとに、前記製品の不具合の発生可能性を示す指標をそれぞれ算出する算出部と、
   前記それぞれ算出した前記指標のうち２以上の指標に基づいて、前記製品に不具合が発生している可能性が高いか否かを判定する判定部と、
   前記判定部において前記製品に不具合が発生している可能性が高いと判定された場合に、前記要素を抽出した情報を、抽出情報記憶部に格納する格納部と、を備える情報管理装置。
2. 前記判定部は、前記それぞれ算出した前記指標のうち２つ以上を統合した統合指標を算出し、該統合指標と予め定められた閾値との比較結果に基づいて、前記判定を行うことを特徴とする請求項１記載の情報管理装置。
3. 前記判定部は、前記それぞれに算出した指標と当該指標ごとの重み付け係数とを用いて前記統合指標を算出することを特徴とする請求項２に記載の情報管理装置。
4. 前記格納部と、前記抽出情報記憶部を有する外部装置とを接続する接続部を更に備える請求項１乃至請求項３のいずれか一項に記載の情報管理装置。
5. 前記複数の要素は、前記情報の時間的要素、前記情報の人的要素、前記情報の成果物としての要素の少なくとも１つであることを特徴とする請求項１乃至請求項４のいずれか一項に記載の情報管理装置。
6. 前記情報の時間的要素には、情報に対する承認時期における定常状態との乖離度、及び／又は情報の編集時間における定常状態との乖離度が含まれることを特徴とする請求項５に記載の情報管理装置。
7. 前記情報の人的要素には、前記情報としての電子メールにおけるやり取り回数における定常状態との乖離度、及び／又は前記情報としての電子メールにおける宛先数における定常状態との乖離度が含まれることを特徴とする請求項５に記載の情報管理装置。
8. 前記情報の成果物としての要素には、前記製品に関連して作成された情報の種類における定常状態との乖離度が含まれることを特徴とする請求項５に記載の情報管理装置。
9. 前記算出部は、前記複数の情報のうち第一のアプリケーションによって作成された第一の情報から前記複数の要素のうち第一の要素を抽出するとともに、該第一のアプリケーションとは異なる第二のアプリケーションによって作成された第二の情報から前記第一の要素とは異なる第二の要素を抽出することを特徴とする請求項１乃至８のいずれか一項に記載の情報管理装置。
10. コンピュータが、
    製品に関連して作成された１又は複数の情報から複数の要素を抽出するとともに、当該抽出された前記複数の要素ごとに、前記製品の不具合の発生可能性を示す指標をそれぞれ算出する工程と、
    前記それぞれ算出した前記指標のうち２以上の指標に基づいて、前記製品に不具合が発生している可能性が高いか否かを判定する判定する工程と、
    前記判定部において前記製品に不具合が発生している可能性が高いと判定された場合に、前記要素を抽出した情報を、抽出情報記憶部に格納する工程と、を実行する情報管理方法。
11. コンピュータに、
    製品に関連して作成された１又は複数の情報から複数の要素を抽出するとともに、当該抽出された前記複数の要素ごとに、前記製品の不具合の発生可能性を示す指標をそれぞれ算出する工程と、
    前記それぞれ算出した前記指標のうち２以上の指標に基づいて、前記製品に不具合が発生している可能性が高いか否かを判定する判定する工程と、
    前記判定部において前記製品に不具合が発生している可能性が高いと判定された場合に、前記要素を抽出した情報を、抽出情報記憶部に格納する工程と、を実行させることを特徴とする情報管理プログラム。

Images