~/icsd.ir — bash
SYSTEM_ONLINE

نرم‌افزار تعمیرات و نگهداری در کاشان: راهنمای انتخاب CMMS و معرفی سامانه حافظ

2026/08/12 // by admin

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

پاسخ کوتاه

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

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

نرم‌افزار نت (CMMS) دقیقاً چه کاری انجام می‌دهد؟

CMMS مخفف Computerized Maintenance Management System است؛ در فارسی معمولاً «نرم‌افزار نگهداری و تعمیرات» یا کوتاه‌تر «نرم‌افزار نت» گفته می‌شود. تفاوت آن با یک فایل اکسل خوب، در سه چیز است:

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

دوم، یادآوری خودکار. برنامه‌ی روان‌کاری هر ۳۰ روز یا هر ۵۰۰ ساعت کارکرد، وقتی روی کاغذ باشد فراموش می‌شود. سامانه خودش دستور کار را می‌سازد و به مسئولش اطلاع می‌دهد.

سوم، حافظه‌ی سازمانی. دانشِ اینکه فلان یاتاقان هر سه ماه می‌سوزد و علتش تنظیم نبودن هم‌محوری است، معمولاً در ذهن یک سرکارگر باتجربه است. با رفتن او، آن دانش هم می‌رود. ثبت ساخت‌یافته‌ی علت خرابی، این دانش را ماندگار می‌کند — و اسم «حافظ» هم از همین‌جا می‌آید.

PM و EM: تفاوت نگهداری پیشگیرانه و اضطراری

دو اصطلاحی که در هر بحث نت تکرار می‌شوند و گاهی جابه‌جا به کار می‌روند:

نوع عنوان کامل محرک نمونه
PM Preventive Maintenance — نگهداری پیشگیرانه گذشت زمان یا رسیدن کارکرد به عدد مشخص تعویض فیلتر هر ۹۰ روز؛ گریس‌کاری هر ۱۰۰۰ ساعت
EM Emergency Maintenance — تعمیرات اضطراری توقف ناگهانی خط یا تجهیز سوختن موتور وسط شیفت شب
CM Corrective Maintenance — تعمیرات اصلاحی عیبِ شناسایی‌شده که فوری نیست لرزش غیرعادی که در بازرسی ثبت شده
PdM Predictive Maintenance — نگهداری پیش‌بینانه داده‌ی پایش وضعیت (ارتعاش، دما، آنالیز روغن) هشدار افزایش ارتعاش یاتاقان

نسبت این‌ها به هم، معیار سنجش بلوغ واحد فنی است. جایی که بیش از نیمی از دستور کارها EM باشند، واحد نت در حالت «آتش‌نشانی» کار می‌کند: پرهزینه، غیرقابل برنامه‌ریزی و فرساینده برای تیم. هدف عملی، بردن سهم PM به بالای شصت درصد است، نه صفر کردن EM — که شدنی نیست.

نکته‌ای که در پیاده‌سازی زیاد دیده می‌شود: بدون ثبت دقیق EM، هیچ‌وقت نمی‌فهمید برنامه‌ی PM‌تان جواب داده یا نه. سنجه‌ی موفقیت PM، کم شدن EM است؛ پس هر دو باید در یک سامانه ثبت شوند.

چرا صنایع کاشان به نرم‌افزار نت نیاز دارند

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

نساجی و فرش ماشینی. به گزارش خبرگزاری فارس (۱۴۰۰)، حدود ۷۰ درصد فرش ماشینی کشور در کاشان تولید می‌شود. ماشین‌آلات بافندگی و ریسندگی، تعداد بالای قطعات مصرفی و برنامه‌ی سرویس فشرده دارند؛ توقف یک ماشین ژاکارد یعنی خواب سرمایه‌ی سنگین و به‌هم‌ریختن زنجیره‌ی رنگرزی و تکمیل.

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

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

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

هفت معیار انتخاب نرم‌افزار تعمیرات و نگهداری

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

