Open Source Business Process Management for Handling Processes in the Public Sector

Open source Business Process Management for handling processes in the public sector

MIKAELA NÖTEBERG

Master’s Thesis at CSC Supervisor: Joel Brynielsson Examiner: Jens Lagergren

TRITA xxx yyyy-nn

Abstract

Business processes are part of every organization, in more or less structured ways. They serve as a documentation of how work should be performed. Business Process Management (BPM) is a set of methods and technologies to support the modeling, execution, administration, and analysis of business processes. BPM aims to bridge the gap between strategy and operations in an organization. Inefficient manual processes in this gap introduce problems with consistency, traceability and agility. This degree project investigates the suitability of open source Business Process Manage- ment Systems (BPMSs) for handling processes in government agencies to address these issues. The Swedish Export Credits Guarantee Board’s (EKN’s) application process for export guarantee offers is used as case. Interviews were conducted and a proof of concept using open source BPM for EKN’s application process was implemented, which to- gether with the literature review are analyzed to find key factors indicating a process’ successful execution in a process engine. The key factors found are that the process should be delimited, repetitive, not running for too long, and be predictable with regard to every possible outcome. Referat

Open source Business Process Management för handläggningsprocesser inom oﬀentlig verksamhet

Alla organisationer har processer, i mer eller mindre struk- turerade former. Processer fungerar som en dokumentation över hur arbete ska genomföras. Business Process Mana- gement (BPM) är en uppsättning metoder och tekniker för att stödja modellering, exekvering, administrering och analys av processer. BPM är ett sätt att försöka minska klyftan mellan organisationen och verksamheten i en orga- nisation. Ineffektiva manuella processer däremellan skapar problem med hur konsekvent, spårbart och flexibelt arbe- tet blir. Detta examensarbete undersöker lämplighetsgra- den av open source Business Process Management System (BPMS) för handläggningsprocesser inom myndigheter för att hantera dessa problem. Exportkreditnämndens (EKN:s) ansökningsprocess för exportgaranti-offerter används som exempel. Intervjuer genomfördes och en proof of concept av open source BPM för EKN:s ansökningsprocess imple- menterades, vilket tillsammans med litteraturstudien ana- lyseras för att hitta viktiga faktorer för en process som in- dikerar framgångsrik exekvering i en processmotor. De faktorer som hittats är att processen ska vara avgränsad och repetitiv, samt att processen inte får pågå under för lång tid och är känd avseende alla möjliga utfall. Contents

1 Introduction1 1.1 Background...... 1 1.2 Purpose...... 1 1.3 Business processes ...... 2 1.3.1 Process modeling...... 2 1.3.2 Business Process Model and Notation...... 2 1.4 Business Process Management...... 2 1.4.1 Lifecycle...... 3 1.4.2 Stakeholders ...... 4

2 Theory5 2.1 Basic business process patterns in BPMN...... 5 2.1.1 BPMN deﬁnitions ...... 6 2.1.2 BPMN modeling...... 9 2.2 Business Process Management Systems...... 9 2.2.1 Brief history of BPMSs ...... 10 2.2.2 BPMS components...... 10 2.2.3 Open source BPMSs...... 11 2.3 Why BPM?...... 12

3 Methodology 15 3.1 Research design...... 15 3.2 Interviews...... 16 3.3 Proof of concept ...... 16 3.3.1 Context...... 17 3.3.2 Modeling in BPMN ...... 17 3.3.3 Implementing an executable process ...... 17 3.3.4 Validation...... 18

4 Results 19 4.1 Interviews...... 19 4.1.1 Respondent A...... 19 4.1.2 Respondent B...... 20 4.1.3 Respondent C...... 21 4.2 Proof of concept ...... 22

5 Discussion 23 5.1 Business Process Management...... 23 5.1.1 Predictability...... 23 5.1.2 BPMSs over traditional system development ...... 24 5.1.3 To implement and use...... 24 5.1.4 User acceptance ...... 26 5.1.5 Open source...... 26 5.2 Government agencies...... 27

6 Conclusions 29 6.1 Key factors ...... 29 6.2 Future work...... 30

Bibliography 31 Chapter 1

Introduction

This chapter is an introduction to this degree project. Section 1.1 presents the background, Section 1.2 presents the purpose and research questions, Section 1.3 introduces business processes, and Section 1.4 introduces Business Process Manage- ment.

1.1 Background

There is often a gap between strategy (business: the what) and operations (IT, resources: the how) of an organization. Inefficient manual processes in this gap leads to problems with consistency, traceability and agility: work could get overlooked or duplicated, it is difficult to tell the whereabouts or status of an errand, and distributing or forwarding work between resources takes both time and effort.

1.2 Purpose

Government agencies, e.g., the Swedish Export Credits Guarantee Board (Export- kreditnämnden, EKN), often have business process models to document the way their organization works. The thesis objective is to investigate how open source Business Process Management (BPM) would suit handling processes in the public sector to address the issues mentioned above. The case used is EKN’s application process for export guarantee oﬀers.

Research questions • What are the strengths of using BPM for handling processes in the public sector? • What are the advantages and disadvantages of using an open source Busi- ness Process Management System (BPMS) compared to using a commercial BPMS? • What are the key factors indicating whether the execution in a BPMS is the appropriate solution for a given process?

1 CHAPTER 1. INTRODUCTION

1.3 Business processes

Processes are part of every organization, every business, in more or less structured ways. A business process can be defined as a set of activities or tasks that given one or more inputs creates value for a defined customer [4]. A customer in this context could be both internal or external, and value could be anything from reaching a business goal to manufacturing a physical product. The identification and structure of these business processes is a key to taking advantage of possible improvements, such as effectiveness (time), efficiency (cost), and quality (e.g., error rates) to ensure consistent outcomes. Davenport and Short[6] emphasize the improvement potentials of examining an entire process rather than each activity or task separately, which is the cornerstone of BPM.

1.3.1 Process modeling Business process modeling can be deﬁned as the process of creating representations, i.e., models, of a business process with the intention to improve it [8]. A more general way of putting it is that process models are documentations of how an organization actually works [7]. There are many approaches, in the form of methods and techniques, to business process modeling; activity diagrams, use case diagrams, event-driven process chains, Petri nets, etc. [1, 27]. However, in the context of BPM, one widely adopted standard for high-level representation of business processes is the Object Management Group (OMG) standard BPMN [5, 20], see the following section.

