مرجع فیلم آموزشی و مقالات آموزشی برای موفقیت و پیشرفت

تکنیک های حل مسئله؛ چطور می‌توانیم مسائل را به خوبی حل کنیم؟

1

در حالی که اکثر افراد تولید ناب را ابزار و قوانینی می‌دانند همچون طرح‌ریزی جریان ارزش، جریان تک واحدی، کانبان،‌ ۵-اس، نگهداری و تعمیرات بهره‌ورِ فراگیر و رویداد‌های بهبود مستمر(کایزن) ، تعداد کمی هم به جنبه‌های دیگر این فکر می‌کنند. حل مسئله به دلیل توانمند کردن افراد تیم یکی از لازمه‌های اجرای موفق روش تولید ناب است.


حتما بخوانید: چگونه مهارت حل مسئله را در خودمان افزایش دهیم؟

تولید ناب راه‌حلی متفاوت در حل مسائل ارائه می‌کند. در این روش صرفا به اثرات مساله توجه نمی‌شود و هدف حذف این اثرات نیست، بلکه علت ریشه‌ای مساله شناخته می‌شود و علت ریشه‌ای و عوامل همراه با آن هردو از سیستم، فرآیند یا زیرساخت حذف می‌شوند تا مساله به طور دائم حل شود. تفاوت این دو روش چیست؟ ساده است، وقتی علت اصلی را پیدا و اصلاح کنید، مساله را همیشگی حل کرده‌اید، با این کار حتی مسائل دیگر ناشی از این علت هم برطرف می‌شوند.

واضح است ابتدا باید علت‌های ریشه‌ای مساله‌ را بشناسیم تا بتوانیم از طریق روش تولید ناب حل‌شان کنیم. اما چگونه؟ چه ابزارهایی برای این کار در دسترس است؟ ابتدا ببنیم حل مساله چیست؟ با پرسیدن سوال « مساله‌ی ما چیست؟» شروع می‌کنیم. تعریف درست مساله بر اساس آنگونه که شرایط استاندارد باید باشد است . به بیان دیگر ابتدا بدانید که در حالت درست شرایط چگونه باید باشد تا بتوانید علت احتمالی آنکه اینگونه نیست را پیدا کنید. پس از آنکه مساله شناخته شد می‌توان از روشهای مرسوم حل مساله استفاده کرد.

تیم‌های پربازده‌ معمولا از چهار ابزار حل مساله استفاده می‌کنند:

  1. برنامه، اجرا، بررسی، اقدام (PDCA)؛
  2. تحلیل ۵ چرا؛
  3. نمودا ایشیکاوا ( استخوان ماهی)؛
  4. تحلیل ساده شده‌ی اثرات و حالات شکست (SFMEA).

برنامه، اجرا، بررسی، اقدام

چرخه PDCA روشی موثر برای حل مساله ارائه می‌دهد. چرخه شامل موارد زیر است:

۱. برنامه

مساله را به طور واضح تعریف کنید(p1)

« مساله‌ای که خوب بیان شده، ‌مساله‌ای است نیمه حل شده» گرچه این مرحله پیش پاافتاده و ساده به نظر می‌رسد، نباید آن را دست کم بگیرید. بسیار مهم است که مسیر حل مساله را با بیان مختصر و مفید مساله‌ شروع کنید. اگر این بخش به درستی انجام نشود ممکن است منجر به یکی از این موارد شود: صرف زمان اضافه برای شناسایی علت‌ّها به دلیل تعریف وسیع مساله، سوگیری اعضای تیم به راه حلی خاص یا ممکن است حل مساله جای آنکه فرایندی برای شناسایی عامل ریشه ای و درمان آن باشد تبدیل به فرایند امتحان راه‌حل‌های مختلف ‌شود.

جمع آوری شواهد مربوط به مساله (P2)

در این مرحله توجه بر جمع آوری شواهد اثبات وجود مساله است. در حل مساله تیمی این مرحله باید سریع اجرا شود. خروجی این فعالیت شامل فهرستی از مدارک یا نمودارهایی است که وجود مساله و همچنین اندازه و اهمیت آن روشن می‌کند.

