Management Information System : Exam ( part of Mr.

Heng )
Business Process

Cross-functional processes IMPORTANT

- No single functional aera is responsible

- Steps executed in a coordinated, collaborative way
- Procurement & fulfillment Cross-functional processes

Business process and ERP IMPORTANT

- A crucial role of ERP in business is to better position the organization to change its
business processes
- ERP software have hundreds of business processes built into the logic of the system
which may or not agree with current processes of an organization
- When implementing an ERP system, organizations have two choices: change business
processes to match the software functionality / modify the ERP software to match
the business processes

ERP implementation plan IMPORTANT

- Comprehensive: - involves implementation of the full functionnality of the ERP
software in addition to industry-specific modules - requires a high level of business
process re-engineering
 - Middle-of-the-road: - involves some changes in the core ERP modules and a
significant amount of business process re-engineering
- Vanilla: - utilizes core ERP functionality and exploits the best practice business
processes built into the software – business process re-engineering is eliminated

Business Process Model and Notation (BPMN)

- OMG standard (nowadays BPMN 2.0)
- Both for conceptual and executable models
- Supported by numerous tools (signavio, bizagi process modeler, cameo business
analyst)

BPMN from 10,000 miles

- Based on popular graphical flowcharts : core set of notation elements, each core
element has various subtypes
- A BPMN process model is a graph consisting of four types of core elements :

- Activities captured work performed in a process (different types of activities)

- Events represent the process’triggers (start event) and outcomes (end event)
(different types of events)

LAB 1 : Order-to-Cash
This process starts whenever a purchase order has been received from a customer. The first
activity that is carried out is confirming the order. Next, the shipment address is received so
that the product can be shipped to the customer. Afterwards, the invoice is emitted and once
the payment is received the order is archived, thus completing the process.

LAB 1 : Order-to-Cash (solution)

This process starts whenever a purchase order has been received from a customer. The first
activity that is carried out is confirming the order. Next, the shipment address is received so
that the product can be shipped to the customer. Afterwards, the invoice is emitted and
once the payment is received the order is archived, thus completing the process.
Gateway IMPORTANT

LAB 2 : Order-to-Cash
A typical order-to-cash process is triggered by the receipt of a purchase order from a
customer. The purchase order has to be checked against the stock regarding the availability
of the item(s) requested. Depending on stock availability the purchase order may be
confirmed or rejected.
If the purchase order is confirmed, the shipment address is received so that the product can
be shipped to the customer. Then the invoice is emitted and the goods requested are shipped.
Once the payment is received the order is archived then the process is completed.

LAB 2 : Order-to-Cash (solution)

LAB 3 : Order-to-Cash
A typical order-to-cash process is triggered by the receipt of a purchase order from a
customer. The purchase order has to be checked against the stock regarding the availability
of the item(s) requested. Depending on stock availability the purchase order may be
confirmed or rejected.

If the purchase order is confirmed and the shipment address is received. Then, the request
product is shipped while the invoice is emitted and the payment is received. Afterwards, the
order is archived and the process completes.

LAB 3 : Order-to-Cash (solution)

Guidelines: Naming Conventions IMPORTANT

1. Give a name to every event and task

2. For tasks: verb followed by business object name and possibly complement (Issue Driver
License, Renew License via Agency)

3. For message events : object + past participle (Invoice received, Claim settled)

4. Avoid generic verbs such as Handle, Record...

5. Label each XOR – split with a condition (Policy is invalid, Claim is inadmissible)

6.Model in blocks

• Pair up each AND-split with an AND-join and each XOR-split with a XOR-join, whenever
possible

• Exception: sometimes a XOR-split leads to two end events – different outcomes.

BPMN Elements IMPORTANT

- Pool & Lanes
- Pool captures a resource class. Generally used to model a business party (a whole
company)
- Lane: a resource sub-class within a pool. Generally used to model departments,
internal roles, software systems
- Syntactic rules:
- The sequence flow cannot cross the boundaries of a Pool
- Both sequence flow and message flow can cross the boundaries of lanes
- A message flow cannot connect two flow elements within the same pool

LAB 4 : Order-to-Cash
A typical order-to-cash process is triggered by the receipt of a purchase order from a customer
to the sale department. The sale department has to check the stock regarding the availability
of the item(s) requested before confirming the order.

If the requested product is not available the order is rejected by acknowledging to the
customer and the process is terminated.

Otherwise, the sale department confirms the order and gets the address of customer then
requests to the delivery department to ship the product to the customer and, at the same
time, requests to the financial department to emit the invoice to the customer. After receiving
the payment, the order is achieved by the sale department and the process is completed.

LAB 4 : Order-to-Cash (solution)