۱. تقویم شمسی واقعی، نه تاریخ میلادیِ ترجمه‌شده

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

۲. سرعت ورود داده در کف کارگاه

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

۳. امکان استقرار روی سرور داخلی

برای کارخانه‌ای که به دلایل امنیتی یا اینترنت ناپایدار نمی‌خواهد به سرویس ابری وابسته باشد، نصب on-premise شرط اول است — همراه با این ویژگی که رابط کاربری بدون دسترسی به اینترنت هم کامل بارگذاری شود.

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

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

۵. گردش‌کار تایید قابل تنظیم

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

۶. API برای اتصال به سایر سامانه‌ها

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

۷. پشتیبانی در دسترس

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

حافظ؛ سامانه‌ی جامع نگهداری و تعمیرات

حافظ را در توسعه هوشمند فرش ایرانیان با همین هفت معیار به‌عنوان نقطه‌ی شروع طراحی کردیم. سامانه روی Django ۵.۲ و PostgreSQL ساخته شده، رابط کاربری‌اش Bootstrap ۵ راست‌به‌چپ با فونت وزیرمتن است، و تمام فایل‌های ظاهری آن — فونت، اسکریپت، دیت‌پیکر — روی خود سرور سرو می‌شوند؛ هیچ CDN خارجی در کار نیست، پس رابط کاربری در یک شبکه‌ی کاملاً بسته هم بدون نقص بالا می‌آید.

ماژول‌های حافظ

ماژول چه چیزی را مدیریت می‌کند
تجهیزات و موقعیت‌ها ساختار درختی سایت / سالن / خط / دستگاه، شناسنامه و مشخصات فنی، کنتور کارکرد، درخت قطعات (BOM)
پرسنل و چارت سازمانی واحدها و سمت‌ها به‌صورت درختی، مهارت‌ها، نقش‌ها، اتصال هر فرد به حساب کاربری
درخواست و دستور کار ثبت درخواست از کف کارگاه، تبدیل به دستور کار PM/EM/CM، چرخه‌ی حیات کنترل‌شده، پیوست، یادداشت
گردش‌کار تایید تعریف مراحل تایید بر اساس نقش و نوع دستور کار، صندوق تاییدات
چک‌لیست قالب چک‌لیست با بازه‌ی مجاز (حداقل/حداکثر) و واحد برای هر آیتم، ثبت نتیجه و قرائت عدد
نگهداری پیشگیرانه برنامه‌ی PM با تریگر زمانی (روز/هفته/ماه) یا کارکردی (کنتور)، تولید خودکار دستور کار با فاصله‌ی زمانی قابل تنظیم، تقویم PM
انبار و تدارکات کالا و قطعه، تراکنش ورود/خروج/شمارش، حداقل و حداکثر موجودی، نقطه‌ی سفارش، درخواست خرید
ثبت کارکرد، توقف و هزینه ساعت کار هر نفر روی دستور کار، مدت و نوع توقف، قطعات مصرفی و هزینه‌ی ریالی
اعلان‌ها قواعد اعلان به‌ازای هر رویداد، با انتخاب کانال درون‌برنامه‌ای، ایمیل یا پیامک
مستندات کیفیت دستورالعمل و رویه با نسخه‌بندی، مشخص بودن نسخه‌ی جاری، اتصال سند به تجهیز
گزارش و شاخص داشبورد KPI، روند شش‌ماهه بر پایه‌ی ماه‌های شمسی، فهرست پرخرابی‌ترین تجهیزات
API ‏‎/api/v1/‎ بر پایه‌ی DRF با احراز هویت JWT و مستندات OpenAPI

الگوی «تایپ کن، اگر نبود همان‌جا بساز»

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

این جزئیات کوچک به نظر می‌رسد. در عمل، همین است که تعیین می‌کند تکنسین شب‌کار دستور کار را ثبت می‌کند یا روی کاغذ می‌نویسد و فردا فراموش می‌شود.