1.3.2 Business Process Model and Notation Business Process Model and Notation (BPMN) is a graphical and executable notation standard for business processes. BPMN is designed to be used as a common language for all business users, from analysts to system engineers, i.e., in both business process design and implementation. The current version, BPMN 2.0, was released in January 2011 [20].

1.4 Business Process Management

Business Process Management (BPM) is a set of methods, approaches, techniques, and technologies to support the design, execution, automation, administration and analysis of business processes. BPM is an interdisciplinary ﬁeld combining principles from – but not limited to – operations management, quality management, workﬂow management, industrial engineering and software engineering, to support the stages of a business process [7]. It is an area of interest for both business managers, industrial engineers, and system engineers because of the diversity it provides. Business managers and industrial engineers’ interest in BPM lies in the ability to optimize and improve organizational

2 1.4. BUSINESS PROCESS MANAGEMENT performance, whilst it allows system engineers to implement and monitor systems in conjunction with the organizational view of the business managers.

1.4.1 Lifecycle

The BPM lifecycle is an iterative process including the following phases: design, modeling, implementation, monitoring, and optimization (see Figure 1.1). The iterations are preceded by identiﬁcation of a relevant business process, i.e., a delimited process, including any related sub-processes, which is a candidate for execution. To be able to measure the performance of an implemented process it is important to deﬁne performance metrics or key performance indicators (KPIs). These metrics could for instance be cost-, time- and/or quality-related.

Design

M n o io d t e a l i z n i

r n

a i

n i o o n M

Figure 1.1: The BPM lifecycle.

Design

In the design phase a theoretical model of the process is designed, or redesigned with respect to ﬁndings in the optimization phase.

Modeling

In the modeling phase the current state of the process is documented using a suitable notation, including what input and output each part of the process has.

Implementation

In the implementation phase an executable process model is deﬁned and deployed in a Business Process Management System (BPMS), see Section 2.2. In more general

3 CHAPTER 1. INTRODUCTION terms, the development and deployment of an IT system supporting the process takes place. This phase also contains organizational change management, i.e., the actions taken to change how the involved participants work within the process.

Monitoring In the monitoring phase the executed process is monitored and controlled, and relevant data is gathered.

Optimization In the optimization phase the gathered data from the previous phase is analyzed with respect to the deﬁned performance measures for the process. Potential improvement possibilities and bottlenecks are identiﬁed and corrective actions are applied in the design phase accordingly.

1.4.2 Stakeholders Within an organization, there are many stakeholders involved in a BPM initiative. There are the managers with the overall responsibility for the success of the organization. The process owners have the responsibility for the effectiveness and efficiency of a given process. There are the process participants who are the human actors performing work within the process. The analysts are responsible for the identification, analysis, redesign and monitoring of the process. Finally, there are the system engineers, in form of architects and developers, responsible for the implementation of the process.

4 Chapter 2

Theory

This chapter presents the theoretical framework. Section 2.1 describes the most common elements of the business process modeling notation BPMN, Section 2.2 describes Business Process Management Systems – their history and components, and Section 2.3 presents some theoretical factors to why BPM should be used.

2.1 Basic business process patterns in BPMN

The constructs of Business Process Model and Notation (BPMN) are divided into a set of basic modeling elements, and a set of extended modeling elements [20]. To model simpler business processes the basic BPMN elements are sufficient, while the complete element set adds more expressive power [27]. Process designers can start with the basic elements, and add more complexity as they become more familiar with the language. According to findings by zur Muehlen and Recker[19], less than 20% of the BPMN vocabulary is used on a regular basis and an average of 9 different elements are used in each model. The nine most frequently used elements of BPMN, found by zur Muehlen and Recker[19], are activity, sequence flow, start event, end event, basic gateway (non-specific), parallel gateway, data-based XOR, pool and lane, all of which will be described in this section. Figure 2.1 and Figure 2.2 shows a simple BPMN example in the form of a Hello World program.

Hello world

Figure 2.1: Graphical Hello World example in BPMN.

5 CHAPTER 2. THEORY

Figure 2.2: XML Hello World example in BPMN.

2.1.1 BPMN deﬁnitions To describe the ﬂow through a process, BPMN introduces tokens as the current state of a process instance. Since BPMN is both graphical and executable, the standard include both visual and XML representations of the elements.

Activity An activity represents work that needs to be performed during the execution of the process. An activity is either a sub-process or a task. A task is used when the work is not further decomposed into a finer level of process detail [20]. There are different types of tasks depending on what resource is performing the work, e.g., the user or the system. An activity is visualized as a rounded rectangle. The visual difference between a sub-process and a task is that tasks have a small marker in the top left corner indicating what kind of task it is (see Figure 2.3), whilst a sub-process does not have such a marker.

User Task Service Task Script Task Sub-process

Figure 2.3: Example activity representations.

Event A start event is an entry point of the process and, similarly, an end event is an exit point, e.g., when the process (or sub-process) instance ﬁnishes. There are also intermediate events that represent happenings that can occur during the execution of the process. An event is visualized as a circle with an open center, i.e., with room for indicators of triggers or results of that event. A start event is a standard circle, an

6 2.1. BASIC BUSINESS PROCESS PATTERNS IN BPMN end event has a thicker border, and an intermediate event has a double border, see Figure 2.4.

Figure 2.4: Example event representations. Top row from the left: start event, intermediate event, end event. Second row from the left: timer start event, error intermediate event, escalation end event.

Sequence ﬂow

Sequence flows show the order in which activities are performed. A sequence flow is a directed connection between two flow objects, viz. activities, events, and gateways (see below), of the process. During execution, all default outgoing sequence flows from a visited flow object will be followed. Originating from gateways there are conditional sequence flows that are only followed if the applied condition expression evaluates to true. A default sequence flow is followed if none of the conditional sequence flows originating from the same gateway evaluates to true. A sequence flow is visualized as an arrow from the source flow object to the destination flow object. A conditional sequence flow has a condition expression next to it, and a default sequence flow has a crossing line at the start. Figure 2.5 shows the different sequence flows.

conditionExp

Figure 2.5: Top-down: sequence flow, conditional sequence flow, and default sequence flow.

Gateway

Gateways are used to fork or join different paths of the process. That means, depending on the type, it can generate or consume tokens. A parallel gateway, or AND gateway, will await one token per ingoing sequence flow, before continuing the process. Furthermore, it will generate a token for each of the outgoing sequence flows, creating concurrent execution. This means that a parallel gateway can be

