本文へ移動
サポートシェアリングソリューション
OKWAVE Plus

このQ&Aは役に立ちましたか?

ベストアンサー
※ ChatGPTを利用し、要約された質問です(原文:工程異常・クレームの共有)

工程異常・クレームの共有

2023/10/18 13:26

このQ&Aのポイント
  • 工場内での品質問題やクレーム情報を効果的に共有する方法を探しています。特に、原因や対策などの詳細情報を実際に作業に携わっている人たちまで共有して、予知予防に繋げたいと考えています。
  • 現在、社内で品質問題やクレーム情報を会議などで共有していますが、周知しただけでは問題解決にはつながっていない状況です。データベースや掲示スペースなどを活用して、報告内容を簡単に閲覧できるようにする案を考えています。
  • 社内トラブルや顧客クレーム情報を効果的に共有する方法を探しています。実際に作業に携わっている人たちまでが情報を把握し、予防策に繋げることが目標です。データベースや掲示スペースを活用して報告内容を共有する案を考えています。
※ 以下は、質問の原文です

工程異常・クレームの共有

2011/09/20 21:46

お世話になります。
製造業で品質保証を担当しています。
率直にお聞きしますが、皆さんの会社では社内トラブル、顧客クレーム
情報をどの様に共有化していますか?
私の会社では、中々ポカミス起因のトラブルが中々減らず、似たような
原因の不具合が違う製造部署で発生しています。
会議の場などで周知はするのですが、結局のところ周知で終わって
しまっています。
現場の責任者の人だけでなく、実際に作業に携わっている末端の人達
までに社内でどの様な品質問題が起きているのか?を共有してもらう
事で予知予防に繋げてもらい、未然に防げればと考えています。
自身の案としては
?社内のデータベースにエクセルで管理フォーマットを作って報告が
 上がってきたら、何処の工程でどんな問題が起きて、どう対策を
 とったかを入力して会社のどのPCからでもだれでも閲覧できる。
?社内の掲示スペースに報告書をそのまま掲示する。
を考えています。
皆さんの中で社内共有で効果のあった方法があれば教えて頂けると
幸いです。 

質問者が選んだベストアンサー

ベストアンサー
2011/09/21 08:43
回答No.4

皆さんおっしゃるとおり、データベースや掲示はあまり意味がありません。
不良は、忘れた頃にやってきますし・・・。

出来る限り作業者意識付けってこと、以外での対策の
ほうが理想です。
基本的には、対策時に当該工程だけではなく、
・共通基準・ルールへの反映
・対策後の水平展開で、類似工程や作業抽出し
それに対し同じ対策反映を計画だてて管理する
(対策が教育じゃなく治具や見える化テンプレートとか
じゃないと意味ありませんが・・・)
・新規立上げ時の確認項目チェックに盛り込む

とかがベターでしょうか。

不具合の量によっては全部ではなく、対象を選択して
どこまでやるかを決めるのも重要かと思います。

このQ&Aは役に立ちましたか?

この質問は投稿から一年以上経過しています。
解決しない場合、新しい質問の投稿をおすすめします。

質問する

その他の回答 (7件中 1~5件目)

2011/09/22 16:06
回答No.7

1.目的は「情報の共有化」では無いと考えます。
再発するのは、「真」の不良発生原因を分析しきっていないためと推測します。
2.例えば
 信号が無い交差点で交通事故が発生しました、そこで信号機をつけて広報で全員に通知しました。
 数日後、また自己発生となります。
これは信号を「守」ことで再発防止が可能ですが、「守こと」が条件です。
そうでは無く、立体交差点に変更すれば交差点は無くなり、交通事故は無くないます。
 これが「真」の対策になります。
3.掲示
 この立体交差点を付けて交通事故を防止したと掲示すれば、他部門も同様に行い、交通事故が無くなって行くでしょう。 

2011/09/21 20:39
回答No.6

末端までの情報の周知、共有の場合のいわゆるプル型の形態は不十分でしょう。
結果を求めるのであれば、プッシュ型で進めるのがよいと考えます。

