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

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

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

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

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

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

مشکل کجاست؟

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

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

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

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

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

مدیریت کامل حوادث در ITSM

بهترین تمرینات برای حل موثر حوادث مهم در فناوری اطلاعات و ارتباطات

اگر مدیر انفورماتیک سازمانی هستید تشخیص اینکه چه حادثه ای بزرگ است و چه حادثه ای کوچک؟ و یا کدام اتفاق مهم است و چه اتفاقی عادی!؟ نیازمند بررسی موردی و تحقیقات پیرامونی بسیاری است همین بررسی موردی و تحقیقات پیرامونی بی تردید زمانبر خواهد بود شما با شناسایی سرویس ها و خدمات موثر و کلیدی سازمان براحتی از روی تاثیر حوادث بر کسب و کار به اهمیت و بزرگی آن پی خواهید برد و نیازی به بررسی دقیق تر برای تشخیص بزرگی هر حادثه ای ندارید مثلا از کار افتادن ماوس یک کاربر تاثیر آنچنانی روی کسب و کار سازمان نمی گذارد اما اگر وب سایت یا تنها درگاه ارتباط با مشتری سازمان از کار بیافتد یعنی فاجعه! محسوب می شود پس بنابراین پرداختن به حوادث مهم امری کلیدی در مدیریت حوادث[۱] است.

حوادث مهم، تنش زا هستند. اکثر حوادث مهم ناشی از سلسله تغییرات ناآگاهانه قبلی است! و گاهی نیز برای بار نخست است که اتفاق می افتد. بنابراین بزرگی یا مهم بودن یک حادثه به تأثیر آن بر روی کسب و کار باز می گردد.

اگرچه هر حادثه ای کوچکی و گاهاً به ظاهر کم اهمیت هم می تواند به سرعت یک تنش بسیار بزرگی را به دنبال داشته باشد. در جهان فناوری نیز یک حادثه یا وقفه ای چند لحظه ای می تواند کل عملکرد یک سازمان را زیر سوال ببرد بنابراین تمامی حوادثی که در روز در سازمان رخ می دهند هر کدام می توانند فاجعه ای به بار آورند و تنش زا باشند بخصوص حوادثی که به مسائل فناوری اطلاعات مربوط هستند زیرا این دست از حوادث مستقیما بر روند عملیات و نتایج تجاری هر کسب و کاری تأثیر منفی می گذارد. ITIL 4 این دست از حوادث را به عنوان “حادثه ای با تاثیر قابل توجه در کسب و کار، که نیاز به یک راه حل فوری دارد” تعریف می کند.

خیلی از تأثیراتی که بر کسب و کار احساس می شوند علاوه بر بار حیثیتی، بار مالی بهمراه دارد بنابراین حوادث مهم نه تنها دارایی های سازمان را به خطر می اندازد بلکه سبب تحمیل هزینه های بسیاری نیز خواهد کرد که یا از جیب می رود یا از آبرو!

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

در یک نمونه ظاهری در یک شرکت، بدلیل نوسان برق و عدم اتصال سیستم های کاربران برق UPS در آن واحد بیش از ۱۰۰ دستگاه پاور کیس سوخت و کل فروش آن سازمان بطور کل مختل شد!

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

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

1. حقایق را بررسی کنید!

اولین کاری که هنگام برخورد با حوادث مهم باید انجام دهید این است که مطئمن شوید که همه حقایق را دارید بررسی می کنید برای این موضوع باید فهرستی از پرسشهای کلیدی را مطرح کنید و یافته های خود را در ارتباط با حادثه رخ داده شده مستند نمایید:

