問題文の作成

問題解決は、常によく書かれた問題文から始まります。 いつも 発生したことを正確に詳細に記述することで、直面している問題についての混乱やあいまいさを取り除きたいと考えています。

これはあなたのチームがあなたの問題に正確に焦点を当て続けます。 それはまたあなたのチームが一貫してあなたの構成内の心配を解決し、恐れられた”規模のクリープ”を湾で保つのを助ける。

あなたの問題の声明は、手元の問題の原因を詳述するべきではありません。 結局のところ、原因を知っていれば、この文を作成する必要はありません。 あなたはこの方法論の必要はないでしょう。 あなたは原因を排除するために行動を取るだろう。 最後のヒント。.. 個人があなたの問題を引き起こした可能性は低いことに注意してください。 この問題は、プロセスが不十分な結果である可能性が高くなります。 デミングは、問題の85%が不十分な定義または不十分なプロセスの結果であり、問題の15%だけが本当にオペレータエラーであると判断しました!

問題文のルール

不完全に書かれた例-

ウィジェットが長すぎます。

私たちの報告には誤りが多すぎます。

私たちの配達時間は恐ろしいです。

これらの例は、問題の深さを十分に詳しく説明していません。 すべての3はまともな始まりですが、あなたのチームが何が起こったのかを見つけるためにジャンプする前に、より多くの情報が必要です。 あなたの会社が要件を満たすことができなかった方法の追加は、問題の声明では必須です。

良い例-

ウィジェットが38cmの顧客要件を超えています(要件と組織がそれを満たすことができなかった方法を定義します)。

毎月の品質レポート(問題の場所を定義)には、平均して2つ以上のエラーが含まれており、予想される0つのエラー(内部要件を定義)

オンタイム配信は平均92%で、目標の98.5%を下回っている(これも要件を満たすことができなかったことを定義している)。

より良い例-

最後の10回の生産実行(問題が発生したときを定義)は、ウィジェットが平均41cm(問題)を測定し、38cm+/-2cmの顧客要件を超えています。

問題解決ダイ

過去2ヶ月(いつ)の品質レポートには、平均して2つ以上のエラーが含まれており、予想される0つのエラーよりも大きくなっています。

顧客Xへの定時配送(問題が発生した場合)は、過去4ヶ月間で92%に過ぎず、必要な98.5%を下回っています。

これらのより良い例は、あなたのチームに問題を調査するために必要な詳細を与え、あなたのチームがそのリソースを集中すべき場所を定義します。 たとえば、widget investigationでは、過去10回の生産実行を超えて検索する必要はありません。 チームの予備的な調査結果は、これらの実行の前に問題が存在しないことを示しています。

468 ×60静的

ホーム””問題解決戦略””問題文

コメントを残す

メールアドレスが公開されることはありません。