7 CHAPTER 2. THEORY either forking or joining, depending on the number of ingoing and outgoing sequence flows. An exclusive gateway, or data-based XOR, represents decisions. When a token arrives at an exclusive gateway, the outgoing conditioned sequence flows will be evaluated, and the first condition expression evaluating to true will be followed. An exclusive gateway joining several ingoing sequence flows will forward each token received, without synchronization. An inclusive gateway works in a similar manner, only that all of the conditioned sequence flows evaluating to true will be followed. Gateways are visualized as diamond-shapes, with different indicators; a parallel gateway contains a plus sign, an exclusive gateway contains an X, and an inclusive gateway contains a circle, see Figure 2.6.

Figure 2.6: Example gateway representations, from the left: parallel gateway, exclusive gateway, and inclusive gateway.

Pool and lane Pools and lanes are graphical representations of resources. Pools are used to diﬀer- entiate the participants of a collaboration, e.g., separating diﬀerent organizations. A pool can either have internal details, as in the process that will be executed by that participant, or it can be left blank, and thereby treated as a black box. Lanes are used to organize activities within a pool, e.g., categorizing functions or roles. A pool is visualized as a rectangle, with a label indicating the resource group. Lanes are visualized as delimiters, extending the entire vertical or horizontal length of a pool. Figure 2.7 shows a pool with two lanes. Lane B Pool Lane A

Figure 2.7: A pool with two lanes.

8 2.2. BUSINESS PROCESS MANAGEMENT SYSTEMS

2.1.2 BPMN modeling The Object Management Group (OMG) presents some modeling best practices relative process scope, diagram layout, and constructs used. Examples are identifying the what, where, who, why, and when to clearly define the scope of the process, using sub-processes to organize the process in phases, and not using gateways that are both diverging and converging [20]. Dumas et al.[7] suggest a five-step method for making a business process model executable, transforming business-oriented tasks into IT-oriented: identifying the automation boundaries, reviewing manual tasks, completing the model, reviewing the granularity level, and specifying the execution properties. Business process models may consist solely of the “happy path,” i.e., when everything works as expected. The step completing the model is to make sure no information is neglected, e.g., in form of outcomes when something goes wrong. Business process models need to be precise specifications to be executed by a BPMS [7].

2.2 Business Process Management Systems

When it comes to executing a business process, i.e., the implementation phase of the BPM lifecycle as described in Figure 1.1, an application is used to execute and coordinate that process. These applications are referred to as Business Process Management Systems (BPMSs). Their purpose is to coordinate business processes so that the tasks are performed at the right time, by the right resource [7]. In reality, BPMSs do not always execute all steps of the process completely, and they are therefore often accompanied by human intervention, in the form of input when a step is too complex to automate. The difference between a BPMS and other types of process-aware information systems, e.g., Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM), is that BPMSs utilize explicit business process models to coordinate the processes [7, 27]. So, instead of developing an application based on a description of a business process, you would deploy a BPMS using a business process model that users can dynamically change depending on the business requirements [13]. The aim of BPM standards, like BPMN, is to ease this process where business analysts can build a process model, which in turn could be translated into an implementation language of a BPMS [9]. You could say that a BPMS enables the business to live by “Say what you do, do what you say” [24]. There are different types of BPMS tools, which can be grouped into workflow- centric, application integration-centric, and decision-centric – to emphasize what kind of processes they are most suitable for managing [12]. More importantly, though, different BPMSs offer different functionality; from simpler systems with process design and automation, to more complex systems including features like advanced monitoring, process mining, and integration with third-party applications [7]. Despite the variety, the core feature of a BPMS is the execution of a business process.

9 CHAPTER 2. THEORY

A BPMS is generally not supposed to replace existing organization management systems, but rather add a process integration layer to coordinate and add agility, using the information available in the existing systems [29].

2.2.1 Brief history of BPMSs Smith and Fingar[24] presented the evolution of process management systems in three waves; a first wave where process stakeholders focused on work practices, a second where processes were manually re-engineered and applications were developed to automate the work, and a third – made possible by IT revolutions like the Internet – where process models were created that could be dynamically altered by the users. In the early 1990s, work by Davenport and Short[6], amongst others, about improving organizations by focusing on business processes, was the start of the management concept Business Process Re-engineering (BPR). To support BPR, different types of IT systems were developed, e.g., Workflow Management Systems (WfMSs). WfMSs were designed for specific purposes, while Smith and Fingar[24] proposed developing generic systems, based on business process models that would both be dynamic – because it would be easier to change the models when needed – and would save the developers from routine software changes – since the business process logic would be automated by the system [13, 24]. These systems became more sophisticated and integrated over time, and became known as BPMSs [7].

2.2.2 BPMS components A BPMS has four core components: an execution engine, a process modeling tool, a worklist handler and an administration tool [7], described below.

Execution engine

The execution engine, or process engine, handles the states and variables of any active process, including passing tasks to the worklist handler when they are due. All interactions with external services go through the execution engine.

Process modeling tool

The process modeling tool allows for creating and modifying process models, including information about associated data, resources, performance measures, and business rules. The process modeling tool is also where deployments of processes are managed.

Worklist handler

The worklist handler is where process participants recieve, and commit to, tasks. When a participant selects a task from their worklist, a corresponding electronic

10 2.2. BUSINESS PROCESS MANAGEMENT SYSTEMS form – for input and output data – is rendered. Upon ﬁlling out the form, the execution engine gets signaled that the task is complete. Selecting a task is called check-out, while completing the task is called check-in.

Administration tool

The administration tool, or monitoring tool, allows users to monitor the performance of the current processes and the resources executing them.

2.2.3 Open source BPMSs In a study conducted by Wohed et al.[28] on open source BPMS, the conclusion was that open source systems, in contrast to proprietary tools, are more aimed towards developers than business analysts. When comparing state-of-the-art open source BPMSs to proprietary systems, they found that none of them was clearly superior to the others. Diﬀerences found was that some proprietary tools had a wider range of features, and that open source tools had poor pattern support. The authors do, however, state that jBPM (as an open source BPMS) might be a good choice for Java developers. There are many open source BPMSs available, as indicated on lists by Java- Source.net and SourceForge[16, 25]. Both Activiti and jBPM are light-weight open source BPMSs, with Java execution engines supporting BPMN 2.0 at its core [2, 17].

Activiti