• چه تاثیری بر روی کسب و کار می گذارد؟
• چه خدماتی تحت تاثیر قرار می گیرد؟
• چه گروهی از کاربران تحت تاثیر قرار می گیرند؟ آیا بخش یا مکان مشخصی است یا کل کاربران سازمان متاثر از این حادثه هستند؟
• کدام گروه کارشناسان پشتیبانی متولی رسیدگی به این حادثه هستند؟ آیا ما افراد مناسب را درگیر کرده ایم؟
• آیا همه در امنیت هستند؟ اول از همه، مراقب کاربران خود باشید و اطمینان حاصل کنید که همه از خطر احتمالی دور هستند. به ویژه اگر این حادثه مربوط به چیزی مانند سرقت اطلاعات ژنراتور، تعمیر و نگهداری UPS، و یا چاه ارت.
• آیا باید تیم های پشتیبانی دیگر را آگاه کنیم؟
• این حادثه ناشی از چه اتفاقی است آیا ناشی از یک یا مجموعه ای از فعالیت های تغییرات قبلی است؟
• آیا پیش از این راهکار یا خطا شناخته شده و مستندی داشته ایم؟
• آیا برای رسیدگی و رفع حادثه به پشتیبانی شخص ثالث (نظیر پیمانکاران) نیاز داریم؟
• آیا باید به مشتریان پیشین نیز اطلاع دهیم؟
• آیا این حادثه ناشی از نقص امنیتی است و باید سطح امنیتی را افزایش دهیم؟
• آیا سرویس میز خدمت IT قادر به مقابله با حجم فعلی تماس های مرتبط است؟
• مدت زمان بازگردانی وضعیت فعلی به حالت عادی چقدر است؟
• زمان واقعی برای به روز رسانی چه هنگامی است؟

اصول اولیه را تحت پوشش قرار دهید تا از مسله بدقت آگاهی یابید و بتوانید به همه (یا حداقل) سؤالاتی که توسط مشتری (ها) و مدیریت ارشد از شما پرسیده خواهد شد، به درستی پاسخ دهید.

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

نوشته مدیریت کامل حوادث در ITSM اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.

۵ نکته برای موفقیت شیفت به چپ در خدمات فناوری اطلاعات

اگر شما در مدیریت خدمات فناوری اطلاعات (ITSM) و مخصوصا در سرویس دسک فعالیت می کنید احتمال زیاد با مفهوم “Shift Left” یا ” شیفت به چپ” با همدیگر صحبت کرده اید. (البته با توجه به آشنایی که با اکثر افراد در انفورماتیک سازمان ها دارم کمتر کسی از این مفهوم اطلاع درستی داشت! و معمولا برنامه نویسان از این واژه استفاده می کنند) در هر صورت چه از این مفهوم استفاده کرده باشید و یا  اینکه تازه آنرا شنیده اید، این مقاله مناسب  شماست. که به بررسی دقیق و تجزیه و تحلیل چگونگی موفقیت در ارایه خدمات فناوری اطلاعات و ارتباطات با استفاده از مفهوم “شیفت به چپ” با اصطلاح عامیانه تر: “بده به عقبی!” می پردازد.

شیفت چپ یا“Shift Left” چیست!؟

“Shift Left” از مفاهیم رایج در تست نرم‌افزار است. چارچوب هایی نظیر AgileوDevOps ، استفاده  از مفهوم“شیفت چپ”را همواره برای موفقیت در تولید نرم افزار، به آزمایش کننده ها(تسترها) توصیه می‌کنند در ITIL4 نیز که همپوشانی گسترده تری برای چارچوب هایی AgileوDevOps  دیده شده، این مفهوم در کنار مدیریت خدمات انفورماتیک و سرویس دسک، رنگ و بویی تازه به خود گرفته است. برای فهم بهتر از آن به عنوان” شیفت به چپ” یاد می کنیم.

معمولا مراحل تولید یک نرم افزار ساختاری شبیه تصویر زیر خواهیم دارد:

Planning > UI Design > Implantation > Testing > Release

