Learning Unit 5 – Business process level modelling

1. Introduction
In this learning unit we focus on modeling one business process at a time. In this unit
you will learn how to crate teh REA pattern for modeling the business process level.

2. Crow’s foot notation vs CHEN notation

Up to so far in your IT courses, you have learned how to model processes (ERD's), by
using the crow's foot notation. In this course, you are going to learn how to use the
CHEN notation in relation with the REA business process level modelling.
In the CHEN notation, many is denoted as N. The cardinalities are presented in
brackets. The major difference between CHEN and crow's foot is that with Crow's
foot the cardinalities of an entity is put "away from the entity, next to the
participation entity". In CHEN, the cardinality of the entity is placed next to the entity
in question.
The following video will give an explanation of the difference in the two notations:
http://www.youtube.com/watch?v=EQg_zmGjzP4

3. Working with patterns

If you look at two very different kinds of businesses, for example a petroleum
manufacturing company, like SASOL, and a retail shop that sells shoes, one’s first
assumption will be that these two companies will have considerably different
ERD's. However, if you start asking the following questions, you realize, that for a big
part of the activities (except for manufacturing), of these two companies, they are
actually quite the same.
For example:
1. Does the petroleum company engage in marketing events? Does the shoe shop
engage in marketing events?
2. Does the petroleum company take orders from their customers? Does the shoe
shop take orders from their customers?
3. Does the petroleum company sell their product? Does the shoe shop sell their
product?
4. Does the petroleum company receive money for the product they sold? Does the
shoe shop receive money for the product they sold?
5. Does the petroleum company have customers? Does the shoe shop have
customers?
6. Does the petroleum company have products? Does the shoe shop have products?

I think you will agree that for all of these questions we answered yes, for both of these
companies. So inherently, what they are doing on a daily basis are actually the same. They
will then both have and entity for marketing events, the will both have entities for sale
orders, they will both have sale entities, and they will both have entities for receiving
cash. Both of them will also have entities to store their customer and product
information. What will be different will be the attributes that are presented inside the
entities. Obviously the characteristics that will be stored about petroleum products will be
totally different from what will be stored about shoes.
This above is then the pattern that exist for doing sales, and almost all companies will fall
into this pattern. Even if you are modeling a service company, that are not actually selling a
product, the product entity will just be replaced with a service entity.
The same pattern can be found in other business processes. For example in acquisition and
payment, the core pattern that will be followed by most businesses will be as follows: (In
the follow up module (AIBYT2C) we will look at expanding these patterns.
1. A company has products and customers
2. The company buys products/services from its suppliers
3. The company pays for the goods that they received.
In the next lessons we will discover how the core pattern for each business process looks.

4. REA Business Process Level Diagram for Sales & Collection

The core pattern used for Sales & Collection (Revenue) assumes that GOODS and/or
SERVICES are sold through a SALE event, in which a SALESPERSON and a CUSTOMER
participates. The CUSTOMER then pays for the sale (CASH RECEIPT), the money is
received by a CASHIER, and the CASH RECEIPT is recorded into one of the business'
CASH accounts.
The following video will explain the modeling of the REA Diagram for the Sales & Collection
Business Process: http://www.youtube.com/watch?v=_NsnGGxDbpQ

5. REA Business Process Level for Acquisition & Payment

The core pattern used for Acquisition & Payment (Procurement), assumes that
GOODS and/or SERVICES are bought from a SUPPLIER, by an EMPLOYEE, through a
PURCHASE event. The SUPPLIER is then payed for the purchase by a CASH
DISBURSEMENT event, the payment is processed by a CASHIER, and the CASH
DISBURSEMENT is recorded into one of the business' CASH accounts.
6. REA Business Process Level for Conversion
In Conversion the core pattern revolves around a transformation duality
relationship. Raw materials are made available through a materials issuance, these
materials are processed by using machines or equipment in a machine usage event,
and labour is used through a labour operation event. The use of all these events and
resources together creates a finished product through the Work In Progress Event.
Each of the events will be linked by 2 internal agents, normally the one doing the
work, and the other one overseeing the work.
7. REA Business Process Level for HR
In HR LABOUR is acquired through a LABOUR ACQUISITION event from an
EMPLOYEE, and this EMPLOYEE is again paid from one of the CASH accounts through
a CASH DISBURSEMENT event.
8. REA Business Process Level for Financing
In Financing, money is deposited in one of the enterprises CASH accounts through a
CASH RECEIPT event, which is paid by an INVESTOR/CREDITOR, and received by a
CASHIER. Money that was received, also now need to be paid back, from a CASH
account by a CASH DISBURSMENT event to an INVESTOR/CREDITOR by a CASHIER.
9. Heuristic Cardinalities
 Heuristic means “the way it is most of the time”.
1. Heuristic Cardinalities for Resource – Event relationships
The heuristic cardinalities is as follows:
Resource (0,N) -------- (1,N) Event
A resource will normally be entered into the database even before any activity is
associated with the resource, and most resources can be sold/purchased more than
once. Remember that it is not the actual product that is sold twice, but another
product with the same code. An event cannot take place without a resource
involved in it, and each event can have multiple resources associated with it.

One exception to the rule is where unique (one of a kind) products are sold. Each
product can now only be sold once. This will change the cardinalities to:
Resource (0,1) ------ (1, N) Event

Another exception is when an event can be linked to two different types of

resources. When there is a choice whether the event can be linked to either the one
or the other resource, it changes the cardinalities to:
Resource (0,N) -------(0,N) Event

2. Heuristic Cardinalities for Event – Agent relationships

The heuristic cardinalities is as follows:
Event (1,1) ------- (0,N) Agent
An event will normally only be linked to only one agent, and it must be linked to an
agent, to keep track of who does what in an enterprise. Agents will always be able
to be entered into the database before taking part in any activities, and agents must
be able to take part in many activities.

The exception to this rule is:

Event (1,N) ------- (0,N) Agent
This situation can arise when an event can be handled by more than one agent, for
example where two people need to sign off on a specific transaction.

10. Finding and interpreting cardinalities.

In a real world situation, the business analyst to not receive a case study from the
enterprise he/ she needs to create a system for. The analyst need to find the
cardinalities and business rules through interviews and observation.