چهار واژه‌ای که در Service Desk زیاد شنیده می‌شوند اگر اشتباه استفاده شوند، کل گزارش و مسئولیت تیم را مخدوش می‌کنند: Incident، Request، Problem و Change.
این مفاهیم برای پیچیده‌کردن کار ساخته نشده‌اند؛ هرکدام سؤال متفاوتی را پاسخ می‌دهند. Incident می‌پرسد چطور خدمت را سریع برگردانیم، Problem می‌پرسد چرا این اتفاق تکرار می‌شود و Change می‌پرسد چطور راه‌حل را کنترل‌شده وارد محیط کنیم.
Service Request هم معمولاً نیاز استاندارد کاربر است، نه خرابی.
سناریو: اینترنت شعبه هر دوشنبه قطع می‌شود
دوشنبه ساعت ۹ اینترنت شعبه قطع می‌شود. کاربر تیکت ثبت می‌کند و تیم شبکه با Restart یک تجهیز سرویس را برمی‌گرداند. این Incident است؛ تمرکز اول روی بازیابی خدمت بوده است.
سه هفته پیاپی همان اتفاق تکرار می‌شود. حالا یک Problem برای پیدا کردن علت ایجاد می‌شود. بررسی نشان می‌دهد Firmware تجهیز با یک شرایط خاص مشکل دارد. برای ارتقا Firmware یک Change برنامه‌ریزی می‌شود. در همین روز کاربری هم درخواست دسترسی VPN می‌دهد؛ آن مورد Service Request است.
مسئله را درست تعریف کنیم
این چهار رکورد می‌توانند به هم مرتبط باشند اما جای هم را نمی‌گیرند. بستن Incident به معنی حل Root Cause نیست و بازکردن Change به معنی Incident بودن کار نیست.
ارتباط درست میان آن‌ها گزارش را هم واقعی‌تر می‌کند: چند Incident از یک Problem آمده و کدام Change آن را کاهش داده است؟
| مفهوم | هدف اصلی | نمونه |
|---|---|---|
| Incident | بازیابی سریع خدمت | قطعی اینترنت شعبه |
| Service Request | ارائه درخواست استاندارد | درخواست VPN |
| Problem | کشف علت و کنترل تکرار | خرابی تکراری Firmware |
| Change | اعمال تغییر کنترل‌شده | ارتقای Firmware |
| Known Error | ثبت علت شناخته‌شده و Workaround | راه‌حل موقت تا Change |
مسیر اجرایی پیشنهادی
1. در لحظه خرابی روی بازیابی تمرکز کنید
Incident Management نباید منتظر Root Cause کامل بماند. اگر Workaround امن وجود دارد، اول خدمت را برگردانید و بعد تحلیل عمیق را ادامه دهید.
2. تکرار را به Problem تبدیل کنید
هر Incident الزاماً Problem نمی‌خواهد. الگوهای تکراری، اثر بالا یا علت نامعلوم ارزش Problem Record دارند.
3. Workaround را قابل‌استفاده کنید
راه‌حل موقت باید ثبت شود تا دفعه بعد تیم از صفر شروع نکند. این کار زمان بازیابی Incidentهای بعدی را کاهش می‌دهد.
4. راه‌حل پایدار را با Change اجرا کنید
اگر رفع ریشه‌ای نیاز به تغییر محیط دارد، ریسک، زمان، تست و Rollback باید در Change مدیریت شوند.
5. رابطه رکوردها را حفظ کنید
Incidentها را به Problem و Change مرتبط کنید. این ارتباط نشان می‌دهد یک اقدام اصلاحی واقعاً چند رخداد را کم کرده است.
از کجا بفهمیم مسیر درست است؟
برای Incident، زمان بازیابی و تجربه کاربر مهم است. برای Problem، کاهش تکرار و رفع Root Cause. برای Change، نرخ موفقیت و اثر ناخواسته. یک KPI واحد برای هر چهار مفهوم مناسب نیست.
وقتی تیم واژه‌ها را درست به کار می‌برد، گزارش‌ها هم به جای آمار خام، رفتار واقعی سرویس را نشان می‌دهند.
خطاهای رایج
- ثبت هر درخواست کاربر به عنوان Incident.
- باز نگه‌داشتن Incident تا زمان Root Cause کامل.
- اجرای راه‌حل Problem بدون Change کنترل‌شده.
- نبود رابطه بین Incidentهای تکراری و Problem.
لینک‌های داخلی برای ادامه مطالعه
جمع‌بندی
Incident، Request، Problem و Change چهار مرحله خطی نیستند؛ چهار نوع کار با هدف متفاوت‌اند که در سناریوهای واقعی به هم متصل می‌شوند.
تفکیک درست آن‌ها هم عملیات را روشن‌تر می‌کند و هم به مدیریت نشان می‌دهد تیم کجا در حال بازیابی، کجا در حال ریشه‌یابی و کجا در حال تغییر است.
کلیدواژه‌های این راهنما: تفاوت Incident Request Problem Change، ITIL، Incident Management، Problem Management، Change Enablement