When are message sent or received? IMPORTANT
- A send activity will send the outgoing message upon activity completion
- A receive activity won’t start until the incoming message has been received
Process (or Orchestation) Diagram IMPORTANT
- Models a single business party and can be public view (black box empty) or private
view (white box detailled with BPMN elements)

Collaboration Diagram IMPORTANT

- Models a global business process between at least two business parties (each
modelled by a pool)

Order-to-Cash process
The purchase order document serves as an input to the stock availability check. Based on the
outcome of this check, the status of the document is updated, either to “approved” or
“rejected”. If the order is approved, an invoice and a shipment notice are produced.

Model with information artifacts IMPORTANT

- A data object captures an artifact required (input) or produced (output) by an activity

(physical or electronic)
- A data store is a place containing data objects that must be persisted beyond the
duration of a process instance. It is used by an activity to store (as output) or retrieve
(as input) data objects
- A text annotation is a mechanism to provide additional text information to the model
reader (doesn’t affect the flow of tokens through the process)
Sub-process IMPORTANT
 - An activity in a process can invoke a separate sub-process
- Use this feature to decompose large models into smaller ones, making them easier to
understand and maintain
Guideline: multi-level modeling
- Level 1: Value chain : simple linear description of the phases of the process, no
gateways, each activity chain is a sub-process
- Level 2: expand each activity in the value chain, add incrementally the following :
decisions, handoffs (lanes, pools) / parallel gateways, types of events / data objects &
data stores / as much details as you need
- At each level, decompose according to logical milestones towards achieving the
outcome of the process and to major objects used in the process
- Decompose until proccesses are of “reasonable” size (example: 30 nodes per model)
-

Rework and repetition:

SESE = Singe Entry Single Exit fragment ( a fragment delimited by a single entry node and a
single exit node (there are no other incoming acrs into the fragment or outgoing arcs from
the fragment))
Example of XOR-join: entry point and XOR-split: exit point (exclusive gateways)

Bloc-structured repetition: Loop activity:

 - BPMN also provides the loop activity construct to allow the repetition of a task or
sub-process

Example of procurement (multi-instance activity) : In procurement, typically a quote is to be

obtained from all preferred suppliers (assumption: five preferred suppliers exist). After all
quotes are received, they are evaluated and the best quote is selected. A corresponding
purchase order is then placed.

OR :

Parallel repetition: multi-instance activity:

- Provides a mechanism to indicate that an activity is executed mutliple times
concurrently
- Useful when the same activity needs to be executed for multiple entities or data items,
such as:
• Request quotes from multiple suppliers
• Check the availability for each line item in an order separately
• Send and gather questionnaires from multiple witnesses in the context of an insurance
claim
How do we model this scenario ?
PO handling A Purchase Order (PO) handling process starts when a PO is received. The PO is
first registered. If the current date is not a working day, the process waits until the following
working day before proceeding. Otherwise, an availability check is performed and a PO
response is sent back to the customer.

Events handling IMPORTANT

In BPMN, events model something instantaneous happening during the execution of the
process. The affect the process flow: Start / Intermediate / End
 - Use message events only when the corresponding activity would simply send or
receive a message and nothing else

Temporal events IMPORTANT

In a small claims tribunal, callovers occur once a month to set down the matter for the
upcoming trials. The process for setting up a callover starts three weeks prior to the callover
day, with the preparation of the callover list containing information such as contact details of
the involved parties and estimated hearing date. One week prior to the callover, the involved
parties are notified of the callover date. Finally, on the callover day, the callover material is
prepared and the callover is held.

PO handling A Purchase Order (PO) handling process starts when a PO is received. The PO is
first registered. If the current date is not a working day, the process waits until the following
working day before proceeding. Otherwise, an availability check is performed and a PO
response is sent back to the customer.

Multiple start events IMPORTANT

Racing events: Event-based decision IMPORTANT

With the XOR-split gateway, a branch is chosen based on conditions that evaluate over
available data : The choice can be made immediately after the token arrives from the incoming
flow
Sometimes, the choice must be delayed until an event happens: The choice is based on a
“race” among events
Two types of XOR split: data-driven XOR-split / event-driven XOR split
Matching choices in different business parties IMPORTANT

Lead-to-Quote:

Recap: message and timer events IMPORTANT

Process abortion:
- Exceptions are events that deviate a process from its “normal” course
- The simplest form of exception is to notify that there is an exception (negative
outcome)
- This can be done via the Terminate end event: it forces the whole process to abort
(“wipes off” all tokens left behind, if any)
Example: terminate event

