رادیو مشتری- قسمت دهم – آقای مهندس درخشی(میز خدمت)

دانلود دهمین قسمت رادیو مشتری

راه اندازی میز خدمت

در قسمت دهم رادیو مشتری با جناب آقای مهندس درخشی ، متخصص مدیریت خدمات بروی ITIL ، گفتگویی جذاب داشته ام.

این گفتگو با عنوان راه اندازی میز خدمت انجام شده است و پیشنهاد می کنم به هیچ عنوان این قسمت را از دست ندهید.

باتوجه به تجربیات ارزشمند ایشان در خصوص راه اندازی Service Desk شرکت بزرگ بیمه ایران ، به ارائه مباحث تخصصی در این زمینه پرداخته ایم.

• معرفی فریمورک ITIL
• راه اندازی میز خدمت در سازمانها
• نرم افزارهای مورد نیاز
• نکات مهم در ITIL

هدف رادیو مشتری گفتگو با متخصصین و صاحبین کسب و کارهای ایرانی در حوزه مدیریت ارتباط با مشتری است، گفتگویی راحت و خودمانی…

رادیو مشتری را دنبال کنید و منتظر گفتگوهای بعدی باشید

خوشحال خواهیم شد تا نظرات خود را نیز با ما به اشتراک بگذارید

تمایل دارید با چه افرادی گفتگو داشته باشیم؟

متن گفتگوی رادیو مشتری قسمت دهم (میز خدمت)

آقای حمید حاتم طهرانی:

سلام عرض می­کنم خدمت دوستان عزیز، حمید حاتم­ طهرانی هستم و با قسمتی دیگر از رادیو مشتری در خدمت شما هستیم.

امروز در خدمت جناب آقای مهندس درخشی هستم، از ایشان خواهش می­کنم که خودشان را معرفی کنند تا بعد از آن من سوالات خودم را از ایشان بپرسم. جناب مهندس خیلی خوش آمدید و خیلی متشکرم از اینکه دعوت بنده را پذیرفتید.

آقای درخشی:

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

در حوزه­ ی تخصصی، بنده متخصص مدیریت خدمات هستم و در زمینه­ ی مدیریتِ پروژه هم برروی چارچوب پی­ ام باک تسلط کامل دارم. در خدمتتان هستم.

آقای حمید حاتم طهرانی:

متشکرم، توضیحی در ابتدای ماجرا بدهم راجع به اینکه هدف ما از این گفت­ وگو چیست. ما می­خواهیم در حوزه­ ی راه ­اندازی Service desk (میزخدمت) با هم صحبتی داشته باشیم و ببینیم که این سرویس به چه قدم­ها و استانداردهایی نیاز دارد و من اگر بخواهم در سازمان خودم یک میز خدمت را راه ­اندازی کنم، باید به چه نکاتی دقت کنم.

جناب­عالی مدیر پروژه­ های مختلف هستید و در حال حاضر هم در بیمه ایران مشغول به فعالیت هستید، می­ خواستم بدانم که تجربه ­ی شما در زمینه راه ­اندازی این میزخدمت­ ها چیست؟

و اینکه شما چطور توانستید میز خدمت را به بهترین شکل در بیمه­ ی ایران استقرار دهید و چه خروجی ­هایی از آن گرفته ­اید؟

آقای درخشی:

بله همانطور که فرمودید، تخصص اصلیِ من توزیع مدیریت خدمات است و Service desk یا همان میز خدمت به عنوان یکی از اجبارهای پیاده سازیِ مدیریت خدمات در هر سازمان می­باشد.

ما در کل دنیا برای پیاده­ کردن Service desk از چارچوب ITIL بهره می­بریم. در ورژن سه ITIL، ۲۵ فرآیند و ۴ واحد یا Function ارائه شده است که می­توانیم به آن­ها به عنوانِ یک نقطه­ ی مرجع نگاه کنیم و از آن­ها استفاده کنیم.