شناسایی تاثیرات یا فرصت‌ها (P3)

در این قسمت مزایای حل شدن مساله را بررسی می‌کنیم. این فعالیت باید از دو دیدگاه انجام شود زیرا کار تیم پروژه ممکن است یا مانند کار کنترلی باشد (مانند حل مساله‌ای که مانع رسیدن به نتایج موردنظر شده است) یا شکل بهبود خالص ( تلاش برای رساندن نتایج به سطح جدیدی از کارایی) در هر دو مورد خروجی این فعالیت فهرستی است از بیان تاثیرها و فرصت‌ها. این فهرست باید از جنس از دست دادن پول، زمان، محصول، دوباره‌کاری، زمان پردازش و/یا روحیه باشد.

اندازه گیری مساله (P4)

قبل از پیشروی در حل، تیم باید معتبر و قابل اعتماد بودن داده‌هایی که بر اساس آنها تصمیم‌ می‌گیرد را به سرعت بررسی کند. آیا اطلاعاتی وجود دارد که اعتبار،‌دقت یا قابل‌اعتمادبودن شواهد مساله را زیر سوال ببرد؟ چه از ابزار و تجهیزات برای ثبت اطلاعات استفاده کرده باشیم و چه افراد این کار را انجام داده باشند، باید این سوال را بررسی کرد. اگر اعضای تیم فکر احتمال می‌دهند که مساله‌ای اعتبار داده‌ها را مخدوش کرده باشد، باید این مسائل اندازه‌گیری، بررسی و حل شود و داده‌های جدیدی ثبت شود.

ملاک‌های موثربودن (P5)

در این مرحله اعضای تیم باید مشخص کنند که میزان موفقیتشان را چگونه اندازه‌گیری می‌کنند؟ این قسمت یکی از مهم‌ترین گام‌های روش PDCA و یکی از تفاوت‌های اصلی آن با روش‌های سنتی حل مساله است . روش کار به این صورت است که ابتدا پیش از اجرای اصلاحات ارزیابی انجام شود و بر سر چگونگی انجام این ارزیابی توافق شود سپس روش PDCA اجرا شود و پس از آن دوباره ارزیابی صورت بگیرد. پس از ارزیابی مجدد،‌ اعضای تیم باید تصمیم بگیرند که برای رسیدن به اهداف از پیش تعیین شده نیاز به انجام دوباره PDCA است یا خیر.


حتما بخوانید: آشنایی با مراحل حل مسئله به شیوه‌ای مؤثر

۲. اجرا

تعیین علت‌های ممکن (D1)

برای جلوگیری از افتادن در دام امتحان راه‌حل‌ها یا حل مساله از طریق آزمون و خطا، باید از «لوح سفید» شروع کرد و از چشم‌اندازی تازه فهرست همه‌ی علت‌های ممکن را نوشت. در این مرحله مرحله می‌توان از داده‌ها و دانش‌ جمعی تیم و تجربیات آن برای تشخیص عوامل محتمل‌تر استفاده کرد.

پیشروی در این روش باعث می‌شود که تیم در نهایت به علت‌های ریشه‌ای مساله دست یابد و فقط در درمان علائم ظاهری متوقف نشود. بهترین ابزار برای تسهیل این کار کشیدن نمودار علت و معلول توسط افرادی است که بیشترین دانش را از مساله دارند و با آن بیشتر درگیرند.

شناسایی عوامل مشکل‌دار و نیاز به تعمیر (D2)

قبل از انجام برنامه عملیاتی ( برای اصلاح عوامل) یا برنامه‌ی آزمون تجربی، اغلب بخش‌هایی از فرآیند مشکل دارد که باید به شیوه‌ّهای مختلف درست شود.

نوشتن برنامه عملیاتی یا طرح آزمایش تجربی (D3/4)

روش چه زمانی استفاده می‌شود؟ چه راه‌حلی؟
نوشتن طرح عملیات برای راه‌حل‌ها ۱. نمی‌توان علت های احتمالی را به آسانی تغییر داد.

۲. متغییرهای وابسته (به غیر از ملاک موثر بود) واضح نیستند.

