ホーム / ベストプラクティス / 根本的な原因の根本を分析すると

根本的な原因の根本を分析すると

システムがクラッシュすると、通常は原因が1つあるだけではありません。しかし、私たちは、経験したすべての問題が 1つ前の重要な問題にまで遡ることができるかのように、根本的な原因の分析をし続けています。ロブ・イングランド(Rob England)氏は、これが事実ではなくて、根本を無視する原因分析の開発用の呼び出しを思い出させてくれます。まあ、完全ではありませんが、一般にそれは根がさらに大きな問題の一部であることを認識すべき潮時であり、その問題の根本に到達することは、常にあなたの最優先事項であってはならないはずです。災害のど真ん中にいるときは、先に最もアクセス可能な原因を特定してそれを除外することが、最も有益であることもあります。何が根本的な問題なのかを心配することは、後のために取っておくこともできるはずです。

イングランド氏はまた、すべての複雑なシステムが壊れているという彼の洞察力を共有しています。そこには何かがいつ何時おかしくなってしまうかもしれない可能性がありますが、それは壊れた破片が一列に並んで、私たちが気がつくことになる場合だけです。その後、「根本的原因」を見つけて、通常自分の仕事をしている、ある人にその責任を転嫁します。彼らがやっていたことが間違ってしまう可能性は常にありますが、システムが失敗したのは他の原因の影響が示されるまで、そうではなかったはずです。将来、失敗が発生しないことを望むなら、根本的な原因だけでなく、種々の原因を見つけてください。それは全く同じ問題が再発するのを防ぐだけでなく、他のことも同様に防ぐことになるはずです。

約 Rachel Ginder

Rachel Ginder was a staff writer for CAI's Accelerating IT Success and joined the team in 2013. She also helped with social media and research.

また、チェック

重要システム停止で最善を尽くす

誰もがその瞬間を知っています。画面が黒くなり、エラーメッセージがポップアップし、あなたが必死にマウスを横に振っても、何も動きません。重要システムの停止が、一般の従業員には迷惑だとすれば、 ITの専門化にとっては、実にパニックを誘発するほどです。それは不可避な問題ですが、重要システムの停止で生き残るためには、スコット•マットソン(Scott Matteson) 氏の10のヒントがあれば、準備は十分にできます。彼のヒントには以下が含まれています。 パニックしない すべてを文書化する その状況に関わ

Leave a Reply

Your email address will not be published. Required fields are marked *