رفتن به محتوای اصلی
ITIL Service Management

SLA و مدیریت خدمات در پشتیبانی شبکه؛ مدل عملی مبتنی بر ITIL

SLA، Incident، Request، Problem، Change و Knowledge؛ برای اینکه پشتیبانی قابل پیش‌بینی، قابل گزارش و قابل بهبود باشد.

IncidentRestore سریع
Problemرفع علت تکرار
SLAتعهد قابل سنجش

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، ساعت خدمت و ظرفیت واقعی توافق شود؛ یک جدول واحد برای همه سازمان‌ها منطقی نیست.

چه چیزی باید گزارش شود؟

درصد رعایت SLA
MTTR و MTTD
Backlog و Aging
Incidentهای تکراری
Major Incident و Postmortem
Change موفق/ناموفق
Problemهای باز
رضایت یا Feedback کاربر

ServiceDesk Plus چه کمکی می‌کند؟

ServiceDesk Plus برای Ticket، SLA، Priority، Automation، Knowledge و Report یک بستر ساختاریافته فراهم می‌کند. مزیت مدانت این است که این ابزار را صرفاً به‌عنوان محصول نمی‌شناسد؛ منطق ITSM آن را در طراحی عملیات پشتیبانی نیز به‌کار می‌گیرد.

Service Review؛ جلسه‌ای که باید تصمیم بسازد

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

ITIL برای پشتیبانی یعنی نظم قابل استفاده

هدف افزودن بروکراسی نیست؛ هدف این است که تیم بداند چه چیزی Incident است، چه چیزی باید Escalate شود و کجا تکرار مشکل نیاز به ریشه‌یابی دارد.

22
قدم بعدی

پشتیبانی را از یک قرارداد مبهم به یک سرویس قابل سنجش تبدیل کنید

فهرست خدمات بازگشت سرمایه استعلام قیمت