۳. کمبود داده‌ برای بررسی علت ها

 

۱. طوفان فکری برای یافتن راه‌حل‌های ممکن

۲. برای علت‌های اصلی حوزه‌های جواب مشخص شود.

۳. برنامه عملیاتی نوشته می‌شود تا مشخص شود چه کاری، توسط چه کسی و چگونه انجام می‌شود

نوشتن طرح آزمایش تجربی ۱. هنگامی که بتوان علت‌های احتمالی را در دو یا چند سطح دستکاری کرد

۲. هر سطح را بتوان آسان و دقیق تغییر داد

۳. تأثیرات را بتوان از طریق متغیرهای وابسته اندازه گرفت

 

در طرح آزمایش تجربی از سایر تکنیک‌ها یا تکنیک‌های طراحی آزمون هم استفاده می‌شود

در این مرحله بسته به نوع مساله، روش PDCA دو راه را در پیش می‌گیرد. انتخاب روش بر اساس «داده‌مبنا» بودن یا « داده محدود» بودن مساله است. در جدول زیر تفاوت این دو روش و به طور خاص تفاوت برنامه عملیاتی و طرح آزمون تجربی نشان داده شده است. توجه داشته باشید در برخی مواد لازم است از ترکیب برنامه عملیاتی و طرح آزمون تجربی استفاده کنید.یعنی برای برخی عوامل مساله برنامه عملیاتی مناسب است و برای سایر عوامل همان مساله طرح آزمون تجربی بهترین روش است.

برای راه‌حل ها برنامه عملیاتی بنویسید (D3)

برای شروع نوشتن برنامه عملیاتی اعضای تیم باید درباره راه‌حل‌های ممکن در هر حوزه از عوامل، طوفان فکری برگزار کنند و بر سر راه‌حل‌هایی اولویت‌بندی شده به توافق برسند. این کار را می‌توان به طور گروهی انجام داد یا آنکه اعضا به چند تیم کوچکتر تقسیم شوند . در هر دو صورت همه‌ی اعضا باید با راه‌حل‌های پیشنهاد شده و برنامه عملیاتی موافق باشند. برنامه عملیاتی در قسمتِ «بررسی» استفاده می‌شود.

طرحی برای آزمون تجربی بنویسید (D4)

طرح آزمون تجربی مدرکی است که آزمون‌های لازم را نشان می‌دهد. این کار بررسی می‌کند که عوامل ریشه‌ایِ شناسایی‌شده واقعا بر متغییر‌های موردنظر ما تاثیر می‌گذارند یا خیر. گاهی اوقات ممکن است با یک آزمون تمام عوامل بررسی شوند و گاهی اوقات نیاز به چند آزمون است.

نکته: اگر احتمال وجود برهمکنش بین علت‌ها را می‌دهید،‌ علت‌های موردنظر باید در یک آزمون به صورت یکجا بررسی شوند.

طرح آزمون تجربی باید موارد زیر را دارا باشد:

  1. زمان/مدت آزمون؛
  2. چگونگی تغییر عوامل در طول آزمایش‌ها؛
  3. متغیرهای وابسته موردنظر؛
  4. هر گونه متغیر نویزی که باید دنبال شود؛
  5. مواردی که باید ثابت نگه داشته شود.

همه افراد درگیر آزمایش باید پیش از شروع آزمون از موارد زیر مطلع شوند:

  1. هدف آزمون؛
  2. جزئیات طرح آزمایش؛
  3. نقش آن‌ها چیست؛
  4. ملاک‌های اصلی کیفیت نتایج.

وقتی راه‌حل‌ها بررسی شد، اعضای تیم باید آماده‌ی آزمودن راه‌حل‌ها و استفاده از روش « کلید قطع و وصل » شوند.

منابع شناسایی شده (D5)

بعد از نوشتن برنامه عملیاتی و طرح‌ازمون برای اعضای تیم تقریبا واضح است که چه منابع نیاز دارند. برای منابعی که بر عهده‌ی تیم نیست باید فهرستی تهیه شود و افرادی که به این منابع نیاز دارند، دلیل نیازمندی، چارچوب زمانی و مقدار زمان تقریبی موردنیاز در آن ذکر شود . این اطلاعات به تیم مدیریت داده می‌شود.


