A Business Process Model is a commonly used business analysis technique that captures how a business process works and how individuals from different groups work together to achieve a business goal.
- If you tend to be technology-focused, a business process model can really help you break away from the software or system-focus that you cover in a use case.
- If you know more about the business than about the technology, a business process model is a tool you can use to analyze and communicate the information you have about what the business wants without getting into the technical details.
- And if technology changes tend to create a lot of headache, a business process model might help you discover a lot of improvements you can make without touching the technology systems at all.
Let’s look at what a business process model is, how you’d go about creating one, how a process is different from a procedure, and then briefly discuss BPMN and when to use it (because that’s a question that comes up a lot!).
What is a Business Process Model?
A Business Process Model is a step-by-step description of what one or more business users does to accomplish a specific goal. Those steps can be manual, paper-based, or software-based.
A Business Process Model also covers the variations and exceptions in the process. For example, if you are looking at a billing process, you might decide how the accounts receivable clerk should handle the case of an invalid postal code.
How Do You Create a Business Process Model?
A Business Process Model contains the following elements:
- Statement of Scope – It’s very easy for one process to turn into several. Naming your process with a clear name in the [Verb] [Noun] syntax and writing a starts with / ends when statement will help you clearly identify the scope of the process.
- Desired Outcome – It’s easy for a process to get ingrained in “how we do it here” but lose its value over time. As a BA, it’s also very easy to jump into the details of what we do before stopping to consider why we do it. A clear answer to why we work through this process will guide your analysis.
- Process Flow or Activity Descriptions – This is the meat of the process model. It’s essentially a list of the steps completed by people in certain roles. This is the primary or most common path through the business process.
- Exceptions – In addition to the primary path, you want to include variations. What happens if information on a form is illegible, a required piece of information is not provided, or a special condition is met?
- Business Rules – Your process flow will presume a certain set of rules are followed or enforce those rules. As processes get more complex, it often makes sense to break the business rules out separately so they can be more easily managed as they change.
- Entry Criteria and Inputs – Entry Criteria identify what needs to be true in order for the process to start. Inputs identify any tangible work items someone executing the business process needs to have present-at-hand.
- Exit Criteria and Outputs – Exit Criteria identify what needs to be true when the process ends. Outputs identify tangible work items generated through the course of the business process.
- Workflow Diagram – While not required, often it makes sense to include a visual model showing the primary activity steps and exceptions. When multiple roles are involved, a swimlane diagram is a good choice.
Before I forget, you can download my annotated business process template free-of-charge.
A Business Process Model is Not a Procedure
One common mistake I find when reviewing deliverables is that the BA will cover the “how” of the business process in too much detail. As you do this, you start to lose the process view of the model (or the “what”) and get into a procedural view.
- A Procedure captures the specific actions (such as clicks, downloading files, and updating files) that instructs a specific business user how to do their job. You’d typically see a procedure included in an operating manual or training guide.
- A Process captures the sequence of steps at a slightly higher level, focusing on what needs to be accomplished and how activities from different departments integrate together.
While Procedures are a valid form of documentation and can be necessary to train people to do their jobs, they tend not to achieve the same objectives as processes. Because they are so granular, you lose the big picture view of the end-to-end process. If you are looking at changing your systems or updating your processes, you might find that your discussion is too deep into the weeds to discover the bigger impact improvements available to you.
BPMN is Not Required
Business Process Model Notation (or BPMN) is a notation that can be used to put together a visual model describing the business process. While BPMN is the most commonly used formal notation for business process models, it’s not the most commonly used notation generally. And if you’d looked at the list of 50+ elements that are part of BPMN you might be feeling overwhelmed at the possibility of creating such a diagram.
I have some good news for you.
Most business analysts still use simple workflow diagrams to visually model their business processes. Simpler models communicate the same information but tend to be easier for our stakeholders to understand and provide feedback on.
Unless your organization is formally introducing BPMN or you are dealing with a complex business process that requires some more sophisticated modeling elements, start with a workflow diagram. You’ll be more confident in what you put together and everyone will be able to focus more intellectual energy on getting the process right without worrying about getting the model right.
(In the Business Process Analysis course, we provide a list of 5 modeling elements that most BAs use 90% of the time – this doesn’t have to be complicated.)
A Business Process Model Helps You Get to the Underlying Problem
As you are looking for ways to expand your role as a business analyst, a business process model is a logical choice.
- As a software developer, discovering a business process can help you get out of the technical details and learn more about what your business users need from your software. (Here’s how one of our readers transitioned from software development to business analysis, starting by documenting a business process for her technology department.)
- As a subject matter expert, discovering the business process can help you understand the upstream or downstream impact at your work or improve the work you do day-to-day.
- As a business analyst, discovering the business process can help you discover the underlying business need before you start specifying the details of a solution