Agile Business Process Development: Why, How and When

The final version of this paper has been published by Springer in the journal of Information Systems and e-Business Management, DOI 10.1007/s10257-014-0256-1. The text is available online at http://link.springer.com/article/10.1007/s10257-014-0256-1

Copyright ©Springer-Verlag Berlin Heidelberg 2014

Agile Business Process Development: Why, How and When Applying Nonaka's theory of knowledge transformation to business process development

Ilia Bider1,2, Amin Jalali1 1DSV - Stockholm University, Stockholm, Sweden

2IbisSoft AB, Stockholm, Sweden ilia{dsv.su.se | ibissoft}.se, [email protected]

Abstract. The traditional way of business process development is via creating a detailed model of a business process in question, acquiring an IT-system to support it, and then implementing it in the organizational practice. Acquiring a system can be done via designing and manufacturing it by the business itself, or via commissioning it to somebody else. Alternatively, a generic system can be bought and configured according to the business process model created. The traditional approach has a number of risks that become visible only during the latest phase of introducing the system in the organizational practice, e.g., when it becomes clear that the system does not fit the business and/or people who work in it. These risks could be mitigated by using an agile approach to the development of business processes. In agile approach: (a) the phases of process modeling, IT-system design, and manufacturing are merged into one, and (b) instead of using one big cycle, a series of smaller development cycles is used. The paper discusses what is needed to implement the agile approach, and in which business situations the agile approach is the most appropriate. Examples of tools to support agile development are presented and analyzed. The results presented in the paper have been achieved based on the knowledge transformation perspective along the lines suggested by Nonaka in SECI model. The modification of this model has been used to understand the risks and requirements connected to a particular process development strategy.

Keywords: Agile development, Business Process, Knowledge transformation, SECI model

1 Introduction

Recently, agile business process development became one of the newest buzzwords in the domain of Business Process Management (BPM). Both practitioners and researchers give talks and write articles on the topic promoting their tools, methods and theories as facilitating agile business process development, e.g. (Thiemich & Puhlmann, 2013; Seethamraju & Seethamraju, 2009; Bider et al., 2010; Kindermann, 2013). Most probably, the idea of Agile Business Process Development (ABPD) was transferred to BPM from the software development, where agile software development became an established term and method of software development. The main principles of the agile software development are summarized in the so-called Manifesto for Agile Software Development (Fowler & Highsmith, 2001). Besides the manifesto, there is a large body of practical and research literature on agile software development, see for example (Shore & Warden, 2008).

In difference from agile software development, ABPD has neither manifesto, nor any other definition of what it is accepted by practitioners and/or researchers. It is not clear whether the two professionals talking or writing about ABPD really mean the same thing. In addition, it is not clear how the agile process development differs from the non-agile (i.e. traditional) one, what the advantages with the agile process development are, and when it should or should not be used.

The goal of this paper is three-fold; it is aimed to work out a theoretical platform that could help in (a) explaining the difference between the agile and non-agile business process development; (b) defining the requirements on the tool support for ABPD; (c) defining the area of applicability of ABPD.

While striving to attain these goals, the following tasks have been completed and reported in this paper:

2

1. Building models of both non-agile and agile business process development. Based on these models, we have analyzed the drawbacks, advantages and risks involved in each of the methods. Our findings have been validated through using them in the analysis of completed business process development projects, both non-agile and agile.

2. Compiling a list of BPM tools’ properties alongside with their values that would make a tool more suitable for ABPD. The properties are presented as a table to be filled for each of the tools considered when choosing tool support for APBD. The table was used for analysis of two candidate tools for APBD as partial validation of its usefulness.

3. Identifying two different business situations that require different approaches to process development: traditional development, and APBD.

The work has been inspired by our own experience of developing and introducing business process support systems in organizational practice, see for example, (Andersson et al., 2005). We wanted to understand why in some cases the introduction of a system and process created a major problem, while in others, it was done relatively easy. The first step was intuitive understanding that the difference lied in the level of agility of a project, i.e. the extent to which the system and the process were developed in parallel with introducing them in organizational practice. This understanding led us to look for a theoretical foundation that could help to explain the difference.

While searching for a known theory to explain the difference between agile and non-agile process development, we came across the work on Nonaka (Nonaka, 1994) on knowledge transformation in organizations that suggested a so-called SECI model, where SECI stays for Socialization – Externalization – Combination – Internalization. This model explains how the knowledge is transferred/and or converted inside and between two different forms – tacit (in the heads of people) and explicit (in the form of writings, drawings, mathematical models, etc.).

Applying the knowledge transformation perspective to business process development resulted in building two different models of knowledge transformation, one for traditional (non-agile) process development and the other one - for APBD. The first model got the name ECEA, which stays for Externalization – Combination – Embedment – Adoption. The second model got the name SEA, which stays for Socialization – Embedment – Adoption. To build these models, we introduced a new type of knowledge, absent in the SECI model, namely, embedded knowledge. The latter represents the knowledge that resides in a software system aimed to support the process under development. The idea of including the embedded knowledge in the cycle comes from the well-known “good regulator theorem” from (Conant & Ashby, 1970) that states: “Every good regulator of a system must be a model of that system”. Adding a new category of knowledge led us to add two additional knowledge transformation categories to adapt the SECI model to our needs. First transformation is from explicit knowledge to embedded one – Embedment, and the second transformation is from embedded knowledge to tacit knowledge – Adoption.

Having built ECEA and SEA models, we theoretically analyzed the risks of the traditional process development and showed how they can be minimized by employing the agile process development. This analysis then was applied to our own experience and revealed that the risks identified theoretically was not abstract but explicated themselves in the projects run according to ECEA model. Based on the analysis of SEA model, we also have been able to identify requirements on the tools to support ABPD. On a general abstract level, the requirements amount to having separation of different concerns/aspects of a business process so that one concern can be adjusted without affecting others. This is analogues to aspect-oriented programming (Kiczales et al., 1997).

In this paper, we present our findings according to the following plan. In section 2, we overview the existing literature to analyze what different authors understand by agile business process development,

Agile Process Development 3

and show that there is no common theoretical definition of the term. In Section 3, we overview our own experience that inspired us to search for the answers to the questions formulated above. In Section 4, we present our theoretical framework and analyze the risks with non-agile and agile process development. In Section 5, we apply the theoretical framework to our own experience, which constitutes the first step of validation of the usefulness of our theoretical framework. In Section 6, we discuss requirements on the tools to support ABPD and give examples of such tools. In Section 7, we discuss areas where ADBD is applicable. The latter is done based on our previous theoretical work (Bider et al., 2011). Section 8 summarizes the results and draws plans for the future.

2 Literature overview

In more than two decades of its existence, BPM worked out detail recommendations on how to design business processes and enact them in organizational practice. There is vast literature that concern standard cycle of business process development. For example, (Becker et al., 2011) gives a detailed overview of methods and tools for the process design that includes the following phases: modeling a process as-is; optimizing it through creating the model of a process to be; changing organizational structure; rolling the process out; introducing continues process improvement. This book also discusses the usage of technology in the business process development cycles, such as ERP systems, Workflow Management Systems (WfMS), process simulation tools. The view presented in (Becker et al., 2011) corresponds to other works devoted to process development. For example, (Weske, 2012) defines the BPM lifecycle as consisting of ‘Design and Analysis’, ‘Configuration’, ‘Enactment’ and ‘Evaluation’ phases.

Though the traditional approach to process development has its merits, it does not suit well all business environments, in particular, it may not be suitable for the environments with a high degree of dynamism. To deal with the dynamic and volatile environments, two interconnected but different directions appeared in the BPM research and practical literature. We refer to the first direction as to business process flexibility, and to the second one – as to agile business process development (ABPD). The process flexibility deals with the degree in which the instances/cases of the same process can deviate from each other. More flexibility means that process participants have more possibilities to take a decision on how to act in a specific process instance/case dependent on the fluctuations in the business environment. APBD deals with promptly changing the process design adapting it to more permanent changes in the business environment.

2.1 Business process flexibility

There are two diametrically opposing approaches to achieving required level of process flexibility/rigidness. The first one is to start with very flexible process and add restrictions; the second approach is to start with a rigid workflow process, and add flexibility to it. The first approach is pursued in Case Management (van der Aalst, 2005) and, especially, Adaptive Case Management (Swenson, 2010), as well as in our approach using the state-oriented view on business processes (Khomyakov & Bider, 2001; Bider & Striy, 2008). The second approach tries to augment the classical rigid workflow, so that it allows higher level of deviations for process instances. As the workflow is a predominant paradigm in BPM, the work on flexible workflows has received more attention from the research community. Therefore, below, we review some approaches to achieve process flexibility while remaining in the workflow paradigm.

The works aimed at supporting workflow flexibility can be divided into four different categories based on the completeness of process definition (partial or full) and the time of flexibility configuration (design or runtime) (Schonenberg et al., 2008). These flexibility types are named flexibility by design, underspecification (late binding and late modeling), deviation and change (see Fig. 1).

4

DesignChange

Deviation

UnderspecificationUnderspecification(Late binding) (Late modeling)

Run-timeDesign-time

Pa

rtia

lF

ull

Flexibility Configuration

Pro

cess

De

fin

itio

n C

om

ple

ten

ess

Figure 1. Taxonomy of process flexibility (Schonenberg et al., 2008)

