Что касается дорожек в моделере, то проблема такая есть, но обходится она легко: используйте повторно-используемые подпроцессы.

Как сейчас обстоят дела в Bizagi с возможностью использовать дорожки внутри подпроцессов? Ранее (год назад примерно), как я помню, это было затруднительно.

Постараюсь объяснить:

Допустим, мы имеем некий сквозной процесс “от звонка клиента до доставки клиенту”, который мы моделируем “на самом верхнем уровне” как два пула: “клиент” как черный ящик и сам наш процесс; процесс (happy way) показываем в пуле развернуто и совсем крупно как последовательность, например, десяти подпроцессов, реализуем (указываем) межпроцессные взаимодействия.

Далее мы хотим начать “углубляться” (структурно декомпозировать подпроцессы до уровня исполнителей/ролей). Например, моделируем первый подпроцесс “обработка входящего звонка” (если клиент звонит первый раз, если второй раз, если новый клиент, если не новый, если постоянный ну и так далее), который подразумевает при его исполнении подключение разных ролей (в простых случаях Марина (операторы), в средних - саентолог Коля (отдела кирбистов, на разных этапах) и в тяжёлых - Михалпетрович (подразделения гипноза и зомбирования). То есть имеется некое интуитивное желание/необходимость разделить роли и описать подпроцесс “по ролям”, используя пул и для каждой роли дорожки. Архитектура процессов в таком случае видится как “пирамида процессов” - набор от вершины к основанию.

Имеет место быть такая практика описания “от общего к частному” при моделировании/описании неисполняемых процессов? Или такая логика описания процессов ущербна (допустим, что все задачи процесса синхронны [пусть workflow для примера])? Извините за легкомысленный стиль изложения - я надеюсь, мне удалось выразить суть вопроса.

There are two use cases for subprocesses:

1) Process decomposition. The best practice for these are collapsed subprocesses I believe.

2) “Technical subprocess” to implement certain workflow pattern. For example, non-interruptive attached events behaviour can be implemented with a subprocess within BPMN 1.x palette. In this case expanded subprocesses may be useful.

If there are more than one processes on the diagram then you may draw just one of them without the pool - the canvas becomes the pool. There are enough such examples in the spec.

Lanes in the subprocesses are allowed but your remark about performer is valid and should be addressed. Here is how I personally approach this today, three years after the posting.

Let’s separate performers - people who actually do the work and assgnee - human, entity or role responsible for the work to be done. In case of atomic activity i.e. task they are the same. In case of a subprocess the lane specifies assignee but not necessarily a performer - there may be several performers and hense lanes at the next level of details.

Does anyone use the lanes - from my observations yes, most of people do.

My guess is that sub processes are just as much activities as tasks. And it matters in which lane task is positioned. Sao maybe lanes in subprocesses are not allowed because, if you used lanes in you top level diagram and your collapsed subproces is in “sales” lane, all of it’s tasks be done by “sales” not “production.” If that is the case, BPMN 3.0 should state that subprocess is process not activity and it doesn’t matter in which lane subprocess is positioned (same as events and gatways).

Or maybe it is because collapsed and expanded subproceses should be interchangeable, but lanes in expanded subprocesses are nonsense (visually). In this case they should just dump expanded subprocesses from notation. I mean — DOES ANYONE USE THEM AT ALL???

For me, subprocesses are the way to introduce levels of abstractions. The less top-level diagram “knows” about internal structure of a subprocess the better. From this perspective we shouldn’t make suggestions about what lanes may be needed to depict subprocess activities and hence we would be unable to define the common root lane.

Besides, they very likely would not have such a common root except the company as a whole.

Yet there is another idea to combine subprocesses and lanes: to depict the unit *responsible* for the subprocess, not the performer(s). In case of a task they are the same, in case of a subprocess there are many performers yet very well may be a single responsible/coordinating business unit or role.

How do you like this?

As I understand the specification, lanes can be nested. Why, then, cannot the decomposition of a lane be shown in a sub-process?

There would need to be certain caveats to this. For example, that the lanes do not already appear at a higher level of the hierarchy in the process set. I am sure there are others…

I welcome your thoughts.

Steve