چکیده
مدیریت فرآیند کسب و کار (BPM) در سال های اخیر تبدیل به یکی از مهم ترین نظام های مدیریتی شده است. در واقع، با این حال، بسیاری از پروژه های بهبود فرآیند عملی در گذشته با شکست مواجه شدند و به نتایج مورد انتظار دست نیافتند. در همان زمان جنبش توسعه نرم افزار چابک پیشرفت شگرفی را در تقابل با راهبردهای آبشاری کلاسیکی به دست آورد که هنوز هم متدولوژی های بنیادی برای بسیاری از پروژه های BPM محسوب می شوند. این مقاله ترکیبی از یک متدولوژی BPM سنتی و بهبود نرم افزاری چابک را مورد مطالعه قرار می دهد تا محدودیت های متدولوژی های BPM موجود را برطرف سازد. تمرکز اصلی بر روی پروژه هایی است که تحقق عملی فرآیندهای مبتنی بر سیستم های مدیریت فرآیند کسب و کار مدرن (BPMS) را پوشش می دهند.
۱ انگیزه
مدیریت فرآیند کسب و کار (BPM) به شرکت هایی که بر روی فرآیندهای ارزش-افزا و منسجم و حمایت آنها توسط سیستم های IT تمرکز دارند، کمک می کند. بنابراین روی پیاده سازی سیستم های کاربردی کسب و کاری بازه-وسیع و با دوام و مبتنی بر فرآیند با استفاده از مجموعه مشخصی از ابزارها (سیستم مدیریت فرآیند کسب و کار، به اختصار BPMS)، تمرکز دارد. علاوه بر آن از مدیریت تغییر سازمانی که برای گسترش موفقیت آمیز این تغییرات در سرتاسر شرکت مورد نیاز است، حمایت می کند.
با این حال در برخی از پروژه هایمان پی بردیم که با پیاده سازی فرآیند، واحدهای سازمانی دقیقاً می دانستند که سابقا چه چیزی نیاز داشتند اما با وجودیکه نیازمندی ها در خلال زمان تغییر می کردند، آنها نمی دانستند که اکنون چه چیزی نیاز دارند. شیوه های مهندسی نرم افزار سنتی با مشکلات مشابهی رو به رو شده بودند اما در نهایت به راه حل هایی دست یافتند که مشتریان (افرادی که نیازمندی ها را تعیین می کردند) را به شکل نزدیکی با مهندسانی که آن سیستم ها را واقعا می ساختند، در ارتباط قرار می دادند. راه حل ها مبتنی بر قوانین توسعه نرم افزاری چابک مانند “مشتری را با ارائه ی سریع و مداوم نرم افزار ارزشمند راضی کنید” و “نیازمندی های تغییرات را بپذیرید، حتی اگر در خلال توسعه، دیرتر پیش بیایند” و “به طور مداوم نرم افزار کاری را تحویل بدهید” می باشند.
برای حصول منافع قوانین چابک برای پروژه های مدیریت فرایند، ما راهبرد جدیدی را برای تحقق پروژه های BPM توسعه دادیم که مبتنی بر قوانین توسعه ی نرم افزار چابک می باشد. بنابراین ما خروجی ها و شیوه های یک روش BPM موجود را با استفاده از اجرای پروژه ی آبشاری سنتی (که IBPM نام دارد) طبقه بندی می کنیم و بخش های عمومی آن را مجدداً طرح ریزی می کنیم تا به یک روش توسعه ای چابک مبتنی بر Scrum دست بیابیم. چارچوب کاری مشتق شده، شالوده ی یک روش BPM سریع را می سازد که می تواند راهنمای نوآوری های پروژه ی BPM اولیه تا پیاده سازی نهایی باشد.
تصویر ۱. چارچوب کاری روش پروژه BPM مجتمع
این مقاله به شیوه ی مقابل سازمان دهی شده است. با مروری از مقدمات مخصوصاً راجع به IBPM و Scrum در بخش ۲ کار را آغاز می کنیم. بخش ۳ درباره ی شالوده های پروژه های BPM چابک بحث می کند. در کنار ارائه ی کاربرد قوانین چابک درBPM، همچنین ما را راهنمایی می کند که آیا پروژه ی BPM باید با استفاده از مراحل سنتی و یا با یک روش چابک پیاده سازی شود. بخش ۴ ایده های هسته ای روش BPM چابک شامل مدل متای رسمی، مراحل چرخه ی چابک و خروجی ها و روش های کلیدی را ارائه می دهد. بخش ۵ یک تجربه ی عملی با به کارگیری روش چابک را معرفی می کند. کارهای مرتبط را در بخش ۶ و نتیجه گیری را در بخش ۷ بحث خواهیم کرد.
۲ مقدمات: IBPM و Scrum
این بخش پایه های روش شناسی پروژه BPM مجتمع یا (IBPM) و چارچوب کاری توسعه نرم افزار Scrum را معرفی می کند. هر دو راهبرد اهداف متفاوتی دارند. درحالی که IBPM تمرکز شدیدی بر تحلیل و طراحی دارد، Scrum راهبردی کلی از چگونگی پیاده سازی ملزومات را ارائه می دهد. IBPM علاوه بر این بهترین عملکردها و خروجی ها را برای درک و بحث حول نیازمندی های کسب و کار ارائه می دهد.
۲٫۱ روش شناسی پروژه BPM مجتمع
روش شناسی پروژه BPM مجتمع، پروژه های BPM را قادر می سازد تا به شیوه ای ساختاریافته به انجام برسند. نویسندگان ویژگی های مختلف پروژه های BPM را که برای خالص سازی پروژه های توسعه نرم افزار، مشخص و واضح هستند، معرفی می کنند. چالش این است که جریان فرآیند و منطق تصمیم گیری را از ابعاد توسعه ای نرم افزار مانند توابع جدا کنیم، بنابراین یک معماری به دست خواهد آمد که به خوبی هم تراز شده است و پیوستگی آزادانه ای دارد و نیز خدمات-محور می باشد.
تصویر ۲. راهبرد پروژه ی IBPM طبق [۱۲]
انگیزه ی پشت IBPM تمایلی برای افزایش کیفیت و تاثیرگذاری به همراه کاهش ریسک ها و هزینه ها بود که افراد را قادر می ساخت پرسش های درستی را مطرح کرده و خروجی های صحیح را در زمان صحیح تحویل دهند. به این منظور IBPM از بهترین عملیات بهره می برد و شامل سه عنصر هسته ای مقابل می باشد: چارچوب کاری IBPM، کاتالوگ الگوی IBPM و راهبرد پروژه ی IBPM.
مقدمات ۱ (چارچوب کاری IBPM)
چارچوب کاری IBPM، که در تصویر شماره ۱ نشان داده شده است، شامل ده ستون موضوعی می باشد که مهم ترین ابعاد دورنمای فرآیند-محور و خدمات-محور در یک پروژه ی BPM را با هم ترکیب می کند. هر یک از این دو دورنما در قالب پنج ستون معرفی شده اند. با در نظر گرفتن اینکه مدل فرآیند مبتنی بر BPMN می باشد، این موضوع ابزار عمده ی دورنمای فرآیند-محور به حساب می آید. ستون های دیگر شامل سازمان و نقش ها (B)، وظایف کاربر (C)، نقش های کسب و کار (D) و در نهایت نظارت فرآیند (E) می باشند. ایده ی مشابهی را می توانیم برای ستون های دورنمای خدماتی اعمال کنیم. مولفه گرایی (F) شامل عمده ترین ابزاری است که با SOA-Map به همراه چهار ستون پالایشی دیگر نشان داده می شود. این چارچوب علاوه بر این مبتنی بر پنج سطح مختلف از جزئیات (طرح ریزی، تحلیل، طراحی کسب و کار، طراحی پیاده سازی و پیاده سازی) می باشد.
مقدمات ۲ (کاتالوگ الگوی IBPM)
کاتالوگ الگوی IBPM مبتنی بر بهترین عملیات بوده و قراردادهای پروژه را برای هشت بُعد مختلف با الگوهای از پیش تعریف شده ارائه می دهد. الگوها شامل راهنماهای مدل سازی IBPM ، قالب های UI یا الگوهایی برای پوشش مدیریت تغییرات می باشد.
مقدمات ۳(راهبرد پروژه ی IBPM)
راهبرد پروژه ی IBPM (تصویر ۲) مبتنی بر راهبرد آبشاری بوده و فازهای مختلف پروژه (طرح ریزی، تحلیل، طراحی کسب و کار، طراحی پیاده سازی و پیاده سازی) و بسته های کاری را در حالی که بر روی فرآیندها و یا خدمات تمرکز دارد، همراه با تاکیدی شدید بر تحلیل و طراحی یک پروژه ی BPM ، معرفی می کند. IBPM فاز طراحی را به دو بخش طراحی کسب و کار و طراحی پیاده سازی تقسیم بندی می کند. در مقایسه ی بین IBPM و راهبردهای پروژه ی عمومی، IBPM با تعیین کارها، نقش ها و خروجی های مخصوص BPM، سبب افزایش ارزش می شود.
۲٫۲ چارچوب کاری توسعه نرم افزار Scrum
Scrum یک چارچوب توسعه ای سبک است که درک آسانی داشته و نقش ها و فرآیندهای معینی را ارائه می دهد. اگرچه که این چارچوب در اوایل دهه ۱۹۹۰ به منظور اهداف توسعه ی نرم افزار متولد شد، نظام های دیگر شامل مدیریت عمومی، بیش تر و بیش تر از آن بهره برده اند. این چارچوب با تمرکز بر روی همکاری و تعامل برای جلب رضایت مشتری، نماینده ی بیانیه ی چابکو قوانین مرتبط می باشد. Scrum مبتنی بر نظریه ی کنترل فرآیند تجربی بوده و از راهبردی تکرارشونده و افزایشی برای کنترل خطرات و بهینه سازی قابلیت پیش بینی بهره می برد. هدف اصلی این است که بخش های قابل ترخیص بالقوه ی محصول را از طریق تکرارهای کوتاه، پایدار و با زمان مشخص که اسپرینت نام دارند، توسعه دهیم.
Scrum مبتنی بر سه نقش (صاحب محصول، مدیر Scrum و تیم)، چهار جلسه ملاقات (طرح ریزی اسپرینت، Scrum روزانه، مرور اسپرینت و نگاه به گذشته ی اسپرینت) و سه خروجی (انباشه ی محصول، انباشه و ترقی محصول) می باشد. انباشه محصول و سایر خروجی ها و نقش ها را بر اساس جلسات نشان داده شده در تصویر ۳ معرفی می کنیم.
تصویر۳٫ فرآیند توسعه ی Scrum
مقدمات ۴ (انباشه ی محصول)
یک “انباشه ی محصول” توصیف کننده ی نیازمندی ها برای یک محصول است که به ترتیب ارزش کسب و کاری شان اولویت بندی شده اند. علاوه بر این هر مورد در انباشه (طبق یک شیوه ی تلاش انتزاعی مبتنی بر “نقاط پروفایل”) تخمین زده می شود و مجموعه ای از معیارهای پذیرش را دارد.
مقدمات ۵ (طرح ریزی اسپرینت)
در اولین بخش “طرح ریزی اسپرینت” ، “صاحب محصول” هدف خود را برای اسپرینت زیر ارائه می کند و اولویت هایش را بیان می کند. تیم موارد ارائه شده را تخمین زده و بسته به سرعت (مثلا یک تیم در حال حاضر و در یک بازه زمانی از پیش تعیین شده چه تعداد “نقاط پروفایل” می تواند پیاده سازی کند)، مقدار مشخصی از “موارد انباشه” برای اسپرینت انتخاب می کند. در دومین بخش از “طرح ریزی اسپرینت” آن نیازمندی ها را به تعدادی “کار یا وظیفه” می شکنیم که ورودی های “انباشه ی اسپرینت” خواهند بود.
مقدمات ۶ (Scrum روزانه)
در خلال یک بازه ی از پیش تعیین شده برای اسپرینت (معمولا ۲ تا ۴ هفته) تیم به صورت روزانه برای “Scrum روزانه” جلسه خواهد داشت تا کار جاری و مخصوصا مشکلات (موانع موجود) را به شکل همزمان حل کند. “مدیر Scrum” مسئول حل کردن آن موانع با سرعت هرچه بیش تر می باشد.
مقدمات ۷ (نقد اسپرینت)
در پایان یک “اسپرینت”، “تیم”، “مدیر Scrum ” و “صاحب محصول” مجددا برای “نقد اسپرینت” با هم ملاقات خواهند داشت. بر پایه ی نیازمندی ها و معیارهای پذیرش از پیش تعیین شده ی آنها، “صاحب محصول” ملزومات را در سیستم نهایی تایید خواهد کرد.
مقدمات ۸ (بازگشت به گذشته اسپرینت)
آخرین جلسه درباره ی “اسپرینت” مربوط به “بازگشت به گذشته” می باشد، جایی که “تیم” و “مدیر Scrum ” (گاهی اوقات به همراه “صاحب محصول”) نتیجه ی “اسپرینت” را مورد بررسی قرار می دهند و وظایفی را برای بهبود فرآیند Scrum خود تعریف می کنند.
Scrum تعدادی متغیر و گام ها یا خروجی های اضافی دارد مثل آراستن انباشه، تعریف آماده و تعریف انجام شده. آراستن انباشه ملاقات جدیدی را ترتیب می دهد که به صاحب محصول کمک می کند تا انباشه ی محصول خود را حفظ کند. او می تواند از دستیاری تیم برای حصول اطمینان از این که موارد در انباشه ی محصولش آماده ی گنجیدن در تعریف آماده هستند، بهره ببرد. تعریف انجام شده زمانی مورد استفاده قرار می گیرد که معیارهای کلی ای که برای هر خروجی مورد نیاز است تا توسط صاحب محصول مورد تایید واقع شوند، موجود باشند.