2010/08/01の記事の続きです。
中野医療器株式会社のQMSの(現状の)問題点は他にもあります。
◆外注部品の不良率が改善しない。
・コストダウンの要求が厳しく、外注先を価格の安いところへ変えた。
・たくさん作って利益を確保するのに精一杯で、改善している暇などないのだろう。
「不良が見つかったら返品してくれればいいですよ。」というスタンス。
・たまに指導にも行っているが、効果は無い。
・不良品は受入検査で止めている。
そこで"見えないコスト"がかかっているのは承知している。
この点は、審査員からも「何とかするように」と言われているそうなのですが、
はたしてそうでしょうか?
「安かろう悪かろう」というのは、ある意味経済の原則であり、避けがたいものです。
たとえ信頼できる外注先であっても、受入検査をしないわけにはいかないので
そのコストは減ることはあってもゼロにはなりません。
ただ、受入検査で不良を発見できなかったら問題です。
外注部品を自社製品に組み込んで、完成してから出荷直前に不良に気付いた場合、
組み立てにかけた手間と時間が無駄になります。
これほど悲しい無駄はありません。
検査の手間というのは、流通の過程で、
結局どこかで誰かが負担しなくてはいけないものです。
それを外注先にはさせず、自社で負うからその分価格が安くなっているわけです。
そういう意図ではないでしょうが、事実としてそうなっています。
中野医療器がまずやるべきことは、外注部品の不良率が高いことで、
どれだけのコストが自社内に発生しているかを、ちゃんと把握することでしょう。
「返品作業にかかる手間」も含め、「不良率が○%以内だったら発生しないはずのコスト」
を計算してみると良いと思います。
その結果、「現在の購入額は十分安く、検査作業を自社で負担しても黒字である。」
という答えが出たのであれば、何の問題もありません。
審査員からあれこれ言われす筋合いも無ければ、
自社の問題として改善する必要もありません。
逆に、「赤字だ」という答えが出たのであれば話は別です。
外注先と、
「うちに納入する前にこれだけの検査はちゃんとやってくれ。
そのために価格が○円上がっても良い。」
と交渉をすべきです。
それが受け入れられ無かったら、受け入れてくれる外注先を探せば良いのです。
不良品対応というのは通常業務の中に埋没しがちで、
それゆえに「見えないコスト」と呼ばれたりすることもあります。
それをリアルな数字として計算するのは大変だと思いますが、
逆を言えばその大変な事をやってこそ「マネジメント」なわけですから、
なんとか取り組んで欲しいと思います。
ここで大事なのは、審査員の言うことを
全て真に受け、プレッシャーに感じる必要は無いということです。
別に規格は「外注品の不良率を○%以下に抑えなさい」なんてことを
要求はしていませんから。
もちろん低い方が望ましいのは当然ですが、
「では、どれだけ低ければ十分だと言えるのか?」は、
企業が自身の判断で決めて良いことです。
(外注先に「何らかの選定基準」を定めることは、規格要求事項の中にあります。)
だからといって、さしたる根拠もなく「今期は外注不良率○%減!」なんて
"もっともらしい"目標を立ててしまうと、
自分で自分の首を締めることになるので注意が必要です。
(目標を立てた後で、さらなるコストダウンが要求される可能性もありますから。)
「仕事の成果」とは、多くの場合複合的なものです。
一部だけを切り取って目標化すると、まず上手くいきません。
「目標の立て方」自体、本当は結構奥が深いはずなのですが、
そこを意識している企業は意外と少ないのかもしれません。
つづく。
カテゴリー: 品質(ISO9001)
月刊アイソス 2010年8月号(No.153) 感想
ISOに関わる業務をしている者にとって、
何かと示唆に富む記事の多い月刊アイソス。
本日の当投稿は、8月号P62~65の
「5年後の品質マネジメントシステム」(連載第5回)
を読んでの感想文です。
取り上げられているのは中野医療器株式会社。
20名ほどの医療系製造業です。
「ISO13485」という医療機器の品質マネジメント規格の認証を取得していますが、
製造しているのは家庭用の医療機器であり、手術用具メーカーほど
衛生的にシビアではないため、事実上ISO9001とあまり変わらないそうです。
記事を執筆しているのは、この会社をコンサルした
宇野通(株式会社ケー・シー・シー チーフコンサルタント)という方で、
中野医療器のQMSの、導入によるメリット、そして上手くいっていない点を
だいぶ踏み込んで書いています。
QMSを通じて業務改善に成功した点として、
「生産計画(営業、製造現場、資材購買の連携など)が
きちんと立てられるようになった。」
ということが挙げられています。
そんなことは、QMS以前に"企業として"やって当たり前でしょ、
と言ってしまえばそれまでなのですが、
なかなかそれが出来ていないのも中小企業の現実です。
「認証取得」という大義名分を振りかざすことで
きちんとした体制が作れたのなら、それはそれで良いことです。
社長クラスの高い視点から見たら
ISOも所詮は会社運営のためのツールの一つなのですから、
現場を動かすために「こう言えば効きそうだ」と思ったら
迷わず言えば良いのです。
「ISOで決めたルールに従っていろいろ準備するのは面倒ですが、
ISOの審査のために困るというよりも、
物を作って品質を確保するために必要です。
ただし、ISO13485で必須だという意識がなかったら、
崩れていくかもしれません。
ちゃんと維持できているのは、ISOの効果だと思います。」
と書かれています。
上手くいっていない点として、まず「品質目標」が挙げられているのですが、
この部分は読んでいて引っ掛かるところが多くありました。
総務など管理系の部門は、無理矢理品質目標を設定してもしょうがないとの理由で
一度は品質目標から外したそうです。
極めて常識的な判断だと思います。(別に設定しても問題ではありませんが。)
ところが、審査員から「全ての部門で品質目標を設定しなくては不適合。」
と言われ、形式的なのを承知で設定したそうです。
これは大きな誤りです。
規格は「全ての部門で品質目標を設定しなさい」などと要求してはいません。
ISO13485:2003の規格原文5.4.1によると、
ISO9001と同じ「relevant funcions」となっています。
relevantとは「関連する」という意味であり、
ISO9001の日本語訳では、「しかるべき」となっています。
また、↓西沢総研のサイトでも、(ISO9001ですが、)
http://www.n-souken.com/news/news081003.html
規格改定の意図にまで踏み込んで「全ての部門ではない」ことが説明されています。
もちろん、企業が自主的にやるのは別に構わないのですが、
「不勉強な審査員と、その言いなりになる企業」が
経営判断から乖離した規格ごっこをしている印象を受けました。
(犠牲になるのは現場です。)
審査員からこのような"会社のためにならない"不適合を受けたら、
その場で言い返せずとも、しっかり調べてから
審査機関へ苦情を入れるのがよいでしょう。
つづく
「設計・開発」とは <5> レビューと検証と妥当性確認 【対象(後編)】
しばらく続いた 「ISO9001 7.3 設計・開発」についてのシリーズも、
今回でいったん一区切りです。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
<観点2> 「何を○○するの?」
◆妥当性確認:2010/2/6の記事でも触れましたが、対象となるのは
「結果として得られる製品」であり、それが
「指定された、意図された用途」に適うかを確認するのが
「妥当性確認」です。
実際に作ったモノをじっくり見てみたら、設計図を描いているときには
なかなか気付かないような不備に気付くかもしれません。
あるいは、それを現場の職人さんが修正した痕跡を見つけるかもしれません。
はたまた、製造技術の限界により、設計者の意図通りに作られてない点が
発見できるかもしれません。
私がISO9001に関わるよりずっと前の、製造業向けCAD・CAMシステムの
営業をしていた頃にによく耳にしたことですが、
設計という作業は、決してお絵描きではありません。
描いて終わりではないのです。
あくまでも、実際に作られる「モノ」こそが大事であり、
設計・開発というのはモノに至るまでの前工程の一つです。
だからこそ、設計・開発の質を評価しようと思ったら、
「現物」なしには語れないのです。
実際に顧客に届けられる製品(やサービス)の品質に対して、
製造現場だけでなく組織全体・全工程がそれぞれの責任を果たす、
というのがISO9001の主旨なのだろうと勝手に解釈しています。
「設計・開発」とは <4> レビューと検証と妥当性確認 【対象(中編)】
珍しく連続投稿です。
いつもこの筆不精なブログをお読みいただいている皆様、本当にありがとうございます。
妥当性確認は後編に回し、今回の中編では設計・開発の検証(7.3.5)のみを取り上げます。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
<観点2> 「何を○○するの?」
◆ 検 証 :これは比較的分かりやすい部分です。(少なくとも文意としては。)
設計・開発のアウトプットが、インプットされた要求事項を満たしているかを
確認すればよいだけです。
なお、アウトプットはインプットと対比しやすい形態をとるよう、
7.3.3で求められています。
そのインプットとはどんなものかと言うと、
・その製品の、機能や性能の要求事項
(顧客から明示された機能や性能と、
そうではないが暗黙の了解に基づく機能や性能の両方だと考えられます。)
・関連する法規制など
・過去の類似事例があれば、そこで得られた、今回の設計・開発に有用なノウハウ。
・設計・開発に不可欠なその他の要求事項
の4点から成ります。(7.3.2参照)
アウトプットの条件は、上述の形態に加え、
・インプットされた要求事項を満たし、
・後工程(購買・製造およびサービスの提供)に必要かつ適切な情報であり、
・製品の合否判定基準が分かり、
・製品の安全かつ適正な使用に不可欠な特性が分かる(※)
ことです。(7.3.3参照)
※ たとえば製品の一部に有害物質が含まれている場合です。
最終的には、「取り扱い上の注意点」を取扱説明書に明記しなくては販売出来ません。
しかし、なにもその文面までを設計・開発部門で考えなくてはいけないわけではありません。
まあやりたければやってもいいのですけど、普通は後工程の仕事です。
「有害物質がふくまれていますよ!」という情報が、確実に後工程に伝わればいいのです。
言わずもがな、伝わっていないと大変なことになります・・・
「設計・開発」とは <3> レビューと検証と妥当性確認 【対象(前編)】
おまたせしました。2010年02月6日の記事の続編です。
気がついたら1か月も空いてしまいました・・・
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
<観点2> 「何を○○するの?」
◆レビュー :規格には、「設計・開発の結果」が「要求事項」を満たせるかを評価し、
問題があったらなんとかしなさい、とあります。
ここで言う「結果」ですが、一体何を指しているのでしょうか?
また、「要求事項」は何を指しているのでしょうか?
手がかりになるる記述が乏しくISO9001の中でも大変不親切な部分です。
次項の「検証」には、「設計・開発からのアウトプットが云々」という記述があるので、
「結果」は、必ずしも「アウトプット」と同一のものを指すわけではないことがわかります。
同じものを指すのであれば、同じ言葉を使うはずですから。
「設計・開発からのアウトプット」であれば、「(次工程である)製造工程に引き渡すモノ」
(製造業であれば設計図面や試作品など)であることと理解できますが、(7.3.3のb)参照)
それとは別の概念である「設計・開発の結果」とは何でしょうか?
ヒントになると思われる記述が、「妥当性確認」の項にあります。
ここに、「結果として得られる製品が云々」とあるのです。
「製品とは、製造工程の結果なのでは?」という疑問が湧く方も少なくないと思います。
最終的に出来あがる「モノとしての製品」ならその通りでしょうが、
設計・開発工程においても、手では図面を書きながらも、頭の中には
出来上がった製品のイメージがあるはずです。
(そもそも、そうでなければ図面は起こせない。)
設計・開発の途中段階においては、「結果(として作られるであろうの製品)」は
設計者の頭の中にしかありません。
「こんなモノを作りたい」というイメージです。
最初はボンヤリしているでしょうが、スケッチを描いたり試作してみたりして、
徐々にはっきりさせていきます。
その「作りたいモノのイメージ」が「要求事項」を満たしているか、
設計途中でチェックしなさい、と言っているのが「設計・開発のレビュー」だと思います
ではさて、「要求事項」とは何でしょうか?
通常、規格内で要求事項と言う言葉が使われる場合、
「顧客要求事項」や「製品に関連する要求事項」など、何らかの修飾がなされます。
しかしこの7.3.4にはそれがありません。
英語の原文を読んでも、やはり単なる「requirement」とあるのみです。
ということは・・・ あらゆるタイプの要求事項を含んだ概念でしょうか!?
そうすると、全ての規格要求事項も含むことになってしまいますので、さすがに馴染みません。
ここは、「製品に関連する要求事項」に読み代えてよいと思います。
(この部分は、根拠が薄いと言われても仕方ないかもしれません・・・)
なお、製品に関連する要求事項とは、顧客が明示した要求以外にも、
・常識的に考えて満たしていなくてはいけない暗黙の要求
・法令などの規制
・その他、組織が必要と判断したもの全て
が含まれます。(7.2.1参照)
さて、この「設計・開発のレビュー」が規格に盛り込まれた意図は何でしょうか。
設計・開発を進め、技術的な課題と格闘するうちに、
いつのまにか設計者の頭の中で「作りたいモノのイメージ」が
「顧客が望むモノ」からズレていくのを防ぐためだろうと、私は考えています。
レビューだけで長くなてしまったので、検証と妥当性確認については次回に持ち越します。
早めに書くよう心がけます・・・
「設計・開発」とは <2> レビューと検証と妥当性確認 【タイミング】
おまたせしました。2010年01月23日の記事の続編です。
ISO9001:2008の「7.3 設計・開発」では、行った(行っている)設計・開発に対し、
「7.3.4 レビュー」、「7.3.5 検証」、「7.3.6 妥当性確認」といったことを、
それぞれ異なった目的をもって行うよう求めています。
これらの言葉だけを見ても、いったい何が違うのかよく分からないので、
いくつかの観点から3つを比較し、一つ一つ解きほぐしていきます。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
<観点1> 「いつやるの?」
◆レビュー :規格には、「設計・開発の適切な段階」とあります。
つまり、設計・開発工程の、初期でも途中でも仕上げ段階でもいいわけですね。
ただ、設計・開発が終わった後ではないと思われます。
なお、英語の原文には「evaluate」という言葉が使われており、
「評価する」と訳されていますが、これには「査定する・見積る」というニュアンスもあります。
◆ 検 証 :規格には、「設計・開発からのアウトプットが~~を確実にするために~~」とあります。
当然、その時点でアウトプットが出来上がってないと実施できません。
つまり、設計・開発が終わった直後(作り始める直前)あたりが適切と思われます。
なお、英語の原文にも、「~ outputs have met ~」と「過去完了形」で記載されています。
やはり、アウトプットが存在する以前(設計・開発の最中)には実施できないと読み取れます。
また、「検証」という言葉は原文では「verificaion」ですが、
これには「立証」というニュアンスもあります。
アウトプットが存在しない時点では、立証のしようがありません。
◆妥当性確認:規格には、「実行可能な場合にはいつでも、製品の引き渡し又は提供の前に」とあります。
確認の対象は、「結果として得られる製品」です。
つまり、設計・開発工程が終わった後であることは間違いなく、
さらに製造工程も経て、製品がほとんど出来上がっている段階が適切と思われます。
製造現場の職人さんは図面通りにモノを造るのが仕事ですが、決してロボットではありません。
図面にささいな間違いがあって、「このまま作るとちょっと引っ掛かる」ことに気付けば、
その部分を自分の判断でチョチョイノチョイと削ってしまうこともあります。
(こうした修正行為は"現合"などと呼ばれます。)
かくして、「設計・開発には問題があったが、出来上がった製品には問題が無い」
ということにないます。
そういった「現場の判断による修正」が設計部にちゃんと共有されなければ、
設計部の人間はいつまでたっても同じ間違いを(間違いだと気付かないまま)繰り返し、
現場の「修正の手間」も無くならないでしょう。
(↑無ければ無いに越したことはない、無駄な手間です。)
仕様書と図面だけ見ていても、「その設計が本当に正しかったか否か」は
決して十分には分からないのです。
規格は、「必ず現物に目を向けましょうね」と言いたいのだと思います。
これはトヨタの「三現主義」にも通じる考え方だと、勝手に解釈しています。
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
次回は、「何をどうやって確認するのか?」という観点から、3つを比較したいと思います。
アウトプットが気に入らないときに・・・
最近、私の住む市のゴミ収集の制度が大きく変わりました。
今までは、街中のいたるところに設置されたダストボックスに
好きな時に投函しておけば、定期的に回収されていました。
今後は、決まった曜日の朝にしかゴミを出せなくなります。
ゴミ袋は自治体指定のもので、これが結構高い・・・
市のHPを見てみました。
制度が変わった背景には
「焼却炉の閉鎖などでゴミの減量が急務であること」
「あと3年で期限を迎える、ゴミ50%削減という市の目標」などがあり、
そのための策として
「自分で出したごみは自分で負担・管理することで、ごみ問題への意識を高める」
というやり方が採用されたそうです。
たしかに、ゴミ出しの日が制限され、ゴミ袋が高いとなれば、
当然、消費者(ゴミを出す側)としては心理的な制約になります。
きっと、ゴミはいくらか減ることでしょう。
しかし、ゴミは消費者の心理から生まれるものでしょうか。
そういう一面があるのは確かですし、意識改革も必要なことではあります。
しかし、それが要因としてさほど大きいとは思えません。
現代社会の消費構造自体が、まだまだ「ゴミを極力出さずに済ませる仕組み」になっていのが
主な要因でしょうね。
(そもそも、ゴミの量を10年間で50%も減らそうと思ったら、
市レベルの活動でどうこうなるとは思えないのですが・・・)
プロセスを変えずに出口だけを絞るような真似をすれば、
消費自体が冷え込む可能性もあります。(大袈裟?)
このブログをお読みのみなさんの会社でも、似たようなことは行われていないでしょうか?
たとえば、「ノー残業デー」です。
「○曜日は残業しないようにしましょう。」などと呼びかけるだけで
本気で残業が無くなると思っているのかどうか分かりませんが、日本中の多くの企業で行われています。
それで上手くいった(残業及び残業代の削減に効果があった)会社があるのなら
真似をするのも分かりますが、そういう話も聞きません。
たしか、だいぶ前の「ヤング島耕作」に、
「用もないのに会社に遅くまで残り、残業代だけ稼ぐ社員」がちょこっとだけ登場しました。
そういう社員を早く帰らせるには、多少は効果があると思います。
もっとも、最初から残業代を稼ぐことが目的であれば、他の曜日により長く残ればいいだけですが。
本当に忙しくて残業している社員にとっては、「ノー残業デー」の呼びかけなど、ただ煩わしいだけです。
仕事が終わらなければ自分の評価が下がるだけなので、
無視するか、家に仕事を持ち帰るか、どちらかです。
業務体系を抜本的に改善して効率化するか、
仕事のスピードを速めるテクニックを各社員に伝授しないかぎり、
残業が減るということは本来あり得ないはずです。
「そんなテクニックは自分で考えろ!」という考え方もアリだとは思うのですが、
たいていの社員はこっそり家に仕事を持ち帰るんじゃないでしょうか。
(たとえ禁止されていても、可能な限り。)
だってその方が、仕事の仕方を変えるより楽ですからね。
アウトプットとプロセスは表裏一体です。
プロセスの質はアウトプットで計測し、アプトプットを改善したくば
プロセスを改善するしかありません。
毎月3件以上のクレームを起こしている社員に対し、
「お前は来月からクレームを2件以上起こすな!」と言ったところで、
本当にクレームが減るでしょうか。
減ったとしたら、うまく隠してるだけです。
そんな馬鹿な指導をする管理職がいるとは思えませんが、
実はそれと同じくらいナンセンスなことが世の中ではいっぱい行われている、というお話でした。
現状でそれなりに成立している(してしまっている)プロセスを変えることは、本当に大変なことです。
しかしだからこそ価値がある仕事と言えます。
(安易に出口を絞る仕事は、簡単ですぐに出来る分、成果もたいして上がりません。)
そんな仕事をしようしようと思いつつ、「自分に甘い」悪い癖のおかげでやらずにきてしまいました。
しかしとうとう、やらざるを得ない状況に・・・
日本のサラリーマンのみなさん、しなやかにたくましく、それなりに頑張りましょう!
「設計・開発」とは <1> そもそも何が設計・開発か。
今日のテーマは「設計・開発」です。
「設計って、図面を描くことでしょ?」と思われるかもしれませんが、
ISO9001の規格の文脈においては少々意味合いが異なります。
7「製品実現」の章に 7.3「設計・開発」という条があり、その中に
7.3.1「○○の計画」
7.3.2「○○へのインプット」
7.3.3「○○からのアウトプット」
7.3.4「○○のレビュー」
7.3.5「○○の検証」
7.3.6「○○の妥当性確認」
7.3.7「○○の変更管理」
の項があります。
(○○の部分は"設計・開発"に置き換えてお読みください。)
あれこれと要求されているわけですが、
「そもそも『設計・開発』とは何をするものなのか」が明確ではありません。
そのため、この条を適用除外として認める基準は認証機関によってバラバラです。
(アイソスNo.146「認証機関への質問」より)
顧客から図面を渡され、「この通りに作ってほしい」と言われるような
「受託製造」型の企業では除外を認めるケースが多いようですが、
私は「7.3.3設計・開発からのアウトプット」に着目し、少し違う結論を出しました。
この項の中では、「設計・開発からのアウトプットは次の状態でなければならない」として、
「b)購買、製造及びサービス提供に対して適切な情報を提供する」ことを要求しています。
つまり、「設計・開発」とは「購買、製造及びサービス提供」のための、
ひとつ前の準備段階なんですね。
そもそもISO9001の構成では、
7.2「顧客関連のプロセス」
7.3「設計・開発」
7.4「購買」
7.5「製造及びサービスの提供」
という順序でならんでおり、設計・開発の前には
「顧客要求事項を明確にする」という工程があります。
顧客から要望を聞き、それを明確化してレビューしたところで、
いきなりモノを作り始めることができるでしょうか?
いきなりサービスを始めることができるでしょうか?
必ず、「この要望を実現するにはどんなモノをどう作ったらよいだろうか?」
「どんなサービスをどう提供したらよいだろうか?」
を考える工程が存在するはずです。
それが無ければ、具体的に何をしたらいいのか分からないはずだからです。
よって、業種・業態・企業規模にかかわらず、
「設計・開発」が存在しないということはあり得ない、というのが私見です。
顧客から図面を渡されている場合、たしかに
「どんな製品を作ったらよいか」は明確ですが、それだけです。
納期までに指定の数を製造するには、
「原材料の調達、稼働人員の調整、ラインの構成」など、考えることはいっぱいあります。
それら「生産計画の策定」が、「設計・開発」に該当します。
(私がよく参考にしている西沢総研のサイトでは、それを「工程設計」と読んでいます。)
もっとも、QMSの適用範囲を個々の製品の品質のみとし、納期や数量を管理外とするならば話は別ですが。
私のような解釈の仕方は一般的ではないようで、
実際、規格の「7.1製品実現の計画」の注記において
「組織は、製品実現のプロセスの構築に当たって、7.3に規定する要求事項を適用してもよい。」
と書いてあります。
つまり、「生産(製造)計画の策定にあたって、「設計・開発」の考えを当てはめるかどうかは任意です。」
と言っているわけです。
よって、
「何を作ればよいかは顧客から明確に指示があり、
生産計画を策定しさえすれば製造工程をスタートできる」
スタイルの企業であれば、設計・開発を除外出来ると考えてよさそうです。
さて、次回は「レビューと検証と妥当性確認」です。
知的体力があるのなら・・・
こちらのサイトをご覧ください。
(ISO9001を取得し、不良減、クレーム減に成功した事例です。)
http://www.n-souken.com/news/news091003.html
この西沢先生のサイトは大変勉強になるため、日ごろからよくチェックしているのですが、
たま~に「ひっかかる」ことがあります。
今回もちょっと腑に落ちない点がありました。
最初から、「注意します」などの精神論に逃げ込まない対策が出来たことは、素晴らしいと思います。
お世辞でも嫌みでもなく、本っ当にそう思います。
(認証を取得していても、それが出来ない企業は多いですから。)
しかし、「真因の究明」を最初から出来るぐらい「知的体力」とやらがある企業だったら、
それに続く「組織的な対策」なども出来てた筈だと思うんですよね。
であれば、認証取得後に不良やクレームが激減するなんてことは無い筈です。
「いままで本気で仕事をしてなかっただけなんじゃないの?」
と、冷たい突っ込みを入れたくなりました。
知的体力と言う「素質」を十分に持ちながらも、不良やクレームの低減を出来ずにいた会社が、
ISO導入によって、足りなかった「何か」が補完され、それを実現出来たということでしょうか?
だとしたら、その「何か」とは一体何だったのか・・・ 気になります。
ISOの「外圧効果」が、社員に本気で仕事をさせたのだとしたら、
トップのリーダーシップが致命的に足りなかったということになりますね・・・
文書の意味を見直そう <3> 「品質目標」 補強篇
2009/10/03の続きです。
私は日ごろ、ISO関係のコンサルタントや実務担当者のブログを多く読んでいるのですが、
その中でたまたま見つけた「品質マネジメント8原則」というものが、
私の持論をちょっと違った角度から理論的に補強してくれることに気付いたので、
補強篇を書くことにしました。
恥ずかしながら、この「品質マネジメント8原則」というものを
これまで全く知らなかったのですが、
こちら↓のサイトの説明を見ると、規格の"精神"をうまくまとめたものと言えそうです。
http://www.aims.co.jp/hiketu/8principle.htm
まさにマネジメントシステムの土台です。
これからISO9001取得を目指す経営者の方は、
ヘンテコな日本語で書かれた規格条文を読んで首をかしげる前に、
この原則をしっかり消化するといいと思います。
さて本題に入ります。
上記サイトの「原則1.顧客重視」のページをご覧ください。
「顧客重視とは、顧客のゴキゲンをとることではなく、
顧客もマネジメントシステムに取り込むこと。」
「『顧客情報』は売上の中にある!」
とあります。
これは、私が10/03の投稿の最後に書いた、
>>なお、企業が企業活動全体を通して世の中にアウトプットしているモノに対する世の中からの評価、
>>つまり企業の存在価値の総合評価は、
>>最終的には「中長期的な売上高」と「リピーター率」の二指標に現れるものだと考えてます。
に通じる考え方です。
会社の業務は、顧客のために行われます。
直接的であれ間接的であれ、どんな業務も「顧客のため」という一つの焦点があるはずです。
そして顧客は「対価」を通してその企業の業務を評価します。
その結果として継続的に利益をあげられる企業だけが、企業として存続することを許されるのです。
これは、ISOだのQMSだのを語る以前の、
人類の歴史に企業というモノが誕生した時から変わっていないはずの大前提です。
企業を採点する絶対的な存在は、審査機関でも株主でもなく、顧客だと思います。
どんなに真面目に是正処置をやっても、いくら詳細な顧客アンケートを取っても、
どれだけ優秀なコンサルタントから助言を受けようとも、
形の上ではマネジメントシステムが完成しても、
本来の目的である「企業の成長」が実現するとは限りません。
是正処置の効果は、取り組む人間の能力にも左右されますし、
全ての顧客が本当に正しい情報をアンケートに記述してくれるとは限りません。
そういった業務をしっかりやった"つもり"でも、審査には受かるでしょうが
企業が成長するとは限りません。
企業にとって客観的かつ絶対的な指標があるとしたら、
それは"顧客の支持"が否が応にも反映される、「中長期的な売上高」と「リピーター率」です。
(あくどい商売をすれば、短期的に売り上げを伸ばすことは誰にでも出来るでしょうから、
あえて「中長期的な」としておきます。)
こんな素晴らしいものを、マネジメントシステムに取り込まない手はありません。
短期的な目標として「顧客満足度アンケートの<満足>の数」を数えるのはいいでしょう。
しかし、そのアンケートの手法が本当に正しいかどうかは、どうやって計測するのですか?
それを考えずにいくらアンケートを取っても、茶番でしかありません。
もし、「アンケートの結果は上々なのに、リピーター率は低いまま。」
という状態に陥ったとしたら、それはアンケートの取り方が間違っている証拠です。
ピアノは、ドの鍵盤を押せば、基本的にはドの音が出ます。
しかし時間が経つと弦が緩み、音程がずれます。 そのため、定期的な調律が必要です。
音程がズレているにも関わらず、
「ドの鍵盤を押しているのだから、ドの音が出ているはずだ!」
などと言い張ってもしょうがありません。
アンケートの結果がどうであれ、売上とリピーター率が低ければ、
それは顧客満足が低いということなんだと思います。
現実から目をそらしてはいけません。
アンケート手法の見直しが必要です。
そういった指標は、売上高とリピーター率の二つだけではないかも知れませんが、
とにかく、主観的でも相対的でもない、信頼できる確かな"拠り所"を見つけて
それを足がかりに「マネジメントシステムの調律」を行う必要があります。
でなければ、マネジメントシステムは形骸化してしまいます。
マネジメントシステム自体の有効性を継続的に改善する、とはそういうことなのだと思います。
なお、「中長期的な売上高」や「リピーター率」は、
あくまでも「中長期的な企業の総合評価」であり、それ自体は短期的な目標としては不向きのはずです。
(業種業態によっては適しているのかもしれませんが、慎重に考える必要があります。)
なにしろ漠然とし過ぎていていますので、たとえ良い結果が出来たとしても、
それが製品の良さによるものなのか、営業マンの努力によるものなのか、
はたまた接待の質によるものなのかが見えて来ません。
それらは個別に計測し、フィードバック(改善)も短期的にやらねばなりません。
「中長期的な売上高」や「リピーター率」は、「個別の短期目標の調律」に用いるのが良いでしょう。