اين ارايه شامل نحوه استفاده از notationهاي كاربردي BPMN در مدلسازي فرآيندهاي كسب و كار است. caseهاي عنوان شده در فايل، برگرفته از patternهاي استاندارد BPMN مي باشد.
this presentation is about how to practically use BPMN in process modelling. the cases are derived from BPMN Patterns.
در اين فايل، سعي شده است علاوه بر معرفي notionهاي كاربردي BPMN يك سري نكات كه بايستي در مدلسازي مدنظر قرار گيرد عنوان شود.
همچنين در خصوص patternهاي BPMN صحبت خواهد شد. Patternها الگوهاي استاندارد يا در واقع Best practiceهايي هستند كه براي مدلسازي يك مساله قابل استفاده هستند. به عنوان مثال، نياز داريد: درخواستي براي 5 نفر ارسال شود، به محض اين كه 2 نفر از آنها درخواست را پاسخ گفتند فرآيند منتظر اعلام نظر 3 نفر ديگر نمانده و روند خود را طي كند.
اين صورت مساله، شايد به طرق مختلف قابل حل باشد ولي با استفاده از patternيي كه براي حل مسايل مشابه وجود دارد ميتوان به سادگي و با استفاده از حداقل notion، آن را ترسيم نمود.
بالغ بر 40 الگوي استاندارد براي BPMN مطرح شده است.
در Caseهايي كه در بخش نهايي اين فايل آورده شده است، سعي شده است صرفاًpatternهاي كاربردي مورد استفاده و معرفي قرار گيرند. به دليل كاهش پيچيدگي مباحث از ذكر عنوان patternها خودداري شده است. در حدود 15 pattern در اين Caseها استفاده شده است.
BPMN استانداردی است حاوی اشکال گرافیکی که برای مدلسازی در حوزه کسب و کار مورد استفاده قرار می گیرد و قابلیت این را دارد که با سیستم های اطلاعاتی و محیط شیرپوینت ارتباط برقرار کند. خروجی آن به صورت زبان BPEL این امکان را فراهم می سازد.
دیاگرام Collaboration شامل چند pool می باشد.
دیاگرام Choreographies تمرکز بر ارتباطات میان poolها در دیاگرام Collaboration دارد.
دیاگرام Conversation تمرکز بر ارتباطات میان اجزای دیاگرام Choreographies دارد.
ولی تمرکز ما به دیاگرام های فرآیندهای کسب و کار است که به آن اصطلاحاً BPD گفته می شود
پوستر حاوی تمام اشکال گرافیکی BPMN
BPMN حاوی بیش از شکل گرافیکی است که تمامی آنها توسط تمامی ابزارها پشتیبیانی نمیشود و بسیاری از آنها نیز توسط متخصصین به درستی درک نشده اند.
غالباً استفاده از حدود 20 نماد برای ترسیم مدل فرآیند کفایت می کند.
ابزارهایی که فلش آبی در کنار آنها است در sampleها مورد استفاده قرار گرفته است.
ابزارهایی که فلش آبی در کنار آنها است در sampleها مورد استفاده قرار گرفته است.
ابزارهایی که فلش آبی در کنار آنها است در sampleها مورد استفاده قرار گرفته است.
ابزارهایی که فلش آبی در کنار آنها است در sampleها مورد استفاده قرار گرفته است.
ابزارهایی که فلش آبی در کنار آنها است در sampleها مورد استفاده قرار گرفته است.
اگرچه BPMN یک استاندارد برای مدلسازی ارایه میکند لیکن نرم افزارهای مختلفی هستند که بالواقع این الگوها را رعایت نمیکند و ماحصل مدل طراحی شده توسط آنها ابداً شکل استاندارد ندارد و به خاطر استاندارد نبودن قابل فهم توسط مشتری نیستند. برای قابل فهم بودن باید چند نکته رعایت شود.
اولین و مهمترین نکته که باید رعایت شود رعایت سادگی در طراحی است.
در نظر داشته باشید این مدل باید توسط افراد غیرفنی و غیرحرفهای نیز قابل درک باشد.
فرایند را در ابتدا ساده ببینید و هم آنچه هست را مدل نمایید.
پیش بینی تغییرات را از ابتدا دیده و مدل ایده ال را مدنظرداشته باشید.
به آرامی و به صورت مستمر مدل را ارتقا بخشید
تمامی nodeها بایستی دارای نقطه ی پایان و خاتمه باشند.
تنها یک نقطه شروع برای هر مدل بایستی وجود داشته باشد.
نقاط شروع متفاوت می توانند تعریف شوند لیکن بسته به شرایط خاص تنها باید یکی از آنها اتفاق بیافتد.
ترجیحاً حداکثر 15 فعالیت در یک دیاگرام ترسیم شود و از زیرفرآیند برای ترسیم بخش/ بخشهایی از فرآیند استفاده گردد.
دیاگرام را خلاصه کنید و زمانی که امکان ادغام چند نماد است درنگ نکنید.
تمام فعالیت ها یا taskهایی که در دیاگرام وجود دارد از جنس user task هستند حتماً باید دارای مسوول در سازمان باشند.
درخواست مرخصي توسط متقاضي ارايه ميشود. مدير متقاضي درخواست را بررسي مينمايد. در صورت عدم تاييد، اطلاعرساني عدم مرخصي و در صورت تاييد، اطلاعرساني تاييد به متقاضي ارسال ميگردد.
از طريق service task اطلاعات مانده مرخصي متقاضي از سيستم اطلاعاتي ديگر اخذ ميشود. متقاضي درخواست خود را صادر ميكند. پس از تاييد مدير، به صورت همزمان، هم اطلاع رساني به متقاضي انجام ميشود و هم اطلاعات مرخصي متقاضي در سيستم تردد و كاركرد وي ثبت ميگردد. استفاده از link intermediate event اين امكان را فراهم ميسازد كه مدل فرآيندي خلوتتري داشته باشيم و كمتر از Sequence flow استفاده نماييم.
اطلاعرساني تاييد مرخصي، در صورتي كه 3 روز گذشته و به رويت متقاضي نرسيده باشد خاتمه مييابد و از كارتابل وي حذف ميگردد.
متقاضي درخواست خدمات كامپيوتري خود را ثبت ميكند. مدير درخوست را يا تاييد يا رد ميكند. در صورت تاييد،درخواست به مركز تماس ميرسد. مركز تماس يا خود درخواست را انجام ميدهد يا آن را به توزيعكننده ميفرستد. توزيعكننده درخواست به يك مجري يا مجريان متعدد ميتواند ارجاع دهد. در نهايت كه تمامي مجريان كار خود را انجام دادند بررسي نهايي توسط توزيع كننده انجام ميشود و اطلاع رساني انجام ميشود. در اينجا از نوعي subprocess تحت عنوان multiple استفاده كرديم و شرط خروج از آن را «اتمام تمامي instanceها» قرار دادهاي بدين معني كه بايستي تمامي مجريان روي فعاليت خود اقدام نموده باشند و اقدام ايشان تاييد شده باشد تا از زيرفرآيند خارج شويم و به گام «بررسي نهايي» رويم.
اقدام انجام شده بين هر يك از مجريان و توزيعكننده گردش ميكند تا بالاخره به تاييد توزيع كننده برسد. هر اقدام كه تعيين تكليف شد منتظر ميماند تا اقدام ساير مجريان نيز تعيين تكليف شود.
Gatewayها دو نقش دارند :1- split 2- merge
در اين ويرايش، درخواست متقاضي هم براي مدير مستقيم هم براي جانشين وي ارسال ميشود (توسط parallel gateway در واقع split ميشود). وقتي merge از طريق exclusive gateway انجام شود تنها يك تاييد (از طرف مدير يا جانشينوي)كافي است تا درخواست به مركز تماس ارسال شود. اگر merge از طريق complex gateway انجام شده بود به معني انجام n تا از m بود. در اين مثال،استفاده از exclusive يا complex فرقي نميكند چون m 2 تا است.
متقاضي جهت رفتن به ماموريت شهرستان درخواست خود را ارسال ميكند. درخواست وي،در صورتي كه ماموريت مربوط به پروژه خاصي باشد بايستي به تاييد مدير پروژه برسد در غير اين صورت تاييد مدير سازماني كافي است.
پس از اخذ تاييدات لازم، درخواست به تاييد واحد اداري رسيده و حكم ماموريت فرد صادر ميشود.
به صورت همزمان هم حكم به متقاضي ابلاغ ميشود و هم درخواستهاي بليط و عليالحساب در صورتي كه مورد نياز متقاضي باشد به واحدهاي روابط عمومي و مالي ارسال ميگردد.
استفاده از inclusive gateway اين امكان را فراهم ميسازد كه يك يا تمامي نودها انتخاب شوند. (يعني فرد ممكن است تنها بليط بخواهد يا تنها علي الحساب و يا امكان دارد هر دو مورد نياز وي باشد. بسته به شروط برنامه، يك يا هر دو انتخاب ميشوند)
در اين مثال، به خاطر اين كه بعد از درخواست بليط و علي الحساب هيچ gatway جهت merge كردن نيامده است،بنابراين لازم نيست حتماً وضعيت هر دو منبع مورد نياز (بليط يا عليالحساب) تا فرآيند خاتمه يابد و هر يك به صورت جداگانه طي شده و خاتمه مييابند.
در ويرايش 2، درخواستهاي بليط و عليالحساب با يكديگر توسط inclusive gateway ، merge شدهاند و اين بدان معني است كه حتماً بايستي هر دوي اين Taskها به نتيجه رسيده باشند تا فرآيند ادامه يابد.
در ويرايش 3،به منظور سهولت فهم مدل فرآيندي از فازبندي يا اصطلاحاً milestone استفاده شده است.
در اين مدل فرآيندي، براي خلوت شدن مدل فرآيندي و سهولت فهم آن، كليه تاييدات در داخل يك Subprocess انجام شده است. اين زيرفرآيند از جنس embedded بوده است يعني اين زيرفرآيند از جنس خود فرآيند ميباشد و صرفاً جهت سادهسازي مدل فرآيندي به كار رفته است.
زيرفرآيند تاييدات ماموريت شهرستان، به اين شكل است. شروع فرآيند با يك شرط است اين شرط بيان ميدارد كه آيا تاييد مدير پروژه نيز لازم است يا خير، در صورتي كه تاييد مدير پروژه لازم بود فرآيند از مدير پروژه شروع ميشود. در غير اين صورت،فرآيند از مدير سازماني شروع ميشود.
علامت terminate به اين معناست كه چنانچه درخواست توسط مديران پذيرفته نشود كل فرآيند منهدم شود. در صورتي كه end به معناي آن است كه زيرفرآيند خاتمه يافته و جريان فرآيند اصلي ميتواند ادامه يابد. البته Terminate در زيرفرآيند زماني اين مفهوم را دارد كه embeded subprocess داشته باشيم. در خصوص multiple subprocess به اين شكل قابل مدلسازي نيست.
ويرايش 5 درخواست ماموريت شهرستان،كل تهيه منابع را نيز به دليل سادهسازي مدل فرآيندي داخل يك embeded subprocess قرار ميدهد. خروجي اين subprocess اطلاعرساني به متقاضي در خصوص منابع تهيه شده است.
زيرفرآيند درخواست تهيه منابع به اين شكل ميباشد. همان چيزي كه در فرآيند پدر وجود داشت به يك subprocess منتقل گرديد.
ممكن است به دلايلي امكان تهيه بليط يا پرداخت علي الحساب ميسر نباشد. اين مساله را ميتوان با compensate كه به Task ضميمه شده است نمايش داد. هنگام Attach كردن اين event به task، بايد روال جبران نيز تعريف شود كه غالباً به صورت manual انجام ميشود و به اين شكل نمايش مييابد.
حال براي اين كه متقاضي متوجه شود چه منابعي از منابع مورد نياز وي تهيه نشده است، بايستي subprocess به نوعي از جنس transaction تغيير يابد، يك cancel event به آن attach شود و اطلاع رساني تهيه منابع تهيه نشده به متقاضي صورت گيرد.
به جاي استفاده از copmpensate در ويرايش قبل،ميتوان اين مساله را با اين رويكرد مدل نمود. (لازم به ذكر است براي مدلسازي يك نيازمندي، ممكن است راهها و solutionها يا به اصطلاح patternهاي مختلف وجود داشته باشد. )مثلاً در مثال بالا، در صورتي كه خريد بليط انجام شد يا امكان خريد بليط فراهم نشد،هر يك كه اتفاق بيفتند شاخه مربوط به تهيه بليط تعيين تكليف شده است و منتظر علي الحساب ميماند تا آن نيز تعيين تكليف شود و زيرفرآيند به اتمام برسد.
در اين مثال،خريد بليط از طرف واحد روابط عمومي به آژانس مسافرتي ارسال ميشود. آژانس مسافرتي يك partner است و فرآيند خود را دارد. ارتباط اين دو از طريق message است.
واحد روابط عمومي، درخواست خريد بليط هواپيما را از طريق يك intermediate event از جنس message به آژانس اعلام ميكند. فرآيند مربوط به خريد بليط در آژانس شروع ميشود. پس از آن، درخواست در يك gateway از جنس Event based منتظر ميماند تا يكي از دو اتفاق روي دهد. يعني يا بليط خريداري شده و پيام از طرف آژانس برسد. يا روابط عمومي اعلام نمايد كه امكان خريد بليط نيست.
در اين مثال،فرآيندي كه در آژانس هواپيمايي صورت ميگيرد از ما پوشيده است و به صورت يك black box نمايش داده ميشود.