The Activiti team has the mission statement to “Make Business Process Manage- ment (BPM) ubiquitous by oﬀering solutions that both business people and developers love” [3]. The core is the execution engine, which is a Java process engine running BPMN 2.0 processes natively. Except for the execution engine Activiti provides a web application, called Activiti Explorer, which is both a worklist handler and an administration tool. The Activiti Explorer is the access to the execution engine for all users of the system. Activiti also comes with Activiti Modeler and Activiti Designer. Activiti Modeler is a process modeling tool for graphical author- ing of BPMN 2.0 business processes, as well as the tool to manage the diﬀerent servers and deployments. The Activiti Designer is a plugin for Eclipse for the same modeling purposes as Activiti Modeler [2]. jBPM

Similar to the mission statement of Activiti, jBPM focuses on process management features for both business users and developers. jBPM supports business processes through the entire BPM lifecycle, providing tools to model, execute, and monitor business processes. The core is the execution engine, written in Java, supporting BPMN 2.0. jBPM comes with JBoss Workbench IDE which is a web application on top of the execution engine, containing the worklist handler, administration tools,

11 CHAPTER 2. THEORY process modeling tools (including data modeling tools), and dashboards for Business Activity Monitoring (BAM). jBPM can run in any Java environment, either as a service or embedded in an application. Packaged with jBPM is also the opportunity to deﬁne, manage, and execute business rules in order to fulﬁll business requirements and regulations [17].

2.3 Why BPM?

Many sources agree that BPM offers a solution to bridge the gap between business and IT, and between analysts and developers. The overall goal is continuous improvement in the form of business process models and an iterative lifecycle. It was estimated in the 1990s that 40% of the source code running in banks had to do with business process logic, such as coordination and execution order, rather than the actual data processing [7]. A BPMS can support the execution of a business process, managing the complexity in the background. Business processes are dynamic and ever-changing. The point of using a BPMS – not only for its support of the flow in process oriented work – is to be open for those changes (without changing an entire application). Smith and Fingar[24] argue that the alternative to a BPMS is extensive custom development that – even though versatile – becomes difficult to maintain as the workflows change, since it does not directly reflect business processes. A BPMS separates business process logic from data processing, which provides flexibility in maintenance and managing of the systems involved. A BPMS allows you to update a business process model without altering code, and – vice versa – to alter an application without affecting the business process logic. One immediate benefit of introducing a BPMS is workload reduction. The system will take care of the coordination of tasks, making sure they are forwarded to the right resource as soon as the previous task is completed. The BPMS will also transport the work electronically, meaning removing both the effort and de- lay introduced by handling and transporting paper within the organization [4,7]. Furthermore, it will ensure progress in the form of forwarding work when tasks are completed, as well as traceability of the status of each errand. Dumas et al.[7] presents the evolution of BPMSs with the insight that they provide support for the field of process orchestration logic, just like Database Man- agement Systems (DBMSs) do for the data management field. A BPMS can be used to orchestrate separate systems. Deploying a business process model including several systems will ensure the systems to perform their due tasks in that process [7]. There are many factors pertaining to successful adoption of BPM in an organization. Eikebrokk et al.[8] concludes that management, individual, and socio-political factors all have influence. The authors suggest that organizations increase employee involvement by persuading, rather than forcing, them to take part in process modeling projects, which would increase the effectiveness of both process modeling and BPM [8]. Wong[29] highlights the importance of employee involvement meaning

12 2.3. WHY BPM? organizations should provide the employees with the necessary training and resources, as well as encourage them to make important decisions regarding process improvements.

Chapter 3

Methodology

This chapter describes the methodology used in the process of trying to answer the research questions. This study uses a qualitative research approach combining interviews and implementation of a proof of concept. Section 3.1 describes the overall research design, Section 3.2 describes the performed interviews, and Section 3.3 describes the implementation.

3.1 Research design

In an article by Hazzan et al.[14] the suitability of qualitative research in computer science education is discussed. In conclusion, depending on the research goal, investigation by qualitative research may be better suited than quantitative. Qual- itative research is outcome-oriented and applies to research of unstructured data, or data without ordinal values [11]. Instead of accepting or rejecting an a-priori hypothesis, a grounded theory is formed during the research by analyzing the data gathered [14]. This study uses a qualitative research approach combining interviews and observations. The observations in this case means implementation of a proof of concept. The iterative nature of qualitative research will help to gradually provide an understanding of the importance, usage, and diﬃculties of business processes – and in extension BPM and BPMSs – to analyze the strengths of open source BPM in the public sector. The project was conducted through three iterative phases of data collection, in the following order: literature review, interviews, and implementation of a proof of concept (i.e., observations). The literature review served as an exploratory study of the ﬁelds BPM, BPMSs, and the notation BPMN, as well as motivations of the usage of BPM according to earlier research (see Chapter2). The next phase was to perform in-depth interviews to understand attitudes and thoughts regarding the people-centered situation entailed by process handling and the introduction of task management systems. The interviews were complemented with observations in order to contrast the data gathered from the interviews with the experience of

15 CHAPTER 3. METHODOLOGY implementing a prototype.

3.2 Interviews

Interviews have been held with people involved with process handling in different government agencies, as well as people with experience with BPM and different BPMSs. The interviews were of an unstructured nature because of the diversity of expertise among the interviewees. An unstructured interview, in contrast to structured and semi-structured interviews, means adapting the questions to the interviewee [10]. Unstructured interviews are more flexible and sensitive to participants meaning they allow for discovery of new aspects and theories on the embraced themes, but are as a downside hard to replicate. Three in-depth interviews were held with one respondent each. The respondents were from different companies, and the themes of the interviews varied. The purpose of the interviews was to investigate how government agencies work with business processes, and to get a sense of what BPM and BPMSs are used for by discussing experiences with both proprietary and open source BPMSs.

• Respondent A is a senior solutions architect at a software company developing open source solutions. The theme of the interview was open source and jBPM.

• Respondent B is a business architect at a large government agency. The theme of the interview was process handling in government agencies.

• Respondent C is a system developer and architect at an IT consulting ﬁrm. The theme of the interview was experience with BPMSs, namely Oracle BPM and Activiti, and usage of BPM at two diﬀerent government agencies.

A fourth interview was held with an IT administrator at the Swedish Export Credits Guarantee Board (EKN), whose application process for guarantee oﬀers is used for the proof of concept (see the following section). The objective of this interview was to study and understand the case that would be implemented.

3.3 Proof of concept

