BUSINESS PROCESS DESIGN BASED ON COMMUNICATION

AND INTERACTION

Joseph Barjis

Department of Information Technology, Georgia Southern University

P.O. Box 8150

Statesboro, GA 30460, U.S.A.

Isaac Barjis

New York City College of Technology, City University of New York

Room P313, 300 Jay Street

Brooklyn, NY 11201, U.S.A.

Keywords: Petri net, transaction concept, business processes design, IS design.

Abstract: The easiest way that people describe their roles in an organization or the way that members of an

organization make promises and commitments to fulfil a task is through communication and interaction. In

such a communication language is used as a tool or facilitator of action when a customer requests a service

and the supplier promises to provide such a service. In this paper we introduce a language-action based

methodology for designing business processes for the Department of University Housing at Georgia

Southern University planning to acquire a new information system for managing, supporting and improving

the “process of rooms assignment” to some 4000 students. As stated, the methodology is based on language-

action perspective and therefore we have used the business transaction concept for mining atomic business

processes. Each business transaction identifies an essential activity and reveals the actors and their roles as

an initiator or executor of the transaction. Since the transaction concept is used as a conceptual basis, the

methodology is complemented with Petri net graphical notations as a modelling technique.

1 INTRODUCTION

It is very natural that members of an organization

use natural language (communication) for describing

how they fulfil their duty and contribute to the

mission of their organization. They use

communication when they are making

commitments, participate in carrying out tasks,

interacting with customers. Therefore the language-

action perspective (LAP) became an interesting

framework in understanding, analyzing and

designing organizational processes, business

systems, IS and IT Applications. In this paper

authors uses a methodology based on the language

action perspective.

How language and communication facilitate

actions has been studied by philosophers for long

time. Although this study traces its origin back to

ancient philosophy of language, however most cited

work within the community of practice is Austin

(Austin, 1992) who, in his work “How to Do Things

with Words”, argues that human being uses

communication as a means of coordinating and

accomplishing actions and creating facts and by

saying they mean to do something. This approach

was further developed and applied in the work of

other authors that made marvellous contribution to

the study of language as facilitator of actions

(Habermas, 1984; Searle, 1969; Winograd and

Flores, 1986).

Although different approaches are used for

business process design, in this paper we discuss a

methodology based on the transaction concept

introduced within the DEMO methodology (Dietz,

1999; Dietz, 2002) which in turn is based on the

language action perspective.

The transaction concept, that will be discussed

later, is about how communication leads to actions

197

Barjis J. and Barjis I. (2006).

BUSINESS PROCESS DESIGN BASED ON COMMUNICATION AND INTERACTION.

In Proceedings of the Eighth International Conference on Enterprise Information Systems - ISAS, pages 197-203

DOI: 10.5220/0002497601970203

 SciTePress

and how communication can serve as basis for

elicitation of atomic processes – called business

transactions. Consequently, each business

transaction is a building block in designing business

processes or a requirement for planning and

designing an information system.

In order to put business transaction in an easily

readable and timely order to build a complete model

and communicate the results back to the users, clear

and readable graphical notations are needed. For this

purpose, the rich graphical notations of Petri nets are

combined with the transaction concept.

A challenge in information system or business

process design is adequacy, simplicity, integrity and

computer support of methodologies and tools used

for this purpose. In order to propose a more

integrated and comprehensive methodology, we

have combined the two mentioned concepts –

transaction concept and Petri nets – to help analysts

in designing system at conceptual level that will be

further used for physical system design. The rest of

this paper will introduce both the transaction concept

and Petri nets, and their application in designing

business processes in the Department of University

Housing at Georgia Southern University planning to

design an information system to make the room

assignment process more effective and efficient.

2 THE TRANSACTION

CONCEPT

The transaction concept is based on idea that an

organization and its underlying business processes

are a network of business transactions that represent

the essence of this organization. This concept looks

at communication, more precisely, business

communication as a tool to elicit and capture

underlying action patterns that represent the business

processes. In this context, the notion of

communication is not an exchange of information

(words and sentences), but negotiation, coordination,

agreement, commitment that lead to certain actions.

In turn, these actions create new facts, deliver

results, and accomplish the mission of an

organization.

Each business transaction, as illustrated in figure

1, encompasses action and interaction. The action is

the core of a business transaction. The action

represents an activity that changes the state of the