بحث ITIL به عنوانِ کتاب­خانه­ ی زیرساخت فناوری اطلاعات، بر روی خدمات آی تی می­باشد. ولی با توجه به این­که خودِ ITIL، Frame work است و با شخصی­ سازی کردن می­توانیم از آن استفاده کنیم، من این Frame work را در زمینه­ ی Service management استفاده کردم و آن چه که می­توانم خدمت شما عرض کنم این است که این چارچوب فقط زمینه­ ی سرویس را کار می­کند و Product را پشتیبانی نمی­کند.

در شرکت بیمه­ ی ایران ما برنامه ریزیِ یک Service desk را از اواخر سال ۸۸ و مقدماتِ شروع آن را از ابتدای سال ۸۹ شروع کردیم و آن را در ابتدا به عنوان میزخدمتِ آی تیِ سازمان مورد استفاده قرار دادیم.

بعداً با توجه به این که خدمات این میز خدمت در خصوص آی تیِ سازمان قابل توجه بود، از من خواسته شد که این Service desk را به کلِ کسب­ وکار شرکت تعمیم دهم. در حال حاضر که حدود ۱۰ سال از این ماجرا می ­گذرد، ما در Service desk بیمه ایران روزانه در حدود ۱۰۰۰ تماس و درخواست را پاسخ می­دهیم و می­توان گفت که خدمات را مدیریت می­­کنیم و تنها بحثِ پاسخ­گویی مطرح نیست.

آقای حمید حاتم طهرانی:

موضوعی که وجود دارد این است که برای انتخاب نرم ­افزار در حوزه­ ی آی­تی باید به چه عواملی دقت کنیم؟

یک بخش مدیریت­ تماس­ها است و بخش دیگر مدیریت درخواست­های مشتریان؛ این دو را چگونه باید با هم همگام­ سازی کنیم و چگونه بین آن­ها ارتباط برقرار کنیم؟ و برای انتخاب یک نرم­ افزار مناسب در این زمینه باید به چه مواردی دقت کنیم؟

آقای درخشی:

به نکته­ ی قابل توجهی اشاره کردید، اما قبل از این که من به سوال شما پاسخ بدهم، می­خواهم این نکته را خدمت شما عرض کنم که نرم ­افزار، درون هر Service desk لزوماً نیاز نیست.

شما می­توانید که فرآیندهای ITIL یا فرآیندهای داخل واحدی فانکشنِ Service desk خودتان را طراحی و استفاده کنید، بعداً اگر لازم بود که قطعاً در سازمان­های بزرگ لازم خواهد شد، برای اتومات کردن این فرآیندها از نرم ­افزار استفاده کنید.

خیلی از سازمان­ها در ابتدا به فکر خرید نرم­ افزار می­افتند بدون اینکه فرآیندهایشان را شناسایی کنند یا اینکه در حوزه­ ی فرآیندی Best practiceها را پیاده­ سازی کنند، و چون نرم ­افزارها در این حوزه غالباً فرآیندی و غول ­پیکر هستند، وقتی که نرم­ افزار را تهیه کردند در کار پیاده­ سازیِ آن خواهند ماند.

برای پیاده­ سازیِ یک Service desk باید اول به این نکته توجه داشته باشیم که این Service desk  خدماتی را که به صورت متمرکز و یک­پارچه از سازمان ارائه می­شوند می­تواند پشتیبانی کند و خدمات غیرمتمرکز که در سراسر کشور ارائه می­شوند را نمی­تواند مدیریت کند.

نکته بعد این است که زمانی که قرار است خدمات ارائه شود، Service desk باید یک توپولوژی خاص را دارا باشد. همانطور که ITIL بیان می­کند، توپولوژی­ های مختلفی در زمینه ­ی انتخاب یک Service desk وجود دارند.

یکی از این توپولوژی­ها از دیدگاهِ نوعِ Service desk هست که آیا این Service desk مثلاً به صورت ۲۴ ساعته باشد، متمرکز یا غیرمتمرکز باشد، استانی یا منطقه ای باشد یا اینکه به صورت مرکزی که می­تواند تهران باشد، استفاده کند.

هرکدام از این توپولوژ­ی­ها مزایا و معایبی دارند که باید به آن­ها توجه داشته باشیم. نکته دوم این­که باید بتوانند سطوح مختلف میز خدمت را شناسایی کنند. خودِ Service Desk از دیدگاه ITIL، سطحِ اول تماس و مواجهه با مشتری است که می­تواند درجه ­ی خبرگی داشته باشد و این درجه می­تواند سطح ۳۰، ۵۰ یا ۷۰ درصد داشته باشد و بیشتر از ۷۰ درصد را پیشنهاد نمی­کند.

