Xass خدمتی با طعم مدیریت خدمات

چرا دنیا به سمت خدمت پیش رفته؟ چرا امروزه هر چیزی باید به شکل سرویس درآید؟ چرا برای ارائه‌ی سرویس نیازمند ITIL هستیم؟ بیشترین باری که کلمه‌ی سرویس را در زندگی بکار می‌گیرم این است که:”دهنمان سرویس شده!” این‌که چه چیزی باعث سرویس شدن دهانمان شده همان مجهولی است که بی‌ارتباط به این بحث نیست! البته این صرفاً جنبه‌ی مزاح بود اما به‌واقع سرویس بسیاربسیار در زندگی امروزی ما فراگیر شده. سرویس یا خدمت به فعالیتی گفته می‌شود که از سمتی به سمت دیگر ارائه می‌شود. در فناوری اولین بار سرویس را از کلاینت به‌عنوان سرویس‌گیرنده و از سرور به‌عنوان سرویس‌دهنده فهمیدیم. اما امروزه هر چیزی را که می‌بینیم لقب سرویس را به خود گرفته. آن‌چنان‌که برای عرضه‌ی مطلوب آن، چارچوب‌ها، استانداردها و روش‌های بسیاری نیز در سطح جهان ارائه‌شده. سرویس بر اساس عرضه و تقاضاست یعنی تا چیزی توسط سرویس‌گیرنده طلب نشود سرویس‌دهنده آن را عرضه نمی‌کند. سرویس‌گیرنده می‌تواند مردم، اشیا، حکومت و فناوری و یا هر چیز دیگری باشد و سرویس‌دهنده نیز به همین شکل. هدف از خطاب کردن هر چیزی تحت عنوان سرویس، برای خلق ارزش است. حلقه‌های درهم‌تنیده‌ی با طعم اینترنت که دنیا را به سمت سرویس پیش برده. امروزه با مفهومی بنام As a Service شاید زیاد مواجهه شده‌اید مثلاً بانکداری به‌عنوان سرویس BaaS ((Banking as a service یا فناوری اطلاعات به‌عنوان یک سرویس: ITaaS و یا دانش به‌عنوان یک خدمت :KaaS و…

XaaS یا X as Service مخفف چیزی به‌عنوان سرویس است (X به‌عنوان هر چیزی است که به شکل یک سرویس قرار است عرضه شود)، و به چیزی اشاره دارد که به یک مشتری داخلی یا خارجی، به‌عنوان یک سرویس ارائه می‌شود. ارائه‌های به‌عنوان سرویس یا XaaS نقاط پایانی را برای مشتریان/مصرف‌کنندگان فراهم می‌کنند تا با آن‌ها ارتباط برقرار کنند. داخل این سیستم‌های اغلب پیچیده، عموماً درجه بالایی از اتوماسیون داخلی وجود دارد که به‌طورکلی سطوح مختلفی از تحمل خطا و انعطاف‌پذیری را ارائه می‌دهند، تا توانایی افزایش/کاهش در داخل یا خارج شدن الزامات عملکرد بارهای کاری ارسال‌شده به سرویس توسط کاربران را فراهم کنند. تا مصرف‌کنندگان بدون نیاز به دخالت انسان، عملکردهای روزانه خود را انجام دهند. این سیستم‌ها، در حالت ایده آل برای انجام وظایف/نقش‌های خود نیاز به دخالت کمی یا بدون دخالت انسانی دارند، احتمالاً می‌توانند در صورت تقاضا تا ظرفیت کامل منابع فیزیکی خود، خدمات لازم را ارائه کنند که حسب نیاز و میزان و حجم تقاضا معمولاً از زیرساخت‌های بسیار قدرتمندی برخوردارند. خدمات XaaS صرفه‌جویی زیادی در هزینه نسبت به زیرساخت‌های سنتی ارائه‌شده توسط فروشنده، ارائه می‌کنند امروزه تقریباً هر محصولی را تحت لوای یک سرویس در نظر می‌گیرند. برای عرضه‌ی چنین سرویس‌هایی زیرساخت پیچیده لازم است که خود این زیرساخت نیز به‌عنوان سرویس مطرح است یعنی Infrastructure as a service. نمونه‌های بسیاری برای چیزی به‌عنوان خدمت در نظر گرفته‌شده که در جدول زیر مشهود است:

مدیریت این سرویس‌ها نیازمند چارچوبی است تا علاوه بر خلق ارزش خدمات آن را به‌سوی بهبود مستمر پیش ببرد و بین تمام چارچوب‌هایی که تاکنون عرضه‌شده، ITIL بهترین و موفق‌ترین چارچوب برای مدیریت آن‌ها لقب گرفته است.

هادی احمدی

نوشته Xass خدمتی با طعم مدیریت خدمات اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

گزینه‌های پیش و روی کاربران، برای حل مشکلاتشان کدامند!؟

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

۲۹٪ گفته‌اند: که ناچارند از همکار خود بپرسند!

۲۸٪ گفته‌اند: پاسخ مشکل‌اشان را در اینترنت جستجو می‌کنند.

۲۵٪ گفته‌اند: از تلفن برای ارتباط با پشتیبانی فناوری اطلاعات استفاده می‌کنند.

و تنها ۷٪ پاسخ داده‌اند که از طریق ایمیل و یا از طریق سرویس دسک (میز خدمات فناوری اطلاعات) پیگیر مشکلاتشان می‌شوند.

این خبر بدی است!

زیرا نشان می‌دهد فناوری اطلاعات علیرغم پیاده‌سازی سرویس دسک قادر نبوده جلوی ترافیک درخواست‌های سطح پایین که توسط خود کاربران قابل حل است را بگیرد.

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

به این نوع درخواست‌های سطح پایین که تاثیر چندانی در کسب و کار سازمان ندارد، درخواست راهنمایی یا بهتر بگویم درخواست سطح پایین گفته می‌شود.

جدای از اینکه فرم اعلام یک خرابی که توسط کاربر ثبت شده ناشی از یک حادثه در سرویس است یا ناآگاهی او، مدیریت راهکارها یا پایگاه دانش بعنوان یک ابزار کلیدی در اینجا حضور دارد تا جلوی بسیاری از این درخواست‌ها را بگیرد البته نه بصورت دستوری و الزامی. بلکه بصورت پیشنهادی.

متاسفانه فرایند مدیریت راهکار در ابزار میزخدمت مبتنی بر ITIL توسط فناوری اطلاعات یا نادیده گرفته می‌شود یا راهکارهایی که تولید شده، هدفمند، گویا، ساده و قابل درک نیست.

برای آنکه یک پایگاه دانش قدرتمند و محبوب مورد انتظار کاربران داشته باشیم باید به این نکات توجه کنیم:

• از مفاهیم قابل درک و فهم استفاده کنیم.
• تا جایی که ممکن است راهکار پیشنهادی را ساده‌سازی کنید.
• به ازای هر خرابی، در هنگام طراحی سرویس، راهکار متناظر را تولید نمایید.
• از ویدئو، موشن گرافیک و متن غنی Rich Text استفاده نمایید.
• راهکارها را دسته‌بندی کنید.
• کارشناسان فناوری را مجبور کنید تا فیلد نوع درخواست را که حاوی دو مقدار (رخداد و راهنمایی) هست را هنگام بستن درخواست کاربران تکمیل کنند. با این کار در بازه‌ی کوتاه‌مدتی گزارش میگیرد و از میزان حجم درخواست‌هایی که منشا راهنمایی داشتند اطمینان حاصل خواهید کرد.
• نیازی نیست که تمام راهکارها توسط تمام کاربران مشاهده شود زیرا در این حالت سبب سردرگمی و انزجار آنان می‌شود. پس با گروه‌بندی کاربران می‌توانید راهکارهایی را در اختیار آنان قرار دهید که قطعاً به آنها نیاز خواهند داشت.
• یک تیم عملیاتی برای تولید راهکارهای حرفه‌ای و ساده بر پایه تجربه‌ی کاربری تشکیل دهید.
• از کلمات کلیدی استفاده نمایید تا راهکار مرتبط با خرابی سرویس را به کاربر پیشنهاد دهد.
• با استفاده از میزان بازدید راهکارها توسط کاربران از محبوبیت و گیرایی آنها مطلع شود و برای راهکارهای کمتر دیده شده، را بازنویسی و یا علل عدم توجه کاربران به آن را جویا شوید.
• در بازه‌های زمانی به نظرسنجی و یا گزارشات حجم درخواست‌های خرابی ورودی اندازه بگیرد که میزان کارآیی راهکار چقدر بوده و چقدر توانسته جلوی ثبت درخواست‌های سطح پایین را بگیرد.
• بجای انکه شب و روز کاربران در پی چگونگی حل مشکل سپری شود و بجای آنکه کارشناسان فناوری اطلاعات وقت خود را هر روز زیر بار انبوه درخواست‌های تکراری که هیچ ارزشی را خلق نمی‌کند تلف کنند بهترست یک فرد را بعنوان مدیر راهکار استخدام یا منصوب کنید تا بر اساس خلاقیت‌های آموزشی بتواند بستری بسازد تا جلوی این حجم از درخواست‌ها را با ارایه‌ی راهکارهای منسجم و زیبا بگیرد.
• فراموش نکنید هزینه‌ی حل یک درخواست توسط خود کاربر ۱ دلار است و هزینه ثبت یک درخواست، ارجاع آن به انفورماتیک و رسیدگی و پیگیری ۹۹۵ دلار!

اگر نکات کلیدی فوق را بخوبی اجرا کنید و در صورتی‌که با استفاده از پایگاه دانش و پورتال سلف سرویس، راهکارها و راه‌حل‌های مرتبط را در اختیار کاربران قرار بگیرد اکثر درخواست خرابی‌های مطرح شده توسط خود کاربران قابل حل خواهد بود.

دقت کنید حجم بسیار کمی از درخواست‌هاست که ناشی از وقفه در کار یک سرویس است!

خُب فرض کنیم تمام نکات فوق را به نحو احسن انجام دادید در این صورت می‌توان چنین چیزی انتظار داشت:

۲۹٪ بجای آنکه ناچارند از همکار خود بپرسند، از راهکارهای موجود استفاده می‌کنند.

۲۸٪ بجای آنکه پاسخ مشکل‌اشان را در اینترنت جستجو می‌کنند، به سادگی در لیست راه‌حل‌های موجود در سرویس دسک جستجو می‌کنند.

۲۵٪ بجای آنکه از تلفن برای ارتباط با پشتیبانی فناوری اطلاعات استفاده می‌کنند، محبوب‌ترین راهکارهای پربازدید را مطالعه و مشاهده خواهند کرد.

و ۷٪ بجای آنکه از طریق سرویس دسک (میز خدمات فناوری اطلاعات) مشکلاتشان را ثبت می‌کنند، سرویس دسک در هنگام ثبت مشکل، بلافاصله بطور خودکار راهکار مرتبط با نیاز وی را به‌ او پیشنهاد می‌کند..

این هدفگذاری کاملاً قابل تحصیل است اما نه بدون یک تیم قدرتمند و خلاق برای تولید راهکارهای آموزشی!

نوشته گزینه‌های پیش و روی کاربران، برای حل مشکلاتشان کدامند!؟ اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

تنها نقطه‌ی تماس

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

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

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

و یا مثلا حضورا چیزی را پیگیری می‌کنید، یک نفر در اتاق نخست هست که شما باید کل نیازتان را برایش توضیح می‌دهد اما او اظهار بی‌اطلاعی می‌کند و شما را پاس می‌دهد به اتاق بعدی و یک نفر دیگر! و شما مجدد کل شرح‌ماوقع را به نفر دوم هم ارایه می‌کنید که می‌گوید این مربوط به من نیست و باید از فلان… پیگیری کنید و از شما می‌خواهد منتظر بمانید تا شیفت‌تان بدهد به نفر بعدی…! و این دور باطل!

این سناریو را در تمامی روش‌های ارایه خدمت نظیر: ایمیل، سامانه‌های نرم‌افزاری، شبکه‌های اجتماعی، گفتگو(چت آنلاین)، پیام‌رسان‌ها، نامه‌نگاری کاغذی، پورتال سازمانی، اپلیکیشن‌های موبایل و… تعمیم دهید، نتیجه، همان است!

مشکل کجاست؟

مشکل بی‌اطلاعی نفر اول نیست، مشکل، درگاه و یا روش ارتباط نیست! مشکل، تعدد درگاه‌ها نیست! مشکل، دقیقا ناشی از عدم وجود میزخدمت است درگاهی که مستندسازی و پیگیری صفر تا صد و پاسخگویی کامل همان نفر اول باید در آن صورت بگیرد.

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

اولین نفر پاسخگو، آخرین نفر هم خواهد بود زیرا او خوب می‌داند که کار را باید ارجاع دهد نه کاربر را!

ادامه مطلب در صفحه بعد…

نوشته تنها نقطه‌ی تماس اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.