Design Business Processes with SAP Signavio Solutions

Events - Act and React for Consultants

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

After completing this lesson, you will be able to:

  • Understand how to use events

Start / Intermediate / End Events

Using Events

So far, our processes had a very isolated focus. They didn't consider or react on any external input (e.g. a message from a customer), except the start of the process. The entire chapter is about, using events as part of the process flow to act and react with the business environment.

Events Mark a State in a Process

Events mark a state in a process, at least at the start and at the end. The BPMN 2.0 notation counts more than 60 different events, which emphasizes their importance for business process modeling.

Events are required to show, at which place the business process has to wait for external input to react accordingly. Those events could be:

  • A response from a customer
  • A reached point in time
  • A certain condition (e.g. budget approved)
  • ...

Three Aspects When Using Events

Before we dive deeper into the world of events, it's important to know there are three aspects behind the usage of events. These aspects are helpful in understanding the event behavior and using them correctly.

  1. There are start events, intermediate events and end events - WHERE is an event used?
  2. Events can be catching or throwing - HOW is an event used?
  3. Events can be specified by a type - WHICH event is used?

Start, Intermediate, and End Events

Based on their occurrence in the process, events are categorized as start events, intermediate events and end events. You know already start - and end events, but let's take a closer look at intermediate events.

Blank Start Event

These events can only occur at the start of a process, as they're representing the trigger. Hence, they can only have one outgoing sequence flow.

Blank Intermediate Event

Intermediate events need to have an incoming and outgoing sequence flow. They mark a state in a process without impacting the process flow. The token just "passes through" and marks the state.

Why is this useful? Blank intermediate events can be used to highlight a certain progress (Milestone) in the process flow, for example:

  • Mark a stage as "phase 2 completed"
  • Mark manufacturing status "component X manufactured"

Blank End Event

This event marks the end of the process, as it's representing the process goal. Hence, it can only have an incoming sequence flow.

In some processes it might be useful to mark the state when a certain milestone has been reached. If the process gets executed in a technical environment, the time between different milestones could be measured more specifically. However, such milestones are always optional. Their importance depends on what they are actually describing in the process.

Intermediate Events as Milestones

Key Takeaways - BPMN Events

Event Types

We've only used unspecified events so far (so-called "blank events"). Now it's time to be more specific when we describe a process trigger or an end event. With the need to become more concrete in specifying an event, we have to consider there is a distinction if the event gets triggered or is a trigger itself.

Catching and Throwing

All events have in one thing in common: They define a certain state, which triggers or ends the process. But how does an event reach such a state? There are two possible options:

  1. The event "waits" to get triggered (it "catches" a trigger from the outside).
  2. The event itself is a trigger (it "throws" a trigger to the outside).

This is the concept of catching and throwing events. If this is too theoretical, let's use an example:

Catching Start Event

Reacting on a Trigger

The start event is always in a "waiting" status to start the process as soon as an order arrives. It "catches" the trigger and starts the process.

Throwing End Event

Acting as a Trigger

The end event has "thrown" the trigger and set the state.

Conclusion

Catching events have an impact on process flows. They can:

  • start processes as soon as they got triggered
  • continue process flows as soon as they got triggered
Note
Start events are always catching events!

Throwing events can:

be triggered at the end of the process

Note
End events are always throwing events!

Event Types

Very good! With the two rather theoretical aspects in mind, we can tackle now the last one! Fortunately, this is quite visual and you'll learn new BPMN elements.

All events can be specified, based on their actual nature. They can react to points in time, get triggered by messages or any other external conditions. Based on the real world, not all events be a trigger or got triggered by external influences - it depends on their type.

Event Messages

Manage Interactions with Messages

In most business processes, communication with external participants is an essential part of the process. However, the term and symbol "message" is not limited to letters, e-mails or phone calls. Message events represent everything, which can be received or be sent - it stands rather for "interaction" in general.

BPMN counts 4 different message events, depending on if we're receiving or sending a message.

Catching Intermediate Message Event

Example: Ordering a Pizza

The receiving of the pizza is indicated by a message event and it actually even has to be modeled by using a message event. Otherwise, the task "eat pizza" would be immediately started after the pizza has been ordered (no loss in time).

Hence, we need a message event to express:

  • There is a waiting situation between ordering and eating.
  • The process continues as soon as the pizza arrives or in other words it stops the process flow until the external condition (receiving pizza) becomes true.

Throwing an Intermediate Message Event

Example: Ordering a Pizza