ولی این مراتب با فرهنگ داخل کشور ما تا حدودی هم­خوانی ندارد. ما در داخل کشور با متخصصینی در این زمینه مواجه هستیم که معمولاً هوش بالایی دارند و تمایل دارند که تمامی سرویس­ها را یاد گرفته و به کمتر از آن قانع نمی­شوند، ولی پیشنهادِ خودِ Best practice این است که حداکثر از ۷۰ درصد درجه­ ی خبرگی استفاده شود.

این دلایل مختلفی دارد که یکی از آن دلایل می­تواند این باشد که حل یک مساله تخصصی زمان زیادی را از میزخدمت طلب می­کند و مطمئناً مشتریان دیگری پشت خط خواهند ماند.

می­تواند سطوح دیگری مثل ارجاع را داشته باشد. ارجاع به معنی اضافه کردن خطوطِ منابع از سطح بالاتر به سطح پایین­ تر است. یعنی در مواقعی که Service desk تشخیص می­دهد، افرادی متخصص ­تر از سطح اول که در سطح دوم نشسته ­اند، میتوانند به سطح اول اضافه شوند و ارائه خدمت کنند و در کار مدیریت خدمت مشارکت داشته باشند.

می­تواند سطوح سوم، چهارم یا بالاتر را هم داشته باشد، بسته به این که ما از چه سرویسی استفاده می­ کنیم. بعد از این نکات قطعاً باید فرهنگ مشتریان را در نظر بگیریم؛ فرهنگ مشتریان ما به طور حتمی در توپولوژی و سطح بندیِ Service desk مهم است.

می­دانیم که کشور ما از فرهنگ، قوم­ها و گویش­ های مختلفی تشکیل شده است که اگر ما بتوانیم چندین Service desk در داخل کشور داشته باشیم، مزایای بیشتری خواهد داشت. البته داشتن چندین Service desk معایبی مثل هزینه ­ی بالاتر و یا مدیریت سخت­ تر هم خواهد داشت . این­ها نکاتی بودند که ما باید به آن­ها توجه کنیم.

چون هدف عمده­ای که ما از پیاده­ سازیِ یک Service desk داریم، بیشتر رضایت مشتری است نه رضایت­مندیِ کارکنان، بنابراین ما حتماً باید به آنچه که مشتری می­خواهد توجه داشته باشیم و نکته­ ی آخری که در پیاده سازیِ Service desk باید به آن توجه داشته باشیم، فرآیندهای داخلیِ خود Service desk هستند.

فرآیندهای داخلی هیچ مبنایی در هیچ Frame work ندارد، ما می­توانیم با استفاده از علوم مختلف مثل علوم ارتباطات برای ایجاد ارتباط با مشتریان استفاده کنیم، فرآیندهای ارجاع داخلی ­مان به چه شکل باید باشد و یا اینکه آنالیز فرآیندهایمان باید به چه شکل باشد؛

این­ها همه مواردی بودند که ما باید در داخل Service desk خودمان حتماً رعایت کنیم تا بتوانیم یک میزخدمت مناسب و آنچه که مشتری می­خواهد را محقق کنیم.

آقای حمید حاتم طهرانی:

ممنون از توضیحات خوبتان که بیشتر در حوزه­ ی استقرار میزخدمت بودند. اما در حوزه­ ی انتخاب نرم­ افزار برای شرکت­ های بزرگ چه پیشنهادی را دارید تا به چه صورت این کار را انجام دهند؟من در زمینه نرم افزار crm مقاله ای را در سایت درج کرده ام

سازمان­های کوچک چکار کنند و میزخدمت را چگونه برای خود راه ­اندازی کنند تا بتوانند بهترین بهره را از این موضوع بگیرند؟

همیشه تماس­ها برای سازمان­های مختلف حائز اهمیت بوده­اند تا بتوانند خدمات مد نظر مشتری را به او ارائه کنند. نظر تخصصیِ شما در این زمینه چیست؟

