Agile Business Process Development: Why, How and When

Click here to load reader

  • date post

    14-Feb-2017
  • Category

    Documents

  • view

    213
  • download

    0

Embed Size (px)

Transcript of 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 Manage