world, where the interaction is facilitator of this

activity. The interaction represents communication

(request, coordination, discussion, agreement,

negotiation, commitment, promise) for the initiation

and completion of the action.

Figure 1: The business transaction concept.

Example: a customer applies for home

mortgage to a loan officer in a bank. The first

interaction takes place when the customer

communicates with the officer to request a loan,

and submits an application. Then the officer

processes the application, checks the documents

and makes a decision, that is, takes an action.

The second interaction takes place when the

officer, after processing the application,

communicates the decision to the customer.

As the ‘mortgage’ example shows, there are

three stages in the process: the first interaction, the

action, and the second interaction. Accordingly, as

illustrated in figure 2, the transaction concept states

that each business transaction consists of three

phases that are called order phase, execution phase,

and result phase. The order phase is the first

interaction, the result phase is the second interaction

and the execution phase is where the action takes

place. These phases are abbreviated as O, E and R

correspondingly. To distinguish between the action

and interaction, the action (E-phase) is represented

by a different colour. The diagram of figure 2 is

based on Petri nets notations that will be discussed

later in this paper.

Figure 2: The transaction structure using Petri net

diagram.

On the left side of figure 2, a transaction is

represented as a sequence of the three phases, while,

for compactness, the right side of the figure

compresses the three phases into one unit called a

transaction (T). The importance of splitting a

Action

Interaction

Transaction

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

198

transaction into three phases or compressing them

into one unit arises when dealing with complex

business processes, where numerous transactions are

chained together. A simple transaction is carried out

straightforward without triggering other

transactions; therefore a compact notation is used.

The compressed notation helps to build more

compact models.

Example: in the ‘requesting mortgage’

transaction, the application processing triggers

another transaction ‘checking credit’. In order to

approve the application, the officer needs to

check credit history of the customer with a credit

reporting agency. It means the ‘requesting

mortgage’ transaction is nesting the ‘checking

credit’ transaction. Thus, the ‘requesting

mortgage’ transaction starts first and the

‘checking credit’ transaction starts afterwards,

but the ‘requesting mortgage’ transaction can’t

be completed until the result of the ‘checking

credit’ transaction is known.

In real life, business processes are more complex

than the ‘requesting mortgage’ example that is

purposefully simplified in order to escape in-depth

discussion for later.

The last notion to be explained in regard to the

transaction concept is the role of actors involved in a

business transaction. As it is apparent from the

‘requesting mortgage’ example, each transaction

involves two actors. The actor that initiates the

transaction is called the initiator (e.g., customer,

client or consumer) of the transaction, while the

actor that executes the transaction is called the

executor (e.g., supplier, server or provider) of the

transaction. Actors can be a human actor, software

agent or machine. For example, if the mortgage

application is submitted online, a software agent will

collect data and process application instead of the

loan officer and make preliminary estimates for later

approval by a human actor (the loan officer).

Now that the transaction concept is introduced, it

is appropriate to give a definition of business

transaction used in this paper.

Definition: A business transaction is a generic

pattern of activity carried out in a close interaction

between two distinct actors called initiator and

executor. The activity is carried out in three phases

called order phase, execution phase, and result phase

that creates a new fact and changes the state of the

world. These three phases are made up of interaction

and action, where the order and result phases

represent the interaction and the execution phase

represents the action.

Concluding this section, the following is

description of the ‘requesting mortgage’ process

using the transaction concept:

Transaction 1: ‘requesting mortgage’

Initiator: ‘customer’

Executor: ‘officer’

Result: ‘loan approved/declined’

Transaction 2: ‘checking credit’

Initiator: ‘officer’

Executor: ‘credit agency’

Result: ‘credit report is created’

From the two transactions above, transaction 2

must be initiated and executed during transaction 1.

Thus, initiation, execution, or completion of a

business transaction may lead to initiation and

execution of new transactions. In this way

transactions are chained into arbitrarily large

structures, called business processes (Dietz, 1999).

The following is a definition of business process

in the framework of the methodology that is applied

in this paper based on the transaction concept.

Definition: A business process is network of

interrelated business transactions that delivers value

(good or service) to customers having one start point

and one end point. It starts with a request by an actor

and ends with a result communicated to the same

actor. Usually a business process is one super

transaction that for its completion initiates a series of

other transactions.

Now having discussed the transaction concept,

the following section provides a brief introduction to

Petri nets in general.

