نمونه های BPMN

نمونه های واقعی BPMN 2. 0 و پاسخ به سوالات رایج.

سبک های مدل سازی BPMN

مدل ساز آنلاین

مدل ساز ما یک ابزار آنلاین و دسکتاپ برای طراحی، بحث و تبادل نظر و به اشتراک گذاری نمودارهای BPMN با تیم شما است.

بررسی اجمالی

ما BPMN را به هزاران نفر آموزش داده‌ایم و از سال 2007 نماد را در کار پروژه روزانه خود به کار می‌بریم. در زیر می‌توانید نمونه‌های BPMN زیادی از مشکلات مدل‌سازی رایج را بیابید. صرف نظر از پروژه خاص یا صنعت شما، سوالات رایج زیادی در مورد استفاده از BPMN وجود دارد. در تجربه ما، بیشتر نمونه های BPMN زیر برای هر کاربر BPMN مفید است.

ما در سال 2009 به عنوان یک عضو تأثیرگذار به OMG پیوستیم. از آن زمان، ما در توسعه BPMN 2. 0 شرکت کرده ایم.

نمونه های BPMN

قوانین کسب و کار و BPMN

سناریوی مدلسازی

فرض کنید می‌خواهیم فرآیندی را در BPMN مدل‌سازی کنیم و این فرآیند برخی قوانین تجاری را القا می‌کند. ما از مثال ایجاد یک لایحه استفاده خواهیم کرد. برای ایجاد صورتحساب، باید تخفیف محاسبه شود. مجموع سفارش و نوع مشتری معیارهای مربوطه برای محاسبه تخفیف است.

این یک مثال بسیار ساده است که به ما نشان می دهد که کجا BPMN را اعمال کنیم و کجا نه.

راه حل به عنوان نمودار BPMN 2. 0

توضیح

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

مدل کردن محاسبه خود تخفیف در مدل BPMN منطقی نیست (به مثال زیر مراجعه کنید). برای درخت تصمیم قوانین، برای هر معیار اضافی، کاردینالیته ها به صورت تصاعدی رشد می کنند. این چیزی نیست که ما در مدل BPMN می خواهیم.

بنابراین، تفکیک قوانین فرآیند و تجارت منطقی است.

راه اشتباه برای مدل کردن آن

نمونه های وابسته

سناریوی مدلسازی

فرض کنید می خواهیم یک فرآیند را با نمونه های همزمان مدل کنیم. ما از یک مثال ساده استفاده می کنیم. اگر یک بررسی اعتباری یک مشتری در حال اجرا باشد، نمی‌خواهیم اعتبار دیگری برای همان مشتری در همان زمان انجام شود.

دلیل آن می تواند این باشد که تعداد کل چک های اعتباری انجام شده بر نتیجه چک تأثیر می گذارد.

بیایید فرض کنیم که ما در حال اجرای یک بررسی اعتباری برای یک مشتری هستیم و در همان زمان درخواست دوم را برای همان مشتری دریافت می کنیم.

وجه مشترک همه راه حل ها این است که هر نمونه جدید باید قبل از شروع بررسی اعتبار واقعی، موارد همزمان در سطح داده را بررسی کند.

راه حل با رویداد سیگنال

از همان مشتری؟

توضیح

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

راه حل با رویداد پیام

از همان مشتری؟

از همان مشتری؟

برای انتظار بررسی کنید

توضیح

این راه حل کمی پیچیده تر است، زیرا باید گیرنده (یک نمونه) پیام را تعیین کنید. این یک درخواست داده دوم را قبل از پایان نمونه القا می کند. با این حال، این راه صحیح برای حل مشکلی است که در راه حل رویداد سیگنال رخ می دهد.

راه حل با تایمر و حلقه

از همان مشتری؟

توضیح

در این مثال ما نیازی به ارتباط بین نمونه ها نداریم. اگر بتواند به بررسی اعتباری ادامه دهد، خود نمونه تناوب را بررسی می کند. نکته منفی این است که ممکن است باعث تاخیر و سربار به دلیل حلقه شود.

اصل چهار چشم

سناریوی مدلسازی

ما می خواهیم وضعیت زیر را با استفاده از BPMN 2. 0 مدل کنیم. برای درخواست (به عنوان مثال ، پرداخت) به دو مصوبه دو نفر مختلف مورد نیاز است. یک موتور فرآیند باید اطمینان حاصل کند که هر دو مصوبات قبل از تأیید درخواست برآورده می شوند. مراحل دستی که توسط دو تأیید کننده انجام می شود نیز باید در نمودار BPMN مدل سازی شود. تصمیم تصویب با استفاده از پورتال با لیست کار انجام می شود.

موارد استفاده

موارد استفاده برای این الگوی بیشمار است. در اینجا چند مثال آورده شده است:

• تصویب پرداخت
• تصویب فاکتور
• تصویب قرارداد
• …

راه حل به عنوان نمودار BPMN 2. 0

توضیح

ما از استخرهای جداگانه برای موتور فرآیند ، برای اولین بار و برای تأیید کننده 2 استفاده می کنیم. به این ترتیب ، ما می توانیم به وضوح تعریف کنیم که چه کسی کنترل کدام فرآیند را دارد.

در استخر موتور از کارهای کاربر استفاده می شود. این وظایف کاربر مطابق با وظایفی است که در لیست وظیفه از 1 و 2 تأیید کننده نشان داده شده است.

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

به منظور کاهش پیچیدگی ، لیست کار خود مدل سازی نشده است.

تغییرات

تأیید کننده به عنوان استخرهای فرو ریخته

تعیین تأیید با LDAP

صورتحساب ماهانه

سناریوی مدلسازی

این مثال یک مبارزه بسیار رایج با ساختار نمودارهای BPMN 2. 0 را توضیح می دهد. بیایید بگوییم یک وکیل وجود دارد که به مشتریان خود مشاوره حقوقی ارائه می دهد. این سرویس به شرح زیر است: مشتریان می توانند هر زمان که به آن نیاز داشته باشند ، مشاوره حقوقی بخواهند. وکیل مشاوره درخواست شده را ارائه می دهد و ساعات قابل پرداخت را در برگه زمانی مشتری قرار می دهد. هنگامی که ماه به پایان رسید ، حسابدار وکالت ساعات قابل پرداخت را بر اساس برگه زمانی تعیین می کند و فاکتور را ایجاد می کند.

این مثال یک سناریوی مدل سازی بسیار متداول را نشان می دهد. این مراحل فرآیندهای دشوار نیست ، بلکه ساختار نمودار است.

راه حل به عنوان نمودار BPMN 2. 0

مشاوره حقوقی

ایجاد و ارسال

توضیح

مهمترین جنبه نمودار ساختار آن است.

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

البته این دو استخر کاملاً مستقل از یکدیگر نیستند. چرا؟آنها روی همان داده ها کار می کنند - برگه زمانی مشتری. توانایی ما برای مدل سازی چنین اتصال مرتبط با داده در BPMN بسیار محدود است. این به این دلیل است که BPMN به جای جریان داده ها بر جریان کنترل متمرکز است.

با این حال ، ما می توانیم از عنصر فروشگاه داده برای مدل سازی این اتصال در سطح داده استفاده کنیم.

راه اشتباه برای مدل کردن آن

مشاوره حقوقی

ایجاد و ارسال

توضیح اینکه چرا این اشتباه است

در این مثال ، هر دو فرآیند به یک مخلوط می شوند. این - در بهترین حالت - روشی بسیار ضمنی برای مدل سازی آن است. این بدان معناست که برای هر مشاوره حقوقی ارائه شده ، فاکتور پس از پایان ماه ارسال می شود. این روش مدل سازی در بیشتر موارد اشتباه است.

اطلاعات اضافی مورد نیاز پس از کار کاربر

سناریوی مدلسازی

بیایید فرض کنیم که می خواهیم سناریوی زیر را مدل کنیم: ما می خواهیم یک کار کاربر را اجرا کنیم که توسط یک کاربر در یک پورتال انجام می شود. پس از اتمام کار کاربر ، ممکن است اطلاعات اضافی لازم باشد. در این صورت ، موتور فرآیند درخواست اطلاعات را به کاربر دیگری (راه حل 1) یا به یک سرویس فنی (راه حل 2) ارسال می کند.

راه حل 1: درخواست اطلاعات از کاربر دیگر

راه حل 2: درخواست اطلاعات از یک سرویس فنی

برخی از خدمات فنی

پردازش دسته ای از سفارشات از یک بازار

موقعیت

ما می خواهیم سناریوی زیر را با استفاده از BPMN 2. 0 الگوبرداری کنیم: فرض کنیم یک شرکت از کانال های مختلف توزیع سفارشات دریافت می کند. یکی از این کانال ها یک بازار است. در فواصل مشخصی از زمان ، سفارشات موجود در بازار به عنوان دسته ای به دست می آید. قبل از وارد کردن به سیستم ERP ، هر سفارش در این دسته باید تأیید شود.

راه حل به عنوان نمودار BPMN 2. 0

سفارشات را از بازار به ERP وارد کنید

وارد کردن سفارش به

برای هر تک

توضیحات

