Project topics and materials
Get Complete Project Material File(s) Now! »
Chapter 2 Background
This chapter introduces the key concepts and basic terminology used in Business Process Management (BPM), business process modeling, and case management that were relevant to the development of this thesis.
This chapter is organized as follows. Section 2.1 provides an introduction to BPM. Section 2.2 introduces process modeling and its different aspects, including model types, focus, and the role of process metrics. This section also provides background material that will be referred to in Chapter 6. Section 2.3 provides an introduction to case management and offers background material that will be used in Section 3.3. Section 2.4 describes the evolution of Business Artifact (BA)s and their influence on the Case Management Model and Notation (CMMN) [OMG14a] specification, and also provides background material for Chapter 3. Please note that some of the material that appears in Section 2.3 was previously published in Marin et al. [Mar+15a], and that Section 2.4 expands on material that was previously published in Marin et al. [Mar+13]. The examples referred to in Section 2.2.1 were also previously published in Marin et al. [Mar+14b].
Business Process Management
Organizations are more likely to achieve their business goals when employees, Information Technology (IT) systems and other enterprise resources are well integrated. BPM plays an important role in facilitating this integration [Wes12]. Many organizations adopt BPM in order to improve their operations and to better serve their customers [MM15]. This adoption of BPM technology has created a vibrant software and consultancy market [Pit15]. Today most activities that an organization performs are supported by information systems, and BPM helps to organize these activities [Wes12]. This has led to a very healthy and satu-rated BPM software market that, as described by Fleming and Silverstein [FS15], grew at 8.2% in 2014 to an estimated 3.2 billion US dollars. BPM provides the “concepts, methods, and techniques to support the design, administration, configuration, enactment, and analy-sis of business processes” [Wes12]. It combines computer science and management science with both communities showing increased interest in the topic [van13; Wes12]. BPM has evolved into an interdisciplinary field that combines methods from business administration, organizational theory, computer science, and information systems [Pit15] and is motivated by real applications [Rei+10a]. However, the interdisciplinary mix of methodologies and approaches in BPM can lead to confusion [Rei+10a]. The scope and definition of BPM is often still confused with Business Process Re-engineering (BPR), and Workflow Management (WfM) [Ko09]. According to de Bruin and Doebeli [dD10], the lack of clarity around BPM is attributable to at least three interpretations of the term which include:
1. BPM as a technology for process management. This interpretation views BPM as a set of software tools that automate and manage processes.
2. BPM as an approach to manage the life cycle of processes. This interpretation views BPM as managing the process life cycle. This view combines the technological view with the management of that technology.
3. BPM as an organizational process. This interpretation perceives BPM as a management discipline that uses a process centric view. Therefore, this interpretation does not view BPM from a technological perspective.
This thesis focuses on BPM from a technological perspective. This perspective views BPM as an extension of WfM systems. Traditionally, both of these technologies (i.e., WfM and BPM) were based on Petri Net token semantics [van15].
BPM technology automates business processes by organizing the IT assets in the order required to achieve a desired business outcome. Business processes refer to how organizations deliver products and services to their customers, with organizations trying to outperform each other by improving their business processes and executing them better [Dum+13]. Therefore, business processes are central to BPM [Pit15], and are important to understand if one wants to know how the organization operates [Wes12]. Furthermore, these processes are important because they have an influence on the organization’s IT systems [Wes12]. This thesis uses Weske’s [Wes12] definition of process, which describes a business process as a set of coordinated activities that realize a business goal and are performed by an organization using a technical environment. A process is sometimes referred to as a workflow.
Process Lifecycle
Business processes or workflows are IT assets and therefore have a life cycle. BPM literature describes multiple versions of a business process life cycle [de +14], as can be evidenced in work done by Bouneffa and Ahmad [BA14], di Ciccio et al. [di +14], Dumas et al. [Dum+13], Schulte et al. [Sch+15], and Weske [Wes12]. This thesis uses Mendling’s [Men08] apud [zur04] version illustrated in Figure 2.1. This version’s life cycle views BPM as technology and describes the outputs of each phase, including the process model which is the focus of this thesis. The life cycle in Figure 2.1 consists of six phases:
Analysis. This phase focuses on project goals, and the organizational structures in the environment of the business process [zur04]. The business process and its requirements are identified in this phase. The requirements for the business process constitute the output of this phase.
Design. In this phase the process is engineered and includes the identification and definition of activities and the ordering needed to implement the requirements that were identified in the previous phase, which will achieve the business goal [Men08; zur04]. Business process modeling and validation techniques, including simulation and verification, are used in this phase [Wes12]. The output of this phase is a process model.
Implementation. During this phase, the necessary infrastructure required to support the business process, including the Business Process Management System (BPMS), is configured [zur04]. The implementation includes the integration of the business process with other information systems and employee training [Wes12]. The output of this phase is the infrastructure required to support the business process.
Enactment. In this phase the BPMS is able to create process instances and to execute them according to the process model that is being enacted [Wes12]. Resources needed by the process are allocated and participants in the process are presented with activities that they must complete [zur04]. The output of enactment is a set of instance data, normally stored in log files or database tables.
Monitoring. Two aspects are measured during monitoring. From the information system’s perspective the operations and performance of the BPMS are measured, and from the organization’s perspective process measurements are taken [zur04]. Visual monitor-ing tools are normally used to present the state of process instances [Wes12]. This monitoring phase normally occurs simultaneously with the enactment phase.
Evaluation. The information gathered during the enactment and monitoring phases is used for resource planning and to generate new requirements for the business process. Audit trails from the BPMS and measurements from the monitoring tools are used for staffing and resource planning, as well as to identify adjustments to the process [zur04].
This thesis focuses on process models that correspond with the output of the design phase.
Business Process Modeling
The activity of documenting and organizing the IT assets and the corresponding user inter-actions is called business process modeling or process modeling. Organizations make use of business process modeling to describe the business processes that are to be automated by describing the activities that need to be performed in order to achieve a business goal. Process modeling is an important activity in a successful BPM project [Fle+14]. A business process model, also referred to as a process model, is normally described in a visual manner and represents the way that business representatives conduct the operation of a business [BR05].
A process model visualizes the main activities of a process including the actors and systems involved in performing those activities [Rei+10b]. Modeling is a symbolic representation of a specific part of reality [Hen12]. Guizzardi [Gui05] defined the term “conceptualization” as the set of concepts used to describe the abstractions of a domain. A cognitive model refers to a particular situation abstracted using a conceptualization. These two concepts (i.e., conceptualization and cognitive model) reside in the mind of a person or a community of persons [Gui05]. A concrete artifact is required to communicate and document a cognitive model and this artifact is referred to as a model [Gui05]. To create a model a modeling language is required. Figure 2.2 describes the relationships between the conceptualization and the model.
1 Introduction
1.1 Motivation
1.2 Problem Statement
1.3 Objectives and Contributions
1.4 Outline
1.5 Previous Publications
2 Background
2.1 Business Process Management
2.2 Business Process Modeling
2.3 Case Management
2.4 Business Artifacts
2.5 Summary
3 Business Artifacts and Case Management
3.1 Business Artifacts with Lifecycle Services and Associations
3.2 Guard-Stage-Milestone
3.3 Case Management Model and Notation
3.4 Differences between GSM and CMMN
3.5 Summary
4 Case Management Model and Notation Method Complexity
4.1 Method Complexity
4.2 Methodology
4.4 Findings
4.4.1 Implications
4.5 Summary
5 Transformations Between GSM and CMMN
5.1 Motivation
5.2 Transforming an Artifact Type into a Case Type
5.3 Transforming a Case Type into an Artifact Type
5.4 Summary
6 Systematic Literature Review of Process Modeling Complexity Metrics
6.1 Background
6.1.1 Related Work
6.1.2 Context
6.1.3 Validation of Process Metrics
6.2 Review Questions
6.3 Review Methods
6.4 Results
6.5 Discussion
6.5.1 Principal Findings
6.5.2 Strengths and Weaknesses
6.6 Summary
7 Metrics for Case Management
7.1 Applicability of Current Process Metrics to Case Management Modeling and Notation
7.2 Defining Metrics for Case Management Modeling and Notation
7.3 Theoretical Validation
7.4 Summary
8 Empirical Validation of Case Management Metrics
8.1 Empirical Validation
8.2 Methodology
8.3 Analysis
8.3.1 Sample Size
8.3.2 Normality
8.3.3 Times
8.3.4 Hypothesis Testing
8.3.4.1 Model Comprehension
8.3.4.2 Perceived Complexity
8.3.4.3 Perceived Complexity and Model Comprehension
8.3.4.4 Pairwise Comparison
8.3.4.5 Complexity Weights Validation
8.3.5 Measurement Validity
8.3.6 Findings
8.4 Summary
9 Conclusion and Future Areas for Investigation
9.1 Discussion of Findings
9.2 Implications
9.3 Limitations
9.4 Recommendations for Future Research
9.5 Summary
Bibliography
GET THE COMPLETE PROJECT