آقای درخشی:

صرف نظر از اینکه چه نرم ­افزارهایی در داخل مرکز تماس لازم هستند که برای هر سازمان می­تواند متفاوت باشد، دو نرم ­افزار یا ابزار برای هر Service desk لازم است. یکی از آن­ها نرم­ افزار مدیریت تماس است، البته تماس نه به معنای تلفن بلکه تماس با کانال­های مختلف از قبیلِ تلفن، فکس، ایمیل، پیامک، شبکه­ های اجتماعی یا انواع موبایل اپلیکیشن­ها.

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

برای Service desk قوی در یک سازمان بزرگ، باید هر دو نرم­ افزار را تهیه کرد و به نحوی این دو نرم ­افزار را با استفاده از پروتکل­هایی که یکدیگر را می­پذیرند، به یک­دیگر مرتبط کرد.

پیشنهاد من برای موفقیت در سازمان این است که پیش از خرید نرم ­افزار، کلیه­ ی فرآیند­ها، شناسایی و پیاده­ سازی شوند و بعد از آن به دنبال تهیه نرم ­افزار برویم تا بتوانیم یک نرم­ افزار مناسب را خریداری کنیم.

صرف نظر از اینکه در داخل کشور نرم­ افزارهای بسیار متنوعی در این زمینه وجود دارند، مرجعی رسمی در کل دنیا وجود دارد که این نرم­ افزارها را درجه­ بندی و رتبه ­بندی می­کند و فرآیندهای مختلف آن را تایید می­کند.

پس نرم ­افزارها را باید از حیث این مرجع، به نرم ­افزارهای تایید شده از نظر فرآیندی تقسیم بندی کرد، اما متاسفانه در داخل کشور ایران هیچ­گونه نرم­ا فزاری را نداریم که توسط این مرجع تایید شده باشد. در خصوص نرم­ افزارهای موجود در کل دنیا، نرم­ افزارهای بسیار متنوعی وجود دارند که معمولاً نسبت به تخصص آن­ها می­ توانیم آن­ها را تقسیم ­بندی کنیم ولی آنچه که best practice هم پیشنهاد می­کند این است که سازمان­ها زمانی که در شروع کار خود قرار دارند، برمبنای رویکردی که دارند سراغ پیاده ­سازیِ فرآیندهای خاصی بروند و تمام فرآیندهای best practice را پیاده سازی نکنند بلکه فقط آن فرآیندهایی که نیاز به پیاده­ سازی دارند را راه­ اندازی کنند.

پس در مرحله اول ما باید ببینیم که می­خواهیم چه فرآیند­هایی را پیاده­ سازی کنیم، در مرحله بعد به سراغ نرم ­افزارهایی که این فرآیندها را به ما پشتیبانی می­دهند، برویم و بعد ببینیم که این فرآیندها توسط آن مرجع تایید می­شوند یا نه.

به عنوان مثال نرم ­افزار management engine service desk plus یک نرم ­افزار بسیار محبوب است و این نرم­ افزار مخصوصاً در حوزه­ ی ریپورتینگ­ بسیار کامل است که در رابطه با مدیریت خدمت این قابلیت بسیار حائز اهمیت است.

اما فقطincident management (مدیریت رویداد) این نرم ­افزار در نسخه­ ی ۹ به بالا، مورد تایید آن مرجعِ گفته­ شده می­باشد. با این­که فرآیند این نرم ­افزار در نسخه­ های پایین هم با تقریب خوبی نزدیک به ITIL بود اما خود مرجع این نرم­ افزار را تایید نکرد.

این­ها نکاتی هستند که ما باید به آن­ها توجه کنیم. اینکه تصمیم به پیاده­ سازیِ چه فرآیندهایی داریم، چه رویکردی با پیاده­ سازی این میز خدمت در سازمان خواهیم داشت و می­خواهیم که چه اهدافی را محقق کنیم، بر مبنای تمام این موارد نرم­ افزاری را انتخاب کنیم که مرجع هم آن را تایید می­کند.

آقای حمید حاتم طهرانی:

پس ما تا قبل از شناسایی فرآیندها، به سمت خرید نرم ­افزار نخواهیم رفت. برای شرکت­های کوچک پیشنهادتان چیست؟

