製品が出荷された後のフィールドにおける製品の品質保証、クレーム対応等を通じて、
顧客の満足度を向上するために行う。
また、「合格後の製品に対する責任は品質保証部門にある」との自覚を持ってアフターサービスに望むことが肝要である。
クレーム処理
フィールドからの製品に対するクレームは、一般的に営業やSEを経由して品質保証部門に連絡が入ってくる。
品質保証部門は速やかに事故の速報を発行し関連部署に展開する。
この場合「チームワークによるサービス」という基本的な考えに基づいて行動すること。
クレーム処理は、初動調査が重要であり、受付時に現象の把握と資料の採取(製品ごとに的を絞った調査表を作成すると良い)を十分に行う必要がある。
【チームワークによるサービス】
自分の担当製品でなくても、それに対する顧客の苦情や要望も伺い関連部署に正確に連絡し回答や対策などをフォローする心構えが必要である。
・ 他部署の製品であっても、協力し合って対処する。
・ 他人にかかってきた電話でも要件を聞いて、できる限り対応するよう心がける。
・ 問題解決に当たっては、上長や設計部署、その他関連部署の協力を得ること。
独力で解決しようとして、重要度や緊急度の判断を誤らぬこと。
・ 顧客からの要望事項は、担当外の製品であってもよく伺い、担当部署に連絡をすること。
チームワークで仕事をするときは、良いコミュニケーションにより、情報の流れを良くすることが大切である。
「報告、連絡、相談」→ホウレンソウ
【アフターサービスの品質水準】
社外事故連絡に対する回答日数:原則1日以内、一週間を超える場合は中間回答をする。
社外事故対策版の発行:目標一週間以内、最大でも1ヶ月とする等。
事故の対策は、顧客に及ぼす迷惑(不稼働時間)を最小限にとどめることを主旨として行動する。
また、事故の解決まで顧客が不安感をもって使用することを考えれば、一刻も速く解決するよう努めなければならない。
しかしながら、事故対策の失敗は、事故で失った信用を更に悪化させることになるので、慎重の上にも慎重を期して行わなければならない。
対策の遅れによる同件事故の再発もさることながら、対策失敗による二重事故は顧客の信頼を大きく損なう。
このため回避策がある場合は、十分な時間を頂き修正確認を誤り無く行う方が良い。
一般的には、各企業内で定めた「事故対策について(基本と心得)」と言ったようなマニュアルに従って行動すること。
プロジェクトが順調に進展し、最終の総合試験や運用訓練試験もほぼ予定通りに消化できれば、予定通りめでたく稼動にこぎつくことができるが、混乱プロジェクトでは中々バグ収束にいたらないで、顧客から「予定通り稼動できるのか?」、「何時になったら稼動できるのか?」等の厳しい判断を迫られることになる。
■品質安定状況の見極め
バグの収束状況を見るためにはバグ発見解決曲線が一般的判断資料となるが以下の事項に注意されたい。
・ バグ半減化(1/2)低減経験則(サチッても まだ半分 バグ残る)
多くのプロジェクトを見ると一般に単体テスト、組合せテスト、総合テストとテストの結合性が上昇するにつれて発見されるバグの数は段階的に約1/2(1/3~2/3)に低減する。
従って現在完了したテスト段階でN件のバグが発見されたとしたらまだ0.5N件前後のバグが残っていると推定せざるを得ない。
・ テストをしなければバグは発見されない(サボれば サチる バグ曲線)
バグ曲線の飽和状況を見て安定したと思うのは早計である。
テストをしない日はバグも発見されないから曲線は横ばいになるのである。
チェック項目の消化が進んだのにバグが発見されない時にはじめて安定状態になったと言える。
・ 何をテストしてきたのか(同じこと 何回やっても バグとれず)
この質問に的確に回答できるプロジェクトなら、テスト開始前に、テスト計画の設計がキチンと出来たプロジェクトであり、追加テスト項目として何をすればよいかすぐわかる。
とかく担当任せきりにしていると、追加テストをさせたつもりでも追加にならず、単に過去のテストのやり直しをしているのに過ぎないと言うようなことになってしまう。
バグ分析をして今までのテストでバグの多かった部位を狙ってテストするのは当然としても、網羅性となると怪しくなる。
■稼動開始可能日の判定
正しい判断は所詮無理であるが、品質安定状況、追加テスト日程計画等何時システムが稼動可能状況になるか判断せざるを得ない。
このためにも過去に経験したプロジェクトの実績や似たような他のプロジェクト例の実績データを集めておくことが必要である。
■事故発生時の影響を冷静に判断しよう
事故がおきたときに、迷惑を受ける人、影響を受ける対象範囲、影響を受ける時間など、多面的に分析し、事故の被害を顧客と共によく認識し合って、稼動に突入してよいかどうか判断しなければならない。
いずれにしても、稼動後の品質状況をいかに見通すかが重要である。
事故時に迷惑する人は:ユーザ社内だけ、+取引業者、+取引顧客、+一般顧客、+不特定者
影響を受ける対象、範囲:特定品(特定の口座/銘柄、製品/装置、列車/ホテル等等)か全対象か
影響を受ける時間:分以下、1時間以下、半日以下、全日
予防保守とは、
一度発生した障害を他の顧客で発生させないようにすることである。
一般には、最初の事故が発生した時には一生懸命対策するが、同件事故(同じ原因で二度目以降に発生した事故)には鈍感になる傾向がある。
しかし、顧客にとっては、それは初めての事故であり、重要性に変わりは無い。
かえって、原因が判っている不良を対処せずに放置されたとなると一層不信感を招く結果となる。
同件事故防止は、
品質保証部門の重要な職責であり、稼動品質を管理し社外事故が多発していたり同件事故が多いときは、予防保守を最優先で行う必要がある。
予防保守は、目的によって次のことを行う。
・対策版の作成
新たな顧客に出荷される製品に不良修正を行う物であり、社外事故の発生頻度に応じて発行する。
目標1週間以内、最大でも1ヶ月とする。
・修正情報の作成
重大な不良や同件事故の多発が予想される場合は、1件1件の不良対応にプログラムの暫定的な修正方法(パッチ)を、対象となる全顧客に適用する。
・マニュアル補足版の作成
次に示すような物があり、あくまでもマニュアルを補完する物でありマニュアルと同様に扱うこと。
ーマニュアルの訂正のお知らせ
ー使用上の注意事項のお知らせ
ー一時的制限事項のお知らせ等
品質に関するコンサルテーションは、今後、重要なサービスの一つとなる分野でしょう。
ここで述べる品質コンサルは、これまで述べてきたことを具体的に実践する際の援助である。
現実は、品質保証活動の組織そのものは、企業によって異なり、多くの場合、それは企業文化や歴史に依存する。
品質保証活動の規模や編成は、扱うプロジェクト、実装や関連するビジネスプロセスの複雑さによってさまざまに異なる。
更に、企業によっては、アウトソーシングも含めて品質保証を実施しなければならない。
アウトソーシング(品質保証活動そのものも含めて)に適している分野はどこか、社内に留保すべき領域はどこかを把握し、そうした企業の意思決定をも支援することになる。
最近の「品質保証活動のあり方」カテゴリーもっと見る
最近の記事
カテゴリー
- 心と体(19)
- 植物:全般(119)
- 美しい雑草(52)
- 雑草(49)
- 観葉植物/ハーブ(29)
- 多肉植物/サボテン/菫(19)
- 秋の七草(12)
- 野菜(25)
- つる性植物/薔薇(27)
- シダ/芝/希少種(16)
- 苔(13)
- 春の七草(2)
- 樹木:全般(143)
- 剪定(10)
- コニファー/ヒペリカム(15)
- 衰退・枯死・治療等(14)
- 果樹(13)
- 躑躅/皐月(16)
- 桜/梅(26)
- 紫陽花/雪柳(20)
- 百日紅/山法師/花水木/空木(17)
- 楓/紅葉(18)
- 松/多行松(30)
- 木犀/木斛/餅木/椿/槐(27)
- 樫/欅/曙杉(28)
- ジブリ:全般(2)
- 大倉庫(4)
- 魔女の谷(4)
- もののけの里(3)
- どんどこ森(5)
- 青春の丘(9)
- モリコロ:全般(15)
- センターエリア(31)
- 南エリア(18)
- 東エリア(8)
- 西エリア(16)
- 日本庭園(19)
- 北エリア(16)
- 動物等(38)
- 楓池・めだか池(17)
- マンション;全般(44)
- ;動物・昆虫等(32)
- ;近辺(42)
- みよし;ため池巡り(17)
- ;神社仏閣(9)
- ;ボランティア活動(5)
- ;モニュメント巡り(52)
- お城(8)
- 庭園・公園(33)
- 偉人(話題の人)(19)
- 宇宙(10)
- 旅行等(26)
- コラム・つぶやき(43)
- 同窓会等;全般(8)
- ;にわか師会(22)
- ;群馬同窓会(7)
- ;NPO協力会(13)
- 品質保証活動のあり方(46)
- コンピュータとの思いで(38)
バックナンバー
2007年
2001年
2000年
人気記事