حتما بخوانید: حل مسئله به روش خلاقانه

جدول زمانی اصلاح شده PDCA (D6)

در این مرحله اعضای تیم نسبت به آنچه در ادامه PDCA قرار است انجام شود شهود بهتری دارند و باید جدول‌های زمانی ارائه شده در طرح را اصلاح کنند و تحویل تیم مدیریت دهند.

بررسی/ تایید تیم مدیریت (D7)

اکنون تیم به مرحله‌ای مهم در چرخه PDCA رسیده است.کاری که قرار است انجام دهند تاثیر و نتایج مهمی بر دپارتمان دارد. به همین دلیل لازم است کارشان را برای تیم مدیریت ارائه دهند این کار را هم رهبر تیم ‌می‌تواند انجام دهد و هم کل تیم. محتوا و هدف ارائه از این قرار است:

  • ارائه خروجی تیم؛
  • ارائه منطقِ پشت کار.

دریافت تایید تیم مدیریت برای:

  • میزان موثربودن با ملاک قبل از آزمایش؛
  • عوامل مهم؛
  • برنامه عملیاتی ( برای راه‌حل‌ها) یا طرح آزمایش تجربی؛
  • جدول زمانی اصلاح شده.

۳. بررسی

برنامه ریزی

اجرای آزمای تجربی یا برنامه عملیاتی (C1/C2)

بسته به ماهیت مساله، تیم باید یکی از این گام‌ها را بردارد:

  • اجرای آزمون‌های تجربی برای تایید عوامل ریشه‌ای یا
  • اجرای کامل و دقیق راه‌حل‌های هر عامل و سپس برسی داده‌ها برای مشخص شدن میزان موثر بودن راه‌حل‌ّها.

عمل‌کردن به برنامه عملیاتی (C1)

پس از آنکه راه‌حل‌های ارائه شده در برنامه عملیاتی بررسی شدند و اعضای تیم با آن‌ها موافق بودند برای تایید موثر و مناسب بودن این راه‌حل‌ها لازم است از روش « کلید قطع و وصل» استفاده شود. برای استفاده از این روش، باید متغیر‌های وابسته شناسایی شوند یعنی متغیرهایی که می‌خواهیم با تغییر علت‌ها بر آن‌ها تاثیر بگذاریم.

اجرای طرح آزمون تجربی

در مدت زمان اجرای قسمت بررسی باید آزمایش‌هایی تجربی برای بررسی همه عامل‌های اصلی انجام شود و داده‌ها تحلیل شود و نتایج استخراج شود و به تایید تیم برسد.

تجزیه و تحلیل اطلاعات به دست آمده از آزمایش‌ها یا برنامه عملیاتی (C3)

به طور معمول یک نفر از اعضای تیم مسئول تحلیل داده‌های طرح آزمون می‌شود. در صورت لزوم این فرد باید از منابع در دسترسِ دپارتمان یا شرکت برای انتخاب ابزارهای مناسب تحلیل داده و تفسیر خروجی ‌ها استفاده کند. ابزاری که استفاده می‌شود به ماهیت طرح آزمون بستگی دارد.

تصمیم درباره برگشت به مرحله اجرا‌ ‌ٔ‌یا پیشروی (C4)

بعد از بازبینی نتایج تحلیل داده درمورد عوامل احتمالی یا راه‌حل‌های آزموده‌شده، اعضای تیم باید تصمیم بگیرتد براساس این اطلاعات چه اقدامی را انجام دهد.

اجرای برنامه برای ایجاد تغییرات دائمی (C5)

