همه Problemها ارزش یکسانی برای حل ندارند. ممکن است یک Problem هر هفته ده‌ها Incident کوچک بسازد و مجموع زمان تیم را ببلعد؛ Problem دیگری شاید فقط یک‌بار رخ داده باشد اما در صورت تکرار بتواند سرویس حیاتی را متوقف کند. اگر Problem Management فقط بر اساس «قدیمی‌ترین رکورد» یا «بیشترین صدای کاربر» اولویت‌بندی شود، منابع فنی به جای بیشترین ارزش، صرف بیشترین فشار لحظه‌ای می‌شوند.

PeopleCert در Practice رسمی Problem Management هدف را کاهش احتمال و اثر Incidentها از طریق شناسایی علت‌های واقعی و بالقوه و مدیریت Workaroundها و Known Errorها تعریف می‌کند. برای رسیدن به این هدف، سازمان باید بتواند تشخیص دهد کدام Problem باید امروز تحلیل شود، کدام باید وارد Backlog بماند و کدام به Change فوری نیاز دارد.

سناریوی واقعی: ۳۰ Problem باز، فقط ۳ تحلیلگر

فرض کنید تیم شما ۳۰ Problem باز دارد. پنج مورد مربوط به خطاهای تکراری نرم‌افزارهای داخلی است، چهار مورد به شبکه شعب، سه مورد به سرویس‌های امنیتی و بقیه به خطاهای پراکنده کاربران مربوط‌اند. تیم فقط سه تحلیلگر دارد و امکان بررسی همزمان همه موارد وجود ندارد.

اگر اولویت را فقط بر اساس تعداد Incident تعیین کنید، ممکن است Problemی با ۵۰ Incident کم‌اثر بالاتر از Problemی با دو Incident بحرانی قرار گیرد. اگر فقط Impact را ببینید، ممکن است یک مسئله پرریسک اما بسیار کم‌احتمال تمام ظرفیت تیم را بگیرد. مدل خوب باید چند عامل را با هم ببیند.

چه عواملی باید در اولویت Problem دخیل باشند؟

Impact را فقط با تعداد کاربر نسنجید

یک Incident روی سیستم مدیرعامل ممکن است فقط یک کاربر را متاثر کند، اما اثر کسب‌وکاری آن با یک خطای کوچک روی ۲۰۰ کاربر عادی برابر نیست. بنابراین Impact باید بر اساس سرویس، نقش کاربر، تعهد قانونی، درآمد، امنیت و Reputation سنجیده شود.

برای این کار بهتر است Problem به Service و CI مرتبط باشد. اگر Criticality سرویس مشخص است، Problem Management می‌تواند از همان داده برای اولویت‌بندی استفاده کند. اینجا CMDB فقط مخزن دارایی نیست؛ ابزار تصمیم‌گیری است.

Frequency چه چیزی را نشان می‌دهد؟

تکرار زیاد یک Problem نشان می‌دهد سازمان به‌صورت مستمر هزینه می‌دهد: زمان Service Desk، نارضایتی کاربر، کاهش بهره‌وری و هزینه Escalation. حتی اگر هر Incident کوچک باشد، مجموع Cost می‌تواند قابل توجه شود.

یک راه ساده این است که تعداد Incident مرتبط با Problem در ۳۰ یا ۹۰ روز گذشته را با میانگین زمان حل ضرب کنید. این عدد «Technical Friction» را به زبان زمان قابل اندازه‌گیری تبدیل می‌کند.

Workaround می‌تواند اولویت را تغییر دهد

اگر یک Problem Workaround بسیار سریع، امن و پایدار دارد، Urgency حل دائم ممکن است پایین‌تر باشد. اما اگر Workaround نیازمند مداخله تیم ارشد، Downtime یا اقدام پرریسک است، حتی تعداد Incident کم هم می‌تواند اولویت Problem را بالا ببرد.

بنابراین «وجود Workaround» کافی نیست؛ کیفیت آن مهم است. Workaround باید مدت اجرا، Success Rate، Risk و نیاز به Privilege را هم در ارزیابی Problem وارد کند.

Cost of Delay را وارد تصمیم کنید

Problemهایی که هر هفته هزینه ثابت ایجاد می‌کنند، معمولاً قربانی Backlog می‌شوند چون هیچ Incident واحدی بحرانی نیست. Cost of Delay کمک می‌کند این هزینه تجمعی دیده شود.

این جدول نشان می‌دهد تعداد Incident به‌تنهایی کافی نیست. باید زمان، Criticality و اثر کسب‌وکار را با هم دید.

یک مدل امتیازدهی وزنی بسازید

برای اینکه تصمیم بین تیم‌ها قابل دفاع باشد، می‌توانید برای هر عامل امتیاز ۱ تا ۵ تعیین کنید و سپس وزن بدهید. مثلاً Impact و Business Criticality هرکدام ۳۰ درصد، Frequency بیست درصد، Workaround Quality ده درصد و Cost of Delay ده درصد. سازمانی که محیط Regulatory دارد ممکن است وزن Compliance را هم اضافه کند.

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

