Комментарии к записи: Процессный антипаттерн: шаг с односторонним движением https://mainthing.ru/ru/item/217/ BPM-блог Анатолия Белайчука Sat, 18 Apr 2026 09:04:45 +0000 http://wordpress.org/?v=2.6.5 Автор: Scott https://mainthing.ru/ru/item/217/#comment-673 Scott Mon, 09 Nov 2009 02:27:00 +0000 http://mainthing.ru/?p=217#comment-673 I have to agree that it is shocking how often then "No" case is overlooked. Especially when estimating a process build-out. Because the happy path is less expensive to implement than the "no" path. It isn't as simple as "No." - usually when the VP says no, the submitter/requestor has an opportunity to redress any concerns and re-apply. Then you enter questions as to how many roundtrips should be allowed- and if there are two approvers in the chain, does any change force re-approval by both approvers or only the one who had previously rejected the proposal? The logic can be a little convoluted to get through with the business, but it is work that has to be sorted out! I have to agree that it is shocking how often then “No” case is overlooked. Especially when estimating a process build-out. Because the happy path is less expensive to implement than the “no” path. It isn’t as simple as “No.” - usually when the VP says no, the submitter/requestor has an opportunity to redress any concerns and re-apply. Then you enter questions as to how many roundtrips should be allowed- and if there are two approvers in the chain, does any change force re-approval by both approvers or only the one who had previously rejected the proposal? The logic can be a little convoluted to get through with the business, but it is work that has to be sorted out!

]]> Автор: Keith https://mainthing.ru/ru/item/217/#comment-672 Keith Sun, 08 Nov 2009 19:45:24 +0000 http://mainthing.ru/?p=217#comment-672 I think this example touches on a problem with the design of BPMN notation when you apply it to the field of Human BPM. Both of your example are human "facilitator" diagrams. Making decisions is an inherent part of most human activities, or at least most knowledge worker activities. Like you point out, people can always decide not to do something. Some shallow minded individual will claim that the process should "force" them to do it, but anyone who examines the problem will see that there exist situations that it is the right and correct thing to decline to do the action. This anti-pattern is a good one, and I would suggest that in order to design a system to avoid this problem would be to represent every activity as both an activity and decision. Note that a decision is not the same thing as a branch. A decision is made by a person, and usually, but not always, corresponds to a branch. I wrote this up here: http://kswenson.wordpress.com/2009/04/06/representing-choice-in-a-process-diagram/ The current designers of BPMN are not thinking about people doing the actions, but instead each activity is just a call to a service. Services are not flexible like people, and don't really, as you put it, have free will. Thus BPMN is not designed to make it easy to avoid this antipattern. I think this example touches on a problem with the design of BPMN notation when you apply it to the field of Human BPM. Both of your example are human “facilitator” diagrams. Making decisions is an inherent part of most human activities, or at least most knowledge worker activities. Like you point out, people can always decide not to do something. Some shallow minded individual will claim that the process should “force” them to do it, but anyone who examines the problem will see that there exist situations that it is the right and correct thing to decline to do the action.

This anti-pattern is a good one, and I would suggest that in order to design a system to avoid this problem would be to represent every activity as both an activity and decision. Note that a decision is not the same thing as a branch. A decision is made by a person, and usually, but not always, corresponds to a branch. I wrote this up here:

http://kswenson.wordpress.com/2009/04/06/representing-choice-in-a-process-diagram/

The current designers of BPMN are not thinking about people doing the actions, but instead each activity is just a call to a service. Services are not flexible like people, and don’t really, as you put it, have free will. Thus BPMN is not designed to make it easy to avoid this antipattern.

]]>