میز خدمت IT در بسیاری از سازمان‌ها هنوز یک گروه پیام است. درخواست در چت می‌آید، وضعیتش در ذهن یک نفر است و فردا که همکار دیگری همان مشکل را می‌پرسد، کسی یادش نیست دفعهٔ قبل چطور حل شد. جاهایی که ITSM دارند هم مسئله فرق میکند: تیکتها هست، ولی پیدا کردن آنچه لازم است وقت میگیرد، و گزارش صبح مدیر را هنوز با دست جمع می‌کنند.
«دستیار هوش مصنوعی» دقیقاً برای همین فاصله مطرح میشود. اما پیش از هر دمویی باید بدانید چه چیزی را از آن می‌خواهید و چه چیزی را نباید.
سه نفر، سه پرسش
یک میز خدمت سه مخاطب دارد و هر کدام چیز دیگری می‌پرسد:
- درخواست‌دهنده: «درخواست من کجاست و چرا طول کشید؟» او به پاسخ فوری و فارسی نیاز دارد، پیش از آنکه تیکتی باز شود یا همکاری را مزاحم کند.
- کارشناس: «این مشکل را قبلاً چطور حل کردیم؟» او به راه‌حل قبلی و خلاصهٔ تیکت‌های مشابه نیاز دارد، با لینک به خود تیکت.
- مدیر IT: «گلوگاه کجاست؟» او عدد می‌خواهد: کدام خدمت بیشتر تکرار میشود، کدام صف دیر پاسخ میگیرد، گزارش صبح را کی ببیند.
هر دستیاری که این سه را همزمان جواب ندهد، فقط یک ابزار جست‌وجو یا فقط یک چت‌بات است.
معیارهای انتخاب
هفت پرسش که پیش از هر انتخابی بپرسید:
- روی ITSM فعلی می‌نشیند یا آن را جایگزین میکند؟ مهاجرت سامانه یک پروژهٔ جدا و پرریسک است. بهتر است دستیار ابتدا فقط بخواند.
- هر پاسخ منبع دارد؟ عدد یا راه‌حلی که به تیکت یا مقالهٔ مشخصی برنگردد، قابل اتکا نیست. روی هر پاسخ باید بتوانید بزنید و منبعش را ببینید.
- وقتی داده نیست چه می‌گوید؟ دستیاری که به‌جای «دادهٔ معتبر ندارم» عدد می‌سازد، خطرناک‌تر از نبودن دستیار است.
- نوشتن در سامانه چطور است؟ بسته‌شدن یا ثبت خودکار تیکت پیش از تأیید انسان یعنی مسئولیت بی‌صاحب. باید هر نوشتن با تأیید باشد.
- دانش از کجا می‌آید و چه کسی تأییدش میکند؟ راه‌حلی که به دانش رسمی تبدیل میشود باید صف تأیید داشته باشد.
- فارسی را واقعاً می‌فهمد؟ رابط راست‌چین کافی نیست؛ متن تیکت‌های واقعی شما با غلط املایی و اصطلاح محلی را باید آزمود.
- داده کجا می‌رود؟ دادهٔ شخصی کارکنان در تیکتها هست. پیش از ارسال به هر مدل، باید روشن باشد چه چیزی ماسک میشود و مدل کجا اجرا میشود.
کجا اشتباه می‌کنند؟
الگوی تکراری این است که فروشنده «کاهش چشمگیر تیکت» وعده میدهد و عددی از سازمانی دیگر نشان میدهد. آن عدد دربارهٔ تیکت‌های شما نیست. عدد شما را نمونه‌ای از تیکت‌های خودتان میدهد: چند درصدشان تکراری‌اند، چند درصد راه‌حل قبلی دارند و برای چند درصد دانش مکتوب هست. اگر این نمونه را نخواسته‌اند، عددهایشان حدس است. ما هم در ارزیابی از نمونه‌ای از تیکت‌های شما شروع می‌کنیم.
فرایون در این میان کجاست؟
فرایون دستیار هوشمند میز خدمت پرودکس است و وضعیت امروز آن روی سایت چنین است: «نسخهٔ ۱٫۵ — آمادهٔ پایلوت». ITSM فعلی را فقط‌خواندنی به یک لایهٔ معنایی وصل میکند و کارهای زیر در نمونهٔ آن هست:
- وضعیت درخواست و راه‌حل، پیش از آنکه تیکتی باز شود؛
- راه‌حل قبلی و خلاصهٔ تیکت برای کارشناس، با لینک به منبع؛
- صف تأیید دانش؛
- کارنامهٔ بلوغ و گلوگاه‌ها و گزارش صبحگاهی برای مدیر.
مرزهایش را هم بگوییم:
- نمونهٔ روی سایت با دادهٔ مصنوعی ساخته شده؛ هیچ داده یا عددی از سازمانی واقعی در آن نیست.
- ITSM را جایگزین نمی‌کند.
- اگر داده نباشد، عدد نمی‌سازد و همین را می‌گوید.
- هیچ تیکتی را خودکار ثبت نمی‌کند یا نمی‌بندد؛ هر نوشتن با تأیید انسان است. نوشتن در ITSM هم به دسترسی نوشتاری رسمی سامانهٔ شما وابسته است.
- حذف یا ماسک دادهٔ شخصی پیش از ایندکس، طراحی‌شده است و هنوز ساخته نشده.
- دربارهٔ محل اجرای مدل ادعای قطعی نداریم: قابل استقرار در زیرساخت سازمان؛ معماری در ارزیابی تعیین میشود.
برای دیدن آنچه نوشتیم، پخش‌کنندهٔ شش نقش را باز کنید: درخواست‌دهنده، کارشناس، مسئول فنی، مدیر IT، مدیر ارشد و مسئول انبار و دارایی، هرکدام چهار گام، و هر پاسخ با مهر منبع. سناریوی تیکت تازه در مرکز دمو هم ثبت در ITSM را فقط با تأیید خودتان نشان میدهد. بدون ثبت‌نام است.
در پایلوت چه چیزی را اندازه بگیرید؟
چهار سنجه کافی است و هر چهار از خود ITSM شما قابل استخراج‌اند:
- سهم درخواست‌های تکراری: چند درصد تیکتها قبلاً مشابهش حل شده؟
- زمان پیدا کردن راه‌حل قبلی: کارشناس برای پیدا کردن راه‌حل مشابه چه مدت می‌گذارد؟ پیش و پس از دستیار اندازه بگیرید.
- سهم پاسخ‌هایی که منبع دارند: هدف همهٔ پاسخ‌هاست؛ هر پاسخ بدون منبع باید یا حذف شود یا برچسب بخورد.
- سهم موارد «ندارم» درست: وقتی دانش وجود ندارد، دستیار باید این را بگوید. این سنجه نشان میدهد دستیار به‌جای حدس زدن، صادق است.
از «رضایت» ظاهری هفتهٔ اول زیاد خوشحال نشوید؛ اندازه‌گیری رفتار واقعی ارزش بیشتری دارد.
دانش را کی و چگونه وارد کنیم؟
بزرگ‌ترین خطر دستیارهای میز خدمت این است که یک راه‌حل اشتباه یک بار تأیید شود و همیشه تکرار شود. به همین دلیل مسیر درست این است که راه‌حل پیشنهادی از تیکت‌های بسته‌شده بیاید، یک متخصص تأیید کند و بعد به دانش رسمی تبدیل شود. صف تأیید دانش یعنی همین: هیچ پیشنهادی بی‌تأیید انسان به مقالهٔ رسمی تبدیل نمی‌شود.
یک آزمون ساده برای هر فروشنده
نمونه‌ای از ده تیکت واقعی خودتان را بردارید، بدون نام اشخاص، و از فروشنده بخواهید سه کار کند: برای هر تیکت راه‌حل قبلی را پیدا کند، منبعش را نشان بدهد و برای یکی که جواب ندارد بگوید «ندارم». اگر آخری را نمی‌گوید، همین کافی است که بدانید چه خریده‌اید.
گام بعد
اگر می‌خواهید ببینید در میز خدمت سازمان شما چه سهمی از وقت کارشناسان قابل آزاد شدن است، ارزیابی روی نمونهٔ تیکت‌های خودتان انجام میشود. ارزیابی فرصت پرودکس، با نام «۲۱ روز تا سود»، یعنی نقشهٔ اولین پایلوت سودآور شما، ۲۱ روز طول می‌کشد و ۷۵ میلیون تومان است (مالیات بر ارزش افزوده جداست). خروجی‌اش یک برگه است: مسئله، دادهٔ لازم، معیار موفقیت و بازده برآوردی یک پایلوت ۸ هفته‌ای. سهم شما دسترسی به دادهٔ موجود و ۲ جلسهٔ کاری است. درخواست ارزیابی را ثبت کنید.
برای شروع سبک‌تر، راهنمای هفت مسئلهٔ میز خدمت IT را بگیرید.