همانطور که می‌بینید، مرحله تست در سمت راست چرخه حیات توسعه نرم افزار است. این یعنی مرحله تست Testing تا پیش از انتشار رسمی ( Release) سدی در برابر باگ ها و اشکالات شناسایی شده در فرایندهای برنامه ریزی Planning ، طراحی UI Design و اجرا Implantation  است که باعث می شود تا اگر باگی در مرحله Testing مشاهده شد یک گام به عقب(چپ) باز گردیم، مرحله قبلی نیز در صورت عدم رفع مشکل به مرحله قبل ازخود شیفت می دهد و الی آخر… این انتقال به چپ ادامه خواهد داشت. تا پس از اصلاح در مراحل قبلی، محصول کامل تری را عرضه کنیم به این گام رو به عقب همان “Shift Left” یا شیفت به چپ می گویند.

در ITSM نیز ساختار مشابهی هست:

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

اگر ابزار پیاده سازی ITIL شما، قابلیت سلف سرویس (خود خدمتی) را در اختیار کاربر بگذارد و شما آموزش های لازم را برای کاربران در آن قرار داده باشید تا خودش به خوش کمک کند دیگر نیازی به ثبت درخواست احتمالی او از انفورماتیک نخواهد بود. اما اگر چیزی برای کمک نداشته باشد یک تیکت ثبت می کند تیکت به لایه ۱ می رسد لایه ۱ بررسی لازم را انجام می دهد اگر بتواند آنرا حل و فصل کند که هیچ! درخواست را می بندد و تمام. اما در صورت عدم توانایی حل و بستن درخواست آنرا به لایه های قبلی (چپ) منتقل خواهد کرد و الی آخر..

اغلب واحد انفورماتیک سازمان ها دارای حداقل ۳ لایه پشتیبانی هستند. در مقاله DNA پشتیبانی انفورماتیک به بررسی سطوح ارایه خدمت پرداخته بودم.

میز کار فناوری اطلاعات، (هلپ دسک) ویترین و یا خط مقدم جبهه است یعنی مرکز توجه و عملیات کار با کاربر / مشتری نهایی است. “Shift Left” هلپ دسک نقطه عطف استراتژی ITSM سازمان است که نیاز به تغییرات در افراد، فرایندها و تکنولوژی دارد “Shift Left” در هلپ دسک شامل دریافت بازخوردهای کاربران، تست و بررسی فردی یا گروهی محصولات و یا خدمات است که استفاده مکرر از این مفهوم بسیار ملموس است و با مدیریت دانش، خودآموزی و خودکارسازی(اتوماسیون) می توان در بهبود این نقطه عطف، نقش قابل توجهی ایفا کرد. اما “Shift Left” صرفا به میزکار(هلپ دسک) سرویس فناوری اطلاعات محدود نمی شود، بلکه یکی از بهترین سناریوهای  مورد استفاده در ITSM و برای تمامی بخش های فناوری اطلاعات است برای درک و توضیح چگونگی و نحوه کار آن است:

هر لایه یک سری از وظایف از پیش تعیین شده و یا بعداً تحمیل شده! را انجام می دهد مثلا: پشتیبانی برخی از کارهای لایه ۲ را می توان به لایه ۱ تغییر داد و یا بعضی از کارهای لایه ۱ می تواند تغییر کند به لایه ۰ -قابلیت خودخدمتی(سلف سرویس) فناوری اطلاعات یعنی خود کاربران دست به کار شوند و بتوانند کارهایی بکنند که دقیقا شبیه عملیاتی است که در لایه ۲ انجام می شود.

Shift-Left یک استراتژی برای سرویس دسک فناوری اطلاعات است نه یک تاکتیک!

Shift-left باید یک تلاش آگاهانه برای بهبود خدمات فناوری اطلاعات باشد تا بتوان به منظور صرفه جویی در هزینه به صورت یکپارچه از آن بهره گرفت. این یک استراتژی است که بر تعدادی از مزایای زیر متمرکز شده است، از جمله:

• حل و فصل سریعتر حوادث و درخواست خدمات
• کاهش هزینه ها
• استفاده بهتر از دانش فنی و توانایی های کمیاب
• ارائه یک تجربه بهتر در مورد کاربر / مشتری

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

