یک سیستم گزارش و ارزیابی خرابی و عمل اصلاحی (FRACAS) قدرتمند ستون فقرات تلاش در جهت بهبود عملکرد دارایی ها است. FRACAS عناصر کسب و کاری لازم را جهت بستن حلقه ی عملیات های RCFA و RCM ارائه می کند. FRACAS، آنالیز ریشه خرابی ها را از یک فرایند خطی و یکباره، به یک برنامه ی مدیریت شده جهت بهبود روشمند عملکرد دارایی ها و فرایند ها، تبدیل می کند. این مقاله عناصر اصلی جهت پیاده سازی FRACASو چگونگی استفاده از آن جهت تضمین پیاده سازی توصیه های RCFA را تشریح می کند.
شکل 1- فرایند FRACAS
1. مدیریت FRACAS
FRACAS یک سیستم است بنابراین مثل هر سیستم دیگری نیاز به توجه مدیریت دارد. برای پیاده سازی FRACAS نیاز به یک مدیریت هدفمند است تا FRACAS از بالا به پایین و در سرتاسر سیاست ها و دستورالعمل ها جهت تضمین کیفیت کار و دریافت نتایج با معنی، اعمال گردد.
1.1 سیاست ها
نخستین مرحله در توسعه ی FRACAS پایه گذاری سیاست های مدیریتی برای بهبود قابلیت اطمینان تجهیزات و فرایندهاست که شامل الزاماتی برای گزارش دهی، ارزیابی و سیستم اصلاح خرابی ها است. بیانیه ی سیاست باید شامل تشریح اهداف FRACAS، بیان مسئولیت های افراد در تمامی سطوح و شرحی از عناصر پایه ای لازم برای FRACAS باشد.
2.1 دستورالعمل ها
FRACAS یک سیستم دستورالعمل محور است. در این سیستم نیاز است تا دستورالعمل هایی برای گزارش دهی، ارزیابی و اصلاح خرابی ها نگاشته شود. در دستورالعمل های FRACAS راهنمایی هایی جهت این که خرابی ها چگونه گزارش شوند، اطلاعات در کجا ذخیره شوند، کدام روش ارزیابی خاص باید استفاده شود، ارزیابی ها چه موقع استفاده شوند و چه کسی آن ها را بکار گیرد، می آید.
2.عناصر پایه برای اجرای FRACAS
1.2 گزارش خرابی
خرابی ها باید بگونه ای گزارش شوند که اطلاعات خرابی حاصله را بتوان در ابزارهای مهندسی قابلیت اطمینان، مثل ویبول، RCM و شبیه سازی قابلیت دسترسی استفاده کرد. بهترین الگوی گزارش دهی، استفاده از مدهای خرابی به عنوان پایه ای برای گزارش خرابی هاست. الگوهای خرابی باید ساختار سلسله مراتبی تجهیزات را درون فرایند دنبال کنند.
1.1.2 مدهای خرابی
مد خرابی، شرحی است بر آنچه که بر یک جز (Component) از آیتم قابل نگهداشت (Maintainable Item) اتفاق افتاده. مدهای خرابی علت ناتوانایی سیستم در تولید خروجی مطلوب از آن هستند.
2.1.2 ایجاد لیست مدهای خرابی
بهترین روش ایجاد لیست مدهای خرابی، استفاده از یک سیستم ترتیبی از ارزیابی وظیفه ای تجهیز مورد استفاده در فرایند است (م: درخت اجزاء). تجهیزات بصورت سلسله مراتبی می شکنند و بصورت گرافیکی نمایش میدهد که چطور اجزای یک تجهیز در کنار هم باعث می شوند که خروجی مورد انتظار از تجهیز بدست آید.
شکل 2- سلسه مراتب دارایی
3.1.2 آنالیز مدها و اثرات خرابی (FMEA)
FMEA شاید بهترین روش جهت ایجاد لیست مدهای خرابی برای استفاده در سیستم گزارش دهی FRACAS باشد. FMEA یک ارزیابی کاملا روشمند در نگاه به وظایف آیتم های قابل نگهداشت جهت تعیین محتمل ترین علل از دست رفتن وظیفه هاست. علل از دست رفتن خرابی های های وظیفه ای، مدهای خرابی تجهیز هستند. (م: این تعریف با آنچه که در استانداردهایی چون ISO 14224 آمده، متفاوت است. در استاندارد ISO 14224 مدهای خرابی ظاهر خرابی در سطح تجهیز هستند (که در این مقاله آن ها را با نام خرابی های وظیفه ای معرفی کرده) و مدهای خرابی در سطح آیتم قابل نگهداشت، مکانیزم خرابی معرفی می شود.).
FMEA که باعث شناسایی تمامی مدهای خرابی تجهیز شود، دقیق ترین نتایج را تولید می کند اما ممکن است عملیات شناسایی زمان زیادی را بطلبد و تا مدت ها نتوان از آن ها در گزارش های خرابی روزانه استفاده کرد. بجای این کار می توان با استفاده از درخت اجزای تجهیز و لیستی از محتمل ترین خرابی ها، مدهای خرابی را شناسایی کرد. اجرای FMEA بهتر است توسط افرادی که روزانه با تجهیز کار می کنند انجام شود. آن چه مهم است، درک وظایف تجهیز و شناسایی عواملی است که باعث از دست رفتن وظایف تجهیز می شود.
1.3.1.2 آیتم های قابل نگهداشت
آیتم های قابل نگهداشت پایین ترین سطح سلسله مراتب آیتم ها هستند که خود می توانند به اجزا (Component) بشکنند. آیتم های قابل نگهداشت وظایف منحصر بفرد و تعریف شده ای دارند که از دست رفتن آن ها منجر به از دست رفتن تولید، کاهش کیفیت، مشکلات ایمنی، محیط زیستی و بهره برداری می شود. (م: در استاندارد ISO 14224 آیتم های قابل نگهداشت و اجزاء معادل هم هستند و می توانند به قطعات که پایین ترین سطح در سلسله مراتب آیتم ها هستند، بشکنند.).
تاکتیک های نگهداشت و استراتژی های حفظ عملکرد مطلوب سیستم، در سطح آیتم های قابل نگهداشت اعمال می شود.
2.3.1.2 وظایف
وظایف یک آیتم قابل نگهداشت، علت وجودی آن را تعریف می کنند. بیشتر آیتم های قابل نگهداشت یک یا چند وظیفه اصلی و یک یا چند وظیفه ی فرعی دارند. وظایف آنچه را که آیتم قابل نگهداشت انجام می دهد، شرح می دهند، نه آنچه که آیتم قابل نگهداشت هست. وظیفه ها باید بگونه ای تشریح شوند که شناسایی خرابی وظیفه ای آسان شود. بهترین روش بیان وظایف، استفاده از زبانی است که ما روزانه استفاده می کنیم. اصطلاحات محلی تا زمانی قابل قبول هستند که کسانی که از FMEA استفاده می کنند معنای آن ها را بفهمند.
3.3.1.2 خرابی های وظیفه ای
خرابی های وظیفه ای از دست رفتن وظیفه ی لازم یا مطلوب آیتم قابل نگهداشت را تشریح می کنند. خرابی های وظیفه ای معمولا شامل یک صفت و نام وظیفه هستند. خرابی های وظیفه ای بندرت حاوی نام یک قطعه هستند.
4.3.1.2 مدهای خرابی
زمانی که خرابی های وظیفه ای تعریف شدند، ما می توانیم مدهای خرابی را (مانند آنچه که در جداول یک و دو نمایش داده شده) شناسایی کنیم. نکته ی مهم این است که بیاد داشته باشیم که مدهای خرابی ترکیبی از نام یک جزء و کلمات توصیف کننده است جهت این که بگوید چه بر سر جزء آمده است.
2.2. مسئولیت ها
هر عوض از سازمان نقش و مسئولیتی در ارتباط با گزارش خرابی ها دارد و هر شخص در سازمان باید نقش و مسئولیتش را در این مورد درک کند.
1.2.2 مدیریت دارایی ها
مدیر دارایی ها مسئول پایه گذاری سیاست هایی است که جهت توسعه ی FRACAS لازم است. مدیر دارایی ها انگیزه ی بالا به پایین را جهت تضمین این که هر شخصی در سازمان بر گزارش دهی، ارزیابی و اصلاح خرابی ها تمرکز لازم را دارد، ایجاد می کند.
2.2.2. مسئول پروژه
مسئول پروژه ی FRACAS مسئولیت نگارش دستورالعمل های لازم جهت پیاده سازی برنامه را به عهده دارد. مسئول پروژه، ارتباطات بالا به پایین سیاست های برنامه، اهداف و نتایج را برقرار می کند. مسئول پروژه، مستقیما مسئول تضمین این است که آموزش های لازم انجام شود و هر شخص در سازمان بداند که نقش و هدفش در برنامه ی FRACAS چیست.
3.2.2 مدیران بهره برداری و نت
توسعه ی موفق و استفاده از FRACAS نیاز به همکاری مشترک میان مدیران نت و بهره برداری دارد. غالبا شکست در ارتباطات در این سطح می تواند منجر به کاهش قابل توجه در مزایایی شود که می تواند با وجود اجرای FRACAS به دست آید. معمولا لحن ارتباطی میان این دو مدیر، لحن ارتباطات میان زیردستانشان را تعیین می کند.
4.2.2. ناظران بهره برداری
ناظران بهره برداری نقش خیلی مهمی در توسعه و حفظ FRACAS بازی می کنند. ناظران بهره برداری مسئول تضمین این هستند که اهداف FRACAS به گزارش هایشان اعمال شود و خرابی ها بصورت خیلی با کیفیت گزارش شوند. گزارش اولیه ی خرابی بی کیفیت منجر به گزارش نهایی بی کیفیت می شود و اطلاعات جمع آوری شده را جهت پیش بینی و پیش گیری خرابی در آینده، بی فایده می سازد.
5.2.2 ناظران نت
ناظران نت نیز نقش خیلی مهمی در توسعه و حفظ FRACAS ایفا می کنند. آن ها مسئول تضمین این هستند که پرسنل نت، زمان لازم را صرف تضمین این که اطلاعات خرابی، صحیح و مطابق با مدهای خرابی تعریف شده درون سیستم گزارش دهی FRACASاست، بگذارند. در اینجا نیز، گزاش اولیه ی خرابی بی کیفیت منجر به گزارش نهایی بی کیفیت می شود و اطلاعات جمع آوری شده را جهت پیش بینی و پیش گیری خرابی در آینده، بی فایده می سازد. یک گزارش خرابی خوب به ارتباطات خوب میان ناظران بهره برداری و نت نیاز دارد.
6.2.2 بهره برداران
بهره برداران گزارش های اولیه ی خرابی را برای FRACAS تهیه می کنند. آن ها باید متوجه اهمیت گزارش های بامعنی و صحیح درباره ی خرابی های وظیفه ای مشاهده شده باشند. بهره برداران باید درک کاملی از آیتم های قابل نگهداشتی که در سیستم حضور دارند، داشته باشند. از بهره برداران توقع می رود که خرابی های وظیفه ای را با جزئیات کافی تشریح کنند تا به مجریان نت در فرایند عیب یابی و به ارزیابان خرابی با تهیه ی اطلاعات مفید کمک کنند.
7.2.2. مجریان نت
مجریان نت در جایگاهی هستند که بیش ترین تاثیر را بر روی خروجی عملیات FRACAS دارند. آن ها معمولا بهتر از هر کسی می توانند تعیین کنند که کدام جزء از تجهیز خراب شده و چه بر سر آن آمده است. همچنین آن ها ممکن است بتوانند تعیین کنند که علت ریشه ای خرابی چه بوده است اما این منطقی نیست که از آن ها انتظار داشته باشیم که بتوانند علت ریشه ای هر خرابی را تعیین کنند. مجری نت مشئولیت های خیلی خاصی دارد که لازم است برشمرده شود.
1.7.2.2 حفظ شواهد
مجری نت معمولا اولین نفری خواهد بود که در صحنه حضور می یابد و با اجزای خراب شده ارتباط مستقیم دارد. وی باید وضعیت اجزا را همانگونه که مشاهده کرده، مستند، ثبت و ضبط کند. مجریان باید فنون حفظ شواهد خرابی و چگونگی ثبت وضعیت اطراف جزء را با استفاده از کلمات و تصاویر یاد بگیرد. در هیچ موردی مجری نباید سعی کند که وضعیت را تمیز کند یا وضعیت اجزای خراب را تغییر دهد. مجری باید شواهد را بوسیله ی پوشاندن آزادانه ی آن بوسیله ی حفاظی مثل کیسه ی پلاستیکی جهت جلوگیری از آلودگی از منابع خارجی حفظ کند.
2.7.2.2 ثبت وضعیت
مجری باید وضعیت های اطراف اجزای خراب را ثبت کند. بهترین روش گرفتن عکس و نوشتن یادداشتی مختصر درباره ی آنچه که دیده است، می باشد.
3.7.2.2 شناسایی علل بالقوه و عوامل سببی
ممکن است مجری بتواند تعیین کند که چه عاملی باعث خرابی جزء شده و همچنین بتواند برخی عوامل سببی که ممکن است منجر به خرابی شده باشد را تعیین کند. البته مهم است که به مجری اجازه دهیم که بگوید " نمی دانم". اغلب مجری در خلال ارزیابی اولیه ی صحنه ی خرابی، قادر به این نیست که بگوید چه چیزی باعث خرابی آیتم شده است. در این مورد گفتن این که نمی داند، بهتر است از این که بی حساب، علت ریشه ای خرابی را حدس بزند. تعیین علت خرابی ممکن است نیاز به آزمایشات بیشتری بوسیله ی مهندسان متخصص مثل مهندسین مواد و افرادی که در تعیین علت اجزای خرابی تجربه دارند، داشته باشد.
8.2.2. ارزیاب
ارزیاب خرابی، مسئول غربال کردن گزارش های اولیه خرابی است تا تعیین کند که آیا گزارش ها کاملند و آیا به ارزیابی بیشتری نیاز است یا نه. ارزیاب ممکن است بسته به پیامدهای خرابی، درخواست انجام RCFA بدهد. تعیین این که سفارش RCFA توسط ارزیاب چه موقع انجام شود، باید بر مبنای سیاست ها و راهنماهای نوشته شده در FRACAS باشد. ارزیاب همچنین مسئول تضمین این است که داده ی خرابی در ابزارهای ارزیابی در دسترس و بر اساس مقررات، استفاده شوند تا تعیین شود که آیا نیازی به بروزرسانی برنامه های نگهداشت پیشگیرانه و پیشگویانه است یا انجام RCFA بر روی مدهای خرابی تکراری و یا انجام RCFA بر روی مدهای خرابی اولیه (infant).
3. پایگاه داده ی FRACAS
1.3 مقدمه
پایگاه داده ی FRACAS مخزنی برای تمامی اطلاعات خرابی جمع آوری شده است. این مخزن باید به گونه ای ایجاد شود که اجازه ی ورود آسان اطلاعات خرابی و بازیابی آسان داده های خرابی را برای ارزیابی به روش های مختلف بدهد. پایگاه داده FRACAS ممکن است بسته به اندازه و مهارت سازمان در انواع مختلفی وجود داشته باشد.
2.3. فرم های پایگاه داده
پایگاه داده ی FRACAS ممکن است در سازمان های کوچک توسط خود سازمان برنامه نویسی شود و یا در سازمان های بزرگ نرم افزار اختصاصی برای آن خریداری شود و یا با CMMS یا EAM یکپارچه شود.
1.2.3. پایگاه داده ی برنامه نویسی شده در سازمان
شرکت های کوچک یا سازمان هایی که بودجه یا منابع کافی برای خرید نرم افزار CMMS ندارند، ترجیح می دهند که پایگاه داده ی FRACAS را خودشان را بسازند. مزیت این روش هزینه ی پایین و همچنین توسعه بر مبنای نیازهای خاص سازمان است. اینگونه پایگاه داده ها معمولا بوسیله ی یک فرد خاص که برای این کار اختصاص یافته نگهداری می شود. اشکال عمده ی این نوع نرم افزارها عدم توانایی در اشتراک و گزارش داده در محدوده ی بزرگتری از کاربران است. (م: همچنین عیب بزرگتر از دست رفتن پشتیبانی از نرم افزار با رفتن شخص پشتیبان نرم افزار از سازمان است.).
2.2.3 نرم افزارهای از پیش آماده
امروزه نرم افزارهای FRACAS زیادی وجود دارد. این نرم افزارها معمولا بیشتر برای سازمان های بزرگ مناسبند. بیشتر این نرم افزارها توانایی انجام برخی ارزیابی های از پیش تعبیه شده و توانایی الصاق اسناد و تصاویر جهت غنی سازی گزارش ها و ارزیابی ها را دارند. این نرم افزارها را ممکن است بتوان در محیط های LAN و WAN و یا بر روی اینترنت استفاده کرد. این نرم افزارها را یا باید بصورت جداگانه و یا ترکیبی از ورود داده ی جداگانه و خروجی اطلاعات از یک نرم افزار CMMS یا EAM، تغذیه کرد. در بیشتر موارد داده های ورودی اینگونه نرم افزارها از خروجی CMMS در فرمت اکسل بدست می آید.
3.2.3 نرم افزارهای CMMS و EAMS
سازمان های خبره ی دارای دپارتمان های فناوری اطلاعات یا سیستم های اطلاعاتی بزرگ، ممکن است بتوانند FRACAS را درون CMMS اجرا کنند. مزیت این راه حل این است که تمامی اطلاعات در یک مخزن مفرد قرار دارد که برای تمامی سطوح سازمان دردسترس است. عیب این مورد این است که سرمایه گذاری زیادی در برنامه نویسی نیاز دارد و ممکن است تغییر در برنامه نویسی نرم افزار را بوسیله تامین کننده ی آن لازم داشته باشد تا ماژول FRACAS را بازنویسی کند. (م: امروزه نرم افزارهای CMMS معتبر براساس پایگاه داده ی FRACAS برنامه نویسی شده اند و نیازی به بازنویسی در برنامه ندارند.).
3.3. حداقل الزامات پایگاه داده ی FRACAS
1.3.3 مقدمه
حداقل الزامات پایگاه داده ی FRACAS باید شامل عناصری باشد که به کاربران اجازه دهد تا خرابی ها را با استفاده از آنالیز ویبول، RCM، شبیه سازی قابلیت دسترسی و RCFA ارزیابی کنند. لیست زیر به معنای ارائه ی حداقل الزامات برای پایگاه داده است:
1.1.3.3. سلسله مراتب تجهیزات
پایگاه داده باید محتوی سلسله مراتب تجهیز تا سطح آیتم قابل نگهداشت باشد.
2.1.3.3. مدهای خرابی
مدهای خرابی باید در یک فرمت جدولی در پایگاه داده وجود داشته باشد. اگر امکان گروه بندی مدهای خرابی وجود داشته باشد، لیست مدهای خرابی خلاصه می شود و بنابراین زمان جستجوی مد خرابی مناسب و اختصاص آن به گزارش خرابی کاهش پیدا می کند.
3.1.3.3. تاریخ و ساعت
تاریخ و ساعت دقیق گزارش باید ثبت تا امکان ارزیابی موفق ویبول فراهم شود. عدم ثبت زمان های دقیق گزارش خرابی، بر توانایی ارزیاب در تعیین زمان های دقیق تا خرابی (TTF) برای مدهای خرابی خاص تاثیر می گذارد. حداقل، تاریخ خرابی باید ثبت شود.
4.1.3.3. شرح خرابی
گزارش دهنده ی خرابی باید توانایی تشریح آنچه اتفاق افتاده را در سخنان خود جهت شمول خرابی های وظیفه ای آیتم های قابل نگهداشت داشته باشد.
5.1.3.3. تاثیر خرابی
پایگاه داده باید شامل اطلاعاتی درباره ی تاثیری که خرابی بر سازمان از لحاظ هزینه، توقف، ایمنی، محیط زیست و تولید می گذارد، باشد.
6.1.3.3. عوامل سببی
اطلاعات درباره ی این که چه چیزی ممکن است علت خرابی باشد یا هر عامل سببی ای که ممکن است منجر به خرابی شود باید ثبت شود. این اطلاعات می تواند برای ارزیابی بعدی خرابی، حیاتی باشد.
7.1.3.3. پیگیری RCFA
خیلی از سازمان هایی که RCFA را انجام می دهند، نمی توانند قدرت RCFA را آزاد کنند، زیرا آن ها قادر نیستند حلقه ی توصیه های آن را ببندند. FRACAS یک مکان عالی جهت نگهداری اطلاعات درباره ی این است که کدام خرابی ها به RCFA نیاز دارند و چه کسی مسئول پیگیری اجرای توصیه های RCFA است.
2.3.3. قابلیت گزارش دهی
پایگاه داده ی FRACAS باید اجازه دهد که ارزیاب، گزارش های مختلف جدولی و گرافیکی را جهت کمک به ارزیابی خرابی ها تولید کند. گزارش داده های ویبول، تکرار مدهای خرابی مختلف شدیدا مهم هستند.
4. نتیجه
یک FRACAS که بخوبی طراحی شده، می تواند بخش مهمی از فرایند بهبود مستمر باشد. کدهای خرابی ای که بوسیله ی تحلیل وظیفه ای تجهیزات بدست آمده، قویا توانایی مهندس قابلیت اطمینان را در ارزیابی خرابی و تغییرات اولیه در طراحی تجهیز، استراتژی های نت و استراتژی های بهره برداری افزایش می دهد.
اگر کدهای خرابی دو قسمتی ساده در نرم افزارهای CMMS/EAM استفاده شوند، به بهره برداران و مجریان نت اجازه می دهد که اطلاعات خرابی را جهت استفاده در FRACAS، بصورت بهتر ثبت کنند.
نویسنده: بیل کیتر
