Perhaps the greatest failing of the BPMN 2.0 spec is the inadequate explanation of its most fundamental concept: process. That failure lies at the root of so much confusion and modeler error.
A process in BPMN has four distinct aspects: as an "orchestration", as a collaboration "participant", as a container of activity performers, and as an actor in its own right. It is all of these things at once.
As an orchestration...
The spec defines a process as "a sequence or flow of Activities in an organization with the objective of carrying out work." Mmmm... no. A process is that, but many other things that are not a BPMN process are that as well: a case in adaptive case management, for example. A process in BPMN is a certain kind of activity flow with the objective of carrying out work, called an orchestration. An orchestration is not just any old set of activities intended to do some work. The set of activities must be performed repeatedly in the course of business, meaning it has instances with a well-defined start and end. It is not some business function performed continuously. Books of BPM architecture famously talk about Management Processes - Manage This or Monitor That. These are not BPMN processes because they are not performed repeatedly on instances.The phrase "carrying out work" implies some particular initial state of the instance and some desired final state. BPMN acknowledges the possibility that some instances may not reach the desired final state but will end in some other exception end state. In fact, a BPMN process is not merely a log of the path of one instance from start to end but a map of all possible paths from what is normally a single initial state (start event) to any allowed end state (end event). Only paths defined by the process are allowed. Ad hoc insertion of new activities for a particular instance is not allowed, and you can't do the activities out of the prescribed order, either. That's orchestration. These are the constraints that drive ACM people batty. They would maintain that real processes don't work that way. I would say that many processes do work that way, and many do not. BPMN is really well suited only for those that do.
As a participant...
Many people confuse BPMN's term participant with the performer of an activity, but that is incorrect. In BPMN, participant and performer are different things entirely. A participant is defined in the context of a collaboration, that is, a pattern of interactions between a process and entities external to it. It only has meaning in that context, and in that context, the process itself is one of the participants, and other pools in the collaboration diagram represent the other participants. If those pools are empty, or black-box, they are not associated with any process. In other words, the process as a whole is an actor in some interaction with other entities. If the process describes a seller's order handling, for example, the buyer would typically be represented as an external participant. You might say the participant on the process side is not the process itself but its role in the collaboration, seller. There is logic in that, but in the BPMN 2.0 metamodel, a participant (that is not a black-box pool) is uniquely associated with a SINGLE process. So even if you label the process pool Seller or MyCompany, the participant represented by the pool does not really mean that role or entity in general but just Seller/MyCompany's order process. Any other process performed by Seller/MyCompany would need a different participant id. That's why I say that in a collaboration, a process IS one of the participants.In my book and training, for that reason, I recommend that process pools, if drawn, should be labeled with the name of the process. It's the only place in the diagram where the process name appears. But that drives some folks nuts, and I still get occasional hate mail for it. If you want to label your process pool MyCompany, go right ahead. The spec is silent about the link between shape labels and the semantic elements. But the unique association of the participant with one particular process cannot be denied.
As a container of performers...
As evident from the above discussion, a person or system performing some action related to the process can be either inside or outside the process. It must be one or the other, not both simultaneously. What does that really mean? Again, the spec is largely silent. If an activity is part of the orchestration, it is inside the process, and its performer is implicitly inside as well. But that really begs the question. Is the Customer inside or outside? I think normally outside, because of their participant role in the collaboration. Employee-facing processes are a gray area. They are part of the organization providing the process, but they may have no defined performer role in it. They might simply be an effectively "external" requester.Modelers are thus faced with deciding whether various actors are inside or outside the process, whether their actions connect to the rest of the process via sequence flows or message flows. Other than saying a particular actor must be either inside or outside, not both, there is no absolute rule about it.
As an independent actor...
This aspect is strangest of all to business people, but it's baked into the concept of orchestration. We say that the performers of all activities inside the process are themselves part of the process. But who is the "performer" of a Message end event? What actor sends the message? It actually is "the process" itself, not a performer. In a BPMS, it would be the process engine, but even in non-executable BPMN this "virtual process engine" is implied. It derives from BPMN's origins as a service orchestration language, a graphical front end for BPML and later, equally unsuccessfully, for BPEL. In web services, there is a service requester and a service provider. In BPEL, an invoke node in the process was the requester and the partnerLink, the service endpoint, was the provider. BPMN tries to hide the distinction, but it's still there. In a BPMN activity, the "process" is the requester and the "performer" is the provider. A Service task implies the performer is "inside" the process and a Send/Receive task pair implies the performer is "outside", but there is no fundamental difference. (A Script task means there is no performer; the action is performed by the process itself.)
While these aspects are fundamental in executable BPMN, they are less critical in non-executable models. Nevertheless, appreciating all four aspects of process is helpful to all modelers in making decisions about what is inside the process and what is outside.