هر مفهومی باید ابتدا، فرهنگ سازی و پیاده سازی شود تا بتوان از آن بهره برداری و مزایای آنرا درو کرد!

 به عنوان مثال، ایجاد قابلیت خودخدمتی در فناوری اطلاعات که برای صرفه جویی در هزینه طراحی شده و تحویل داده می شود، به احتمال زیاد به اندازه کافی توسط کاربران مورد استفاده قرار نخواهد گرفت بنابراین نیل به مزایای معنوی و مادی مفهوم “Shift Left” در دنیای واقعی و با انتظارات و عملیات پشتیبانی فناوری اطلاعات ممکن است به سادگی میسر نشود! این یعنی صرفاً داشتن یک ابزار (مقاله احمق با یک ابزار هنوز احمق است را بخوانید) نمی توان به نتایج مطلوب رسید اولین قدم، بررسی هزینه هاست شما با درک هزینه واحد پشتیبانی فناوری اطلاعات و فرهنگ سازی بین بخش ها و سازمان می توانید “Shift Left” را به کار ببرید تا با آن تفاوت قابل توجهی را در عملیات پشتیبانی ITSM و IT داشته باشید. به طور خاص، در هزینه واحد! به عنوان مثال هزینه طرح و رسیدگی به هر تیکت (درخواست)کاربر نهایی/مشتری در سال ۲۰۱۷، طبق آمار شرکت MetricNet به شرح زیر است:

هزینه پشتیبانی لایه ۰ حدود ۱۰% کمتر از هزینه های لایه ۱ است.

بنابراین به ترتیب:

لایه ۰ :

• هزینه سلف سرویس: ۲ دلار در هر درخواست

لایه ۱ :

• هزینه میزخدمت:۲۲  دلار در هر درخواست

لایه ۲:

• هزینه پشتیبانی از دسک تاپ: ۶۹ دلار در هر درخواست
• هزینه پشتیبانی از IT سازمان: ۱۰۴ دلار در هر درخواست

لایه ۳:

• هزینه پشتیبانی پیمانکار/فروشنده: ۵۹۹ دلار در هر درخواست

بنابراین، برای کاهش هزینه ها هرچقدر تیکت های کاربران به سمت چپ، شیفت داده شود(منتقل گردد)  هزینه تمام شده ارزان تر از آن است که بخواهیم آنها را حل کنیم. و یا مقرراتی و محدودیت های دست و پا گیری برای کاربران اما در نهایت علیه خود اعمال کنیم!

عناصر کلیدی موفقیت شیفت به چپ

موفقیت شیفت به چپ وابسته به ۴ توانایی اصلی است:

1. مدیریت تغییر سازمان (OCM). برای “Shift Left”باید تغییری در شیوه های کار سنتی و نحوه مدیریت افراد و تفکر فعلی آنها در فرایند ارایه خدمت داد.
2. فناوری اطلاعات خودآموزی. سلف سرویس، قابلیت خودکارآمدی مناسب است که مهمترین سازوکار تعامل با مشتری برای ارائه مزایای “شیفت به چپ” است. هرچند که این امر بدون در نظر گرفتن عناصر بعدی (مدیریت دانش و توانایی اتوماسیون) هم امکان پذیر است.
3. مدیریت دانش. در دسترس بودن مقالات شناخته شده برای مقاصد و پرسش های متداول یک عامل کلیدی برای برنده شدن از طریق راهنماهای آموزشی(خودآموز IT ) است و در نتیجه پشتیبانی در همان لایه ۰ تثبیت شده باقی می ماند.
4. اتوماسیون. حذف روش های تکراری و دستی، استفاده از ابزار مناسب در ارائه مزایای مربوط به هر دو افزایش سرعت حل و فصل / و کاهش هزینه و همچنین، تجربه مشتری موثر است

بنابراین، استراتژی “چپ شیفت”  یا شیفت به چپ، روشی عالی است،

