Напомню, что дорожки (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/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.
Как раз расположение подпроцесса на дорожке очень удобно - видно ответственное лицо за контроль исполнения подпроцесса, которое вправе изменить структуру подпроцесса по ходу выполнения экземпляра в случае если это не изменит результат на выходе из подпроцесса в худшую сторону (например вмешаться в подпроцесс нарушить его форсмажорно и тем самым ускорить выполнение подпроцесса). Важная роль дорожек для подпроцессов неоднократно раскрывалась разработчиками стандарта. Поэтому странно, что дорожкам нет места где подпроцессы или может я вас не так понял.
Илья
А ведь Вы правы: стандарт говорит, что дорожки имеют смысл для активностей, т.е. и для подпроцессов тоже.
Стал разбираться с чего я взял, что дорожки имеют смысл только для user task - по-видимому, из книги Брюса Силвера “BPMN Method & Style”, стр. 36: “Lanes usually just make sense for human task”. Но он фактически говорит о стиля, а у меня он трансформировался в правило.
Спасибо за находку.
Nice summation of the principle concerns and some enthusiastic contributions … the crux seems to be the following:
“Regarding #4 “Embedded subprocesses do not have pools and therefore can’t have lanes” - which part of it is incorrect?”
I think this is based on an over-zealous interpretation of the BPMN specification by the tool developers; in other words, while it is true that the sub-process cannot have a pool, the BPMN specification does not specify that the sub-process cannot have (swim)lanes.
Here’s why I think lanes in sub-processes should be permitted:
1) Implicitly a sub-process has a pool, because it is in a pool and inherits attributes of its parent.
2) Therefore, everything within a sub-process must logically take place in its parent lane.
3) As there are no theoretical limits to nesting lanes.
4) Therefore, a sub-process should be able to have lanes, so long as those lanes are semantically nested within the parent lane.
An example of this might be a lane for a warehouse and a sub-process for order picking. Within the sub-process, we should be able to have lanes that represent various direct operational responsibilities (e.g. fork-lift, aisle pickers, consignment packers, etc.), as well as any appropriate management and support responsibilities (e.g. warehouse administration, damaged goods bay, etc.).
David
You are absolutely right and my initital statement is wrong - I admitted it already in the previos in comment but it’s in Russian.
The standard is bit vague on this but there is no direct prohibition.
I also agree that it’s an overlook of some tool developers. Swimlanes in subprocesses are undoubtedly useful and should be enabled.
Anatoly,
Then the approach that makes most sense to me is to use no lane in parent process and use lanes freely in subprocesses. I just worked in a process and because I did want lanes in parent process because of the complex structure of organization, I started to find out that my process decompozition became too driven by lanes, because sometimes a subprocess tended to spend multiple parent lanes, so I had to break subprocesses just to have lane-homogenous sub-subprocesses. But by using my initial statement of this post, it seems to me this way one gets the best of both worlds. Am I missing anything here?
Cristian, you’ve got the point.
Anyway, your idea with groups works nicely as well. Does Bizagi allow lanes in a subprocess these days? I read your request on their forum some time ago…
I’m afraid not yet. Have to utilize reusable subprocesses just for this.
The difference is groups are visible always in parent process, while lanes are only visible in expanded subprocess, so subprocesses encapsulate the performer info.
Oh
i was hoping they do…
Then groups come to the rescue. I remember you try to do bpm with bpmn the way it is, not as it will possibly become. So groups are the option for now.
Sorry, silly me…groups may also be encapsulated, more like a pseudo-lane in subprocess. Actually nothing gets lost with groups, at all, I think. I find this approach better than using callable activities as a workaround. Really…
One can even draw the lanes as groups, themselves.
Anatoly,
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
Steve
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?
“A Lane is a sub-partition within a Pool or a Process”… There’s “or” for a reason. Pools are optional if you’re drawing a single process. But if there’s two or more processes interacting you need to destinguish one from another. In this case do you need to put both processes in pools? The notation doesn’t specify, so it isn’t forbidden. IMO the drawing area is implied as the process, where you can use lanes without pools.
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???
Edmund
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.
I was asking if anyone is using expanded subprocesses? I’m not, are you?
Sorry, didn’t get you right.
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.
Анатолий, здравствуйте!
Как сейчас обстоят дела в Bizagi с возможностью использовать дорожки внутри подпроцессов? Ранее (год назад примерно), как я помню, это было затруднительно.
Постараюсь объяснить:
Допустим, мы имеем некий сквозной процесс “от звонка клиента до доставки клиенту”, который мы моделируем “на самом верхнем уровне” как два пула: “клиент” как черный ящик и сам наш процесс; процесс (happy way) показываем в пуле развернуто и совсем крупно как последовательность, например, десяти подпроцессов, реализуем (указываем) межпроцессные взаимодействия.
Далее мы хотим начать “углубляться” (структурно декомпозировать подпроцессы до уровня исполнителей/ролей). Например, моделируем первый подпроцесс “обработка входящего звонка” (если клиент звонит первый раз, если второй раз, если новый клиент, если не новый, если постоянный ну и так далее), который подразумевает при его исполнении подключение разных ролей (в простых случаях Марина (операторы), в средних - саентолог Коля (отдела кирбистов, на разных этапах) и в тяжёлых - Михалпетрович (подразделения гипноза и зомбирования). То есть имеется некое интуитивное желание/необходимость разделить роли и описать подпроцесс “по ролям”, используя пул и для каждой роли дорожки. Архитектура процессов в таком случае видится как “пирамида процессов” - набор от вершины к основанию.
Имеет место быть такая практика описания “от общего к частному” при моделировании/описании неисполняемых процессов? Или такая логика описания процессов ущербна (допустим, что все задачи процесса синхронны [пусть workflow для примера])? Извините за легкомысленный стиль изложения - я надеюсь, мне удалось выразить суть вопроса.
Такая практика не только имеет место, но является рекомендуемой.
Что касается дорожек в моделере, то проблема такая есть, но обходится она легко: используйте повторно-используемые подпроцессы.