Flexibility by design means the enumeration of all possible scenarios in the process model (full process definition) at the design time. The workflow patterns can be considered as one sort of this kind of flexibility (van der Aalst et al., 2003). The pros of this kind of flexibility are that the model contains all solutions for different scenarios, but the cons are that the model can be very complex, and the whole BPM-lifecycle should be repeated for any change in the process definition.

Flexibility by underspecification proposes to separate the definition of flexible points from the process models by defining a placeholder for those points. The specification of the placeholders can be defined at design time or runtime, called late binding and late modeling respectively. In late binding, the definition of placeholder can be bound or changed at runtime. In late modeling, both the definition of placeholder and the binding are done at runtime. Worklet Selection Service (Adams et al., 2005) is an example of a service which enables this kind of flexibility in the WfMS tool called YAWL (YAWL Foundation, 2004), where YAWL stays for Yet Another Workflow Language.

Flexibility by deviation aims at supporting arbitrary deviations in the process execution. It is suitable for situations in which the points where flexibility is needed are not known beforehand; thus, the process specification can be considered as complete. This kind of flexibility allows the process to deviate from the normal path at runtime at any point. The support of exception handling in YAWL is an example of flexibility by deviation (Adams et al., 2005). Although flexibility by deviation, such as exception handling, adds some flexibility to process models, it is not suitable when the deviations happen often. The deviations that happen often should be considered as a norm in the main process, and thus included in the process model.

Flexibility by change proposes to change the specification of a process instance or the process model at runtime. In this way, the processes can be adapted to changes at runtime. However, such approach required migration of process instance from one specification to another, which is a task that so far does not have a generic solution.

The flexibility types discussed above can be combined to cover complex situations, as suggested in the concept of Flexibility as a Service in (van der Aalst et al., 2009). A more radical way of achieving flexibility is implemented in Declare Service (Pesic et al., 2007) that uses a declarative way of defining process models. The model in Declare is defined as a set of constraints that specify the relations between activities in the process being supported. A constraint can specify a prohibition e.g. what activity should not take place if the other one has been completed, or obligation, e.g. if a particular activity has been


completed, the other one should exactly follow after it. If too many constraints are defined, the process would be rigid; very few constraints give flexibility for completing activities in any order. The latter suits well the knowledge-intensive business processes where people can decide the order of activities in the process on the fly (i.e. at runtime).

2.2 Agile business process development

As it was mentioned in the beginning of Section 2, agile business process development (ABPD) is related to adaptation of processes to more permanent changes in the business environment. Therefore, APBD belongs to the more general domain of enterprise agility. Enterprise agility is understood as a property of an enterprise to function in the highly dynamic world (Sherehiy et al., 2007). The agility concerns both being able to adjust to the changes in the surrounding environment, and discovering new opportunities constantly appearing in the dynamic world for launching completely new products/services. Becoming agile requires setting a structure that allows discovering changes and opportunities as soon as possible and react on them appropriately.

The largest body of practical and research literature that is devoted to agility belongs to Agile Software Development (ASD) that appeared as a reaction on the increasing rate of changes in system requirements, see, for example, (Highsmith et al., 2000): “requirements change at rates that swamp traditional methods”. Though there are numerous books and articles on ASD, e.g. (Shore & Warden, 2008) there is no complete agreement on the definition of what ASD is. The main problem here is that the essence of ASD is sometimes mixed with particular project methodologies, like SCRUM, that could be used in both agile and non-agile software projects. Currently, the only definition of ASD on which there is a common agreement, is the so-called agile manifesto (Fowler & Highsmith, 2001). The weak side of the manifesto is that it does not have an underlying scientific theory, but consists of a number of principles that allow different interpretations. For example, (Conboy & Fitzgerald, 2004a; Conboy & Fitzgerald, 2004b) considers the lack of theory and philosophy behind Agile Manifesto as a root of misunderstanding of agility not only in software development, but also in other related disciplines, e.g., Information Systems (IS). Their consideration is a result of reviewing agility in many disciplines. They also claim that the lack of considering agility outside the software development makes this manifesto not generally accepted by the wider audience.

In BPM research literature, we can track the same kind of confusion of what agility means, as in ASD. For example, the term ‘’agile’’ is widely used in BPM area as a synonym for flexibility (from section 2.1), see, for example, (Markovic & Pereira, 2008; Rosemann et al., 2008). This is one of the confusions that (Conboy & Fitzgerald, 2004a; Conboy & Fitzgerald, 2004b) mentions, and other authors describe in connection to BPM, e.g. (Gong & Janssen, 2011). As the result of the existing confusion, there is no commonly accepted definition of agility in BPM. At the same time, various researchers try to make the concept of agility in BPM more precise through underlining different aspects of agility, e.g., through:

• proposing methods of evaluation of agility in a manufacturing process (Meade & Sarkis, 2010), • measuring the impact of the enterprise systems on business process agility (Seethamraju &

Seethamraju, 2009), • proposing a conceptual model to refine what agility means in BPM (Raschke & David, 2005).

Furthermore, according to (Bruno et al., 2011), enabling agile BPM requires a paradigmatic change in BPM lifecycle. A new cycle should provide (a) effective knowledge sharing and (b) new kind of engineering, execution and management of processes. To achieve the shift, (Thiemich & Puhlmann, 2013)

6

proposes merging modeling and implementation phases of BPM Lifecycle in order to support agility better, while (Bruno et al., 2011) proposes an approach to achieve agility through using social software.

2.3 Summary of the literature overview

Summarizing the literature overview in Sections 2.1, 2.2 we can conclude that:

1. There are two interconnected but distinct areas of dealing with uncertainty and dynamic business environment in BPM: one concerns allowing deviation of process instances; the other concerns changing processes to adapt them to changing business environment. While the first area has a substantial body of research literature, the second area is, for the time being, less developed.

2. In research and practical literature, there is no clear separation between the above two concerns. To have a clear view on agility in BPM, there is a need to separate different concerns of dealing with the dynamic environment. Best of all would be that different terms are used for these two concerns. We consider that already well-established term business process flexibility is sufficient for referring to the degree of deviation in process instances, and suggest using term agility only in connection with process development/adaptation. This would be more in line with other areas where the term agility is used, e.g. agile software development (ASD). In this paper, we consider only agility in business process development, leaving flexibility of processes themselves outside the scope of consideration. Actually, these two concepts are more or less orthogonal, e.g., the agile business process development (ABPD) can be used for development of flexible as well as rigid processes.

3. Though ASD and ABPD have much in common, they are not identical. As ABPD includes developing or adjusting a Business Process Support (BPS) system, using ASD for development of this system can be, at least partially, considered as part of APBD. However, as BPS systems are a special class of software systems, there is a possibility to define ABPD in a stricter way than ASD, which is a methodology for development of any kind of software systems.

4. As far as agile process development is concerned, there are some interesting ideas in the literature on the paradigm shift that requires new business process management lifecycle. However, there is a lack of theoretical models that could be used to underpin such a cycle and show how it differs from the traditional one. Our paper is aimed at closing this gap.

3 Overview of own experience

As it was pointed out in the introduction, the research reported in this paper was inspired by our own experience that concerned building software systems/services to support business processes and introducing them in organizational practice. The experience was obtained in a number of projects that started from business process mapping and ended with a system introduced in practice of several organizations. The analysis of our experience in this paper does not concern the principles on which processes and systems have been designed, but on the cycle of the process and system development. In this section, we will present two different approaches used in our practice: the first one is a traditional approach, while the second one could be considered as an agile approach.

The traditional approach that we followed consisted in the following steps (a) building a relatively detailed business process model via facilitating workshops, (b) designing and "manufacturing" a support system using the model as a requirement specification, and (c) introducing the system into the organizational practice. In the agile approach, the phase of detailed process modeling has been skipped in


favor of directly developing a system and letting the users to test it in their practice. In the subsections below we present examples of application of these two approaches in our practice.

3.1 Traditional business process development – a case from a nonprofit organization

The biggest project in which our team1 was engaged when using the traditional scheme was process-orientation of a regional office of a non-profit interest organization called the Association of Tenants, Region West Sweden (in Swedish: Hyresgästföreningen, Region Västra Sverige) and abbreviated to HGF. The organization unites more than 60 000 tenants and the purpose of the regional office, which has about 60 employees, is to guard the interests of its members. This is done in a number of areas, such as giving legal and practical advice to its members, conducting rent negotiation on behalf of its members, and lobbying.

The project called ProBis was initiated in 2002 after a successful implementation into HGF's organizational practice of a system called ReKo (Andersson et al., 2002) that supported recruiting activities in the organization. The ProBis project was ambitious and affected several key HGF processes, such as processing feedback from their local offices, support for these offices, and lobbying. Expectations were high, mainly due to the success of ProBis's predecessor ReKo that helped the organization in making recruiting new members more efficient.

Process development and introduction of a support system into the organizational practice in the ProBis project, more or less, followed the standard practice of process and support system development. Before the system development started, we conducted a number of business process analysis projects at the main office of Association of Tenants in West Sweden. The processes analyzed included services (e.g., advice, conflict management) provided by the main office to their field (grass root) organizations, processing of feedback (e.g., complaints), lobbying (i.e., influencing the decisions of others), and some others. The business process analysis projects were conducted via facilitating workshops with process participants; at least three workshops were conducted for each process. The format of these projects is described in more details in (Andersson et al., 2002; Perjons et al., 2007).

