8 اشتباه پرهزینه در مدیریت نگهداری و تعمیرات که مدیران کارخانه باید بشناسند

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

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

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

نرم افزار CMMS قرار است چه مشکلی را حل کند؟

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

اما CMMS فقط یک دفترچه دیجیتال برای ثبت خرابی نیست. ارزش اصلی آن زمانی ایجاد می‌شود که مدیران بتوانند با استفاده از داده‌های ثبت‌شده به سؤال‌های عملیاتی پاسخ دهند:

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

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

اشتباه اول: انتخاب نرم‌افزار پیش از شناخت مسئله کارخانه

گاهی فرایند انتخاب با این سؤال شروع می‌شود:

کدام نرم افزار CMMS امکانات بیشتری دارد؟

در حالی که سؤال درست این است:

کارخانه دقیقاً می‌خواهد کدام مشکل را حل کند؟

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

اگر هدف پروژه روشن نباشد، مقایسه نرم‌افزارها به بررسی تعداد ماژول‌ها و ظاهر داشبورد محدود می‌شود.

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

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

نرم‌افزار باید براساس توانایی حل این مسائل ارزیابی شود، نه صرفاً براساس تعداد قابلیت‌های معرفی‌شده.

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

کمترین قیمت لزوماً به معنای کمترین هزینه نیست. قیمت خرید تنها بخشی از هزینه واقعی پروژه CMMS است.

هزینه‌های دیگری نیز باید بررسی شوند:

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

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

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

اشتباه سوم: انتخاب براساس طولانی‌ترین فهرست امکانات

یکی از رایج‌ترین دام‌ها، انتخاب نرم‌افزاری است که بیشترین تعداد ماژول و منو را دارد.

اما آیا تمام آن امکانات واقعاً در کارخانه استفاده خواهند شد؟

پیچیدگی غیرضروری می‌تواند باعث شود:

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

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

در جلسه دمو، به‌جای مشاهده تمام منوها، از ارائه‌دهنده بخواهید چند سناریوی واقعی کارخانه را اجرا کند؛ برای مثال:

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

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

اشتباه چهارم: نادیده‌گرفتن کاربران عملیاتی

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

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

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

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

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

اشتباه پنجم: انتقال بی‌برنامه اطلاعات قدیمی

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

این کار ممکن است دیتابیس را از همان ابتدا با اطلاعات ناقص، تکراری یا غیرقابل اعتماد پر کند.

پیش از انتقال داده باید مشخص شود:

• کدام اطلاعات واقعاً موردنیاز هستند؟
• کد تجهیزات یکتا و استاندارد است یا خیر؟
• نام‌گذاری دارایی‌ها در واحدهای مختلف یکسان است؟
• تجهیزات از رده خارج هنوز در فهرست وجود دارند؟
• سوابق قدیمی قابلیت استناد دارند؟
• قطعات تکراری با چند نام ثبت شده‌اند؟

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

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

اشتباه ششم: اجرای هم‌زمان CMMS در تمام کارخانه

اجرای یک‌باره در تمام خطوط، سایت‌ها و واحدها ممکن است جذاب به نظر برسد؛ اما ریسک پروژه را بالا می‌برد.

در شروع کار معمولاً این مشکلات ظاهر می‌شوند:

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

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

اجرای مرحله‌ای به معنای کوچک‌کردن هدف پروژه نیست؛ بلکه فرصتی برای جلوگیری از تکرار خطا در کل سازمان است.

اشتباه هفتم: نگاه‌کردن به CMMS به‌عنوان پروژه واحد IT

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

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

برای استقرار موفق، نقش بخش‌ها باید روشن باشد:

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

اگر پروژه فقط به IT سپرده شود، ممکن است از نظر فنی اجرا شود اما با نیاز روزانه واحد نت تطابق کافی نداشته باشد.

اشتباه هشتم: تعریف‌نکردن معیار موفقیت

ممکن است نرم‌افزار نصب شود، کاربران آموزش ببینند و اطلاعات نیز وارد شوند؛ اما پس از چند ماه هیچ‌کس نداند پروژه واقعاً موفق بوده یا نه.

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

• درصد تحقق برنامه‌های PM
• تعداد دستورکارهای باز و معوق
• متوسط زمان تعمیر یا MTTR
• متوسط فاصله میان خرابی‌ها یا MTBF
• مدت توقف تجهیزات بحرانی
• تعداد خرابی‌های تکرارشونده
• سهم تعمیرات اضطراری
• هزینه نگهداری به تفکیک تجهیز
• زمان انتظار برای قطعه
• میزان استفاده کاربران از سیستم

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

گزارش بدون اقدام، فقط شکل دیجیتال همان بایگانی قبلی است.

پیش از انتخاب CMMS این چک‌لیست را بررسی کنید

مدیران کارخانه پیش از تصمیم نهایی بهتر است پاسخ این سؤال‌ها را آماده کنند:

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

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

نرم افزار cmms پرگاv چگونه ارزیابی می‌شود؟

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

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

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

جمع‌بندی

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

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

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

برچسب ها : نرم افزار نگهداری تعمیرات,نرم افزار cmms,نرم افزار پرگارنت,نگهداری تعمیرات,استقرار نرم افزار cmms