To get a more concrete view of what BPMSs can be used for, a proof of concept (POC) was implemented. The point of a POC is to make a concrete implementation of an abstract concept. The abstract concept in this case is the usage of open source BPM for handling processes in a government agency. To properly triangulate the problem, theory and interviews are combined with actually testing the concept of an open source BPMS for a particular business process of a government agency. The idea is to get ﬁrst hand experience of BPM implementations as well as technical veriﬁcation of the concept of open source BPM in the public sector. Considering the role of IT, i.e., focusing on the implementation phase of the BPM lifecycle, the goal

16 3.3. PROOF OF CONCEPT was to implement an executable application process (from a government agency) using an open source BPMS.

3.3.1 Context The business process analyzed and implemented was the Swedish Export Cred- its Guarantee Board’s (Exportkreditnämnden, EKN) application process for export guarantee offers. EKN issues guarantees to insure exporters and banks against the risk of non-payment in export transactions [26]. The process of applying for an offer is both identified and designed earlier by EKN. The process was provided in an internal notation, and is a somewhat complex model containing both manual and automated steps. Hence, it is a suitable first case to implement in order to see what is difficult, easy, and at all supported.

3.3.2 Modeling in BPMN The ﬁrst step towards an executable process model was modeling the process in BPMN 2.0 using a combination of a plugin for Eclipse, the web tool provided by the chosen application (see Section 3.3.3), and manually altering the XML. The process model provided by EKN was not designed with the intention to deploy it in a BPMS, and thus some altering was needed similar to the ﬁve-step method suggested by Dumas et al.[7], see Section 2.1.2.

3.3.3 Implementing an executable process The implementation was made using jBPM, see Section 2.2.3. The reasons behind this choice was that: (1) jBPM is one of the most popular open source BPMSs, both thoroughly mentioned [12, 28] and used – over 3000 downloads per week at SourceForge in February 2014 [25], (2) a new release, version 6, as of January 2014 indicates the relevancy of the product, and (3) jBPM provides all the necessary tools for this study. jBPM is packaged with an execution engine, a modeling tool, a worklist handler, administration tools, a demo application to get started quickly, etc. The aim of the implementation was to obtain an executable version of EKN’s application process. The executed process would orchestrate the deﬁned tasks in the right order, according to diﬀerent outcomes of other tasks of that same process. It was to forward the tasks to the correct resource – either a system or the correct work unit. System tasks would provide communication with Java classes using “empty logic,” i.e., call methods with parameters and obtaining return values from dummy code. The data used in the implementation was limited to only using the variables needed to be able to simulate every possible path of the process.

17 CHAPTER 3. METHODOLOGY

3.3.4 Validation The proof of concept was considered fully implemented when it behaved as expected, i.e., when any process instance follows its decided path through the process – given the right parameters.

18 Chapter 4

Results

This chapter presents the results from applying the methodology. Section 4.1 presents data gathered from the interviews, and Section 4.2 presents ﬁndings from implementing the proof of concept.

4.1 Interviews

This section presents the ﬁndings from the performed interviews. Section 4.1.1 presents thoughts and opinions from respondent A [21], Section 4.1.2 presents thoughts and opinions from respondent B [22], and Section 4.1.3 presents thoughts and opinions from respondent C [23].

4.1.1 Respondent A

The open source community is quick to embrace trends and new technology. One benefit of open source is code quality: the developers often give the code a little more thought since the code is openly accessible in order to present it just right and thoroughly documented from the start. There is a higher number of “eyes on the code,” which improves it. Another benefit with open source is the opportunity to modify the product you are using by altering the code base directly. Open source is a type of establishment where many organizations work and flourish. As a publisher of open source products you get benefits like development from outside the company. The parts of a product, proprietary or not, that are not of direct relevance to the main activity of the organization could be released as open source in order to develop a well functioning asset for the main product. An example of this is Facebook releasing their database management system Cassandra as open source. Government agencies are governed by laws and regulations for which you can use a rule engine. Some BPMSs, e.g., jBPM, have a rule engine included. You do not always need a process to evaluate rules, though. The software company which respondent A is from has worked with a number of government agencies,

19 CHAPTER 4. RESULTS one of which uses the same rule engine for direct evaluation on their website (i.e., making it possible to ﬁll in some parameters and get a preliminary application result, before submitting an application) as their process engine use for handling the submitted applications. The rule engine is designed to be read and understood by both business people and IT people within the organization.

4.1.2 Respondent B

Respondent B works at a large government agency with many IT systems supporting different parts of the organization. Some of these systems are developed internally, while others are supported by a process engine. Being such a large government agency, the organization often take the responsibilities from other government agencies. When this happens, the organization often adopts the old systems (and sometimes personnel) handling the responsibility, which is an explanation for the number of IT systems maintained by the organization and also makes standardization more difficult. In larger organizations it is easy to see the improvement potentials of standardization. Documenting processes is one of the steps towards standardization: the business processes are collected for analysis to produce a common way of working. A standardization process of an organization should be from the bottom up, but it is difficult to standardize the core when all parts of the organization have different demands. Especially in government agencies, it is hard to force organizational change: humans are creatures of habit and does not always welcome change. In retrospect from performing standardization in the organization, it was determined that a common way of working probably should be established before building a common IT system. The purpose of the standardization procedure was to automate more tasks, and the organization chose a large proprietary IT system (Oracle BPEL SOA Suite) for this purpose. The choice of system was partially made because it would be easier to find consultants maintaining the system, since it is more common with product knowledge of well known systems from reputable product developers. An important goal for the organization, since they handle a large amount of paper acts, is reducing the amount of paper handled. One advantage with digitalizing, except for the obvious environmental aspect, is that task management becomes less tied to a physical office. This means that tasks can be shared between offices, depending on the load at each office, much easier than using a paper route. Gov- ernment agencies are also more strictly regulated than private organizations, and there are many laws and regulations that must be followed. During the process of digitalizing there are decisions to be made regarding the generalisation of the work, e.g., whether to keep an underwriter per case or per manual task in a case. If there are different underwriters per manual task, it is important to keep all the relevant information with the digital instance of the case. Otherwise work might be duplicated, e.g., conducting multiple preliminary investi- gations. There are also more or less qualified tasks to be performed within a process, which might cause employees to specialize and always perform the same particular

