フォト
無料ブログはココログ

Six Thinking Hats リンク

« 製造部クレーム対応-現状を把握する(後半) | トップページ | 製造部クレーム対応-対策立案・実施 »

2013年4月27日 (土)

製造部クレーム対応-データの整理

  これまでのクレーム対応は現状把握が終わった段階で状況説明を行い、客先には「社員の注意徹底」や「再教育」といった適当な報告で済ませていた。実質的には技術部の指導で製造部がきちんと対策を実施していたので今回のような再発はしなかった。しかしながら、先方の吸収合併した親会社のルールでは説明責任を求められていた。

  その理由は将来この障害が原因でPL問題など訴訟が起きた場合に責任の所在を明確にしておくための記録が必要だという。個人情報が漏れて損害を受けたと事実かどうか判然としないにもかかわらず公聴会で追及されマスコミやネットでも犯罪者呼ばわりされ、明確な反論も出来ないまま数億円の賠償金を払わされた同業者がいた。その結果トップだったシェアが急落、その上巨額の賠償金支払いのため昨年は赤字に転落した。国内のビジネスは相撲の土俵、海外のビジネスは何でもありのバトルロイヤルのリンクで戦うようなもので、対戦相手が誰か分からず、弱点があれば不意を突かれて負ける。正義やルールはビジネスの勝者が決める。同じ土俵で戦えば勝てるといういいわけはグローバル化が進む現在では通用しない。

  こうした対策で記録が必要なことはもちろんだが、そうした記録によって問題発生時に履歴を追えるトレーサビリティが必要だ。それによって問題の影響の範囲を限定でき、応急処置を的確に行えるばかりでなく、原因追及も絞り込みやすい。後で訴訟になったとしても適切に対応したことを証明できる。しかしながら現状ではオンラインシステムのデータベースが機能しておらず、各部門でデータフォームも内容も管理方法も違う形でデータが散在している。そのため問題発生時の対策やレポートに統一性がなく顧客の不信感を助長してしまう。その原因は顧客の関心事に合わせて都度レポートをまとめるため常にスクラッチから始め、作られたレポートは顧客への報告以外に利用されることなく、問題が解決すると設計や関連部門にフィードバックされることなく忘れられ、データベースとはならず、経験や勘といった曖昧な記憶にしかならなかった。それが問題発生時に思いつきの対策しか出来ない根本原因でもあった。

  営業課長はエンジニアとしての経験を生かしてデータに基づいた戦略を立て営業活動を展開し、成績を上げたことが認められ昨年昇格したばかりだった。そのためデータの必要性については身に染みて感じているがそのような社員は少数派である。この対策を通じて考え方を変え、データに基づく仕事が基本動作となるように行動を変えようとした。改善は仕組みを変え、考え方を変え、その結果として行動が変わることで改善効果としてアウトプットすることであるから、そのためにデータに基づく仕事の仕組みにしなければならない。

  そこで対策を進めるに当たってどのようなデータを必要とし、そのデータの存在の有無を調査してまとめた。
<図表はクリックで拡大>

Datalist
  対策プロセスのモデルは一種の帰還増幅回路のようなシステムと考えられる。すなわち、対策内容をインプットして、そのアウトプット-問題解決の進捗や効果を定量的にデータとして測定し、インプット側や、対策中のプロジェクトチームにフィードバックすることによって対策効果の予測や計画と比較して、ギャップがあればその解消に向けた行動を起こし、期日までに問題解決を完了するシステムだ。データは White Hat でその採り方やデータから集約される情報を読み取る。読み取った内容に基づいて予測を立てるYellow Hat、判断を下すRed Hat,対策効果を高めるアイデアを出す Green Hat, さらなる問題点や障害を見いだす Black Hat、対策プロジェクトを管理するBlue Hatへと展開して行く。

  この対策プロジェクトをデータのフィードバックによって管理する仕組みは製造部の日常管理の仕組みと同じだ。