3 PETRI NETS (PN)

In research and commercial projects, Petri nets are

extensively used as tools for systems and processes

study and their design, specification, modelling,

simulation and verification (Peterson, 1981). Petri

nets are developed in two directions: theory and

application. The theoretical development of Petri

nets is based on their application in systems and

processes modelling, design and simulation.

Since the application of Petri nets in systems

design and modelling has driven tremendous interest

among researchers and a huge number of papers,

theses, and projects were devoted to this issue, Petri

nets have been getting serious extensions that

resulted in different types of Petri nets. Nevertheless,

the basic principles of Petri nets and the basic

graphical notations remain almost the same. For

interested readers, the following are references to

BUSINESS PROCESS DESIGN BASED ON COMMUNICATION AND INTERACTION

199

different types of Petri nets used by analysts and

researchers in different areas.

These different types of Petri nets include

elementary Petri net (Peterson, 1981), High Level

Petri Net (HLPN) (Reisig & Rozenberg, 1998),

Coloured Petri Net (Jensen, 1997), Stochastic Petri

Nets (Haas, 2002), Workflow Petri Net (Aalst and

Hee, 2002), Hierarchical Petri Nets, Timed Petri

Nets, Predict /Transition Nets, etc.

Definition: Petri nets are graphical and

mathematical modelling tool which is

particularly well suited for discrete event

systems. The Petri nets diagrammatic structure

consists of places, transitions and directed arcs,

as depicted in figure 3. Places can contain

tokens. Graphically, places are represented by

circles (or ellipses), transitions by rectangles (or

bars), and tokens by black dots (or numbers).

Figure 3: Graphical notations of Petri nets.

Transition – a transition represents an action,

process, operation, or any activity that changes the

state of the system or causes advances and progress

in a process.

Place – a place represents state, or any result

achieved after a specific activity (transition) takes

place. Places can contain tokens that illustrate the

current state of the modelled system (the marking).

The marking used to describe the initial state of the

system, is called the initial marking.

Arc – in its common role, an arc illustrates the

course of actions, the flow of processes, or the

sequence of operations.

Token – tokens are indicators of the system state.

Thus an overall distribution of tokens represents the

overall state of the system at a given time.

4 TRANSACTION ORIENTED

PETRI NET

By now it should be apparent that the transaction

concept lies in the core of our methodology and the

Petri nets notations are its main graphical elements.

Therefore the proposed methodology is entitled

Transaction Oriented Petri nets Methodology or

TOP Methodology for short.

In order to use Petri nets in systems analysis and

design for the purpose of information systems design

or IT application development, a few minor

extensions to the graphical notation of the ordinary

Petri nets is suggested in this paper. These

extensions make the models easily understandable,

intuitively readable and a straightforward input for

simulation modelling if analysis, verification or

comparison of different design alternatives is

needed.

As the legend, shown in figure 2, illustrates,

there are distinct graphical elements for action

(rectangle with plain line filled in grey), interaction

(rectangle with plain line), a complete transaction

where action and interaction are represented together

(rectangle with a bold line), and composite

transaction where a transaction is nesting one or

more transactions (multiple rectangles with a plain

line). In terms of the Petri net concept, all these

elements are transitions and thus represented by

different types of rectangle.

Further, the proposed extensions suggest two

places, start place and end place that indicate where

a process starts and where it eventually ends. These

two new places are used along with the standard

Petri net element called state that shows the

intermediate states of processes (transactions).

Again, in terms of the Petri net concept, all these

elements are places and thus represented by different

types of circle.

For distinguishing between intra-organizational

and inter-organizational processes, the process

boundary element is added. Introduction of this

element helps when analysts need to model or

illustrate the interaction of one process with other

processes within the organization or with the

environment. This interaction can be modelled with

a set of places on the process boundary.

In addition to standard Petri net arc, link, a

conditional link is also used to indicate a condition

(shown as dotted arc). The conditional link

represents a situation, when a transaction is not

always executed and its execution depends on

certain condition.

Place

Transition

Arc

Place with token

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

200

Figure 4: Legend of the TOP Methodology.

The advantage of the compact presentation,

where the three phases are compressed together, is

that the model becomes smaller and easier to

communicate between analysts, practitioners and

users. It can be applied to simple transactions, i.e.

when there are no transactions to be executed during

this transaction, or if there are any transactions, they

