Introduction to Business Process Modeling in Practice (BPMN 2.0)

Every process journey starts with information.

There are hundreds of definitions on the internet, but we can all agree that a process needs a start and finish - and along the way, there are tasks to complete. Getting lunch is a daily process, but it is not a business process. In this lesson, we focus on business processes and how to analyze them.

A business process is like an assembly line; tasks are completed in various stages to create a finished product.

Business Process Model and Notation (BPMN) and covers many years of process development and improvement. Today, it's known as the common standard of modeling business processes in companies worldwide. It's a graphical notation (collection of symbols/element shapes) for process modeling, standardized by the Object Management Group (OMG).

You can download the BPMN 2.0 specification from the official OMG website: https://www.omg.org/spec/BPMN/2.0.2/PDF

BPMN is a globally accepted modeling notation and is used across different industries (we, at SAP Signavio can definitely confirm this). Although our customers' business processes are all different and include different levels of complexity, BPMN 2.0 comes with a set of symbols and modeling elements to simplify procedures.

There are good reasons for its successful adoption:

• Extensive selection of process modeling elements

  In comparison to other notations, such as EPC (event-driven process chain, from ARIS), BPMN provides various elements to model specific scenarios in processes. For example, specific event types, external driven decisions, or better responsibility assignment.

• Intuitive

  BPMN process models are naturally flow-oriented and process viewers can understand them intuitively, which is a critical adoption factor for companies and employees.

• Executable

  BPMN process models can be expected as a BPMN XML, which is defined in the specification as well. This file is executable by Process Engines, such as SAP Signavio Process Governance.

• International standard

  Due to its international ISO standardization, BPMN is used globally and has a huge supporting community. The official norm is ISO/IEC 19510:2013.

• Certification program

  You can obtain a certification on the BPM knowledge by the OMG, including BPMN 2.0.

Why is a construction manual for a chair not written in text but explained in images? Because people can understand visual instructions easier.

Read the description of an Order-to-Shipment process and ask yourself the following questions.

When a new order arrives from a customer, the receipt of the order is acknowledged. The customer service team calculates any possible discount and then starts to create an invoice. Meanwhile, the warehouse team prepares the goods for shipment. After checking the priority of the shipment, the goods are dispatched via express delivery (for high priority shipment) or standard delivery (for standard priority shipment). Once the goods are dispatched, the customer receives a notification that the goods are on the way so that the delivery status can be tracked.

1. How many tasks are mentioned?
2. Are there gaps in the process?
3. How many responsibilities exist?
4. Is other information that is not captured in the description relevant?
5. Where decisions must you make?

1. Goal: Shipping an order to the customer
2. Tasks: To complete the process, six tasks must be executed.
3. Responsibilities: One customer, two internal departments
4. Handovers and interactions: Two internal handovers (Customer service to Warehouse). The customer is contacted four times.
5. Decisions: One decision about "shipment priority" is included.

This is a simple example and most business processes are more complex. Nonetheless, this simple process emphasizes the importance and true power of representing a process in a visual way. Also, it's important to know that the more complex a process is, the more relevant the visualization of the process is.

In the next section, we check the requirements for a BPMN process model.

Imagine you want to draw a map of your daily commute.

You already know that you must consider buildings, parks, places, and maybe even some other elements to provide an orientation, so another person gets an understanding of your route. It must be connected correctly, for example, by streets and bridges. More importantly, the connection must also include the names of the streets. Finally, the route is clearly defined and understandable, so that other people can also follow the route.

Creating business process models with BPMN 2.0 often involves numerous people within an organization. This increases the importance of maintaining quality and having standards throughout. Knowing about BPMN shapes and elements (similar to or our map example) doesn't automatically lead to a well-designed process model. Sometimes, the level of complexity is hidden, for example, in sub-processes, or paths in a process must be rearranged to provide better process knowledge.

Even if all elements are connected correctly (syntactically correct), a system cannot check if the tasks are in the right order or if roles/departments are named correctly (semantically correct). It requires internal modeling conventions to ensure consistency. For example, consistent use of the same terms for roles and systems.

In practice, it can be challenging to ensure that process models are easy to understand for new viewers especially when modeling complex business scenarios. BPMN 2.0 provides a wide range of elements to model various business processes. However, not all process viewers can understand these elements intuitively by looking at a picture of the process.

This refers to the intricacies of business operations, structures, and processes within an organization. High business complexity can arise from various factors, such as:

• many processes.
• diverse teams.
• global operations.
• regulatory requirements.
• intricate interdependencies between business units.

In the context of business process management, model simplicity typically refers to the clarity, ease of understanding, and efficiency of representing business processes in a visual model. Simple models are easier to comprehend and maintain, facilitating better communication among stakeholders and making it easier to identify areas for improvement or optimization.

Let's look at a business scenario that describes a typical process for creating and sending a quote. This scenario includes the review, approval, and process that loops back to the start if something goes wrong.

Let's use the following process example.

Before a sales quote is sent to a customer, the Sales Quality team must review and approve the quote. After sending an approved quote to the customer, the next step in the process is up to the customer:

• If the quote is accepted, the new service subscription is activated.
• If more negotiations are required, the Sales Quality team must review and approve an adjusted quote. This is done before the quote is sent out again. Therefore, part of the process is repeated.
• If the customer rejects the quote, the customer is contacted for further clarification. The results are further adjustments to the quote or an actual rejection.

This is a process example based on the process described previously. Can you clearly see the process flow or is it confusing? Although all information has been considered correctly, the process model looks overloaded and confusing. It's because the process design has not been considered properly, but it plays an important role in process modeling.

What leads to a visual problem?

• Too much wasted space.
• Tasks are not aligned.
• Sequence flows are not aligned.
• Sequence flows are crossing each other.
• The mix of object usage flows and message flows distract from the actual process flow.

We recommend modeling the actual process but not showing all the details, such as usage flows, data objects, and IT-Systems. The process flow must be easy for viewers to follow.

Here are a few examples of how to improve the process design:

• Remove unnecessary space when possible.
• For a better visual separation in complex processes, use colors wisely. For example, successful and nonsuccessful process endings.
• Add helpful hints if an advanced element is needed, so other viewers can understand by reading.
• Avoid crossing process flows. Switch lanes or rearrange them if possible.

There is no general answer, since the level of detail and complexity depends on the target group. To determine how detailed it must be, ask yourself the following questions:

• Who is the target group for your model? For example, management, subject-matter experts, or new employees.
• What is the proper level of detail for this target group? For example, high-level overview, core tasks, or detailed steps.
• What is the purpose of your model? For example, overall process understanding or detailed explanation for system implementation.

What Level of Abstraction is Required?

Having only one process model is difficult if you must address different stakeholders. In practice, when deciding the level of abstraction required, there can be several aspects to consider for a process:

• High-level view
• Detailed view

Management is likely to be interested in short facts and a summary of what is happening. Is this rough overview sufficient for the roles that are involved in the process?

Semantic inaccuracies or contradictions always carry the risk that your model can be misinterpreted. This risk is high if you create a to-be model and hand it over to the IT colleagues to implement it technically.

IT-related stakeholders, especially technical execution teams, usually need more details for automating business processes or supporting them with systems.

If you want to feed your process model directly into a process engine or ERP system for execution, you have no choice but to model correctly, accurately and consistently.

You might have to create individual models for specific target groups, so that they contain all the facts that are important for the business case.

The requirements of the process model differ, depending on the purpose of the model and the stakeholders.