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

وبلاگ

  • خانه
  • بلاگ
  • وبلاگ
  • یک پروژه ITIL رو چه جوری تعریف و از کجا شروع کنیم که موفقیتش تضمین شده باشه؟

یک پروژه ITIL رو چه جوری تعریف و از کجا شروع کنیم که موفقیتش تضمین شده باشه؟

  • ارسال شده توسط رایزن سامانه گستر
  • تاریخ مرداد ۲۴, ۱۳۹۶
  • نظرات ۰ نظر
4.9/5 - (9 امتیاز)

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

پروژه رو چه جوری تعریف کنیم؟

نکته اصلی به نظرم توی همین مرحله است. اولین چیزی که باید توجه داشته باشین و همه خبره های این حوزه هم روش تاکید دارند اینه که عملا ما قرار نیست یک پروژه انجام بدیم! چرا؟ برای اینکه یک پروژه یکسری فعالیت موقتیه و قراره در یک بازه زمانی مشخص و محدود به یک نتیجه مشخص برسه! خب ما واقعا یک همچین چیزی میخوایم؟ میخوایم که توی مثلا ۶ ماه به یک نتیجه ای برسیم و تموم؟ من که فکر نمیکنم اگر کسی در حال تعریف یک پروژه واقعی ITIL باشه این شرایط براش صدق بکنه؛ ما اصولا دلمون میخواد که بتونیم توی مثلا ۶ ماه یکسری تغییر در قالب مجموعه ای از بهبودها و اصلاحات ایجاد کنیم و اصولا برامون هم مهمه که دوباره برنگردیم سر جای قبلی 🙂 خب پس واقعا این خیلی شبیه یک پروژه که بهش میگیم مجموعه ای از فعالیتهای موقتی نیست و یک موضوع دنباله داره که حالا ما میخوایم توی مثلا ۶ ماه عملا یک پایه گذاری مناسب براش انجام بدیم.

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

تغییر سازمانی و مشارکت ذینفعان

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

پس باید به این نکته توجه داشته باشین که همونجوری که دارین صورت مسئله رو تعریف میکنین و اجزاء پروژه رو کنار هم میچینین، به جواب سئوالهای ذینفعانش هم فکر کنین که وقتی قراره توی ذهنشون یا خیلی مستقیم ازتون بپرسن “خب که چی؟” بتونین یک جواب قانع کننده بهشون ارائه بدین؛

وقتیکه بتونین همین دو تا نکته بالا یعنی “جلب مشارکت افراد در طول پروژه (از اول تا آخر)” و “ارائه پاسخ به سئوال چی گیر من میاد؟” را رعایت کنیم شاید بتونم بگم که حداقل ۵۰-۶۰% مسیر رو رفتین و بقیه ماجرا خیلی کار خاصی نداره!

پیشنیازهای فرهنگی در تیم و سازمان

دلیل اصلی تاکیدم روی اینها شرایط آخرین کلاسیه که هفته پیش داشتم! بچه های کلاس از دو گروه کلی تشکیل شده بودن؛ گروه اول افرادی بودن که درگیر تعریف و به نوعی مجری پروژه ITIL بودن و گروه دوم افرادی بودن که تحت تاثیر اون پروژه بودن مثل بچه های شبکه و نرم افزار و …! خب اوضاع چه جوری بود؟ میشه گفت بامزه 😉 گروه اول میخواستن کلاس به سمتی بره که گروه دوم مجاب بشه که کارهایی که انجام دادن درسته و باید به حرفشون گوش بدن و طبیعتا گروه دوم هم در نقطه مقابل بودن! میخواستن من یک چیزی بگم که ازش استفاده کنن و اثبات کنن که کارهای گروه اول اشتباهه و به نوعی از زیر کار در برن 🙂

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

عبارت انگلیسی که برای این شرایط استفاده میکنن Blame Game یا Finger Pointing هستش
عبارت انگلیسی که برای این شرایط استفاده میکنن Blame Game یا Finger Pointing هستش

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

حرف آخر

اینرو همیشه و همه جا تاکید کردم که پروژه های ITIL رو خیلی تخیلی و آرمانگرایانه تعریف نکنید که بعدا توی ذوقتون بخوره و به نتیجه خاصی نرسید. پروژه ها رو کوچیک تعریف کنید و با تمرکز برروی مشکلات اصلی و پررنگ تیم یا سازمانتون! الکی دامنه پروژه رو بزرگ نکنید که به همون نسبت ریسکها و چالش اجراش هم بزرگتر میشه و واقعا میره توی فضای همون ضرب المثل “سنگ بزرگ نشونه نزدنه”؛

اگر دوست داشتین با تیم مشاوره شرکت رایزن سامانه گستر تماس بگیرین و برای تعریف بهتر پروژه هاتون بصورت رایگان ازشون کمک بگیرید.

