بررسی پیاده‌سازی چارچوب ITIL در اسپاتیفای

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

اسپاتیفای یکی از بزرگترین ارائه‌دهندگان خدمات پخش و نشر موسیقی آنلاین است که افراد می‌توانند اشتراک آن را تهیه کنند. اسپاتیفای بر یک بازار دوسویه کاربر–هنرمند استوار است و بر پایه داده‌ها، تحلیل‌ها و نرم‌افزار مدیریت می‌شود.

در این مطالعه موردی، Ola Källgården نشان می‌دهد چگونه اولینگو (Olingo) شرکت سوئدی مشاوره مدیریت، به اسپاتیفای کمک کرد تا اصول ITIL را پیاده‌سازی نماید.

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

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

مقدمه

پیام اصلی اسپاتیفای سرعت است. برقراری جریان ارائه خدمات برای استفاده حداکثری از منابع بسیار مهم است. محرک اصلی این شرکت برای رقابت در بازار امروز، بهبود مستمر و ارائه خدمات با سرعت است. یا به بیان جک ولش (Jack Welch) می‌توان چنین گفت: «اگر سرعت تغییر در بیرون از سازمان از سرعت تغییر در درون سازمان فزونی بگیرد، پایان کار نزدیک است!»

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

پیشینه

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

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

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

موارد زیر بخشی از اهداف Olingo در اسپاتیفای بود:

• مدیریت جریان کاری: یافتن راهی کارآمد برای مدیریت حجم کاری تیم‌ها، شامل درخواست‌ تغییرات، رخدادها، مسائل فنی و پروژه‌ها.
• مدیریت تطابق: اطمینان از اینکه قوانین به درستی رعایت می‌شوند و با قوانین نهادهای مالی رسمی تطابق دارند.

در اسپاتیفای، کارها حول تیم‌های خودمختار و عملیاتی سازماندهی شده است. این بدان معناست که هر تیم به طور مستقل همه قابلیت‌های مورد نیاز برای به سرانجام رساندن کار را در اختیار دارد. انتقال کار از یک تیم به تیم دیگر به ندرت پیش می‌آید و حتی اگر امکان آن فراهم باشد از آن اجتناب می‌شود. هر تیم مسئول به سرانجام رساندن مأموریت خود و دستیابی به اهداف تعیین شده برای آن است؛ در عین حال آزادی عمل دارد تا کار را آن طور که مناسب هر تیم کاری است انجام دهد. تیم سیستم‌های مالی (FS) مسئولیت ارائه آن دسته از خدمات IT را برعهده دارد که توسط عملکردهای داخلی، مانند مالیات، تدارکات و حسابداری استفاده می‌شوند. وقتی Olingo کار با اسپاتیفای را شروع کرد، این خدمات روی پلتفرم برنامه‌ریزی منابع سازمانی (ERP) اجرا می‌شدند و تیم FS مسئول توسعه خدمات و همچنین بهبود و پشتیبانی تیم بود. این خدمات به شدت برای آنکه با قوانین نهادهای نظارتی مطابقت داشته باشند، تحت تاثیر قرار گرفته بودند. به علاوه، تیم FS یک چالش اساسی در این مرحله داشت و آن انتقال از ERP مستقر در شرکت به چند ERP در فضای ابری در یک بازه زمانی اندک بود. با توجه به این موانع زمانی، بیشتر افراد درگیر در این پروژه فکر می‌کردند این کار در مدت مورد نظر انجام نخواهد پذیرفت.

بسیاری از تیم‌ها در اسپاتیفای از پروژه Olingo تاثیر گرفتند، ولی برای این مطالعه موردی، ما فقط از مثال تیم سیستم‌های مالی FS استفاده می‌کنیم و از این به بعد به اختصار فقط آن را «تیم» می‌نامیم.

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

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

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

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

• بصری‌سازی حجم‌ کلی کار
• مدیریت کارهای انباشته
• هماهنگی نیازهای مشتریان داخلی
• مدیریت انواع مختلف کار.

بصری‌سازی حجم‌ کلی کار

برای آنکه مفهوم «حجم کار» مشخص شود، باید ابتدا سیستم مدیریت تیکت کنار گذاشته می‌شد. مفهوم کانبان (Kanban) و تخته کانبان (Kanban Board) در اسپاتیفای به طور گسترده مورد پذیرش بود، ولی تا آن زمان توسط تیم استفاده نشده بود. یکی از کارهایی که توسط Olingo و مربیان درون سازمان صورت پذیرفت، استفاده از کانبان به نحوی کارآمد و با تکیه بر اصول ITIL بود که به تیم کمک کرد بتواند فرآیندهای مختلف خود را اولویت‌بندی کند. نسخه اولیه بسیار ابتدایی بود، متشکل از یک وایت‌بورد قابل حمل و پرینت تیکت‌های موجود در ابزار مدیریت تیکت! ولی نظرات و بحث‌های مختلفی شکل گرفت که به پیشرفت آن کمک کرد. آیتم‌های کاری در ستون‌ها نوشته شد و هر ستون نمایانگر یک سطح از جریان کاری بود، برای مثال «برای انجام» یا «در دست اقدام». از چالش‌هایی که بلافاصله مشاهده شد، اندازه حجم کار بود. با اینکه تیم می‌دانست قسمت اعظمی از حجم کاری در سیستم مدیریت تیکت پنهان شده است، ولی در واقعیت امر، شرایط بسیار بحرانی‌تر از حد انتظار بود!