Besides a report that included a business process model, each process analysis project delivered a simulation of the process done with the help of a specially developed tool ProVis (Process Visualizer). A screen dump from this tool related to the project is presented in Fig. 2. Simulation was done based on examples from the experience of the participants provided by them. The purpose of simulation was twofold:

• Verify that the process model created in the project covered real-life examples from the participants' practice. The simulation was completed iteratively along with process modeling. As soon as simulation showed that the model was not adequate in regard to the examples provided by the participants, the model had been corrected.

• Give future users understanding of what a system supporting the given process would look like.

Process participants were the only source of information in the analysis projects. As the analysts were not experts in the business activities of HGF, they had not much influence on defining how processes are (or should be) run; they were responsible only for designing the process model according to the information received. Participants of each project agreed that the model developed correctly represented the activities in their business.

After all analysis, projects had been completed, we got a commission to develop a system using the analysis project reports and simulation results as systems requirements. The support system, also called 1 This case comes from the experience of the first author.

8

ProBis (Andersson et al., 2005), was developed and delivered in a module-by-module fashion, where each module was responsible for a particular process or group of processes. Modularization was envisaged to make the introduction easier. All modules were built on the same principles and shared a common user interface. We believed that by the time the next module was introduced, the users would already know how to deal with the system by learning the previous module. However, this intention never materialized, as the introduction process was not well planned. After initial training, the end-users were simply asked to use the system. The result of such a simplified introduction process was negative, i.e., very few actually used the system. An investigation was conducted on the causes of failure, which resulted in a critique of the usability of the system, i.e., the system design was not sufficiently intuitive and user-friendly.

Figure 2. Screen dump from process visualizer for one of ProBis processes

After this discovery, the user interface of the system was completely redesigned, and the users were once more invited to use the system. The result was negative this time as well, i.e., very few used the system. However, nobody was criticizing the system usability any longer. The situation was plainly explained by a statement from one of the supposed users: “I am sure the system is very good, but I do not know what I should use it for”. As nobody was blaming the system itself, the attention of our group was moved to search for the reasons of failure elsewhere, namely in the quality of the introduction process. Our research on this issue resulted in a general framework, called A3, supporting the introduction of IT systems into organizational practice (Bider et al., 2012). This framework was accepted by the management


and partly implemented. ProBis has been eventually introduced in the organization. The scope of its use, however, has never reached the intended level.

Despite the delays and the level of usage below than expected, the ProBis system, which was set into operation in October 2004, continues to be in operation up to the moment of writing. This is despite the fact that we discontinued our support for the product in 2010. On 31 of May 2012, the ProBis database contained 1686 completed process instances and 783 active ones (some of the latter were completed but not archived). The database also contained 6148 documents, 393 organizations, 1528 contact persons, and 18193 events registered for all processes2.

ProBis system development was completed with the help of a home-made high level tool which increased productivity and made it easier introducing changes. This tool, however, was designed for people with technical skills. Staff at HGF did not have enough competence to use this tool, thus all changes in the process and system was done by the system vendor.

3.2 Traditional business process development – a case from a bank

This section reports on a failure of a BPM project in a bank3, in which the traditional BPM lifecycle was employed. The bank outsourced the project of developing a system to support all processes in International Division to an IT company. The project included 17 sub-projects, such as “Letter of Credit (LC) Management”, “Treasury Management”, “SWIFT Management”, etc. Each of sub-projects dealt with a number of business processes. The project started with three main work streams namely “Business Vision”, “Current State Business Process”, and “Current State Technology”.

Business Vision was aimed at: (1) documenting division’s business vision and strategy; (2) understanding business needs. Current State Business Process was aimed at: (1) documenting, at a high-level, existing banking processes; (2) discovering new potential processes and refining the existing ones. Current State Technology was aimed at: (1) gathering information, understanding and documenting the existing technology architecture; (2) reviewing all relevant Lines of Business and functional areas from the viewpoint of the current technology; (3) identifying capabilities, strengths, weaknesses, risks, and limitations; (4) assessing the quality of the existing applications, technology and related operations as well as systems development processes and methodologies.

After finishing the work streams above, three other work streams were defined, namely: “Document Gaps”, “To-Be Technology”, and “Prioritization & Option Development”. After their completion, the project manager chose business processes for further development according to the prioritization table and availability of resources.

The process development was conducted in cycles that included: (1) studying current documents and performing initial interviews; (2) designing process models; (3) analysis; (4) implementation; (5) configuration; (6) pilot execution; (7) diagnosis of the results. When the system development was finished, the delivery team released the sub-project results to be employed by customers.

The process development cycles, though formally well-organized, showed to be problematic. At the beginning of the process development, both stakeholders and IT staff agreed on how each process should look like and what requirements and goals it should cover. The IT staff had also access to all documents which were obtained during the previous phases of the cycle. The design, analysis, implementations were conducted by IT without interaction with the stakeholders. The problem appeared during the pilot execution. Stakeholders blamed the IT staff for misunderstanding requirements, and rejected the process implementation. There were many iterations for each process model, and the project was over budget. 2 The data above were derived from ProBis system logs on 31 of May 2012. 3 This case comes from the experience of the second author.

10

Finally, the bank management decided to discontinue the project since it was impossible to estimate how long it would take to finish it successfully.

3.3 Agile process development – a case from a municipality

Our experience with agile process development started with a project of implementing a so-called BBiC process in the social office of the municipality of Jönköping (Sweden)4. BBiC stands for Child Needs in Center (“Barnens Behov i Centrum” in Swedish) and deals with investigation, decision making, and following up decisions in cases of suspected child abuse, or families that cannot take care of their children. The guidelines for this process were drawn by the National Board of Health and Welfare, and they were strongly recommended for Swedish municipalities to follow. As the process had already been defined, the project concerned only its organizational implementation, which included developing a system to support it.

Having been invited to participate in the project as a system vendor, we decided not to start with developing a system to support the BBiC process, but develop a tool that would allow to relatively quickly configure such a system, as well as any other system of the same kind. One of the main requirements on the tool was that a person with knowledge in the domain and with the minimum of technical knowledge could use it for configuring support for a new business process. The development started in 2007 and resulted in creating a tool called iPB (Bider et al., 2010), which is now in its 6.0 edition5. In this project, BBiC process has served and continues to serve as a pilot for the tool development. The BBiC process went through several major revisions after the first introduction, where the complexity of the process map had been gradually increased. Currently, there are approximately 266 active participants in the BBiC process, including 80% of heavy users who work with the BPS system on a daily basis, and 20% of occasional users who work with it rarely and complete only few operations.

Our role in this project was more technical in comparison with the ProBis project, where we had carried out complete analysis of HGF's business processes. In this project, we only provided a tool that facilitated the customer's own staff to build a system to support the BBiC process. This was done by one person, who continues to develop the BBiC system having constant second-tier support from us. The person is a professional in the domain who has acquired some technical knowledge to become a go-between between technical and business people.

Besides completing the BBiC project without major problems, the municipality of Jönköping got in their possession a tool that allowed them to restructure about a dozen of other processes. This has been and is being done by the system administrator working in the following manner. When discovering needs for introducing a structured process supported by an IT-system, he:

1. Discusses the needs with the staff.

2. Drafts the system directly in iPB, foregoing any formal modeling.

3. Presents the system to the group of future users and gather their comments.

4. Introduces changes and shows the draft again (steps 3, 4 can be repeated several times).

5. Sets the system in operation (after its acceptance).

4 This case comes from the experience of the first author. 5 In this section we do not provide the description of iPB which is done in Section 6. The main focus in this section is

on how iPB is being used in the process and system development.


6. Makes constant revisions based on the actual usage of the system without arranging any extensive projects on process reengineering. Some of these revisions are due to the changes in the process, others due to the new possibilities introduced in the next version of iPB.

4 Building a theoretical framework

When looking for sources that could be relevant for building a theory that could explain our experience, we considered that the knowledge perspective was of special interest for our endeavor. The idea is in line with the opinion of other researchers, see, for example, (Bruno et al., 2011) that considers knowledge sharing as an important component of agility. We found the following two theoretical ideas, especially useful for our theory building

• SECI model of Nonaka (Nonaka, 1994), and • Good regulator theorem of Conant and Ashby (Conant & Ashby, 1970).

The SECI model, where SECI stays for Socialization – Externalization – Combination – Internalization, by Nonaka (Nonaka, 1994) explains the ways of how knowledge is created in an organization while being transformed from the tacit form (in the heads of the people using it) to the explicit one (on the paper or in the computer) and back, see Fig. 3 that describes the cycle of knowledge creation as consisting of four steps or phases:

• The cycle starts with Socialization (left top corner of Fig. 3), where tacit knowledge is transferred from the heads of one group of people to others via informal means, conversations during the coffee breaks, meetings, observations, working together, etc.

• The next phase is Externalization, which is the conversion of knowledge from the tacit form into the explicit one, e.g. a model of the situation at hand (right top corner of Fig. 3).

• The third phase is Combination, which is transforming the externalized (explicit) knowledge in a new form using existing knowledge, e.g. known design principles (right bottom corner of Fig. 3).

• The last phase is Internalization, which is converting the explicit knowledge, e.g. a solution, in the tacit knowledge of people that are ready to apply this knowledge to any situation that warrants it (left bottom corner of Fig. 3).

