Understanding BPMN gateways: a visual guide

Denys Gobov, CBAP, PMI-PBA, PhD the whole problem lies in three things: 1) most process designers are not well educated in BPMN, 2) BPMN does not provide clear use cases and 3) the learning resources and materials from BPMN and training organizations are not good enough. You are trying to provide a visual guide to educate the community. That is very welcome. But it is still steps away from a visual guide that will teach many.

Nice. But you’ve only covered flows out. It would be worth covering flows in, too.

Thanks for sharing Denys Gobov, CBAP, PMI-PBA, PhD In my opinion, choosing the appropriate modeling standards, notation symbols, and level of detail primarily depends on the objective of documenting the business process. It is also essential to ensure that the process model remains clear and easily understandable to all stakeholders — whether internal or external.

Цікава демонстрація. Особливо корисним тут вважаю згадку про Event-based шлюз, про який може і не входить по переліку інтуітивно зрозумілих але він є іноді єдиним вірним рішенням при обробці подій.

Круті пости в такому стилі. Дякую за цю рубрику!

Thanks and always interesting.. back in the 80s there was an ITU standard ...standard description language (SDL) recommendation Z.101, I even have a paper copy! Very very similar... Used extensively in Telco and on network and internet inter working protocol designs...x.25 and ISDN.. thus ideal for process and state machines... The but is.. today it's global interconnected, user experience based trusted real time information systems , designed from a dev ops operational perspective, thus the tool set is not process flow and state design diagramatic tools ...but platform based chassis on which networked, web centric, click action, software systems are evolved around usability, decision support, regulatory compliance and productivity...

Thanks for sharing, Denys Gobov, CBAP, PMI-PBA, PhD I believe that these notational symbols are based on the conditions that are dependent on the nature of the business processes itself wither if its objective is simplified or complexed. From my experience, I found that there are two common grounds: 1) Misunderstandings between parallel and inclusive gateways not because it is hard to grasp, but rather it’s because the conditions behind it could be either subjective (due to discrepancy of data gathering, and/or there may be no legacy system in place to capture actual data) or fear from covering up the actual pain-points in the process itself from stakeholders. 2) Business Rules - which are in most cases to be considered as the backend approach - they set up the constraints on how the as-is process model is implemented and executed by several stakeholders. Once the accuracy of communication is captured, it’ll become clearly feasible to tackle changes in the business process model from as-is to future state based on factors such as value status (Added/Not Added), impact level, severity and so on.

Great real examples!