متدولوژی عملیاتی BPM - قسمت پنجم

در قسمت چهارم این مطلب، فاز سوم متدولوژی عملیاتی BPM ارائه گردید. در این مطلب فاز ۴ یعنی طراحی (Design) ارائه می شود.

 

فاز 4: طراحی (Design)

زمانی که به فاز طراحی می رسیم، پروژه بسیار سریع در حال انجام است. هدف اصلی فاز طراحی، دستیابی به بهترین راهکار مدیریت فرآیند و ساخت یک نمونه اولیه برای اطمینان از امکان اجرایی بودن آن است. موارد زیر، خلاصه کلیه ی وظایفی که در این فاز مطرح می گردد را بیان می کند:

بهینه سازی طراحی فرآیندهای کسب و کار

  • کارگاه های آموزشی برای دستیابی به سناریوهای فرآیندی برگزار گردد.
  • پیش نویس فرآیند جایگزین تهیه گردد.
  • برای دستیابی به بهترین فرآیند جایگزین از شبیه ساز استفاده کنید.
  • فرآیند جایگزین را با شبیه سازی و پالایش های مکرر بهینه سازی کنید.

 

ساخت نمونه اولیه (Prototype) فرآیند

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

 

تکمیل جزئیات راهکار

  • چارت سازمانی را بر اساس طراحی جدید به روز رسانی کنید.
  • جزئیات جریان فرآیند را طراحی کنید.
  • مدل فنی راهکار فرآیند را پیاده سازی کنید.
  • مستندات طراحی عملیاتی (Functional Design) را کامل کنید.

 

تیم تغییر کسب و کار، مسئول طراحی فرآیند در این فاز است. برای دریافت سناریوی فرآیند و نظرات، جلسات و کارگاه های آموزشی با تمامی ذینفعان کسب و کار برگزار می شود. پس از دریافت نظرات ذینفعان، تیم تغییر با کمک کارشناسان طراحی، به یک جمع بندی کلی از فرآیند طراحی شده دست می یابد. فرآیند طراحی شده بوسیله ابزار طراحی فرآیند BPMS و شبیه سازها اجرا می گردد تا مناسب ترین فرآیند جایگزین گردد. به عبارت ساده تر،فرآیندها همانند لایه های یک پیاز هستند که هنگام بررسی، هر لایه جزئیات بیشتری مطرح می گردد. بنابراین فرآیند انتخاب شده همانند دنیای واقعی در چرخه شبیه سازی و پالایش قرار می گیرد تا تمامی نقاط تصمیم گیری، مسیرهای فرآیندی و استثنائات آن مورد بازبینی قرار گیرد. علاقه مندان به مطالب بیشتر در رابطه با تکنیک های تحلیل و طراحی فرآیند می توانند کتاب های Harmon و Burlton در این زمینه را مطالعه کنند.

همزمان که طراحی فرآیندها مورد بازبینی قرار می گیرند، کارشناسان طراحی چارت سازمانی باید ساختار سازمانی را بر اساس این تغییرات به روز رسانی کنند. این تغییرات می تواند همچون تغییر عنوان یک شغل، ساده یا مانند ایجاد و حذف یک واحد سازمانی، بنیادی باشد. خروجی کار تیم تغییرات چارت سازمانی در این فاز شامل موارد زیر است:

  • شرح شغل ها
  • نقش ها
  • فعالیت ها
  • فرآیندهای کسب و کار

در انتهای این فاز باید نقش های درگیر در فرآیندها و فعالیت های آتی (to-be) نهایی شده باشند.

برای مشخص شدن امکان پیاده سازی فرآیند آتی، باید یک نمونه اولیه از آن ساخته شود. نمونه اولیه باید شامل ویژگی های اصلی فرآیند باشد. مثلاً اگر قرار باشد فرآیند با سایر برنامه های کاربردی سازمان یکپارچه شود؛ در نمونه اولیه حداقل یکی از این یکپارچگی ها پیاده سازی شود. نمونه اولیه حاصل تلاش مشترک تیم های "تغییر کسب و کار" و "توسعه" است. در این میان تیم توسعه این شانس را دارد که تا حدودی با فرآیند آشنا شود و میزان کدنویسی آن را پیش بینی کند. در حالی که در متدولوژی آبشاری، توسعه دهندگان بعد از اتمام کار تیم اجرایی می توانستند درگیر پروژه شوند.

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