The cycle of SECI can be repeated indefinitely reflecting constant creation of new knowledge.

Figure 3. SECI diagram, adapted from (Gram Consulting, 2009).

Socialization Externalization

Internaliztion Combination

Tacit Knowledge

Explicit Knowledge

Tacit Knowledge

Explicit Knowledge

Exp

licit Kn

ow

led

ge

Exp

licit K

no

wle

dg

eTa

cit

Kn

ow

led

ge

Ta

cit

Kn

ow

led

ge

Spiral of Knowledge Creation

12

In the current business environment, where computers play an increasing role in running business processes, differentiating only two types of knowledge – tacit and explicit – is not sufficient. We need to consider the knowledge built into the computer system(s) that supports and/or (at least partly) controls the processes. This knowledge cannot be regarded as explicit as people using the system may not know how it works internally. This knowledge cannot be called tacit as it belongs to the system not to the human beings (unless we consider the system being an agent comparable with the human being). We refer to the knowledge built into the system as to embedded knowledge. The existence of the embedded knowledge is supported by Conant and Ashby theorem (Conant & Ashby, 1970) that “every good regulator of a system must be a model of that system”. The theorem can be applied to other areas as well, as in (Scholten, 2010) :

• A good solution is a model of the problem it solves. • A good key is a model of the lock it opens.

Using the same analogy, we can reformulate (specialize) the Conant and Ashby theorem as

“A good business process support system is a model of the process it supports”

The latter stresses the importance of creating a good system that embeds (or is) the model of the process, independently whether the model exists in its explicit form, e.g., as a flowchart diagram on the paper.

Adding an additional category of knowledge allowed us to apply the ideas from (Nonaka, 1994) to the cycle of business process development, both in its traditional and agile forms. As the result, we got the models of these cycles that are presented in section 4.1 and 4.2 below, followed by their analysis in Section 4.3. When designing the models, we considered only the modern way of business process development, the one that includes employing IT systems to help running the processes. The process development where the processes run manually remains outside the scope of this research.

4.1 Knowledge transformation in the traditional business process development

Applying Nonaka’s ideas to knowledge transformation during the traditional cycle of business process development, we have got a model in Fig 3. The model is abbreviated to ECEA, which stays for Externalization-Combination-Embedment-Adoption. The cycle starts with tacit knowledge in the heads of the stakeholders on the needs to introduce a new structured business process or to change an already existing one. The cycle consists of four phases:

• Phase 1 – business process identification and modeling - consists of transforming tacit knowledge possessed by current or future process participants into explicit knowledge of the business process model/map/description (right top corner of Fig. 4). This phase corresponds to Externalization from SECI model. The conversion is usually done via facilitating workshops where specialists in BPM works together with business people who participate in the process that is going to be changed/reengineered, or who will be participating in a new process to be introduced. The business people have tacit knowledge on the process, its context, and business needs; the BPM specialists help to convert this knowledge into a model or structured description.

• Phase 2 – support system design – consists of transforming explicit knowledge of the process model to explicit knowledge of BPS system design (right bottom corner of Fig. 4). This phase corresponds to Combination of SECI model. The conversion is done by applying contemporary or innovative design principles to the model in order to produce design documents, e.g. class diagrams which can be then converted to a support system.

• Phase 3 – support system manufacturing consists of transforming the explicit knowledge of system design to the knowledge embedded in the system (left bottom corner in Fig. 4). Though parallel to


Internalization from SECI model, this phase does not correspond to the latter exactly. We call this transformation Embedment. For programmers engaged in this activity, this transformation is from one form of explicit knowledge to another (program code). However, for the end users, the knowledge built within the system is not explicit. The conversion is done using contemporary or innovative methods of programming, e.g. object-oriented programming.

• Phase 4 – learning to use in own practice – consists of transforming embedded in the system knowledge into the tacit knowledge of how to use it (left top corner in Fig. 4). Though parallel to Socialization from Fig. 3, this phase does not correspond to the latter exactly. We call this transformation Adoption. Learning how to use the system in own practice is done, more or less, using the try and error method, which does not exclude training sessions.

Note that the cycle above is an idealization. For example, parallel to Embedment there might be additional knowledge transformations:

• Writing manuals, which is converting embedded knowledge into the explicit one, and • Reading manuals, which is converting explicit knowledge from the manuals into the tacit one.

However, these two transformations are losing their importance as the contemporary users learn new systems in the try and error fashion. In our experience of the ProBis project, the manuals were requested but never read when delivered.

As with the SECI model, the cycle of Fig. 4 can be repeated as soon as there are needs to change the process and/or the system, e.g. in order to optimize it.

4.2 Knowledge transformation in the agile process development

Applying Nonaka’s ideas to knowledge transformation during the agile cycle of business process development from Section 3.2, we have got a model in Fig 4. The model is abbreviated to SEA, which stays for Socialization-Embedment-Adoption. The SEA cycle differs from ECEA cycle in three respects:

Figure 4. ECEA - Knowledge transformation in the traditional process development

14

• In this cycle, process modeling, system design and manufacturing are merged into one phase Support system manufacturing (Embedment).

• The nature of the first phase in Fig. 5 is changed against Fig. 4. It consists in transferring tacit knowledge on the desired process from the stakeholders to the design team. This phase corresponds to Socialization in Fig. 3.

• In addition, one big cycle is substituted by many smaller and shorter ones. The system is built iteratively starting with the basic functionality that does not limit flexibility of process participants to experiment with the new process. During the usage of the basic system, better understanding of the needs is acquired, which is converted in adding details to the system in the next cycle.

The ECA cycle reflects the desire to exclude as much as possible converting the knowledge into the explicit form. This is because in the end, we need knowledge in the embedded (system) and tacit (people) form. As with ECEA, the SEA model is an idealization. During both Socialization and Embedment, some knowledge is transferred into the explicit form, e.g., simple flowcharts drawn on the paper, or on the black/white board. This, however, is done in order to facilitate the tacit knowledge transfer from one group of people to another, or into the system. Therefore, the aim of using explicit knowledge in Socialization from Fig. 5 is different from the one of Externalization of Fig. 4, in which the whole phase is directed at building a detailed process model of the business process at hand before going further with Combination and Embedment.

4.3 Using ECEA and SEA models for analysis of traditional and agile process development

In this section, we use the ECEA, and SEA models to analyze strengths and weaknesses of the traditional and agile approaches to business process development. We start with analyzing risks inherent to the traditional process development. As the ECEA cycle consists of four types of “heavy-weight” knowledge transformations, there is a risk that some or all of them can include errors that could have accumulative effect at the last phase. More exactly, the following risks can be identified for each of the four phases:

1. Risks with Externalization. The process model does not capture the tacitly understood needs properly. Usually, the result of this phase is a detailed process model/map expressed in some business process

Figure 5. SEA - Knowledge transformation in the agile process development

Modeling + Design + Manufacturing


modeling language, e.g., BPMN (OMG, 2011). A typical way of building the model is through facilitating workshops with the stakeholders - business people engaged or to be engaged in the process. Verification is done by the stakeholders agreeing that the model expresses their view on the process and business needs. In many cases, stakeholders are not technical, but business people, who find it difficult to understand all details of a complex model in a technical notation. As the result, they may miss omissions and wrongly captured details. In addition, some less often encountered situations may not be captured at all, which results in the model being incomplete.

2. Risks with Combination. The process model is not converted into a proper system design. This, for example, may happen when choosing the type of user interface that is not suitable for the given group of systems users.

3. Risks with Embedment. The system manufacturing does not follow the system design. This can happen when the design documents allow different interpretations, but can also happen when the suggested design solutions are difficult to implement with the programming languages and tools chosen.

4. The BPS system is not properly understood by its users and is rejected or used in an inappropriate way. This can happen because of no or unqualified training, or training given at a wrong time. It can also be that the users used the try and error approach and fail to understand the system.

The four risks above are connected to knowledge transformation. In principle, they can be mitigated by employing exceptionally qualified business process engineers, developers, programmers, and trainers. These, however, may not always be available, and even when they are available, the transformation risks above can never be totally eliminated.

Besides the risks connected to knowledge transformation, there is another risk in today's highly dynamic business environment, namely:

5. While a new process and a corresponding system are being developed, problems and needs continue to evolve. As the result, the process and the system could be outdated before they are implemented in practice. This risk is directly connected to the desire to develop the process in one go including all small details.

It is difficult to mitigate the last risk while remaining inside the traditional development cycle. One way to shorten the cycle is via buying some off-the-shelf BPS system on the market instead of developing own BPS system, e.g. a CRM system, and then configuring it for own needs. This solution, however, has its weaknesses, namely, instead of developing a process and a system that satisfies the current business needs, the organization might end up with adjusting itself to the process embedded in the acquired system.

In difference from one big cycle of ECEA, the SEA model suggests multiple short cycles. Therefore, abandoning the traditional process development in favor of the agile one can be considered as a way of mitigating the last risk (to be outdated). The risks of introducing errors in transformation phases continue to exist even in the SEA cycle. However, due to the smaller new portions introduced in each cycle, it is easier to deal with them by making correction in the next cycle. The main risk with SEA model is the following:

1. Failure to make the cycle short due to the following two reasons:

a. It is impossible to limit the functionality of the support system while making it useful for running the processes. An example of such a situation can be when a new system needs to be integrated with a number of existing systems and there is no proper API for them and no tool that could help the integration.

