با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
چند Ticket را اولویتبندی کن
در تمرین، برای هر Ticket اثر، Urgency، تعداد کاربران و سرویس درگیر را بنویس و سپس اولویت بده؛ دلیل اولویت باید قابل توضیح باشد، نه بر اساس ترتیب ورود یا فشار کاربر در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
Category و مسئول بده
دستهبندی درست گزارشگیری و مسیریابی Ticket را بهتر میکند و مسئول مشخص مسئول پیگیری را روشن نگه میدارد. Ticket بدون مسئول نباید در صف رها شود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
Escalation کامل بنویس
ارجاع یعنی انتقال مسئله به سطح فنی یا مدیریتی مناسب وقتی دانش، دسترسی، زمان یا اثر رخداد از سطح فعلی خارج است؛ همراه ارجاع خلاصه، شواهد، تستها و تغییرهای انجامشده را بفرست ارجاع بدون اطلاعات فقط زمان تیم بعدی را هدر میدهد در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند
برای مورد تکراری Problem پیشنهاد بده
Problem علت یا علتهای احتمالی یک یا چند رخداد را بررسی میکند؛ رخداد تکراری باید از حالت رفع موقت خارج و ریشهای بررسی شود بستن رخداد به معنی بسته شدن Problem نیست در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند
Resolution Note تهیه کن
Resolution Note باید علت یا یافته، اقدام انجامشده و وضعیت نهایی را خلاصه کند تا کاربر و تیم بعدی بفهمند چرا Ticket بسته شده است در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند در کار روزمره بهتر است این موضوع را اینطور بررسی کنی: اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
فرض کن در میز خدمت و سامانه درخواستها مشکلی گزارش شده و احتمال میدهی به آزمایشگاه مدیریت Ticket مربوط باشد. قبل از تغییر، وضعیت فعلی را با سامانه Ticketing، Queue، SLA و تاریخچه درخواست بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- دستهبندی درست گزارشگیری و مسیریابی Ticket را بهتر میکند و مسئول مشخص مسئول پیگیری را روشن نگه میدارد. Ticket بدون مسئول نباید در صف رها شود
- تغییر دادن تنظیمات مرتبط با آزمایشگاه مدیریت Ticket قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
- نتیجهگیری درباره آزمایشگاه مدیریت Ticket فقط از روی یک نشانه و بدون انجام تست نهایی
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با آزمایشگاه مدیریت Ticket، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با سامانه Ticketing، Queue، SLA و تاریخچه درخواست وضعیت مرتبط با آزمایشگاه مدیریت Ticket را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با آزمایشگاه مدیریت Ticket بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- چند Ticket را اولویتبندی کن
- Category و مسئول بده
- Escalation کامل بنویس
- برای مورد تکراری Problem پیشنهاد بده
- Resolution Note تهیه کن
- رمز و اطلاعات محرمانه را داخل Ticket عمومی ثبت نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
چرا باید چند Ticket را اولویتبندی کنی و از کجا میفهمی نتیجه درست است؟
در تمرین، برای هر Ticket اثر، Urgency، تعداد کاربران و سرویس درگیر را بنویس و سپس اولویت بده. دلیل اولویت باید قابل توضیح باشد، نه بر اساس ترتیب ورود یا فشار کاربر
چرا باید Category و مسئول بدهی و از کجا میفهمی نتیجه درست است؟
دستهبندی درست گزارشگیری و مسیریابی Ticket را بهتر میکند و مسئول مشخص مسئول پیگیری را روشن نگه میدارد. Ticket بدون مسئول نباید در صف رها شود
چرا باید Escalation کامل بنویسی و از کجا میفهمی نتیجه درست است؟
ارجاع یعنی انتقال مسئله به سطح فنی یا مدیریتی مناسب وقتی دانش، دسترسی، زمان یا اثر رخداد از سطح فعلی خارج است؛ همراه ارجاع خلاصه، شواهد، تستها و تغییرهای انجامشده را بفرست
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
