کاربران گیج سازمان!

دسته بندی صحیح خدمات، بزرگترین رمز کاربری ابزار ITIL این عنوان توهین به کاربران سازمان نیست رویکرد غلط و دشوار فناوری اطلاعات است که آنها را گیج می کند! بحث چگونگی ترویج استفاده از سرویس دسک توسط کاربران و نحوه طبقه بندی خدمات قایل ارایه فناوری اطلاعات بحثی است که من حتی نمیتوانم به شما بگویم که چند ساعت یا حتی چندین روز، در مورد دسته بندی خدمات در ابزارهای IT با روسا و کارشناسان فناوری بارها بحث و گفتگو کرده ام. چیزی که بسیار در نهایت می شنوم این است که کاربران ما گیج هستند! اول چیزی که خیلی مهم است اینست که هرگز طرح جامع، منجسم و ۱۰۰% تضمینی برای تعریف دسته بندی های خدمات بر اساس یک الگوی ثابت و استاندارد وجود ندارد مهمترین دلیل آن هم این است که خدمات و سیاست های هر سازمانی با دیگری متفاوت است. پس کپی برداری از یک الگوی واحد برای سازمان شما ایده جالبی نیست! دوم اینکه بسیاری از شرکت ها حتی خدمات خود را کاملا درک نکرده اند، بنابراین چگونه می توان چیزی را که به طور کامل درک نشده است دسته بندی کنید؟ برای مثال، چگونه یک رویداد با یک سرور Exchange دسته بندی می شود: مسئله سرور؟ شماره ایمیل؟ یک مشکل با یک سرویس ایمیل؟ سوم، همیشه روشن نیست که چرا حوادث به هر حال به یک رده از دسته بندی ها نیاز دارند. آیا امیدوار هستید که اصلا وجود دسته بندی، مسیریابی را بهبود ببخشید؟ درباره پایگاه دانش شما چطور؟ از آنجایی که هر شرکت دارای فرهنگ خاص خود است، من هم نمیتوانم یک روش درمان برای طبقه بندی خدمات شما بطور اخص تجویز کنم. تنها کاری که می توان کرد، راهنمایی و ارایه دستورالعمل هایی برای ایجاد و یا تغییر دسته های شما است. من زمانی فقط این قوانین را می فهمم که مدیران فناوری اطلاعات یا راهبران سرویس دسک، دسته بندی ها را نادیده نمی گیرند ...

قانون شماره ۱

یک برنامه مدون را به طور مداوم برای بهبود مستمر طبقه بندی خدمات در بازهای زمانی منظم ترتیب دهید اگر کسی می گوید: "من وجود این دسته بندی را ۱۰۰٪ تضمین می کنم، این ۱۰۰٪ صحیح نیست." اگر شما با استفاده از ابزار جدید یا تمیز کردن دسته های موجود، به "تجزیه تحلیل صحیح" نروید هرگز به نتیجه مطلوب دست نخواهید یافت.

قانون شماره ۲

می دانید چرا شما از دسته ها استفاده می کنید؟ طبقه بندی حوادث می تواند برای تحقیق در مورد مشکلات تکراری، مسیریابی خودکار بلیط ها، ورود به یک پایگاه دانش یا حتی برای کمک به اولویت بندی استفاده شود. دانستن "چرا" به شما کمک خواهد کرد که چه چیزی را طبقه بندی کنید، کدام دسته ها را استفاده کنید و حتی چگونه آنها باید نامگذاری شوند.

قانون شماره ۳

بهتر است شروع به کوچک شدن کنید و سپس آنرا گسترش دهید، بعد با صدها دسته از جزئیات که باید بعدا ترکیب شوند شروع شود. مثال خوب ایمیل است با یک دسته ایمیل ساده شروع کنید. بعدا اگر متوجه شدید که تعداد زیادی از مسائل مربوط به ایمیل مبتنی بر سرویس گیرنده در مقایسه با مسائل مربوط به سرور وجود دارد و تفاوت بین آنها دو مشکل است، "ایمیل" را به "ایمیل سرویس دهنده" و "سرور ایمیل" تقسیم کنید. مثلا: ایمیل مایکروسافت و سرور ایمیل

قانون شماره ۴

پس از تعریف دسته بندی ها، هرگز به سادگی یک دسته را در ابزار IT خود حذف یا تغییر ندهید.  سوابق داده ها یکی از مهم ترین بخش های یک برنامه ITSM است، بنابراین حفظ  آنها کلیدی است. اگر مجبور به این کار هستید ابتدا دسته بندی جدیدی را تعریف نمایید و آن قبلی را غیرفعال کنید تا امکان انتخاب آن توسط کاربر نهایی/مشتری میسر نباشد البته، این همه بستگی به تکنولوژی نرم افزار ITIL سازمان شما دارد، اما این یک قاعده خوب است.

قانون شماره ۵

دسته بندی را به یک فیلد محدود نکنید. انواع سیستم های متنوعی که دیده ام ترکیبی از CI، یک سرویس و یک دسته است. ابتدا ببیند خدمت ایمیل جزو کدام دسته بندی اصلی است برای نشان دادن یک مسئله که در آن یک کاربر با مشکل در ایمیل مواجه شد، تیکت ممکن است به صورت زیر پر شود:

نام خدمت: ایمیل CI / دارایی: Server_Email دسته بندی: نرم افزارهای سازمانیß ایمیلßپیغام خطا این نوع ساختار، با هر فیلد مستقل از یکدیگر، امکان گزارش دادن به یک CI خاص، یک سرویس خاص، یک دسته یا ترکیبی از این زمینه ها را فراهم می کند. این اجازه می دهد تا داده ها با روش های مختلف گزارش شوند.

قانون شماره ۶

احتمالا اگر بطور دقیق، شفاف و مطابق با نظرات کاربران، دسته بندی های را تعیین نکرده باشید باید منتظر استفاده کاربران از گزینه های" سایر" یا "متفرقه" به عنوان یک دسته بندی پر تکرار باشید، می توانم اطمینان حاصل کنم که بیش از ۵۰٪ از درخواست ها در این دسته ها قرار می گیرند. چرا که کاربر همیشه دنبال ساده ترین راه طرح مشکل خود است پس اگر دسته بندی های پیچیده، نامفهوم، فراوان و ... ایجاد کرده باشید باید منتظر این بار ترافیکی ناخواسته باشید، پس درک اینکه مشتری چه چیزی را میخواهد مطرح کند و چگونه باید آنرا در دسترس او قرار داد بسیار مهم است.

قانون شماره ۷

برای بررسی و بازبینی دوره ای دسته بندی ها برنامه ریزی کنید که در آن تمامی نمایندگان کاربران و کارشناسان فناوری حضور داشته باشند انتظارات آنها، شناساندن خدمات به آنها و چگونگی ارایه طبقه بندی و مسیر رسیدن به طرح یک درخواست را برایشان شفاف سازی نمایید.

قانون شماره ۸

برای ادامه قانون # ۷، این نیز یک ایده خوب است که که از هر دسته تعریف شده در یک بازره زمانی خاص گزارش گیری نمایید. این می تواند نوع خطاهای مربوط به انواع مشکلات را با هم مرتبط کند. حتی می تواند برای کمک به مسیریابی خودکار رخواست ها مورد استفاده قرار گیرد.

قانون شماره ۹

سعی کنید از نام های فروشندگان و سرویس دهنده های خاص دور بمانید. معمولا یک خدمت نظیر" ایمیل" در بلند مدت و در چشم اندازهای آینده سازمان مرسوم و رایج باقی می ماند اما، هیچ تضمینی وجود ندارد که در چند سال آینده  آن فروشنده وجود داشته باشد. یا اینکه ممکن است در بلندمدت سرویس این فروشنده جایگزین دیگری شود پس بجاری استفاده از دسته بندی با عنوان "ایمیل مایکروسافت" از عنوان "سرویس ایمیل" استفاده نمایید چراکه فروشنده ها می آیند و می روند، و استفاده از نام آنها، سبب تغییرات دسته بندی ها می شود که در آینده کاربران و شما را با داده کاوی و گزارشگیری با مشکل روبرو خواهد کرد.

قانون شماره ۱۰

همیشه نتیجه نهایی را در ذهن داشته باشید - گزارش دهی و معیارسنجی! شاید هم حتی کمی مسیریابی باشد. بنابراین بدنیال طرح بهترین عناوین باشید، اما در طول سفر پیاده سازی ITIL فراموش نکنید که این تلاش شما برای کمک به شفافیت در سازمان است.

نتیجه گیری

طبقه بندی خدمات قابل ارایه توسط واحد فناوری اطلاعات و یا هر مرکز ارایه کننده خدمات سبب دسترسی سریع کاربران برای طرح رخداد خواهد شد و این طبقه بندی هر چقدر شفاف تری، سده تر، قابل فهم تر و عمومی تر باشد علاوه بر اینکه از سردرگمی کاربران جلوگیری کرده اید باعث دریافت بهترین گزارشات و همچنین امکان گسترش موضوعات و آیتم ها در آینده بدون اعمال تغییرات در طبقه بندی فعلی خواهد شد. پس این را به گیجی و کم سوادی کاربران بسط ندهید کاربران کاملا بصورت شرطی روال و پروسه هایی که شما ایجاد می کنید را حتی اگر به واقع از آن اطلاع دقیقی هم نداشته باشند اما مو به مو یاد می گیرند و انجام می دهند پس با ایجاد یک طبقه بندی جذاب، ساده و شفاف، از گیج شدن آنها در مواجه با ابزار سرویس دسک جلوگیری کنید. درج دقیق دسته بندی ها در روند تشخیص، تجزیه و تحلیل دلیل ریشه ای مشکل، توسعه و گسترش آن در آینده برای ایجاد ارزش، کلید موفقیت شما در پیاده سازی سرویس دسک است – پس بدون فشار پس از آن! به یاد داشته باشید این نوشته هم ممکن است لزوما مناسب سازمان شما نباشد بلکه از آن صرفا به عنوان راهنمایی در نظر بگیرید،

نظرات خود را حتما قید فرمایید. هادی احمدی