درس ۵ از ۱۰

Category، Assignment و صف

هدف این درس این است که Category، Assignment و صف برایت فقط یک عنوان تئوری نباشد؛ مفهوم را کوتاه و روشن می‌فهمیم، بعد با سامانه Ticketing، Queue، SLA و تاریخچه درخواست سراغ وضعیت واقعی می‌رویم و در پایان روش بررسی یک مشکل مرتبط را تمرین می‌کنیم این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

این درس برای مطالعه کامل نوشته شده است

با حوصله بخوان، مثال‌ها را تحلیل کن و تمرین‌ها را انجام بده؛ هدف حفظ کردن تعریف‌ها نیست

Category گزارش و Routing را بهتر می‌کند

Category درست باعث می‌شود Ticket به صف مناسب برود و گزارش‌های بعدی علت‌های پرتکرار را نشان دهند؛ دسته‌بندی نباید بر اساس حدس بدون اطلاعات انجام شود نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند نکته‌ای که هنگام پشتیبانی نباید از آن عبور کنی این است که اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

Subcategory نباید بیش از حد پیچیده باشد

Subcategory باید به‌اندازه‌ای جزئی باشد که گزارش مفید شود ولی نه آن‌قدر زیاد که کارشناس بین ده‌ها گزینه مشابه سردرگم شود برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

Assignment مالک را مشخص می‌کند

Assignment مشخص می‌کند کدام فرد یا تیم مسئول اقدام بعدی است؛ هنگام ارجاع زمان و دلیل انتقال را ثبت کن در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای عیب‌یابی درست، این بخش را فقط به‌عنوان یک اصطلاح حفظ نکن و توجه داشته باش که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

صف حوزه مسئول را نشان می‌دهد

صف صف انتظار Packet یا عملیات است و وقتی منبع از نرخ ورود کندتر باشد رشد می‌کند؛ در شبکه یا Storage، صف طولانی همراه با Latency بالا می‌تواند نشانه فشار باشد وجود صف کوتاه طبیعی است؛ روند و اثر روی سرویس مهم است در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست

دسته‌بندی اشتباه گزارش را خراب می‌کند

اگر Ticketها مدام در Category غلط بسته شوند آمار مدیریت و برنامه بهبود غلط می‌شود؛ داده Service Desk فقط وقتی ارزش دارد که ثبت آن قابل اعتماد باشد اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع می‌شود، نفر بعدی نباید مجبور باشد همه پرسش‌های اولیه را از ابتدا تکرار کند در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن می‌شود که اولویت با صدای بلندتر کاربر تعیین نمی‌شود؛ اثر بر کسب‌وکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشه‌ای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی

مثال محیط واقعی

فرض کن در میز خدمت و سامانه درخواست‌ها مشکلی گزارش شده و احتمال می‌دهی به Category، Assignment و صف مربوط باشد. قبل از تغییر، وضعیت فعلی را با سامانه Ticketing، Queue، SLA و تاریخچه درخواست بررسی می‌کنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه می‌کنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر می‌دهی و بعد همان تست را دوباره اجرا می‌کنی تا مطمئن شوی مشکل واقعاً برطرف شده است

اشتباهات رایج

این اشتباه‌ها را تکرار نکن

  • Category درست باعث می‌شود Ticket به صف مناسب برود و گزارش‌های بعدی علت‌های پرتکرار را نشان دهند؛ دسته‌بندی نباید بر اساس حدس بدون اطلاعات انجام شود
  • تغییر دادن تنظیمات مرتبط با Category، Assignment و صف قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
  • نتیجه‌گیری درباره Category، Assignment و صف فقط از روی یک نشانه و بدون انجام تست نهایی
تمرین عملی

حالا خودت انجام بده

  1. در یک نمونه آزمایشی مرتبط با Category، Assignment و صف، فقط وضعیت فعلی را مشاهده کن و سه نکته‌ای را که برای تشخیص حالت سالم مهم‌اند یادداشت کن
  2. با سامانه Ticketing، Queue، SLA و تاریخچه درخواست وضعیت مرتبط با Category، Assignment و صف را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو می‌گویند
  3. یک خطای فرضی مرتبط با Category، Assignment و صف بنویس و مشخص کن اولین تست کم‌خطر تو چیست و چه نتیجه‌ای فرضیه‌ات را رد می‌کند

نکته‌هایی که باید با خودت ببری

  • Category گزارش و Routing را بهتر می‌کند
  • Subcategory نباید بیش از حد پیچیده باشد
  • Assignment مالک را مشخص می‌کند
  • صف حوزه مسئول را نشان می‌دهد
  • دسته‌بندی اشتباه گزارش را خراب می‌کند
  • رمز و اطلاعات محرمانه را داخل Ticket عمومی ثبت نکن
خودسنجی

قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده

این نکته را با یک مثال توضیح بده: Category گزارش و Routing را بهتر می‌کند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Category درست باعث می‌شود Ticket به صف مناسب برود و گزارش‌های بعدی علت‌های پرتکرار را نشان دهند؛ دسته‌بندی نباید بر اساس حدس بدون اطلاعات انجام شود

این نکته را با یک مثال توضیح بده: Subcategory نباید بیش از حد پیچیده باشد. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Subcategory باید به‌اندازه‌ای جزئی باشد که گزارش مفید شود ولی نه آن‌قدر زیاد که کارشناس بین ده‌ها گزینه مشابه سردرگم شود

این نکته را با یک مثال توضیح بده: Assignment مالک را مشخص می‌کند. بعد بگو در عمل چطور آن را بررسی می‌کنی.

Assignment مشخص می‌کند کدام فرد یا تیم مسئول اقدام بعدی است؛ هنگام ارجاع زمان و دلیل انتقال را ثبت کن

مطالعه درس همیشه عمومی است

برای ذخیره پیشرفت، دوره را رسمی شروع کن

با ثبت‌نام، تکمیل درس‌ها و نمره آزمون روی حساب ذخیره می‌شود

ثبت‌نام و شروع رسمی