Ontology-based CBR and Process Execution Approach

Get Complete Project Material File(s) Now! »

Theoretical Framework

This chapter gives an outline of the theoretical framework of the thesis. It introduces the three relevant aspects, which supporting this research work: process execution and flexibility, case-based reasoning (CBR), and the proposed combination of CBR and process execution to support flexibility.

Process Execution and Flexibility

Process execution refers to the accomplishment of roughly, partially or entirely predefined processes by humans and/or information systems. According to the Workflow Management Coalition (WfMC, 1995, p.7) a process definition or model is a “[…] computerised representation of a process that includes the manual definition and workflow definition”. This definition is rather narrow since it defines that a process model has to be computerised at all. In the following, this definition is extended:

Definition 2.1: Process Model/Definition

A process model or definition is a representation of a business process that includes a manual work definition and/or computerised workflow definition (adapted from WfMC (1995, p.7)).
In addition to this, a “[…] process model captures the activities to be executed, their control and data flow, the organizational entities performing the activities, and the data objects and documents accessed by them” (Reichert and Weber, 2012, p.15). The process models can serve as the basis for the execution of the containing process logic. Since most process-oriented information systems “[…] describe process logic explicitly regarding a process model providing the schema for process execution” (Reichert and Weber, 2012, p.4). The term process execution is related to and used interchangeably with the term workflow, which can be defined as follows:

Definition 2.2: Process Execution/Workflow

Process execution or workflow is the “[…] computerised facilitation or automation of a business process, in whole or part” (WfMC, 1995, p.6).
The computerised facilitation or automation of a business process, the process execution, is usually done with the support of a workflow management system.

Definition 2.3: Workflow Management System

A workflow management system “[…] completely defines, manages and executes “workflows” through the execution of software whose order of execution is driven by a computer representation of the [process] logic” (WfMC, 1995, p.6).
The specific execution component, the core element, of a workflow management system is called workflow engine or process execution engine.

Definition 2.4: Workflow Engine/Process Execution Engine

A workflow engine or process execution engine is a software component that “[…] allows creating, executing, and managing process instances related to the same or to different process models” (Reichert and Weber, 2012, p.33).
The introduced concept of processes execution and workflows exist since quite a while. Moreover, traditionally those workflow management systems are focussing on rigid and stable business processes. Nevertheless, the workflow concept has its legitimation but needs to be extended to support knowledge worker in a more flexible manner.

Flexibility of Business Processes and Workflows

Traditionally, workflow management systems are focussing “[…] predictable and repetitive business processes, which can be fully described prior to their execution in terms of formal process models” (Reichert and Weber, 2012, p.43).
However, “[…] flexibility is required to accommodate the need for evolving business processes” (Reichert and Weber, 2012, p.43). This flexibility especially required for business processes, which support knowledge workers perform their knowledge-intensive tasks. Reichert and Weber (2012) identified the following four major needs of business process flexibility: variability, looseness, adaptation, and evolution.

  1. Process variability: Process variability occurs when processes need to be handled in different process variants based on the current context during process execution. “Process variants typically share the same core process whereas the concrete course of action fluctuates from variant to variant” Reichert and Weber, 2012, p.45).
  2. Process looseness: Process looseness refers to knowledge-intensive processes, which are regarded as unpredictable and emergent. « For processes of this category, only their goal is known a priori » (Reichert and Weber, 2012, p.46). An example of process looseness is patient treatment cases, where “[…] the parameters determining the exact course of action are typically not known a priori and might change during process execution” (Reichert and Weber, 2012, p.46). Therefore, a predefined and detailed process description is rather difficult and even impossible. Instead, processes of this category require a loose specification” (Reichert and Weber, 2012, p.46).
  3. Process adaptation: Process adaptation exists when entire processes or their structure need to be adapted to “special situations” or when certain “exceptions” occur (Reichert and Weber, 2012).
  4. Process evolution: Process “[…] evolution represents the ability of the process implemented [in a workflow management system] to change when the corresponding business process evolves” (Reichert and Weber, 2012, p.47).

As mentioned the processes and workflows of knowledge workers tend to be unpredictable and can be assigned to the “process looseness” category. Reichert and Weber (Reichert and Weber, 2012, p.46) argue that “[…] it is not possible to establish a set of process variants for these processes, since the parameters causing differences between process instances are not known a priori” (Reichert and Weber, 2012, p.46).
Therefore, there is a need for an approach and corresponding method to enhance a workflow management system to deal with knowledge work, by providing process variants based contextual information.
In the following related concepts and methods will be introduced as a potential basis for the approach that will be presented in the research work.