16

b. Embedment itself takes too much time, even when the functionality is limited.

While it might be difficult to mitigate the risk attached to 1a, it is fully possible to deal with the risk attached to 1b. When combining modeling, design and manufacturing in one phase, we cannot continue to use traditional programming languages, e.g. Java, for system development. A high-level system development tool is required for having a possibility to complete system manufacturing in an acceptable time frame. Requirements on such a tool are discussed in Section 6.

Besides the risks connected to the failure of shortening the cycle, the SEA model has another drawback:

2. Not having a process model in an explicit form hinders application of known methods for process analysis such as validation, verification and performance analysis (van der Aalst, 1998), which facilitates process improvement.

While the issues listed above might not be of importance in the first iterations of SEA, they may become important later. When the needs for checking correctness, simulation, or optimization arise, an explicit model is to be built, e.g. by reverse engineering of the system. The time needed for this operation could be minimized if the tool used for system development employs some kind of executable process model. This will be of help even if such a model is simplified and does not include all details due to the details being implemented in the system in an ad-hoc fashion, e.g. as hook functions. In a case when a model is present, it can be extracted and extended based on the standard business process analysis, or reverse engineering from the system and/or its logs as in process mining (van der Aalst & Weijters, 2004).

Note that the drawbacks of SEA discussed above limit the area of its applicability, and thus agile business process development. This issue is discussed in more details in Section 7.

5 Validation - analysis of our experience

To validate the usefulness6 of the models described in the previous section, we applied the analysis from section 4.3 to our experience, which was summarized in section 3. As far as traditional process development is concerned, all five types of risks uncovered in section 4.3 have been fully realized in the ProBis project (see Section 2.1). More exactly:

1. The process models created during the process analysis projects were too complex for serving as requirements for the first version of the system. Though the users who participated in building the models confirmed their correctness based on simulation results, they could not imagine what it would mean to work according to them. As a result, Externalization phase from Fig. 4 produced inadequate models/requirements for system design. The main problem here was over-structuring the data processed in the frame of process instances. We were forced to simplify the structure considerably in order to introduce the support system into organizational practice. More details on the issue see in (Andersson et al., 2005).

2. Based on our previous experience, the system design was completed based on the assumption that the users would be prepared to learn the logic behind the system. As the result, not enough efforts had been invested in making the user interface intuitive, which created considerable problems during the Adoption phase of the ECEA cycle (“Learning to use in own practice”). Though the user interface was eventually completely revised, some problems remained, especially for the occasional users.

3. Though we did not strictly differentiate design and programming, some problems were introduced due to the limitation of the tools we employed for system manufacturing. The tools supported multi-

6 Here, we follow the idea of (Box & Draper, 1987), p.424: “Essentially, all models are wrong, but some are useful"

considering that that showing the usefulness for practical purposes as the best way to validate a model.


windows interface, which would be a perfect choice for an IT-professional, but showed to be a hinder for business users, especially for occasional ones. For our business users, a browser-like one window interface showed to be a much better choice, especially when complemented with an option of having multiple windows. This drawback was fixed in the second revision of the system. However, not doing the right implementation choice from the beginning added additional problems in the Adoption phase (see below).

4. Poor understanding of the amount of effort required for completing the last phase (Adoption) resulted in an inadequate plan being devised for the system introduction into organizational practice. The users got training too early in the cycle, and by the time they needed to start using the system, they forgot everything they had learned. Besides, accumulation of the not so optimal decisions introduced in the previous phases made the task practically impossible. To cope with the problem, the user interface was completely revised (Andersson et al., 2005), and a new method of system introduction into organizational practice was developed and used (Bider et al., 2012).

5. The delivery time of the system was quite long, and the internal environment changed before the system was introduced in practice. For example, some of the people who participated in the business process analysis left, and new people were hired, which made Adoption phase more difficult. In addition, the nature of some processes changed so that the models built no longer corresponded to the reality.

For the banking case described in section 3.2, the major reason for the project failure was the errors introduced in the Externalization phase of the traditional cycle of Fig. 4. This was because of misunderstanding between business and IT people. Relying on complex technical notations for process modeling contributed to this misunderstanding.

As far as the example of agile development described in Section 3.3 is concerned, so far, we have not experienced any major problems. The cycles were made short due to the usage of the high-level system development tool iPB. As far as the drawback of not having an explicit process model is concerned, up to now, the issues of simulation, correctness and optimization have not been raised in the projects of which we are aware.

6 Tool support for agile process development

6.1 Requirements on tools support

As it has been discussed in Section 4.3, it is impossible to use the agile SEA cycle without having a proper high-level tool for system development. The tool is needed to ensure short development time in each iterative cycle. From this objective, we can derive two main requirements on the tool:

1. The tool should facilitate creating a first version of the system in a shortest possible time. The first version may have the minimum functionality, but should still be considered useful by its users for running business process instances.

2. Changes that are to be introduced in the later iteration cycles should not require complete redesign of the system. This is especially important for the later iteration cycles when the system may become quite complex.

The fulfillment of the first requirement depends on the nature of the process to be supported. For the processes that require a strict order of activities, a tool based on the workflow thinking may suit well; for other types of processes, a tool designed for Case Management (van der Aalst, 2005) or adaptive case management (Swenson, 2010) could be more suitable than a WfMS tool.

18

The second requirement is aimed at insuring that changes made in the later iterations will not totally destabilize the system. This goal can be attained by separation different concerns/aspects as suggested in Aspect Oriented System Development (Kiczales et al., 1997). There are multiple concerns that can be differentiated in relation to business processes. To the most important ones belong differentiating:

a) What – goals/sub-goals to be achieved.

b) How – actions to be undertaken for achieving the goals.

Traditional workflow management systems (WfMS) do not separate what and how as they define a process as a sequence of activities that follow each other. The tools that are aimed at controlling flexible processes introduce some means to separate these two concerns through the usage of underspecified tasks or worklets (Adams et al., 2005), see also the discussion in Section 2.1. In terms of what/how, a worklet is used to specify what (the goal or sub-goal), and a workflow that realizes it - the how.

c) In what order – order in which goals should be achieved and action taken.

Traditional WfMS do not separate the order from the goals and tasks which increases the complexity of the task of changing the order. This aspect is better separated in the declarative workflows, see, for example, (Pesic et al., 2007).

d) Data involved – what data should be acquired/processed in order to reach a goal, or complete an action.

e) By whom – who is obliged/allowed to complete action access or change data or take other decisions if the frame of a process instance.

f) Modality – whether a rule of any kind, e.g. particular order of activities, is mandatory or optional.

One way of expressing modality is through using the ideas of deontic logic as suggested in (Bider & Striy, 2008). Modality is expressed by four categories that can be assigned to a rule: obligation, recommendation, negative recommendation and prohibition. Changing modality of a rule from obligation to recommendation, or from prohibition to negative recommendation will increase the flexibility of the process, changes in the opposite direction will make the process more rigid.

To satisfy the second requirement, i.e., minimizing the number of changes in each iteration, a tool should facilitate system architecture where the above concerns are separated so that changes in one of them do not require major changes in others.

Besides the two requirements above that are a must, other requirements can be added to the list. In particular, it could be reasonable to add the following two requirements:

1. The tool can be managed by a specialist in the application domain who has some technical knowledge. This will minimize the needs to involve technical staff without domain knowledge, which will require extra efforts for tacit knowledge transfer at the Socialization phase. This does not exclude the domain specialist having support from a tool specialist assisting him/her.

2. The tool is built based on the idea of executable business process modeling (Kueng & Kawalek, 1997) . This means that the developer building a system creates some kind of a process model, and the system interprets it at runtime. The model does not need to cover the whole system; some parts of it could still be programmed in the ad-hoc manner. The developers do not need to consider themselves building the model while creating the system; the model can be hidden behind the scene, but could be easily explicated. Moreover, the model does not need to be a workflow model, but can be defined based on


other views on business processes, e.g., on the state-oriented view (Khomyakov & Bider, 2001). The explicit model can help to avoid the second drawback inherent to the agile SEA cycle as discussed in Section 4.3.

Summarizing the discussion above, we created a template to be used for assessing suitability of tools for agile business process development presented in Table 1. The table represents a preliminary suggestion and needs to be validated by other specialists in business process development, tested in practice and improved. As the first test, in the next subsections we described and asses two candidate tools for agile process development. The first tool has already been used in practice; the other one is a suggestion on adding functionality to an already existing tool for making it more suitable for agile process development.

Table 1. A template for tool assessment

Features

Level of support, or separation, e.g. full, partial, limited, none

Comments

1. Creating the first version of a system in the shortest possible time

2. Separation of concerns to insure easiness of making changes

a What b How c In what order d Data e By whom f Changing modality g Separation of other concerns,

e.g. security

3. Usability for non-technical people 4. Having an executable model

6.2 iPB – a tool based on shared spaces

As the first example, we consider iPB (Bider et al., 2010; IbisSoft, 2009) that was used in the BBiC project described in Section 3.2. iBP has been built based on the state-oriented view on business processes, see (Bider et al., 2010), though its users do not need to have any knowledge on the theory behind the tool.

