SLA و مدیریت خدمات در پشتیبانی شبکه؛ مدل عملی مبتنی بر ITIL
SLA، Incident، Request، Problem، Change و Knowledge؛ برای اینکه پشتیبانی قابل پیشبینی، قابل گزارش و قابل بهبود باشد.
SLA زمانی مفید است که دو طرف دقیقاً بدانند «چه چیزی»، «در چه سطحی» و «با چه دادهای» سنجیده میشود. عددی مثل «پاسخ در ۱۵ دقیقه» بدون تعریف Priority، ساعت خدمت، Scope و کانال ثبت درخواست، بیشتر منبع اختلاف است تا ابزار مدیریت.
اول نوع کار را درست تشخیص بدهید
Incident
اختلال یا کاهش کیفیت سرویس؛ هدف اولیه Restore است.
Service Request
درخواست استاندارد مثل نصب نرمافزار، دسترسی یا تغییر معمول.
Problem
علت یا علت احتمالی Incidentهای تکراری؛ تمرکز روی Root Cause.
Change
تغییر کنترلشده با Risk، زمانبندی، Approval و Rollback در موارد حساس.
Knowledge
راهحل، Runbook و Known Error برای جلوگیری از شروع دوباره از صفر.
Major Incident
رخداد با اثر بالا که نیاز به هماهنگی، ارتباطات و Escalation ویژه دارد.
Priority را با Impact و Urgency بسازید
| نمونه | Impact | Urgency | رویکرد |
|---|---|---|---|
| قطع سرویس مالی کل سازمان | بالا | بالا | Major / P1 |
| اختلال یک واحد کاری | متوسط | بالا | P2 یا P3 بسته به سرویس |
| مشکل یک کاربر با Workaround | پایین | متوسط | صف استاندارد |
| درخواست نصب نرمافزار | درخواست | قابل برنامهریزی | Service Request |
عدد دقیق SLA باید در قرارداد براساس Criticality، ساعت خدمت و ظرفیت واقعی توافق شود؛ یک جدول واحد برای همه سازمانها منطقی نیست.
چه چیزی باید گزارش شود؟
ServiceDesk Plus چه کمکی میکند؟
ServiceDesk Plus برای Ticket، SLA، Priority، Automation، Knowledge و Report یک بستر ساختاریافته فراهم میکند. مزیت مدانت این است که این ابزار را صرفاً بهعنوان محصول نمیشناسد؛ منطق ITSM آن را در طراحی عملیات پشتیبانی نیز بهکار میگیرد.
Service Review؛ جلسهای که باید تصمیم بسازد
گزارش ماهانه نباید فقط PDF تعداد Ticket باشد. باید مشخص کند چه اتفاق مهمی افتاد، کدام سرویس ریسک دارد، کدام Problem هنوز باز است، چه Capacity به حد نزدیک شده و اقدام ماه بعد چیست.
ITIL برای پشتیبانی یعنی نظم قابل استفاده
هدف افزودن بروکراسی نیست؛ هدف این است که تیم بداند چه چیزی Incident است، چه چیزی باید Escalate شود و کجا تکرار مشکل نیاز به ریشهیابی دارد.
