بررسی علل ثبت درخواست های تکراری و مشابه و جلوگیری از وقوع آنها بدون مدیریت مشکل!
چند قلوهایی که گاهی با لبخند و گاهی با ناراحتی جلوی دیدگان شما ظاهر می شوند و شما می مانید و شناختن دقیق آنها! آیا همه آنها یکی هستند؟ آیا با هم متفاوت هستند؟ اگر متفاوتند چرا ظاهر آنهای مشابه و شبیه به هم است؟ چه باید کرد تا آنها را از هم تمیز داد؟ چه باید کرد تا بدون مراجعه به بخش دیگری آنها را شناخت!؟
در تعریفی که از حادثه یا Incident در چارچوب ITIL داشتیم گفتیم که هر حادثه یعنی وقفه در عملیات جاری کاربر و تکرر حوادث می تواند ناشی از بروز و وقوع یک مشکل Problem بزرگ و فراگیر باشد.
مدیریت حوادث هم یعنی رسیدگی فوری و سریع به رخدادها و بازگردان عملیات به حالت عادی است در حالیکه هدف مدیریت مشکل، یافتن سرچشمه علل وقوع حوادث، حل ریشه ای و جلوگیری از تکرار وقوع آنهاست و همچنین بارها طی جلسات آموزشی چیزی که تاکید بسیاری روی آن دارم این است که نرم افزارها و ابزارها فرایند (تمرین) مدیریت مشکل را انجام نمی دهند به عبارتی داشتن ابزار به تنهایی گره کشای معضلات و مشکلات سازمان شما نیست! مقاله احمق با یک ابزار هنوز احمق است را بخوانید.
ابزار فقط بستری جهت سهولت در بررسی مدیریت مشکل برای شما فراهم می کنند چراکه خود مدیریت مشکل یک رویداد انسانی است و ماشینی نیست فعلا که نیست! اگر هوش مصنوعی با قدرت یادگیری ماشین بر روی سرویس های پیاده سازی ITIL سوار شود آنگاه شاید بتوان از ربات ها بجای انسان استفاده کرد اما چیزی که این هوش های مصنوعی تاکنون نداشته اند و ظاهرا نخواهند داشت قدرت تجزیه و تحلیل است مهمترین فاز در شناخت یک مشکل هم همان تجزیه تحلیل آن است، توانایی تجسم، بیان، درک یا حل مسائل ساده و پیچیده با اتخاذ تصمیمات معقول بر پایه اطلاعات موجود را تجزیه و تحلیل و یا مهارت تحلیل می گویند که این قدرت همان تفکر اندیشمندانه است که در نهاد بشر جاری است و البته حتی در بسیاری از آدمها! نیز ممکن است اثری از آن نباشد! مهارت تجزیهو تحلیل جدای از تمامی ضرایب هوشی (هوش اقتصادی، هوش ریاضی، هوش اجتماعی و…) شامل استفاده از تفکر منطقی برای شکستن مسایل پیچیده به اجزای کوچکتر آن است دقیقا شبیه خُرد کردن یک پروژه به فازهای و کارها…
تحلیلی فکر کردن یک مهارت اکتسابی است، شبیه چوب بری یا رانندگی کردن که می‌توان آنرا آموخت، و با تمرین کردن زیاد، نیز بهبود خواهد یافت. این مهارت صرفا با آموختن مفاهیم تئوریک به دست نمی آید مثلا همانند خیلی از مهارت‌های دیگر مانند دوچرخه سواری، با نشستن در کلاس درس و شنیدن اینکه چگونه انجام می‌شود، قابل یادگیری نیست. تحلیلگران با عمل کردن، مهارت پیدا می‌کنند .
برای آزمودن مهارت‌های تحلیلی ممکن است از فرد خواسته شود تا در یک مقاله در مورد آسیب های اجتماعی بنویسد و یا یک سری از حوادث را در دسته بندی خاصی قرار دهد، یا مطلبی را نقد کند.
به عبارتی مهارت تحلیلی ذهن پرسشگر افراد را به کار می اندازد تا برای هر مشکلی دنبال یک راه حل باشند این همان قدرت تجزیه و تحلیل است یک مهارت تکامل یافته در انسان.
فرض کنیم در سازمانی با ۵۰۰ کاربر ، ۶ تیکت با عنوان عدم اتصال به اینترنت همزمان طی یک روز (امروز) در سرویس دسک انفورماتیک ثبت شده در نگاه نخست این می تواند نشانگر وقوع یک مشکل باشد!
اینجا دو مسیر برای بررسی این موارد پیش روی شماست:
فهمیدن هر کدام از آنها نیازمند درک و مهارت تحلیلی شماست که آیا توان مدیریت مشکل را دارید؟
و البته بررسی تیکت های ثبت شده بنابراین درک دو مورد فوق نیازمند قوه تشخیص دقیق شما دارد.
پس در این سناریو از تیکت ها را بررسی می کنید فرض کنیم که کاربران زیر به دلایل چنین درخواستی ثبت کرده اند:
در موارد فوق هر کاربر با هر حادثه ای، دلیل وقوع خودش را دارد و نمی تواند ناشی از مشکل فراگیر و یا گسترده ای باشد و تکرار یک عنوان دال بر وجود یک مشکل ناشناخته یا شناخته شده هم نیست!
پس چیست!؟
می دانید که اگر شما در مقام مدیر مشکل باشید این سناریو یک چالش برای شما خواهد بود!؟
چرا چندین مورد درخواست با علل مختلف تحت یک عنوان مشابه ثبت شده!؟
خود این یک مشکل است! بنابراین جلوگیری از تکرار این معضل را باید در اولویت قرار داد.
اما این مشکل چیست!؟
اگر فقط فرم درخواستی بنام “عدم اتصال به اینترنت” در پورتال سلف سرویس کاربران ایجاد کرده اید باید هم منتظر چنین پیامدی باشید زیرا کاربران انتخاب دیگری ندارند و هر چیزیکه در دید و دسترس آنها باشد برای ثبت فوری درخواست از آن استفاده می کنند.
یا اگر کاربر قرار است درخواست خود را با کلمه کلیدی مثل “اینترنت” مطرح کند و این کلمه را در کاتالوگ خدمات پورتال سلف سرویس خود جستجو کند و در این حال با چندین فرم متنوع روبرو شود همیشه ساده ترین و یا اولین گزینه را در میان انبوه فرم ها انتخاب می کند و اینجا نیز باید باز هم منتظر همین پیامد مشابه باشیم.
پس چه کنیم؟ چه فرم بگذاریم و چه نگذاریم همین داستان است!
باید خدمت شما عرض کنم که خیر می توان بر این مشکل فائق آمد.
این یعنی شما چیزی برای کاربر در واسط کاربری گذاشته اید که کاربر دنبال چیز دیگری است و آن سادگی است و سرعت در رسیدن به نیازمندی!
برای جلوگیری از چنین پیامدی در سرویس دسک سازمان موارد زیر را در نظر بگیرید:
یک سازمان، کاتالوگ خدماتی طراحی کرده که ۱۰۰ فرم در آن است کاربر بیچاره برای یافتن نیازمندی خود باید زمان زیادی را صرف یافتن فرم مرتبط در میان انبوهی از فم های رخداد و سرویس کند که این مهم علاوه بر تولید فرم های نامرتبط (بدلیل ساده ترین راه (تجربه کاربری)) سبب اتلاف وقت کاربر و مدیر مشکل برای بررسی علل وقوع این نوع درخواست می گردد.
بهترین تمرین:
در اکثر نرم افزارهای پیاده سازی ITIL قابلیتی بنام Editor یا ویرایشگر هست با استفاده از آن قادر خواهید بود تا کاربرانی که فهم و درک بهتری از IT نسبت به سایر همکاران خود دارند برای مدیریت درخواستهایی که صحیح ثبت نمی شوند کمک بطلبید این نقش کمک می کند تا زمانی یک کاربر درخواستی را ثبت می کند درخواست پیش از آنکه به انفورماتیک برسد به دست ویرایشگر می رسد این ویرایشگر هر کسی می تواند باشد، مدیر کاربر، منشی واحد و یا هر نماینده انتخاب شده ای دیگر او پس از دریافت درخواست اصلاحات لازم را بر روی آن انجام و برای رسیدگی به انفورماتیک ارجاع می دهد.
همیشه شب امتحان، اجباری برای درس خواندن است! گویی اجبار باید باشد بخصوص در کشور ایران! اجبار سبب انجام وظایفی می شود که از آنها شانه خالی می کردیم. فقط کاربران نیستند که بدنبال سادگی و تنبلی اند، کارشناسان پشتیبانی نیز هستند که درخواست ها را بدون هیچ اقدام مازادی می بندند!
بی آنکه از طریق مدیریت حوادث برای آن راهکاری عرضه کنند بی آنکه کار یا گزارشکار و یا یادداشت و حتی گفتگویی با کاربر ثبت کنند بلافاصله درخواست ها را می بندند. ایجاد فیلدهای اجباری در فرم های حادثه و سرویس این امکان را می دهد تا اگر کاربر در ثبت درخواست های تکراری و مشابه اقدام کرد کارشناسان پشتیبانی بتوانند “علت دقیق حادثه” را درج کنند این به مدیر مشکل کمک می کند در آینده از میان هزاران درخواست مشابه به هم با عناوین و یا دسته بندیهای تکراری، گزینه ای دیگر برای فیلتر کردن حوادث تکراری داشته باشد.
در مقاله سطوح پشتبانی انفورماتیک گفتم که کم هزینه ترین لایه پشتیبانی، سطح صفر یا همان پورتال سلف سرویس کاربران است پس بجای اینکه انرژِی خود را روی مدیریت مشکل و.. بگذارید از تمام کارشناسان بخواهید تا بر روی آموزش و خودخدمتی کاربران تمرکز کنند و با ایجاد راهکارهای محبوب و مورد پسند آنها را برای افزایش سطح تسلط به خدمات و حوادث مرتبط ترغیب کنید بی شک می دانید که حوادث و مشکلات هیچ ارزشی به همراه ندارد و فقط بار منفی و (ارزش منفی) بهمراه خواهد آورد.
بهبود مستمر از تمرینات عالی ITIL است قطعا حتی تمرینات فوق هم نسخه شفابخش نیستند بسته به سیاست ها، رفتار و تجربه کاربری کاربران سازمان، مرتبط بهبود مستمر را در ارایه خدمات لحاظ کنید بویژه این بهبود باید به گونه ای باشد که علاوه بر افزایش خشنودی کاربر، سهولت و کارایی و سرعت بیشتر را به ارمغان بیاورد
[…] مقاله مرتبط: همه حوادث تکراری مشکل نیستند! […]
[…] چرا حوادث تکراری، مشکل نیستند! […]
[…] همیشه حوادث تکراری مشکل نیستند! […]
[…] همیشه حوادث تکراری مشکل نیستند! […]