این کتاب سال ۲۰۱۹ منتشر شده و موضوعش یافتن ریشه مشکلات هستش. بر خلاف عکس روی جلدش، درباره مفاهیم آماری نیست، بلکه روی یافتن علت و ریشه مشکلات تاکید داره.
این روزا اکثر آدم ها و شرکت ها وقت کافی برای تحلیل عمیق مشکلات نمیذارن، در نتیجه اصلاحات سطحی انجام میدن تا مشکل را کمتر نشون بدن و راهحلهای موقتی بکار میگیرند و امیدوارند از بروز مجدد اون جلوگیری کنند. اما وقتی مشکل برمیگرده، ناامید میشن و این چرخه باطل تکرار میشه.
تمرکز کتاب روی "فرآیند تحلیلی" که در پیدا کردن علل واقعی مشکلات به ما کمک میکنند هستش، و مراحل دقیقی برای چگونگی حل مسائل رو ارائه میکنه. این کار را با استفاده از تعداد زیادی شکل، نمودار و ابزار مفید انجام میده. ابتدا به جای بررسی اتفاقات بزرگ، روی حل مشکلات تکراری تاکید میکنه. بیشتر از اصطلاحات ساده استفاده شده در نتیجه تو زندگی شخصیمون هم میتون مفید باشه. مثالها بیشتر شامل مواردی هست که برای هممون آشناست و بهش برخوردیم.
مثلا یکی از کاربرداش تحلیل نرخ خرابی قطعات و میزان هزینه ایی که براشون صرف میشه در دیتا سنترها هستش.
یا چک لیست های خلبان ها قبل پرواز، یا شمارشی که در اتاق عمل انجام میدن تا از موندن گاز (پانسمان) در بدن بیمار جلوگیری کنند.
زمانی که علت روپیدا نمیکنیم استفاده از روش بیومیمیک (حل مشکلات با الهام از طبیعت) توصیه میکنه.
مثلا یک دکتر سوئیسی که با سگش میره جنگل و از چسبیدن گیاه زردینه (سرده) به سگش و لباس خودش ایده چسب های شرکت ولکرو به ذهنش میرسه. یا ایده قطار های تندرو ژاپنی که از روی پرنده کینگ فیشر گرفته شده، یا ایده کلاه ایمنی دوچرخه سواری که از سر دارکوب گرفته شده، یا شیشه هایی که خودشون رو تمیز میکنند که به اثر لوتوس معروف هستش و از نیلوفر آبی ایده اون گرفته شده اشاره میکنه.
بیان مسئله یکی دیگه از مواردی هست در این کتاب بهش پرداخته میشه، چطور مشکل رو باید به درستی پیدا و شرح بدیم؟ مهم که اصطلاحات استفاده شده در بیان مسئله نامشخص، مبهم، یا مایل به مبهم نباشه.
مفاهیم و ابزار های شرح داده شده در این کتاب:
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).
مثال ۱: افزایش دان تایم: با اینکه نشون میده مشکلی وجود دارد، اما مطمئناً برای تشخیص علت کافی نیست. سوالات خوبی که میشه در این مرحله مطرح کرد:
کدام سرور(ها)؟
کدام بخش؟
چند وقته خیلی زیاد شده؟
چقدر زیاد؟
سطح قابل قبول چقدره؟ یا قبل از غیرقابل قبول شدن چه سطحی بوده است؟
نوع دان تایم (به عنوان مثال، خرابی، ارتقاء نرم افزار، یا تعمیر و نگهداری سخت افزار) در اعداد وجود داره یا مستثنی شده؟
مثال۲: درصد مشتریانی که خودروهایشان در زمان وعده داده شده آماده تحویل نبودند در سه ماه گذشته افزایش یافته است.
چقدر افزایش یافته است؟
میانگین هفته قبل چقدر بود و الان چقدر است؟
افزایش ناگهانی بود یا تدریجی؟
آیا میشه مشتریان با توجه به نوع کاری که انجام دادند به طور دقیق تری شناسایی کرد؟
کدام سه ماه (به عنوان مثال، "سه ماه گذشته" نسبت به حال هست و تغییر خواهد کرد)؟
مثال ۳: دو بیمارستان در حال مقایسه مدت زمان عمل جراحی تعویض مفصل زانو بودند. هر بیمارستان روند خود را در سطح بالایی ترسیم می کند و سپس داده ها را جمع آوری می کند تا بفهمد هر یک از مراحل اصلی چقدر طول کشیده است. مشخص شد که یک بیمارستان به طور قابل توجهی زمان کمتری را در اتاق عمل نسبت به بیمارستان دیگر صرف میکند و به نظر میرسد که این نقطه خوبی برای بهبود بیمارستان دوم باشد. اما مشخص شد که هر بیمارستان تعریف متفاوتی از زمان شروع شد و پایان عمل دارد در نتیجه اعداد متفاوتی بدست می آوردند. یعنی آنها تعاریف عملیاتی متفاوتی برای زمان داشتند و معیار مقایسه مناسبی در نظر نگرفتند.
مثال ۴: این مثال درباره اهمیت مشاهده و نقطه نظر هستش. این مورد معلوم نیست واقعیه یا خیالی، اما زیاد میشنوم از بچه های نرم افزاری. میگن یک تیم آی تی در نیمه های شب گاه به گاه با دان شدن سرور مواجه میشدن و بعد از مدتی دوباره سرور ها به وضعیت عادی برمیگشتن. بررسی سخت افزاری و نرم افزاری هیچ چیزی رو مشخص نکرد، بنابراین تصمیم گرفتند شیفتی تو شرکت بمونند تا ببینند علت چی هستش. چند شب اول هیچی پیدا نکردن، ولی در نهایت علت را پیدا کردند که نگهبان ساختمان سرور را از برق جدا میکرده تا کف شور به برق بزنه!