Design Business Processes with SAP Signavio Solutions

Introduction to Business Process Modeling in Practice (BPMN 2.0) for Consultants

Objectives
After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Read, interpret, and model business processes in BPMN 2.0

Process Modeling and Design

How Can we Define a Process?

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.

A Business Related Input

The input can be considered a value that will be transformed by a business processes to add more worth to the company. This increased value can be internal or external. 

Inputs can be:

  • Raw material
  • Data
  • Services
  • Information

Repetitive Business Tasks

Tasks in a process transform the input to an output that provides value to a company. These tasks should be:

  • Repetitive
  • Measurable
  • Relevant

Performing Resources

Although responsibilities are not part of the process definition, there can't be a process without defined resources performing the tasks.

These resources can be:

  • People
  • Systems
  • Machines

A Business Goal/Output

The output provides added value to the company. This can be a product, data, or service. Depending on the process, the output can also serve as an input for subsequent processes.

Outputs can be:

  • Products
  • Created data
  • Services

Depending on the output, processes can be divided into management processes, operational processes (also called "core processes"), and supporting processes. Ideally, all these processes follow an end-to-end perspective to provide a value-added output to either external customers or internal processes.

BPMN 2.0

BPMN stands for Business Process Model and Notation and covers 14 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 2.0 Adoption

Why is BPMN 2.0 so Well-adopted in the market?

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
  • Intuitive
  • Executable
  • International standard
  • Certification program

Order-to-Shipment Process Example

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 questions for this process.

Questions:

  • 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?

Process Models Relay Answers Quickly

  • 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 lesson!

Requirements for a (BPMN) Process Model

How can we define a process?

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.

Designing a Map

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.

BPMN Process Modeling

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.).

Process Modeling Goals

In Process Modeling there are three goals which need to be considered:

  • Goal 1 - Syntactically Correct
  • Goal 2 - Semantically Correct
  • Goal 3 - Understandable

Goal 1 - Syntactically Correct

Checked by the system:

  • Are the used elements connected correctly?
  • Can it connect them (according to BPMN rules)?

Goal 2 - Semantically Correct

Checked by people:

  • Is the order of tasks correct?
  • Are the correct responsibilities used?

Goal 3 - Understandable

Checked by people:

  • Can the process be understood by stakeholders?
  • Is the process flow easy-to-follow or confusing?

The Challenge: Business Complexity vs. Model Simplicity

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.

Business Scenario

How can we ensure process models are simple to follow?

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.

Step 1: Model the Relevant Process Information first!

Is the process model below easy to follow?

This is a process example based on the process description 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

Step 2: Improve the Design Afterwards!

Better design to achieve greater understanding

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, successfully 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.

How Detailed Should a Process be Modeled?

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.

Option A: High-level View of an Order-To-Cash Process Example

High-level 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.

Option B: Exemplary Process Illustration of a Technical Process (e.g. Order-to-Cash Executed in an ERP-System)

High-level 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.

Conclusion

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.

Key Takeaways

Save progress to your learning plan by logging in or creating an account