ادامه بخش اول
۳.شالوده های پروژه های BPM چابک
این بخش قوانین برگزیده ی سیستم چابک و چگونگی تاثیرگذاری آنها در پروژه های BPM را مورد بحث قرار می دهد. کار را با معرفی شالوده ی پروژه های BPM چابک در مقایسه با ایده ی BPM و تعریف یک پروژه آغاز می کنیم. ایده ی پشت BPM فراهم نمودن بهبودهای پایدار و همیشگی است، درحالی که پروژه ها با قصد منحصر بودن و داشتن اهداف معین تعریف می شوند.
بر طبق تجربه ی ما، بیش تر بهبودهای BPM توسط یک پروژه انگیزه دهی می شوند و به هیچ عنوان همیشگی نمی باشند. هدف BPM منعطف سازی فرآیندهای کسب و کاری و تقویت آن ها به صورت مداوم می باشد. با اینکه پروژه های چابک هنوز هم پروژه هستند، مزیت های مشخصی را در ترکیب با BPM از خود نشان می دهند. آنها منجر به انعطاف پذیری غیرقابل پیش گیری برای پروژه های BPM می شوند که تغییرات را با آغوش باز می پذیرد. علاوه بر این، زمانی که اکثر پروژه های آغاز می شوند، هدف آنها اغلب به شکل دقیق و با سطوح جزئیاتی تعریف نشده است. راهبردهای چابک زمان اضافی را از یک تحلیل و فاز طراحی چند ماهه حذف می کنند و نتایج ملموسی را در فازهای اولیه ی یک پروژه تحویل می دهند.
بهترین عملکرد ۱ (انگیزه دهی به راهبردهای مختلف با استفاده از “مثلث جادویی”).
از “مثلث جادویی” که در تصویر ۴ نشان داده شده است برای درک ایده ی تغییر نمونه استفاده کنید که یک راهبرد توسعه ی چابک را همراهی می کند. در حالی که راهبرد آبشاری کلاسیک، نمای پروژه ی ثابتی دارد و تنها مفروضاتی را راجع به زمان و بودجه در نظر می گیرد. با تبدیل مثلث به نوع چابک، در مقابل، یک زمان و بودجه ی ثابت پیشنهاد می شود اما محدودیت یا مانعی بر دورنما قرار نمی گیرد.
تصویر۴٫ مقایسه ی مثلث جادویی
تا همین اواخر، یک پروژه بدون دورنمای تعریف شده ی واضح قابل قبول نبود. امروزه معلوم شده است که پروژه های طولانی مدت با یک دورنمای ثابت معمولا موفقیت آمیز نیست و منجر به هیچ پذیرش نهایی توسط مشتری نمی شود. برای رهایی یافتن از این معضل، شالوده ی پروژه های BPM چابک مبتنی بر پذیرش بیانیه ی چابک و قوانین آن می باشد. در ادامه، مرتبط ترین قوانین بیانیه ی چابک از منظر پروژه ی BPM عنوان می شوند. قوانین را طبق منبع شماره ۵ ذکر می کنیم:
قانون ۱. بالاترین اولویت ماجلب رضایت مشتری از طریق تحویل زودهنگام و مداوم نرم افزار ارزشمند می باشد.
تعدادی از پروژه های BPM فاز تحلیل و طراحی طولانی مدتی دارند که منجر به ارائه ی دیرهنگام نتایج مشهود می باشد. بنابراین، مشتری قادر نیست که جهت پروژه را در زمان های صحیح به خوبی تعیین کند که این موضوع منجر به هیچ ارائه ی مداومی نخواهد شد. پروژه های BPM اغلب با خروجی های دانه درشتی همراه هستند. از آنجایی که BPM و راهبردهای سریع شرایط اولیه ی مشابهی دارند، تحقیق بیش تری برای فهم چگونگی هماهنگی آنها ضروری است. دوباره، ایده ی BPM این است که فرآیندهای کسب و کاری در حد توان بهبود یافته و حمایت شوند و کاری با انجام دادن یک پروژه ی تنها ندارد. این یک مشکل قابل توجه است که توسط پروژه های BPM چابک رفع می گردد.
قانون دوم. پذیرای هر تغییری در نیازمندی ها باشید حتی اگر در آخرین مراحل توسعه ایجاد شوند. فرآیندهای چابک تغییر را به دلیل مزیت رقابتی مشتری، تحت کنترل در می آورند.
چرا شرکت ها از BPM استفاده می کنند؟ آنها منتظر مزایای رقابتی هستند و می خواهند زمان رسیدن نوآوریها و نسخه های بهبودیافته شان به بازار را کاهش دهند. تجربه ی ما نشان داده است که پروژه های BPM اغلب به دلیل تغییرات مربوط به نیازمندی ها دچار تاخیر می شوند. شیوه های چابک تغییرات را می پذیرند تا نیازمندیهای مشتری را که به مرور زمان تکامل می یابند، به انجام برسانند. این پیاده سازی فرآیند را پالایش می دهد و آن را در مسیری قرار می دهد که نیازهای مشتری را ارضا کند.
قانون ۳. متناوباً نرم افزار کاری را تحویل دهید، یعنی دو هفته یک بار تا دو ماه یک بار، البته مقیاس زمانی کوتاه تر را ترجیح بدهید.
این قانون پرسش مقابل را مطرح می کند ” معنای نرم افزار کاری برای یک پروژه ی BPM چیست؟” آیا تنها اجرای فرآیند زنده در BPMS است یا به این معنا است که ما فرآیند را در سرتاسر شرکت گسترش داده ایم و آموزش و مستندات را هم در نظر گرفته ایم؟ یک گسترش کامل نمی تواند در خلال یک اسپرینت تنها حاصل گردد. در مورد یک پروژه ی BPM عملی ما نیاز داریم که متناوباً در BPMS خود فرآیند کاری را تحویل دهیم. بسته به پروژه، ممکن است چندین ارائه در هر ۵-۱۰ اسپرینت داشته باشیم.
تصویر ۵٫ پارامترهای پروژه
در این مورد مهم است اطمینان حاصل کنیم که چرخه ی کلی یک فرآیند کامل شده است (شامل آزمایش، گسترش، آموزش)
قانون ۴. در سرتاسر پروژه، متخصصین و توسعه دهندگان کسب و کار باید به صورت روزانه با هم کار کنند.
یکی از منافع اصلی راهبردهای توسعه نرم افزار چابک این است که در خلال دور های تکراری و کوتاه مدت اجرا می شوند. این موضوع وضوح بالاتری را برای هر دو طرف مقدور می سازد. مشکلات سریع تر از راهبردهای کلاسیک مشخص شده و می توانند مستقیما برطرف شوند. متخصصان کسب وکار اغلب دارند در یک زمان واحد روی چندین پروژه کار می کنند. این موضوع منجر به مشکلی درباره ی در دسترس بودن و تمرکز آنها بر روی یک پروژه ی واحد می گردد. در پروژه های BPM متخصصان کسب وکار نیاز دارند تا به نزدیکی در کنار هم قرار گیرند زیرا نه تنها راجع به نرم افزار در حال تغییر بلکه راجع به تغییرات سازمانی می باشد.
قانون ۵. توجه مداوم به تعالی فنی و طراحی خوب، سبب بهبود سرعت می گردد.
در کنار نیاز به یک معماری با طراحی خوب، پیاده سازی فنی و عملی فرآیند کسب و کار ممکن است با مدل فرآیندهای کسب و کار متفاوت باشد. بنابراین هم زمان سازی مورد نیاز است. در این هنگام، بحثی پیش می آید که آیا مدل فرآیند و یا پیاده سازی فنی (موجود) تعیین کننده تر می باشد؟ از نقطه نظر ما مدل فرآیند می بایست خروجی تعیین کننده باشد. در غیر این صورت، برای پیش برد پروژه های BPM چابک، ضروری است که ابتدا روی معماری تمرکز داشته باشیم. یکی از مزایای استفاده از BPMS چابک این است که توافق مشترکی درباره ی معماری های مرجعی که می توانند به عنوان نقطه ی آغاز برای پروژه های جدید استفاده شوند، وجود دارد.
قانون ۶. سادگی- یعنی هنر به حداکثر رساندن میزان کاری که انجام نمی شود – ضروری است.
هنگامی که افراد درگیر در کسب و کار و مسئولین فناوری اطلاعات با هم کار می کنند، ضروری است که همه چیز ساده نگه داشته شود. تمرکز همواره باید بر روی یک فرآیند اررزشمند حداقلی باشد. به این معنی که جزئیات فقط برای ملزوماتی مورد نیاز هستند که در ۲ یا ۳ اسپرینت بعدی قرار است پیاده سازی شوند. با انجام این کار، راهبردمان مطابق با قوانین چابک نگه داشته می شود. این قوانین برای تولید ارزش کسب وکار بیش تر از مستندسازی، ارزش قائل هستند.
کلیه ی قوانین مورد بحث، بر روی یک پروژه ی BPM تاثیرگذار هستند. در بسیاری از موارد، ممکن نیست که بتوان از همه ی آنها پیروی کرد.
بهترین عملکرد ۲ (پارامترها برای راهبردهای پروژه ی چابک یا کلاسیک)
پارامترهای نشان داده شده در تصویر ۵ را ارزیابی کنید تا تصمیم بگیرید که آیا باید مایل به اجرای پروژه ی خود با راهبرد سریع یا کلاسیک (یعنی راهبرد آبشاری) باشید.
تصویر ۶٫ نگاه کلی از چارچوب کاری BPM سریع
۴ روش شناسی BPM سریع
از آنجا که IBPM و Scrum روش های مناسبی برای اهداف مدنظر خود می باشند، در واقع جای یک ارتباط و پیوند میان این دو خالی است تا به ترکیبی از هر دو چارچوب، برسیم. هدف این بخش ترکیب نمودن BPM و Scrum برای معرفی یک چارچوب منعطف برای پروژه های BPM چابک می باشد. چارچوب پیشنهاد شده شامل سه بُعد هسته ای می باشد: “راهبرد پروژه” “خروجی ها” و “روش ها” . این موضوع پذیرش انعکاسی قوانین چابک در پروژه های BPM را آسان تر می کند. تمرکز ما بر پیاده سازی فنی پروژه های فرآیند-محوری است که بر اساس BPMS تحقق می یابند.
پروژه های BPM چابک می توانند به فازها و انواع اسپرینت های نشان داده شده در تصویر ۶ تقسیم شوند. همان گونه که بحث شد، ما میان خروجی ها، روش ها و فعالیت ها در هر فاز، تمایز قائل می شویم. پیش از آن که پروژه ای آغاز شود، باید به خوبی بررسی گردد. در مرحله بعد، پروژه آغاز می شود و سپس تعداد قابل تنظیمی از اسپرینت ها به وقوع می پیوندند تا جایی که به هدف پروژه دسترسی بیابیم. بسته به پروژه، تعداد ارائه ها متفاوت خواهد بود.
در محل های حضور مشتری، چرخه ی چابک اغلب به بحثی حول مدل سازی در برابر پیاده سازی منجر خواهد شد. این یکی از تفاوت های مرکزی میان پروژه های توسعه نرم افزار چابک سنتی و پروژه های BPM است. بنابراین، چگونه مستندسازی و مدل سازی فرآیندهای کسب و کاری در ایده ی توسعه نرم افزار سریع می گنجند؟ با این که واضح است که این قانون خودش نوعی مستندسازی به حساب می آید، چگونه می توانیم درباره ی ارزش مدل های فرآیند کسب وکار بحث کنیم؟ از آنجایی که یک پروژه ی BPM عمدتا در سطوح انتزاعی متفاوتی (مدیریت، متخصصین کسب وکار و فناوری اطلاعات) اجرا می شود، نیاز داریم زبانی را تعریف کنیم که توسط هر دو بخش فهمیده شود. یک مدل فرآیند کمک می کند تا نیازهای افراد درگیر در کسب و کار به واحد فناوری اطلاعات انتقال داده شود. علاوه بر این، یک BPMS مدرن پیاده سازی فرآیندها را مبتنی بر مدل هایشان مقدور می سازد.