共有というキーワードでくくると、
貴殿と複数の現場責任者とで、貴殿の期待、危機感と、情報の共有。
ここまでは必要。(情報の共有は、プル型でも可能)
末端へは、事故情報、予防方法(教訓)程度を、朝礼・集会などで伝達する。
(プッシュ型)
これだけでも、最初は抵抗感があるみたいですが、続けていくとトラブルの話をオープンに扱う空気ができてきます。
でも、部内徹底のレベルであって、他の部署のことまで取り上げないでしょ。

水を差すようで申し訳ないが、
ポカミス、似たような原因 であれば、ハードウェアな対策を追求しないんでしょうか?
情報共有にいっちゃいますか?
対策の共有が望ましいわけですよね。
対策が効果的でないような気がします。原因のつかみ方が甘いとそんなことになります。

回答(4)さんに近いかな。

2011/09/21 13:17
回答No.5

他の回答者さんと同様ですが、データベースの閲覧やクレーム情報の掲示は意味がありません。

社内トラブルや顧客クレームを集計しているのであれば、
◆ 実質損失を集計する
◆ 修復までの損失は、実質損失×(2~3)となる集計
  本来生産できる工程と材料等で再生産するため
◆ 顧客クレーム等は、信用的間接&直接損失の集計
をして、給与や賞与に影響していることを自覚させる。

社内トラブルや顧客クレームがあれば、『鉄は熱い内に打て』なので、各所属長から
所属内の類似事項提出と対策プランを提出させる。
(品質会議等にて、社内トラブルや顧客クレームNo.毎に)

品質保証も過去の類似事項内容を事前に把握しておいて、各所属長からの類似事項提出
内容が過去類似事項No.*****と同じであるから、対策プランは済み等の報告をさせた後に
品質保証の見解を述べ、会議を進行させる。
対策プランとその実施状況も会議で(書類)報告させ、品質保証も現場に行き、現物確認し、
現実を把握すると、見落としの類似事項がその現場で発見できるし、会議の場での現場内容討議
に加われる。
再発又は類似トラブルも、所属毎に統計を取り、管理する。

品質クレームは、品質保証だけの仕事である悪しき温床から脱却し、現場と一体の活動とする。
品質保証は社長直属の部署であることが多くし、トラブル損失は会社の利益を圧迫し、
給与や賞与に影響するので、会社一丸となって取り組む活動ができるように、貴殿等が
リーダーシップを取って進めてください。

2011/09/21 04:53
回答No.3

私の会社では、これに似たようなものとして事故情報を回覧しているが、中身をまじめに見る人は殆どいません。
 事故報告は原因が客観的に整理され、本当のことが分からないようなものがが多い。本当の原因が知りたくても、本人にあって聞けるようなものではない。

多分、質問者さんは同じような事を考えていると思いますが、整理された情報はあまり役に立たないと思います。
この辺のことは畑村陽一著「失敗学のすすめ」に書かれていますので、出来れば一読して下さい。
(1)さんのようなやり方が良いと思う。出来ればみんなの前で発表する手も
ある。(当事者でなく品質管理委員会で行う)

2011/09/21 00:23
回答No.2

>>会社のどのPCからでもだれでも閲覧できる。
>>報告書をそのまま掲示する。


ほこりをかぶって渦持てるのが関の山


>>内容は、トラブル事例を読み上げて、
>>・何が問題か
>>・どのようにすれば防げたか
>>ことをリーダが無作為にメンバーを指名して意見を述べさせ、
>>それに対して簡単な議論を行う。


それをFMEAと呼ぶ
http://ja.wikipedia.org/wiki/FMEA
http://www.atmarkit.co.jp/aig/04biz/fmea.html



ちなみに
原発でもやってたはずなんだが
http://www.geocities.jp/takaro_u/std11-11.html

http://www.atmarkit.co.jp/aig/04biz/fmeca.html



いかにおざなりになってるかわかる

お礼をおくりました

さらに、この回答をベストアンサーに選びますか?

ベストアンサーを選ぶと質問が締切られます。
なおベストアンサーを選びなおすことはできません。