Напомню, что дорожки (lane в BPMN 2.0, swimlane в BPMN 1.x) изображают исполнителей процесса.
Правила для дорожек:
- Дорожки опциональны – диаграмма может обходиться без них.
- Дорожки могут быть вложенными (иерархическими).
- Семантика дорожек может быть любой, на усмотрение автора диаграммы – подразделение, роль, должность…
- Встроенные подпроцессы (embedded subprocesses) не имеют пулов и, следовательно, не могут иметь дорожек.
- Дорожки имеют отношение только к задачам, исполняемым людьми (user task) – автоматическим задачам (service task, script task), подпроцессам, развилкам, событиям все равно на какую дорожку вы их поместили.
- Даже для задач, назначаемых людям, дорожки по сути является комментариями – реальный исполнитель задается в атрибутах модели для данной задачи.
Начинающие пользователи BPMN любят дорожки и с энтузиазмом рисуют их в своих первых диаграммах:
Рис.1. BPMN-диаграмма с дорожками.
Однако, используя дорожки, вы лишаете себя возможности показать на магистральный путь процесса (happy path), что, возможно, является более ценным с точки зрения легкости восприятия схемы процесса:
Рис.2. BPMN-диаграмма, на которой показан магистральный путь процесса.
Когда же вы переходите к масштабным задачам, то обнаруживаете, что в них применить дорожки не получается.
Дело в том, что существует универсальное правило, применимое к любой нотации, не только BPMN: число активностей на одном уровне диаграммы не должно превосходить 7-9. Иначе схему становится сложно воспринимать:
Рис.3. “Плоская” диаграмма с большим числом активностей сложна для понимания.
Соответственно, если процесс состоит из большего числа задач, его следует подвергнуть структурной декомпозиции – разбить на подпроцессы:
Рис.4. С помощью подпроцессов сложный процесс можно изобразить в виде простой диаграммы.
Однако в этом стиле моделирования для дорожек не остается места:
- На верхнем уровне остаются только подпроцессы, а дорожки относятся только к задачам, исполняемым людьми (правило 5).
- На схеме подпроцесса нет ни пула, ни дорожек (правило 4).
Точнее, правило 4 относится только к встроенным процессам, а в повторно-используемых процессах дорожки могут быть. Мне приходилось видеть диаграммы, в которых авторы использовали повторно-используемые подпроцессы вместо встроенных исключительно для того, чтобы иметь возможность изобразить дорожки. Это плохая практика – для структурной декомпозиции следует применять встроенные подпроцессы. Повторно-используемые подпроцессы привносят неоправданную дополнительную сложность, так как, в отличие от встроенных, они исполняются в собственном контексте данных.
Если вам так уж необходимо показать исполнителей на схеме встроенного подпроцесса, используйте BPMN-артефакт «группа»:
Рис.5. Исполнители во встроенном подпроцессе изображены группами.
Great article, Anatoly!
Here you touched on one issue that I meet almost every day. The fact that lanes cannot be included in sub-process (unless they are global) frustrates many process analysts that don’t fully understand the logic behind BPMN rules. And that becomes especially hot when they move from a drawing tool to a real modelling tool that does not allow and/or alerts on semantic errors. But probably lanes come as frustration number two or three. Number one in my experience is the inability to have message flows reaching nodes inside sub-processes. Or at least that’s the thing I spent most time explaining. The absolute dependency (data- and control-wise) of the sub-process on its parent seems very difficult for many people to understand. Should we ask them to try harder or maybe it’s time BPMN got friendlier to their needs without losing its execution capabilities.
Kind regards,
Ivo
Interesting thought, Ivo. I don’t see any particular logic in forbidding swimlanes in subprocesses, too. OK, there is one reason but it’s pure technical: no pool therefore no swimlanes. Guess they could find a workaround.
Вы говорите, что семантика дорожек может быть любой, таким образом, описывайте некий шаблон (полноценный стандарт), как нужно строить диаграммы бизнес-процессов.
Как Вы считаете, возможно, ли создание стандартов выполнения бизнес-процессов в организации, не с точки зрения конкретики (например, заказ должен быть оплачен в течение трех дней), а с точки зрения выполнения бизнес-процесса как такового на концептуальном уровне (например, на схеме событий типа «сообщение» должно быть в количестве 5)? Это своего рода перерастает в некий стандарт, на который можно в последствии накладывать на конкретные данные (бизнес-процессы в организации). Спасибо
Ирина
Эффективное применение BPMN в организации требует выработки внутреннего стандарта по моделированию. Это необходимо из-за того, что BPMN позволяет моделировать одно и то же несколькими разными способами. В частности, в таком стандарте может быть сказано, что дорожками мы моделируем подразделения.
Anatoly -
would you say you’re arguing more for limiting the use of swim lanes, or limiting the use of re-usable subprocesses (if just for the purpose of getting swim lanes)?
The way I read it (could be wrong) you’re not arguing one shouldn’t use swim lanes, just that the spec and the use of proper model decomposition make it hard to use swim lanes properly without using re-usable subprocesses… but I may be misreading.
The issue with swimlanes is that they are a useful analytical device for identifying process improvement, but as this great article shows they make end user adoption very difficult. Why - the ability to lay out a swimlane makes the diagram too large to be easily displayed on a browser, iPad or smartphone. Printed and stuck on an office wall is no longer good enough with a mobile workforce.
Scott
Well I didn’t mean to give recommendations, just to explain what can and what can’t be done with swimlanes. BPMN was intentionally desinged as methodology-neutral so there is no single truth there. But there are rules that confine modeler’s freedom and I just wanted to clarify them for novice BPMN users.
My personal position is this: one can’t bring secondary aspects to the diagram without compromising primary things, i.e. making them less clear. For me, the control flow is primary and participants are secondary.
So for really complex processes swimlanes are luxury we can’t afford; happy path style diagram are 1) more informative, 2) more compact as Ian noted and 3) are scalable in BPMN because unlike swimlane style diagrams they don’t suffer from process decomposition into subprocesses.
BTW, I apply the same principles to data flows: there are data objects in BPMN but they are secondary with respect to control flow. Data objects/stores become primary issue only in interprocess communications, see http://mainthing.ru/ru/item/434/
Anatoly,
While I disagree with some of your “rules” about lanes (#4 is incorrect, for example), I agree with the general points you make. I have noticed that people who really care about lanes, such as process improvement consultants, prefer the flat modeling style, as opposed to architects, who favor hierarchical modeling. If you care about handoffs between lanes in your process improvement methodology, flat models work better. I have had a difficult time using lanes effectively in my Method and Style approach, which favors the hierarchical style.
–Bruce
Bruce
Thank you for the valuable input.
Regarding #4 “Embedded subprocesses do not have pools and therefore can’t have lanes” - which part of it is incorrect?
- Is it possible to draw a pool on embedded subprocess diagram (apart from external entities and processes others than the one the subprocess belong to)? I’t be very confusing: we already used the pool for the top-level process.
- Is it possible to draw lanes without pools on embedded subprocess diagram? The spec (p.282) says “A Lane is a sub-partition within a Pool or a Process”. It’s hard to imagine lanes without a pool.
Lanes are sub-partitions within a Pool or a Process. However, you are allowed to remove the boundary of at most one Pool (participant) in Collaboration. So, for me that impies that I can use lanes without a pool. So I can use it within a subprocess as well. Anyway I am not sure is that a real problem. I need lanes only when I need to stress that there is a “more” complicated “structure” of an organisation involved in process.
Szymon
You are probably right but it raises a question about the quality of BPMN spec: better have it explicit rather than guessing of what’s implied. At the end of the day each vendor would follow its own judgement.
It’s not a real problem for you neither for me but it is for many people as comments above witness.
Как раз расположение подпроцесса на дорожке очень удобно - видно ответственное лицо за контроль исполнения подпроцесса, которое вправе изменить структуру подпроцесса по ходу выполнения экземпляра в случае если это не изменит результат на выходе из подпроцесса в худшую сторону (например вмешаться в подпроцесс нарушить его форсмажорно и тем самым ускорить выполнение подпроцесса). Важная роль дорожек для подпроцессов неоднократно раскрывалась разработчиками стандарта. Поэтому странно, что дорожкам нет места где подпроцессы или может я вас не так понял.