بهترین عملکرد ۳ (روشن سازی مدل سازی در برابر پیاده سازی)
ما عقیده داریم که در یک پروژه ی BPM، هردوی – مدل فرآیند و پیاده سازی- ارزش کسب و کاری تولید می کنند. علاوه بر این، پروژه های BPM، اغلب با تغییر سازمانی ای در ارتباط اند که مبتنی بر مدل های متفاوت می باشند و از همین طریق ارتباط برقرار می کنند.
۴٫۱ مدل متای BPM سریع
با در نظر گرفتن این که یک مدل فرآیندی به پروژه ارزش اضافه خواهد کرد و نیاز دارد که قبل از پیاده سازی فرآیند مشخص شود، ما وابستگی های اضافی را که باید مدیریت شوند، تولید می کنیم. یک مشکل متداول در پروژه ی توسعه ی نرم افزار با استفاده از Scrum و User Stories این است که جای تصویر بزرگ یا هدف راهبردی خالی است. ترکیب IBPM و Scrum در یک پروژه ی BPM چابک به حفظ این تصویر بزرگ کمک می کند. بنابراین چندین روش و خروجی در راهبرد ما مورد استفاده قرار گرفته اند.
تصویر۷.مدل متای BPM سریع
در پاراگراف های بعد، مروری کلی و برخی مثال ها را برای برجسته تر کردن ارتباط میان هر دو راهبرد عنوان خواهیم کرد.
مدل متای راهبرد پیشنهادی ما که در تصویر شماره ۷ نشان داده شده است، خروجی ها، روش ها و فعالیت های مختلفی را به تصویر می کشد و نشان می دهد که آنها چگونه با فرآیندها در ارتباط اند. در یک سطح معین از جزئیات، همه ی روابط نشان داده نشده اند. همان طور که مشاهده می شود، طبق تصویر شماره ۶، مدل به موضوعات اصلی مختلفی تقسیم شده است. از دیدگاه BPM، ما فرض می کنیم که پروژه یک مدیر، یک صاحب و چندین شرکت کننده دارد. فرآیندها در ارائه های مختلف وجود دارند. یک بهبود فرآیند از طریق یک پروژه ی جدید آغاز می شود که در آن یک پروژه نقش های متفاوتی دارد. بسته به اندازه ی پروژه، پروژه می تواند شامل یک یا چندین تیم باشد که با هم کار می کنند. هر تیم، طبق ایده ی Scrum، مدیر BPM چابک، صاحب فرآیند BPM چابک و یک ۳ تا ۵ عضو دارد. ما از واژگان متفاوتی استفاده کردیم تا روشن کنیم که آن نقش ها شایستگی های مضاعفی را نیازمندند.
صاحب فرآیند BPM چابک مسئول تعیین نیازهای مشتری می باشد. او باید نیازها را استخراج کرده و به نیازمندی های مناسبی در انباشه ی فرآیند تبدیل کند. اولویت بندی و تخمین انباشه نیز مسئولیت او می باشد. در کنار آن، او مسئول بازگشت سرمایه پروژه نیز می باشد. ضروری است که اگر پرسش یا مشکلی در خلال یک اسپرینت پیش بیاید، او همیشه در دسترس تیم باشد. مدیر BPM چابک مراقب است که به روش BPM چابک، راهبرد پروژه و مسئولیت های مختلف پایبند بمانند. او با BPM و نیز قوانین و راهبردهای چابک آشناست. مخصوصا در فازهای اولیه ی پروژه او مربی و معلم برای کل تیم پروژه بوده و تعادل را در جلسات ملاقات برقرار می سازد. او اولین فرد ارتباطی در مورد هر موضوع مبهم دوپهلو و هر مشکلاتی است که حصول هدف را تهدید می کنند. تیم نقش مشابهی را دارد که در Scrum وجود داشت.
از آنجایی که با یک پروژه ی BPM طرف هستیم، مهارت های لازم برای آن با مهارت مورد نیاز برای پروژه های توسعه ی نرم افزار متفاوت اند. پروژه ها چندین اسپرینت دارند و این اسپرینت ها همبسته به ارائه های فرآیندهای مناسب می باشند. همه ی اسپرینت ها به شیوه ی یکسانی اجرا می شوند. در این نقطه، راهبرد ما بسیار مشابه Scrum می باشد. ما تصمیم گرفتیم که پیرایش انباشه را به عنوان کاری اجباری در پروژه های خود در نظر بگیریم زیرا کشف کردیم که بیش تر پروژه ها از مورد مشابهی استفاده می کنند تا به صاحب پروژه کمک کنند که انباشه را برای اسپرینت های بعدی آماده کند.
۴٫۲ ابزارها و تکنیک ها
ما مجموعه ای از ابزارها و تکنیک ها را که ما را در تحویل پروژه های BPM موفق حمایت می کنند، مشخص کردیم. در ادامه، گلچینی از این ابزارها و تکنیک ها را به عنوان بهترین عملکردها توصیف می کنیم.
با در نظر گرفتن این که ما با پروفایل های کاربر در انباشه ی خود کار می کنیم، سه سطح بررسی چابک IBPM را مبتنی بر ماتریس IBPM (تصویر ۱ را ببینید) برای اهداف و فازهای مختلف (تصویر ۶ را ببینید) توسعه دادیم. آنها تصویر بزرگ را برپا می کنند و کمک می کنند تا خروجی های BPM مورد نیاز برای دست یابی به نشانه ها و اهداف تعیین شده را معین کنیم. هدف آن بررسی های چابک مختلف، پرسیدن سوال های مناسب بسته به سطح جزئیات و راهبرد پروژه می باشد.
تصویر۸٫سطح بررسی چابک IBPM
– آیا به UI احتیاج داریم؟ اگر پاسخ مثبت است، چگونه باید باشد؟
– آیا هیچ نماینده هایی برای قانون کسب و کار در فرآیند وجود دارند؟
– چه نیازمندی های غیر-کارکردی باید در نظر گرفته شوند؟
بهترین عملکرد ۴ (از بررسی پروفایل IBPM استفاده کنید)
شما بهتر است از بررسی پروفایل IBPM (تصویر ۹ را ببینید) در فاز ابتدایی یک پروفایل کاربر جدید استفاده کنید تا تعیین کنید چه موضوعات و وابستگی هایی، این پروفایل خاص ایجاد خواهد کرد. هدف این است که نیازمندی های جدید طبقه بندی شوند و ستون های IBPM مربوطه تعیین شوند. با این که این کار یک بهبود بسیار ساده برای کارت پروفایل است، خیلی به ما کمک می کند که در پروژه هایمان با وابستگی ها کنار بیاییم و تصویر بزرگ را حفظ کنیم. بیایید فرض کنیم که کارت پروفایلی داریم که می گوید: “من به عنوان یک مامور خرید، می خواهم درخواست خرید جدیدی را ایجاد کنم تا فرآیند خرید را آغاز کنم.” این پروفایل از اولویتی برخوردار خواهد شد و تعدادی معیار پذیرش خواهد داشت. در چارچوب ما، علاوه براین، این پروفایل را به یک گام فرآیند خاص می نگاریم. در این مورد “ایجاد درخواست خرید” خواهد بود. این گام فرآیند می تواند مستقیما در مدل فرآیند ما پیدا شود. انجام این کار برای هر پروفایل کاربر به ما کمک خواهد کرد تا مسیر فرآیندهای به هم دوخته شده را دنبال کنیم. یک بهترین عملکرد این است که سه گزینه مرتبط با هر ستون خاص پیشنهاد دهیم: خروجی های موجود، خروجی های مورد نیاز، و خروجی های غیرلازم. بر اساس این اطلاعات می توانیم وظایف و خروجی های خاصی را که باید قبل از اینکه بتوانیم پروفایل را در یک اسپرینت خاص قرار دهیم، تحویل داده شوند، استنتاج نماییم. ما شدیدا پیشنهاد می کنیم که این روش را به تعریف آماده (Definition of Ready) ارتباط دهید.
بهترین عملکرد ۵ (بررسی های چابک IBPM را به کار ببرید)
از سطوح مختلف بررسی های چابک IBPM را که در تصویر ۱۰ نشان داده شده اند، برای تصمیم گیری درباره ی گام های مهم درون یک اسپرینت استفاده کنید. از آنجایی که سطح یک بررسی چابک IBPM تنها در آغاز پروژه استفاده می شود، سه تای دیگر در آماده سازی اسپرینت های بعدی استفاده می شوند. پیرایش انباشه در سطوح ۲ و ۳ حمایت می شوند. هدف، در دسترس سازی نیازمندی ها برای تیم می باشد. بنابراین ضروری است که خروجیهای BPMای که جایشان خالی است را شناسایی کنیم. اگر مصنوعاتی بودند که جایشان خالی بود، می بایست در اسپرینت بعدی به آنها بپردازیم و آنها را برطرف کنیم. از آنجایی که IBPM خروجی های فراوانی را تعیین می کند، اجباری نیست که به همه ی آنها دست پیدا کنیم. در پروژه های BPM چابک، پروفایل کاربر مرتبط به عنوان راهنما استفاده می شود که چه خروجی هایی باید در نظر گرفته شوند. تیم تعیین می کند که کدام یک از خروجی ها برای کسب و کار و تنظیمات فناوری اطلاعات ارزش آوری خواهد نمود.
تصویر۹٫بررسی پروفایل IBPM
همه ی این بررسی ها مجموعه ی وسیعی از خروجی ها را تولید می کنند. خروجی ها یا به یک فرآیند و یا به پروژه و یا به روش ها مرتبط می شوند. برای کنار آمدن با پیچیدگی و برای درک روابط آنها، از مدل متا نشان داده شده در ابتدای این بخش استفاده می کنیم.
بهترین عملکرد ۶ ( تغییر چارچوب به دلخواه)
برای تفکر دقیق راجع به تغییرات دلخواه مورد نیاز پروژه، زمانی را اختصاص دهید. بسته به مشکلات یا پرسش های خاص، راه هایی برای حل مسائل با بهره گیری از برخی از بهترین عملکردهای ما وجود دارد. نکته ای که برخی اوقات منجر به پرسش هایی می شود، امکان پذیر بودن اجرای نیازمندی ها در یک اسپرینت می باشد. برای کسب اطمینان از اینکه هر یک از نیازمندی هایی که وارد یک اسپرینت می شود، با موفقیت به انجام خواهد رسید، تعریف آماده یا Definition of Ready معین می کند که چه چیزی باید قبل از تحقق، تحویل داده شود. یکی از بهترین عملکردها این است که پیرایش انباشه را برای تعیین تقاضای اطلاعات برای یک یا دو اسپرینت بعدی انجام دهیم. در شرایطی که تیم و صاحب فرآیند BPM سریع تشخیص دهند که جای یکی از خروجی ها خالی است، زمان کافی برای جمع آوری یا ایجاد اطلاعات مورد نیاز، وجود دارد.
بهترین عملکرد ۷ ( از گروه های با فاصله ی زمانی برای دورنماهای کسب وکار و فنی در صورت نیاز استفاده کنید)
اگر پروفایل ها بسیار پیچیده باشند، از تیم های موازی با فاصله ی زمانی برای تولید موارد انباشه با انحرافی معادل یک اسپرینت استفاده کنید. یک تیم نماینده ی دورنمای کسب و کار بوده و نیازمندی هایی را که سپس توسط تیم دوم پیاده سازی خواهند شد، شکل می دهد. این راهبرد با قوانین چابک در تضاد است اما برخی اوقات کمک می کند تا حداقل برخی از ایده هایش را در یک پروژه قرار دهیم.
بهترین عملکرد ۸ (در حین پیشرفت پروژه پروفایل ها را از حالت افقی به حالت عمودی تنظیم کنید)
از دورنمای توسعه محصول، پروفایل های کاربران باید عمودی باشند (یعنی یک ویژگی/ فعالیت به صورت عمقی). در غیر این صورت نمی توانند هیچ سودی تولید کنند. در مقابل، پروژه های BPM مرتبط با توسعه ی محصول نیستند. ما تشخیص دادیم که اغلب پروفایل های افقی کاربران هستند که در آغاز یک پروژه به شکل غالبی وجود دارند (click-dummy فرآیند). آنها به افراد کمک می کنند که بفهمند فرآیندشان چه شکلی خواهد بود و چه حالتی خواهد داشت. بعدها بسیار آسان تر خواهد بود که تعیین کنیم کدام ابعاد باید به شکل عمودی نظر گرفته شوند.
تصویر۱۰٫آمادگی اسپرینت با بررسی های سریع IBPM
همین طور که پروژه در حال پیش رفت است، پروفایل های کاربر را از حالت افقی به عمودی تنظیم کنید.
۵ تجربه
در تجارب حرفه ای، چندین پروژه را تحلیل کرده و از آنها درس هایی را آموخته ایم. بیش تر پروژه هایی که موفقیت کمتری داشتند، از مشکلات یکسانی رنج می برند. راهبردهای آبشاری-محور قادر نبودند از منافع BPMS مدرن بهره ببرند. زمان بین طرح ریزی اولیه، تحلیل، فاز طراحی و پیاده سازی نهایی سبب کاهش پذیرش نهایی توسط مشتری و کمبود توجه به مدیریت و اغلب نیازمندی های کسب و کاری تغییریافته می شود.
اولین تجربه های عملی از کاربرد چارچوب پیشنهادی بسیار امیدوارکننده اند. چندین پروژه داشتیم که با موفقیت مبتنی بر چارچوب پیشنهادی به انجام رسیدند. ما مشاهده نمودیم که طبقه بندی محیط پروژه یکی از مسائل کلیدی برای پروژه های BPM موفق است (بهترین عملکرد ۲ را ببینید). در پروژه هایی که در آنها از راهبردهای چابک برای اهداف نادرست استفاده شده است، مثلا فقط برای اینکه طبق جدیدترین روندهای علمی روز به نظر برسند، ما تشخیص دادیم که آنها نه موفق بودند و نه تاکیدی بر قوانین چابک داشتند. صحبت با اعضای پروژه روشن ساخت که این کار تنها به تباهی امکانات اولیه انجامیده بود. یکی از اهداف ما ارائه ی راهنمایی هایی است که به پروژه های BPM کمک می کند تا بین راهبردهای کلاسیک و چابک، انتخاب خود را انجام دهند. در ادامه یکی از پروژه های اخیر خود را معرفی می کنیم که چگونگی استفاده از چارچوب طراحی شده برای ملزومات خاص را به شکل برجسته ای نمایش می دهد.
۵٫۱ پروژه ی پرتال خدماتی
در سپتامبر ۲۰۱۲، شرکت ما پروژه ای را راه اندازی کرد تا پرتال خدمات از راه دوری را مبتنی بر محصولات بسازد. قبل از اینکه پروژه آغاز شود، پارامترهایی را که می توانستند پروژه را تحت تاثیر قرار دهند، در نظر گرفتیم. نتیجه ی طبقه بندی ما (طبق تصویر ۵) بیان کرد که با انتظارات ما از یک محیط چابک همخوانی داشت. پروژه با بازه زمانی معین و منابع مشخصی تعریف شده بود.
از آنجایی که پروژه مبتنی بر محصولات محوری ما بود، معماری فنی همچنین در گام اولیه ی پروژه به خوبی تعیین شده بود. یک بعد مهم دیگر، ملزومات فازی در ابتدای پروژه بود که بیش تر به یک تصور شباهت داشت تا مسائل مشخص. پارامترهای بنیادی پروژه می توانند به شکل زیر خلاصه شوند. ما یک تیم تنها داشتیم که قابلیت فعالیت های چندگانه و بین المللی را داشت اما هیچ تجربه ی قبلی با روش های چابک نداشت. در این پروژه ما با آموزش تیم آغاز کردیم و انتصاب مدیر BPM چابک را انجام دادیم. علاوه بر آن ما صاحب محصول BPM چابک را با آماده کردن داستان ها بر طبق تعریف خود، حمایت نمودیم. از آنجایی که تیم هیچ تجربه ای درباره IBPM یا Scrum نداشت، تصمیم گرفتیم که با مجموعه ی خلاصه شده ای از خروجی ها، کار را آغاز کنیم. در کنار کمبود تجربه در حوزه ی BPM چابک، ما مجبور بودیم که با تفاوت های فرهنگی هم رو به رو شویم. افرادی که گروه را تشکیل می دادند اهالی سنگاپور، آمریکا و آلمان بودند. با این وجود، ما فازهای معینی را پشت سر گذاشتیم (تصویر ۶ را ببینید) که به تیم کمک می کرد تا کار خود را مخصوصا در کارگاه ها و اسپرینت های ابتدایی، چندین بار ساختاردهی کنند.
تیم تصمیم گرفت تا با اسپرینتی به طول یک هفته کار را آغاز کند. آنها به چندین دلیل کار را با این فرکانس بالا آغاز کردند. اول از همه آنها می خواستند راجع به راهبرد BPM سریع چیزهای بیش تری یاد بگیرند و می خواستند سریع تر به آن عادت کنند. از دیگر سو، آنها ملزومات فازی ای داشتند و می خواستند در مواجهه با انباشه فرآیند به شدت در حال تغییر، منعطف باقی بمانند. در پایان پروژه، تصمیم آنها سبب ارزش افزوده ای شد. در خلال پروژه افراد بسیار از نتایج و راهبرد پروژه راضی بودند. قبل از اینکه پروژه آغاز شود، یک شک بارز در میان افراد وجود داشت. آنها شک داشتند که چگونه یک تیم تازه شکل گرفته و بین المللی می توانست نتیجه ی قابل توجهی را در چنین پروژه ی کوتاه مدتی تولید کند. نتایج پروژه ی ما نشان داده است که بیشتر مسائل می توانند مبتنی بر استفاده از قوانین چابک که پیش تر توضیح داده شد، حل شوند.
۵٫۲ درس های آموخته شده
ما یاد گرفتیم فرآیندی که برای همکاری، به وضوح تعریف شده باشد، به انتقال دانش و تاثیرگذاری شتاب می دهد. از تجربه ی خود آموختیم که اگر با دورنماهای کوچکی در پروژه های چابک آغاز کنیم، کار بهتر پیش می رود. مهم ترین چیز برای آغاز کردن راهبردهای چابک، پیدا کردن یک آغازگر پروژه است که با ملزومات یک راهبرد چابک همخوانی دارد. سعی نکنید راهبرد چابک را در پروژه ای فقط برای اینکه بگویید دارید چنین کاری می کنید، به کار بسته و پیاده سازی کنید، زیرا در بسیاری از موارد این کار نتیجه ی خوبی نخواهد داد.
علاوه بر این ما پی بردیم که ادارات فناوری اطلاعات اغلب در بازه های کوتاه مدت می اندیشند. متاسفانه، در بسیاری از موارد، ادارات کسب و کار آماده نیستند تا به طریق مشابهی فکر کنند. سازمان آنها از بازخوردهای مداوم و زودهنگام استقبال نمی کند زیرا آنها روی بسیاری از پروژه های مختلف کار می کنند و نمی توانند همه ی تمرکز خود را روی یک پروژه قرار دهند. در مورد این قضیه راهبرد ما نمی تواند پیشنهادی کلی ارائه دهد زیرا هر شرکتی به شیوه ی خاص خود سازمان دهی می شود. ما تنها می توانیم بگوییم که افراد از ادارات کسب و کار باید حداقل نیمی از زمان خود را برای پروژه ای خاص در نظر بگیرند زیرا در غیر این صورت ممکن نخواهد بود که نبض کسب و کار و فناوری اطلاعات را هم راستا کنیم.
همچنین در ذهن داشته باشید که یکی از مهم ترین چیزها این است که همه چیز را ساده نگه دارید. نمی گوییم از چارچوب ما به شکل متعصبانه ای پیروی کنید ولی حرف ما این است که مسیری واقع بینانه و عملی و متناسب شرایط تان را پیدا کنید. وقتی ما شروع می کنیم که با راهبرد خود کار کنیم، افراد و دانش آنها را در نظر می گیریم و سپس به طور متوالی روش ها، ابزارها و خروجی هایی را وارد کار می کنیم.
۶ کار مرتبط
روش های BPM می توانند بر پایه ی تمرکز ( سازمان، فرآیند یا سطح پروژه) یا هدفی (طراحی مجدد فرآیند کسب و کار یا بهبودهای مداوم فرآیند) که دارند، تقسیم بندی شوند. BPM سازمانی بر روی برقراری BPM در سراسر سازمان تمرکز دارد. این امر به ما کمک می کند که ابتکارهای پروژه را تشخیص دهیم، پس زمینه های کاربردی پیچیده را مدیریت کنیم و BPM را مبتنی بر یک راهبرد ریسک-محور بهبود بخشیم. روش های six-sigma DMAIC ، RummlerBrache ، یا Jeston and Nelis بر سطح فرآیند تمرکز دارند.
علاوه بر آن روش ها، تعدادی راهبرد دیگر نیز وجود دارند. با این اوصاف بیش تر تمرکز روی سطح فرآیند و کمک به تعیین بهبودهای محتمل فرآیند می باشد. شیوه های BPM موجود در یعنی IBPM به واحدهای کسب و کار کمک می کند تا به طور دقیقی ملزومات خود را به عنوان مدل های فرآیند و خروجی های مربوطه بیان کنند. چرخه سنتی BPM (مدل، پیاده سازی، اجرا، تحلیل) چگونگی ارائه ی ملزومات مستند شده به اداره فناوری اطلاعات برای پیاده سازی را معین می کند.
در ارزیابی شیوه ها و راهبردهای چابک، ما بر روی محبوب ترین شیوه ها مانند Scrum و Kanban تمرکز کردیم. Scrum اساساً چارچوبی برای توسعه ی محصولات نرم افزاری پیچیده می باشد. ما از Scrum در این راهبرد استفاده کردیم زیرا به خوبی با راهبرد IBPM همخوانی دارد.
در خلال سال گذشته، ما تشخیص دادیم که علاقه ی قوی تری در این موضوع در بخش دانشگاهی و نیز صنعتی به وجود آمده است. موازی با پایان نامه ای که این مقاله از آن استنتاج شده است، تحقیقات و بررسی های دیگری هم در این موضوع انجام شده بود. یکی از آنها مطالعه ای است که تایید می کند که راهبردهای چابک به شکل فزاینده ای با پروژه های فرآیند-محور انطباق دارند. Wauch و Meyer در مقاله ی کنفرانسی خود، راهبردی را برای ایجاد یک سازمان BPM چابک در شرکت توضیح می دهند. موضوع دیگر، افزایش کنونی در خدمات ابری و ترکیب آنها با BPM و روش های چابک می باشد.
۷ نتیجه گیری
این مقاله یک روش پروژه ی BPM چابک را که مبتنی بر روش BPM موجود و یک چارچوب توسعه ی نرم افزار چابک می باشد، معرفی کرد. در مقابل روش های BPM موجود، روش چابک پیشنهادی با جاسازی دقیق نیازهای مشتری درون پیاده سازی فرآیند، روی نیازهای مشتری تمرکز می کند.
در نتیجه، دو گام اول از چرخه BPM سنتی (یعنی مدل سازی و پیاده سازی) در هم ادغام می شوند که نتیجه ی آن فرآیندهای “بهتر” است زیرا ادارات کسب و کار با ادارات فناوری اطلاعات در چرخه های نزدیکی با هم کار می کنند تا فرآیندهایی را پیاده سازی کنند که واقعا مورد نیاز می باشند. از آنجا که کسب و کار، درک بهتری از چیزی که می خواهد در هر تکرار انجام دهد پیدا می کند، گیج کنندگی فرآیند ها در مراحل اولیه از بین می رود. به دلیل فرکانس بالای چرخه های بازخورد و تقارن و هم زمانی روزانه ی پیش رفت، ما پی بردیم که راهبردهای چابک محیط پروژه ی بسیار روشنی را فراهم می آورند.
در حالی که اولین نتایج عملی بسیار تشویق کننده اند، در تحقیق در حال انجام خود، پروژه های BPM بیش تری را تحلیل خواهیم کرد و نتایج را برای حصول پیشنهادات درباره ی کنار آمدن با دشواری های موجود، بررسی خواهیم نمود. در آن صورت قطعا چارچوب پیشنهادی حمایت دقیق تری از مشکلات مختلف پروژه ها ارائه خواهد کرد.
پایان
لطفا توجه بفرمایید
رویکرد تدریس ما در دوره های مدیریت فرایند کاملاً منطبق با رویکردهای چابک جدید مطرح در حوزه مدیریت فرایند در سطح جهان است.
در مورد دوره آموزش مدیریت فرایند از اینجا اطلاعات بیشتر کسب نمایید.