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

Six Thinking Hats リンク

« 製造部クレーム対応-根本原因の追及(中編) | トップページ | クレームへの対応-総集編(1) »

2013年8月 2日 (金)

製造部クレーム対応-根本原因の追及(後編)

  判明した根本原因が取り除けない場合は現状のメカニズムでは不可能ということなので設計を変更する以外に改善の方法はない。解決するにはいままでとは全く違った考え方をしなければならない。そのヒントはベテランエンジニアの製品Zの開発プロセスにあった。

  昨年製品Xが大量の問題を発生して市場を失いつつあったとき、ベテランエンジニアが集められて製品Zが開発された。ベテランエンジニアはこれが最後の仕事になることが分かっており、集大成の意味も込めて製品Zと名付けていた。通常は10名程度のプロジェクトで新製品が開発されるが、1ヶ月以内に製品Xと同等の処理能力を目標としたため約30名でデザイン・ハードウェア・ソフトウェアが同時進行で開発された。

  開発方針として新しく設計を変更する時間がないので製品Xのハードウェアはメーカーが異なる同等品で組み合わせの最適化、ソフトウェアは基本ロジックは変えずにパラメータを変えて最適水準を選定することにした。何度かの打ち合わせの結果ハードウェア(HW1~8)の8種類、ソフトウェア(SW1~2)の2種類のパラメータを変更して実験を行った。特性値は望小特性の内部温度上昇として外側に使用環境の標準条件と最悪条件を配置してSN比で評価した。
<図表はクリックで拡大>
L12xvsz

  結果はハードウェアHW1、HW7、ソフトウェアSW2を変更することで内部温度上昇を抑えられることが分かった。ハードウェアは製品Xの開発時に信頼性試験を行っており、保守部品の代替品としても登録してあったので、すぐに量産体制に入り、製品Xと置き換えられて販売された。ただ、HW7は温度上昇が少ない分、処理能力に問題があった。この問題が分かっていても設計変更は出来ないので定期点検で問題発生を感知して現場で対応するしかない。そのためベテランエンジニアは現場でよく使われているKY(危険予知)の問題解決4ラウンドで6色ハット発想法を使って話し合い、定期点検の最適化を行っていた。
Optimizecheck_2   
  開発課長はこうしたベテランエンジニアによる危険予知と定期点検の最適化を含むシステムの運用探索方法をRFA(Route Finding Analysis)としてまとめた。
Rfa_2
RCAは問題がゆっくり大きくなる製造ラインのような状況では対策に十分時間が取れるので損失は大きくならないが情報システムのように短時間で状況が変わる場合には原因が分かってから対応するのではその時間の遅れが致命的になる。過去に起きた通信システム障害では数分の遅れが数万人の個人データ損失を引き起こしたことがあった。そのバックアップはマニュアル作業で行われ回復までに数ヶ月、数千万の損失となった。RFAは予測しながらそうした危険を回避し、想定外の問題が起きそうな場合はすぐに回復できるようにバックアップしたり、分散処理でリスクを分散させたり、最悪でも安全にシステムをシャットダウンさせるようになっている。また、問題が予測との差という形でフィードバックされ、ログにも残るので、あとから問題を再現させて根本原因を追及するのも容易になる。

  こうして開発課長は新製品Vの開発、再発防止のRFAの導入・標準化で製品Qの問題解決を同時に終えた。開発された製品Vは客先でもクレーム対策の最終案として提案され、新たに建設されるデータセンターに納入されることが決まった。RFAは公開され客先のデータベースで運用して効果を確認、客先でもソリューションパッケージとして販売されることになった。プロジェクトメンバーには1ヶ月の休暇と報償が与えられた。開発課長は休養をかねて次のプロジェクトを模索するためにアメリカに旅立った。
Vacance

« 製造部クレーム対応-根本原因の追及(中編) | トップページ | クレームへの対応-総集編(1) »

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