موانع فعالیت شیفت به چپ

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

ابتکار مدیریت دانش از مانع فوق نیز رنج می برد اگر از آن به عنوان یک پروژه تکنولوژیک بجای تغییر سازمان یاد کنید موانع زیادی برای عدم موفقیت مدیریت دانش شکل می گیرد که مهمترین آن:

به اشتراک گذاری دانش برای یک کسب و کار مرسوم  Business-as-usual (BAU) است.

«کسب و کارِ مرسوم» (Business as usual) به وضعیتی گفته می‌شود که یک سازمان مطابق رویه‌های بومی و مرسوم خود به فعالیت ادامه می‌دهد یعنی علیرغم وجود راهکار و یا حتی فراهم بودن بستر مورد نظر، باز نمی خواهد تن به تغییر وضعیت جدید بدهد!

«کسب و کارِ مرسوم» (Business as usual)
به وضعیتی گفته می‌شود که یک سازمان مطابق رویه‌های بومی و مرسوم خود به فعالیت ادامه می‌دهد یعنی علیرغم وجود راهکار و یا حتی فراهم بودن بستر مورد نظر، باز نمی خواهد تن به تغییر و پذیرفتن وضعیت جدید بدهد!
از این اصطلاح اغلب برای توضیح وضعیت غیرعادی در سازمان ها استفاده می‌شود که یعنی آن سازمان برای جلوگیری از وقوع عوارض منفی نیازمند اتخاذ رویه‌های خلاقانه جدید و تغییر مسیر است، اما متاسفانه بجای آن تصمیم می‌گیرد به رویه مرسوم خود ادامه دهد و تغییر مسیر ندهد و به عبارتی کسب و کارش را همین شکلی که هست ادامه می دهد. این فرایند مرسوم معمولا از مراتب سازمانی بالا بیشتر پایداری خود را حفظ می کنند یعنی مدیران جز، میانی و ارشد بیشتر متمایل به طی کردن فرایندهای مرسوم هستند و تغییرات در لایه های زیرین پرسنل چشمگیرتر است اما در هر صورت در سازمان اگر قدرت لازم برای تغییر، گرفته نشود، BAU به سراغ آنها خواهند آمد، مثلا: هر روز حملات زیادی به شبکه و سرورهای سازمان وارد می شود و سازمان مرتباً از شرکت های ارایه کننده خدمات امنیتی، راهکار می خواهد، اما با اطلاع از وجود و دریافت راهکار، مدیران این سازمان به گونه ای دیگر رفتار می کنند، آن‌ها کما فی‌السابق سیاست‌های پرهزینه قبلی را دنبال می‌کنند. انگار نه انگار که راهکاری ارایه شده، باز هم به «کسب و کارِ مرسوم» خود ادامه می دهند.
مثلا هشدارهای امنیتی و باگ هایی که نادیده گرفته می شوند و در نهایت سبب نشت اطلاعات می شود نمونه ای از این تفکر BAU در سازمان هاست. یا در مورد خرید تمام ابزارهای مدیریتی و حتی ابزارهای پیاده سازی ITIL باز، همان روال سابق را دنبال می کند….
پس اگر سازمان شما در قبال راهکارها و تغییر رویه ها، وضعیت خود را از حالتی که هست تغییر ندهد بدانید که آن سازمان مبتلا به عارضه “رویه های مرسوم” شده و این سازمان، یک سازمان غیرعادی است! که البته در ایران به وفور یافت می شود…

فکرش را بکنید شما می خواهید مدیریت دانش را در چنین سازمان هایی پیاده کنید! پس برای جا انداختن و فرهنگ سازی و رفع این مانع خطرناک، به رسمیت شناختن این که ارزش به اشتراک گذاری دانش و استفاده از دانش است، نه گرفتن و ذخیره سازی دانش!

شما می توانید اطلاعات بیشتری در مورد مدیریت دانش در اینجا بخوانید.