From the architectural point of view, iPB is based on the concept of “construction site” information logistics, and it employs shared spaces to facilitate communication and information exchange between the process participants (Bider et al., 2010). An iPB application has no explicit data/information flow. A shared information space is created for each process instance/case to hold all information that is relevant to the process instance, e.g., documents received and sent, information on tasks planned and completed, reports on results achieved when completing these tasks, etc. All this information is easily available each time a process participant is invited to visit this space and complete some task related to it. A shared space is similar to a construction site where different kinds of workers are invited to complete their own tasks and leave the rest to the others.

The functioning of an iPB application can be described in the following way:

20

• When a new process instance/case starts, a new shared space is created. It gets a unique name, an owner (responsible for the case), and possibly, a case team.

• When the process instance reaches its operational goal, the shared space is closed (sealed), but remains accessible for reading (a case goes to the archive).

• A person who is assigned a task in the frame of the process case “goes” to this case’s shared space to get information he/she needs for completing the task and reports the results achieved in the same space.

The components of iBP are presented in Fig. 6, see also (IbisSoft, 2009). There are two main parts in iPB:

• System development environment- iPB-Designer and • Run-time environment – iPB-Runtime (interpreter).

Figure 6. iPB components, adapted from (IbisSoft, 2009).

Development of a system to support a business process mainly consists of designing the structure of the appropriate shared space with the help of Map-designer, and Form-designer. In addition, the developer set restriction on when certain parts of the process shared space can be accessed (Business rules editor) and by whom (Profile editor).

The structure of the process shared space in iPB is called Process map, and it consists of the following three components: Process step, Process form, Form field. The basic relationships between these components and the Process map are as follows.

• A process map consists of a collection of named process steps arranged on a two-dimensional surface called process layout. The layout consists of two areas – (a) the upper row called flow-independent steps, and (b) a lower area, which is a two dimensional matrix called flow-dependent steps, see Fig. 7.

• Each process step in a process map has a step form attached to it. • A step form consists of a collection of named fields arranged in a two-dimensional matrix called form

layout, see Fig. 8. Each field belongs to a certain type. There are simple types, like, text, multi-text, date, date-time, option list, checkbox (Boolean), etc., and complex types like uploaded file, journal, person, organization. In addition, field collections that belong to different step forms can intersect. This is done by defining fields in one form, and then referring to them in other forms.

The runtime system interprets step forms as web forms for inputting, viewing and changing information, see Fig. 9. The process map constitutes a mechanism for user navigation through these forms serving as a table of content for the shared space of a particular process instance, see Fig. 10. To open a web-form, the user clicks on the step in the instance map (see Fig. 10). As it can be seen from Fig. 10, some steps are allowed to have multiple forms at runtime (see the tabs for each lecture in Fig. 9).


Figure 7. Process map

Figure 8. Step form for step Lectures/Lesson preparation from Fig. 7.

The normal order of accessing the forms is from top to bottom and from left to right. However, the map itself does not prevent to skip some steps or to begin a process instance with a form that is placed in the middle of the layout. If constraints on the access order are needed, they are established by so called business rules. One type of such rules controls whether the user can open a particular step form based on the state of completion of other forms. Steps that cannot yet be clicked on are colored grey, see Fig. 10. Such rules are specified with the help of a square matrix where both rows and columns correspond to the steps defined in the process. In this matrix, the content of a cell can determine that the row step can be started only after the column step has been completed (blue color in Fig. 10), or started (green color in Fig. 10). Other types of rules prescribe synchronization of steps with multiple forms, e.g., steps "Lectures/Lessons preparation" and "Lectures/Lessons completion" in Fig. 7 and 10. Other types of business rules establish when data in a step form can be saved or the step can be closed. Such rules are expressed via defining some fields on a form as mandatory for save, or close.

22

Figure 9. Step form from Fig. 7 as a web-form

Figure 10. Instance process map from Fig. 8 as a user navigation mechanism

As with the access order, the map itself does not define who has rights to access web forms, and which rights, e.g. read, modify, etc. The rights are defined in user profiles created with the help of Profile editor (see Fig. 6), and then they are assigned to specific users with the help of iPB administrator (see Fig. 6).

Assessing iPB using the template in form of Table 1, we get a summary of its properties in Table 2.

Table 2. iPB assessment

Features

Level of support

Comments

1. Creating the first version of a system in the shortest possible

Supported The minimum that is required to do for developing a support system with iPB is to define a process map. iPB automatically creates a default form for each step that consists of a “journal field” (see the bottom part of Fig. 8 and 9) where the users can register notes when completing the


time step. This “minimum” system can be useful for some processes. If having a journal field is not sufficient, additional fields can be added with minor efforts.

2. Separation of concerns

a What Full separation

Process goals (more exactly sub-goals) are represented by steps separately from detailed actions to be completed in them.

b How Full separation

Actions are represented as checklists, and other types of fields in the form, separately from actions needed for completing other steps.

c In what order Enough separation

The order of goals to achieve is defined in two ways: (a) by placing the steps in a particular visual order from top to bottom and from left to right on the map see Fig. 7; (b) by introducing restrictions on opening steps through business rules. Visual order represents the recommended order that is not mandatory to follow. This order is easy to change, as there are no connectors between the steps in the map in the development studio (see Fig. 7). Strict constraints on the order - business rules - are clearly separated from the map.

The recommended order of actions to be taken is represented by placing the fields, e.g. check lists in certain order from left to right and from top to bottom. This order is easy to change by “swapping” the positions of the fields without affecting other parts of the form. Besides, changing the order of the fields in one form does not affect other forms.

d Data Partial separation

Data is separated from the goals to be achieved (steps), but not from the actions. Both are represented via fields on the form, and form design includes both defining the data and the actions. In the current version of iPB, there is no separate presentation of data structures independent of forms, though such presentation is technically possible to implement in the future releases. Also, in the current version, it is not possible to move a field from one form to another, which is planned to implement in the future.

e By whom Full separation

Defined by user profiles.

f Changing Modality

Some support

Changing modality is supported in two places: (a) the strictness of order of steps opening, (b) obligations to complete certain actions, or have certain information fields filled. As it has already been mentioned above, the visual order of steps gives only recommendations. Adding business rules can make some of these recommendations mandatory in a lesser or greater degree. The lesser degree means that the user cannot open the next form, unless there is some information in the previous form. The greater degree means that the user needs to finish filling the previous form before opening the next one.

Placing a field on the form means only recommendation that it should be filled, or checked (in case of a checklist). The field can be made mandatory for save, or close meaning that the form cannot be saved, or the step it belongs too cannot be closed if it is not filled or checked.

24

g Separation of other concerns, e.g. security

No support

3. Usability for non-technical people

Supported As described in section 3.3, iPB can be used by a person without deep technical or formal knowledge in the BPM area.

4. Having an executable model

Supported The map and form definitions plus business rules represent a process model from the position of the state-oriented view on business processes (Khomyakov & Bider, 2001). The map defines the total process space as a composition of subspaces, each of which is defined by a step form. Business rules set restrictions on the allowed trajectories in the state-space; more details see in (Bider et al., 2010). Currently, we do not have methods for formal checks, simulation and optimization that could be applied for models built based on the state-oriented view. However, the work on this type of business process modeling continues, and such methods might appear in the future.

6.3 Aspect Service - a workflow based approach

Aspect Oriented Business Process Management (AOBPM) is an approach to separate cross-cutting concerns from process models. In this way, cross-cutting concerns can be encapsulated in different modules, and they can be defined and related to process models even at the runtime. There are different works and proposal on how AOBPM can be applied, yet only Aspect Service defines how these models can be executed at runtime (Jalali, 2014). Aspect Service is a tool that has been implemented on the top of YAWL (YAWL Foundation, 2004) – a framework that supports execution of workflow-based process models. AOBPM is based on orthogonal modularization of aspects of business processes, and it employs the concept of so called dynamic weaving for execution of modularized models.

The modeling phase in AOBPM starts when a process designer creating the skeleton of a business process. The skeleton contains the main concern of a business process, excluding any other concerns like security, privacy, etc. Fig. 11 shows the skeleton of Deal for speculation and Change Asset Deal processes in a bank. Other concerns can be modeled before or after introduction of the support system in organizational practice. Fig. 12 shows three security aspects related to these processes, i.e. control, sign and confirm. Both the main concern and the cross-cutting concerns are separate models that can be changed independently to each other.


Provide

Swift Draft

Register

VoucherArchive

Voucher

Send Swift

Make a

request

Open

position

Back

Office

Employee

Position Sheet

Fill

DealSlip

Make a

Deal Sign

Sign

Receive

MT300

Control

Confirm when the request is more than

the Junior dealer limit

Provide

Swift Draft

Register

VoucherArchive

Send Swift

Fill position

Sheet

Fill

DealSlip

Make a

Deal

Sign

Sign

Receive

MT300

Control

Confirm

VoucherBack

Office

Employee

Figure 11. Skeleton of dealing processes (in BPMN notation)

Dynamic weaving is an approach to support implementation, configuration and execution of modularized models. The semantic of this approach is formalized using Colored Petri Nets (Jensen et al., 2007) in (Jalali et al., 2012). Technical details of Aspect Service implementation can be found in (Jalali et al., 2013). Dynamic weaving enables execution of cross-cutting concerns at runtime; changes made in separate modules become instantly available for execution for any new or already started business process instance. In this way, changes in a particular concern model are introduced without disrupting other parts of the support system. Aspect service has been tested in a simulated environment, but so far, has not been implemented in practice in any organization.

