Understanding Modeling Requirements of

Unstructured Business Processes

Zaharah Allah Bukhsh

, Marten van Sinderen

, N. Sikkel (Klaas)

and Dick Quartel

University of Twente, Drienerlolaan 5, 7522 NB, Enschede, The Netherlands

BiZZdesign BV, Capitool 15, 7521 PL, Enschede, The Netherlands

Keywords:

Business Process Management, Case Management, Business Process Model and Notation, Case Management

Model and Notation, BPMN, CMMN, Unstructured Business Process, Flexibility.

Abstract:

Management of structured business processes is of interest to both academia and industry, where academia fo-

cuses on the development of methods and techniques while industry focuses on the development of supporting

tools. With the shift from routine to knowledge work, the relevance of management of Unstructured Busi-

ness Processes (UBP) is increasing. However, currently available modeling notations are not optimally suited

for modeling UBP. By means of a representative example, we investigate the limitations of Business Process

Model and Notation (BPMN) and Case Management Model and Notation (CMMN) in this respect. We de-

rive a set of requirements for representations that are needed for modeling UBP. These requirements allow to

express end-to-end business processes while providing ﬂexibility for run-time changes. We demonstrate these

requirements by a possible extension to BPMN.

1 INTRODUCTION

Business process modeling has been a very useful

notion for process management. A business pro-

cess model maps the end-to-end business operations,

thus provide the business process awareness, ﬁlter out

complexities, and enable estimation of resource uti-

lization (Bandara et al., 2005). Depending on the na-

ture of business process, the task of process modeling

can be very straightforward or very complex. A busi-

ness process is characterized by its involved partic-

ipants, resources and its interactions with computer

systems (Dumas et al., 2005). Various studies (Mc-

cready, 1992; Kemsley, 2011; W.M.P and Van Hee,

2004) have deﬁned the classiﬁcation of business pro-

cesses based on their level of structuredness. A busi-

ness process having an ordered set of planned activi-

ties, which are deﬁned at design-time, is said to be a

Structured Business Process (SBP). While, a business

process which depends on real-time events, available

data and knowledge of knowledge workers is referred

as an Unstructured Business Process (UBP).

In last few years, we observed an increased fo-

cus on UBP management by industry. According to

report by AIIM (Miles, 2014), for 51% of the compa-

nies polled, more than half of their business processes

are unstructured and unpredictable in nature. Compa-

nies adopt various methodologies (e.g. in-house col-

laborative systems, process management suites, etc.,)

to deal with the shift in focus from structured to un-

structured business processes. Traditionally, UBP are

dealt in a structured way (Dumas et al., 2010). For ex-

ample, a business process is modeled on design-time

using Business Process Model and Notation (BPMN)

while Business Process Management Suite (BPMS)

implements the designed business process. Such pro-

cess automation provides efﬁciency, however, it limits

the process engineer to predeﬁned activities and con-

ditional ﬂows.

Considering these limitations, some new and/or

modiﬁed process management paradigms and mod-

eling languages have been suggested that are specif-

ically targeted to provide the ﬂexibility for manage-

ment of UBP. Van der Aalst et al. (2005), proposed

case handling as a new paradigm to deal with UBP.

To support the dynamic nature of business processes,

a number of new modeling constructs were added

in the BPMN v2.0 release (OMG, 2011). More-

over, OMG recently proposed a new modeling lan-

guage called Case Management Model and Nota-

tion (CMMN) for modeling processes where the pro-

cess activities depend on real-time evolving circum-

stances (OMG, 2014). The availability of a number

of process modeling paradigms, with their advertised

Bukhsh, Z., Sinderen, M., (Klaas), N. and Quartel, D.

Understanding Modeling Requirements of Unstructured Business Processes.

DOI: 10.5220/0006398400170027

In Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 2: ICE-B, pages 17-27

ISBN: 978-989-758-257-8

vendor solutions, pushes companies to rethink their

tools that are used for process modeling. On one

hand, BPMN is usually preferred since it is widely

adopted and understood as an industry standard. On

the other hand, the new proposed modeling language

(i.e. CMMN) is attractive since it promises an in-

creased level of expressibility for modeling of evolv-

ing business processes. The current scientiﬁc litera-

ture on process modeling languages lacks a compari-

son and capability assessment of BPMN and CMMN

for UBP. However, a number of online discussions

1, 2

and a recently published study by Hinkelmann (2016)

suggest the integration of BPMN and CMMN for im-

proved process modeling beneﬁts.

This study intends to ﬁll the gap in the scien-

tiﬁc literature by assessing the modeling capabilities