are considered as a black box.

Before proceeding further, readers should be

reminded that the structure illustrated in figure 2

represents a business transaction at a high level. Its

decomposition will lead to a workflow model having

one input and one output, that is, by virtue a

business transaction (meanly its E-phase)

encapsulates a workflow where flow of data,

documents, services or goods takes place. However,

due to limited scope of this paper, we will leave this

discussion for future research.

5 THE FRAMEWORK OF THE

TOP METHODOLOGY

For a successful system design or its model

construction, a practitioner needs to follow some

formal framework. The framework will help where

to seek for pieces of essential or business related

information. Since we are applying the TOP

Methodology, this methodology suggests that first

an organization is described in terms of major

business processes (patient examination, order

processing, customer call processing, inventory

control, etc.). Then each of these major business

processes is studied and described as a network of

business transactions (core activities), where each of

these transactions involve two actors, one initiator of

the activity and one executor of this activity.

According to the transaction concept underlying this

methodology, an activity is considered as a business

transaction if it creates a new fact, changes the status

of the system or brings results. Now having this in

mind, the following is a high-level framework to

follow:

1. Definition of major business processes

This is a high level definition of major processes

that can be done reading the documentation of the

organization. Examples of a major process can be

‘order processing’, ‘delivery’, ‘procurement’,

‘restocking’, etc.

2. Description of each major business process

This is either based on documentation of the

organization where processes and procedures are

described or such a description can be prepared

through interviews with the manger of the business

process.

3. Identification of business transactions (core

activities or key processes) and relevant actors

for each major business process

Identify transactions (main activities) that cause

changes in the states of the process and advance the

process; Identify who is initiator and who is

executor for each transaction.

4. Constructing a model(s) of each major

business process

In this part, using the notations of the TOP

methodology, all the identified transactions are put

together in a sequential order

6 APPLICATION OF THE TOP

METHODOLOGY

In order to illustrate the application of the TOP

Methodology, this section provides a case example

carried out in the department of university housing

planning to design a new information system to

support and improve the work of this office. For the

ease of reference, we will identify our case example

as the Room Assignment Process, or RAP for short.

6.1 The Housing Department

Currently the Department of University Housing (or

simply housing office) is serving about 4,000 on-

campus residents and managing hundreds of new

applications all the time. Using a paper-based

Start

Interaction

Action

Transaction

Composite

End

Link

Condition

Border

State

T1T1

BUSINESS PROCESS DESIGN BASED ON COMMUNICATION AND INTERACTION

201

system to fill 4,000 spaces is virtually out of the

question and would take weeks or even months to

complete not mentioning the possible number of

human errors. Therefore this department recently

acquired a new web based IT system, called RMS,

that helps to automate, simplify and improve the

room assignment process. Although there are still

some paper elements to the system, most of them

have been eliminated and improved, since it is no

longer necessary for people to have to individually

sift through housing applications and match

roommates.

The New Student Application Process

When a new student applies for housing, they

first visit the Housing web site and following the site

to the RMS home page. Here, they log in using their

school-assigned login account, automatically created

by the Housing department when the student has

been entered into the campus student database. Upon

logging in, they are prompted to create a profile first.

Most information, since it is extracted from WINGS

is already filled in on the form, and the student need

only verify their information and submit the form to

confirm their account in the system. From there, the

student can then continue to apply for housing.

After clicking the “apply” link on the RMS

homepage, the student is first prompted to choose

the term for which they are applying list their

preferences for the halls/communities in which they

do or do not wish to live. If so desired, the student

also has the opportunity to specify the ID numbers

of other students with which they specifically would

like to live. Each student who requests specific

roommates must also ensure that their potential

roommates have requested him or her as well. After

all this information has been filled out by the

applicant, they proceed to submit the application

data and complete the application. Since they are

currently not living on campus, the Department of

University Housing requires that they pay a $300

refundable security deposit toward their room. This

deposit confirms that a student does indeed wish to

live on-campus, and also serves as the security

deposit for their potential assignment. At this point,

the student is directed to a billing page on the

Housing site that either collects credit card

information or provides instructions about alternate

payment methods. Upon payment of the deposit, the

student has completed the application process. From

here, a student may log in to RMS at any time and

view their application and/or assignment status.

However, the student is not required to take any

further action until the assignments have been made

by the Housing department.

6.2 Business Transactions