Pdsasida   いわゆる統計的品質管理で設計規格の中心と規格の範囲内に製品の性能が分布するように製造の管理限界を推定、その範囲内に収まるようにPDSAを回す。その範囲は過去の実績から統計的に推定するか、設計規格に対する安全係数で設定し、その範囲内に入るようにばらつきを調節する。日々の日常管理は短期的にはSIDAループによって変化の瞬間を感知して即座に対応し、その結果として範囲内かどうかをPDSAで長期的に管理することになる。短期にしても長期にしてもデータをとった時点で問題があれば次にデータをとるまでの間に解決しなければデータをとる意味がない。調査した結果ではデータはとられているが記録されているだけで全く使われていないのが現状だった。日常管理はデータを管理図やQC七つ道具で使うための仕組みではなく、データによるフィードバックシステムのアーキテクチャーを構築・運用することなのだ。

  かつてTQC活動を全社的に推進していたころは製造部が中心になってこうした日常管理を実施して不良が低減した。QCサークルもそれなりに成果が上がっているように見えた。しかし、今振り返ってみると、見逃していた不良が社内で見つかるようになっただけであった。その不良の原因もほとんどがワークマンシップ-正しい作業の仕方が出来ていないか、ずさんな管理にあった。つまり、こうした意識を高めるだけの活動は人が原因の問題しか解決せず、改善活動は社内発表会で報告されるだけで、発表された数ヶ月後には元に戻っていた。発表者の現場は発表会がセレモニーと分かっていたので演出に大半の時間を割き、そうして誇張された改善結果は審査員となったマネジメントが満足するだけであった。

  品質は設計された時点で決まり、それ以上良くなることはない。製造で品質が改善されたとしたらそれは取りこぼしが減ったに過ぎない。製造ラインで出来ることはいかにして工程条件を調節して設計で決めた品質に近づけられるかだけだ。生産のしやすさも設計できまるので、それ以上に対価を払わずアウトプットを求める「改善提案」や「創意工夫」は社員の時間を必要以上に拘束し、会社への無料奉仕を強要・洗脳する労働強化の道具といえる。経営者は社員の時間や能力を自由や幸福を得るための契約の範囲内で活用すべきだ。家族的な経営と言えば聞こえがよいが、その実は生殺与奪の権利を掌握して社員の全人格・全生活を支配・私物化したがる。先代社長の考え方は戦後間もないころに日々の生活がままならなかった状況では価値があった。社員の生活が安定して豊かになった今は幸福を考える時間や拘束されない自由によって得られる幸福感を出来るだけ与えることのほうが価値がある。価値観は時代とともに変わり、新しい価値観がより幸福な社会や夢を実現して行くのだ。今はその価値観の変わり目にいるのかも知れない。

  これまで生産管理といえば「生産量はより多く」=効率化、「不良数はより少なく」=品質管理という固定観念があった。簡単に言えば目標値の無い管理なのだ。「生産量前年比〇〇%」とか「不良率半減」といった目標は「もっと頑張ろう」と言っているのと同じだ。投資に見合った利益を生み出し、持続可能な経営を実現するために生き残りをかけて必ず到達しなければならないレベルが目標なのだ。もともと達成できるとは考えていないマネジメントの思いつきで立てられた「もっと頑張ろう」を言い換えただけの目標は張り紙や看板にスローガンのように描かれるだけでそうした危機感はなく、達成しようとする努力もしない。

  この誤った固定観念の「効率化」により過剰な生産量を要求され、定時間内で作業は終わらず、「品質向上」で過剰な品質管理のために選別や検査が行われていた。その結果販売予定のない過剰在庫と過剰な品質検査で性能や商品価値には全く影響の無い不良品が生産され、ラインにはリワークを待つ不良の仕掛、倉庫に売り先のない在庫が増え続けた。営業がノルマを達成するために立てた根拠のない受注予測に基づく生産計画は破綻し、大量の陳腐化した仕掛や在庫を廃棄したため昨年は実質的には大幅な赤字であった。

  設計で見積もった生産量以上に出来たらその差分は支払うべきだし、生産が予定通り達成できなければ生産性を上げられるように設計を変えるか、管理の仕方を変える以外にはない。生産計画もまた実質的な需要やその変化に応じて設計や生産の根拠を与える情報として提供されなければならない。そうした設計や生産、情報管理の善し悪し-品質マネジメントシステムが直感的に判断できるような「見える化」なら良いが、コンサルタントの指導によって導入された「見える化」は責任を追及するための「見える化」としか利用されず、作業者を晒しものにして追い詰め、恐怖感を与えるだけの道具に過ぎなかった。「見える化」はマネジメントシステム-経営に求められるのであって設計-生産-販売の企業活動はきちんと経営機能の仕様通りに設計され常に見えなければならないのだ。営業課長は「見える化」を現場に求めるのは経営機能が無いためだと理解するようになった。

  これは顧客の要求にもいえることで規格や仕様が決まっているにもかかわらず、それ以上の性能を要求したり、不良のような品質問題は全く発生しないことを要求するばかりか、発生したときは無制限に償いを要求する。これがクレーム時によくある顧客という優位な立場を利用した到達目標のない「誠意を見せろ」という無制限の要求となる。

  営業課長はこうした背景をもとにデータの必要性を製造部のスタッフに説明し、データの収集は情報システム部に依頼した。すでに対策が始まって1週間が過ぎているので、先方の購買部長には進捗状況も併せて報告するするように対策書をまとめる作業に入った。4月中旬に稼働の約束だったが事情を説明して連休明けまで延期を願い出た。購買部長は「これが最後だ」といって苦渋の承認をした。

  もう、あとがない。営業課長や対策プロジェクトのメンバーやスタッフは連休の予定をすべて取りやめて、研修所で合宿して対策をまとめることになった。先ほどまで晴れていた空は急に暗くなって霰混じりの激しい雨と風に見舞われた。時折、雷鳴が響き会議室に閃光が走った。

« 製造部クレーム対応-現状を把握する(後半) | トップページ | 製造部クレーム対応-対策立案・実施 »

ファシリテーション」カテゴリの記事