Exception handling:
- Handling exceptions often involves stopping a sub-process and performing a special
activity
- Types of exceptions for an activity (task/sub-process):
• Internal: something goes wrong inside an activity, whose execution must thus be
interrupted. Handled with the Error event (that indicates an error: the “end”)
• External: something goes wrong outside the process, and the execution of the current
activity must be interrupted. Handled with the Message event
• Timeout: an activity takes too long and must be interrupted. Handled with the Timer
event
- All these events are catching intermediate events. They stop the enclosing activity and
start an exception handling routine.

Example: internal exception SOLUTION

Consider again our “PO Handling process” example with the following extension: if an item is
not available, any processing related to the PO must be stopped. Thereafter, the client need
to be notified that the PO cannot be further processed.
Example: external exception SOLUTION
PO handling A PO change request may be received any time after the PO is registered. This
request includes a change in quantity or line items. When such a request is received, any
processing related to the PO must be stopped. The PO change request is then registered.
Thereafter, the process proceeds as it would do after a normal PO is registered. Further, if the
customer sends a PO cancelation request after the PO registration, the PO processing must be
stopped and the cancelation request must be handled.

Example: non-interrupting boundary events SOLUTION

PO handling: The customer may send a request for address change after the PO registration.
When such a request is received, it is just registered, without further action.
Sometimes we may need to trigger an activity in parallel to the normal flow, i.e. without
interrupting the normal flow.
This can be achieved by using non-interrupting boundary events

Complex Exceptions: non-interrupting event + Signal event SOLUTION

Further, if the customer sends a PO cancelation request after the PO registration, the PO
processing must be stopped and the change request needs to be handled.
[...] Further, if the customer sends a PO cancelation request after the PO registration, the
request is first assessed. Based on the progress of the order handling (e.g. if items have already
been fetched from external warehouses) a penalty is determined and communicated to the
customer. The customer has 48 hours to accept the penalty and go on with the cancelation or
to stop the cancelation and continue with the order handling.
To send or receive a signal for synchronization purposes
A signal is broadcasted without any specific target. Thus is can be caught multiple times
Signals are different than messages which are routed to a specific target

Recap: Events

Process Modeling Method

Stepwise method to conduct the modeling
1. Identify the process boundaries
What are the process triggers?
• Purchase order received
What are the possible outcomes (positive/negative)?
• Positive outcome: order fulfilled
• Negative outcome: order rejected
Which perspective do we assume?
• Seller
What artifacts are required as input and output to the process?
• Input: Purchase order
• Output: Invoice, Shipment notice

2. Identify activities and events

3. Identify resources and their handovers

4. Identify the control flow

 5. Identify additional elements ( data objects, types of events, exception handling )

Process model quality assurance IMPORTANT

Syntactic quality: Structural correctness IMPORTANT

1. Element-level rules:
• activities must have at least one incoming and one outgoing sequence flow
• start events must not have incoming arcs, end events must not have outgoing arcs
• gateways must have exactly one incoming and at least two outgoing arcs (splits) or at least
two incoming and exactly one outgoing arcs (joins)
•...
2. Model-level rule: all flow nodes must be on a path from a start to an end event
 i.e. no dangling arcs or disconnected nodes
 implies that a model should have at least one start and one end event.
 → Behavioral correctness
1. option to complete: any running process instance must eventually complete,
2. proper completion: at the moment of completion, each token of the process instance
should be in a different end event, and
3. no dead activities: any activity can be executed in at least one process instance

Semantic quality: validation IMPORTANT

• Semantic quality relates to the adherence of a process model to its real-world process.
• Validation is the activity of checking the semantic quality of a model by comparing it with its
real-world business process.
• A model is of high semantic quality if it is semantically correct:
- Valid (all model instances are correct and relevant) +
- Complete (all possible process instances are covered)

Pragmatic quality: Certification IMPORTANT

Pragmatic quality relates to the usability of a process model

Challenge = anticipate the particular usage of the model

Usability:
• Understandability: how easy it is to read and comprehend the model
• Maintainability: how easy it is to apply changes
• Learning: how good a model reveals how its corresponding process works in reality
Model characteristics that influence usability include size, structural complexity and layout

1. Vocabulary (e.g. banning the use of the OR gateway)

2. Structure (e.g. limiting the size of a model to max 30 nodes)
3. Semantics – rare (e.g. using data objects to only capture information flow)
4. Appearance (e.g. enforcing a particular labeling or layout style)
Seven Process Modeling Guidelines IMPORTANT

- G1 Use as few elements in the model as possible

- G2 Minimize the routing paths per element
- G3 Use one start event (per trigger) and one end event (per outcome)
- G4 Model as structured as possible
- G5 Avoid OR gateways where possible
- G6 Use verb-object activity label
- G7 Decompose a model with more than 30 elements

Mock Exam questions IMPORTANT

Example homework BPMN IMPORTANT