of BPMN and CMMN with respect to UBP. More-

over, this study also assists companies, and speciﬁ-

cally their process engineers and process consultants,

in making a careful selection of the most suitable

modeling language for the process at hand by con-

sidering its modeling requirements. Therefore, num-

ber of representational requirements has been derived

from literature. We believe, a process modeling lan-

guage that is able to fulﬁll these representational re-

quirements can model the SBP and UBP, while keep-

ing their run-time ﬂexibility. The work presented in

this paper is a result of research efforts undertaken as

Master thesis at University of Twente (Allah Bukhsh,

2015).

The rest of the paper is structured as follows: char-

acteristics of UBP are provided in Section 2. To as-

sess the capabilities of modeling languages proposed

by OMG, a sample business process is modeled with

BPMN and CMMN in Section 3. Based on the results

of a capability assessment, a number of representa-

tional requirements for UBP are derived in Section 4.

The representational requirements are demonstrated

by means of an application scenario in Section 5. The

validation of representational requirements with three

experts from BiZZdesign is presented in Section 6.

Finally, Section 7 provides our conclusion.

2 CHARACTERISTICS OF UBP

It is argued that in SBP, the predeﬁned routing

rules drive the process while in UBP the character-

istic of the particular process instance drive the pro-

cess (van der Aalst and Berens, 2001). UBP requires

tacit knowledge, collaboration and decision making

https://www.linkedin.com/groups/1175137/1175137-

5868060474150502404

http://brsilver.com/bpmn-cmmn-compared/

skills from knowledge workers. The knowledge work

of an organization cannot be straight-jacketed into an

automated process and electronic forms due to its un-

structured and evolving nature (Van der Aalst et al.,

2005). Eshuis and Kumar (2016) suggested an ap-

proach to convert the UBP to SBP to be able to model

them with imperative modeling languages.

Many literature studies have discussed the char-

acteristic of UBP under the title of case manage-

ment (Di Ciccio et al., 2014; White, 2009; Mund-

brod et al., 2013; Kitson et al., 2012). Following are

some of the aspects of UBP which make them differ-

ent from SBP.

Goal Oriented: UBP are goal oriented, which

means a process evolves through a series of sub-

goals and milestones (Di Ciccio et al., 2014). The

achievement of each goal depends on a number of

factors, e.g. availability of required data, execu-

tion of activities, decisions of knowledge workers,

and responses from customers. Every sub-goal of

a process is well-integrated with one ﬁnal goal.

An achieved sub-goal can be modiﬁed or proven

wrong as more data and knowledge emerges as the

process progresses (Mundbrod et al., 2013).

Data Dependent: UBP are data dependent which

means process and data are strictly inte-

grated (Chiao et al., 2013). The modiﬁcation, ad-

dition or deletion of process data deﬁnes the fu-

ture activities of the process. However, the un-

availability of particular data may halt the pro-

cessing of the whole process.

Coordination and Collaboration: Execution of

UBP highly relies on the coordination and col-

laboration among the knowledge workers (Mund-

brod et al., 2013). Usually, a single process

involves many knowledge workers (Di Ciccio

et al., 2014). As the process progresses, new

knowledge workers may get involved or existing

knowledge workers may leave their roles.

Business Rule Driven: Conformance to business

rules and standards is one the most convincing ar-

guments to automate a business process. How-

ever, due to the uncertain and emergent nature of

UBP, knowledge workers are required to maintain

the business rules and standards during process

execution. All the process activities are inﬂuenced

by particular rules and policies of business (Di Ci-

ccio et al., 2014).

ICE-B 2017 - 14th International Conference on e-Business

3 ASSESSMENT OF BPMN AND

CMMN FOR MODELING UBP

BPMN and CMMN have been modiﬁed and intro-

duced, respectively, to deal with UBP (Unstructured

Business Process). We use an application scenario of

an admission process to investigate and compare the

capabilities of these notations to model an UBP.

3.1 Application Scenario

The admission process is a knowledge intensive pro-

cess which involves collaboration and communication

among different departments to perform the smooth

intake of students. Following is the detailed descrip-

tion of the admission process.

With the announcement of admission, the stu-

dents can send their documents to the univer-

sity through an online form. Students are re-

quired to submit their personal information

with their academic certiﬁcates, motivation

letter and language certiﬁcate. Once the ad-

mission application is submitted by the stu-

dent, the admission ofﬁce is notiﬁed. Based

on documents received, each admission ﬁle

might go through at number of assessments

before the ﬁnal decision can be made. Ini-