شاخص‌هایی که حافظ محاسبه می‌کند

داشبورد مدیریتی حافظ این شاخص‌ها را از داده‌ی ثبت‌شده استخراج می‌کند:

  • MTBF (میانگین زمان بین خرابی‌ها) — بازه‌ی گزارش تقسیم بر تعداد خرابی‌های ثبت‌شده. هرچه بزرگ‌تر، تجهیز پایدارتر.
  • MTTR (میانگین زمان تعمیر) — میانگین فاصله‌ی شروع تا پایان کار روی دستور کارهای خرابی. این شاخص، سرعت واکنش تیم فنی و در دسترس بودن قطعه را با هم نشان می‌دهد.
  • دسترس‌پذیری — نسبت زمان در دسترس به کل زمان تقویمی، بر اساس توقف‌های ثبت‌شده.
  • تطابق PM — چند درصد از دستور کارهای پیشگیرانه در موعد خود انجام شده‌اند. پایین بودن مداوم این عدد یعنی برنامه‌ی PM با ظرفیت واقعی تیم هم‌خوان نیست.
  • بک‌لاگ — تعداد دستور کارهای باز در لحظه.
  • هزینه — تفکیک هزینه‌ی قطعه، نیروی انسانی و سایر موارد، در سطح تجهیز و در سطح کل.
  • روند شش‌ماهه و پرخرابی‌ترین تجهیزات — برای اینکه بحث در جلسه‌ی ماهانه سر عدد باشد نه سر خاطره.

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

مسیر پیاده‌سازی در یک کارخانه

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

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

سه اشتباه رایج

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

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

تعریف بازه‌های PM از روی کاتالوگ. بازه‌های سازنده برای شرایط استاندارد نوشته شده‌اند. در محیط پرگردوغبار کاشان، بازه‌ی تمیزکاری فیلتر معمولاً باید کوتاه‌تر باشد. بعد از شش ماه، بازه‌ها را بر اساس داده‌ی خودتان تنظیم کنید.

چرا یک تیم کاشانی؟

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

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

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

سوالات متداول

تفاوت CMMS و EAM چیست؟

CMMS بر عملیات نگهداری و تعمیرات تمرکز دارد: دستور کار، برنامه‌ی سرویس، انبار قطعات. EAM دامنه‌ی گسترده‌تری دارد و کل چرخه‌ی عمر دارایی — از خرید و استهلاک تا کنارگذاری — را پوشش می‌دهد. حافظ هسته‌ی CMMS را کامل پیاده کرده و در لایه‌ی دارایی و هزینه به سمت EAM حرکت می‌کند.

آیا حافظ روی سرور داخلی کارخانه نصب می‌شود؟

بله. استقرار روی سرور داخلی (on-premise) حالت پیش‌فرض است و از طریق Docker یا نصب مستقیم روی لینوکس انجام می‌شود. تمام فایل‌های ظاهری سامانه محلی سرو می‌شوند، بنابراین در شبکه‌ی بدون اینترنت هم کامل کار می‌کند. استقرار روی سرور ابری هم در صورت درخواست امکان‌پذیر است.

پیاده‌سازی چقدر طول می‌کشد؟

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

آیا می‌توان داده‌های اکسل موجود را وارد کرد؟

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

آیا اپلیکیشن موبایل دارد؟

معماری سامانه از ابتدا API-first است و تمام قابلیت‌ها پشت endpointهای استاندارد /api/v1/ با احراز هویت JWT قرار دارند؛ همین API پایه‌ی اپ موبایل و PWA در نقشه‌ی راه محصول است. در حال حاضر رابط وب روی موبایل و تبلت به‌صورت واکنش‌گرا کار می‌کند.

جمع‌بندی

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

مشاوره و دموی حافظ

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

ارسال نظر

نمایش سایت

رنگ سایت
حالت نمایش
اندازهٔ متن
خوانایی

این تنظیمات فقط روی مرورگر شما ذخیره می‌شود.