How to Analyze a Business Process

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
• 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 Business Process Model Notation 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 Business Analyst, 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.

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.