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

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

Моделирование в BPMN решений, принимаемых людьми

К сожалению, вопрос “как в BPMN моделировать решения, принимаемые людьми” не относится к числу часто задаваемых.

“К сожалению” потому, что ответ, который новичку кажется очевидным, на самом деле неправилен. Это вот не развилка, это распараллеливание процесса:

На выходе из задачи “Рассмотреть заявку” процесс продолжится параллельно по исходящим ветвям вне зависимости от того, что на них написано.

Правильная BPMN-диаграмма выглядит так:

При этом подразумевается, что у процесса есть атрибут “Одобрено” типа boolean. Пользователь на шаге “Рассмотреть заявку” задает значение этого атрибута, а в развилке оно проверяется, и процесс продолжается по одной из ветвей.

Как видим, авторы BPMN не стали вводить специальную конструкцию для решений, принимаемых человеком, а реализовали их при помощи достаточно искусственной конструкции: специальный атрибут, который надо задать и сразу после этого проверить в развилке.

Пользовательский интерфейс для шага, на котором принимается решение, выглядит примерно так:

По кнопке “Выполнено” форма закрывается, и задача считается выполненной.

Я согласен с мнением Кейта Свенсона, что отказ от явной поддержки в BPMN решений, принимаемых человеком, был неудачным ходом.

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

Будь моя воля, я бы ввел в BPMN явную поддержку решений, принимаемых людьми. Так как первая диаграмма вверху на самом деле интуитивно больше походит на принятие решения, чем правильная BPMN-диаграмма, я бы оттолкнулся от нее:

Здесь к существующим типам потока управления Control Flow, Conditional Flow и Uncontrolled Flow добавлен еще один: Human Controlled Flow, помеченный двойной поперечной черточкой.

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

Если от человека требуют принять решение, то форма должна выглядеть так:

Кнопки можно было бы создавать автоматически исходя из приведенной выше диаграммы.

Впрочем, такой подход можно ведь практиковать и для стандартных BPMN-диаграмм:

Нужно убрать кнопку “Выполнено”, а вместо нее добавить кнопки “Одобрить” и “Отказать”, привязав к каждой по два действия: присвоить значение атрибуту и завершить задачу.

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

27.12.10 | Статьи | , , ,    

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

  1. Dr. Martin Bartonitz 27.12.10 22:33
  2. Anatoly Belychook 27.12.10 23:44

    Martin

    Thank you for the input and for the link to google group I found in Keith’s comment to your post.

    Of course the pattern itself isn’t new - the first part of the post is mostly for those who are new to BPMN. How do you feel about “Human Controlled Flow”? Unfortunately the existing Controlled Flow misses XOR logic.

    Anyway, I wrote it mostly to talk about UI part of the problem: I realized recently that human routing must be rendered differently than normal user task and that we can do it even within today’s BPMN.

  3. Bruce Silver 30.12.10 06:30

    Keith Swenson has been urging something like this for a long time. For me, it is not significantly different from conditional sequence flow, and I would have the same objection to your diagram whether it had diamonds or double slashes on the tails: It is not clear that the two output paths are exclusive alternatives or inclusive. You depend on human understanding of the label instead of the explicit behavior of XOR gateway. Whether two paths in a process level are alternatives or parallel flows is crucial to the downstream process. If you were to say that the double slash always means exclusive human choice, I think it would be a harmless addition to the palette, and apparently a welcome one to some people.

  4. Anatoly Belychook 30.12.10 08:42

    Bruce

    Thank you for sharing your thoughts. Of course the human controlled flows are supposed to be exclusive.

  5. Andrew Stesin 30.12.10 13:06

    К слову, а как правильнее обозначить задачу “Рассмотреть заявку” - как “пользовательскую” (с человечком) или как “неавтоматизированную” (с “ладошкой”)?

  6. Anatoly Belychook 30.12.10 16:22

    Конечно как User. Manual task вообще проходит мимо системы; workflow-движок проскакивает ее не задерживаясь. Фактически это комментарий аналитика: “а в это время…”.

  7. Scott 10.01.11 05:29

    interestingly, Lombardi (now Websphere Lombardi Edition) implements something very much like this for user interfaces, and it is quite intuitive and efficient. the UI drives the possible endpoints, rather than the other way around (which makes sense actually).

  8. Marco Brambilla 11.01.11 12:45

    I fully agree this is a weakness of BPMN.
    We propose an approach based on “user gateways”, you may want to read about it here:
    http://marcobrambi.blogspot.com/2011/01/user-gateways-in-bpmn.html
    Do you think this could be helpful?

  9. Anatoly Belychook 13.01.11 07:42

    Marco

    I considered the option you proposed, too. But for me human decision is a task rather than BPMN-style pure (task-less) gateway.

    E.g. when a person in charge decides to reject an application, he must specify the reason; when approving, he must specify some other data like budgetig item. We may set up Approve and Reject buttons so that thet will be unavailable until the requested data are entered. Can it be done within your approach?

    Kind regards
    Anatoly

  10. Keith 14.01.11 21:45

    Thanks for continuing the discussion on this. Your example of adding the response buttons the UI is exactly what we do in Interstage BPM. What is particularly dramatic is that we can edit a process even while it is running, so to simply add a new line from one activity to another instantly adds the new “completion choice” to the UI. It really reduces the complexity.

    More posts on BPMN at: http://social-biz.org/tag/bpmn/ and http://social-biz.org/tag/bpm/

  11. Keith 14.01.11 21:48

    One more thing: we used the circular “event” symbol because it is natural to represent this choice as an event. Events are exclusive, just like choices. Events happen at a point in time, just like choices. The activity is started and remains in active mode, until completion, either by event or choice. While the activity is active, the worklist item appears on the users worklist, and is removed from the worklist when either an event comes, or a choice is made. To me, the user choice is really just another kind of event.

  12. Илья Логинов 11.04.12 20:20

    Что значит автоматическая развилка, а что решение человека? Я так понимаю вы имеете в виду решение человека как нажатие кнопки явное или явное ДА в электронной почте или устно. А автоматическая, это решение после обработки на основании данных? А зачем их разделить? Решение человека это часть задачи, часть его работы и было бы некорректно это микро действие выносить за пределы задачи в какие то там ромбики или отдельные обозначения стрелок. Ибо решение человека, являясь частью задачи может Сопровождаться входящими данными. Во общем считаю удачным ходом отсутствие разделения - решение человека это часть задачи, а не часть чего то за ее пределами, не часть передачи управления след задаче

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

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