Swimlanes are one of the few sensible graphs in a BPM planning exercise. Used the right way with Value Stream stages and Capability Maps as well as the much newer but similar Customer Experience graphs they are one of the best tools to understand and map human process communications. Unfortunately they are not directly used in most cases to actually control or view a process which reduces their over all usefulness. Much else should be obsolete before swimlanes.

The trend I see is a move from a more free format way of modeling alone (like EPC, then again this too can be very structured if swimlanes are used) towards a combination of more formal ways (like BPMN) and informal ways (VACD & EPC).

I totally agree with Max J. Pucher that swimlanes are one of the more valuable components of a good process model as it immediately shows the interaction points between actors in a process (and it doesn't matter if these actors are carbon-based life forms (also known as humans) or robots (as in RPA)) and for the reader it becomes clear very quickly which parts of the process belong to what actor.

I might be a bit of a self-acclaimed process modeling purist, but doubting the added value of the swimlane almost feels like cursing in the church of BPM... Okay, that might be a bit strong, but swimlanes, in my opinion, are still very, very relevant and not used as much as they should be.

As a matter of style, we do not separate system roles into separate swimlanes. We see system tasks as assisting one or more user stories, therefore we place them in that respective user role swimlane. In today's world, there are no pure "user roles" - a robust BPM system will always assist the user interface with service tasks for validation, error treatment, temporary persistence and other fascinating contraptions of the distributed computing paradigm.

It's not always perfect, but it has two massive advantages:
1/ the process models are so much easier to read if your eyes don't have to jump around every couple of tasks;
2/ creates coherent expectations - putting user roles and system roles in separate lanes creates, from a visual pov, a false expectation of a handoff.
.

From an execution standpoint, they are not relevant (even as per BPMN standard).

From a mapping & communication standpoint, if you are used to the paradigm, sure, go ahead. Even if there are other role modelling paradigms, swimlanes are arguably the most descriptive, as they can easily surface wasteful loops, unneeded handoffs and segregation of duties conflicts.

One could extend their relevance to the software execution realm, especially when it comes to:
1/ inheriting execution semantics from model (e.g. a task dragged into a swimlane is automatically delegated to their respective candidate user roles in the process engine); 2/ process mining, e.g. identifying over- and under-utilization of resources.

I note that neither Meriam-Webster nor the OED recognise swimlane as a word at all, which is interesting in that it indicates a narrower usage than readers of this site might expect.

From p502 of the BPMN spec:

A Swimlane is a graphical container for partitioning a set of activities from other activities. BPMN has two different types of Swimlanes. See “Pool” and “Lane.”.

It's hard to argue that it is no longer useful to group business activities in ways that are meaningful to a group of viewers.

OTOH I've never been comfortable with the way the definitions go on (p110):

A Pool is the graphical representation of a Participant in a Collaboration. A Participant (see page 113) can be a specific PartnerEntity (e.g., a company) or can be a more general PartnerRole (e.g., a buyer, seller, or manufacturer). A Pool MAY or MAY NOT reference a Process.

The text seems quite reasonable at first sight but experience modelling white-box Pools in any non-trivial situation leads to multiple layers of abstraction and people quickly find the organisational structures they have do not fit the strict decomposition required by the Pool-Lane structure. Perhaps this is the sense in which swimlanes are no longer relevant? Honestly I have found them to cause more heat and light than progress in every discussion bar the very highest level of 'hand-waving'.

One of the basics in the performance/management of work is the assignment of responsibility.

Designating a Collaborator as a company means the Case Manager (in the absence of more detailed info) effectively has no control over a task (who do they call to inquire about progress?).

When a task has "skill" as an attribute, this ensures that all users who have a match on that "skill" receive a broadcast of the task.

No reason under 'skill" that a BPMs task cannot have "plumbers" as a skill for task performance plus "house owner(s)" as "for information only" task recipients.

The task is broadcast to all plumbers who are on the approved list of suppliers as and when the task becomes " "current" along the process timeline, the 1st to "take" the task owns that task up to completion or hand-off, the house owners and the Case Manager get to see start/progress/end for the task.

This sounds like a discussion we used to seed when I worked for Tibco Nimbus. We'd argue vehemently against swimlanes while discreetly supporting them in our product.

Swimlanes are like any visual tool on a graph, used in the right way, to convey the right message they can be powerful. Used incorrectly, without a purpose, they cause confusion and obfuscate the real issues you're trying to solve.

I still believe that they make diagrams big and unwieldy because you force boxes into swimlanes. Make the flowchart "flow" and use resources to show handoffs. (Elements.cloud does support swimlanes for those who can't be convinced)

I agree that Swimlanes are still very useful in several business scenarios.

But, the fact is that swimlanes are very confusing when the process involves a lot of participants, and even more when participants are other systems or robots. You need to represent those Web Services, external Web Applications or Robots because they complete tasks as part of your business processes. But doing it turns your swimlane-based diagram mostly unreadable.

I think this is why modern process diagram tools tend to include the participants in the task definition, rather than using explicit swimlanes. Of course, it hides some relevant information (who has to do this task), but the benefit is greater the this cost.

I agree with Max’s statement re the need for “tools to understand and map human process communications”.

I agree with Juan’s statement “modern process diagram tools tend to include the participants in the task definition”.

My view is the typical ACM/BPM run-time scenario has multiple workers focusing on multiple Cases, which reduces the resource allocation need, plan-side, to setting a skill attribute at each task in a workflow.

Other essential plan-side attributes of tasks include 1) task-performance-instructions, 2) data display/data forms, and 3) rule sets, so the question becomes why put such a strong focus on only one of these?

The five elements of task performance are what, why, who, where and when.

What and Why are clearly plan-side attributes.