tially, the admission administrator checks

the application for its correctness and com-

pleteness. The admission ﬁle is then for-

warded to the corresponding department of

university for assessment. The admission co-

ordinator will review the admission ﬁle to

check the attached academic certiﬁcates. The

ﬁnal decision can be made by the admission

coordinator only or it can require the discus-

sion and decision from the admission panel.

During the decision process, the provided de-

tails can be veriﬁed and new documents can

be requested from the student. At the end,

a student can be admitted, rejected or con-

ditionally admitted. The involved knowledge

workers and the decision highly depend on the

particular admission ﬁle. Finally, the student

is informed about the decision based on his

admission ﬁle.

In this scenario description, verbs in italic letters

show the activities of the admission process while

nouns in bold letters represent the involved knowl-

edge workers.

3.2 Modeling UBP with BPMN

As discussed earlier, BPMN is one of the widely

adopted process modeling notations due to its ease of

use and expressibility. A BPMN process model pro-

vides a layout of the business process by modeling

the set of ordered activities, events, and process ﬂow

logic (Dumas et al., 2010). BPMN is often regarded

as the modeling notation of choice for SBP (Rosen-

feld, 2011). Figure 1 shows the admission process

modeled using BPMN modeling constructs.

Following are some problems of modeling

an UBP with procedural modeling language like

BPMN (Rychkova and Nurcan, 2011).

Task Ordering: Procedural modeling languages like

BPMN introduce the ordering and task dependency in

process executions. For example, in Figure 1, the task

ordering implies that the activity ‘Send certiﬁcate for

authentication’ will be only performed after the task

‘Review admission form’ has been completed. While,

in reality, the veriﬁcation of certiﬁcates and review of

admission form can be performed in parallel.

Unavailable Optional Tasks: In BPMN, the ex-

ecution of tasks can be skipped only by employing

conditions on an exclusive gateway. However, tasks

that are deﬁned with a sequential ﬂow on the pro-

cess model without any conditions cannot be skipped.

Even if the tasks are not required by the particular

process instance, the tasks are needed to be executed

to continue the process ﬂow. For example, the activ-

ity ‘Send certiﬁcates for authentication’, in Figure 1,

should be regarded as an optional activity if the au-

thentication is not needed.

Limited View on Data: BPMN provides a very

limited view on data. Business processes like the ad-

mission process are data-intensive in nature; the pro-

vided data can deﬁne the ﬂow of activities. With

BPMN, the data input and output ﬂow can be de-

picted, but the changing state of data can not be de-

ﬁned.

Some of the problems that are highlighted with

BPMN can be mitigated by using the extended BPMN

elements (OMG, 2011, p. 30). The concept of ad-

hoc subprocess has been found to be most useful for

modeling an UBP. An ad-hoc sub-process does not

specify the ordering among activities. The activities

in an ad-hoc sub-process can be executed any number

of times without any pre-deﬁned ordering. Based on

process instance requirements, the activities of ad-hoc

sub-processes can be done, redone or even skipped.

However, according to the BPMN version 2.0 stan-

dard speciﬁcation (OMG, 2011), many process en-

gines don’t provide support for ad-hoc sub-process

execution. Moreover, use of extended BPMN ele-

Understanding Modeling Requirements of Unstructured Business Processes

Figure 1: Process Model of Admission Process Using BPMN.

ments results into a very complex process model. The

activities deﬁned inside the ad-hoc sub-process can-

not be labeled to indicate whether activities are op-

tional, required or re-executable. The use of vari-

ous events and sub-processes can negatively inﬂuence

the understandability and readability of the process

model.

3.3 Modeling UBP with CMMN

CMMN is for modeling the case/process where the

activities are not strictly deﬁned, but dependent on

evolving circumstances and decisions of knowledge

workers (OMG, 2014). As compared to BPMN,

CMMN is a relatively new process modeling lan-

guage with unique constructs. Modeling construct of

CMMN, which are exploited in Figure 2 for admis-

sion process model, are the following:

A rectangle shape with the title of ‘Admission Pro-

cess’ is called case folder, while the title depicts the

name of the case/process. A case folder is a con-

tainer that consists of all CMMN elements to model

the process. A rectangular shape with angled cor-

ners shows the episodes of a process which are called

stages. ‘Check Admission File’, ‘Assess Admission

File’ and ‘Decision on Admission File’ are stages of

the admission process. Shapes with half-rounded cor-

ners are called milestones; they represent the goals

to be achieved in a process. ‘Completed Admission

File’ and ‘Final Decision Submitted’ are milestones

that are required to be achieved in processing of the