20 4.1. INTERVIEWS task. How process monitoring is performed invokes diﬀerent employee behaviour. The organization often keeps statistics of processes, e.g., for a particular type of case where 80% should be completed within three weeks, or how many times a case changes responsible personnel. In reality, no cases are alike and can therefore take various amounts of time. Processing times might diﬀer, so statistics on the whole cases might mislead and could make the employees feel unfairly monitored. There are processes spanning several government agencies, including the government agency that respondent B is from. The eGovernment Delegation, E- delegationen, documents patterns for cooperative processes to make it easier for citizens when, e.g., a relative passes away.

4.1.3 Respondent C Many proprietary BPMSs, e.g., Oracle BPM Suite, are complete product solutions (platforms). The underlying thought is to do everything and you need to accept how the product owners want you to use the product, and trust the product and its underlying framework. If you do respect and trust how the product works, there is great turnaround to be gained: you can create well functioning applications quickly. Open source BPMSs, e.g., Activiti and jBPM, are often Java-centric, giving them positive integration possibilities. In difference to complete platforms, Activiti and jBPM are core systems meaning that they can be integrated with your own system or product. From experience with introducing BPM at government agencies, respondent C states that introducing a new system first – e.g., a BPMS where the processes are strictly defined programmatically – and thus forcing a way of working, is not easy. Therefore the definition of a business process is important and the process model should be established in the organization before it is implemented in a BPMS. Re- garding actual implementation, however, a suitable process for deployment in a BPMS must have a reasonable life-span with regard to its instances. It is not desir- able to have process instances in the execution engine for months. Adaptive Case Management (ACM) [18] is well suited for government agencies, where investigation takes place. A process instance should only be present in the execution engine when it is actively worked with, and ACM allows process instances to be parked. For automation, we want clear and repetitive processes because volatile processes are hard to automate. The “happy path” of a process is not sufficient, i.e., every if case must be stated, since otherwise there could emerge errands that can not be dealt with in the process engine. One important issue with BPMSs is that the payload (data) is locked in a process instance. One solution is to only save keys to underlying data in the process instance, and save the actual payloads elsewhere.

21 CHAPTER 4. RESULTS

4.2 Proof of concept

The implemented proof of concept consisted of several sub-processes, two of which can be found in Figure 4.1 and Figure 4.2. Implementing and executing business processes in a BPMS, in this case jBPM, was found to be straightforward. What is important is to devote time to properly model the process prior to the implementation. Otherwise process instances would get stuck, i.e., not be able to be advanced, at certain activities of the process. In the jBPM web tool there was, though, a quick ﬁx where you could batch move several errands to another part of the process, or simply abort those instances. The business activity monitoring of the system could not be used properly, since the executed processes were not in production, but there was simulation capabilities to test execution load. Key Performance Indicators (KPIs) could be assigned to the tasks, and an estimation of the percentage of instances following a certain path (from a diverging gateway) could be speciﬁed. Further, there was the possibility to simulate a number of process instances traversing the executable process, with a given time distance.

Figure 4.1: The sub-process for registering (diarieföra) an application for an export guarantee oﬀer.

Figure 4.2: The sub-process for analyzing an application for an export guarantee oﬀer.

22 Chapter 5

Discussion

In this chapter the ﬁndings from the interviews and implementation will be discussed. Section 5.1 discusses the beneﬁts – and key factors – of Business Process Management, and Section 5.2 discusses the suitability of BPM for government agencies.

5.1 Business Process Management

Business processes are part of every organization, only that they in some cases are not defined. Process orientation is naturally a key aspect for introducing a Business Process Management System (BPMS), which more or less is equivalent to a process engine in the core functionality. If the work can not be defined in a process oriented manner, it has no place in a process engine. Business processes describe work procedures, and the point of a BPMS is orchestration of those processes in a monitored fashion. Although all work procedures can be defined as business processes, only in different level of granularity, not every process is suited for deployment in a BPMS even if it is possible to do so. To gain value from such an implementation, the chosen process should be properly delimited and repetitive, as was brought up during the interviews [23]. It is unnecessary to dedicate the time and effort to construct an executed process if it will never be used, if it is only used by one user, and/or the process consists of a single task.

5.1.1 Predictability

Even though BPMSs can be tailored to business processes of any kind, it is important to construct proper business process models for that purpose, as was shown with the proof of concept. The “happy path,” where everything works as expected, is often easy to deﬁne, but when deploying a model into an IT system to execute the process, it is important to describe every possible path of any instance of that process. If not, there will be consequences in terms of process instances getting

23 CHAPTER 5. DISCUSSION stuck at tasks which they cannot handle, and the tasks will therefore not be advanced. Take a simplified loan application as an example, where in some cases a more thorough credit report on the applicant is needed. If that particular case is not included in the model, the bank can neither accept nor reject the application. The worklist would slowly fill with ghost errands, i.e., instances without closure. This is also one motivation for not wanting long running process instances in an implemented process. A full worklist gives a cloudy overview, where it is hard to see what actually needs to be done, and what instances of a particular task are new. The solution for ghost errands is to batch move them and trying to merge them into a new version of the process. It would be much easier with predictability of the paths and outcomes of the process to implement. Sometimes that predictability can not be defined. If the order in which sub-processes are to be executed differ, they cannot be included in one overall business process. Unpredictability in business processes can be managed through Adaptive Case Management (ACM), which does not exist in every BPMS. ACM provides the functionality to park process instances, and when needed execute them in a relevant defined process, which settles the issues regarding unpredictability and long running instances. This, of course, could instead be handled with extensive custom development, but that would somehow miss the point of the process logic already being in place.

5.1.2 BPMSs over traditional system development

Smith and Fingar[24] states that a big disadvantage with traditional programming – in contrast to using a BPMS – is that it does not directly reﬂect business processes and therefore gets harder and harder to maintain as the process changes. What needs to be understood is that processes are dynamic and changeable, and maintaining software code supporting that agility takes time and eﬀort from the actual business logic. The advantage of using a BPMS is – when working process oriented – that the process orchestration logic is already in place.

5.1.3 To implement and use

Existing BPMSs provide tools that allow for rapid prototyping, since the complexity of process logic is managed in the background. Some difficulties with executing business processes are met as soon as a process model is turned executable, others are more of an application settings issue. The biggest problems met when implementing the proof of concept were simply because of not being familiar with the system. When introducing a new system into an organization there are often education and training involved to begin with, to overcome that first threshold. The “happy path” is a good starting point for implementation, but as previously mentioned it is not sufficient for production. Naive processes are simple, but leaving the basic elements of Business Process Model and Notation (BPMN) requires a little more thought when it comes to setting up the necessary configurations. BPMSs supporting BPMN differ when it comes to what set of elements is implemented.