گام تحلیل داده‌ها ممکن است در هر یک از حالت‌های زیر اجرا شده باشد:

  • بعد از آنکه برنامه عملیاتی ( راه‌حل‌ها) انجام شد، تحلیل داده صورت گرفت تا مشاهده شود که آیا متغیرهای وابسته تغییر کرده‌اند یا خیر. اگر نتایج دلخواه بود تیم می‌تواند به سراغ طرح اقدام برود.
  • طرح آزمون تجربی اجرا شد و داده ها تحلیل شدند تا تاثیر علت‌ها بررسی شود. اگر نتایج دلخواه بود ( عوامل اصلی شناسایی شدند) اعضای تیم باید پیش از رفتن به مرحله طرح اقدام راه‌حل‌هایی برای غلبه بر عوامل‌ یافته‌شده طراحی کنند ( برای مثال ممکن است از طریق طرح ازمون مشخص شود که اختلافات آزمایشگاهی در اندازه‌گیری‌ها اثرگذارند)

میدان نیرو در اجرا (C6)

پس از نوشتن برنامه عملیاتی، اعضای تیم باید به تحلیل میدان نیرو بر عوامل له و علیه اجرای موفق بپردازند. منظور از موفق آن است که پس از اجرای راه‌حل‌ها،‌ نتایج آزمون‌ها به طور همواره درست باشند.

بررسی/ تایید تیم مدیریت (C7)

تیم به مرحله‌ای بسیار حیاتی در چرخه PDCA رسیده است و باید پیش از ادامه کار با تیم مدیریت ملاقات داشته باشد. این دیدار بسیار مهم است زیرا قرار است تغییراتی دائمی در عملکردها داده شود. تیم مدیریت نباید فقط این تغییرات را تایید کند بلکه باید شیوه‌ی اجرای آن را هم بررسی و تایید کند.

۴. عمل

موانع

عمل‌کردن به برنامه عملیاتی (A1)

اگر برنامه‌ای کامل،‌ واضح و فکر‌شده نوشته باشید، هنگام اجرای آن برایتان واضح است که هرکس باید چه کاری را در چه زمانی انجام دهد. باید بسیار توجه کرد ارتباطات و آموزش‌ها به طول کامل انجام شود به گونه‌ای که هر یک از اعضای دپارتمان بدانند که چه چیزی‌ تغییر می‌کند، چرا تغییر می‌کند و برای موفقیت طرح چه کاری باید انجام دهند.

اندازه‌گیری میزان موثربودن (A2)

بعد از آنکه همه تغییرات اعمال شد و زمان مورد نیاز برای مشاهده تاثیرگذاری این تغییرات سپری شد، اعضای تیم باید همه داده‌ّ را جمع‌اوری کنند و بررسی کنند که آیا تغییر چشمگیری رخ داده است یا خیر.

تحلیل نتایج به دست آمده با توجه به اهداف تیم (A3)

در گام قبل بررسی شد که آیا اعمال تغییرات، تاثیر چشمگیری بر معیارهای موثربودن گذاشته است یا خیر. اما نمی‌توان در اینجا متوقف شد. اگه جواب سوال قبل «بله» است، باید بررسی کرد که مقدار بهبود برابر با اهداف از پیش تعیین شده است یا خیر.

جمع‌آوریِ بازخورد‌های تیم (A4)

بعد از تایید موفقیت چرخه PDCA ( بر اساس تغییر ملاک موثربودن) باید این اطلاعات به تیم مدیریت ارائه شود. پیش از این کار، لازم است رهبر تیم از اعضا بازخورد بگیرد. این بازخورد به شکل پرسشنامه‌ای است که همه اعضای تیم از جمله خود رهبر پر می‌کنند. نتایج توسط رهبر بررسی و در فرم مربوط به قسمت A3 ثبت می‌شود.

جلسه نهایی با تیم مدیریت (A5)

پیش از پایان کار باید جلسه‌ای با تیم مدیریت برگزار شود. مسائلی که باید در این جلسه مطرح شود شامل موارد زیر است:

  • جمع بندی تمام کارهای ناتمام
  • بررسی میزان موثربودن نتایج در مقایسه با اهداف تیم
  • اطمینان از این که مدارک تیم کامل و مرتب است
  • مطرح کردن بازخوردهای اعضای از تجربه کار تیمی ( از طریق فرم‌های استاندارد و صحبت‌های غیررسمی)

روش حل مساله ۵ چرا