The intermediate throwing message event can also be used model the state the order has been sent. The actual task "send order" is not necessarily required, as the state "pizza order sent" implies the task.

The throwing intermediate message event:

- implicit the task of ordering the pizza

Modeling the ordering task AND the throwing message event would be wrong, as we would order twice in that case.

All Message Events Used

Example: Ordering a pizza

In this example, we can see all four different message events.

So our process starts with receiving a new flyer and ends with providing feedback.

This explains that messages can:

  1. start processes (e.g. by getting triggered other ones)
  2. be sent within a process
  3. delay a process during its execution
  4. end a process (and trigger other ones)

Timer Events

React on points in time.

Due to its flexible usage, the timer event is very popular in practical modeling with BPMN. It can be used to start a process at a fixed - or relative or even a recurring point in time.

A timer event cannot be triggered by the process, so they are always "catching".

Behind this rule is a real-world logic:

  1. the process itself has no influence on time
  2. the process can only react to a current or a past point in time

Timer events are always catching events as a process can only react to a point in time - but cannot control it!

Timer Start Event

Timer start event should be used, whenever the start of a process depends on a certain point a time. There are several options how this time-based start is defined. It can be an interval, a fixed point in time or a relative point to a specific event.

Click on each element to discover the examples.

Timer Events

Using Timer Events

Pizza Process with Timer Event

With timer start events we have the flexibility to start our process at dinner time and order pizza. Ten minutes later, we can start setting the table to get ready for receiving and eating the pizza.

