چرا داده‌های خرابی در CMMS بی‌ارزش می‌شوند؟

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

چرا CMMS گاهی به بایگانی دیجیتال تبدیل می‌شود؟

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

اما پس از مدتی یک سؤال مهم مطرح می‌شود:

چرا با وجود ثبت این همه اطلاعات، گزارش‌های سیستم به تصمیم‌گیری مدیران کمک نمی‌کنند؟

در بسیاری از موارد، مشکل از نرم‌افزار نیست. کیفیت داده‌های ثبت‌شده اهمیت بیشتری دارد. یک CMMS حتی با امکانات پیشرفته نمی‌تواند از داده‌های ناقص و مبهم، تحلیل قابل اعتماد تولید کند.

این موضوع با اصل معروف GIGO توضیح داده می‌شود:

ورودی بی‌کیفیت = خروجی غیرقابل اعتماد

اگر کارکنان اطلاعات خرابی را درست ثبت نکنند، شاخص‌هایی مانند MTBF، MTTR، نرخ خرابی، هزینه تعمیرات، زمان توقف، دسترس‌پذیری و OEE نیز ممکن است تصویر دقیقی از وضعیت واقعی ارائه ندهند.

در چنین شرایطی، مدیران به‌جای تصمیم‌گیری بر اساس داده، به تجربه فردی یا حدس تکیه می‌کنند.

در این مقاله، ۵ اشتباه مهم در ثبت داده‌های خرابی در CMMS را بررسی می‌کنیم و برای هرکدام راهکار عملی ارائه می‌دهیم.

داده خرابی باکیفیت چه ویژگی‌هایی دارد؟

پیش از بررسی اشتباهات، باید بدانیم یک گزارش خرابی مناسب چه ویژگی‌هایی دارد. داده باکیفیت باید:

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

برای مثال، عبارت «پمپ خراب شد و تعمیر شد» ارزش تحلیلی بسیار کمی دارد.

اما گزارش زیر اطلاعات بیشتری در اختیار مدیر قرار می‌دهد:

تجهیز: پمپ سانتریفیوژ P-102
زمان شروع توقف: ۱۰:۲۰
زمان پایان توقف: ۱۲:۰۰
حالت خرابی: نشتی از سیل مکانیکی
علت خرابی: فرسایش سطح شفت
اقدام اصلاحی: تعویض سیل مکانیکی و اصلاح سطح شفت
قطعه مصرفی: Mechanical Seal، کد فنی MS-102
اثر بر تولید: توقف خط به مدت ۱۰۰ دقیقه
اولویت: بالا

تفاوت این دو گزارش، تفاوت میان «ثبت یک رویداد» و «ساخت دانش سازمانی» است.

۱. استفاده از کدهای خرابی مبهم و سلیقه‌ای

یکی از مهم‌ترین دلایل افت کیفیت داده، استفاده از کدها و توضیحات مبهم است. کاربران گاهی برای علت خرابی عباراتی مانند این موارد را ثبت می‌کنند:

• خراب شد
• نیاز به تعمیر
• مشکل دستگاه
• ایراد مکانیکی
• مشکل برقی
• توقف ناگهانی
• سایر موارد
• تعمیر انجام شد

این عبارت‌ها شاید برای بستن سریع یک دستورکار کافی باشند، اما برای تحلیل خرابی اطلاعات مفیدی ارائه نمی‌کنند.

برای مثال، اگر در یک ماه ۵۰ دستورکار با عنوان «مشکل برقی» ثبت شود، مدیر نت نمی‌تواند تشخیص دهد مشکل اصلی از موتور، کابل، تابلو برق، سنسور، PLC، اتصالات یا نوسان ولتاژ بوده است.

پیامدهای کدگذاری نامناسب:

• تحلیل پارتو خرابی‌ها دقت کافی ندارد.
• حالت‌های پرتکرار خرابی مشخص نمی‌شوند.
• پروژه‌های بهبود قابلیت اطمینان بر پایه حدس تعریف می‌شوند.
• تجهیزات مسئله‌دار به‌درستی شناسایی نمی‌شوند.
• مقایسه داده‌ها میان شیفت‌ها دشوار می‌شود.
• تحلیل‌های RCM، FMEA و RCA ارزش خود را از دست می‌دهند.

راهکار: طراحی ساختار استاندارد کدهای خرابی

کدهای خرابی باید متناسب با نوع تجهیز و بر اساس یک ساختار مشخص تعریف شوند. استاندارد ISO 14224 نیز می‌تواند برای طراحی این ساختار، به‌ویژه در صنایع نفت، گاز، پتروشیمی و فرایندی، مرجع مناسبی باشد.

