How to Use Workflow Diagrams in Your Business Analysis Report

A workflow diagram (or workflow) is a visual way for your business analysis to show how work gets accomplished. Workflows are composed of a set of symbols that show how various workers accomplish tasks and interact with each other, as well as how information (data) flows through the business area. These diagrams have been around for a long time and come in many varieties:

• Swimlane: This workflow diagram focuses on interactions between organizational units and exposes bottlenecks and process inefficiencies

• ANSI flowchart: This style grew out of flowcharting in the 1970s and became the first standard for workflows. The symbols came out of the American National Standards Institute (hence, ANSI). Many people still use the symbols today, often inside swimlanes to show work being accomplished. For example, an ANSI flowchart may show how an employee’s vacation request is approved.

• UML Activity: This diagram arose from UML (Unified Modeling Language). It operates like a flowchart and shows different steps and ordered tasks as well as the flow of control.

• BPMN: Business Process Modeling Notation (BPMN) is a standard created for the business rather than for application development. In other words, it focuses on graphically presenting business processes and information rather than solutions. For instance, a BPMN diagram may show the process of vacation approval overlaid on all the external agents in the process: the employee’s, manager’s, and company’s vacation calendars.

• Geographic diagrams: These diagrams are commonly used in warehousing and logistics to show the placement of objects in relation to workers. For example, a geographic diagram would mandate that the least-commonly ordered products be placed farthest from the shipping dock and highest up on the racks and that the most-commonly ordered products be placed closest to the shipping station.

• SIPOC: SIPOC stands for “Supplier–Input–Process–Output–Customer.” Used primarily in Six Sigma, this diagram shows who creates the data, details the high-level process, and depicts who receives the data. For example, a shipping company (supplier) provides a tracking number (input) attached to your order (the process), and a confirmation e-mail goes out (output) to you (customer, consumer).

Here are some examples of when you should apply this technique:

• When you’re automating a manual process

• When you’re defining responsibilities: who does what task in a process

• When you’re tracking metrics for a process

• When you’re trying to improve a process by looking for process inefficiencies and exposing bottlenecks

This technique has its advantages — it’s a very good way to see inefficiencies in the process, and it helps define the roles and responsibilities for the process — but it’s also limited in that it doesn’t actually solve the problem (it just documents the process). Make sure you identify the root cause of a problem before simply automating a bad process.

How to decode diagram symbols for business analysis

All these diagrams use symbols to show the flow of the process as it moves through the business area within scope of your project. Each diagram uses different symbols, but they all document various aspects about the process, such as who does the work, where it is done, what data the process uses, where decisions are made, who makes those decisions, when the process starts, and what causes the process to end.

Credit: Illustration by Wiley, Composition Services Graphics

How to create a workflow diagram for business analysis

Here are the essentials of how to make a workflow diagram::

1. Determine the point of view and point in time you’re diagramming.

   Are you diagraming the process from the business’ point of view or from the customers’ point of view? Are you showing the way you’re doing the process today (called the as is process) or how you want to do it with the new implementation (called the to be process). If you don’t know, ask your stakeholders. Title the workflow appropriately.

2. Figure out where the process starts and where it ends.

   This step is very important because it forms the starting point for your process activities and also identifies when it successfully (or unsuccessfully) ends. If you don’t know — you guessed it — ask your stakeholders.

3. Ask “What happens next?” or “And then what happens?” questions of your stakeholders until you understand the process from end to end.

   Document each task and connect iy to create a flow (or path) from one task to another. When working with stakeholders, keep going down the most likely path (the one that happens most of the time) first. Then return to the alternate paths (those that don’t follow the normal path). This strategy helps you avoid getting stuck in all the “what if” paths.

   As you uncover the process, listen for operative words such as validate or approve; those are your decision points. When you come across these words, you’re going to have two paths coming out of the decision: one for the approval and one for the denial. Continue down the most common path at this point, but make sure to return to the exception path.

4. At the decision points, figure out what information or data the worker needs in order to make a decision.

   For each task, inquire about the data they either use (or read, in data language) or generate (create). This information leads you to requirements.

5. Choose the type of workflow.

   No one-size-fits-all solution works here. Your choice depends on what the company’s culture is, whether the company has worked with any kind of workflow diagram in the past, and which option will best communicate to their stakeholders, as well as on your own experience and comfort level with various workflows.