نمونه ساده

در این مثال Problem A با اینکه Frequency کمی دارد، به‌خاطر Impact و Criticality بالا جلو می‌افتد. Problem B تکرارشونده است اما اثر محدودتری دارد؛ بنابراین ممکن است برای Automation یا Knowledge Improvement مناسب‌تر از یک RCA فوری باشد.

Problem Backlog را به صف فراموش‌شده تبدیل نکنید

Problemهایی که اکنون اولویت ندارند نباید رها شوند. برای هر رکورد باید Owner، Review Date و Trigger بازبینی وجود داشته باشد. مثلاً اگر تعداد Incident از یک Threshold عبور کرد یا سرویس Criticality بالاتری گرفت، اولویت دوباره محاسبه شود.

همچنین Problemهای بدون Incident جدید برای مدت طولانی باید بازبینی شوند: شاید Issue دیگر وجود ندارد، شاید Monitoring تغییر کرده یا شاید کاربران راه دیگری پیدا کرده‌اند و Incident ثبت نمی‌کنند. Status قدیمی همیشه به معنی Risk پایین نیست.

Review Cadence تعریف کنید

یک Practice ساده این است که Backlog در سه لایه بازبینی شود: Problemهای Critical هر هفته، Problemهای High هر دو هفته و بقیه ماهانه. این Cadence باید با حجم سازمان سازگار باشد. هدف جلسه بیشتر نیست؛ هدف این است که Problem بدون Owner و بدون تصمیم برای ماه‌ها باز نماند.

در هر Review سه سؤال کافی است: آیا Priority هنوز درست است؟ آیا داده جدیدی از Incidentها آمده؟ آیا Workaround یا Permanent Fix وضعیت را تغییر داده است؟

ارتباط Problem Priority با SLA و Service Level

اگر Problem پشت چند SLA Breach قرار دارد، این داده باید در اولویت منعکس شود. تکرار Incidentهایی که هرکدام SLA را نقض می‌کنند، نشان می‌دهد Problem فقط مسئله فنی نیست و Service Level را هم تخریب می‌کند. در مقابل، Problemی که هیچ Impact قابل اندازه‌گیری روی سطح خدمت ندارد ممکن است با Priority پایین‌تر مدیریت شود.

ارتباط Problem Priority با Change Enablement

وقتی Root Cause مشخص شد، Permanent Fix معمولاً نیازمند Change است. اما Priority Problem و Priority Change همیشه یکی نیستند. ممکن است Problem بحرانی باشد ولی Change پیشنهادی ریسک زیادی داشته باشد و فقط در Window خاص اجرا شود.

بنابراین Problem Management باید Business Need و Cost of Delay را به Change منتقل کند؛ Change Enablement هم Risk اجرای Fix را ارزیابی کند. برای سنجش نتیجه بعد از اجرا، مقاله سنجش موفقیت Change بعد از اجرا مکمل این فرایند است.

چه داده‌هایی برای تصمیم بهتر لازم است؟

• تعداد Incidentهای مرتبط در بازه زمانی مشخص؛
• Service و CI متاثر؛
• Business Criticality؛
• میانگین و مجموع زمان حل Incidentها؛
• وجود و کیفیت Workaround؛
• روند تکرار؛
• Major Incident یا Security Impact مرتبط؛
• Change یا Vendor Fix در دسترس؛
• Owner و Review Date.

نکات کلیدی

• قدیمی‌ترین Problem الزاماً مهم‌ترین Problem نیست.
• Impact و Frequency باید هم‌زمان دیده شوند.
• Workaround خوب می‌تواند Urgency را کاهش دهد، نه Risk را حذف کند.
• Cost of Delay برای Problemهای پرتکرار بسیار مهم است.
• Backlog باید Owner و Review Trigger داشته باشد.
• اولویت Problem باید به Change و Continual Improvement منتقل شود.

اگر ServiceDesk Plus را برای Problem Management استفاده می‌کنید، طراحی Priority Matrix و اتصال Problem به Incident، Service و Change باید با فرایند واقعی سازمان هماهنگ باشد. در چنین پروژه‌هایی آموزش تخصصی مدانت می‌تواند تیم را از تنظیم چند فیلد ساده به سمت مدل تصمیم‌گیری قابل اندازه‌گیری ببرد.

سخن پایانی

Problem Management زمانی بالغ است که بتواند پاسخ دهد «چرا این Problem الان مهم‌تر از بقیه است؟». اگر پاسخ فقط «چون مدیر خواسته» یا «چون قدیمی‌تر است» باشد، اولویت‌بندی هنوز داده‌محور نشده است. ترکیب Impact، Frequency، Criticality، Workaround و Cost of Delay کمک می‌کند تیم محدود تحلیلگر روی Problemهایی کار کند که بیشترین کاهش Incident و بیشترین ارزش کسب‌وکاری را ایجاد می‌کنند.

منابع

• PeopleCert — ITIL 4 Practitioner: Problem Management
• ManageEngine — IT Problem Management
• ManageEngine ServiceDesk Plus — Problem Management Help