Who, also a plan-side attribute (a skill designation, not any named individual), involves, in most Case settings, a broadcast of each task to all whose profile yields a match with the plan-side task skill attribute.

Where typically gets decided at run-time (e.g. which hospital do we transport this particular patient to?).

When is a run-time consequence of a task becoming “current” (sum of task performance plus wait times along the longest parallel path, plus additional delays related to availability of a resource with a match on skill and delays waiting for a rule-set to “fire”).

One approach to viewing/understanding task performance needs is to compile a flowgraph and piano-play the resulting workflow template to a group of ‘skill’ actors.

The actors are quick to reject tasks they perceive as “not their job”, they get to comment on the flow (why three sequential tasks instead of one?), they are able to comment on the forms (wrong form, obsolete form, missing fields, unneeded fields), and they get to see how rules trigger as a result of their actions/inactions.

My contention, since 2012, has been that task scheduling in many organizations needs a three-tier approach i.e. R.A.L.B. (except in the area of automated industrial process control).

What Max is asking for "clear understanding of handoffs & RASCI" can be delivered in a way that still enables the diagrams to be tight and readable. It is called UPN - where there is a "resource" attached below each process step. Simple.

Except that most handoffs occur at run time (i.e. one medical specialist looks at a patient in an ER, another takes over as the 1st gets called away; a crime scene photographer goes off shift and effects a handoff; a Case Manager re-assigns a task to a different insurance adjuster in the middle of processing a claim).

The other argument is if you display all attributes (instructions, forms, resource, rule set), your diagram is no longer "tight and readable"

Business logic is simple and readily mapped out with direct input from users helped by the BPM thinking. Do not rely on just mangers who often do not know how work is actually carried out! Swim lanes just add confusion but may have a place for a quick high level view? However with the capability now proven that mapping out the detail is now the build environment it is much more productive and credible with users when at a click you can get first pass of a deployed process for feed back. Yes no coding or compiling which of course readily supports inevitable future change.

Once user "get it" the new business driven deployment of working applications changes the game...and there in lies the real challenge as old IT complex ways will slide into history with significantly lower costs which big vendors and their supply chain will "resist". With this new way "The Map is the App" and readily available for scrutiny as required for audit/compliance. Indeed there is a case for early involvement in the build by such knowledge input.

+1 to mapping with direct input from users. I would add that this is best done in real time, either in front of a small group of stakeholders OR at, say, a GoToMeeting. Important here to give the stakeholders "instant gratification" i.e. do not take on a mapping session that extends longer than to allow "map->compile-> piano-play -> update the map -> compile-> piano play".

If you are on site, 2-hour sessions are OK, so the ideal setup is one group in the morning, then a separate group in the afternoon.

I am intrigued by "The Map is the App" - difficult for me to imagine how any system would function differently. i.e. you map, compile with one click which rolls out a template of your process to your run time workflow/workload platform library, then stream a relational db record onto the template to get a private instance of the template.

Why have things more complicated than this?

We could go on for days. Unfortunate that the terminology is all over the place.

I just talked to one corporation with a history of BPM (i.e. they were onboard and actively engaged) but when I asked to see a "Case History" they showed me a "log" (i.e. date, time, user, names of data collection form(s) accessed, but, no data). The essentials of any Case History for me include date, time, user, plus forms accessed complete with data as it was, at the time it was collected, on the form versions that were in service at the time. e.g. If a form has an address block on it and the patient, insured individual, etc. moves 9 times, then you need to see 10 address blocks, not just the latest.

The process we use for process development / rollout is summed up in a 2011 blog article "The Facilitator Is Coming" https://wp.me/pzzpB-aG

From a sales perspective (or later just from the business analyst or manager's perspective as business lead), swimlanes may be a good way of looking at a process and its environment. But as pointed out above, sometimes swimlanes are useful and sometimes not -- and anything not necessary is just more cognitive overload. From a software technical POV, a swimlane is just one perspective on a complex semantic entity which is a business process. Perhaps someone here knows if any BPM software enables one to "expose" or alternatively "hide" a swimlane perspective? In this way, everyone wins.

+! John . . I agree perspective or vantage point is all important in design.

One possible reason we have such a divergence of features/functions/implementations in BPMs' is that some of the folks setting the architecture may have failed consider the fundamentals of workflow/workload.

Interviewing line staff on what they do/how etc. is easy but design traditionally has been done off-line (unless you go through a long incremental prototyping exercise, which is costly).

One thing I recall from days at GE was my boss encouraging all of the design engineers to do daily walkabouts to see firsthand what the impact of their designs were on production line work/workers.

Walkabouts are very helpful for discovering reasons for inconsistencies in finished products and, in a few cases, to discover and explain consistencies.

In the plant where I worked, one of the products was watt-hour meters and these of course required magnets.

For years HQ could not understand why the quality of the magnets was so high, relative to other watt-hour production plants. A walkabout reveled that the blacksmith (yes, they had a blacksmith in those days), whose shift was 8 to 4, same as everyone else, actually came in at 6 AM to start up his hearth and stayed to 6 PM to clean up. The effect was a steady state by 8AM and readiness to start the next day by 6PM.

I have been a fan of walkabouts (production facilities and office) since that time.

Walter - your reminiscence of the dedicated blacksmith is very moving. I take it that good magnet production quality is achieved when hearth temperatures are stable? An example then of tacit knowledge that had not been rationalized in that GE plant?

It's also an example of the human factor, i.e. the "moving" part of my response. So much can be explored around the idea of the tacit; the concept is not just about epistemology (i.e. here concerning what we systematically have not incorporated into a process specification and system). Tacit is also about trust, personal dedication and social capital, on all of which work processes depend.