1
Download スライド 1 - PBL
Transcript
クレームデータ利用に関する検討 協力企業：ヒューテック株式会社 香川大学工学部 桑島 近間 ○ 溝口 和泉 聖大 亮介 大介 俊彦 目次 １．ヒューテックとは ２．品質管理・サポートの現状 ３．目的 ４．データ解析 ５．まとめ ６．提案 株式会社ヒューテック 本社：高松営業所 フィルムや紙、シートなどの表面に起こるキズ、しわ、 および異物の混入などの欠陥の検査機械を開発 これらのシートは食品包装、医薬品、フィルム、テー プ、液晶、壁紙などに利用されている 生産工場内ネットワークとリンクしたQCインライン システムを開発し、品質管理と生産性向上に貢献す るシステムを開発している テーマ決定の背景 お客様からの問い合わせやクレームは決められた項目にデータを 入力することでその内容を管理している 「対応受付記録」 としてデータベース化されている ㈱FUTECでは、クレームに関するデータを再発 防止策に活かせていない そこで・・・ 2年前のPBL活動で、問い合わせとクレームに関する データ解析が行われ、1年3ヶ月分の解析が行われた 蓄積したデータを利用するための提案には至っていない 対応受付記録のフォーマット 機種名や顧客名、対応受付日など 一般的な情報を入力する 問い合わせ内容の具体的な原因、対応内容、 対象部位などの情報を入力する 目的 現在まで蓄積したクレーム情報を使えるものにしたい データベースを用いて解析を進めた結果 クレーム完了率は90%を超えている しかしながら、完了までの日数がかかりすぎているのでは？？ 過去の事例を参考に新しいクレームへの 対応を手助けすることはできないか？ 蓄積したデータを有効利用することで、 クレーム対応の期間を短縮させるための提案を行う 解析データの分類 協力企業先からお借りしたデータは以下の期間のものとする 2006年7月 2007年1月 2007年7月 2008年1月 2008年7月 2009年1月 ～ ～ ～ ～ ～ ～ 2006年12月 2007年6月 2007年12月 2008年6月 2008年12月 2009年6月 総件数 341件 281件 286件 247件 301件 286件 総件数は1742件 ただし、この会社は作っている機種の種類が非常に多いため、 本解析では主要5機種以外を「その他」として扱うこととする 機種ごとの完了率 100% 90% 80% 70% 60% 50% MaxEye.P EasyMax. Mc MaxEye. AQuO PKD MaxEye.F ほぼすべての機種で完了率 は90%を超えている しかしながら・・・ ここまでは企業として当たり前！！ 早く解決して欲しい なぁ・・・ 完了までに要した時間 MaxEye.P 27 27 EasyMax. Mc 72 MaxEye. AQuO 34 52 PKD 44 94 MaxEye.F 35 107 0% 20% 46 40% 60% 80% 1週間以内 1週間～2週間 2週間～1ヶ月 1ヶ月～3ヶ月 3ヶ月～半年 半年～1年 1年以上 程度によって対応に必 要な時間も異なるが・・・ 一般的な感覚では1ヶ月以 内に完了して欲しい 100% グラフよりわかること ・ 1ヶ月以内で完了しているものは半分にも満たない ・ 1年以上かかっているものが多すぎる 完了までの時間を短縮させるためにデータを用いて何か工夫ができないか？ 完了までにかかる時間を短縮する工夫 京都大学の文献によると・・・ 新規クレームの約60%は、過去のクレームを 参考にすることで解決できる ただし、実際はそこまで 効率はよくない 原因：ヒューマンエラーが発生 類似パターンを検索できれば、対応期間の 短縮や正確性の向上につながる 手法 ① 検索システムを開発する ② クレーム内容からいくつかのキーワードを抽出する ③ 過去の事例の解決手段と照らし合わせ、解決のヒントを得る 良い事例．欠点画像 2007月05月：受付 本件では、担当者が以前にあったケースを覚えていた 欠点画像が表示されない。 「欠点」、「画像」、「表示」というキーワードに注目し、 過去の事例を検索する 検索パターン 欠点のみ ： 458件 欠点＋画像 ： 188件 欠点＋画像＋表示 ： 127件 欠点＋画像＋表示されない ： 28件 キーワードから過去の事例を参照することで、解決手順が絞られる 本件では、2006年8月に同様の事例を発見できた 良い事例の解決方法比較 ・ 過去の事例の解決までの手段概要（2006年8月） 1. 社内でわからない現象であっため、A社のBさんに相談 考えられるケースを教えてもらう 2. Bさんに入場してもらい、考えられるケースを確認 Dドライブの空き容量が不足していることを発見 3. 不要なフォルダを削除してもらい、容量を確保 解決した ・ 今回の解決までの手段概要（2007年5月） 1. 担当者が、以前あった現象と思いお客様に確認をお願いする やはり、空き容量の不足が原因だった 2. 不要なフォルダを削除してもらい、容量を確保 解決した 2007年5月の件は即日解決 ⇒ 経験があると解決時間の短縮につながる 悪い事例．画像にシマ模様 2009月2月：受付 本件では、一から対策を始めた 画像全面に黒白の縦シマが入る。 「画像」、「シマ」というキーワードに注目する 検索パターン 画像のみ ： 282件 画像＋スジ ： 10件 画像＋縞 ： 4件 画像＋シマ ： 2件 本件でも、同様の現象が2007年7月にあった それにも関わらず、2009年2月に受け付けたものは、 解決までに3ヶ月以上かかっている 悪い事例の解決方法比較 ・ 過去の事例の解決までの手段概要（2007年7月） 1. 特定のカメラのみでそのような画像なのかを確認 FV関連の基盤（IMM2・IMD2）が怪しいと予想 2. IMD2基盤を入れ替えて動作確認 この段階で問題なし 3. しばらく様子見し、再発があれば連絡 再発しなかったので、解決 ・ 今回の解決までの手段概要（2009年2月） 1. IMM3ハードを3.32に書き換え 2. 書き換え後再発していないため完了 解決までの手順はほぼ同じ ⇒ しかしながら、2009年2月に受け付けたもの は、解決までに3ヶ月以上かかっている わかったこと 解析活動からわかったこと ● 過去の事例が利用されると解決までの期間が格段に早い ● 過去の事例が解決に利用されていることが少ない 活動中に気付いたこと ● まとまりのない文、統一性のない単語で事例が 保存されている ● 故障箇所や原因箇所が明記されていない ● 対応完了までの最短手順が整理されていない 解析の結果からの提案 1. 検索エンジンの開発もしくは備え付け ・ 蓄積したデータを活かすために過去の事例を検索できる環境が必要 2. 入力段階での単語の限定・統一 ・ フリーワード検索の際、別の表現では検索にひっかからない Ex) 「シマ」と「スジ」の違い etc… ・ 初期段階では単語統一表などを作成して対応すると効果的 3. 入力する人は、後から見てわかりやすい入力をする ・ 故障箇所・不具合箇所を決められた部分に明記 ・ 解決までの最短手順を記入する項目を加え、順序を箇条書きすることで、 今後、同様の事例が発生したときの対応が素早く、かつ、らくになる これらを実行することでヒューマンエラーを減少させることができる 企業としてのクレーム対応力が向上する 謝辞 この度は、株式会社ヒューテックの開発部 廣苅様をはじめ、多田様、廣瀬様には大変 お世話になり、ありがとうございました。 また、香川大学の荒川先生にはこのような 貴重な体験の場を与えていただきました。こ こに感謝の意を示します。 解析手法 ・ 長期間の大量のデータを扱う ヒューテックさんから預かった過 去のデータをデータベース化し、 検索や集計を行えるようにした ・ 計数の簡易化 ・ 期間ごとのデータ推移の検索 ・ フリーワード検索 QCインラインとは・・・ 物の流れ 情報の流れ 製造工程（変換過程） 投入物 測定器 修正装置 品質測定データ 修正命令 品質測定 品質診断 品質情報 産出物 修正処置 修正案 QCインライン 品質管理を自動化するハードと それを高度情報化するソフトを融合化させたシステム 活動中にわかったこと ● まとまりのない文、統一性のない単語で事例が保存されている ・ クレームの内容が記入者によってバラバラ Ex) 内容をそのまま記入・内容をまとめて記入 etc… ・ 対応内容に統一性が必要 対応内容をすべて記入している現状も問題ないが、試した手順はすべて 示されているが、最短の解決手順の情報が不足 文でまばらに書かれているため、故障箇所や原因箇所がわかりにくい ・ 対応した日付を書ける項目を作ると、対応の項目がもう少しスッキリする ● 過去の事例が解決に利用されていることが少ない ・ 全く同様の事例が過去にあったにも関わらず、完了までに3ヶ月も要している 事例も存在した ⇒ 使えている事例は即日解決している ・ クレーム内容が同様であるにも関わらず、異なる対応から試しているケース が存在 ただし、件数の多い内容については、経験的に同様の対応を行っている 様子が伺えた 解析の結果からの提案 1. 検索エンジンの開発もしくは備え付け ・ 蓄積したデータを活かすために過去の事例を検索できる環境が必要 2. 入力段階での単語の限定・統一 ・ フリーワード検索の際、別の表現では検索にひっかからない Ex) 「シマ」と「スジ」の違い etc… ・ 初期段階では単語統一表などを作成して対応すると効果的 3. 入力する人は、後から見てわかりやすい入力をする ・ 故障箇所・不具合箇所を決められた部分に明記、もしくはその項目を作る ・ 解決までの最短手順を記入する項目を加え、順序を箇条書きすることで、 今後、同様の事例が発生したときの対応が素早く、かつ、らくになる これらを実行することでヒューマンエラーを減少させることができる 企業としてのクレーム対応力が向上する 良い事例1．欠点画像 2007月05月：受付 本件では、担当者が以前にあったケースを覚えていた 欠点画像が表示されない。 「欠点」、「画像」、「表示」というキーワードに注目し、 過去の事例を検索する 検索パターン 欠点のみ ： 458件 欠点＋画像 ： 188件 欠点＋画像＋表示 ： 127件 欠点＋画像＋表示されない ： 28件 ・キーワードから過去の事例を参照することで、解決手順が絞られる 事例1の解決方法比較 ・ 過去の事例の解決までの手段概要 A社のOさんに相談。 考えられるのは、領域画面のときは全画のデータはメモリ上にて扱っている。 領域書き込みにて、ファイルとして保存される。 一瞬表示されるメッセージは保存できなかったメッ セージでは？ 全画がファイルとして保存されていないので、結果として欠点モニタ画面では 表示 できなくなっている。 ただ、この装置は品種データや過去データなどの取りうる容量計算をし、そ れに 見合ったHDDを選定しているはずだが？ Oさんに入場してもらい、Ｄドライブの空き容量を確認してもらう。 160KBしか空いていない。 Ｄド ライブには、FUTECフォルダ以外に２つフォルダがあり、それらの合計が３ＧＢ程度 ある。 不要な フォルダを丸ごと削除してもらうよう指示。 このようなケースはイレギュラーなので、どう扱うか ・ 今回の解決までの手段概要 以前あった現象と思い、過去データをお客様に確認の上、削除してもらった。 現象変わらず。 Reportフォルダ（稼動履歴の情報が格納されている）が28GBもとっている。そのため、空き 容量が900MB程度しかない。空き容量確保の初期設定が1GBなので、新たな欠点データ が保存されても、すぐさま 削除されていると思われる。 Reportフォルダもお客様に確認の 上、削除してもらった。正常に動作。 即日解決している！ 悪い事例2．画像にシマ模様 2009月2月25日：受付 画像全面に黒白の縦シマが入る。 「画像」、「シマ」というキーワードに注目する 検索パターン 画像のみ ： 282件 画像+縞 ： 4件 画像＋シマ ： 2件 本件でも、全く同様の現象が過去にあった それにも関わらず、2009年2月に受け付けたものは、解決までに3ヶ月以上かかっている 過去の事例を用いることで、完了までの時間が短縮することは明らか 事例2の解決方法比較 ・ 過去の事例の解決までの手段 2007/07/02 ・まず特定のカメラのみそのような画像なのか？を確認してもらう。 また同時 期にもう1台MaxEye.F（52C5583と思われる）を納入しているので、基板を 入れ替えれるのであれば入れ替えてみて確認する予定。 FV関連の基板 （IMM2、IMD2）があやしそう… 2007/07/03 ・ IMD2基板を入れ替えてみて、動作確認するが問題なし。 52C5583の検査 機を使用するとのことなので、基板を元に戻すが、現象は再発せず。 パラメー タが正常に送信できていなかった？！ しばらく様子見し、現象再発するようで あれば、基板交換をお願いする。 2007/10/23 ・Bさんに状況確認し、7/3以降不具合連絡がないとのこと。 IMD基板の接触不 良が原因か？！ とりあえず完了とします。 ・ 今回の解決までの手段 ・添付の現象と思われるので、imm3ハード3.32に書き換え 2009/06/03 ・書き換え後現象が再発していないので一旦完了とします。 機種ごとの完了率 問い合わせ クレーム ほぼすべての機種で完了率は90%を超えている しかしながら・・・ ここまでは企業として当たり前！！ ユーザー側の気持ち 早く解決して欲しい なぁ・・・ MaxEye.P EasyMax. Mc MaxEye. AQuO PKD MaxEye.F MaxEye.P EasyMax. Mc MaxEye. AQuO PKD 100% 90% 80% 70% 60% 50% MaxEye.F 100% 90% 80% 70% 60% 50% 完了までに要した時間 MaxEye.P 23 EasyMax. Mc 40 MaxEye. AQuO 38 91 MaxEye.F 36 56 0% 20% 1日以内 1日～3日 3日～1週間 1週間～2週間 2週間～1ヶ月 1ヶ月～2ヶ月 2ヶ月以上 16 24 PKD MaxEye.P 6 46 40% 60% 80% 100% 問い合わせ 一般的に、問い合わせはすぐに返事が欲しい 27 27 EasyMax. Mc 72 MaxEye. AQuO 34 52 44 PKD 94 35 MaxEye.F 107 46 0% 20% 40% 60% 80% 1週間以内 1週間～2週間 2週間～1ヶ月 1ヶ月～3ヶ月 3ヶ月～半年 半年～1年 1年以上 100% クレーム クレームは、程度によって対応に 必要な時間も異なるが・・・ 即日解決は半分程度 1ヶ月以内に完了する必要があるのでは？ 問い合わせに関して、もう少し早く完了に 向かう努力が必要なのでは？ 1ヶ月以内で完了しているものは半分に も満たない 1年以上かかっているものが多すぎる 事例1．波形モニタ 2008月11月28日：受付のクレーム内容 波形モニタのエンド側、視野端ギリギリにセットしている糸が カメラ直、基板のチェックピンでは確認できるが波形モニタに 現れない 「波形」、「モニタ」、「エンド」、「基板」というキーワードに注目する 検索パターン 波形のみ ： 83件 波形＋モニタ ： 16件 波形＋モニタ＋エンド ： 3件 波形＋モニタ＋エンド＋基板： 0件 ・キーワードから過去の事例を参照することで、解決手順が絞られた ・本件では3つのキーワードを基に検索した結果、類似内容の解決手順だった このように考えた場合、まとまりのない文で事例が保存されている 事例1の解決方法比較 ・ 過去の事例の解決までの手段概要 2007/03/20 一度、PC→盤へパラメータを送信してもらうよう依頼。 単純にエッジの端をとっ ている？ 両サイドのマスク量を大きめにしてみてはどうか？ ・添付波形モニタ のハードコピーが送られてきたが、系列1のエンド側で余分に検査幅を設定し ているようにみえる。 → 現地Sysデータで、再度パラメータを確認したところ系 列1の1ch視野幅が470mmのところが440mmの設定になっている。これが原 因の可能性あり。設定を変更して、様子見してもらう。 2007/04/14 長期間、現象再発など連絡なしのため【完了】とする。 ・ 今回の解決までの手段概要 2008/12/02 現地で状況の確認 2008/12/05 社内で聞き込みと再現調査 SBLの外側にある糸は波形モニターでは見れ ない 波形モニターエンド側の拡大は拡大させたいスタートビットとそこから の見たいビット数を入力してください。 以上の内容を伝えた。 なぜ調整時 に波形モニタを使用しているのかの確認が必要 調整時に波形モニタを使用したのは現場と制御盤が離れているので2手に 分かれて作業していたため（BLを変更するとき） 2008/12/17 2008/02/05 現地で問題にはなっていないため一旦保留 問い合わせ内容が分類分けされていない やりとりの内容のキーワードを含めた箇条書き Subjectの中にもう少しキーワードが欲しい Bodyの要約が欲しい（） 結局何が問題だったのかを統一した単語で明確に記入すべき 入力率 100% 80% 60% 入力あり 入力なし 40% 20% 100% 原因箇所 （Reason） 改善管轄 （Demarcation） 致命度 （Critical） 修正箇所？ （ENQ） 修正対応の扱い？ （Body） 対象範囲？ （Subject） 80% 轄 60% 管 善 改 原 因 個 所 （R ea so n） （D em ar ca tio 致 n） 命 度 （C rit 修 ic 正 al） 箇 修 所 正 ？ 対 （E 応 NQ の 扱 ） い ？ 対 （B 象 範 od 囲 y） ？ （S ub jec t） 0% 40% 20% 0% 2006. 7～12 2007. 1～6 2007. 7～12 2008. 1～6 2008. 7～12 2009. 1～6 修正箇所・修正対応の扱い・対象範囲についてはきちんと記入されている。 しかし、それ以外の原因箇所であったり、改善管轄、致命度は2年前の提案があった にも関わらず、改善されるどころか減少傾向が見られる。 MaxEye.P AccureX2 AccureX PMAX FMAX MaxEye.C MaxEye.FM MaxEye.next80 FMAX-MR EasyMax EasyMax.MC(オフ輪) EasyMax.GS EasyMax.NEO AMAX EasyMax.R MaxEye.REVO MaxEye.PM MaxEye.CORE EasyMax(オフ輪) EasyMaxImpact その他 MaxEye.F PKD MaxEye.AQuO EasyMax.Mc 件数（件） 機種ごとの問い合わせ・クレームの総件数 600 500 400 300 200 100 0 機種名 400 350 350 150 100 150 100 PKD MaxEye.F 0 MaxEye.P 0 EasyMax. MC 50 MaxEye. AQuO 50 問い合わせ クレーム 3年間のデータを総合した場合 100 80 長期不具合 クレーム対応 問い合わせ 60 40 20 ・ MaxEye.Fについては問い合わせ・ クレーム件数ともに多い ・ PKDでは問い合わせ件数の多さが 目立つ MaxEye.P EasyMax. MC MaxEye. AQuO PKD 0 MaxEye.F 全件に占める割合 200 MaxEye.P 200 250 EasyMax. MC 250 300 MaxEye. AQuO 300 PKD クレーム件数（件） 400 MaxEye.F 問い合わせ件数（件） 主要5機種の問い合わせとクレーム件数の内訳 問い合わせが多い項目は、取扱説明書 を工夫すれば減少できるのでは？ MaxEye.P EasyMax. MC MaxEye. AQuO PKD 0 10 5 0 機種ごとのまとめ ・ 問い合わせ全件のうち、PKDの問い合わせ割合が約20%ある ・ PKDとMaxEye.Fの件数を合わせると約40%がこの2機種で占めている ・ クレーム全件のうち、MaxEye.Fが約25%である ・ MaxEye.F・PKD・MaxEye AQuOの3機種で50%以上を占めている MaxEye.P 5 15 EasyMax. MC 10 20 MaxEye. AQuO 15 クレーム PKD 20 25 MaxEye.F 問い合わせ 各機種に占める割合（%） 25 MaxEye.F 各機種に占める割合（%） 全機種に対して主要5機種の相談件数が占める割合 問い合わせ・クレーム件数の推移 新機種 旧機種 20 09 .1 ～ 6 12 ～ 08 .7 20 08 .1 ～ 6 12 ～ 07 .7 20 20 07 .1 ～ 6 12 ～ クレームは一定の傾向はみられない 250 問い合わせは2008年7月以降増加している 200 150 問い合わせ増加した原因が、新機 種出荷のためではないかと考えた 100 50 6 09 .1 20 ～ 08 .7 20 ～ 12 6 20 08 .1 ～ 12 20 07 .7 ～ ～ 07 .1 20 06 .7 ～ 12 6 0 20 問い合わせ件数（件） 300 100 50 0 06 .7 20 07 .1～ 6 20 07 .7～ 12 20 08 .1～ 6 20 08 .7～ 12 20 09 .1～ 6 20 06 .7～ 12 150 100 50 0 300 250 200 150 20 件数（件） 件数（件） 350 300 250 200 350 クレーム 350 20 問い合わせ 増減は旧機種の増減傾向に依存し ているため、新機種が原因ではない まとめ・わかったこと 問い合わせ・クレーム件数が多い上位5機種について ・ PKD・MaxEye.Fの問い合わせ件数が多い ・ PKDの問い合わせ・クレーム件数は順調に減少している ・ EasyMax.MCの問い合わせ・クレーム件数が2008年7月以降急激に 増加している ・ クレームに関してみると、MaxEye.F・PKD・MaxEye AQuOの3機種で 50%以上を占めている 完了までの時間について ・ 問い合わせから完了まで2週間以内に完了しているものが少ない ・ クレーム対応では3ヶ月以内に完了しているものが多い一方、12ヶ 月以上完了していないものの件数も非常に多い 解析の結果からの提案 その1 問い合わせ件数が多い機種では、内容を確認し、 簡単な取扱説明書で解決できるようなものであれば そういったものを添付することで問い合わせ件数は 減少するのではないか？ 問い合わせについては2週間サイクルで、クレーム については3ヶ月サイクルで、現状を担当社員全員 が把握できるようなシステムを構築する必要 解析の結果からの提案 その2 2008年以降に急増したEasy Max. MCについて問 い合わせ・クレーム件数が増加していることに対す る検証と対策 MaxEye.F・PKD・MaxEye AQuOでのクレームが 全体の50%を超えていることから、これら3機種のク レーム内容の検証 もし、クレームの原因になっている箇所が重なっているならば、 そこを改善することでクレーム件数を急激に減らすことができる 各機種の問い合わせ・クレーム件数の変化 MaxEye.F PKD MaxEye.AQuO EasyMax.MC MaxEye.P 80 20 08 .7 20 09 .1 ～ ～ 6 12 6 ～ 08 .1 20 ～ 07 .7 20 ～ 06 .7 20 6 6 ～ 09 .1 ～ 08 .7 20 20 6 ～ 08 .1 ～ 07 .7 20 20 6 ～ 07 .1 20 ～ 06 .7 12 0 12 0 12 20 12 20 12 40 ～ 40 60 07 .1 件数（件） 60 20 件数（件） 80 MaxEye.F PKD MaxEye.AQuO EasyMax.MC MaxEye.P 100 20 100 機種ごとの時系列変化のまとめ ・ PKDでは問い合わせ件数もクレーム件数も順調に減少している ・ EasyMax.MCでは、2008年7月以降、問い合わせ件数もクレーム件数 も急激に増加している この増加が全体の問い合わせの増加に効いている それぞれの内容を解析し、原因を明らかにすることが必要 EasyMax.MCの問い合わせ・クレーム部位 不明 2% その他 4% 不明 6% その他 18% ソフトウェア 36% 仕様 16% ソフトウェア 57% 仕様 21% 50 40 30 ハード 17% ハード 23% 50 その他 不明 仕様 ハード ソフトウェア 40 30 20 20 10 10 0 0 2006. 7～12 2007. 1～6 2007. 7～12 2008. 1～6 問い合わせ 2008. 7～12 2009. 1～6 その他 不明 仕様 ハード ソフトウェア 2006. 7～12 2007. 1～6 2007. 7～12 2008. 1～6 クレーム 2008. 7～12 2009. 1～6 MaxEye.Fの問い合わせ部位 不明 4% 50 その他 7% 40 仕様 10% ハード 18% その他 不明 仕様 ハード ソフトウェア 30 ソフト 61% 20 10 0 2006. 7～12 2007. 1～6 2007. 7～12 2008. 1～6 2008. 7～12 2009. 1～6 2年前のPBL実施による提案 1. 入力率の向上 ・ 現在のデータベースには、未入力の項目が多く見られる データ解析が十分に行えていない原因の一つ ・ フィードバックに不可欠な項目は必ず入力する 原因箇所・修正箇所・対象範囲・致命度 etc… 2. 1ヶ月ごとのデータ解析 ・ 日数が経つにつれてクレーム対応などの処理が完了しづらくなっていると いう結果が出ていることから、クレームデータなどを定期的に把握する必要性 3. 社内伝達システムの構築 ・ １ヶ月分のデータを周知することでクレームなどの長期間放置を防止する PKD 問い合わせ 100 80 40 0 0 ～ 6 20 08 .1 ～ 6 ～ 12 20 09 .1 60 20 09 .1～ 6 80 20 08 .7 20 PKD クレーム 20 08 .7～ 12 20 20 08 .1～ 6 0 ～ 12 0 20 07 .7 20 ～ 6 20 20 07 .1 80 20 07 .7～ 12 40 ～ 12 40 20 06 .7 60 件数（件） 100 20 07 .1～ 6 60 件数（件） 6 12 6 ～ ～ 20 09 .1 20 08 .7 12 6 ～ ～ 20 08 .1 20 07 .7 12 ～ ～ Max Eye. F 問い合わせ 20 06 .7～ 12 20 09 . 1～ 6 20 08 . 7～ 12 20 08 . 1～ 6 20 07 . 7～ 12 100 20 07 .1 20 06 .7 件数（件） 100 20 07 . 1～ 6 20 06 . 7～ 12 件数（件） 各機種の問い合わせ・クレーム件数の変化 Max Eye. F クレーム 80 60 40 6 9. 1～ 20 0 .7 ～ 12 0 20 08 0 6 20 8. 1～ 20 20 0 100 .7 ～ 12 Easy Max. Mc 問い合わせ ～ 6 12 ～ 20 09 .1 20 08 .7 ～ 6 12 ～ 20 08 .1 20 07 .7 0 20 07 0 ～ 6 20 20 07 .1 20 6 40 12 80 7. 1～ 60 ～ 件数（件） 40 100 20 0 20 06 .7 件数（件） 60 .7 ～ 12 80 件数（件） 6 ～ 12 6 ～ ～ 20 09 .1 20 08 .7 6 12 ～ 20 08 .1 20 07 .7 ～ 12 ～ 20 07 .1 20 06 .7 Max Eye. AQuO 問い合わせ 20 06 6 .1～ 09 20 12 ～ 20 08 .7 6 .1～ 08 20 12 ～ 20 07 .7 6 .1～ 100 07 件数（件） 100 20 12 ～ 20 06 .7 各機種の問い合わせ・クレーム件数の変化 Max Eye. AQuO クレーム 80 60 40 Easy Max. Mc クレーム 80 60 40 各機種の問い合わせ・クレーム件数の変化 Max Eye. P 問い合わせ 100 80 ～ 20 09 .1 ～ 20 08 .7 6 12 6 ～ 6 ～ 20 08 .1 20 06 .7 ～ 6 ～ 09 .1 20 6 20 08 .7～ ～ 08 .1 20 6 20 07 .7～ ～ 07 .1 20 20 06 .7～ 12 0 12 0 12 20 12 20 12 40 20 07 .7 40 60 ～ 60 20 07 .1 件数（件） 80 件数（件） Max Eye. P 問い合わせ 100 機種ごとの時系列変化のまとめ ・ PKDでは問い合わせ件数もクレーム件数も順調に減少している ・ EasyMax.MCでは、2008年7月以降、問い合わせ件数もクレーム件数 も急激に増加している この増加が全体の問い合わせの増加に効いている それぞれの内容を解析し、原因を明らかにすることが必要 長期不具合についての扱い 16 14 12 件数（件） 10 8 6 4 2 0 2006.7~12 2007.1~6 2007.7~12 2008.1~6 2008.7~12 2009.1~6 期間 何をもって長期不具合とされているか基準がなく不明 2008年以降、使われている様子がない 入力率 件数 機種 対応内容 ステータス 完了日 25 13 1 329 入力率 1.0 0.5 0.0 12.9
