Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Business Proces...  Swimlane Diagram Best Practice
Previous Previous
 
Next Next
New Post 12/25/2013 9:02 AM
User is offline remedina
1 posts
No Ranking


Swimlane Diagram Best Practice 

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.

 
New Post 12/28/2013 12:57 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Swimlane Diagram Best Practice 

 Hi,

Swimlanes are for actors that interact with your system. An actor can be a user role or a system.

But the most important thing is that they are actors that interact with your system, so by definition, you cannot have the system itself as an actor i.e. swimlane. Very important point and a common error. So your colleague is wrong.

Kimbo

 
New Post 2/4/2014 7:18 AM
User is offline Steve Orr
1 posts
No Ranking


Re: Swimlane Diagram Best Practice 

 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.

 

 
 
New Post 2/12/2014 8:36 AM
User is offline Kathleen
1 posts
No Ranking


Re: Swimlane Diagram Best Practice 

Regardless of whether your colleague was "right" or "wrong", you must provide documentation that can be understood EASILY by your client/reader.  If that entails using a swimlane to depict a process that is performed by a system, then by all means do so.  The reader of this model needs to be able to pick it up and understand it with no instructions.  Don't get caught up in the semantics of what is or isn't an"actor."  If using a lane to hold all the process boxes carried out by a system is something the reader will understand then DO IT.  Nobody's grading you on this except the reader, who will be grading you on how well they understand it. Do whatever you need to convey your message clearly.

 
New Post 2/13/2014 12:57 AM
User is offline Kimbo
454 posts
5th Level Poster


Re: Swimlane Diagram Best Practice 
Modified By Kimbo  on 2/13/2014 4:00:08 AM)

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

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Business Proces...  Swimlane Diagram Best Practice

Community Blog - Latest Posts

A business analysis checklist helps you stay organized while you work through projects. It includes questions that will help you identify problems in your current processes, and suggest improvements for future projects. Understand the Problem Before you start writing code, you need to understand what problem you're solving. This means u...
I’ve heard “The End is Near!” for Business Analysts for almost 20 years.  Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.  To be honest, that’s mostly true.  With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-...
Business analysis is used to identify and articulate the need for change in how organizations work, and to facilitate that change. As business analysts, we identify and define the solutions that will maximize the value delivered by an organization to its stakeholders. We look for opportunities for new business models and new ways to work together. ...

 






 

Copyright 2006-2022 by Modern Analyst Media LLC