Why Model Business Processes?

By Tom Karasmanis, Senior Consultant – Enterprise Business Analyst
imageUnderstanding how work is done within an organization is very important in deciding change. To do this, business analysts may use a model to see how business processes work within a business unit. A business process is a repeatable flow of activities initiated by a business event that may have multiple paths to completion. 
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) version 2.0 defines business process models as follows:

“A [business] process model is a visual representation of the sequential flow and control logic of a set of related activities or actions.” (9.21.2)
So why do we model business processes? There are two interesting answers to this question. From a more workflow-focused perspective, we model to see how multiple people or groups collaborate over a period of time to perform work. These processes are often complex so a visual representation is a good way to understand that complexity.

From a more business-focused view, we model to capture the approach an organization takes to create, deliver and capture value. This definition highlights one important question a business process model must address: How does the business process deliver value?
Modeling business processes therefore helps with many things, including but not limited to:
  • Eliminating irrelevant details,
  • Presenting processes in a common format for all stakeholders,
  • Understanding complexity,
  • Assessing efficiency,
  • Capturing how value is delivered, and
  • Determining time and cost.
How do we create a Business Process Model?
A business process model will contain two states: the “as-is” or current state and the “to-be” or future state. We often model a number of possible future states based on business requirements, and then we choose the one that best meets our needs and is within our available timeline and budget. Another very important step is to create a change management process that describes how to get from the current state to the selected future state.
To create the current state, a good approach is to start with a set of questions to determine what the current challenges are and ensure a full understanding of the problem we are addressing through our current modeling initiative. At this point it is very important to identify the scope of the model: the objectives that we are trying to achieve and the boundaries of the organizational unit being modeled. The objectives guide is to understand when our model is complete. The boundary guide identifies what is being modeled and what is not. Anything outside the organizational boundary is an external entity that may or may not interact with our process, but is not part of the process.

We then identify key external and internal business events that trigger processes within the organizational unit and refine them into a set of processes. For each process identified we identify the participants (people and groups) and the activities they perform in completing that process to completion, ensuring we also capture exception flows.
When modeling the activities of a process, it is best to start with a context-level “one-pager” that captures the key “top-level” activities. A model is a simplified view of the entire organizational unit that can be drilled down to varying degrees of detail. We can therefore drill down layer-by-layer, expanding activities into sub-processes with their own activities until the required level of detail is reached. How do we know when we have reached the correct level of detail? When all the challenges have been satisfactorily addressed and our objectives achieved. It is important to not get carried away and continue modeling for the sake of modeling. A model simplifies our view of the world and should only contain the amount of detail needed to achieve our modeling goals.
The future state follows a very similar approach as current state, but the focus is on how we would like the process to work in order to deliver better value more efficiently. We develop several candidate (desired) future states along with the high-level transition requirements to get from the current state to the future state. We then assess needs, timelines and cost and determine the most appropriate future state.
Business Process Modeling vs. Business Use Cases
Business use cases define specific processes as a series of sequential steps with alternate flows where necessary. A process model is a collection of processes in an entire business unit (e.g. organization, department, operation). 
Take, for example, handling a mortgage. A business use case may detail how to perform any one process, such as applying for a mortgage, including any alternate flows in that process. A process model will include every process involved in handling a mortgage, including applying, reviewing, renewing, canceling, etc. A business use case provides an individual narrative, where a process model will collect all relevant narratives in one model.
UML vs. BPMN vs. Cross-functional (Swim Lane) Diagrams
Cross-functional (Swim Lane) Diagrams are arguably the first visual format ever used to model business processes. Based on the basic Flowchart Diagram, a Cross-functional diagram adds the swim lane element, which allows the visual identification of who performs a given activity.
Two widely used newer notations are Unified Modeling Language (UML) and Business Process Model Notation (BPMN). With the introduction of BPMN, UML is being used more for systems modeling and BPMN has surpassed it as the preferred practice for business process modeling. However, UML can still be used quite comfortably to model business processes. 
Each notation uses its own unique symbols and terminology, but all models consist of the same basic elements:
  • Activity: triggered by an event, an activity within a process describes work a person or group or system performs
  • Event: an action (manual or automated), condition (rule), or temporal instance (passage or period of time), that triggers an action or process
  • Gateway (Decision): a point in the process where a flow splits into two or more flows or where two or more flows join together
  • Flow: the direction of the sequence, or order of events and actions
  • Swim lanes (Pools): a visual distinction of responsibility, or a visual element identifying who is doing a particular set of activities within a process
One significant advantage of BPMN is the inclusion of intermediate events. These allow for the easy modeling of intermediate conditions that can occur at any time within a sub-process and which trigger a new flow typically out of the existing sub-process, i.e. an exception.
BPMN is also a bit more user-friendly than UML and is often preferred by business users and subject matter experts. However, Cross-functional diagrams continue to be very widely used, primarily as users are more familiar with their notation and are easier to produce as not all tools support UML and BPMN, whereas virtually any drawing tool will likely support the elements required for Cross-functional diagrams.
Models are easy to read and understand, but can often be difficult to write. As one gains experience in modeling processes, there are more techniques and symbols that can be used to make a model more effective.
Modeling business processes is an effective way to examine how work is done within an organization, to understand complexity and to describe how the organization creates, delivers and captures value. By capturing the current and future states, we can implement a change management process to realize that transition as smoothly and painlessly as possible. Since business analysts are concerned with managing change, business process modeling is a critical skill to have.