26

Figure 12. Cross-cutting concerns of dealing processes (in BPMN notation)

Assessing Aspect Service using the template in form of Table 1, we get a summary of its properties in Table 3.

Table 3. Aspect Service assessment

Features

Level of support

Comments

1. Creating the first version of a system in the shortest possible time

Partial support

The Aspect Service enables process developers to design the skeleton of the business process. The skeleton consists of the main business process functionality, without cross-cutting concerns like security, privacy, etc. Cross-cutting concerns can be added in later phases.

2. Separation of concerns

Some types of separations below are supported by YAWL, on which Aspect Service has been built, others are implemented by Aspect Service itself.

a What Partial Process sub-goals are not explicitly modeled in YAWL; however, they


separation may be depicted through underspecified tasks. b How Partial

separation Through underspecification tasks supported by YAWL, see above.

c In what order No separation

As long as Aspect Service is dependent on YAWL, this kind of separation cannot be achieved. Switching to Declare (Pesic et al., 2007), however, could help in achieving this separation.

d Data Full separation

The data perspective is separated from process, task and resource perspectives in YAWL.

e By whom Full separation

The users and organizational model are defined in YAWL separately from process models. Different users can be involved in different processes, and concerns and each process and concern can be handled by different users.

f Changing Modality

No support

Only one sort of Modality is supported - obligation. The definition of aspects makes them necessary to be followed based on specified conditions. Thus, there is no possibility to change the modality.

g Other concerns, e.g. security

Supported Aspect Service fully supports separation of additional concerns like security, privacy, logging, etc., which is the main objective of the aspect oriented business process management (Jalali et al., 2013).

3. Usability for non-technical people

No Support

Aspect Service needs to be configured by process administrator who should be quite knowledgeable in the BPM area. Therefore, non-technical users cannot introduce changes themselves.

4. Having an executable model

Supported Aspect Service has a formal executable semantics in Colored Petri Nets (Jalali et al., 2013). Also, it has been implemented on the top of YAWL that is based on the concept of executable business process models.

7 Areas of applicability for the traditional and agile process development methodologies

As it was discussed in Section 4.3, both the traditional and agile business process development methodologies have its advantages and drawbacks, which limit their areas of application. To the advantages of the agile methodology, for example, belongs minimizing the risk of the process and system it supports not being fitted to the business reality. To the drawbacks of this methodology, for example, belongs limited possibility of using formal methods for process optimization. While the latter can be overcome by employing the traditional process development methodology, this methodology itself has drawbacks discussed in section 4.3.

To establish areas of applicability for both methodologies, we will turn to (Bider et al., 2011) that presents a System Thinking point of view on BPM. This work suggests differentiating three categories of business processes that interact with each other:

1. Operational processes like sales, production, HR (e.g. hiring), etc.

2. Process improvement processes that are aimed at improving and optimizing other business processes.

3. Strategic processes that are aimed at defining strategic direction, plans, and policies for an organization.

Schematically, the interaction between different categories of processes is illustrated in Fig. 13. In this figure, BPT stays for business process type or template; in other words, for a formal or non-formal process definition. A BPT “controls” two kinds of systems that run according to the template/definition. The first one is called a sensor and is responsible for discovering a situation that warrants starting a business process instance (BPI) of the given BPT.

28

Due to the interplay between the different categories of processes illustrated in Fig. 13, an enterprise behaves as an adaptive system. It constantly interacts with the environment based on the BPTs of operational processes, optimizes itself to the current environment through the improvement processes, and can reconfigure itself when the environment changes based on the strategic processes (after which it can start optimization to the new environment).

Based on the model from Fig. 13, the following general rule can be applied to choosing a methodology for process development:

1. Situation: a strategic process discovers the needs to change an operational process radically, or introduce a new one, see arrow 1 in Fig. 13. Here, the agile process development is suitable to apply. Note that when a completely new process is introduced in an organization, there are too little data and experience to use the traditional scheme; incremental approach of the agile development suits this task better. Moreover, changing a manually driven process to the one supported by a software system represents a radical change. Not taking this into consideration may result in failure or problems when introducing the new process and system in practice, which did happen in our experience, see Section 4.1 and (Bider et al., 2012). Starting with a simpler system in the beginning might ease the pain of completing the change.

2. Situation: a process stabilizes, and reliable statistical data on its behavior can be gathered so that an improvement process can be started to optimize the original process, see arrow 2 in Fig. 13. Here, the traditional process development is suitable to apply. Note that if a process is expected to be radically changed relatively often, e.g., due to the volatile external and/or internal environment, there is not much of a chance to have enough time for optimization. However, if a stable internal and external environment is expected for some time, optimizing the process makes sense.

Figure 13. Classification of business processes BPT- Business Process Type (model) BPI- Business Processes Instance (case)

2

1

1

2


8 Summary of results and plans for the future research

In the title of this paper, we posed three questions related to agile business process development: why, how and when. The results attained in this paper could be summarized in a table that gives our answers to these questions along with how they have been attained, see Table 4.

Table 4. agile business process development: why, how and when

Questions Answers and how they have been attained Why The traditional business process development cycle has a number of drawbacks that make

it unsuitable for certain processes and situation. The most serious drawback is the high risk of the process and system it supports being outdated long before they are introduced into practice.

The answer has been obtained based on building and analyzing the model of the traditional business process development based on the knowledge transformation perspective, see Fig. 4. The analysis of the model resulted in a list of drawbacks/risks to be considered when employing the traditional development cycle. The list has been verified based on the data from the past projects in which the authors participated.

How By changing the traditional cycle of process development into the agile one by merging the phases of building a detailed process model to-be, system design and system manufacturing in one phase, and using high-level development tools based on executable process models.

The answer has been obtained based on building and analyzing the model of the agile business process development cycle based on knowledge transformation perspective, see Fig. 5. Based on the analysis of the model, a list of requirements for a development tool to support ABPD has been compiled, see Table 1. The list has been tested in the analysis of two development tools from the authors own practice.

When When a completely new business process needs to be introduced, or an existing process is to be radically changed in order to adapt to the changing environment or exploit an opportunity that such changes give to develop new processes or services. Introducing a BPS system for a process handled manually is considered as a radical change as it represents an opportunity provided by the new technology.

The answer has been obtained based on (a) the drawbacks of ABPD detected via the analysis of the model in Fig. 5, and (b) based on the previous work (Bider et al., 2011) that explicates the interplay between different kinds of processes.

In the Introduction, we have defined three goals for our research (a) explaining the difference between the agile and non-agile business process development; (b) defining the requirements on the tool support for ABPD; (c) defining the area of applicability of ABPD. All three were attained to some degree which has implications for both research and practice:

• The difference between agile and non-agile business process development was explained based on creating the knowledge transformation models for both traditional and agile business process development. Analysis of these models allowed to derive risks inherent to and advantages of each of the business process development cycles. To the best of our knowledge, the models are new and original, as nobody tried to apply the knowledge transformation perspective to business process development. The results of the model analysis are not completely new and part or all of them might be known to the expert practitioners. However, explicating them based on the analysis of two

30

relatively simple models makes it easier to transfer this knowledge to non-experts. The latter could help to spread the agile business process development, and, which might be more essential, to prevent it being used incorrectly, e.g., beyond the area of ABPD applicability, or with the help of tools not appropriate for APBD. We also hope that our results could inspire other researchers to apply the knowledge transformation perspective to various aspects of BPM.

• Based on the analysis of the ABPD model (Fig. 5), we created a list of requirements on tool support for APBD in the form of Table 1. To the best of our knowledge, this is the first attempt of the kind. Though the list is preliminary, and thus requires adjustment, it can be used both by process developers to find the right tool for the situation at hand and by tool vendors to provide the features relevant to ABPD.

• Based on the analysis of the model of the ABPD (Fig. 5) and the view from the previous work (Bider et al., 2011) depicted in Fig. 13, we defined the area of applicability of APBD, limiting it to developing new processes, and radically changing the old ones. This can be used by process developers when deciding whether to use or not to use ABPD in a particular situation. This exercise also showed the usefulness of the view from Fig. 13, which may help to attract the attention of other researchers to this view.

The major limitation of this work is that it has been validated only on the material from the projects in which the authors participated. This concern even the part related to requirements on tool support from Table 1, as they were applied only to tools in the development of which the authors participated. Therefore, the results achieved require further empirical validation, which constitute our nearest plans for the future research related to ABPD. We plan to do it in several directions, e.g.:

• Analyzing other projects where traditional or agile process development has been used to see whether some risks, advantages or disadvantages have revealed themselves.

• Conducting a survey among process development specialists to see whether they experienced these kinds of risks.

• Evaluating BPM tools existing in the market to see how well they satisfy the requirements of Table 1. This work could help to further develop requirements on tool support.

• Conducting a survey among the BPM tool vendors to find out whether they consider Table 1 useful and whether they are providing or planning to provide support for ABPD.

In addition to empirical validation, we plan to apply the knowledge transformation perspective to other areas where agility is or could be employed. As it already has been discussed in Section 2, APBD in not equal but has interconnection with ASD (Agile Software Development). The models that we have built and analyzed in Section 4 are specific for business process development, and cannot be applied as-is to software development. However, we believe that they can be generalized and used for explicating the risks involved in ASD and defining the area of applicability for ASD. This work is already under way (Bider, 2014). As with the models presented in this paper, we are not so much looking for the new facts about ASD, but rather for theoretically explanation of the facts already known to the experts in ASD, though often in the tacit form. In case of success, the results could be used for educational purposes to avoid using ASD in the situations, for which it is not suitable.