admission ﬁle. Finally, diamond shapes in the model

are called as sentries; they deﬁne the entry and exit

criteria for tasks and stages.

Following are problems that were encountered

while modeling an UBP with CMMN.

Predeﬁne Users: CMMN doesn’t have any nota-

tion to represent the assigned user roles. According

to CMMN speciﬁcation OMG (2014), the user roles

are deﬁned semantically when the case/process is ini-

tiated.

Limited View on Data: CMMN is meant to

model those processes that evolve with time and

where the execution of a process is mainly based on

data and knowledge workers’ decisions. CMMN has

a concept of case ﬁle along with ﬁle versioning. How-

ever, the versioning of a case ﬁle is deﬁned semanti-

cally. From a visualization perspective, CMMN pro-

vides a very limited view on data.

Task Dependency: Connectors and sentries rep-

resent the concept of task dependency in CMMN. The

tasks will be executed only if the entry/exit condition,

associated with it, is fulﬁlled. However, as compared

to BPMN, the combination of connector and sentries

provides poor readability. For example, in Figure 2,

the stage of Assess Admission File will only be exe-

cuted if the milestone Application Check Completed

has been achieved.

Unlike BPMN, CMMN is a declarative language.

It is used to specify what should be done in the pro-

cess instead of how it should be done. The purpose

of a CMMN model is to provide a guidance map

which instructs the process engineers on what can

be done for successful process execution. Instead of

design-time deﬁned conditional ﬂows, the evolving

data and knowledge of knowledge workers drive the

process execution. Consequently, BPMN is more ex-

pressive in its process ﬂows as compared to CMMN.

On the other hand, the discretionary tasks and stages

of CMMN provide a better understanding of which

tasks can be skipped during process execution as com-

pared to ad-hoc sub-processes of BPMN. A detailed

ICE-B 2017 - 14th International Conference on e-Business

Figure 2: Case Model of Admission Process Using CMMN.

comparison of BPMN and CMMN notations is pro-

vided in (Allah Bukhsh, 2015, section 4.4).

4 REPRESENTATIONAL

REQUIREMENTS OF UBP

In this section, representational requirements of UBP

are presented. These requirements will facilitate us

into modeling the UBP in a ﬂexible manner. The

proposed requirements are based on the limitations of

BPMN and CMMN discussed in Section 3. Cardoso

et al. (2016) also comparatively evaluated the BPMN

with another modeling language and concluded that,

despite its popularity, BPMN is limited in its ability

to model UBS. Therefore, representational require-

ments for modeling UBS are suggested in this study.

Some literature studies (Hauder et al., 2014; Di Ci-

ccio et al., 2014; Chiao et al., 2013) have proposed

the requirements for the development of an adaptive

process management system, which support ﬂexibil-

ity in management of a knowledge-intensive process.

While, the representational requirements presented in

this section are mainly focused on process modeling.

To deﬁne requirements concretely, we adopted the

convention from (Chiao et al., 2013), where each re-

quirement is explained with the help of an application

example.

4.1 Process Speciﬁcation Requirements

Each process has some general requirements that need

to be fulﬁlled to represent the real-world scenarios.

Support to Capture Real-time Events: It should

be possible for UBP to capture and respond to real-

time events. These real-time events can be related to

process start or end, arrival of data, modiﬁcation of

existing data, or they can be triggered by user activity.

When an applicant submits his admission ap-

plication, the admission ofﬁce is notiﬁed. The

notify event can be a start event to initiate the

admission process.

Support to Quantify and/or Qualify the Condi-

tions: On certain steps in processing of an UBP, the

decision to execute next process activities is taken. It

should be possible to represent the conditional ﬂow

on process model.

A complete check in admission process is an

example of quantifying condition.

4.2 Activities Speciﬁcation

Requirements

Activities deﬁne the work that is expected to be

performed for successful execution of a process.

The requirements of activities speciﬁcation from the

perspective of an UBP are discussed below.

Support for Ordered and Unordered Activi-

ties: A business process consists of structured and

unstructured parts of the process. It should be pos-

sible to deﬁne and follow the control ﬂow among the

activities as well as skip the activities’ execution, if

needed.

Understanding Modeling Requirements of Unstructured Business Processes

Ordered Activities: The steps like submission

of admission ﬁle by student and notifying it to

admission ofﬁce are ordered set of activities.

These process activities are required to be ex-

ecuted one after another.

Unordered Activities: An assessment activity

which consist of check on academic certiﬁ-

cates, analysis of their authenticity and review

of other related documents are example of un-