مدیریت کارهای انباشته شده

برای آنکه حجم کاری قابل مدیریت باشد، برای هر ستون محدودیت «کار در دست اقدام» (WIP) در نظر گرفته شد. محدودیت‌های WIPها یک سقف مشخصی داشت و تعداد موارد مشخصی امکان قرار گرفتن در ستون را داشتند. محدودیت 3، به معنای نهایتاً 3 مورد کاری در هر لحظه و در هر ستون بود. برای آنکه اطمینان حاصل شود هر مورد مالک مشخصی دارد و کارکنان دچار انباشت کاری نمی‌شوند، آواتارها تعریف شدند. هر آواتار یا تصویر کاربری، نماینده یک عضو تیم بود، که به صورت تصویر شخص روی یک آهن‌ربا روی وایت‌بورد در نظر گرفته شد. برای هر عضو تیم دو آهن ربا وجود داشت، بدین معنا که در آن واحد هر فرد فقط می‌تواند دو آیتم کاری را به عهده بگیرد.

حال که حجم کاری بصری‌سازی شد، چالش بعدی خود را نشان داد! چطور می‌توان موارد کاری در ستون «برای انجام» را مدیریت کرد؟ یکی از جنبه‌های مشکل‌ساز این چالش، این بود که بسیاری از موارد کاری این ستون از خارج از تیم درخواست می‌شدند.

هماهنگی نیازهای مشتریان داخلی

این تیم، مشتریان متعددی درون سازمان داشت، که هرکدام نیاز، الزامات و انتظارات ویژه خود را در رابطه با خدمات IT داشتند. یک شورای عالی، مانند شورای عالی تغییر (CAB) در ITIL مورد نیاز بود. اگرچه، صرفاً اتخاذ تصمیم و برنامه‌ریزی برای تغییرات و رسیدگی به تقاضاها کفایت نمی‌کرد. دریافت اطلاعات تغییرات و درخواست‌ها مفید بود، ولی تیم همچنان با چالش اولویت‌بندی درخواست‌ها روبرو بود و این شامل اولویت‌بندی فرآیندهای مختلف ITIL، مانند درخواست‌های خدمات و رخدادها، در مقابل درخواست‌های تغییرات می‌شد.

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

البته زمان‌هایی وجود داشت که همه درخواست‌ها فوری و دارای اهمیت یکسان به نظر می‌رسید، ولی به جای آنکه محدودیت WIP در ستون «برای انجام» نادیده گرفته شود، تیم راه دیگری یافت. اعضای تیم اتاق جلسه را ترک کردند تا ذینفعان با توجه به اصول هدایتگر ITIL  مانند «تمرکز روی ارزش»، اولویت‌بندی درستی انجام دهند. زیرا تصمیم‌گیری درمورد اولویت‌بندی‌ از منظر کسب‌وکار جزء وظایف یک تیم نیست.

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

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

• پشتیبانی
• گسترش (تغییرات و ویژگی‌های جدید)
• مسائل فنی
• پروژه‌ها

مدل تخته کانبان

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

بررسی پیاده سازی ITIL در اسپاتیفای

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

این روش مزایای متنوعی داشت:

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

مفهوم خودمختاری تیم نقش کلیدی در این مورد ویژه ایفا کرد. برنامه این بود که یک تغییر کلی ایجاد شود و فرآیندهای مدیریتی مورد آزمون قرار گرفته و منتشر شود و به تمام تیم‌هایی که تحت تاثیر قوانین مالی قرار گرفته‌اند تعمیم یابد. قوانین ویژه‌ای برای پیروی وجود داشتند، ولی آن‌ دسته قوانینی که تیم‌های مالی را بیشتر تحت تاثیر قرار داده بودند شامل «تفکیک وظیفه» (Segregation of duty) و «گزارش وقایع» (audit trail) بود.  تفکیک وظیفه به معنای این است که نقش‌های مرتبط و مجزا باید در فرآیند آزمون و تایید تغییرات دخیل باشند و گزارش وقایع به معنای آن است که باید همه تغییراتی که در سیستم مالی انجام می‌شود قابل رهگیری باشند.

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

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

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

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

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

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

مشخص بود که هر تیم یک هدف بنیادی در ذهن دارد، تا با این قوانین مطابقت داشته باشد و کمترین تاثیر را روی جریان کاری و سرعت کار بگذارد.

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