پنج راه موفقیت استفاده از مفهوم شیفت به چپ در ITSM

موفقیت استفاده از مفهوم شیفت به چپ، وابسته به رفع موانع آن است:

1. در مدیریت تغییرات سازمانی سرمایه گذاری کنید زیرا با آن نه تنها برای ایجاد تغییرات ضروری افراد، بلکه به بررسی
نحوه ارزیابی، شناخت و پاداش عملکرد فرد و تیم هم می توانید بپردازید.

این کمک خواهد کرد تا اطمینان حاصل شود که افراد برای تغییر و همچنین حذف یکی از بزرگترین مسائل مربوط به  OCM (مدیریت تغییرات سازمانی)- ترس از ناشناخته است. بدون این، سازمان شما تلاش می کند تا راه های جدیدی از کار مرتبط با مدیریت دانش، خودآموزی و بهره برداری از اتوماسیون را اتخاذ کند.

2. مدیریت دانش را به یک فعالیت مرسوم در کسب و کار مرسوم! BAU تبدیل کنید تا بطور رایج در عملیات روزمره استفاده شود.

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

3. برای بهره برداری، جذب و ذخیره دانش از روش های شناخته شده مدیریت دانش و تکنیک هایی مانند خدمات دانش محور (KCS) و Level Zero Solvable (LZS) استفاده کنید.

این باعث می شود که از “اختراع دوباره چرخ” جلوگیری شود و همچنین این اطمینان به دست می آید که سازمان شما از موفقیت ها و اشتباهات کسانی که در مدیریت دانش (و خودآموزی) قبل از آنها موفق بوده اند بهره مند است.

4. روی خواسته ها و نیازهای کاربران تمرکز کنید، نه بر ویژگی های فن آوری موجود.

برآورده سازی انتظارات کلید توقع و رضایت کاربران است، سیستمی کردن هر چیزی دال بر رفع نیازهای مشتری نیست! مدیریت دانش، خودآموزی، سلف سرویس و اتوماسیون کاربرد دارد. اما اینها نیست که به آنها کمک می کند، افراد به احتمال زیاد از قابلیت هایی استفاده می کنند که زندگی آنها را ساده تر می کند یا تجربه ای بهتر یا ارزش بیشتری را به آنها ارائه می کند. بنابراین با درک خواسته ها و نیازهای کاربران نهایی / مشتریان راه حل های انسانی مطابق با نیازهای آنها و مبتنی بر تکنولوژی ارایه کنید!

5. سازگاری با توانایی های مصرف کننده از لحاظ سهولت استفاده و آنچه که می توان به دست آورد.

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

نتیجه گیری:

احتمال زیاد بارها مفهوم “Shift Left” را استفاده کرده اید بی آنکه دقیقا از وجود و ماهیت و معنای آن اطلاعی داشته باشید.

فرهنگ سازی تغییر تفکر، فرایندهای مرسوم BAU را آرام آرام جا بندازید.

این مفهوم کمک می کند پیش از ارایه یک سرویس به کاربر، تمامی ارزیابی ها و تست ها و تجربه کاربری در لایه های بالایی (چپ) انجام شود تا از نرخ خرابی ها و ترافیک درخواست های ناخواسته خودداری شود.

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

موفقیت استفاده از “Shift Left” وابسته به تفکر پاس دادن به هم نیست بلکه اجرای موفق تست ها در حیطه وظایف و حدود دسترسی تعریف شده برای هر تیم/کارشناس است!

آیا با استفاده از ابزار پیاده سازی ITIL (سرویس دسک) سازمان شما با موفقیت توانسته “شیفت به چپ” کند؟ اگر نه چرا و چه برنامه ریزیی در این خصوص می کنید؟ لطفا در کامنت ها مرا در جریان بگذارید.

با سپاس / هادی احمدی

نوشته شیفت به چپ در انفورماتیک! اولین بار در سرویس دسک پلاس فارسی مدانت. پدیدار شد.