ordered process activities.

Support for Required and Optional Activities:

Due to non-deterministic and emergent nature of

UBP, it should be possible to deﬁne the process ac-

tivities as optional or required.

Required Activities: Irrespective of type of

admission ﬁle, it is required to inform the stu-

dent about the status of his application.

Optional Activities: During the assessment

activity, the activity of certiﬁcates authenti-

cation can be treated as an optional activity

based on admission application.

Support for Re-execution and Undo Activities:

An UBP mainly relies on decisions made by knowl-

edge workers. Such decisions may lead to undo or

re-execute the previously performed activities.

Re-execution of Activities: An admission ap-

plication from the recognized national uni-

versity might require single review while the

international admission application might go

through a number of reviews.

Undo Activities: For example, a request to de-

fer the admission for a speciﬁc time can lead

to undo certain activities that had marked the

student as an upcoming admitted student.

Support for Collaboration among Activities:

In addition to parallel execution of activities, it should

be possible to deﬁne and depict the collaboration

among the individual process activities. BPMN de-

picts the collaboration between the external and inter-

nal process through message passing but not with-in

a process.

The activities of discussion and decision re-

quire collaboration and can further leads

to veriﬁcation of the admission application.

Therefore, the collaboration activities should

be explicit.

Support for Varying Levels of Granularity: A

process model with low level of granularity provides

the ﬂexibility for knowledge workers in process exe-

cution while a process with high level of granularity

limits the knowledge workers’ freedom.

Assessment and veriﬁcation are examples of

those activities that be modeled with varying

level of granularity.

Support for Process and Data Alignment: Un-

like traditional business process, where data are lim-

ited to deﬁning control ﬂows, UBP have an abundance

of data with changing states. With process and data

alignment, it should be possible to trace back data

through a process and vice versa.

Almost each activity of admission process

have associated data e.g. admission docu-

ments, remarks, decisions, etc.

Support for Process/Activity Call: It should be

possible to model the already available process or ac-

tivity. The callable aspect will reduce the burden of

re-modeling/re-doing the same activity.

In case the applicant, who had applied for ad-

mission, also submitted his application for a

scholarship. With activity/process call, the re-

sults of the authentication activities can be re-

used from admission process.

4.3 Data Speciﬁcation Requirements

UBP are fundamentally data-centric, which means

that the process and data are strictly bounded (Marin

et al., 2013; Van der Aalst et al., 2005). The execu-

tion of process highly relies on available and evolving

process data.

Support for Data Representation: UBP pro-

duce and consume data during execution. It should

be possible to clearly deﬁne the inﬂow and outﬂow of

data ﬁles for a particular process activity.

ICE-B 2017 - 14th International Conference on e-Business

In the assessment activity, the admission ap-

plication can be represented as an input data

ﬁle while remarks as an output data ﬁle.

Support for Data Authorization: With the in-

volvement of number of knowledge workers in UBP,

it is should be possible to deﬁne the access level of

data.

The admission application should not be ac-

cessible to the admission coordinator and ad-

mission panel before it is veriﬁed by admis-

sion administrator.

Support for Version Control of Data: Due to

evolving nature of data, the version control of data

is important. The concept of versioning for UBP is

introduced by OMG in CMMN version 1.0 OMG

(2014). Data versioning can be modelled as data

states on a process model.

The remarks and the decision on the admis-

sion ﬁle have evolving nature which can be

revised, added or deleted.

4.4 Business Rules Speciﬁcation

Requirements

To conform to standards and business policies, busi-

ness rules need to be employed during process execu-

tion. These rules provide information on how certain

business processes should be performed and how the

resources can be used Penker and Eriksson (2000).

The alignment of process with business rules will an-

swer the questions about ‘how and why certain ac-

tivities were performed and speciﬁc decisions were

made’.

The admission deadline deﬁned by an insti-

tute is one example of business rule, which is

related to admission process.

4.5 Process Goals Speciﬁcation

Requirements

Goal-orientedness is one of the most distinguishing

characteristics of UBP. Based on the main goal, a

process evolves into a number of sub-goals and mile-

stones as process progresses. To provide an overview

of process, it should be possible to model goals and

sub-goals.

The main goal of admission process is ﬁ-

nal verdict of acceptance or rejection of ad-

mission application, while the other goals

can be ‘application received’, ‘application re-

viewed’, and ‘application veriﬁed’.

4.6 Knowledge Workers’ Speciﬁcation

Requirements

Knowledge workers play a critical role in manag-

ing and solving UBP. Knowledge workers, primary

job is to create, distribute and apply their tacit and

