A business analyst must be comfortable with various modelling techniques and notations, and proficient with those most frequently and universally used. A process flow is one of the most frequently used diagrams in requirements analysis. This article covers the basics of process flows.
| A process flow diagram shows the sequence of steps in a business process. |
Process flows are used ubiquitously in many industries to capture any kind of process. In business analysis, process flow diagrams are used to create abstract representations of any sequence of steps that has defined start and end points. This type of diagram will have many variations, from the simplest and most abstract to intricate and detailed, using scientific or industry-specific shapes and pictures. The only common element in all process flows will be the arrows that show the sequence in which the steps are performed.
For the purposes of this article, we will consider the abstract representation of a business flow that would most often use the following elements:
While there are many more shapes used by various modelling notations to represent process flow details and design, in this article we will not get into those details. As a business analyst working in a specific organization, you will use the accepted modelling standards and tools, aligning with your company’s chosen methodology. For illustrative purposes, here are several ways to depict the starting and the ending point of the flow. None of these are superior: being consistent is more important.
The simplest process flow will use only two elements – boxes that represent steps, and arrows that show the flow of the process:
Such a simple flow can be used for high-level depiction of a process and its major stages. Each of the boxes may be its own complex process, encapsulated in one box for simplicity.
We can add more detail to this flow by including decisions or conditions that may require a different sequence of steps, depending on the outcome. Once you start adding decision diamonds to the flow, it is a good practice to also depict a start and an end point, for example:
At some point in the analysis of the process, it becomes important to capture who does each of the activities in the flow. To show this, a “swimlane” diagram is commonly used, where activities performed by people in different roles are placed in separate lanes, called swimlanes.
For example, once you hand off your book manuscript to the publisher, you are no longer in control of the publishing process; instead, you will become one of several actors that will participate in the process of taking the book to the market:
Real business flows will be much more complex than these examples. Some processes take many days, involve a significant number of participants, require invoking sub-processes, timers, delays, parallel processing, waiting periods and complex decision points with multiple possible outcomes.
If you are tasked with a detailed process flow, you may need to use a notation such as Business Process Model and Notation (BPMN) that can accommodate such complexity. Alternative modelling standards such as the Universal Processing Notation (UPN) have emerged to offer a simpler approach, mitigating some of the BPMN complexity.
Unless you are expected to use BPMN at your organization, starting with simpler process flows is a better approach. This would allow you more easily share the diagrams with business stakeholders and get their feedback. Simpler diagrams appeal to a broader audience and are often sufficient at the early requirements analysis stage, where the necessity for more detailed diagrams would emerge during design.
The required level of detail in a process flow will also dictate how you will validate and verify the accuracy of the diagram. At the very least, consider the following questions:
- How does the process start? Who starts it, or what event triggers it?
- Who is involved in the process?
- What are the main steps?
- Are they always performed in the same sequence?
- Are all steps mandatory? If not, when are they executed or not?
- Who does each of the steps?
- Does each decision diamond have arrows for each of the possible outcomes?
- Are the conditions attached to each decision diamond mutually exclusive?
- Is each of the activities reachable?
- Is there any activity that has no flow out? Do we know what happens after each activity is completed?
- Can the endpoint be reached?
Besides the sequence of steps and decision points, process flow diagrams may also capture (see featured example at the top):
- How does this process fit into the overall business architecture of the enterprise, such as the process group and business capability
- Process owners
- Governance information, e.g., the approval or review date, and the location of the master diagram
- Systems and applications where different process steps are performed
- Audit controls
- Comments and pain points
- Major data groups managed by the process
- References to process documentation and standard operating procedures.
When an organization undertakes a significant process analysis effort (often in preparation for digital transformation), it is a good idea to first establish modelling standards and guidelines, create a solid template, and then use it for multiple process flow diagrams. The details such as those listed above could be captured in a process catalogue as part of the governance. This work may be done by a senior business analyst or a business architect.
For process flow and process catalogue templates, and for mastering other business analysis techniques, get my Business Analysis Playbook and check out these courses and the BA Mindset Video Library. For modelling best practices, read these posts on Clarity, Consistency, and Conciseness.
This article represents an adapted and expanded chapter from the book Business Analyst: A Profession and a Mindset.