Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Процессный антипаттерн: шаг с односторонним движением

Этот антипаттерн почти тривиален. Но судя по тому, что разные люди в разных проектах совершают одну и ту же ошибку, популярность его высока :)

Пример 1: процесс заключения договора. Ближе к завершению процесса договор должен быть подписан с нашей стороны директором:

диаграмма BPMN

Хотя бы из уважения к директору дайте ему возможность не подписать договор - предусмотрите развилку (gateway) сразу за шагом “подписать договор”.

Пример 2: в процессе выполнения заказа клиента компания-посредник размещает заказ у партнера:

диаграмма BPMN

Признайте наличие свободы воли у партнера, предусмотрите возможность того, что он не примет наш заказ и отразите эту возможность развилкой на схеме процесса.

Тут возникает вопрос меры: с одной стороны, никто не отменял рекомендацию начать моделирование процесса с т.н. “happy path” - максимального гладкого варианта протекания процесса. И в happy path приведенные диаграммы вполне уместны.

С другой стороны, а бывают ли вообще шаги с предопределенным результатом - может быть, надо проверять результат работы после каждого шага?

Вряд ли стоит загромождать схему, ставя проверки везде и всюду. Урок, который преподносит данный антипаттерн, можно сформулировать так: для начала поставьте проверки там, где явно просматривается свободная воля - например, лица принимающего решения или независимой от нас организации.

02.11.09 | Статьи | , ,    

Комментарии (2)

  1. Keith 08.11.09 22:45

    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.

  2. Scott 09.11.09 05:27

    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!

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии