این نوشته را حقیقتش بعد ازچند تا دوره هفته های اخیر که برای یکسری شرکت و سازمان برگزار کردم مینویسم. وضعیت این دوره ها بجز دوره آخری خیلی با دوره های قبلتر فرقی نداشتن اما یکسری مسایل پیش اومد که به نظرم لازم بود این مطلب رو بنویسم و به اشتراک بزارم.
پروژه رو چه جوری تعریف کنیم؟
نکته اصلی به نظرم توی همین مرحله است. اولین چیزی که باید توجه داشته باشین و همه خبره های این حوزه هم روش تاکید دارند اینه که عملا ما قرار نیست یک پروژه انجام بدیم! چرا؟ برای اینکه یک پروژه یکسری فعالیت موقتیه و قراره در یک بازه زمانی مشخص و محدود به یک نتیجه مشخص برسه! خب ما واقعا یک همچین چیزی میخوایم؟ میخوایم که توی مثلا ۶ ماه به یک نتیجه ای برسیم و تموم؟ من که فکر نمیکنم اگر کسی در حال تعریف یک پروژه واقعی ITIL باشه این شرایط براش صدق بکنه؛ ما اصولا دلمون میخواد که بتونیم توی مثلا ۶ ماه یکسری تغییر در قالب مجموعه ای از بهبودها و اصلاحات ایجاد کنیم و اصولا برامون هم مهمه که دوباره برنگردیم سر جای قبلی 🙂 خب پس واقعا این خیلی شبیه یک پروژه که بهش میگیم مجموعه ای از فعالیتهای موقتی نیست و یک موضوع دنباله داره که حالا ما میخوایم توی مثلا ۶ ماه عملا یک پایه گذاری مناسب براش انجام بدیم.
پس تاکید کردم که در مرحله اول مهمه باور کنیم و بپذیریم که اگه داریم یک پروژه ITIL تعریف میکنیم قراره حالا حالا کار داشته باشیم و فقط توی یک بازه زمانی مشخص میخوایم پایه گذاری مورد نیازش رو انجام بدیم. نکته دیگه اینکه بپذیریم که داریم یکسری تغییر سازمانی ایجاد میکنیم.
تغییر سازمانی و مشارکت ذینفعان
خب حالا که حرف از تغییر سازمانی زدیم باید یکسری مورد دیگه رو هم مد نظر قرار بدیم. تغییر سازمانی نمیتونه پشت درهای بسته اتفاق بیافته! یعنی شما امکان نداره که مثلا با ۳-۴ نفر بشینی یکسری دستورالعمل و رویه های جدید و فرم و … آماده کنی و از فردا توقع داشته باشی که همه تیم و سازمان از اونها پیروی کنن! خب پس چی؟ معلومه دیگه، باید مشارکت افراد و ذینفعان این تغییرات در سطوح مختلف رو هم در کل تصمیم گیری ها و برنامه ریزیهایی که انجام میدین داشته باشین! نکته مهمی که باید توجه داشته باشین اینه که اصولا افراد برای اینکه با تغییر همراه بشن براشون مهمه که بتونین به این سئوالشون جواب شفاف بدین “واسه من چی داره؟” یا “چی گیر من میاد؟” این جمله ها رو لزوما با بار مالی در نظر نگیرین؛ مثال ساده اش اینه که شما باید بتونی طرف رو توجیه کنی که اگر اینکار رو اینجوری که من میگم انجام بدی “راحت تره”، “سریع تره”، “اثربخش تره” و …؛ اینو خیلی جدی بگیرین چون واقعا همین موضوع به نظر ساده یکی از کلیدی ترین دلایل شکست پروژه اتون میتونه باشه! وقتی افراد توجیه نیستن که اصلا ضرورت انجام فلان کار چیه، پس ضرورتی هم برای دنبال کردنش نمیبینن!
پس باید به این نکته توجه داشته باشین که همونجوری که دارین صورت مسئله رو تعریف میکنین و اجزاء پروژه رو کنار هم میچینین، به جواب سئوالهای ذینفعانش هم فکر کنین که وقتی قراره توی ذهنشون یا خیلی مستقیم ازتون بپرسن “خب که چی؟” بتونین یک جواب قانع کننده بهشون ارائه بدین؛
وقتیکه بتونین همین دو تا نکته بالا یعنی “جلب مشارکت افراد در طول پروژه (از اول تا آخر)” و “ارائه پاسخ به سئوال چی گیر من میاد؟” را رعایت کنیم شاید بتونم بگم که حداقل ۵۰-۶۰% مسیر رو رفتین و بقیه ماجرا خیلی کار خاصی نداره!
پیشنیازهای فرهنگی در تیم و سازمان
دلیل اصلی تاکیدم روی اینها شرایط آخرین کلاسیه که هفته پیش داشتم! بچه های کلاس از دو گروه کلی تشکیل شده بودن؛ گروه اول افرادی بودن که درگیر تعریف و به نوعی مجری پروژه ITIL بودن و گروه دوم افرادی بودن که تحت تاثیر اون پروژه بودن مثل بچه های شبکه و نرم افزار و …! خب اوضاع چه جوری بود؟ میشه گفت بامزه 😉 گروه اول میخواستن کلاس به سمتی بره که گروه دوم مجاب بشه که کارهایی که انجام دادن درسته و باید به حرفشون گوش بدن و طبیعتا گروه دوم هم در نقطه مقابل بودن! میخواستن من یک چیزی بگم که ازش استفاده کنن و اثبات کنن که کارهای گروه اول اشتباهه و به نوعی از زیر کار در برن 🙂
غیر طبیعیه؟ به نظر من که کاملا طبیعی بود! چرا؟ به همون دلایلی که بالا گفتم؛ دوباره تاکید میکنم که پروژه های این مدلی پشت درهای بسته نمیتونه انجام بشه و اگر اینجوری انجام بشه تقریبا سرنوشتش مشخصه؛ این آخر یک عنوان خیلی کلی رو هم تاکید کنم که مد نظر داشته باشین؛ وقتیکه میگم باید همه مشارکت کنن پس باید واقعا اول همه رو توجیه کنید و همه ضرورت انجام تغییر رو درک کرده باشن، همه باید بخوان که اوضاع بهتر بشه! تا زمانیکه تیم یا سازمان شما اوضاعش اینجوریه که هر فرد یا تیمی میخواد مشکل را بندازه گردن یک فرد یا یک تیم دیگه عملا بستر برای انجام این مدل تغییراتی مهیا نیست و شما قبلش باید روی فرهنگ سازمانی و فرهنگ تیمتون کار کنید.
اگه این مشکل را حل نکرده باشین نتیجه این میشه که همه افراد میخوان از این پروژه به نفع خودشون و به عنوان ابزاری برای از زیر کار در رفتن یا حواله دادن مشکلات به یک سمت دیگه استفاده کنن! مثال خیلی ساده و رایجش همیشه این بوده که مثلا یک کارشناس پشتیبانی از فردای راه افتادن یک ابزار ثبت درخواست نصف روزهای قبل کار انجام میده و توجیهش هم اینه که کار با این ابزار و ثبت اطلاعات زمانبر هست و در نتیجه همینیه که هست! پس دوباره تاکید میکنم که اول روی فرهنگسازی و مسئولیت پذیری افراد کار کنید و بعدش بیاین پروژه های این مدلی تعریف کنید.
حرف آخر
اینرو همیشه و همه جا تاکید کردم که پروژه های ITIL رو خیلی تخیلی و آرمانگرایانه تعریف نکنید که بعدا توی ذوقتون بخوره و به نتیجه خاصی نرسید. پروژه ها رو کوچیک تعریف کنید و با تمرکز برروی مشکلات اصلی و پررنگ تیم یا سازمانتون! الکی دامنه پروژه رو بزرگ نکنید که به همون نسبت ریسکها و چالش اجراش هم بزرگتر میشه و واقعا میره توی فضای همون ضرب المثل “سنگ بزرگ نشونه نزدنه”؛
اگر دوست داشتین با تیم مشاوره شرکت رایزن سامانه گستر تماس بگیرین و برای تعریف بهتر پروژه هاتون بصورت رایگان ازشون کمک بگیرید.