این مثال سناریوی مدل سازی بسیار متداول را نشان می دهد. ما گاهی اوقات آن را یک مشکل 1-به N می نامیم. یک نمونه فرآیند (واردات سفارشات) منجر به بسیاری از نمونه های فرآیند واحد دیگر (سیستم ERP) می شود. سازه های معمولی چند نمونه یا حلقه هایی هستند که سایر فرآیندهای را با استفاده از پیام ها (جریان پیام) شروع می کنند.

تعیین مجدد وظایف کاربر

سناریوی مدلسازی

بیایید فرض کنیم که ما باید اطمینان حاصل کنیم که قطعاً یک کار کاربر خاص انجام شده است. بنابراین ، وظایف کاربر باید به محض عدم دسترسی به شخص فعلی ، به عنوان مثال ، به دلیل ترک یا بیماری ، مجدداً تنظیم شود.

راه حل 1: رویداد مرزی پیام و سرویس انتقال مجدد

این امر منطقی است اگر موتور برای تعیین تکلیف جدید با یک سرویس تماس بگیرد.

راه حل 2: رویداد مرزی پیام و قوانین انتصاب

این امر منطقی است اگر موتور برای تعیین تکلیف جدید با موتور قاعده تماس بگیرد.

راه حل 3: رویداد مرزی پیام و انتصاب مجدد ضمنی

این امر منطقی است که اگر موتور خود را به عنوان یک انتساب جدید ، به عنوان مثال ، با استفاده از یک عبارت تعیین کند.

تشدید دو مرحله

سناریوی مدلسازی

ما از مثال زیر برای نشان دادن نحوه مدل سازی یک تشدید دو مرحله با استفاده از BPMN 2. 0 استفاده خواهیم کرد. وقتی پیتزا می خواهیم ، یکی را سفارش می دهیم. گاهی اوقات تحویل پیتزا پیچ می شود و زایمان بیش از 30 دقیقه طول می کشد. سپس از خدمات تحویل شکایت می کنیم. پس از آن ، ما 20 دقیقه دیگر به آنها می دهیم تا پیتزا را تحویل دهند. اگر آنها آن را به موقع انجام ندهند ، ما تسلیم می شویم و سفارش خود را لغو می کنیم.

راه حل 1: دو دروازه مبتنی بر رویداد

مزایای این راه حل

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

مضرات این راه حل

دروازه مبتنی بر رویداد یک نماد BPMN بصری از استاندارد BPMN نیست ، تجربه لازم است.

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

راه حل 2: با تایمرهای پیوست شده کار را دریافت کنید

مزایای این راه حل

این مدل از راه حل اول کوچکتر است و احتمالاً روشی که بیشتر توسعه دهندگان مشکل را روی موتور حل می کنند. از آنجا که ما از یک رویداد تایمر ضمیمه ای بدون وقفه استفاده می کنیم ، این راه حل در هنگام شکایات متعدد انعطاف پذیرتر است (به عنوان مثال ، ما می خواهیم هر 5 دقیقه شکایت کنیم تا 50 دقیقه تمام شود).

مضرات این راه حل

وظیفه دریافت معمولاً برای "بچه های تجاری" شهودی نیست ، که ترجیح می دهند از پیام دریافت می کنند برای آن نوع وضعیت انتظار.

روشی که همکاری تایمر قطع کننده و بدون وقفه نیاز به درک عمیق از وقایع پیوست دارد.

راه حل 3: یک دروازه مبتنی بر رویداد با تایمر عمومی

"عمومی" در این

مزایای این راه حل

این مدل راه حل جمع و جور و عمومی برای مشکل است. اگر صحبت از تشدید N-Step شود ، برای جلوگیری از نمودارهای عظیم به این روش عمومی نیاز خواهید داشت.

مضرات این راه حل

راه حل عمومی نسبت به سایر راه حل ها کمتر صریح است. ما مدت زمان واقعی تایمرها را نمی بینیم ، زیرا یک تایمر واحد برای هر دو مدت استفاده می شود.

برای درک سریع از تشدید دو مرحله ، این روش مدل سازی مناسب نیست.

سبک های مدل سازی BPMN

از عبور از جریان خودداری کنید

توصیه

این مثال BPMN در مورد ایجاد یک طرح خوب از مدل های فرآیند است. هرچه طرح بهتر باشد ، درجه درک بالاتر می رود. این همان چیزی است که ما می خواهیم هنگام ایجاد مدل های فرآیند به آن دست یابیم.

سعی کنید تا حد امکان از عبور از جریان خودداری کنید. این باعث افزایش درک مدل های فرآیند BPMN - برای کاربران BPMN با تجربه و بی تجربه می شود.

البته همیشه جلوگیری از این مشکل همیشه امکان پذیر نیست. به خاطر داشته باشید که همیشه معقول است که برای بهینه سازی طرح به گونه ای سرمایه گذاری کنید که بیشتر جریان های عبور از بین بروند.<Pan> مضرات این راه حل