Flexibility of Case Management


Case management provides the ability to manage cases (as the word suggests), which contains e.g. knowledge of previously experienced situations. This case knowledge can be workflow related information. Van der Aalst, Weske and Grunbauer (2005) propose case management as a paradigm shift in workflow related environments – especially for knowledge-intensive processes. Case management gives the workers more freedom, flexibility and provides the awareness of the whole context of activities within a business process (van der Aalst, Weske and Grunbauer, 2005). McCauley (2010, p.265) defines case management as follows “Case management is the management of long-lived collaborative processes that require coordination of knowledge, content, correspondence and resources to achieve an objective or goal. […] Human judgement is required in determining how to proceed, and the state of the case can be affected by external events.”
Case management focuses on the whole case. Whereas in workflow management, the focus is on the current work item or activity the execution. Workflow management makes only a small contribution towards accomplishing the goal of the entire case. Case handling is driven by the data-flow instead of the control-flow, and this is also true for knowledge-intensive processes where the process is based on a collection of data objects (van der Aalst, Weske and Grunbauer, 2005). This data-flow focus means that the data objects representing the whole context are the key part in knowledge-intensive processes and case management.
Swenson (2010) has taken up the topic of case management and introduced a “new process-management orientation […] as adaptive case management (ACM) [, where] the case itself is the focus” (Swenson, 2010, p.2). Swenson (2010) defines ACM as “[…] systems that are able to support decision making and data capture while providing the freedom for knowledge workers to apply their understanding and subject matter expertise to respond to unique or changing circumstances within the business environment” (Swenson, 2010, p.4). The Workflow Management Coalition (WfMC) has also taken up the ACM topic, in the meantime several books (Swenson, Palmer and Silver, 2011; Swenson, Palmer, Pucher and MD, 2012) were published in association with the WfMC concerning ACM. The adaptability feature of ACM has some similarities with the case-based reasoning methodology. ACM includes mechanisms to reuse « […] templates for initiating new cases, including the use of completed cases as templates. […] So the case itself can be a template for a new case instance » (Palmer, 2011, p.85).

1 Introduction 
1.1 Background
1.2 Problem Statement and Purpose of the Study
1.3 The Objectives and Goals of the Study
1.4 Thesis Statement and Research Questions
1.5 Research Strategy
1.6 Scope, Research Subjects and Limitations
1.7 Rationale of this Study
1.8 Contribution
1.9 Structure of the Thesis
2 Theoretical Framework
2.1 Process Execution and Flexibility
2.2 Case-Based Reasoning
2.3 Case-based Reasoning and Process Execution
2.4 Results and Discussion
3 Research Methodology and Design 
3.1 Information Systems Research
3.2 Design Science Research
3.3 Meta Research Methodology
3.4 Research Design and Process
4 Problem Relevance and Application Scenario 
4.1 Data Source for Application Scenario
4.2 Application Scenario – the Admission Process
4.3 Case and Process Execution Data
4.4 Scenario and Data Analysis
4.5 Problem Relevance and Objectives
5 Ontology-based CBR and Process Execution Approach .
5.1 Introduction
5.2 Related Work
5.3 Integrated CBR Approach
5.4 Ontology Framework
5.5 Conceptual Framework
5.6 Methodology
5.7 Conclusion
6 The Case Model
6.1 Case Description including Process Execution Context
6.2 Complexity and Cognitive Adequacy
6.3 Potential Case Content Modelling Languages
6.4 Case Model of Ontology-based CBR and Process Execution
6.5 Conclusion
7 Case-based Reasoning Services
7.1 Introduction
7.2 Case Similarity
7.3 Case Adaptation
7.4 Case Evaluation and Learning
7.5 Conclusion
8 Ontology-based CBR and Process Execution Prototype 
8.1 Prototype Environment
8.2 ICEBERG-PE Approach Instantiation
8.3 Conclusion
9 Evaluation
9.1 Data Source for Evaluation
9.2 Summative Evaluation of Procedure Model
9.3 Summative Evaluation of Approach and Prototype
9.4 Confirmatory Evaluation
9.5 Conclusion
10 Conclusion
10.1 Contribution
10.2 Summary and Research Questions
10.3 Methodological Reflection
10.4 Recommendations for Further Research
10.5 In Closing

Related Posts