So, our process:

  • starts time based, at a certain point in time
  • is delayed by 10 minutes (but doesn't matter as we have to wait for the pizza anyway)

Both have in common, that the point in time is known to start or continue the process

Note
Timer events can only be used, when the point in time is known, to start or continue the process!

Conditional Events

React on (external) conditions.

Some processes start, based on an external conditions. These conditions are out of the control of the process, which means its unknown when exactly the condition is met - but the process can react to it whenever it is the case. This is the same behavior we have discussed for timer events, so it's also the same rule: Conditional events are always catching events, as they occur out of the control of the process - but the process can react to them!

Conditional Events Example

When to Use Conditional Events?

Isn't everything a condition which needs to be fulfilled? Yes, but based on our pizza example above, there are two uncertainties in the process, which are out of the control of our process:

  • We can't control WHEN the oven reaches 180 degree.
  • We can't control WHEN the pizza is ready - only when it's burned.

This uncertainty of the event and its fulfillment is a good indicator for a conditional event. In practice there are some other examples, where processes cannot influence the condition:

Link Events - Link Process Stages

The link event is to a certain extent a special case: It has no meaning in terms of content, but is only a technical structure element. Two links can replace a sequence flow. This aspect can be really useful in large process models especially where long sequence flows across different lanes would make the model less readable.

Click on each task to find out more.

Link Events

It has no significance related to content, but it facilitates the diagram-creation process. You need to make sure to name them accordingly in order to follow the matching.

Link Events Can be Very Useful

Link events can be very useful if:

  • You have to distribute a process diagram across several pages. Link events allow to link these different process models and enable a "left-to-right" navigation.
  • You have a process with many sequence flows, maybe even across the entire process. Link events help to replace a long sequence flow and keep the process design easy-to-understand.
Note
The name of two link events need exactly to be equal for matching.

Overview of the Most Common Events

Overview of the Learned Event Types

Not every event type has an occurrence in every event dimension, as shown in the figure. It depends on their nature of being only reactive (catching), active (throwing) or even both.

  • Start events can only be catching.

  • Blank Start Event - Can always be used as an unspecified start event.

  • Blank Intermediate Event - Can be used as a milestone in a process. It marks a certain point in a process.

  • Blank End Event - Represents and unspecified end of a process.

  • Message Start Event - Can be used, whenever the process gets triggered by receiving a message, a physical object or anything else.

  • Catching Message Intermediate Event - Represents an incoming message, object or file and "waits" until that point of receiving.

  • Throwing Message Intermediate Event - Represents a message, physical goods to files sent to external process participants.

  • Message End Event - Represents a message, physical goods or files send by ending the process at the same time.

  • Start Timer Event - Can be used, whenever the process start depends on a certain point in time.

    Catching Intermediate Timer Event - Delays the process until a given point in time. Can be used to wait for a deadline (e.g. period for payment before reacting).

  • Start Conditional Event - Can be used, when the process start depends on a condition which is outside of the influence of the process (e.g. an approved budget or a vacant position).

  • Catching Intermediate Conditional Event - Delay the process until an (external) condition is met.

  • Catching Intermediate Link Event - Catches the token from a throwing link event.

  • Throwing Intermediate Link Event - Throws a token to a catching link event.

Note
There are even more event types according to BPMN 2.0, but these are the most important ones, used in process modeling.

Special Topic: Attached Intermediate Events

Since you know now the most common events in BPMN, it's time to focus on a second specialty of events. They can also be used as a cancel condition to tasks.

How does that work? Let's use again our pizza example:

Attached Timer Event

Using the timer event as cancel condition.

In this example, we can't decide on a pizza. Hence, after 10 minutes we give up and decide to cook pasta instead.

That means, when we attach a timer intermediate event to a task:

  • it defines a cancel condition, based on a time
  • we can model an alternative way to the cancelled task and proceed with the process

Attached Mixed Events

Multiple Cancel Conditions

With our cancel condition on choosing a pizza, it can also happen the pizza is not available when we're calling the pizzeria. In this process example we want to make sure, we can still eat pasta and not get starved.

To summarize:

  • All catching intermediate events can be used as cancel conditions for tasks
  • For each attached intermediate event, there must be an alternative path - which can also be the same one

Key Takeaways - Event Types

Event-Based Decision

Reacting on Decisions Made Outside of the Process

So far, we just considered decisions made as part of the process - and used XOR gateways to route the result. Whenever customers or other external participants are involved, we might need to react to decisions made by them in order to proceed with our process accordingly.

Event-Based Gateway

The BPMN has a dedicated gateway to be used to model such cases, the Event-based Gateway.

Note
In business processes, it's often necessary to react to external influences.

Reacting to Decisions Made Outside the Process

Pizza Example

What happens when the Pizza never gets delivered? In the current form the process would get stuck at the catching message event. In practice, it can actually happen we don't get what we've requested or doesn't get at response at all. In that case, we need to think of alternatives to ensure the process can still proceed and doesn't get stuck (and waits forever for an event).

The Event-Based Gateway

The event-based gateway waits for the following intermediate events to happen before it steers the process flow. Whichever of the events happens first is the path that will be taken at the gateway.

The decision is made outside the process, and we or the event based gateway just react to it.

The Event-Based Gateway

Modeling Event-Based Alternatives

In our previous example, it might still be the case we never receive the pizza. How long should we wait? The following process shows a way of modeling an exit of the loop while still not losing the possibility of receiving the pizza.

More specifically:

  • We can always receive the pizza
  • We have an alternative to call the pizzeria 3 times
  • We have an exit, if we don't get the pizza after calling 3 times (90 minutes in total)

Modeling Event-Based Alternatives

Connected Events

Since the event based gateway works in a way of "reaction" to events, there can only be catching intermediate events connected to it. The token waits for the next event occurs in order to proceed.

Key Takeaways - Event Based Gateway

Modeling Exercise - Order Processing (Part 2)

Background

The management of MyStore Inc. is not happy with the previous process and also faces the problem that numerous orders have not been paid yet. In the near future, orders must only be shipped after prepayment. In addition, the process will be extended by the case of missing payment after an order. Therefore, the existing process model has to be adapted again in consideration of these new findings.

Process Modeling Task

Revise your existing process model, so it reflects the following change in the process.

The invoice is not created by the order acceptance department as before, but is now created and sent by the finance department. If payment is received within seven days, the warehouse sends the goods to the customer while the finance department confirms receipt of payment to the customer. If a payment period of 7 days elapses without the customer having paid, a payment reminder is sent. If payment is still not received after a further 5 days, the order will be cancelled and the customer will be informed.

Assignment

  • Transform the process description into a compliant BPMN 2.0 model. We recommend using and editing your model from exercise part 1. You can also create a copy to keep your initial version.
  • Please only use the elements you have already learned and model from the perspective of the MyStore company. There is still no need to include external process participants.

Estimated time effort: ~ 45 min.

Modeling Tip 1- [SMALL SPOILER]

You should use 2 event-based gateways to capture the different possible events, which take place based on the customer "reaction".

Modeling Tip 2 - [BIG SPOILER]

Consider this blank shape model as a design orientation.

If you think you are done, check your solution again for syntax, semantics and naming conventions. Also think about a user-friendly and readable look and feel for your diagram.

Note
There are of course several solutions for this task. However, you should have covered the same subject matters. Of course, the names of the individual elements and overall design may differ slightly.

If you feel confident with your results, view the sample solution and compare with your own.

Signavio Solution to the Order Processing - Part 2

Congratulations! You've completed the section on Events - Act and React!

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