24 5.1. BUSINESS PROCESS MANAGEMENT

Complex business process models could incorporate certain elements that are not available in all systems. For example, the element set in the Eclipse BPMN plugin did not completely correspond to the element set in the jBPM modeling tool. Although difficulties might present themselves while implementing, there is no real technical restriction regarding what a BPMS can execute. When the execution is in place, there is the possibility to automate manual steps. What is worth to automate is not dependent on technical limitations, but rather whether or not it saves time to do so. This is where the analysis and monitoring tools of a BPMS are helpful. We can identify bottlenecks and make rough estimations regarding the suitability of automating tasks of the executed process. Fabra et al.[9] mentions semiautomatic implementation, and explains it as minimum human intervention. Of course automation in many aspects is ideal but the Straight-through Processing (STP) that is provided by a fully automatic system is more suited for a rule engine than a process engine. Not all parts of a process is even possible to automate. Many work procedures of organizations, and government agencies in particular, enforce manual approval or supervision of some steps. Hirschhorn[15] wrote “Robots can’t run factories,” which is a statement relevant to what was just said. There are other benefits gained from introducing a BPMS than managing process orchestration logic in the background. Introducing an IT system to orchestrate work procedures means standardization. Strict definitions of business processes enforce consistent outcomes because the work is carried out in the same manner every time. Standardization and consistent outcomes do in turn provide fair treatment for customers. Having the process logic in place gives the opportunity to dedicate programming efforts toward data processing rather than orchestration. The situation found at banks in the 90s, where 40% of the running source code had to do with process logic, is not sustainable. BPMSs are, according to Smith and Fingar[24], designed to provide flexibility and agility because they are meant to support business process models and altering of the same. Business processes are changeable, and BPMSs are built to support that without altering code running the process logic. With the standardization and digitalizing of business processes comes rule enforcement. A BPMS ensures that the rules of a business process model is followed, and consequently that work is carried out in the predefined manner. A BPM initiative involves monitoring and analyzing executed processes. Many BPMSs provide administration tools for this purpose. This, in combination with the digitalizing, gives the opportunity of traceability of, e.g., status, responsible personnel, whereabouts of errands, and aggregated data with Key Performance Indicators (KPIs) of executed processes. The goal of BPM is continuous improvement. The focus of this study was the implementation phase of the BPM lifecycle. To get the full advantages of BPM, an executed process should be in use for iterations, since the improvement potential gained by analyzing monitored data is only possible in a used system.

25 CHAPTER 5. DISCUSSION

5.1.4 User acceptance The success of a BPM initiative is not only dependent on implementation results. An executed process is a strict deﬁnition of how (in what order and by whom) work is carried out, which means enforcing a way of working. Organizational change is mandatory, which indicates the need of user acceptance. The ﬁrst threshold to overcome is a new system, and on top of that is the standardization procedure where everybody involved are to work in the same manner (in the same process). The creature of habit that is mankind do not always welcome change, and it is therefore important to standardize work procedures before introducing a standard IT system. The importance of user acceptance can not be stressed enough in the context of BPM. The whole idea of BPM is the iterative lifecycle of continuous improvement, meaning the processes in fact will change from time to time. These changes will most probably be milder as time passes and the process gets more settled, yet users must be aware of it.

5.1.5 Open source Open source BPMSs might indeed be more targeted towards developers than proprietary counterparts, like Wohed et al.[28] concluded, but that means massive integration possibilities you would not have otherwise. A Java core engine, like that of jBPM and Activiti, can be run in any Java application, or as a service, and there is also the possibility to integrate with other systems through web services. Ultimately, there is no limitations to what systems they could be integrated with. As for jBPM, for a simple business process the web tool is enough to get things running locally, and that is without major programming efforts. Regarding the article by Wohed et al.[28], about differences between certain open source and proprietary BPMSs, the conclusions do not necessarily reflect the situation today, i.e., five years later. Systems are constantly changing from year to year. The article does, though, provide some preliminary indication of what might differ between different kinds of systems. The differences between various BPMSs are not distinctive enough to really make a difference when implementing simple processes. What it all comes down to is what features one might be looking for in a system, e.g., ACM, or what preferences regarding language and architecture one might have. The product used for the implementation of a proof of concept in this degree project, jBPM, served its intended purpose well. Open source implies code quality, because of the many “eyes on the code.” Many developers collaborate, which leads to better software. On the other hand, proprietary tools often offer more support for their users.

26 5.2. GOVERNMENT AGENCIES

5.2 Government agencies

In the interviews it was found that government agencies often think about processes in their work [22]. The process orientation, needed for BPM, is a fact, although it might not always be strictly followed. Standardization is a frequent subject in government agencies. The goal is to increase efficiency by standardizing work procedures to ensure consistent outcomes. Government agencies have a responsibility towards citizens to treat all people equally, and they also often have a maximum amount of time that a certain type of processing may take, which both benefit from consistent outcomes. Standardization work procedures are one of the benefits of introducing BPM. Another benefit is digitalizing, which of course would come with the introduction of any type of IT system. A digitalizing effort of task management, which BPM provides, has the advantage of load balancing opportunities between different physical offices in the organization – without actually sending around paper acts. Organizations in general want to reduce the amount of paper handling, and government agencies in particular does handle a substantial amount of paper acts. Government agencies are rule enforced, i.e., controlled by laws and regulations. Deploying process models into a BPMS enforce rules, which would act as a safeguard that the laws and rules regulating certain work procedures, e.g., what steps an application goes through, are followed. Laws and regulations change, which is out of the hands of the organization, and it is therefore important to be agile enough and support that flexibility. A BPMS use the explicit declaration of a business process model, and the point is for that model to be dynamically changeable. The value of traceability hardly needs to be explained: it is always a benefit to be able to trace certain errands regarding their status, who is working on it, etc.

Chapter 6

Conclusions

It is clear that most organizations, and government agencies in particular, would benefit from the immediate positive effects of introducing BPM – given that the employees welcome the initiative. The immediate positive effects are standardization, traceability, and agility. Strengths of using Business Process Management for handling processes in the public sector are – in addition to standardization, traceability, and agility – digitalizing task management, and rule enforcement to ensure that laws and regulations are followed. The differences between various Business Process Management Systems are not distinctive enough to really make a difference when implementing simple processes. What it all comes down to is what features one might be looking for in a system, or what preferences regarding language and architecture one might have. There are no limitations to what kind of processes could be executed in a Busi- ness Process Management System, but there are some key factors promoting the success of the implementation.