According to the description, the room assignment

process starts from creating a student profile and

then by filling and submitting the form student

applies for a room. However, before clicking the

submission button, the student is prompted to

another transaction that requires for one month

deposit. So, the making deposit processes is nested

inside the applying for a room process. Otherwise

said, applying for a room transaction starts then the

making deposit transaction starts and completes

before completing the room application form. The

following are the three business transactions

involved in the process:

T1 – Creating a profile

Initiator – house office; Executor – student

Result – a new profile is created

T2 – Applying for a room

Initiator – student; Executor – house office

Result – an application is submitted

T3 – Making a deposit

Initiator – house office; Executor – student

Result – a deposit is made

Note: It should be noted that T3 (making

deposit) is nested inside T2 (applying for a room). It

means that T2 starts first and during its execution T3

is initiated and completed. The result of T2 is

condition for the completion of T3.

Now having all the transactions identified, we place

these transactions into the boundary of their

corresponding business process; the resulting model

is illustrated in figure 5.

Figure 5: Detailed business processes.

House Office

T1 T2/O

T2/E

T2/R

Environment

ICEIS 2006 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

202

The above figure illustrates main business

transactions of the room assignment process. As the

figure shows, the depositing process (T3) is initiated

from the room assignment process but executed in

the environment (outside of the boundary of this

process). The result of this transaction is

communicated back to the initiator. Actually, its

result completes the execution of T2. Therefore T2

is split into three phases to show that this transaction

is nesting transaction T3. However, transaction T1 is

a simple transaction, it is represented in compact

notation (all three phases are compressed into one).

It should be noted that figure 5 is a simplified

version of business process model of the room

assignment process. The reason for this

simplification is that inclusion of all details will

exceed the limit of the paper’s space and scope.

7 CONCLUSION

We have studied how by communicating people

mean acting, doing something or carrying out certain

tasks. The paper introduced a methodology that

combines the transaction concept and the Petri nets

notations for constructing business process models

for the purpose of IS design or IT application

development. The methodology can be used for a

wide range of related purposes such as to help

system designers in business process modelling,

business process engineering, requirements

engineering, information system design and IT

application development. Although for a complete

IS design or IT application development much more

data and details are needed, however the transactions

identified and the models constructed represent

essential information to understand the main

business processes of an organization.

Petri nets graphical notations provide a rich set

of elements for building models of systems and

processes, analyzing these models using simulation

software, and communicating the results with the

users. The resulting business processes model, as the

RAP example showed, is represented in a easily

readable fashion. It will not require any expertise or

technical skills to communicate such a model to

business owners or among system analysts.

REFERENCES

Aalst, W. van der, Hee, K. van. (2002). Workflow

Management: Models, Methods, and Systems, MIT

Austin, J. L. (1962) How to Do Things with Words,

Cambridge, Mass.: Harvard University Press.

Dietz, J.L.G. (1999). Understanding and modelling

business processes with DEMO. The Annual

International Conference on Conceptual Modelling

(ER’99), Paris, November.

Dietz, J.L.G. (2002). The Atoms, Molecules and Matter of

Organizations. The Seventh International Workshop

on the LAP, Delft, Netherlands, ISBN: 90-9015981-9.

Haas, P. (2002) Stochastic Petri Nets: Modelling,

Stability, Simulation. Springer-Verlag, New York.

Habermas, J. (1984). The Theory of Communicative

Action: Reason and Rationalization of Society. Polity

Press, Cambridge.

Jensen, K. (1997) Coloured Petri Nets. Basic Concepts,

Analysis Methods and Practical Use. Volume 1, Basic

Concepts. Monographs in Theoretical Computer

Science, Springer-Verlag, 2nd ed.

Peterson, J. L. (1981) Petri net theory and the modelling of

systems. Prentice-Hall, Inc., Englewood Cliffs, NJ.

Reisig, W. G. Rozenberg (Eds.) (1998) Lectures on Petri

Nets I: Basic Models., Advances in Petri Nets, Lecture

Notes in Computer Science, v. 1491, Springer-Verlag

Searle, J. (1969). Speech Acts: An Essay in the Philosophy

of Language. Cambridge University Press.

Winograd, T., Flores, F. (1986). Understanding Computers

and Cognition: A New Foundation for Design.

BUSINESS PROCESS DESIGN BASED ON COMMUNICATION AND INTERACTION

203