آن شرکت­ها هم همین روند را پیگیری کنند یا برای انتخاب نرم ­افزار روند دیگری را داشته باشند؟

نرم ­افزارهای کوچکی هم در کشور مثل Voip، Elastix و Asterix وجود دارند. به نظر شما شرکت­های کوچک می­ توانند از این نرم ­افزارها استفاده کنند؟

آقای درخشی:

بله راهکاری که من خدمت شما ارائه کردم ویژه ­ی شرکت­های بزرگ بود. در شرکت­های کوچک بحث هزینه خیلی اهمیت دارد.

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

از نظر تکنیکال هم با توجه به سرورها و سیستم عاملی را که دارند، برای رفع مشکلات احتمالی و یا پیکربندی نیاز به متخصصینی دارد که قطعاً هزینه­ های بالایی را طلب خواهند کرد. شرکت­های کوچک، ابتدا باید رویکرد خودشان را از پیاده­ سازیِ میز خدمت مشخص کنند.

کتب مرجعِ ITIL یک دستوالعمل کمکی را به شما ارائه می­کنند که در آن رویکردهای مختلفی را عنوان می­کند. اگر ما رویکرد Service support یا هر رویکرد دیگری را که داشته باشیم، تعدادی از فرآیندهای خاص را برای پیاده­ سازی پیشنهاد می­کند که بر مبنای ارزش­ افزوده ­ای که دارد، می­تواند تمام یا بخشی از آن فرآیندها را پیاده­ سازی کند و برطبق آن یک نرم ­افزار تهیه کند.

برای شرکت­های کوچک نرم­ افزارهای قفل شکسته ­ای مثل همان نرم­ افزارهایی که نام بردید وجود دارند که می­توانند با هزینه­ های بسیار ناچیزی تهیه شوند. در زمینه­ ی مدیریت خدماتشان هم آن­ها می­توانند از نرم­ افزارهای دیگری استفاده کنند.

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

همانطور که عرض کردم اول بایستی رویکرد مشخص گردد یعنی نمی­شود نسخه ­ای واحد به تمام شرکت­های کوچک معرفی کرد.

برمبنای رویکرد، هزینه و اهداف سازمان می­توانند یک نرم ­افزار مشخص و قابل استفاده برای سازمان خودشان تهیه کنند.

آقای حمید حاتم طهرانی:

+ نکته ­ای که وجود دارد این است که در انتها ما چه خروجی­ های جذابی را می­توانیم از راه­ اندازی Service desk دریافت کنیم؟

می­خواهم بدانم که آن پایگاه دانشِ ایجاد شده هم چه کمکی به پرسنل و مجموعه می­کند و از آن چه استفاده­ هایی می­توان کرد؟

آقای درخشی:

ITIL در کتب مرجع خود جمله­ ی بسیاری زیبایی را بیان می­کند که چیزی را که نمی­توانید بسنجید، نمی­توانید کنترل کنید و چیزی را هم که نمی­توانید کنترل کنید، نخواهید توانست که مدیریتش کنید.

برای مدیریت خدمات قاعدتاً باید فرآیندهای قابل سنجش، قابل ردیابی و همینطور خدمات قابل ارزیابی از لحاظ کیفیت، خروجیِ ما باشد که ما بتوانیم برروی آن­ها کنترل و مدیریت را اعمال کنیم.

در ITIL ورژن سوم، چیزی راجع به به­ کارگیریِ همزمانِ چندین frame work، چارچوب، مدل یا استاندارد را نداریم. اما ITIL ورژن چهار که به تازگی عرضه شده است، این بحث را مطرح می­کند که برای موفقیت در حوزه­ ی مدیریتِ خدمات باید از استاندارد­ها، frame workها و مدل­ های مختلفی بهره بگیرید.

به عنوان مثال در لایه­ ی transition یا همان انتقال خدمت، قبلاً هیچ frame work ارائه نمی­کرد و فقط یک سری فرآیند بابتِ ارزیابی و تست محیط عملیاتی به ما می­داد و اینکه چه رویکردهای ارائه­ ی خدمت می­توانیم داشته باشیم.