وقتی با مساله‌ای مواجه شدید،‌ به محلی که مساله اتفاق افتاده است بروید و پنج بار بپرسید «چرا». با این روش علل ریشه ای مساله را پیدا می‌کنید و می‌توانید آنها را برطرف و مساله را حل کنید.

تحلیل ۵چرا از بخش‌بندی داده‌ها، آزمودن فرضیات، رگرسیون یا سایر ابزارهای پیشرفته آماری استفاده نمی‌کند، حتی در بیشتر موارد می‌توان آن را بدون جمع‌آوری داده انجام داد. با حداقل پنج بار پرسیدن «چرا» می‌توانید لایه‌های سطحی نشانه‌ها را کنار زده و به علت ریشه‌ای مساله دست یابید.

برای استفاده از روش ۵ چرا در مشخص کردن علت ریشه‌ای مساله مثالی می‌زنیم: فرض کنید تعداد زیادی از مشتریان، کالایی خاص را برگردادنده‌اند. بیاید با روش پنج چرا این مساله را بررسی کنیم:

۱. سوال: چرا مشتری‌ها محصول را برمی‌گردانند؟

جواب: ۹۰ درصد برگشت‌ها به دلیل وجود سوراخ در پنل کنترل است

۲. سوال: چرا پنل کنترل سوراخ است؟

جواب: پنل‌های کنترل پیش از حمل‌ونقل بازرسی شده‌اند بنابراین باید هنگام حمل آسیب دیده باشند.

۳. سوال: چرا پنل‌ها هنگام حمل‌ونقل آسیب دیده‌اند؟

جواب: زیرا طبق استاندارد بسته‌بندی نشده اند.

۴. سوال: چرا مطابق با استاندارد بسته‌بندی نشده‌اند؟

جواب: زیرا حمل‌ونقل استاندارد بسته‌بندی ندارد.

۵. سوال: چرا حمل‌و نقل استاندارد بسته‌بندی ندارد؟

جواب: زیرا در فرآیند معمول ارسال محصول استانداردی برای حمل تهیه نمی‌کنند.

استفاده از پنج چرا در این مورد نشان داد که وجود نقص در فرایند ارسال محصول منجر به بازگشت آن توسط مشتری شده است.

نمودار اشیکاوا

در برخی موارد ممکن است مساله‌ای بیش از یک عامل اصلی داشته باشد. فرآیند ۵ چرا شاید نتواند اینگونه مسائل پیچیده تر را حل کند. نمایش تصویری اینگونه تحلیل‌ها را می توان با نمودار ایشیکاوا یا علت و معلول نشان داد. این فرآیند به دلیل شکلش به استخوان ماهی نیز معروف است. روش ایشیکاوا به افراد کمک می‌کند تا علت ریشه‌ای و عوامل سهیم در ایجاد مساله را در قالبی تصویری، ساده و گویا نشان دهند. این روش راهی بسیار واضح برای ارائه ارتباط بین علتِ اصلی مساله و همه عوامل احتمالی مرتبط است.

نمودار علت و معلول یا نمودار استخوان ماهی ابزاری گرافیکی برای شناسایی ارتباط بین مساله و علت‌های احتمالی آن است. یکی از موثرترین راه‌های ایجاد چنین نموداری، انجام طوفان فکری درباره علت‌های ممکن است. برای مثال می‌توان برای تعیین علل احتمالی نقص چندباره در فرآیند تولید از نمودار علت و معلول استفاده کرد.

نمودار استخوان ماهی همچون اسکلت ماهی رسم می‌شود به این صورت که مساله در سمت راست نوشته شده و طبقه‌بندی‌های اصلی علت‌ها در جعبه هایی در سمت چپ نمودار نوشته می‌شوند که خلاصه‌ای از علل اصلی هر دسته را بیان می‌کنند. این جعبه‌ها‌ اغلب شامل روش‌ها، اندازه‌گیری‌ها،‌ دستگاه‌ها،‌ مواد و افراد هستند.

زیر هر دسته، عوامل مرتبط با آن نوشته می‌شود. برای مثال اگر این واقعیت که اجزای ناسالم تحویل تیم مونتاژ شده است به عنوان علت احتمالی مساله‌ای بیان شود، این موضوع به عنوان شاخه‌ای زیر دسته «مواد» نوشته می‌شود.