Acknowledgements. The authors are grateful to all members of our team without whose efforts this paper would have never been written. Special thanks to Tomas Andersson, Paul Johannesson, Erik Perjons, Rogier Svensson and Alexey Striy. The authors are also much in debt to the anonymous reviewers whose comments helped us to improve the structure and readability of this paper.


References

Adams, M.J., Ter Hofstede, A.H., Edmond, D. & van der Aalst, W.M., 2005. Facilitating flexibility and dynamic exception handling in workflows through worklets. In CAiSE'05.

Andersson, T., Andersson-Ceder, A. & Bider, I., 2002. State flow as a way of analyzing business processes--case studies. Logistics Information Management, 15(1), pp.34-45.

Andersson, T., Bider, I. & Svensson, R., 2005. Aligning people to business processes experience report. Software Process: Improvement and Practice, 10(4), pp.403-13.

Becker, J., Kugeler, M. & Rosemann, M., eds., 2011. Process Management: A Guide for the the Design of Business Processes. 2nd ed. Springer.

Bider, I., 2014. Analysis of Agile Software Development from the Knowledge Transformation Perspective. In Johansson, B., ed. To appeare in 13th International Conference on Perspectives in Business Informatics Research (BIR 2014). Lund, Sweden. Springer, LNBIP.

Bider, I., Bellinger, G. & Perjons, E., 2011. Modeling an Agile Enterprise: Reconciling Systems and Process Thinking. In The Practice of Enterprise Modeling, LNBIP, Vol. 92. Springer, pp.238-52.

Bider, I., Johannesson, P. & Perjons, E., 2010. In Search of the Holy Grail: Integrating social software with BPM. Experience report. In Enterprise, Business-Process and Information Systems Modeling, LNBIP, Vol. 50. Springer, pp.1-13.

Bider, I., Johannesson, P., Perjons, E. & Johansson, L., 2012. Design Science in Action: Developing a Framework for Introducing IT Systems into Operational Practice. In Proceedings of the International Conference on Information Systems, ICIS. Orlando, Florida, US.

Bider, I. & Striy, A., 2008. Controlling business process instance flexibility via rules of planning. IJBPIM , 3(1), pp.15-25.

Box, G.E.P. & Draper, N.R., 1987. Empirical Model Building and Response Surfaces. New York, NY.: John Wiley & Sons.

Bruno, G. et al., 2011. Key challenges for enabling agile BPM with social software. Journal of Software Maintenance and Evolution: Research and Practice, 23(4), pp.297-326.

Conant, R. & Ashby, R., 1970. Every good regulator of a system must be a model of that system. Int. J. Systems Sci., 1(2), pp.89-97.

Conboy, K. & Fitzgerald, B., 2004a. Toward a conceptual framework of agile methods: a study of agility in different disciplines. In Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research. Newport Beach. ACM, pp.37-44.

Conboy, K. & Fitzgerald, B., 2004b. Toward a conceptual framework of agile methods. In Extreme Programming and Agile Methods-XP-Agile Universe 2004. Springer, pp.105-16.

Fowler, M. & Highsmith, J., 2001. The agile manifesto. Software Development, 9(8), pp.28-35.

Gong, Y. & Janssen, M., 2011. From policy implementation to business process management: Principles for creating flexibility and agility. Government Information Quarterly, 29, pp.S61–71.

Gram Consulting, 2009. “Ba” for Management Development. [Online] Available at: http://gramconsulting.com/2009/04/ba-for-management-development/ [Accessed 17 Augustus 2013].

Highsmith, J., Orr, K. & Cockburn, A., 2000. E-Business Application Delivery, pp. 4-17. [Online] Available at: www.cutter.com/freestuff/ead0002.pdf.

32

IbisSoft, 2009. iPB Reference Manual. [Online] Available at: http://docs.ibissoft.se/node/3 [Accessed 10 Augustus 2013].

Jalali, A., 2014. Assessing Aspect Oriented Approaches in Business Process Management. In Johansson, B., ed. To appeare in 13th International Conference on Perspectives in Business Informatics Research (BIR 2014). Lund, Sweden. Springer, LNBIP.

Jalali, A., Wohed, P. & Ouyang, C., 2012. Aspect Oriented Business Process Modelling with Precedence. In Business Process Model and Notation, LNBIP, Vol. 125. Springer, pp.23-37.

Jalali, A., Wohed, P., Ouyang, C. & Johannesson, P., 2013. Dynamic Weaving in Aspect Oriented Business Process Management. In 21st International Conference on COOPERATIVE INFORMATION SYSTEMS (CoopIS 2013). Springer, pp.2-20.

Jensen, K., Kristensen, L.M. & Wells, L., 2007. Coloured Petri Nets and CPN Tools for modelling and validation of concurrent systems. International Journal on Software Tools for Technology Transfe, 9(3-4), pp.213-54.

Khomyakov, M. & Bider, I., 2001. Achieving workflow flexibility through taming the chaos. In OOIS 2000 - 6th international conference on object oriented information systems. Springer, pp.85-92.

Kiczales, G. et al., 1997. Aspect-oriented programming. In ECOOP'97 — Object-Oriented Programming. Jyväskylä. Springer, pp. 220-242.

Kindermann, H., 2013. Empowering process participants - the way to a truly agile business process management. [Online] Available at: http://www.onthemove-conferences.org/index.php/keynotes2013/2013keynotekindermann [Accessed 15 Augustus 2013].

Kueng, P. & Kawalek, P., 1997. Goal-based business process models: creation and evaluation. Business Process Management Journal (BPMJ), 3(1), pp.17-38.

Markovic, I. & Pereira, A.C., 2008. Towards a Formal Framework for Reuse in Business Process Modeling. In BPM 2007 Workshops. Springer-Verlag Berlin Heidelberg, pp.484-95.

Meade, L.M. & Sarkis, J., 2010. Analyzing organizational project alternatives for agile manufacturing processes: An analytical network approach. International Journal of Production Research, 37(2), pp.241-61.

Nonaka, I., 1994. A dynamic theory of organizational knowledge creation. Organization science, 5(1), pp.14-37.

OMG, 2011. Documents Associated with Business Process Model and Notation (BPMN). [Online] (2.0) Available at: http://www.omg.org/spec/BPMN/2.0/ [Accessed 16 Augustus 2013].

Perjons, E., Bider, I. & Andersson, B., 2007. Building and Exploiting a Business Process Model for Lobbying: Experience Report. Communications of the IIMA, CIIMA, 7(3), pp.1-14.

Pesic, M., Schonenberg, H. & Van der Aalst, W.M.P., 2007. DECLARE: Full Support for Loosely-Structured Processes. In EDOC.

Raschke, R.L. & David, J.S., 2005. Business Process Agility. In AMCIS 2005 Proceedings.

Rosemann, M., Recker, J. & Flender, C., 2008. Contextualization of Business Processes. International Journal of Business Process Integration and Management, pp.47-60.

Scholten, D.L., 2010. Every Good Key Must Be A Model Of The Lock It Opens. [Online] Available at: http://www.goodregulatorproject.org/images/Every_Good_Key_Must_Be_A_Model_Of_The_Lock_It_Opens.pdf [Accessed 6 Augustus 2013].

Schonenberg, H. et al., 2008. Towards a Taxonomy of Process Flexibility. In CAiSE Forum.

Seethamraju, R. & Seethamraju, J., 2009. Enterprise systems and Business Process Agility- A Case Study. In Proceedings of the 42nd Hawaii International Conference on System Sciences., pp.1-12.


Sherehiy, B., W., K. & J.K., L., 2007. A review of enterprise agility: Concepts, frameworks, and attributes. International Journal of Industrial Ergonomics, 37, pp.445-60.

Shore, J. & Warden, S., 2008. The art of agile. O’Reilly.

Swenson, K.D., ed., 2010. Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done. Tampa, Florida, USA: Meghan-Kiffer Press.

Thiemich, C. & Puhlmann, F., 2013. An Agile BPM Project Methodology. In BPM Conference.

van der Aalst, W.M.P., 1998. The application of Petri nets to workflow management. Journal of circuits, systems, and computers, 8(1), pp.21-66.

van der Aalst, W.M.P., 2005. Case handling: a new paradigm for business process support. Data & Knowledge Engineering, 53, pp.129–62.

van der Aalst, W.M. et al., 2009. Flexibility as a Service. In Database Systems for Advanced Applications. Springer, pp.319-33.

van der Aalst, W.M.P., ter Hofstede, A.H.M., Kiepuszewski, B. & Barros, A.P., 2003. Workflow patterns. Distributed and Parallel Databases, 14(1).

van der Aalst, W.M.P. & Weijters, A.J.M.M., 2004. Process mining: a research agenda. Computers in industry, 53(3), pp.231–44.

Weske, M., 2012. Business Process Management: Concepts, Languages, Architectures. 2nd ed. Springer.

YAWL Foundation, 2004. YAWL. [Online] Available at: http://www.yawlfoundation.org/ [Accessed 18 Augustus 2013].

Agile Business Process Development: Why, How and When

Documents

Transcript of Agile Business Process Development: Why, How and When