One of the most commonly used techniques for capturing business processes and analyzing them is the Flowchart. They can be applied to a variety of processes and project types, but what exactly are they, why would we use them and how are they created?
What is a Flowchart?
The Business Analysis Body of Knowledge defines a flowchart as a "visual representation of the sequential flow and control logic of a set of related activities or actions."1 Flowcharts are a non-UML process modeling tool often employed by business analysts. The UML equivalent of a flow chart is an activity diagram. Although flow charting has been around since 1921, its popularity has since increased and today it is a widely used technique.
There are different formats for flowcharts including:
- Linear – Most simple process map and commonly used for high-level process maps
- Top-Down – Provides more detail and can be useful as a drill-down process map
- Cross Functional – Also known as swim lane diagrams, this type of flowchart is useful for depicting steps in a process that are executed by different functional organizations
Additionally, flowcharts may be used for different purposes such as depicting data flows, system interactions or business processes.
Why Use a Flowchart?
Flowcharts have several important benefits, including:
- Graphical format makes them easy to read and understand, even by non-technical team members
- Allows for a team to document current processes ("as-is") as well as future processes ("should-be")
- Can be created at varying levels of detail depending on the project phase and purpose
- Can be leveraged for other analysis techniques, such as use cases
- Shows critical attributes of a process such as: complexity, redundancy and manual vs. automated processes
- Allows a team to identify potential problem areas where a process is known to break and therefore may lead to process and system improvements
- Can serve as a valuable training and communication tool
- Can show parallel processes by function (i.e. swim lanes)
- Can be easier for novice analysts to implement in comparison with the more rigorous UML format
There are also some limitations to flowcharts, which may warrant the selection of an alternate model depending on the need. These include:
- Does not show timeframes associated with the process as a whole or individual steps (although this can be accommodated by additional notation)
- Does not speak to the data involved (for this use a data flow diagram)
- Complex processes may be difficult to diagram such that they are easily readable and may require multiple diagrams to effectively communicate scope
Overall, the benefits tend to outweigh the limitations, making the flowchart a very popular tool.
When to Use a Flowchart
Flowcharts are primarily used for initial requirements elicitation and subsequent requirements analysis, so they are most often associated with Envisioning and Planning phases of the software development lifecycle.
How to Create a Flowchart?
So once you have decided that the flowchart is the tool for you, where do you begin? Start by defining the boundaries of the process. If necessary, the business analyst may offer a baseline set of boundaries to start the conversation, but the project members will still need to validate those initial thoughts to both ensure that they understand the context of the flow as well as validate that no inputs, outputs or participants have been forgotten. Examples of boundaries are below:
- Where does the process begin (i.e. the trigger or specific input)?
- Where does the process end (i.e. the output or result)?
- Who is involved in the process?
- How much detail will be included in the process flow? Keep in mind that typically process models will evolve as the project progresses and early models will likely be simple and high level.
Once you have determined the boundaries, begin documenting the steps in the process. I have found that unstructured brainstorming activities are useful for this purpose. For example, I provide team members with Post-It™ notes to capture thoughts and ask them to randomly place them on a flip chart. Duplicates or inappropriate steps will be validated as part of the next step. Don’t forget to capture the inputs, outputs and critical decisions as well as the individual steps! In fact, you may want to offer different colored pens for the team to differentiate between the types of notes (ex: green for inputs/outputs, red for decision points and black for steps).
After the team feels that they have captured the major activities, the next step is to discuss them as a group and begin placing them in the order in which they are carried out. Another reason that Post-It notes are useful is that it allows the team to move steps repeatedly until everyone can agree to the sequence. It is also less intimidating to novice users in comparison with doing this activity in a software application, allows for individual team members to work in parallel and removes the dependency on a facilitator to capture notations.
After the step sequence is finalized, it is time for the business analyst to transfer the team’s work to an appropriate digital format. The most commonly used tool for this is Microsoft Visio although there are several products that provide similar functionality. If the working session has concluded, the advantage of using the flip chart is that the BA can take the results of the session with them for later entry into a computer. With the prevalence of camera phones, another popular option is to take a picture of the paper flow for later reference.
When transferring the Post It note steps, it is important for the BA to use the appropriate notation. Below are several popular shapes, but most tools will provide a library of shapes along with descriptions of their usage:
The business analyst is also responsible for validation of the flow before presentation back to the users. This validation includes checking to ensure that the following best practices are adhered to:
- All shapes are clearly and accurately labeled, including decision arrows that are marked with "Yes" or "No"
- Correct notation is followed for the type of step displayed (ex: diamond for decision, oval for start/end steps)
- The flow’s path is consistent (ex: all "No" decision arrows flow in the same direction)
- The main path represents the most common scenario
- All loops are closed and every path either leads back to or ahead to another step
- That there is a defined start and end to the flow
- All process steps include a verb for action and a noun describing the system, person or object
- All process steps have a single outbound arrow and at least one inbound arrow
- All decision points are phrased as a question and include two outbound arrows (one for success/confirmation and one for failure/negation)
The last step is to present the flowchart to the project team for review and finalization. It may be necessary to amend the diagram to account for changes in the process or to correct inaccuracies.
Once completed, the flowchart becomes a valuable analysis tool for further requirements definition as well as other ancillary purposes such as team training.
A Guide to the Business Analysis Body of Knowledge (BABOK Guide), 2.0 ed., International Institute of Business Analysis, Toronto, Ontario, Canada, 2009, pg. 193