As technology evolves, enterprises are expected to offer their products and services through an ever-increasing number of channels. The practicalities of this are further complicated by the number of products and services that need to be offered. Taking a bank for example, multiple products and services (current accounts, savings accounts etc.) must be offered through several channels (physical branches, call centers, internet banking, mobile applications etc.) to multiple client types (business client, retail client etc.). The internal structure of the organisation also complicates matters as the responsibility for the product design, technical solution and the operational servicing of the customer is usually the responsibility of different parts of the organisation. However, many of the processes executed in will likely be shared. Depending on the process modeling approach, these shared processes may be modelled separately in each area. A similar situation relating to car components where more than 20 variations of the same process were found based on product, supplier and the development phase of the component also illustrates this problem [1,2].
A client may wish to start in one channel and then switch to a different channel (e.g. possibly call the call center) [3,4]. Due to the organisational structure issues referred to earlier, modeling this process flow becomes problematic because of the number of permutations that emerge. If there are four steps in a process, and two possible channels for each step, then there are eight possible permutations of process flow available. The permutations become even worse when there are four or five channels in use. Modeling business processes across multiple channels and multiple products will be referred to as the multi-channel / multi-product dilemma in this study. Although this issue is likely to occur in most large service related organisations, it is particularly prevalent in financial services where many back-end processes are shared across products, channels, business units, and customer segments. This dilemma has not been addressed in the business process modeling literature. Furthermore, the mapping of business processes in a multi-channel environment is often carried out by different employees, in different parts of the organisation, for different projects and over an extended period of time, which results in multiple models for the same process [1]. As the number of process models in the repository increases over time, new issues begin to appear [2]. Multiple versions of the same model, similar logic appearing in multiple models [1,5], difficulties in locating the correct version of a process model, and conflicting versions of a process model [1] are some of the issues that have been documented in the literature [2,[6][7][8][9][10]. While these issues could be improved by reusing complete process models, one study found that only 10.2% of respondents reused complete process models [11].
Although conceptual models for process model reuse have been proposed [12,13], the reuse of process models in organisations has received less attention than knowledge sharing and reuse [11,14]. We believe that this is indicative of a broader issue relating to the reuse of complete process models in practice. Hence the objective of this research is to develop a business process modeling method to increase complete process model reuse by other models in the repository.
A process modeling method that improves process model reuse in this manner would be of value to organisations that carry out process modeling in an environment with multiple channels, products / services, and customer types. Therefore, the research question posed for this research is: How can complete process model reuse by other models in a multi-channel and multi-product financial services environment be improved?
This research project will adopt a Design Science Research (DSR) methodology and accordingly a pragmatic philosophy. Design science research is considered an appropriate approach because the purpose is to develop an IS artifact (a new method) and it provides a framework that can be used for applied IS research [15,16]. DSR is concerned with developing or improving artifacts (constructs, methods, models, and instantiations) which are of use to society [16][17][18]. It is envisaged that the research will consist of a main DSR cycle (designing the method) and two sub DSR cycles: 1) illustrating the consequences of low levels of process model reuse using System Dynamics and 2) developing a quantitative measure of complete process model reuse in the repository.
A mixed method methodology will be used to conduct the research. These methods will consist of quantitative and qualitative approaches using literature reviews, interviews with stakeholders and statistical analysis of process repositories. The methods vary from being positivist (statistical analysis of historical process repositories) to interpretivist (e.g. interviews being used to develop the SD model and evaluate the artifact in a real setting). However, the mix between quantitative and qualitative methods will vary depending on the DSR cycle in question. Table 1 summarizes the research instruments, data and analysis that will be employed in this research project.
This project will develop a process modeling method (EPReS) which increases the reuse of complete process models by other models in the repository. The DSR approach of Peffers has been adopted for this research [19]. EPReS must be shown to meet its objectives and to be useful [16][17][18]20], and will be evaluated in a business unit of a large South African financial services organisation. However, in research conducted so far, no measure of the level of reuse of process models by other process models has been found, and accordingly, the development of this measure has been incorporated into this project. Such a measure is essential for a quantitative evaluation of EPReS.
Process model reuse has been studied from the perspective of human reuse of process models, reuse of elements of process models, and even conceptual models of process model reuse [12,13,21,22]. The reuse of process models when modeling has been largely focused on how to guide the modeler to create new models based on adapting existing models, for example: reference models, automated variant creation, identification of similar models [23][24][25][26]. However, this approach still results in a new process model being added to the repository and will not solve the problem of multiple redundant models which are caused by the multi-channel / multi-product dilemma.
Process model reuse can be categorized as shown in Fig. 1. Using this approach, we first consider reuse based on whether the reuse is external (e.g. an employee reusing a model in the course of their work), or whether the reuse is internal within the process repository itself. Thereafter, we can classify the reuse into the reuse of partial process models (or elements thereof) and the reuse of complete process models.
A possible measure of process model reuse is the amount of reuse of models in a repository by other process models in the same repository. In this study, we are interested in the reuse of complete process models by other process models internally within the repository. Accordingly, measuring the level of process model reuse by other models in the process repository would be an important indicator of model reuse. While process model reuse is a frequent topic of research, no research could be found relating to the reuse of models within a process repository by other models within the repository.
The current state of this research project is reflected in Table 2.
Status New method development Proposed method has been developed and is being evaluated in a real-world situation Measure of model reuse development Proposed measure has been developed and is being evaluated in a real-world situation. A paper in this regard has been accepted for the BPM 2019 Conference Workshops A Risk Management Framework for DSR has been proposed [27] and this framework was used to identify the top 3 risks to this research project. These risks are shown in Table 3.