جدیداً در ورژن ۴ پیشنهاد ITIL برای ما در فاز انتقال خدمت، Devops framework است. با اینکه در حوزه­ ی سنجش هیچ­وقت یک frame work را به شما ارائه نمی­کند، ولی ما می­دانیم که در حوزه­ ی سنجش، می­توانیم از cobit frame work استفاده کنیم و اگر بخواهیم دریافت­های استراتژیک داشته باشیم، می­توانیم از balance score card در حوزه­ ی استراتژی استفاده کنیم.

ما بعد از اینکه موفق شدی که چرخه­ ی تبدیل دیتا به اطلاعات را در سازمان پیاده­ سازی کنیم، آن­گاه می­توانیم از این چرخه استفاده کنیم بابت اینکه بتوانیم در چهار حوزه ­ای که balance score card پیشنهاد می­کند (از نظر مشتری، مالی، آموزش و …) سازمان را مورد ارزیابی قرار دهیم و سنجش انجام دهیم.

یعنی تکنیک ­هایی را که برای سنجش لازم است را آماده کنیم و این تکنیک­ ها را به یک سری شاخص­های کلیدی عملکرد تبدیل کنیم و بعد از انجام سنجش ببینیم که ما را به آن هدفی که داشته ­ایم می­رساند یا نه؛ رضایت مشتری را اندازه بگیریم، کیفیت خدمات مان را اندازه بگیریم و به آن­ها برنامه بهبود بدهیم.

پس قاعدتاً خروجیِ این­کار بایستی به ما راجع به کیفیت خدماتمان و رضایت مشتری یک برنامه ­ی بهبود بدهد و در آخر باید بتوانیم که قابلیت سنجش و دستیابی به آن هدف­هایی که تعریف کردیم را پیاده سازی کنیم.

اگر به این نکات دستیابی پیدا نکنیم، پیاده­سازیِ سرویس برای سازمان ما منفعتی نخواهد داشت و به غیر از صرف هزینه، اتفاق دیگری داخل سازمان نمی­افتد.

در رابطه با پایگاه دانش؛ خود ITIL پایگاه­های اطلاعاتی و دیتابیس­های مختلفی را دارد. یکی از این پایگاه­های اطلاعاتی، KEDB نام دارد که دومین دیتابیس از لحاظ بزرگی است.

خود ITIL جمله زیبای دیگری دارد که می­گوید: چرخ یک­بار اختراع می­شود! وقتی که چرخ برای اولین بار در دنیا اختراع شد، شرکت­های خودروسازی برای تولید ماشین جدید، هیچ­وقت به دنبال اختراع چرخ نمی­روند.

دانش در سازمان در یکی از فرآیندهای ITIL ذخیره می­شود و توسط Agentهای میزخدمات زمانی که می­خواهند درخواستی را پاسخ دهند، توسط خطوط بعدیِ تخصصی و هم اینکه توسط مشتریان مورد استفاده قرار می­ گیرد. یعنی پایگاه دانشی که به وجود می­ آید کاملاً توسط سطوح مختلف مورد استفاده قرار می­گیرد.

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

آقای حمید حاتم طهرانی:

بسیار عالی بابت توضیحات بسیار خوب شما. در انتها اگر مایلید به ما کتاب معرفی کنید. پیشنهاد می­کنید که ما برای راه ­اندازی یک میز خدمت به چه منابعی مراجعه کنیم؟

چون شرکت­های بزرگ باید به این مراحلی که شما فرمودید دقت کنند. اما آیا شرکت­های کوچک باید بر اساس چهارچوب­هایی که ITIL تعریف کرده است پیش بروند؟ یا به نکات خاصی باید دقت کنند؟

آقای درخشی:

سوال خوبی بود. اولین چیزی که باید دقت کنیم است که Service desk هیچ ارتباطی به نوع سرویس ندارد. یعنی سرویس می­تواند بیمه ­ای، بانکی، خدمات خودرویی یا هر چیز دیگری باشد.

خود ITIL پنج کتاب مرجع دارد که آن­ها را در پنج فاز مختلف مطرح می­کند. Service strategy، Service design، Service transition، Service operation و Service improvement نام این مرجع­ها است. توصیه من این است که این کتاب­ها را مورد مطالعه قرار دهید و پیشنهاد من این است که این کتاب­ها به زبان انگلیسی مورد مطالعه قرار گیرد.

