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

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

اگر شما در مدیریت خدمات فناوری اطلاعات (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

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

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

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

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

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

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

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

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

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

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

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

نتیجه گیری:

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

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

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

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

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

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

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