The first one provides an overall view on the entire flow, showing who is doing what in which order. This is what you need in order to gain an understanding of the company’s processes without going to much into detail. This also helps when you try to improve processes, e.g. by shifting activities from one role to another (such as shifting activities to the customer, creating cheaper and faster processes with a large amount of self service activities). Or you may find that several activities are carried out twice (e.g. partner 1 does a checks the quality of their products before moving them to partner 2, and partner 2 performs the quality check again - you can get rid of the second quality check, if you make sure that partner 1 does the quality check right). You cannot find such weaknesses if you model these partners as separate pools with their private processes. To the contrary: Such a modeling style actually reinforces existing interfaces. Process improvement aims towards reducing the number of interfaces. This purpose of is entirely neglected if you say that business people should always model the process as in your second diagram. It is not a matter whether business experts can learn that type of modelling, but it does not serve some important purposes.

The second diagram highlights the idea of an organization and/or a technical system (such as a BPMS) providing a service to someone, such as a customer or a partner. In order to do this you need to have already decided which partner should carry out which activities, so that the interfaces are defined. Therefore you should draw such a diagram only after you have optimized your overall processes. It provides a more detailed view which should be developed at a later stage in a Business Process Management Project.

Within a pool you have some kind of central control or governance of the process contained, the other participants with their own pools are outside the reach of this control. They have their own control - there is only an agreement on the choreography, i.e. the message exchange. Depending on how you view a process, the scope of control may be different. For example, the management of a company may define and control the company’s core processes. The scope of control would be the company, i.e. when modeling such a core process, the pool would represent the company, lanes could represent departments. After the company has defined and maybe re-engineered its processes, they may decide that is not enough just to draw a picture what has to be done by which department in which order, but they need to define services with specified services etc. So they would create more detailed models specifying theses services. Now the department that actually has to provide the service only controls their part of the overall process (within the broader control scope of the company management), so now it makes sense to model this department as a pool and the other departments as separate pools. So what is a lane in one view of the process may become a pool in another view.

And of course if you want to automize a process with a BPMS the second diagram also makes sense (you even may model the manager and the HR department as separate participants, and the actual process is running in one system pool, as you would model it in Intalio Designer).

BPMN will not be accepted by Business Analysts if IT people force them using workflow concepts where they do not support their purpose of modelling. Business process models are not only used for specifying executable workflows, but for a multitude of other puroposes, as well. I agree that many BPMN concepts can be useful for business people, as well. But they should be used only where they actually provide value.

Process is a kind of Activity, so should have the same notation as Subprocess and Task (rounded rectangle). Maybe Process is a kind of Subprocess??? That way you can build a nice hierarchy of Processes. (Watch out for multiple raised Events!)

Lanes are kinds of Actors. Pools are also Actors, but they have a hierarchical relationship with Lanes. Maybe like an org chart or something?

Some of the confusion comes from the clumsy treatment of the term “process” in BPMN. Quoting from the spec…

Business Process more generically [is] a set of activities that are performed within an organization or across organizations. Thus a Business Process, as shown in a Business Process Diagram, may contain more than one separate Process. Each Process may have its own Sub-Processes and would be contained within a Pool. The individual Processes would be independent in terms of Sequence Flow, but could have Message Flow connecting them.

I use process synonymously with orchestration, i.e. a BPMN process is an orchestration. This is what BPMN calls a “private process.” An “abstract process,” denoted by an empty (black box) pool, is often labeled with the name of the participant, not a process, as discussed above.
–Bruce

Pools are somewhat synonymous with resources possibly taking part in a number of processes (even within a single business process diagram). In fact, the number of distinct processes in a diagramm is not to be determined by simply counting the number of pools. (Would be simple, wouldn’t it? ;))

To give you a simple example: imagine a pool with two start events not even sharing a single diagram object in the subsequent flow. So, there are two completely independent definitions of two totally different business processes performed by the same actor. All of this in the same pool…

Therefore, the distinction of a pool and a process has to be made explicit. Especially if you think of a BPEL transformation as propagated in many of your posts. In fact you can only transform processes, but not pools…

Cheers,
Torben

Expanded upon in my blog
David