یک ساختار مناسب می‌تواند شامل این موارد باشد:

1. کلاس تجهیز: پمپ، کمپرسور، فن، گیربکس، الکتروموتور، ولو و نوار نقاله
2. جزء یا زیرسیستم: یاتاقان، سیل، کوپلینگ، شفت، پروانه، موتور و تابلو برق
3. حالت خرابی: نشتی، شکستگی، لرزش، داغ‌شدن، گیرکردن، کاهش فشار و اتصال کوتاه
4. علت خرابی: فرسایش، روان‌کاری نامناسب، نصب نادرست، آلودگی و بارگذاری بیش از حد
5. اقدام اصلاحی: تعویض، تعمیر، تنظیم، روان‌کاری، بالانس و هم‌راستاسازی

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

۲. ثبت توقف‌های فرآیندی به‌عنوان خرابی فنی

هر توقف تجهیز لزوماً خرابی فنی نیست. این موضوع یکی از خطاهای مهم در تحلیل اطلاعات نگهداری و تعمیرات است.

برای مثال، یک پمپ ممکن است متوقف شود، اما علت توقف می‌تواند یکی از موارد زیر باشد:

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

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

این خطا می‌تواند تصمیم‌هایی مانند تعویض غیرضروری تجهیز، افزایش بی‌دلیل فعالیت‌های PM یا تخصیص نادرست بودجه نت را به دنبال داشته باشد.

راهکار: طبقه‌بندی علت توقف

در CMMS باید میان انواع توقف تفاوت مشخصی وجود داشته باشد:

این تفکیک علاوه بر افزایش دقت شاخص‌های تعمیراتی، برای تحلیل OEE و OAE نیز اهمیت دارد.

۳. ثبت دیرهنگام اطلاعات و تکیه بر حافظه

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

اما حافظه انسان ابزار مناسبی برای ثبت جزئیات فنی نیست. با گذشت زمان، اطلاعاتی مانند موارد زیر فراموش می‌شوند:

• زمان دقیق شروع و پایان خرابی
• علائم اولیه خرابی
• شرایط بهره‌برداری هنگام حادثه
• قطعات تعویض‌شده
• تعداد و نوع نیروهای درگیر
• علت واقعی توقف
• تنظیمات انجام‌شده
• اقدامات موقت و دائمی

در نتیجه، گزارش‌ها به عباراتی مانند «تعمیر شد» یا «مشکل رفع شد» محدود می‌شوند.

راهکار: ثبت اطلاعات در محل انجام کار

بهترین زمان ثبت اطلاعات، نزدیک به زمان وقوع رویداد است. استفاده از قابلیت‌های موبایلی CMMS می‌تواند این فرایند را ساده‌تر کند.

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

1. تکنسین با اسکن QR Code یا بارکد، شناسنامه تجهیز را باز کند.
2. درخواست کار یا دستورکار مربوط را مشاهده کند.
3. زمان شروع فعالیت به‌صورت خودکار ثبت شود.
4. حالت خرابی، علت اولیه و اقدام انجام‌شده را انتخاب کند.
5. قطعات مصرفی و ساعت کار نیروها را ثبت کند.
6. در صورت نیاز، عکس یا فایل مرتبط را پیوست کند.
7. زمان پایان کار و وضعیت نهایی تجهیز را ثبت کند.

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

۴. جدا بودن دستورکار از اطلاعات قطعات یدکی

در برخی سازمان‌ها، کارکنان فعالیت تعمیراتی را در CMMS ثبت می‌کنند، اما خروج قطعات را با فرم کاغذی، فایل اکسل یا نرم‌افزار دیگری انجام می‌دهند.

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

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

در این شرایط، سازمان نمی‌تواند به‌درستی به این پرسش‌ها پاسخ دهد:

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

راهکار: اتصال قطعات، نیروی کار و هزینه به دستورکار

هر دستورکار تعمیراتی باید امکان ثبت این موارد را داشته باشد:

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

این ارتباط، پایه تحلیل هزینه چرخه عمر دارایی (LCC) را فراهم می‌کند.

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

۵. تعریف مبهم شدت خرابی و اولویت تعمیرات

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

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

تفاوت بحرانی بودن تجهیز و شدت خرابی

دو مفهوم مهم را باید از یکدیگر جدا کرد:

• بحرانی بودن تجهیز (Asset Criticality): میزان اهمیت تجهیز برای ایمنی، تولید، محیط زیست، کیفیت و هزینه
• شدت خرابی (Failure Severity): میزان اثر یک رویداد مشخص در زمان وقوع

برای مثال، یک پمپ خوراک اصلی ممکن است اهمیت بسیار بالایی داشته باشد. اما ایراد جزئی در پوشش رنگ بدنه آن لزوماً یک خرابی اضطراری نیست.

در مقابل، نشتی شدید همان پمپ می‌تواند خطر ایمنی و توقف تولید ایجاد کند. بنابراین چنین رویدادی اولویت بالاتری دارد.

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

سازمان می‌تواند اولویت تعمیرات را بر اساس چند معیار مشخص کند:

• اثر بر ایمنی و سلامت کارکنان
• اثر بر محیط زیست
• اثر بر تولید و کیفیت محصول
• اثر مالی و هزینه توقف

سپس برای هر معیار امتیاز مشخصی تعیین کند.

این روش کمک می‌کند منابع محدود تعمیراتی به خرابی‌هایی اختصاص پیدا کنند که بیشترین ریسک و اثر را بر کسب‌وکار دارند.

چگونه فرهنگ ثبت داده باکیفیت را ایجاد کنیم؟

اصلاح فرم‌ها و نرم‌افزار به‌تنهایی کافی نیست. کیفیت داده به فرهنگ سازمانی نیز وابسته است.

اگر تکنسین‌ها ثبت اطلاعات را یک کار اداری اضافی بدانند، حتی بهترین CMMS نیز داده‌های ناقص دریافت می‌کند.

آموزش با تمرکز بر کاربرد واقعی

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

ساده‌سازی فرم‌های ثبت اطلاعات

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

تعیین مسئولیت داده

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

• اپراتور: اعلام به‌موقع علائم و درخواست کار
• تکنسین: ثبت حالت خرابی، اقدام و قطعات مصرفی
• سرپرست: بررسی گزارش و تأیید بستن دستورکار
• برنامه‌ریز نت: تحلیل روندها و اصلاح برنامه‌های PM
• مدیر نت: پایش کیفیت داده و شاخص‌های قابلیت اطمینان

ارائه بازخورد به کاربران

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

پایش شاخص‌های کیفیت داده

خود کیفیت داده نیز باید اندازه‌گیری شود. شاخص‌هایی مانند درصد دستورکارهای بسته‌شده در همان شیفت، درصد استفاده از کد «سایر»، درصد ثبت قطعات مصرفی و درصد گزارش‌های تأییدشده توسط سرپرست می‌توانند در این زمینه مفید باشند.

نقش سایپم در استانداردسازی داده‌های خرابی

نرم‌افزار مدیریت نگهداری و دارایی‌های فیزیکی سایپم (SayPAM) فقط ابزار ثبت دستورکار نیست. رویکرد سایپم بر این اصل استوار است که کیفیت تصمیم مدیریتی از کیفیت داده‌های عملیاتی شروع می‌شود.

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

• طراحی و استانداردسازی شناسنامه و درختواره تجهیزات
• تدوین کدهای خرابی، حالت خرابی و علل ریشه‌ای
• هم‌راستاسازی ساختار داده با استانداردهایی مانند ISO 14224
• طراحی فرم‌های ثبت داده برای تکنسین، اپراتور و سرپرست
• اتصال دستورکارها به قطعات یدکی، نیروی کار و هزینه‌ها
• تعریف ماتریس بحرانی بودن تجهیزات و اولویت‌بندی کارها
• راه‌اندازی داشبوردهای MTBF، MTTR، توقفات و هزینه تعمیرات
• آموزش کاربران و ایجاد فرهنگ ثبت داده دقیق

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

جمع‌بندی

ثبت داده خرابی در CMMS یک فعالیت اداری ساده نیست. این داده‌ها پایه مدیریت قابلیت اطمینان، کنترل هزینه، کاهش توقفات و افزایش عمر مفید دارایی‌ها هستند.

پنج اشتباه اصلی که ارزش داده‌های خرابی را کاهش می‌دهند عبارت‌اند از:

1. استفاده از کدهای خرابی مبهم و بدون ساختار
2. ثبت رویدادهای فرآیندی به‌عنوان خرابی فنی
3. ثبت دیرهنگام اطلاعات و تکیه بر حافظه
4. جدا بودن اطلاعات دستورکار از قطعات یدکی مصرفی
5. تعریف مبهم شدت خرابی و اولویت تعمیرات

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