معمار برنامه های کاربردی سازمان برای ساخت نمونه اولیه فرآیند یک مدل فنی سطح بالا طراحی می کند. مدلسازی او شامل یک مدل داده (Data Model) و یک مدل مولفه (Component Model) است.

در گذشته در متدولوژی شی گرا برای ثبت تغییرات وضعیت شی و جریان فعالیت های فرآیند از نمودارهای توالی (Sequence Diagram)  و انتقال وضعیت (State transition) استفاده می شد؛ در صورتی که طبق رویکرد طراحی در BPMS ها این دو نمودار به عنوان قسمتی از طراحی فرآیند در ابزار بصورت گرافیکی مدل می شوند. این امر مزیت یکپارچگی بین مدلسازی و توسعه را به همراه دارد؛ زیرا توسعه دهنده می تواند به سادگی منطق کد نویسی را به فرآیند مدل شده اضافه کند و معمار برنامه های کاربردی سازمان نیز به جای وقت گذاشتن بر روی طراحی نمودارهای برهم کنش (Interaction) تنها به طراحی توابع (Function) هر مولفه می پردازد.

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

در صورتی که برای طراحی وب، مدلی از سمت سازمان پیشنهاد نشده باشد طراح وب می تواند با چند طراحی پیشنهادی انتخاب را به عهده تیم پروژه بگذارد. برای اطمینان از طراحی و پیاده سازی تمامی ویژگی های در نظر گرفته شده نمونه اولیه، باید کارشناس طراحی فرآیند با تیم توسعه - در حین ساخت - همکاری داشته باشد.

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

متدولوژی BPM و بهره گیری از ابزار BPMS فاصله بین نیازمندی ها و توسعه دهندگان را کمتر می کنند. ماژول طراحی فرآیند BPMS هر دو لایه جریان فرآیندها و منطق برنامه نویسی آن ها را پوشش می دهد. در لایه برنامه نویسی جزئیات به فرآیندها اضافه می شود که مواردی همچون یکپارچگی با سایر برنامه های کاربردی و بهره گیری از وب سرویس ها را در بر می گیرد. کارشناسان طراحی فرآیند، وظیفه طراحی فرآیندهای کسب و کار - لایه سطح بالا - را بر عهده دارند و پس از آن ها تیم توسعه برنامه نویسی منطق کسب و کار - لایه سطح پایین - را انجام می دهد.

ساخت نمونه اولیه فرآیند، فرصت خوبی برای همکاری بین تیم های راهکار و فنی است تا فاصله میان این دو تیم کمتر شود. کارشناسان طراحی فرآیند - از تیم تغییر کسب و کار- جریان فرآیند ها را مدلسازی می کنند و تیم توسعه نیز برنامه نویسی منطق کسب و کار، یکپارچگی با برنامه های کاربردی دیگر و بهره گیری از وب سرویس ها را پیاده سازی می کند. آماده سازی مستندات طراحی نیز فرصت مناسبی برای این همکاری است. در حالی که تیم تغییر، مسئولیت مستندسازی طراحی عملیاتی را بر عهده دارد؛ تیم توسعه نیز برای تکمیل مستندات به آن کمک می کند.

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

ادامه در متدولوژی عملیاتی BPM - قسمت ششم


نویسنده:  James F.Chang

منبع: کتاب Business Process Management System - فصل ۱۰

ترجمه: سهیل نیک فرجام


 

درباره رایورز

شرکت مهندسی نرم‌افزار رایورز در اوایل سال 1368 توسط جمعی‌از فعالین حرفه نرم‌افزار تأسیس گردید...

بیشتر بدانید

ارتباط با ما

  • تهران، خيابان ولی عصر، نرسيده به توانير، خيابان احتشام، شماره 5
  • 89326000

  • BPMS@rayvarz.com

خبرنامه پایگاه دانش BPM