explicit knowledge to comprehend process, analyze

related information and make decisions Grudzi

nska-

Kuna (2013).

Support for Knowledge Workers’ Roles As-

signment: Due to involvement of many knowledge

workers in process management, it should be possible

to deﬁne the roles of each knowledge workers along

with their assigned tasks.

Admission administrator, admission coor-

dinator, and admission decision panel are

knowledge workers of the admission process

with their assigned set of tasks.

Support to Capture Knowledge Workers Deci-

sions: One of the most important tasks of knowledge

workers is to utilize their tacit knowledge, available

data and process context to take the certain decisions.

The decisions made by knowledge workers affect the

process running time, its control ﬂow, ﬁnal outcome

and many other process related aspects. It should

be possible to capture every decision of knowledge

workers.

The admission administrator needs to make a

decision about the completeness of the admis-

sion application before forwarding it to ad-

mission coordinator.

5 DEMONSTRATION OF

REPRESENTATIONAL

REQUIREMENTS

To demonstrate the proposed representational require-

ments, a few extended modeling constructs based

on BPMN are suggested in Table 1. The reason

to demonstrate representational requirements with

Understanding Modeling Requirements of Unstructured Business Processes

Table 1: Extended Modeling Constructs of BPMN (Demonstration).

No Name Notations Semantics

1 Collaborative Sub-process

Collaborative sub-process represents collaboration

among different activities of the process

2 Decision Activity

Decision activity shows a decision taken during

the course of process execution

3 Optional Activity

Optional activity deﬁnes an activity that can be

skipped during the process execution considering

the process context

4 Required Activity

Required activity deﬁnes a process activity that

must be executed

5 Undo Activity

Undo activity represents an activity that can be

undone considering the particular process context

6 Goal Goal represents the purpose of the process.

7 User Role

User role represents a person or a class of people

who are assigned to perform the process execution

8 Business Rule

Business rule represents a related business rule on

the process model

BPMN is two fold: First, as compared to CMMN,

BPMN is widely known and adopted by process en-

gineers. Second, many available modeling constructs

provided by BPMN are able to fulﬁll a number of rep-

resentational requirements.

Using BPMN and the extended modeling con-

struct, an admission process is modeled in Figure 3.

The description of each construct is provided as added

comments in Figure 3 and with Table 1. All the activ-

ities without incoming and outgoing sequential ﬂow

are unordered, while the sequential ﬂow deﬁne the or-

der between activities. Moreover, a sub-process can

be attached to the conditional ﬂow to reach to the

goal. For instance, the goal Application veriﬁed can

be only be reach if the condition veriﬁcation com-

pleted is met. Data objects with their changing states

are also represented in the process model. The po-

sition of data objects in the process model shows the

data access levels for the involved performers. For ex-

ample, the data object applicant ﬁle with created and

verifying state is only accessible by admission admin-

istrator while the applicant ﬁle with veriﬁed state can

be accessed by all the involved performers.

As compared to the admission process model pre-

sented in Figure 1 and 2, the admission model

that fulﬁlls the representational requirements offers a

number of advantages.

Expressive Process Model: As compared to

CMMN, the process model provided in Figure 3 has

a well-deﬁned process start and end event. More-

over, the modeling constructs to show the required,

optional, decision and collaborative tasks makes the

process model easy to read and communicate.

Ability to Model (un) Structured Process: The

process model shown in Figure 3 represents the struc-

tured and unstructured process parts. Sequential ﬂow

represents the task ordering and task dependency be-

tween tasks which is a must requirement to model

structured process. CMMN doesn’t have the concept

of sequential ﬂow while in BPMN the use of the se-

quential ﬂow inside the ad-hoc sub-process yields a

semantically incorrect process model.

Ability to Model User Roles: With the user role

notation, a person or group or department can be set

as responsible to perform certain activities. CMMN

and BPMN don’t have any notation to deﬁne the user

roles on the process model. However, in BPMN lanes

are used for this purpose.

Ability to Model Data Access Level: The data

access level is deﬁned based on data object position

on the process model. A data object that is deﬁned

inside the sub-process belongs to the assigned user

only, while, the data object outside any sub-process is

accessible by all the involved users of a process.

Ability to Model related Business Rules: With

BPMN and CMMN, it is feasible to represent busi-

ICE-B 2017 - 14th International Conference on e-Business

Figure 3: Process Model of Admission Process.

ness rule related activities either by a business rule

task or planning table. However, in order to show the

effect of business rules on process control ﬂow, an ex-

tended modeling construct is used in Figure 3.

