یا اگر کاربر قرار است درخواست خود را با کلمه کلیدی مثل "اینترنت" مطرح کند و این کلمه را در کاتالوگ خدمات پورتال سلف سرویس خود جستجو کند و در این حال با چندین فرم متنوع روبرو شود همیشه ساده ترین و یا اولین گزینه را در میان انبوه فرم ها انتخاب می کند و اینجا نیز باید باز هم منتظر همین پیامد مشابه باشیم.
پس چه کنیم؟ چه فرم بگذاریم و چه نگذاریم همین داستان است!
باید خدمت شما عرض کنم که خیر می توان بر این مشکل فائق آمد.
این یعنی شما چیزی برای کاربر در واسط کاربری گذاشته اید که کاربر دنبال چیز دیگری است و آن سادگی است و سرعت در رسیدن به نیازمندی!
برای جلوگیری از چنین پیامدی در سرویس دسک سازمان موارد زیر را در نظر بگیرید:
- ساده سازی کنید و پیچیده اش نکنید
- ایجاد نقش ویرایشگر
- ایجاد و اجباری کردن تکمیل فیلدی بنام" علل وقوع حادثه" برای کارشناسان پشتیبانی
- آموزش مستمر به کاربران برای انتخاب بهتر دسته بندی ها و موضوع درخواست ها
- بهبود مستمر در تولید فرم های درخواست کاربر
ساده سازی کنید و پیچیده اش نکنید.
یک سازمان، کاتالوگ خدماتی طراحی کرده که ۱۰۰ فرم در آن است کاربر بیچاره برای یافتن نیازمندی خود باید زمان زیادی را صرف یافتن فرم مرتبط در میان انبوهی از فم های رخداد و سرویس کند که این مهم علاوه بر تولید فرم های نامرتبط (بدلیل ساده ترین راه (تجربه کاربری)) سبب اتلاف وقت کاربر و مدیر مشکل برای بررسی علل وقوع این نوع درخواست می گردد.
بهترین تمرین:
- بهتر است که خدمات را بطور شفاف و کلی طراحی کنید و با اجباری کردن فیلدها کاربر را به سمت انتخاب درست مشکل هدایت کنید. مثلا برای سرویسی مثل "اینترنت" یک فرم رخداد (ثبت خرابی) و یک فرم ایجاد دسترسی تولید کنید. کاربر در این حالت فقط ۲ فرم برای ثبت درخواست دارد و با آموزش هایی که شما به او میدهید امکان انتخاب فوری را بدون ثبت غلط دارد.
- دسترسی کاربران به فرم های مرتبط را کنترل کنید مثلا کاربرانی که قرار نیست سرویس اینترنت داشته باشند پس بهتر نیست که اصلا فرم درخواست خرابی اینترنت و یا ایجاد دسترسی به اینترنت را هم نبینند!؟
- اتوماسیون سازی بیشتری بکنید، پشت هر فرم فرایندهایی است که شما قادرید تا با انتخاب هر فیلد در فرم مورد نظر فیلدهایی دیگر بطور خودکار تکمیل شود این کمک میکند تا دقیقا مشکلات کاربر دقیق ثبت گردد.
ایجاد نقش ویرایشگر
در اکثر نرم افزارهای پیاده سازی ITIL قابلیتی بنام Editor یا ویرایشگر هست با استفاده از آن قادر خواهید بود تا کاربرانی که فهم و درک بهتری از IT نسبت به سایر همکاران خود دارند برای مدیریت درخواستهایی که صحیح ثبت نمی شوند کمک بطلبید این نقش کمک می کند تا زمانی یک کاربر درخواستی را ثبت می کند درخواست پیش از آنکه به انفورماتیک برسد به دست ویرایشگر می رسد این ویرایشگر هر کسی می تواند باشد، مدیر کاربر، منشی واحد و یا هر نماینده انتخاب شده ای دیگر او پس از دریافت درخواست اصلاحات لازم را بر روی آن انجام و برای رسیدگی به انفورماتیک ارجاع می دهد.
ایجاد و اجباری کردن تکمیل فیلدی بنام" علل وقوع حادثه" برای کارشناسان پشتیبانی
همیشه شب امتحان، اجباری برای درس خواندن است! گویی اجبار باید باشد بخصوص در کشور ایران! اجبار سبب انجام وظایفی می شود که از آنها شانه خالی می کردیم. فقط کاربران نیستند که بدنبال سادگی و تنبلی اند، کارشناسان پشتیبانی نیز هستند که درخواست ها را بدون هیچ اقدام مازادی می بندند!
بی آنکه از طریق مدیریت حوادث برای آن راهکاری عرضه کنند بی آنکه کار یا گزارشکار و یا یادداشت و حتی گفتگویی با کاربر ثبت کنند بلافاصله درخواست ها را می بندند. ایجاد فیلدهای اجباری در فرم های حادثه و سرویس این امکان را می دهد تا اگر کاربر در ثبت درخواست های تکراری و مشابه اقدام کرد کارشناسان پشتیبانی بتوانند "علت دقیق حادثه" را درج کنند این به مدیر مشکل کمک می کند در آینده از میان هزاران درخواست مشابه به هم با عناوین و یا دسته بندیهای تکراری، گزینه ای دیگر برای فیلتر کردن حوادث تکراری داشته باشد.
آموزش مستمر به کاربران برای انتخاب بهتر دسته بندی ها و موضوع درخواست ها
در مقاله سطوح پشتبانی انفورماتیک گفتم که کم هزینه ترین لایه پشتیبانی، سطح صفر یا همان پورتال سلف سرویس کاربران است پس بجای اینکه انرژِی خود را روی مدیریت مشکل و.. بگذارید از تمام کارشناسان بخواهید تا بر روی آموزش و خودخدمتی کاربران تمرکز کنند و با ایجاد راهکارهای محبوب و مورد پسند آنها را برای افزایش سطح تسلط به خدمات و حوادث مرتبط ترغیب کنید بی شک می دانید که حوادث و مشکلات هیچ ارزشی به همراه ندارد و فقط بار منفی و (ارزش منفی) بهمراه خواهد آورد.
بهبود مستمر در تولید فرم های درخواست کاربر
بهبود مستمر از تمرینات عالی ITIL است قطعا حتی تمرینات فوق هم نسخه شفابخش نیستند بسته به سیاست ها، رفتار و تجربه کاربری کاربران سازمان، مرتبط بهبود مستمر را در ارایه خدمات لحاظ کنید بویژه این بهبود باید به گونه ای باشد که علاوه بر افزایش خشنودی کاربر، سهولت و کارایی و سرعت بیشتر را به ارمغان بیاورد
[…] مقاله مرتبط: همه حوادث تکراری مشکل نیستند! […]
[…] چرا حوادث تکراری، مشکل نیستند! […]
[…] همیشه حوادث تکراری مشکل نیستند! […]
[…] همیشه حوادث تکراری مشکل نیستند! […]
[…] مدانت [ مجری تخصصی پیادهسازی چارچوب ITIL ] حادثه بزرگ چیست و فرایند آن را چگونه پیادهسازی کنیم؟ تاریخ انتشار: 12 آگوست 2023 34-ITIL4 زمان مطالعه: 13 دقیقه تعداد کلمات: 2424 تعداد صفحات: 4 از این دست نوشتهها بیشتر بخوان… شاخصهای کلیدی عملکرد ITIL استفاده از AIOps در مدیریت خدمات همیشه حوادث تکراری، مشکل نیستند! […]