Hi! I am a new member to this forum and I am excited about it.  My background is in electrical engineering, but I have spent most of my recent years working as project manager.  I am working as project manager on a software system development project and a person in the group has developed a swimlane diagram to depict the expected new process.  This person has included the new information system as one lane (or actor) in the diagram.  Is this considered a good practice or should the swimlane diagram include only lanes for system users?  Thanks.

 You may like to check out Alec Sharp, one of the foremost authors and consultants in the area of process models. See for example his book, Workflow Modelling.

If you are using the swimlane technique to model business processes, then each role (actor) gets their own swimlane; actors are the roles that complete the steps (tasks) in the business process; they may or may not use online computer applications to support their work. If they do use online computer applications, then we can refer to the system or application in the task name. However, Alec points out that an alternative representation is to have a 'systems' swimlane, as your colleague has described.  

If the computer application is run in batch mode, rather than online, then it is normal to represent this as a swimlane on a swimlane diagram. Following on from this, it is normal for devices such as IVRs to have their own swimlanes.

More generally we can represent the interaction between an actor and a computer application with a use case.  A use case actually represents a service or goal for an actor but generally they are used where that service is imlemented as a computer application. When I create swimlane diagrams I like to use post it notes, labelled with the name of a use case, and position the post-it inside the rectangle representing the task; this is an 'unofficial' approach but it neatly demonstrates where a use case (computer application) supports a task. It is of course possible to have more than one use case supporting a single task.

We can of course also use 'user stories' to describe the support needed by an actor involved in a business task.

Alec Sharp also points out that a a swimlane can represent another process. This sounds odd but can be very useful in practice to show how one process interfaces with another.

Alec creates his swimlane diagrams with a simple technique; this avoids having to involve business stakeholders in the intricacies of BPMN, UML Activities, or any other specific notation. Formal notations can be applied later if required.

Hi Kathleen,

Actors can be systems. An actor can't be the system you are describing because your actors are external to the system and you're describing the conversation between them and the system you're describing.

I'm all for being pragmatic too but in my experience if you start putting your system as an actor then you start to get into design. And doing design before you understand your requirements is the slippery slope to poor outcomes for business.

Kimbo