Ability to Model Collaborative Activities: The

process model provided in Figure 3 shows the col-

laboration among the activities. The collaboration

among activities presents that the activities are depen-

dent on each other for their execution.

6 VALIDATION

The validation of proposed representational require-

ments and their demonstration with extended BPMN

constructs were performed with three experienced

practitioners of BiZZdesign. Each of these practition-

ers has considerable working experience with BPMN

process modeling language. Semi-structured qualita-

tive interviews were conducted with each participants

in separate sessions that lasted from 60 to 90 minutes.

The suggested representational requirements and

their demonstration with BPMN extended constructs

were mainly validated for their usefulness, ease of un-

derstanding and correctness. The result of validations

is provided as follows:

Usefulness: The concepts of required, optional, col-

laborative sub-process, goal and decision activity

are regarded as very useful for modeling unstruc-

tured business processes. However, the concept

business rule is termed as unnecessary because

business rules are often extensive and are difﬁ-

cult to be included in process model. Apart from

business rules, the respondents found the concepts

of data speciﬁcation very powerful. According to

one of the responded, the demonstration of data

speciﬁcation in Figure 3 is very intuitive as com-

pared to technical speciﬁcation of BPMN.

Ease of Understanding: The suggested representa-

tional requirements are easy to understand and

yields ﬂexibility for modeling UBS. However, the

demonstration of representational requirements in

Figure 3 is indicated difﬁcult to read when com-

pared to BPMN process model (see Figure 1) and

easy to read when compared to CMMN process

model (Figure 2).

Correctness Some of the comments regarding simi-

larities of BPMN with suggested concepts as re-

quirements were highlighted. According to one

of the respondent, the concept of optional task

can be achieved by employing BPMN gateway.

While, he also acknowledges the involved com-

Understanding Modeling Requirements of Unstructured Business Processes

plexity of modeling optional task with gateway

(requiring three constructs) as compared to using

simple optional task. Moreover, the concept of

undo and compensation event of BPMN is found

to be similar. Another respondent suggested to

keep one concept between required and optional

as if some task is not required then it would be

optional. However, other responded ﬁnd the sepa-

rate concepts of required and optional very useful

as it will bring clarity to the process model.

On overall, it is found that representational require-

ments and a set of extended BPMN constructs are able

to model USB without incorporating unnecessary de-

tails and complexity while representing the needed

run-time ﬂexibility.

7 CONCLUSION

UBP are goal-oriented, data dependent, emergent,

and require coordination and collaboration among

stakeholders. Taking the unique nature of UBP

into consideration, a number of modeling limita-

tions of BPMN and CMMN are identiﬁed, for in-

stance, BPMN introduce task dependency in process

execution whereas CMMN is unable to model user

roles/task assignments in process modeling. Though,

BPMN provides a number of useful constructs (e.g.

ad-hoc sub-processes, re-execute task) for modeling

unstructured business processes. But, use of vari-

ous modeling constructs results into a very complex

process model, which is difﬁcult to communicate to

business people along with its semantic content. On

the other hand, the expressibility of CMMN model-

ing constructs is found to be insufﬁcient for process

modeling.

Our contribution in this paper is to derive explicit

requirements for notions that should be represented

in a modeling language for UBP. We have shown how

this could be done by deﬁning an extension to BPMN

that covers these requirements. We do not claim that

this extension is the only or the best notations pos-

sible, but it does show that more adequate modeling

notations for UBP are feasible.

The future work of this study seeks to explore and

demonstrate the suggested representational require-

ments with other imperative and declarative modeling

languages. Considering the fact that a structured busi-

ness process often consists of unstructured activities

and vice versa, there is a need for a comprehensive

modeling language that is able to fulﬁll the modeling

requirements of structured and unstructured business

processes without introducing unnecessary complex-

ity in process models.

REFERENCES

Allah Bukhsh, Z. (2015). BPMN Plus : a mod-

elling language for unstructured business processes.

Master Thesis, University of Twente, Available at:

http://essay.utwente.nl/67945/.

Bandara, W., G. G., G., and M, R. (2005). Factors and Mea-

sures of Business Process Modelling: model building

through a multiple case study. European Journal of

Information Systems, 14(4):347–360.

Cardoso, E., Labunets, K., Dalpiaz, F., Mylopoulos, J., and

Giorgini, P. (2016). Modeling structured and unstruc-

tured processes: An empirical evaluation. In Con-

ceptual Modeling: 35th International Conference, ER

2016, Gifu, Japan, November 14-17, 2016, Proceed-

ings 35, pages 347–361. Springer.