چون در کتاب­های فارسی مطالبی را بر اساس برداشت شخصیِ نویسنده می­بینم که مقداری با کتب مرجع منافات دارد. مطالعه­ ی این پنج کتاب مرجع برای شرکت­های کوچک بر اساس فرآیندهایی که می­خواهند پیاده­ سازی کنند مفید خواهد بود چون هر کدام از این کتاب­ها در داخل خود فرآیندهایی دارند.

مثلاً زمانی که من در حوزه­ ی استراتژی در سازمانم وارد نشده­ ام نیازی نیست که کتاب Service strategy را مطالعه کنم اما دلیلی ندارد که با خود فکر کنم که نیازی نیست که Service strategy در داخل سازمان من پیاده­ سازی شود.

چون تفاوت میان شرکت­هایی که موفق می­شوند و شرکت­هایی که شکست می­خورند معمولاً در همان استراتژی شرکت­ها است.

سازمان­های بزرگ هم اگر بخواهند تخصصی­ تر برخورد کنند، پنج کتاب capability base وجود دارد. اگر بخواهند توزیع operation را در Service desk پیاده­ سازی کنند، کتابی به نام SOO در این زمینه وجود دارد (Service operating and offering). شرکت­هایی هم که می­خواهند به پشتیبانی از خدماتشان بپردازند؛ باید از این کتاب استفاده کنند.

کتاب­های دیگری مثل PPO، RCB و … هم وجود دارند که این شرکت­ها می­توانند از آن­ها استفاده کنند. این کتاب­ها به شما این قدرت را می­دهند که به صورت تخصصی با ماجرا برخورد کنید. مثلاً PPO به این موضوع می­پردازد که اگر شرکتی بخواهد یک پروژه­ برپایه­ ی ITIL را بگیرد، چه کاری باید انجام دهد و این موضوع را تخصصی­ تر بررسی می­کند. اما شرکت­هایی که بخواهند مراحل مقدماتیِ پیاده­ سازیِ یک میز خدمت را داشته باشند، همان ۵ کتاب مرجع برای آن­ها کافی است.

آقای حمید حاتم طهرانی:

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

آقای درخشی:

من فقط دو نکته را می­خواهم خدمت شما عرض کنم. اول باید توجه کنیم که مشتری در جامعه ­ی ما مظلوم است. بنظر من با پیاده ­سازی frame workهایی مثل ITIL یا چندین frame work مشابه دیگر، می­توانیم به استانداردی که در کل دنیا در مواجهه با مشتری وجود دارد، نزدیک شویم.

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

دوم اینکه خیلی از سازمان­ها فکر می­کنند که می­توانند پروژه­ای را به عنوان پیاده­ سازی میز خدمت تعریف کنند و شرکتی آن را برایشان انجام دهد و برود. درست است که در داخل همچین پروژه­ هایی مسائل آی­تی، مدیریتی، کسب­ وکار، نرم ­افزار، فرآیند و … وجود دارد، ولی من این نوع پروژه­ ها را نوعی تعیین فرهنگ می­ بینم.

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

ولی سعی کنیم یک قهرمان را داخل سازمان خود داشته باشیم برای پیاده ­سازیِ درست این frame workها و بحث مشتری مداری. در غیر این صورت اطمینان داشته باشید که پروژه­ ی شما موفق نخواهد بود. پس پیشنهاد من این است که به روش درون­ سپاری (ولی نه درون­سپاریِ محض) عمل کنید و تنها در این صورت موفق خواهید شد که فرهنگ سازمانتان را عوض کنید.

آقای حمید حاتم طهرانی:

ممنون از وقتی که برای گفتگوی میز خدمت گذاشتید، خدانگهدارتان.

آقای درخشی:

من هم متشکرم و امیدوارم که عرایض بنده به شما بزرگواران کمک کرده باشد. خدانگهدار.

درصورتیکه تمایل دارید در گفتگوی رادیو مشتری حضور داشته باشیدلطفا” فرم زیر را تکمیل بفرمایید