The Unofficial Guide to Process Flow Chart Symbols
The primary technique in Business Process Modeling (BPM) is the creation of flow charts and proper use of process flow chart symbols. But first, let me back up to the official definition of business process modeling and a few facts to level set the conversation. Business process modeling is the activity of representing process of an enterprise so that the current process may be analyzed or improved. According to Wikipedia, BPM is typically performed by business analysts (or anyone performing analysis), who provide expertise in the modeling discipline; by subject matter experts (SMEs), who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. There are many types of diagrams that can be used to show workflow. Commonly used examples include:
- ANSI (American National Standards Institute) Standard Flow Charts: traditional, well-established diagramming technique that can show all business processes
- Swim Lane/Functional Flow Charts: a more structured flow chart that focuses on interactions between organizational units
- UML Activity Diagram: based on Use Case diagrams
- BPD (Business Process Diagrams): process models that use BPMN (Business Process Modeling Notation) to detail business processes
- Value Stream Maps: shows all of the actions required to deliver a product or service
- SIPOC: a Six Sigma tool that maps a process at a high level
- Geographic Diagrams: maps, floor plans, office layouts that show where work is accomplished
- Spaghetti Diagrams: uses a continuous flow line tracing the path of an item or activity through a process
A flow chart is composed of a set of process flow chart symbols or modeling notations that show how various workers accomplish tasks and interact with each other, as well as how information (data) flows through the business area.
Why Should You Care about Symbols for Business Process Modeling
Most likely you will need to draw a workflow at some point. Whether you’re involved with a process reengineering effort, the design of a new business process, developing training materials for on-boarding employees, or just trying to understand a process, at some point you will want to sketch a flow chart. They are one of the most fundamental and widely used techniques by business analysts, project team members, and the business community. An analyst should learn as many of the diagrams above and have these as tools in your analysis toolbox.
When the day comes to draw your first flow chart, stop and ask yourself 2 critical questions:
- “Why am I drawing this model?”
- ”Who’s going to use it; today and in the future?”
The answers to those questions will help guide you in terms of formality of the drawing, the type of diagram to use, and the level of detail. Make sure that everyone who needs to use it will be able to interpret it the way it was meant and that it provides enough information for the purpose intended. Like everything else related to analysis, it’s about communicating clearly. Remember those things called Excellent Requirements? They especially matter for business process flow charts.
If you don’t know what they are, now’s a good time to stop and do a little research:
Valuable Requirements describe the right features and capabilities meaning that they:
- Make progress toward satisfying the needs of your stakeholders
- Support your business strategy
- Don’t over solve problems
Concise Excellent requirements provide a useful, easy to read and easy to change understanding of what must be done. They exist to do three things:
- Identify the needs that your stakeholders have (needs can include problems and opportunities).
- Explain why those needs are worth satisfying.
- Define when those needs are satisfied.
Therefore, requirements should present the most important information in the easiest format for your audience to consume.
Design Free A requirement should not specify an implementation (i.e. the how). Specifying only the what, leaves options open for the delivery team to figure out the how. Attainable Requirements should describe a solution that is realistically attainable, and in conjunction with the idea of valuable requirements, the cost to implement the solution should not be more than the benefit received from satisfying the need. Unattainable requirements are generally quite expensive. Complete The full set of your requirements:
- Identify all of the stakeholder needs to be satisfied and their nature (absolute vs. diminishing returns)
- Are logically complete in their coverage / articulation of those stakeholder needs
Consistent Write requirements with grammatical consistency to reduce the chance of ambiguity. Also write logically consistent requirements so that you avoid “impossible” requirements and gaps of unspecified meaning. Requirements need to support your business goals and your organization’s vision. Unambiguous Requirements should have a single, reasonable interpretation. Avoid inserting ambiguity into requirements whenever possible. Verifiable You need to be able to determine whether you successfully delivered the project’s requirements. They need to be testable. Atomic The requirements you use for organizing your work (i.e. user stories or use cases) represent a single stakeholder need that you either satisfy or you don’t. There is no partial satisfaction of atomic requirements. Having requirements established in this manner aids in producing valuable requirements, helps traceability, and aids in validating that a requirement is met.
As an example, in user stories, the presence of “and” or “or’’ means that the user story isn’t atomic. It can be split into smaller stories.
Understandable Make sure the people who are looking at your requirements can understand what the requirements are saying.
Download these excellent requirement characteristics as a checklist!
To illustrate, I want to share an example of a project we had a few years ago. Our company had grown and we needed to add an additional administrative person. However, we weren’t sure exactly how we were going to reorganize the job roles. I asked one of our BAs to interview the current staff and document the processes for our review to see how we could break the activities into logical job descriptions or functions. Being the great BA that he is, he asked me why I needed them and if I wanted them in a particular format. I told him that whatever he thought was best would be fine with me.
Well, he is a BPMN expert and as such decided to do these elaborate swimlane BPMN diagrams. They were beautiful with lots of arrows and symbols on them. I’m sure you can guess the problem. Other than our expert BAs, no one could read the BPMN diagrams or found them difficult to understand without some education. We also didn’t tell him that we were planning to use them to on-board the new employee who probably would not be familiar with BPMN. At first glance, a BPMN diagram seems easy enough to understand, but there are enough unique symbols and details that it is not as straight forward for those that don’t use them that often.
So remember to keep your diagram as simple as possible. The goal isn’t to impress your audience, but rather to provide useful information. If you prefer to provide a highly creative process flow, use a storyboard or infographic at the highest level and then perhaps a more structured business process flow chart for the details. If your diagram communicates effectively, then it’s correct!
Decoding Process Flow Chart Symbols / Notations
If you choose to use a particular type of diagram and are curious about the process flow chart symbols, we’ve provided some guidance below.
Download our complete reference cheat sheet that shows the most frequently used symbols for each type of flow chart.
There is no one correct way to do any of the diagramming techniques. The “correct” way is that it communicates as you intended and provides value. However, various methodologies provide notations and standards as means of providing consistency and therefore, a higher likelihood to minimize misunderstanding among a project team with shared knowledge of the technique. Check with your team to determine if there is a standard notation, otherwise use the diagram that best communicates the information to your audience. The ANSI flow chart has been around since the 1970’s, it’s easy to understand, and used by many organizations today. You know what they say…”If it’s not broke — don’t fix it!”
Get a more comprehensive understanding of these diagramming techniques and how to improve your business process efforts in our Business Process Analysis course.
All the best,
Kupe
Originally published at B2T Training.