نوشته های مرتبط:

  1. فریبکاری در توافقنامه های سطح خدمت
    فریب دادن و به اصطلاح دور زدن SLA بهتر است و یا اینکه روابط خود با مشتری را در طولانی‌مدت بر هم آشفتن؟ بسیاری از سازمان‌ها مورد اول را ترجیح...
  2. بیست و هفتمین دوره ITIL Foundation در مرکز آموزش رایزن سامانه گستر
    بیست و هفتمین دوره آموزشی ITIL Foundation بصورت کارگاهی سه روزه و طی روزهای 30 مهرماه الی 2 آبان ماه برگزار خواهد شد. علاقمندان به شرکت در این دوره میتوانند با...
  3. برای بیست و هشتمین دوره ITIL Foundation ثبت نام کنید!
    طبق برنامه از پیش اعلام شده، مرکز آموزش رایزن سامانه گستر در روزهای 10 الی 12 دیماه سال جاری بیست و هشتمین دوره ITIL Foundation V3 2011 را منطبق با آخرین...
  4. تاریخچه بسیار مختصر ITIL
    در تصویر زیر تاریخچه بسیار مختصری از چارچوب ITIL را مشاهده میکنید. عموم افراد زمانیکه که نام این چارچوب را میشنوند گمان میکنند که با موضوع جدیدی در حوزه فناوری...

برچسب:ITIL, مدیریت خدمات فناوری اطلاعات

  • اشتراک گذاری:
رایزن سامانه گستر
شرکت رایزن سامانه گستر به عنوان یکی از پیشگامان در حوزه چارچوبها و استانداردهای مدیریت فناوری اطلاعات نزدیک به ده سال است که در حال ارائه خدمات آموزش، مشاوره و راهکارهای نرم افزاری به شرکتها و سازمانهای دولتی و خصوصی میباشد. این شرکت به عنوان نماینده رسمی چندین شرکت و موسسه بین المللی نظیر شرکت ماروال انگلستان (ارائه کننده یکی از برترین ابزارهای مدیریت خدمات فناوری اطلاعات ITSM) و ITpreneurs هلند (ارائه کننده محتوای آموزشی تخصصی در حوزه چارچوبها و استانداردهای فناوری اطلاعات) نقش بسزایی در توسعه دانش و حرکت به سمت توسعه این بهروشها در سطح کشور داشته است.

مطلب قبلی

ما چه کار میکنیم؟ مدیریت خدمات فناوری اطلاعات!
مرداد ۲۴, ۱۳۹۶

مطلب بعدی

پیاده سازی ITIL رو از کجا شروع کنیم؟
مرداد ۲۹, ۱۳۹۶

ممکن است همچنین دوست داشته باشید

Self_service_cons-768×736
سوالاتی که باید قبل از پیاده‌سازی پورتال سلف سرویس فناوری اطلاعات بپرسید
۵ مرداد, ۱۴۰۱
CICD Tools
۱۰ تا از برترین ابزارهای CI/CD مورد استفاده برنامه نویسان
۲۹ خرداد, ۱۴۰۱
wef-digital-sustainability-16-9
مسئولیت فناوری اطلاعات نسبت به پایداری
۲۴ فروردین, ۱۴۰۱

نظر بدهید لغو پاسخ

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

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

جستجو

سوالاتی که باید قبل از پیاده‌سازی پورتال سلف سرویس فناوری اطلاعات بپرسید

سوالاتی که باید قبل از پیاده‌سازی پورتال سلف سرویس فناوری اطلاعات بپرسید

اگر به رابطه بین تیم پشتیبانی و کاربران نگاهی...

طراحی و استقرار مجموعه‌ای از فرایندهای چارچوب ITIL4 در “شرکت ابرآمد”

طراحی و استقرار مجموعه‌ای از فرایندهای چارچوب ITIL4 در “شرکت ابرآمد”

شرکت توسعه زیرساخت­‌های فناورانه ابرآمد یکی از شرکت­‌های زیرمجموعه...

۱۰ تا از برترین ابزارهای CI/CD مورد استفاده برنامه نویسان

۱۰ تا از برترین ابزارهای CI/CD مورد استفاده برنامه نویسان

عبارت CI/CD (Continuous Integration /Continuous Delivery) به معنی ادغام...

استقرار سیستم مدیریت خدمات فناوری اطلاعات و دریافت گواهینامه ISO/IEC 20000  در شرکت “مپنا توسعه دو”

استقرار سیستم مدیریت خدمات فناوری اطلاعات و دریافت گواهینامه ISO/IEC 20000 در شرکت “مپنا توسعه دو”

شرکت احداث و توسعه نیروگاه‌های سیکل ترکیبی مپنا –...

مسئولیت فناوری اطلاعات نسبت به پایداری

مسئولیت فناوری اطلاعات نسبت به پایداری

امروزه پایداری به مفهومی رایج و پرکاربرد در میان...

آخرین نوشته ها

  • سوالاتی که باید قبل از پیاده‌سازی پورتال سلف سرویس فناوری اطلاعات بپرسید
  • طراحی و استقرار مجموعه‌ای از فرایندهای چارچوب ITIL4 در “شرکت ابرآمد”
  • ۱۰ تا از برترین ابزارهای CI/CD مورد استفاده برنامه نویسان
  • استقرار سیستم مدیریت خدمات فناوری اطلاعات و دریافت گواهینامه ISO/IEC 20000 در شرکت “مپنا توسعه دو”
  • مسئولیت فناوری اطلاعات نسبت به پایداری
  • معرفی دوره ITIL® ۴ Specialist: Sustainability in Digital and IT
  • اهداف توسعه پایدار


کلیه حقوق این وب سایت به شرکت رایزن سامانه گستر متعلق بوده و نقل مطلب از آن با ذکر منبع بلامانع است.