هر دو روش نمودار استخوان ماهی و تحلیل پنج چرا روش‌هایی ساده و بسیار مفید در حل مساله هستند. یکی از گام‌های اولیه برای ایجاد فرهنگ ناب تبدیل همه کارمندان به حل‌کننده‌ی‌ مساله است . این کار باید از طریق آموزش مداوم روش «پنج چرا» شروع شود.

تحلیل ساده شده‌ی اثرات و حالات شکست

تحلیل ساده شده‌ی اثرات و حالات شکست روشی از بالا به پایین در تحلیل طراحی است که به طور گسترده در صنعت استفاده می‌شود. شرکت‌های خودروسازی امریکایی مانند کرایسلر، فورد و جنرال‌موتورز از این نوع تحلیل استفاده می‌کنند. استانداردهای صنعتی وشرکتیِ بسیار متنوعی وجود دارد اما یکی از پراستفاده‌ترین آنها استاندارد « گروه عملیاتی صنایع خودروسازی » (AIAG ) است.

استفاده از این استاندارد از بررسی هر جزء یا بخش عملکردی و چگونگی احتمال خرابی این اجزا شروع می‌شود (که «حالت‌های خرابی» نامیده می‌شود). سپس تاثیر هر حالت خرابی و شدت آن بر عملکرد سیستم را بررسی می‌شود. در گام بعدی احتمال وقوع و تشخیص آن شکست با استفاده از عدد اولویت ریسک مشخص می‌شود. این عدد را می‌توان از فرمول زیر حساب کرد:

RPN = اهمیت × وقوع × تشخیص

مرحله دوم در نظر گرفتن کارهای اصلاحی برای کاهش شدت یا احتمال وقوع یا افزایش تشخیص است. عموما با مقادیر بالاتر RPN شروع می‌کنند که نشان دهنده بغرنج‌ترین مساله است و به سمت مسائل ساده‌تر حرکت می‌کنند. پس از مشخص شدن کارهای اصلاحی، RPN‌ دوباره محاسبه می‌شود تا مقدار آن به کمترین حالت ممکن برسد.

نتیجه‌گیری

تیم‌های کاری می‌توانند از این چهار ابزار برای حل مسائلی که به طور روزمره با آن مواجه می‌شوند استفاده کنند. هیچ کدام از این ابزارها نیاز به مهارتی خاص ندارند در عوض بر دانش معمول، عقل سلیم و منطق بنا شده‌اند. دانش، تجربه و مهارت تجمیع شده‌ اعضای گروه برای موفقیت در این روش‌ها کافی است.

نکات روزمره برای حل مساله در سازمان‌های ناب:

  • نگذارید مسائل به ظاهر کوچک جمع شده و تبدیل به مشکلاتی بزرگ شوند. تنها راه حل کردن مسائل فردا، حلِ مسائل کوچک امروز است.
  • از ابزارهای مدیریت بصری و کارِ استاندارد برای شناسایی مشکلات کوچک (پیش از بزرگ شدنشان) استفاده کنید.
  • هرچه زودتر مهارت‌ها، ابزارها و سیستم‌های حل این مسائل را آماده کنید
  • از تحیلی ۵ چرا برای رسیدن به عمق مساله و کشف علت ریشه‌ای استفاده کنید.
  • از روش PDCA (برنامه، اجرا، بررسی، اقدام) استفاده کنید. سازمان بدون فهم کامل از علت اتفاقات، نمی‌تواند فرآیندهایش را در جهت ناب ماندن کنترل کند.
  • حواستان باشد که مشکلات کوچک تاثیر مهمی بر نتایج آینده دارند.

ارسال دیدگاه

آدرس ایمیل شما منتشر نخواهد شد.

۱ دیدگاه
  1. del aram می‌گوید

    خیلی خوبه این ، البته که من کار آفرین نیستم اما در حل مسائل روزمره زندگی هم کارساز بود مخصوصا قسمت سوالاتش
    ممنون و خسته نباشید