What do you think?
Rate this book
Root Cause Analysis: The Core of Problem Solving and Corrective Action
We live in a complex world. People and organizations often don’t believe they have the time to perform the in-depth analyses required to solve problems. Instead, they take remedial actions to make the problem less visible and implement a patchwork of ad hoc solutions they hope will prevent recurrence. Then when the problem returns, they get frustrated—and the cycle repeats.
This book provides detailed steps for how to solve problems, focusing more heavily on the analytical process involved in finding the actual causes of problems. It does so using a large number of figures, diagrams, and tools useful for helping make our thinking visible. The primary focus is on solving repetitive problems, rather than performing investigations for major incidents/accidents. Most of the terminology used is everyday language and can therefore also be used for applications in their personal lives. Many of the examples will involve situations with which the reader will likely be familiar.
The focus of the book not on statistics but instead on the logic of finding causes. It has sometimes been described in training workshops as “Six Sigma lite”…problem solving without all the heavy statistics.
This book provides detailed steps for how to solve problems, focusing more heavily on the analytical process involved in finding the actual causes of problems. It does so using a large number of figures, diagrams, and tools useful for helping make our thinking visible. The primary focus is on solving repetitive problems, rather than performing investigations for major incidents/accidents. Most of the terminology used is everyday language and can therefore also be used for applications in their personal lives. Many of the examples will involve situations with which the reader will likely be familiar.
The focus of the book not on statistics but instead on the logic of finding causes. It has sometimes been described in training workshops as “Six Sigma lite”…problem solving without all the heavy statistics.
220 pages, Kindle Edition
First published January 1, 2009
43 people are currently reading
130 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
December 24, 2021
این کتاب سال ۲۰۱۹ منتشر شده و موضوعش یافتن ریشه مشکلات هستش. بر خلاف عکس روی جلدش، درباره مفاهیم آماری نیست، بلکه روی یافتن علت و ریشه مشکلات تاکید داره.
این روزا اکثر آدم ها و شرکت ها وقت کافی برای تحلیل عمیق مشکلات نمیذارن، در نتیجه اصلاحات سطحی انجام میدن تا مشکل را کمتر نشون بدن و راهحلهای موقتی بکار میگیرند و امیدوارند از بروز مجدد اون جلوگیری کنند. اما وقتی مشکل برمیگرده، ناامید میشن و این چرخه باطل تکرار میشه.
تمرکز کتاب روی "فرآیند تحلیلی" که در پیدا کردن علل واقعی مشکلات به ما کمک میکنند هستش، و مراحل دقیقی برای چگونگی حل مسائل رو ارائه میکنه. این کار را با استفاده از تعداد زیادی شکل، نمودار و ابزار مفید انجام میده. ابتدا به جای بررسی اتفاقات بزرگ، روی حل مشکلات تکراری تاکید میکنه. بیشتر از اصطلاحات ساده استفاده شده در نتیجه تو زندگی شخصیمون هم میتون مفید باشه. مثالها بیشتر شامل مواردی هست که برای هممون آشناست و بهش برخوردیم.
مثلا یکی از کاربرداش تحلیل نرخ خرابی قطعات و میزان هزینه ایی که براشون صرف میشه در دیتا سنترها هستش.
یا چک لیست های خلبان ها قبل پرواز، یا شمارشی که در اتاق عمل انجام میدن تا از موندن گاز (پانسمان) در بدن بیمار جلوگیری کنند.
زمانی که علت روپیدا نمیکنیم استفاده از روش بیومیمیک (حل مشکلات با الهام از طبیعت) توصیه میکنه.
مثلا یک دکتر سوئیسی که با سگش میره جنگل و از چسبیدن گیاه زردینه (سرده) به سگش و لباس خودش ایده چسب های شرکت ولکرو به ذهنش میرسه. یا ایده قطار های تندرو ژاپنی که از روی پرنده کینگ فیشر گرفته شده، یا ایده کلاه ایمنی دوچرخه سواری که از سر دارکوب گرفته شده، یا شیشه هایی که خودشون رو تمیز میکنند که به اثر لوتوس معروف هستش و از نیلوفر آبی ایده اون گرفته شده اشاره میکنه.
بیان مسئله یکی دیگه از مواردی هست در این کتاب بهش پرداخته میشه، چطور مشکل رو باید به درستی پیدا و شرح بدیم؟ مهم که اصطلاحات استفاده شده در بیان مسئله نامشخص، مبهم، یا مایل به مبهم نباشه.
مفاهیم و ابزار های شرح داده شده در این کتاب:
Pareto chart 80/20، TRIZ, 5S, 5 whys، Six Sigma (6σ), decision table or matrix, Poka-yoke, Ishikawa diagram, FMEAs, HACCP, HAZOP, DMAIC, DMADV, SIPOC, CTQ tree, QFD, EFM, Kaizen, COPIS, PDCA, Taguchi methods, Value-stream mapping, Cost benefit analysis (CBA).
مثال ۱: افزایش دان تایم: با اینکه نشون میده مشکلی وجود دارد، اما مطمئناً برای تشخیص علت کافی نیست. سوالات خوبی که میشه در این مرحله مطرح کرد:
کدام سرور(ها)؟
کدام بخش؟
چند وقته خیلی زیاد شده؟
چقدر زیاد؟
سطح قابل قبول چقدره؟ یا قبل از غیرقابل قبول شدن چه سطحی بوده است؟
نوع دان تایم (به عنوان مثال، خرابی، ارتقاء نرم افزار، یا تعمیر و نگهداری سخت افزار) در اعداد وجود داره یا مستثنی شده؟
مثال۲: درصد مشتریانی که خودروهایشان در زمان وعده داده شده آماده تحویل نبودند در سه ماه گذشته افزایش یافته است.
چقدر افزایش یافته است؟
میانگین هفته قبل چقدر بود و الان چقدر است؟
افزایش ناگهانی بود یا تدریجی؟
آیا میشه مشتریان با توجه به نوع کاری که انجام دادند به طور دقیق تری شناسایی کرد؟
کدام سه ماه (به عنوان مثال، "سه ماه گذشته" نسبت به حال هست و تغییر خواهد کرد)؟
مثال ۳: دو بیمارستان در حال مقایسه مدت زمان عمل جراحی تعویض مفصل زانو بودند. هر بیمارستان روند خود را در سطح بالایی ترسیم می کند و سپس داده ها را جمع آوری می کند تا بفهمد هر یک از مراحل اصلی چقدر طول کشیده است. مشخص شد که یک بیمارستان به طور قابل توجهی زمان کمتری را در اتاق عمل نسبت به بیمارستان دیگر صرف میکند و به نظر میرسد که این نقطه خوبی برای بهبود بیمارستان دوم باشد. اما مشخص شد که هر بیمارستان تعریف متفاوتی از زمان شروع شد و پایان عمل دارد در نتیجه اعداد متفاوتی بدست می آوردند. یعنی آنها تعاریف عملیاتی متفاوتی برای زمان داشتند و معیار مقایسه مناسبی در نظر نگرفتند.
مثال ۴: این مثال درباره اهمیت مشاهده و نقطه نظر هستش. این مورد معلوم نیست واقعیه یا خیالی، اما زیاد میشنوم از بچه های نرم افزاری. میگن یک تیم آی تی در نیمه های شب گاه به گاه با دان شدن سرور مواجه میشدن و بعد از مدتی دوباره سرور ها به وضعیت عادی برمیگشتن. بررسی سخت افزاری و نرم افزاری هیچ چیزی رو مشخص نکرد، بنابراین تصمیم گرفتند شیفتی تو شرکت بمونند تا ببینند علت چی هستش. چند شب اول هیچی پیدا نکردن، ولی در نهایت علت را پیدا کردند که نگهبان ساختمان سرور را از برق جدا میکرده تا کف شور به برق بزنه!
این روزا اکثر آدم ها و شرکت ها وقت کافی برای تحلیل عمیق مشکلات نمیذارن، در نتیجه اصلاحات سطحی انجام میدن تا مشکل را کمتر نشون بدن و راهحلهای موقتی بکار میگیرند و امیدوارند از بروز مجدد اون جلوگیری کنند. اما وقتی مشکل برمیگرده، ناامید میشن و این چرخه باطل تکرار میشه.
تمرکز کتاب روی "فرآیند تحلیلی" که در پیدا کردن علل واقعی مشکلات به ما کمک میکنند هستش، و مراحل دقیقی برای چگونگی حل مسائل رو ارائه میکنه. این کار را با استفاده از تعداد زیادی شکل، نمودار و ابزار مفید انجام میده. ابتدا به جای بررسی اتفاقات بزرگ، روی حل مشکلات تکراری تاکید میکنه. بیشتر از اصطلاحات ساده استفاده شده در نتیجه تو زندگی شخصیمون هم میتون مفید باشه. مثالها بیشتر شامل مواردی هست که برای هممون آشناست و بهش برخوردیم.
مثلا یکی از کاربرداش تحلیل نرخ خرابی قطعات و میزان هزینه ایی که براشون صرف میشه در دیتا سنترها هستش.
یا چک لیست های خلبان ها قبل پرواز، یا شمارشی که در اتاق عمل انجام میدن تا از موندن گاز (پانسمان) در بدن بیمار جلوگیری کنند.
زمانی که علت روپیدا نمیکنیم استفاده از روش بیومیمیک (حل مشکلات با الهام از طبیعت) توصیه میکنه.
مثلا یک دکتر سوئیسی که با سگش میره جنگل و از چسبیدن گیاه زردینه (سرده) به سگش و لباس خودش ایده چسب های شرکت ولکرو به ذهنش میرسه. یا ایده قطار های تندرو ژاپنی که از روی پرنده کینگ فیشر گرفته شده، یا ایده کلاه ایمنی دوچرخه سواری که از سر دارکوب گرفته شده، یا شیشه هایی که خودشون رو تمیز میکنند که به اثر لوتوس معروف هستش و از نیلوفر آبی ایده اون گرفته شده اشاره میکنه.
بیان مسئله یکی دیگه از مواردی هست در این کتاب بهش پرداخته میشه، چطور مشکل رو باید به درستی پیدا و شرح بدیم؟ مهم که اصطلاحات استفاده شده در بیان مسئله نامشخص، مبهم، یا مایل به مبهم نباشه.
مفاهیم و ابزار های شرح داده شده در این کتاب:
Pareto chart 80/20، TRIZ, 5S, 5 whys، Six Sigma (6σ), decision table or matrix, Poka-yoke, Ishikawa diagram, FMEAs, HACCP, HAZOP, DMAIC, DMADV, SIPOC, CTQ tree, QFD, EFM, Kaizen, COPIS, PDCA, Taguchi methods, Value-stream mapping, Cost benefit analysis (CBA).
مثال ۱: افزایش دان تایم: با اینکه نشون میده مشکلی وجود دارد، اما مطمئناً برای تشخیص علت کافی نیست. سوالات خوبی که میشه در این مرحله مطرح کرد:
کدام سرور(ها)؟
کدام بخش؟
چند وقته خیلی زیاد شده؟
چقدر زیاد؟
سطح قابل قبول چقدره؟ یا قبل از غیرقابل قبول شدن چه سطحی بوده است؟
نوع دان تایم (به عنوان مثال، خرابی، ارتقاء نرم افزار، یا تعمیر و نگهداری سخت افزار) در اعداد وجود داره یا مستثنی شده؟
مثال۲: درصد مشتریانی که خودروهایشان در زمان وعده داده شده آماده تحویل نبودند در سه ماه گذشته افزایش یافته است.
چقدر افزایش یافته است؟
میانگین هفته قبل چقدر بود و الان چقدر است؟
افزایش ناگهانی بود یا تدریجی؟
آیا میشه مشتریان با توجه به نوع کاری که انجام دادند به طور دقیق تری شناسایی کرد؟
کدام سه ماه (به عنوان مثال، "سه ماه گذشته" نسبت به حال هست و تغییر خواهد کرد)؟
مثال ۳: دو بیمارستان در حال مقایسه مدت زمان عمل جراحی تعویض مفصل زانو بودند. هر بیمارستان روند خود را در سطح بالایی ترسیم می کند و سپس داده ها را جمع آوری می کند تا بفهمد هر یک از مراحل اصلی چقدر طول کشیده است. مشخص شد که یک بیمارستان به طور قابل توجهی زمان کمتری را در اتاق عمل نسبت به بیمارستان دیگر صرف میکند و به نظر میرسد که این نقطه خوبی برای بهبود بیمارستان دوم باشد. اما مشخص شد که هر بیمارستان تعریف متفاوتی از زمان شروع شد و پایان عمل دارد در نتیجه اعداد متفاوتی بدست می آوردند. یعنی آنها تعاریف عملیاتی متفاوتی برای زمان داشتند و معیار مقایسه مناسبی در نظر نگرفتند.
مثال ۴: این مثال درباره اهمیت مشاهده و نقطه نظر هستش. این مورد معلوم نیست واقعیه یا خیالی، اما زیاد میشنوم از بچه های نرم افزاری. میگن یک تیم آی تی در نیمه های شب گاه به گاه با دان شدن سرور مواجه میشدن و بعد از مدتی دوباره سرور ها به وضعیت عادی برمیگشتن. بررسی سخت افزاری و نرم افزاری هیچ چیزی رو مشخص نکرد، بنابراین تصمیم گرفتند شیفتی تو شرکت بمونند تا ببینند علت چی هستش. چند شب اول هیچی پیدا نکردن، ولی در نهایت علت را پیدا کردند که نگهبان ساختمان سرور را از برق جدا میکرده تا کف شور به برق بزنه!
July 11, 2018
Not a long book. Covers all parts of RCA superficially viz DMAIC but all chapters except Chpt.8
(Identify and Select Solutions) were uneventful. Sometimes its not the content of the book but the parallel triggers it sets off in your head that is more valuable, that was my purpose to read this book. Anyways there were some tools introduced that I was not aware of, like Barrier analysis, triz and simpler ones like is/is not table, six hats and payoff matrix which I really liked. Had links to some great blogs - like aplomet.com, apqc.org & triz-journal.com.
In conclusion, not too bad, not too good, mediocre.
(Identify and Select Solutions) were uneventful. Sometimes its not the content of the book but the parallel triggers it sets off in your head that is more valuable, that was my purpose to read this book. Anyways there were some tools introduced that I was not aware of, like Barrier analysis, triz and simpler ones like is/is not table, six hats and payoff matrix which I really liked. Had links to some great blogs - like aplomet.com, apqc.org & triz-journal.com.
In conclusion, not too bad, not too good, mediocre.
August 18, 2020
If you you find yourself trying to figure out the five why or other methods to better understand defects and errors in your IT services delivery - this is the right book. It made my reread list.
“We live in a complex world. People and organizations often don’t believe they have the time to perform the in-depth analyses required to solve problems. Instead, they take remedial actions to make the problem less visible and implement a patchwork of ad hoc solutions they hope will prevent recurrence. Then when the problem returns, they get frustrated—and the cycle repeats.”
“We live in a complex world. People and organizations often don’t believe they have the time to perform the in-depth analyses required to solve problems. Instead, they take remedial actions to make the problem less visible and implement a patchwork of ad hoc solutions they hope will prevent recurrence. Then when the problem returns, they get frustrated—and the cycle repeats.”
Displaying 1 - 3 of 3 reviews