6.1 Key factors

A process’ suitability for execution in a BPMS depends on many factors. Some key indicators are that it should be a delimited and repetitive process, the process should not have particularly long-running process instances, and there needs to be predictability of every outcome of that process – meaning it will not deviate from the speciﬁed model. If it is not well deﬁned in which order tasks are to be performed, the process should be split in sub-processes and orchestrated with some type of Advanced Case Management. There also needs to be an overall user acceptance of the BPM concept in order to fully succeed with a BPM initiative.

29 CHAPTER 6. CONCLUSIONS

6.2 Future work

To further evaluate the suitability of open source BPM for government agencies, one possibility is to perform a case study of a BPM initiative while it is being established in a government agency. To observe and evaluate a BPM initiative would serve as a practical complement to this theoretical research, as you would be able to capture raw data of its usage. It would also broaden the scope of the research, since it would encompass the whole BPM life-cycle.

30 Bibliography

[1] Wil van der Aalst and Kees van Hee. Workﬂow Management – Models, Methods and Systems. The MIT Press, 2004. ISBN 978-0-2627-2046-5.

[2] Activiti. Activiti components, 2014. URL http://activiti.org/components.html. Accessed 2014-02-23.

[3] Activiti. Our vision, 2014. URL http://activiti.org/vision.html. Accessed 2014-02-23.

[4] Majed Al-Mashari. Innovation through Information Technology (IT) enabled Business Process Management (BPM): a review of key issues. International Journal of Innovation and Learning, 3(4):403–415, 2006.

[5] Jason A. Beckmann. Business Process Modeling: Software Engineering, Analysis and Applications. Nova Science Publishers, Inc., 2011. ISBN 978-1-61942-800-3.

[6] Thomas H. Davenport and James E. Short. The new industrial engineering: information technology and business process redesign. Sloan Management Review, 31(4):11–27, 1990.

[7] Marlon Dumas, Marcello La Rosa, Jan Mendling, and Hajo A. Reijers. Fundamentals of Business Process Management. Springer-Verlag Berlin Heidelberg, 2013. ISBN 978-3-642-33142-8.

[8] Tom R. Eikebrokk, Jon Iden, Dag H. Olsen, and Andreas L. Opdahl. Understanding the determinants of business process modelling in organisations. Business Process Management Journal, 17(4):639–662, 2011.

[9] Javier Fabra, Valeria de Castro, Pedro Álvarez, and Esperanza Marcos. Automatic execution of business process models: Exploiting the beneﬁts of Model-driven Engineering approaches. Journal of Systems and Software, 85 (3):607–625, 2012.

[10] Andrea Fontana and James H. Frey. Interviewing: The art of science. The Handbook of Qualitative Research, pages 361–376, 1994.

31 BIBLIOGRAPHY

[11] Greg Guest, Emily E. Namey, and Marilyn L. Mitchell. Collecting Qualitative Data: A Field Manual for Applied Research. SAGE Publications, Inc., 2013. ISBN 978-1-4129-8684-7.

[12] Paul Harmon. Exploring BPMS with Free or Open Source Products, 2007. URL http://www.bptrends.com/publicationfiles/advisor200707311.pdf. Accessed 2014-02-13.

[13] Paul Harmon. The BPMS Market, 2013. URL http://www.bptrends.com/publicationfiles/advisor20130730.pdf. Accessed 2014-02-13.

[14] Orit Hazzan, Yael Dubinsky, Larisa Eidelman, Victoria Sakhnini, and Mariana Teif. Qualitative Research in Computer Science Education. ACM SIGCSE Bulletin, 38(1):408–412, 2006.

[15] Larry Hirschhorn. Robots can’t run factories. In Computers in the Human Context: Information Technology, Productivity, and People, pages 301–307. MIT Press, 1989. ISBN 978-0-2625-6050-4.

[16] Java-Source.net. Open Source Workﬂow Engines in Java, 2014. URL http://java-source.net/open-source/workflow-engines. Accessed 2014-02-23.

[17] The JBoss jBPM Team. jBPM Documentation, Version 6.0.1.Final, 2014. URL http://docs.jboss.org/jbpm/v6.0.1/userguide/. Accessed 2014-02-23.

[18] Ajay Khanna. Managing Unpredictability using BPM for Adaptive Case Management, 2013. URL http://www.oracle.com/us/technologies/bpm/ bpm-for-adaptive-case-management-2067429.pdf. Accessed 2014-03-28.

[19] Michael zur Muehlen and Jan Recker. How Much Language is Enough? Theoretical and Practical Use of the Business Process Modeling Notation. Advanced Information Systems Engineering, 5074(1):465–479, 2008.

[20] Object Management Group, Inc. BPMN 2.0 Speciﬁcation, 2011. URL http://www.omg.org/spec/BPMN/2.0/. Accessed 2014-02-10.

[21] Respondent A, senior solutions architect at a software company developing open source solutions. Interview 2014-02-28.

[22] Respondent B, business architect at a large government agency. Interview 2014-02-26.

[23] Respondent C, system developer and architect at an IT consulting ﬁrm. Interview 2014-02-28.

32 BIBLIOGRAPHY

[24] Howard Smith and Peter Fingar. Business Process Management: The Third Wave. Meghan-Kiﬀer Press, 2003. ISBN 978-0-9296-5233-7.

[25] SourceForge. Business Process Management Open Source Software, 2014. URL http://sourceforge.net/directory/business-enterprise/ enterprise/processmanagement/. Accessed 2014-02-23.

[26] The Swedish Export Credits Guarantee Board. Our business, 2010. URL http://www.ekn.se/en/Om-EKN/Our-business/. Accessed 2014-02-18.

[27] Mathias Weske. Business Process Management: Concepts, Languages, Architectures. Springer-Verlag Berlin Heidelberg, second edition, 2012. ISBN 978-3-642-28615-5.

[28] Petia Wohed, Nick Russell, Arthur ter Hofstede, Birger Andersson, and Wil van der Aalst. Patterns-based evaluation of open source BPM systems: The cases of jBPM, OpenWFE, and Enhydra Shark. Information and Software Technology, 51(8):1187–1216, 2009.

[29] Wai Peng Wong. Business-process management: a proposed framework for future research. Total Quality Management & Business Excellence, 24(5-6): 719–732, 2013.