بخش زیادی از کارهای تیم IT تکراریاند: بازبینی ماهانه UPS، تست Backup، پاکسازی Log، سرویس دورهای چاپگر، کنترل ظرفیت Storage یا بررسی سلامت تجهیزات شعب. اگر این فعالیتها فقط در تقویم شخصی ادمین یا یک فایل Excel نگهداری شوند، احتمال فراموشی، اجرای دیرهنگام و نبود شواهد زیاد است. ServiceDesk Plus برای این سناریو Maintenance را به درخواستهای زمانبندیشده تبدیل میکند تا کار دورهای مثل یک رکورد قابل پیگیری، دارای مسئول و قابل گزارش مدیریت شود.
در نسخههای جدید ServiceDesk Plus، Preventive Maintenance به ماژول Maintenance تبدیل شده است. در این ماژول میتوان Maintenance ساخت، الگوی مرتبط را انتخاب کرد، بازه زمانی و تکرار را تعیین کرد و اجازه داد درخواستها در زمان برنامهریزیشده بهصورت خودکار ایجاد شوند. این راهنما بر اساس مستند رسمی ManageEngine، مسیر عملی ساخت و Verify یک Maintenance را توضیح میدهد.
سناریوی واقعی
فرض کنید تیم زیرساخت موظف است هر ماه سلامت UPS اتاق سرور را بررسی کند. کار باید در روز سوم هر ماه انجام شود، یک درخواست برای گروه Infrastructure ساخته شود، Technician بتواند نتیجه تست را ثبت کند و مدیر IT بتواند بفهمد کدام دورهها انجام شده یا عقب افتادهاند.
اگر این کار با Reminder ساده مدیریت شود، تاریخچه و Ownership ضعیف است. اگر با Maintenance مدیریت شود، هر اجرا به یک Request تبدیل میشود و میتوان آن را در جریان عادی Service Desk پیگیری کرد.
پیشنیازها
| مورد | نیاز | دلیل |
|---|---|---|
| دسترسی مناسب | Admin یا مجوز لازم برای Maintenance | ساخت Schedule و Template نیازمند دسترسی مدیریتی است. |
| Template مناسب | Incident/Request Template مرتبط | فیلدهای درخواست، گروه و اولویت از Template قابل کنترلاند. |
| گروه/Technician | از قبل تعریفشده | درخواست تولیدشده باید Owner عملیاتی داشته باشد. |
| زمانبندی روشن | Daily/Weekly/Monthly/Yearly یا One-time | Frequency باید با چرخه واقعی Maintenance منطبق باشد. |
مرحله ۱: وارد ماژول Maintenance شوید
در نسخههای جدید به تب Maintenance بروید و روی New Maintenance کلیک کنید. ManageEngine در مستند فعلی توضیح میدهد که Maintenance Module محل ساخت، مشاهده و مدیریت درخواستهای نگهداری و Scheduleهای آنهاست.
در نسخههای قدیمیتر همین مفهوم با مسیر Admin > Helpdesk > Preventive Maintenance Tasks ارائه میشد. اگر UI شما با مستند جدید متفاوت است، ابتدا Build را بررسی کنید و از نام ماژول متناظر همان نسخه استفاده کنید.
مرحله ۲: Template مناسب را انتخاب کنید
در فرم New Maintenance یک Template مرتبط انتخاب کنید. هدف Template این است که هر بار درخواست با فیلدهای ثابت و قابل پیشبینی ساخته شود. برای سناریوی UPS بهتر است Template مشخصی داشته باشید که Category، Group، Priority و Subject استاندارد را از قبل تعیین کند.
در نسخههای قدیمیتر فرم PM Task شامل Request Details، Owner Details، Requester Details و Category Details بود. مفهوم همان است: قبل از Schedule باید تعیین کنید Request تولیدشده با چه مشخصاتی وارد Service Desk شود.
چه فیلدهایی را استاندارد کنیم؟
- Subject: «بازبینی ماهانه UPS اتاق سرور»
- Category/Subcategory: زیرساخت / برق اضطراری
- Priority: متناسب با اهمیت واقعی کار
- Group: Infrastructure
- Technician: در صورت مالک ثابت
- Description: مراحل کنترل و شواهد موردنیاز
مرحله ۳: Description را به Runbook کوتاه تبدیل کنید
Maintenance اگر فقط یک Subject داشته باشد، Technician هر بار باید از حافظه بداند چه کاری انجام دهد. Description را به Checklist اجرایی تبدیل کنید؛ مثلاً بررسی Alarm، وضعیت Battery، Load، زمان آخرین Self-test و ثبت نتیجه.
از افزودن مراحل ساختگی یا بسیار جزئی که در فرآیند داخلی شما تأیید نشدهاند پرهیز کنید. Maintenance باید همان SOP مصوب را تکرارپذیر کند، نه اینکه خودش جای SOP را بگیرد.
مرحله ۴: وارد Scheduling شوید
بعد از تکمیل Template روی Next بروید تا بخش Scheduling باز شود. در مستند جدید باید Date Range و Time را مشخص کنید، سپس Repeat Frequency را انتخاب کنید. با Advanced Options میتوان Schedule را دقیقتر تنظیم کرد.
Frequencyهای مستند فعلی شامل Daily، Weekly، Monthly و Yearly هستند. در نسخههای قدیمی Periodic و One Time نیز در فرم Preventive Maintenance بهصورت مستقیم وجود داشتند. UI دقیق به Build وابسته است، بنابراین از گزینهای استفاده کنید که در کنسول همان نسخه نمایش داده میشود.
مرحله ۵: Monthly Schedule سناریوی ما را بسازید
برای بازبینی ماهانه UPS:
- Frequency را روی Monthly قرار دهید.
- روز مناسب ماه را انتخاب کنید.
- Time را روی ساعت کاری موردنظر بگذارید.
- در صورت نیاز بازه شروع و پایان Schedule را مشخص کنید.
- اگر Maintenance باید بدون تاریخ پایان ادامه یابد، گزینه مربوط به ادامه تکرار را مطابق UI فعال کنید.
- Save را بزنید.
پس از Save، Schedule باید در فهرست Maintenanceها قابل مشاهده باشد.
مرحله ۶: قبل از اتکا به Schedule، یک اجرا را Verify کنید
ManageEngine در Maintenance List امکان تولید فوری Request را نیز ارائه میکند. برای Verify اولیه، اگر نسخه شما این گزینه را دارد، Request را یکبار بهصورت Instant Generate ایجاد کنید. سپس در Request List بررسی کنید که رکورد با Template، Group، Technician، Subject و Priority درست ساخته شده باشد.
این تست بسیار مهم است؛ چون اشتباه در Template اگر تا ماه بعد کشف شود، چرخه Maintenance عملاً یک ماه با داده غلط ادامه پیدا میکند.
مرحله ۷: Calendar View را بررسی کنید
در مستند جدید، Maintenance List یک Calendar View دارد که Scheduleهای روز، هفته یا ماه را نمایش میدهد. از این نما برای کنترل تراکم فعالیتهای دورهای استفاده کنید. اگر در یک روز تعداد زیادی Maintenance روی یک گروه افتاده باشد، قبل از رسیدن موعد Scheduleها را توزیع کنید.
چه زمانی Daily، Weekly، Monthly یا Yearly؟
| Frequency | نمونه مناسب | ریسک طراحی |
|---|---|---|
| Daily | بازبینی روزانه Job حیاتی | اگر خودکارسازی ممکن باشد، Request روزانه میتواند Noise بسازد. |
| Weekly | کنترل ظرفیت یا سلامت سرویس | روز تعطیل یا Shift را در نظر بگیرید. |
| Monthly | UPS، Patch Review، Inventory Check | انتخاب روز ثابت نزدیک تعطیلات میتواند Delay بسازد. |
| Yearly | بازبینی قرارداد، آزمون جامع یا سرویس سالانه | مالکیت ممکن است طی سال تغییر کند. |
| One-time | Maintenance برنامهریزیشده غیرتکراری | با Change Management اشتباه نشود. |
Maintenance را با Change اشتباه نگیرید
هر فعالیت دورهای الزاماً Change نیست. بازبینی سلامت یا بازرسی معمول میتواند Maintenance Request باشد، اما اگر فعالیت قرار است Configuration سرویس Production را تغییر دهد، بسته به سیاست سازمان ممکن است Change Record و Approval لازم باشد. Maintenance میتواند کار را یادآوری و ایجاد کند، ولی نباید Governance تغییر را دور بزند.
برای تفکیک نوع تغییر و Change Authority، مقاله Standard، Normal یا Emergency Change؛ چه زمانی CAB لازم است؟ را ببینید.
Troubleshooting رایج
| مشکل | بررسی | راهکار |
|---|---|---|
| Request در زمان مقرر ساخته نمیشود | Schedule، بازه تاریخ و وضعیت Maintenance | فعالبودن Schedule و Date Range را کنترل کنید. |
| درخواست به گروه اشتباه میرود | Template و Owner Details | Group/Technician را در Template اصلاح کنید. |
| Maintenance زیاد و تکراری شده | Frequency و Scheduleهای همپوشان | تقویم Maintenance را بازبینی و موارد Duplicate را ادغام کنید. |
| Technician کار را انجام میدهد ولی شواهد ثبت نمیشود | Description و Closure Practice | Checklist و فیلدهای نتیجه را در Template استاندارد کنید. |
| Maintenance دیگر لازم نیست ولی Request تولید میشود | Status/Suspend | Schedule را Suspend یا مطابق نسخه غیرفعال کنید. |
کنترل کیفیت Maintenance
ماهانه سه شاخص را بررسی کنید: درصد Maintenanceهای انجامشده در موعد، تعداد Requestهای overdue و تعداد Scheduleهایی که دیگر Owner معتبر ندارند. اگر فقط Schedule بسازید ولی Outcome را نسنجید، ماژول به کارخانه تولید Ticket تبدیل میشود.
در سازمانهایی که Maintenance، SLA و Change همزمان در ServiceDesk Plus اجرا میشوند، طراحی Template و Ownership اهمیت زیادی دارد. اگر ساختار فعلی نامنظم است، آموزش تخصصی مدانت میتواند تیم را روی طراحی فرایند و تنظیم خود محصول بهصورت یکپارچه جلو ببرد، نه صرفاً آموزش منوها.
چکلیست نهایی
- Maintenance برای یک فعالیت واقعی و تکرارشونده ساخته شده است.
- Template مناسب و مستقل دارد.
- Group و Technician روشناند.
- Description شامل اقدام و شواهد لازم است.
- Frequency با چرخه واقعی کار منطبق است.
- اولین Request قبل از اتکا به Schedule تست شده است.
- Calendar View برای جلوگیری از تراکم بررسی شده است.
- فعالیتهای دارای تغییر Configuration به Change Management ارجاع میشوند.
سخن پایانی
Maintenance زمانی ارزشمند است که کار تکراری را از حافظه افراد خارج کند و به تعهدی قابل پیگیری تبدیل کند. هدف، زیادکردن Ticket نیست؛ هدف این است که کار پیشگیرانه قبل از خرابی انجام شود، Owner مشخص داشته باشد و شواهد اجرای آن باقی بماند.
منابع
- ManageEngine ServiceDesk Plus — Maintenance
- ManageEngine ServiceDesk Plus Cloud — Maintenance Module Enhancements
- ManageEngine ServiceDesk Plus Admin Guide — Preventive Maintenance
