قانون شماره ۵
دسته بندی را به یک فیلد محدود نکنید. انواع سیستم های متنوعی که دیده ام ترکیبی از CI، یک سرویس و یک دسته است.
ابتدا ببیند خدمت ایمیل جزو کدام دسته بندی اصلی است برای نشان دادن یک مسئله که در آن یک کاربر با مشکل در ایمیل مواجه شد، تیکت ممکن است به صورت زیر پر شود:
نام خدمت: ایمیل
CI / دارایی: Server_Email
دسته بندی: نرم افزارهای سازمانیß ایمیلßپیغام خطا
این نوع ساختار، با هر فیلد مستقل از یکدیگر، امکان گزارش دادن به یک CI خاص، یک سرویس خاص، یک دسته یا ترکیبی از این زمینه ها را فراهم می کند. این اجازه می دهد تا داده ها با روش های مختلف گزارش شوند.
قانون شماره ۶
احتمالا اگر بطور دقیق، شفاف و مطابق با نظرات کاربران، دسته بندی های را تعیین نکرده باشید باید منتظر استفاده کاربران از گزینه های" سایر" یا "متفرقه" به عنوان یک دسته بندی پر تکرار باشید، می توانم اطمینان حاصل کنم که بیش از ۵۰٪ از درخواست ها در این دسته ها قرار می گیرند. چرا که کاربر همیشه دنبال ساده ترین راه طرح مشکل خود است پس اگر دسته بندی های پیچیده، نامفهوم، فراوان و ... ایجاد کرده باشید باید منتظر این بار ترافیکی ناخواسته باشید، پس درک اینکه مشتری چه چیزی را میخواهد مطرح کند و چگونه باید آنرا در دسترس او قرار داد بسیار مهم است.
قانون شماره ۷
برای بررسی و بازبینی دوره ای دسته بندی ها برنامه ریزی کنید که در آن تمامی نمایندگان کاربران و کارشناسان فناوری حضور داشته باشند انتظارات آنها، شناساندن خدمات به آنها و چگونگی ارایه طبقه بندی و مسیر رسیدن به طرح یک درخواست را برایشان شفاف سازی نمایید.
قانون شماره ۸
برای ادامه قانون # ۷، این نیز یک ایده خوب است که که از هر دسته تعریف شده در یک بازره زمانی خاص گزارش گیری نمایید. این می تواند نوع خطاهای مربوط به انواع مشکلات را با هم مرتبط کند. حتی می تواند برای کمک به مسیریابی خودکار رخواست ها مورد استفاده قرار گیرد.
قانون شماره ۹
سعی کنید از نام های فروشندگان و سرویس دهنده های خاص دور بمانید. معمولا یک خدمت نظیر" ایمیل" در بلند مدت و در چشم اندازهای آینده سازمان مرسوم و رایج باقی می ماند اما، هیچ تضمینی وجود ندارد که در چند سال آینده آن فروشنده وجود داشته باشد. یا اینکه ممکن است در بلندمدت سرویس این فروشنده جایگزین دیگری شود پس بجاری استفاده از دسته بندی با عنوان "ایمیل مایکروسافت" از عنوان "سرویس ایمیل" استفاده نمایید چراکه فروشنده ها می آیند و می روند، و استفاده از نام آنها، سبب تغییرات دسته بندی ها می شود که در آینده کاربران و شما را با داده کاوی و گزارشگیری با مشکل روبرو خواهد کرد.
قانون شماره ۱۰
همیشه نتیجه نهایی را در ذهن داشته باشید - گزارش دهی و معیارسنجی! شاید هم حتی کمی مسیریابی باشد. بنابراین بدنیال طرح بهترین عناوین باشید، اما در طول سفر پیاده سازی ITIL فراموش نکنید که این تلاش شما برای کمک به شفافیت در سازمان است.
نتیجه گیری
طبقه بندی خدمات قابل ارایه توسط واحد فناوری اطلاعات و یا هر مرکز ارایه کننده خدمات سبب دسترسی سریع کاربران برای طرح رخداد خواهد شد و این طبقه بندی هر چقدر شفاف تری، سده تر، قابل فهم تر و عمومی تر باشد علاوه بر اینکه از سردرگمی کاربران جلوگیری کرده اید باعث دریافت بهترین گزارشات و همچنین امکان گسترش موضوعات و آیتم ها در آینده بدون اعمال تغییرات در طبقه بندی فعلی خواهد شد.
پس این را به گیجی و کم سوادی کاربران بسط ندهید کاربران کاملا بصورت شرطی روال و پروسه هایی که شما ایجاد می کنید را حتی اگر به واقع از آن اطلاع دقیقی هم نداشته باشند اما مو به مو یاد می گیرند و انجام می دهند پس با ایجاد یک طبقه بندی جذاب، ساده و شفاف، از گیج شدن آنها در مواجه با ابزار سرویس دسک جلوگیری کنید.
درج دقیق دسته بندی ها در روند تشخیص، تجزیه و تحلیل دلیل ریشه ای مشکل، توسعه و گسترش آن در آینده برای ایجاد ارزش، کلید موفقیت شما در پیاده سازی سرویس دسک است – پس بدون فشار پس از آن! به یاد داشته باشید این نوشته هم ممکن است لزوما مناسب سازمان شما نباشد بلکه از آن صرفا به عنوان راهنمایی در نظر بگیرید،
نظرات خود را حتما قید فرمایید.
[…] این بحث در لینک زیر وجود دارد http://servicedesk.medanet.ir/services-categorization/ .u79cf6862079803747ecae52ee803760f { padding:0px; margin: 0; padding-top:1em!important; […]