品質でもうけなさい | どうしたら易しく面白くなるか もっと楽にならないか |
5.2 顕在している問題の詳細化 | 品質でもうけなさい《目次》 | |||||||||||||
プロローグ | ||||||||||||||
T.品質とコストの考え方 | ||||||||||||||
目の前に現れた問題を 一つ一つ解決していかなければならないのは当然ですが、 それぞれ緊急度や重要度が違うので、 すべて同じように手を付けるわけにはいきません。 |
1. 問題のない会社はもうからない 2. 品質の良し悪しはコストでわかる 3. 品質保証とはどういうことか? |
|||||||||||||
U.品質問題解決の進め方 | ||||||||||||||
4. 問題解決の効率化を図れ 5. 見える化で問題を共有する |
||||||||||||||
そうかと思えば、複数の問題が 同じ対策で一気に解決できることもあります。 |
||||||||||||||
5.1 5.2 5.3 5.4 |
データで把握しデータで語る 顕在している問題の詳細化 見えない問題を掘り起こす 成果目標を設定して公開する |
|||||||||||||
目の前の問題だけにとらわれないで、 ラインや工場全体を見渡して 同じ問題が起こってないか、 似たような現象はないか、 問題の傾向や特徴を分析しながら 解決していくのがうまいやり方です。 |
||||||||||||||
6. 深堀りで解決の手掛りをつかめ 7. もうからない対策を立てるな |
||||||||||||||
V.品質問題よろず相談事例 | ||||||||||||||
8. 品質問題よろず相談事例 9. レベルアップに必要な考え方 エピローグ |
||||||||||||||
《おもしろがりホームページ》 | ||||||||||||||
おすすめの 出し物 |
||||||||||||||
そこで、どの会社でも、 不具合を処理する仕組みの中に、 不具合をデータにして品質状況を 把握するということをしています。 |
||||||||||||||
みなさんの会社にも下のフローと同じようなものがあるはずです。 この仕組みを改善活動に利用することを考えましょう。 |
||||||||||||||
もし、こういう仕組みがなかったり、 あっても有効に機能していないならば、 改善活動に入る前に仕組み作りをしなければなりません。 |
||||||||||||||
下は、ある会社の女姓担当者がAccessでシステムを作った例です。 | ||||||||||||||
なんとかこの統計データを品質向上に役に立つようにしたいと、 品質保証部の女性が一念発起、改善活動に参加してきました。 |
||||||||||||||
当時、生産管理システムの更新時期にあって、 その方面のデータも不安定な中で、 Accessという少々とっつきにくい汎用ソフトを使いこなして、 よくここまで作り上げたなあと感心しています。 |
||||||||||||||
さて、せっかく不具合データを管理するシステムを持っていても、 お客様に迷惑を掛けた大きな問題は記録するが、 社内で頻繁に起こる小さなロスは無視していませんか? |
||||||||||||||
品質問題を 徹底的に解決していこうと思うならば、 こういう小さなロスも 確実に捉えられるような仕組みに なっていなければいけません。 |
||||||||||||||
普通、小さなロスは、 作業者が自分で修正して 元に戻してしまいます。 わざわざデータを発信するより 手直しの方が手っ取り早い というわけです。 |
||||||||||||||
ところが、 その手直しが生産効率をどれだけ 阻害しているかを計測すると、 「チリも積もれば山となる」で 30%近くのダウンに なっていることもあります。 業種・生産形態によっては もっと大きなロスにもなるでしょう。 このロスをそのまま放っておくなんて 勿体ないと思いませんか? |
||||||||||||||
例えば、 ロス時間が10分を超えたらデータ発行するルールにするとか、 小さなロスはカウントだけしておいて、 |
||||||||||||||
作業終了時に1件のデータにまとめて 発行するようにしても良いでしょう。 このほか、 データ入力の方法を簡略化するなど、 きめ細かいシステムの運用ができる 工夫をして まず、ロスの実態を捉えてみましょう。 |
||||||||||||||
≪楽屋裏話≫ | ||||||||
私の経験からすると、改善活動と同時進行で仕組みの整備を行うのは、当事者によほど問題意識とパワーがないと難しい感じがしています。 この仕組みの中心となる品質保証部門が、品質「補償」しかやらないものですから、何かと理由をつけて動こうとしません。したがって、指導を依頼される場合は、もっと上位のマネジメントの意思によることが多く、それも仕組み作りに限定した指導から入る方が良い結果を生んでいます。 もちろん、品質保証部門がしっかり責任を果たしている会社は、仕組み作りの必要はほとんどなく、すぐに改善活動を開始できています。 なお、不具合データ管理のシステムを作る場合の留意点として、次のようなことがあげられます。機能的なシステムを作るための前提となります。 @)不具合処置の仕組みが明確になっていること. A)パソコンが活用され、ExcelやAccessをよく利用していること. B)不具合内容が層別されコード化されていること. C)工程や部品のストラクチャー展開ができていること. D)生産実績システムが機能していること. E)品質レビューの仕組みが明確になっていること. F)方針展開の仕組みが明確になっていること. G)過去トラ(過去のトラブル)がデータベース化されていること. |
||||||||
〈5.2 顕在している問題の詳細化〉先頭へ | NEXT | |||
Copyright (C) omoshirogari. All Rights Reserved. |