Introduction to Business Process Modeling in Practice (BPMN 2.0)

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. Now, getting lunch may be a daily process, but it is not a business process. In this lesson, we are going to 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.

BPMN stands for Business Process Model and Notation 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 here (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 a variety of elements to model specific scenarios in processes (e.g. specific event types, external driven decisions, or better responsibility assignment).

• Intuitive

  BPMN process models are naturally flow-oriented and can be understood intuitively by process viewers, 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 (like 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

  Users can get certified 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 process description on an Order-to-Shipment process below and ask yourself the following questions. When you're done, answer the Knowledge Check slides for this process.

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.

• How many tasks are mentioned?
• Are there gaps in the process?
• How many responsibilities exist?
• Is other information which is not captured in the description relevant?
• Where are decisions to be made?

• Goal: Shipping an order to the customer
• Tasks: 6 tasks need to be executed to complete the process.
• Responsibilities:1 customer2 Internal departments
• Handovers and interactions: 2 internal handovers (Customer service → Warehouse)Customer gets contacted 4 times
• Decisions: 1 Decision about "shipment priority" included

Of course, this is just 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. Additionally, it's important to know that the more complex a process is, the more relevant the visualization of the process is.

Let's now check the requirements for a BPMN process model in the next section!

Imagine you want to draw a map of your everyday commute

You already know that you need to consider buildings, parks, places, and maybe even some other elements to provide an orientation, so another person gets an understanding of your route. It all needs to be connected correctly (e.g. via streets, bridges etc.). Most importantly, the connection needs to include the name of the streets as well. In the end, the route is clearly defined and provides a good understanding so another person can also follow it.

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 & elements (similar to or our map example above) doesn't automatically lead to a well-designed process model. Sometimes, the level of complexity is hidden (e.g. in sub processes) or paths in a process need to be re-arranged 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 (e.g. consistently using the same terms for roles, systems etc.).

In practice, it might be challenging to ensure 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 the variety of business processes. However, not all process viewers can understand these elements intuitively through looking at a picture of the process.

Select the + icons in the figure for more information.

Let's look at a business scenario that describes a typical process for creating and sending a quote. This 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, it must be reviewed and approved by the Sales Quality team. After sending an approved quote to the customer, the next step in the process is up to the customer:

• If the quote gets accepted, the new service subscription will be activated.
• In the event of further negotiations, an adjusted quote needs to be reviewed and approved by the Sales Quality team. This is done before the quote is sent out again (this means that a part of the process is repeated).
• If the quote gets rejected by the customer, they get contacted for further clarification. The result could be further adjustments to the quote or an actual rejection.

This is a process example based on the process described above. 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 space wasted
• Tasks are not aligned
• Sequence flows are not aligned
• Sequence flows are crossing each other
• 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 (e.g. usage flows, data objects, and IT-Systems). The process flow should be always easy to follow for viewers.

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

• Remove unnecessary space when possible
• Use colors wisely for a better visual separations in complex processes. For example, successful and non-successful 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. In order to determine how detailed it should be, ask yourself the following questions:

What Level of Abstraction is Required?

Having just one process model might be difficult when addressing different stakeholders. In practice, there might be several aspects to be considered for a process when deciding the level of abstraction required:

• High-level view
• Detailed view

Stakeholders from management are most likely interested in short facts and a summary of what is happening. But 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 will be misinterpreted. This risk is particularly high if you create a To-be model and hand it over to the IT colleagues in order 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 they contain all the facts that are important for the business case.

The requirements of the process model may be different depending on the purpose of the model and the stakeholders.

Select each level in the figure for more information.