استفاده از کانبان در عملیات فناوری اطلاعات-بخش نهم

این مقاله، ادامه مقاله «استفاده از کانبان در عملیات فناوری اطلاعات- بخش اول» است. پیشنهاد می‌کنیم برای فهم بهتر، مطالعه را از بخش اول شروع کنید.

۵ کانبان و مدیریت خدمت فناوری اطلاعات

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

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

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

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

۵-۱  مفهوم کار در ITSM

پیش از این، انواع مختلفِ کارهایی را بررسی کردیم که متخصصان عملیات فناوری اطلاعات به صورت روزانه انجام می‌دهند. این در حالی است که ITIL دنبال کردن اقلام کاری مختلف را در طول حیات آنها (از ایجاد تا حل و فصل شدن/بستن) توصیه می‌کند، ابتکارات بهبود‌[1] که از مدیریت کار موقت به مدیریت کار سازمان‌یافته منتهی می‌شود، اغلب به صورت ابتکارات فرآیندمحور[2] یا تیم محور[3] انجام می‌شوند و به ندرت مدیریت کار در طول حیات مورد توجه قرار می‌گیرد.

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

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

۵-۲ از جایی که هستید شروع کنید و مدام پیشرفت دهید

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

یکی دیگر از دلایل واقع گرایانه برای به تاخیر انداختن محدود کردن WIP، عدم پشتیبانی ابزار است. اکثر نرم‌افزارهای ITSM موجود در بازار هنوز از تابلوهای کانبان پشتیبانی نمی‌کنند، در حالی که در چند سال گذشته پیشرفت چشمگیری داشته‌اند، قابلیت کانبان معمولاً محدود به تصویرسازی کار است و نه تنظیم محدودیت‌های WIP. ما انتظار داریم که  در آینده نزدیک تغییر کند. اکثر ابزارهایی که از تابلوی کانبان پشتیبانی کامل می‌کنند در حال حاضر از خارج از بازار سنتی ITSM می‌آیند.

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

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

۵-۳ همکاری و متحد کار کردن

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

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

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

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

۵-۴ ساده نگه دارید و برای تجربه کردن طراحی کنید

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

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

[1] از سوی دیگر، ابتکارات بهبود اغلب به عنوان «فعالیت‌های عملیاتی» در نظر گرفته می‌شوند که باید توسط بخش‌های عملیاتی برای بهبود فرآیندها و سیستم‌های داخلی تحت نظارت و کنترل آن‌ها، انجام شود. ویژگی های مشترک ابتکارات بهبود افزایش رضایت مشتری است.

[2] مدیریت مبتنی بر فرآیند یک رویکرد مدیریتی است که یک کسب و کار را به عنوان مجموعه ای از فرآیندها می بیند که برای دستیابی به نتیجه مطلوب مدیریت می شوند. فرآیندها با هدف دستیابی به چشم انداز، مأموریت و ارزش اصلی توسط سازمان مدیریت و بهبود می یابند.

[3] رویکرد تیم محور سبکی از مدیریت پروژه است که در آن همه اعضای تیم پروژه به طور مساوی مسئول کیفیت و موفقیت پروژه هستند.

ادامه دارد…

مترجمین: حمید خاتمی، شبنم ربیعی

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

منبع: axelos.com