Chiao, C. M., K

unzle, V., and Reichert, M. (2013). Enhanc-

ing the Case Handling Paradigm to Support Object-

aware Processes. In Proceedings of the 3rd Inter-

national Symposium on Data-Driven Process Discov-

ery and Analysis (SIMPDA13). CEUR Workshop Pro-

ceedings, CEUR-WS.org.

Di Ciccio, C., Marrella, A., and Russo, A. (2014).

Knowledge-intensive processes: Characteristics, re-

quirements and analysis of contemporary approaches.

Journal on Data Semantics, pages 1–29.

Dumas, M., Garc

ıa-Ba

nuelos, L., and Polyvyanyy, A.

(2010). Unraveling Unstructured Process Models.

In Business Process Modeling Notation, pages 1–7.

Springer.

Dumas, M., Van der Aalst, W. M., and Ter Hofstede, A. H.

(2005). Process-aware Information Systems: Bridg-

ing People and Software through Process Technology.

John Wiley & Sons.

Eshuis, R. and Kumar, A. (2016). Converting unstructured

into semi-structured process models. Data & Knowl-

edge Engineering, 101:43–61.

Grudzi

nska-Kuna, A. (2013). Supporting Knowledge

Workers: Case Manangement Model and Notation

(CMMN). Information Systems in Management,

2(1):3–11.

Hauder, M., Munch, D., Michel, F., Utz, A., and Matthes,

F. (2014). Examining adaptive case management

to support processes for enterprise architecture man-

agement. In Enterprise Distributed Object Com-

puting Conference Workshops and Demonstrations

(EDOCW), 2014 IEEE 18th International, pages 23–

32. IEEE.

Hinkelmann, K. (2016). Business process ﬂexibility

and decision-aware modelingthe knowledge work de-

signer. In Domain-Speciﬁc Conceptual Modeling,

pages 397–414. Springer.

Kemsley, S. (2011). The Changing Nature of Work: From

Structured to Unstructured, from Controlled to Social.

In Business Process Management.

Kitson, N., Ravisanskar, R., and Soudamini, R. N.

(2012). Case Management - Managing chaos: un-

structured processes and dynamic BPM. Avail-

abe at: www.capgemini.com/bpm-trends, Capgemini

Whitepaper.

ICE-B 2017 - 14th International Conference on e-Business

Marin, M., Hull, R., and Vacul

ın, R. (2013). Data centric

bpm and the emerging case management standard: A

short survey. In Business Process Management Work-

shops, pages 24–30. Springer.

Mccready, S. (1992). There is more Than One Kind of

Workﬂow Software. Computerworld - COWO .

Miles, D. (2014). Case Management and Smart Process

Applications. Technical report, Association for Infor-

mation and Image Management(AIIM).

Mundbrod, N., Kolb, J., and Reichert, M. (2013). Towards

a system support of collaborative knowledge work. In

Business Process Management Workshops, pages 31–

42. Springer.

OMG, T. (2011). Business Process and Model Notation.

Available at: http://www. omg. org/spec/BPMN/2.0.

OMG, T. (2014). Case Management Model and Notation

(CMMN). Available at: www.omg.org/spec/CMMN/.

Penker, M. and Eriksson, H.-E. (2000). Business Modeling

with UML: Business Patterns at Work. John Wiluv &

Sum 220 M. Godowski and D. Czyrnek/Requirement

Management in Practice.

Rosenfeld, A. (Sept. 2011). BPM: Structured vs. Unstruc-

tured. BPTrends. Available at: http://bit.ly/1I6Ev3W.

Rychkova, I. and Nurcan, S. (2011). The Old Therapy

for the New Problem: Declarative Conﬁgurable Pro-

cess Speciﬁcations for the Adaptive Case Manage-

ment Support. In Business Process Management

Workshops, pages 420–432. Springer.

Van der Aalst, W., Weske, M., and Gr

unbauer, D. (2005).

Case Handling: a new paradigm for business process

support. Data & Knowledge Engineering, 53(2):129–

162.

van der Aalst, W. M. and Berens, P. (2001). Beyond

Workﬂow Management: Product-driven Case Han-

dling. In Proceedings of the 2001 International ACM

SIGGROUP Conference on Supporting Group Work,

pages 42–51. ACM.

White, M. (2009). Case management: Combining knowl-

edge with process. BPTrends, July.

W.M.P, V. d. A. and Van Hee, K. M. (2004). Workﬂow man-

agement: models, methods, and systems. The MIT

Press.

Understanding Modeling Requirements of Unstructured Business Processes