Keywords

1 Introduction

The introduction of new technologies and rapid changes in market conditions increase the performance demands put on organizations. Business processes in these organizations control the deployment of their capabilities, both internally and in inter-organizational collaborations. Organizing the business processes into a business process architecture provides the organizations with the capacity to deal with change in a structured way. We refer to this capacity as agility [24]. The structure of these process architectures has been covered by research, both in the holistic architectural sense [10] and in the ingredients to build the structures in these architectures, mostly in the form of process patterns [1]. The majority of the research efforts in this domain focuses, however, on what we call the syntax of process structures, focusing on control flow (or data flow) structures in which process activities are black boxes. Process architectures can also be found as aspects or viewpoints to define behavior in enterprise architecting approaches [27]. Here, process activities are linked, for example, to business services. Like in the process architecture and patterns domains, research in this domain typically focuses on a syntactical point of view. There is not much research yet, however, in addressing the functional content of the business processes, what we call the semantics of the activities in the processes. This is where our research aims to contribute, providing a semantics-driven structure to complement the more syntax-driven structure.

To construct the conceptual foundation for our contribution to business process architecture, we undertake a quest for the fundamental elements of operational and informational functionality of business processes [26]. We combine this with the development of an engineering approach that supports the construction of aggregations of functionality from these fundamental elements. The concept of modularity [15] is central to our approach, as modularity enables agility. The quest for the discovery of a foundational, semantics-based modularity concept provides structured access to what we call business process DNA. From the foundational elements, standardized as parts, it becomes possible to argue about the application of new ways to construct business processes and the role of parts and behavioral patterns, as is done in [8] and [3].

Using the concept of standardized parts and engineering patterns, resulting from a modular business process architecture, offers the foundation for agile mass customization [12] in business process design, using a proven method to deal with variety. In this endeavor, we investigate the possibility of integrating requirements from the business operations, information systems and information technology domains at the lowest level of functional specification. In our analysis of business process DNA, we take as a starting point that all organizational activity happens through processes [6], the elements of which ultimately boil down to ‘actors undertaking activities on objects’. These three foundational elements of functionality structure, properly identified and configured in business process activity blueprints, enable the specification of all constructs of functionality at the lowest level, constituting what we call primitives in previous work [26].

In this paper, we take our research further by developing a taxonomy approach as a means for the definition of business process elements. We argue about the applicability of a taxonomy development method [16, 19] in the context of a complex real-world pilot case. This pilot case study is undertaken to identify and shape those elements of business processes that represent distinct properties at the lowest level of specification, meaning that they cannot be further de-factorized without losing their functional meaning. Once we were able to identify these foundational elements, we applied a taxonomy definition method to be able to identify its ‘genome’. The resulting taxonomy opens up the dimensions of a catalog of reusable foundational business process-building elements (primitives) and constructs thereof. Working in this way, we aim to develop a method as a DSR artifact that enables rigor in business process construction combined with adaptability in its application, hence providing an adequate basis for true business agility. In this context, the leading research question for this paper is: how can a taxonomy be developed for identifying and classifying elements for a catalog of process primitives?

The pilot case is conducted at Rijkswaterstaat (RWS). RWS is part of the Dutch Ministry of Infrastructure and Water Management and is responsible for the design, construction, management, and maintenance of the main infrastructure facilities in the Netherlands, such as roads, waterways, bridges and tunnels. Thereby, RWS is a key player in the national infrastructure that serves both society and business in the Netherlands. RWS has about 10,000 employees, distributed across a complex and distributed organizational structure. The case study is located in the department at the headquarters of RWS in Utrecht that is responsible for the business processes around the standardization of the design, construction and exploitation of bridges and tunnels across the Netherlands. The department is subdivided into several smaller units. The department as a whole manages a large set of complex business processes. One of the problems that the department faces is that its processes have evolved over many years and now have an alignment issue, making it hard to recognize commonalities (or even overlaps in structure), identify unnecessary differences, and address inefficiencies. In other words, they face the problems of expansive BPM and lack of objectivity in process descriptions [4]. This makes them interested in participating in our research.

The structure of this paper is as follows. In Sect. 2, we place our work in the perspective of related research. In Sect. 3, we present the methodology used in our work. Section 4 presents the overall process of developing the taxonomy. In Sect. 5, we present in detail the iterative process of building the taxonomy. As this is a novel line of research that requires next steps, we explicitly reflect on the current step in Sect. 6. Section 7 presents conclusions and outlines future work.

2 Related Work

In this section, we present the core of work that is related to our research. We do this from two perspectives. The first perspective is that of other approaches towards the identification of business process building blocks, i.e., focusing on the ‘product’ perspective of our work. As explained in the introduction, we do this from the process activity content point of view, not from the control flow (or data flow) point of view typically found in pattern-oriented approaches. Our point of view is related to what is mentioned as the concept of ‘content patterns’, used as one of 9 categories in a ‘process pattern taxonomy’ [13] as a classification of process building block classifications. The second perspective of related work is that of approaches to taxonomy development, i.e., focusing on the ‘process’ perspective of our work. In this perspective, we discuss how taxonomy development has been addressed so far in our domain.

2.1 Business Process Building Blocks

The concept of business process building blocks is a well-developed notion within the business process management domain, although the concept covers a range of definitions and a similar range of applications. In the context of our research, we focus on the identification of business process objects that capture the foundational properties of the process structure. Encapsulated as process elements [26], they enable the development of a component-based business process engineering technology. The approach aims to decomplex business processes into foundational process components and relatively simple dependency relationships [7].

Developing descriptions of characteristics of process components is required to identify the properties of these components with the purpose of advancing the use of these process ‘parts’, both intra-organizationally and inter-organizationally. General access to the process components is typically facilitated by the use of catalogs [29] or repositories [17]. In doing so, it is important to understand that describing these components can be performed with different points of view, or lenses, that heavily influence the choice of characteristics of the components. We observe three main lenses in research: the business operations lens, the information systems lens, and the information technology lens.

Today, a tight integration is required between the three lenses when building operational business systems. Non-alignment of the lenses is a major factor in the creation of complexity that hampers the capacity of organizations to deal with change. Adding to this complexity is the individual ‘signature’ in data management constructs that IT professionals unintentionally but inevitably impress on information systems solutions [11]. Too often, ‘digital concrete’ is the result that creates legacy structures that are heavily in the way of agility. Therefore, the nature of process building in terms of the used lens needs to be understood clearly. Next to this, the level of granularity of the process elements under consideration is an important issue [4].

Business process modelers are known to have a high degree of freedom in the decisions they have to make, and also when describing the business processes. This often leads to a lack of objectivity in business process models and descriptions: “model creation is more art than science and the resulting freedom can exacerbate the effective utilization of models. Process models are concise, selective, and arguably subjective representations because there is a lack of objectivity regarding terminology, perspectives, and granularity” [20]. This statement implies that existing approaches have their limitations in improving operational flexibility through the use of information technology. This is the case because they are either vendor-specific, with the lurking danger of locked-ins, are too abstract, demonstrate a partial solution, or do not support the transfer of operations over a variety of technology platforms. Many of the vendors position themselves more as productivity tools for extensions of Lean, TQM, etc. than as independent information architecture platforms [2, 5].

Given the impact of actual technology offerings on virtually all aspects of organizational functionality we infer that an integrated approach is required that covers the three discussed lenses, resulting in the meta-concept of integral business process engineering (BPE). At first glance, this may seem to be another endeavor to advocate the use of process building blocks as they are available in the marketplace at different levels of granularity, e.g., in the form of process patterns [1]. Our research direction differs at a fundamental level from these market offerings but also from theory directions [10] as our method focuses on the semantics of business process structures rather than on the syntax of these. We do not look to shape patterns of process elements but prefer to shape the content of operational activities rather than the form. We do this by identifying and analyzing the properties of process elements, using taxonomies to classify these to structure catalogs that enable the management of these information assets. In doing so, the semantics of business process activities are our starting point for analysis, comparison, and construction, rather than the structures of business processes, as advocated for example in work on process repositories [28].

2.2 Taxonomies

March and Smith [21] present four kinds of research contributions (artifacts) – constructs, models, methods, and instantiations – and two processes (research activities) – artifact building and artifact evaluation – that characterize design science research in IS. In this paper, we present our approach that is intended to support design researchers during their activities in developing a taxonomy for a specific domain. This method is an artifact that serves as a basis for future design science research, the purpose of which is to develop new taxonomies.

Taxonomy is described as “the scientific process of classifying things” (Oxford University Press, 2023). Mapping the properties of a collection of elements is done by using taxonomies as taxonomies offer an adequate framework for the organization of knowledge. Taxonomies “provide a structure and an organization to the knowledge of a field” [14]. They allow to postulate on the relationship between concepts [22] and constitute a fundamental mechanism for organizing knowledge [25].

The development and application of taxonomies have historically been implemented foremost in biology. However, taxonomies have been introduced to other fields of science more recently, such as manufacturing strategies [23] and information systems (IS). In BPM as a subdomain of IS, the ability to study relationships of and between the business process elements actors, activities, and objects is expected to be of value, which is why the development of taxonomies for these process elements is pursued in the scope of this research.

The method of developing taxonomies that are leading in our work is the method for taxonomy development presented by Nickerson et al. [19] and developed further by Kundish et al. [16]. The method for taxonomy development proposed by Nickerson et al. [19] allows the use of both empirical-to-conceptual and conceptual-to-empirical steps in the process of taxonomy construction: “The choice of which approach to use depends on the availability of data about objects under study and the knowledge of the researcher about the domain of interest” [19]. Important in the development of taxonomies is the choice of the domain of concern (the purpose of the analysis), its meta-characteristics, the dimensions of the taxonomy, and the determination of ending conditions. Typically, the development of taxonomies is done by iterations. If the ending conditions are met at the end of a development iteration, the taxonomy development comes to an end. On the other hand, if the determined ending conditions are not met at the end of a development iteration, a new iteration is initiated to advance the taxonomy. Kundish et al. [16] summarize the comments made on the contribution of Nickerson et al. [19] and stress the importance of a more pronounced way of expressing the purpose of a taxonomy as a basis for an improved evaluation mechanism. Their contribution results in a more articulated framework for taxonomy development as an expression of their 18 taxonomy development recommendations (TDRs).

3 Methodology

The method that we use for our taxonomy development is based on the work of Nickerson et al. [19] and Kundish et al. [16]. As discussed in the previous section, the latter is intended to be an extension of the former, so we take the work of Kundish et al. as the basis for our method. Kundish et al. describe a taxonomy development process consisting of 18 process steps organized in 6 phases: (1) identify the problem and motivate this; (2) define the objectives of a solution (the taxonomy); (3) design and develop the taxonomy; (4) demonstrate the taxonomy; (5) evaluate the taxonomy; (6) communicate the developed taxonomy. We basically use the same set of 18 steps as Kundish et al. but rearrange them in three ways.

Firstly, our taxonomy development takes place in collaboration with the organization that owns the business process that we use as empirical input for our development process. Despite the interest of this organization in our work, they cannot be involved in a highly iterative development process (they are not a research organization). For this reason, we rearrange the steps over the phases such, that there is a checking phase that can be performed within the research team on a frequent basis, and an evaluation phase that requires the involvement of the user organization, but on a less frequent basis. For this reason, we move Steps 13 and 14 from Phase V to Phase IV (and consequently relabel Phase IV).

Secondly, we feel that the process flow diagram in the work of Kundish et al. [16] is ambiguous in practice, as there is a single feedback loop with multiple ‘entry’ and ‘exit’ points. We remove this ambiguity by redefining the process flow as follows.

  • We explicitly distinguish between an ‘inner’ feedback loop between Phases IV and III (corresponding with the frequent checking phase mentioned above) and an ‘outer’ feedback loop between Phase V and Phases I–III (corresponding to the infrequent evaluation phase mentioned above).

  • We explicitly distinguish between the reasons to iterate from Phase V to one of the Phases I–III, depending on the observations in Step 17: problems with the users or purposes of the taxonomy, problems with the meta-characteristic or goals of the taxonomy, problems with the ending conditions of the development process, or problems with the elaboration of the dimensions or values of the taxonomy (i.e., the ‘contents’ of the taxonomy).

Thirdly, working with a large organization as our ‘empirical source’, we find that we have to pay explicit attention to not only defining the type of the objects that we classify in taxonomy development but also the scope of objects. In our case, we work with an organization that owns hundreds of complex business processes, which cannot all be an empirical basis for our work. Therefore, we have to explicitly scope our work within this organization to arrive at a feasible empirical basis. We reflect this in our method by splitting up the first step of the process of Kundish et al. into a type definition step and a scope definition step. To stay with step numbering of Kundish et al., we label our new steps as Step 1a and Step 1b.

These three modifications result in the process flow of our taxonomy development method as shown in Fig. 1. We consider this a ‘practical’ variation of the method process flow described by Kundish et al. [16]. For reasons of space limitations, we discuss the details of each of the steps in the application of the method in Sects. 4 and 5 of this paper.

Fig. 1.
figure 1

The taxonomy development process (adapted from [19] and [16])

Full size image

4 The Overall Taxonomy Development Process

In this section, we describe the overall taxonomy development process. This process is an instantiation of the process shown in Fig. 1, applied to the domain of activities for business process engineering. Below, we describe the process in pairs of phases that represent the setup of the development (Phases I and II), the iterative execution of the development (Phases III and IV), and the evaluation and dissemination of the development (Phases V and VI).

4.1 Phases I, II: Identify and Motivate Problem, Define Objectives

Following the (modified) guidelines of Nickerson et al. [19] and Kundish et al. [16], we perform Steps 1–5 in Phases I and II of Fig. 1 as follows per step:

  1. 1a.

    As the observed phenomenon, we specify business process activities (BPAs) as executed in business practice. We interpret BPAs through an information systems lens (as opposed to a business operations lens or an information technology lens).

  2. 1b.

    For the purpose of the work in this paper, we scope the observed set of BPAs to those executed by RWS in their LBS process (with the intention to broaden this scope later). The LBS process is a set of 8 sub-processes that is used to manage the Dutch national standard for building and using bridges in the road infrastructure. The LBS process contains 108 basic business process activities. As these contain many similar activities, we have abstracted them into 35 unique activities, or ‘primitive activities’ [26]. These 35 activities form the empirical set for the work covered in this paper.

  3. 2.

    As the taxonomy users, we take business process designers, i.e., designers of business processes from the information system perspective who work in industrial practice.

  4. 3.

    The purpose of the taxonomy is to provide a structure to define a set of generally reusable core BPA types from an activity content point of view. In the context of this paper, this set of reusable BPA types is scoped to RWS, but the intention is to in further work broaden the scope stepwise by analyzing more sets of BPAs.

  5. 4.

    The meta-characteristic of the objects under analysis is the nature of the core functionality of a BPA, isolated from the specifics of actors that execute a BPA and objects manipulated by a BPA. The overall approach (beyond this paper) is to develop taxonomies for these as well and then combine the three taxonomies.

  6. 5.

    We specialize the generalized ending conditions [19] into specific ending conditions as shown in Table 1.

Table 1. Overview of ending conditions (specialized from [19])
Full size table

4.2 Phases III, IV: Design, Develop and Check Taxonomy

Following the guidelines of Nickerson et al. [19] and Kundish et al. [16], we perform Steps 6–14 in Phases III and IV of Fig. 1. As shown in the figure, the execution of these steps is performed in an iterative fashion: if either one of the objective ending conditions fails (Steps 11 and 12) or one of the subjective ending conditions fails (Steps 13 and 14) in Phase IV, Phase III is executed once more. This process repeats until all 10 ending conditions of Table 1 are satisfied.

In our taxonomy development process, we have used 7 iterations to develop a BPA taxonomy that satisfies all ending conditions. We discuss each of these iterations in detail in Sect. 5 of this paper. Each iteration has been performed with the two following additional considerations. Firstly, even though the development process flow (as in Fig. 1) states that not fulfilling a single objective ending condition implies executing an additional iteration (and hence evaluating the other ending criteria are irrelevant), we have evaluated all ending criteria in each iteration. As building a BPA taxonomy is new, we feel that this more holistic view on the process results in more learning about the structure of the domain of concern and hence a better result. Secondly, in our taxonomy development process, we classify BPAs from the activity perspective only, i.e., we do not take attributes in consideration of actors that execute a BPA or objects that are manipulated by a BPA. This brings a considerable level of abstraction to the classification task. Our aim is to execute similar taxonomy development processes for actors and objects in business processes, such that we can combine the three taxonomies into a three-dimensional classification space of what we call primitives, i.e., activity-actor-object triplets that can be used as standard building blocks in business process engineering [26].

4.3 Phases V, VI: Evaluate Prototype Taxonomy, Disseminate Final Taxonomy

Following the guidelines of Kundish et al. [16], we perform Steps 15–18 of Phases V and VI of Fig. 1. The main effort so far has been devoted to setting up (Step 15) and executing (Steps 16 and 17) the evaluation of the developed taxonomy, as explicitly stipulated by Kundish et al. [16], as detailed below. We are currently in the process of organizing the dissemination of the developed taxonomy (Step 18).

As working with taxonomies is completely new for the intended taxonomy users at RWS, we decided to keep the first round of evaluation fairly informal. Using an approach like TAM with novices is considered to be an overkill for the current phase of the project. We focused the evaluation (more or less in ‘tuned down’ TAM [9] style) on the following quality aspects of the developed taxonomy and related questions:

  • Understandability: do the professionals at RWS understand the concepts, dimensions and values of the developed taxonomy?

  • Completeness: are all essential elements of the RWS LBS process covered by the developed taxonomy?

  • Usability: can the taxonomy be used in RWS practice, does it have a digestible complexity?

  • Intention to use: if the taxonomy is further developed, would RWS use the taxonomy-based approach to streamline their processes?

To evaluate the taxonomy along these lines, two informal evaluation sessions have taken place: one session with all stakeholders involved in the process to obtain an overall impression of the opinion about our work, and one in-depth session with a business process engineer. In the first session, we presented the taxonomy-building approach and an overview of the taxonomy as a result of this. The overall opinion towards our approach and the developed taxonomy was positive, even though this is a completely new take on business process management at RWS. In the in-depth session, the developed taxonomy was presented in detail. The RWS process engineer did not have any corrections or additions to the taxonomy. As this is a new approach towards process analysis and construction at RWS, this was not very surprising to us: the amount of structure and detail may still be overwhelming. Our approach is seen as promising for managing their business processes, specifically from the aspect of aligning the definitions or related processes.

Evaluating the quality aspects raised above, we come for now to the following conclusions. For understandability, we have reached a basis, but work has to be done yet. This is to a large part attributable to the novelty of the approach to RWS. For completeness, according to our evaluation, our taxonomy is perceived to be complete. Taking the previous point into consideration, however, we will need to reiterate completeness at a later point in our project. To increase usability, the taxonomy as developed will need additional explanatory elements and training of users to become usable in practice without our intervention. We plan to address this in a later stage of our work. With respect to intention to use, RWS shows an intention to use our approach (given that the above points receive proper attention), as the issues addressed by the approach are of great importance to the organization (as briefly explained in the introduction of this paper).

Given these preliminary evaluation results, we do not have a basis yet to iterate over Phases I-IV at RWS, following the recommendations of Kundish et al. [16]. As we heavily value the relevance of our work, we rather do not perform a ‘pro forma’ iteration to ‘appear more complete’. As we discuss in the concluding section of this paper, we will continue our current work with a next large case study, which will provide the basis for further development and a more in-depth evaluation of the developed taxonomy. We expect that this will provide a more complete basis to perform one or more iterations over the development process, thereby completing the entire development process.

5 The Taxonomy Building Iterations

In this section, we describe the iterative process of taxonomy building, detailing the execution of Phases III and IV of the overall approach (see Fig. 1), of which the outline has been discussed in Sect. 4.2.

5.1 Iteration 1

In the first iteration of the process of taxonomy building, we choose a deductive approach to create a basis. As we work in the information processing domain, we construct two dimensions that together form an extension of the well-known CRUD typology of database manipulations. The data creation dimension has two values: data acquisition and data generation. This dimension allows distinguishing between two sources of data for activities. The data use dimension has four values: process, read, update, and delete. We add the process value to classify activities that have a complex information processing character (such as revising a document), whereas update refers to simple information manipulation (such as entering data in a form). Note that we use two dimensions as a business process activity may both create data and use data of a different type, so needs to be classified in both dimensions.

Table 2 shows a fragment of the application of the two dimensions on our empirical data set from the RWS case. Note again that the entire set consists of 35 BPAs. We show a fragment in each iteration because of space limitations – the complete data sets are available in an online appendix at: https://drive.google.com/file/d/1PNbmoXmMmXoELesSueURRNJxfHU3HR2K/view?usp=sharing.

Table 2. Data sample from Iteration 1
Full size table

As shown in the table, the data creation and data use dimensions show a reasonable spread of BPAs over the values of the dimensions. The exception is the value delete, which is not used (also in the entire data set). As we expect this value to be required at a later stage or in a broader taxonomy context, however, we have decided to keep this value for the time being.

We have added new dimensions in this iteration, so objective ending condition OC1 has not been met. The taxonomy is not considered sufficiently concise, robust and explanatory, so subjective ending conditions SC1, SC2, and SC5 have not been met either (note that these are indeed subjective assessments, as explicitly explained in [19]). Hence, we have to perform a next iteration, because of both objective and subjective ending conditions.

5.2 Iterations 2 and 3

In Iteration 2 of our development process, we first have deductively chosen the dimension data storage, with values record, file, and database. The intention of this dimension is to classify activities with respect to the way they store data. As we classify activities only (i.e., without explicitly considering the objects that they may store), there appeared to be too little context to make a proper classification in this dimension, and hence this dimension does not add towards ending conditions SC2 and SC5. We therefore have decided to reject this dimension.

In Iteration 3, we have replaced dimension data storage by dimension data move, with values none, inter-company, and intra-company. This deductively chosen dimension enables classifying activities with respect to the scope in which they move (send) data to other activities. Table 3 shows a fragment of the application of the new dimension to our empirical data set. This dimension appears to be useful in classifying data. The table illustrates that even in this fragment of the data set, all values of the dimension occur.

Table 3. Data sample from Iteration 3 (Dimension 1 not shown)
Full size table

We have added a new dimension to the taxonomy, so OC4 is not met. Also, SC1, SC2 and S5 are not met to our satisfaction (which is, as prescribed by the method, again a subjective evaluation). Hence, we have decided to execute a next iteration.

5.3 Iteration 4

In Iteration 4, we have analyzed deductively the way an activity (or the actor executing an activity) performs its messaging to other activities. This has resulted in dimension messaging mode with values physical and automated. Table 4 shows a fragment of the application of the new dimension to the empirical data set. The dimension shows to be useful, so we have accepted it as part of the taxonomy under construction.

Table 4. Data sample from Iteration 4 (Dimensions 1–2 not shown)
Full size table

In this iteration, we have added a new dimension to the taxonomy, so OC4 is not met. Also, SC1, SC2 and S5 are still not met. Hence, we have decided to execute a next iteration.

5.4 Iteration 5

In formal information processing, data validation is of great importance. This is certainly the case in the RWS processes that we analyze, as they are related to standardization. Therefore, taking an inductive approach, we have chosen data validation as the next dimension to add to our taxonomy. In this dimension we classify activities with respect to the goals of data validation: consistency with other data, conformance with respect to internal constraints, or compliance with externally imposed regulations. Table 5 shows a fragment of the application of the new dimension to our empirical data set. To illustrate how all values are used, we show different rows of our data set than in Table 4.

Table 5. Data sample from Iteration 5 (Dimensions 1–3 not shown, different rows shown)
Full size table

In this iteration, we have added another new dimension to the taxonomy, so OC4 is again not met. We have felt that the current taxonomy, with its five dimensions, is concise, so meets subjective ending condition SC1. However, SC2 and S5 are still not met. Hence, we have decided to execute yet another iteration.

5.5 Iterations 6 and 7

In this sixth iteration, we have chosen to take an inductive approach: when looking at activities, we see that some are meant to change the form (format) of data, some are not. Some change the content of data (e.g., edit a document), some don’t. Some are meant to reduce the size of data (e.g., produce a summarization of a data set or document), some keep the size intact. This has led to three new dimensions: form preservation, content preservation, and size preservation. They all have the values yes and no, indicating whether they preserve the characteristic of the data addressed by the respective dimension.

Table 6. Data sample from Iteration 6 (Dims. 1–4 not shown)
Full size table

Table 6 shows a fragment of the application of the three new dimensions to our empirical data set. We use the same subset of data as in Table 5 to illustrate the occurrence of all values.

In this iteration, we have added three new dimensions, so OC4 is not met for sure. Given the protocol of Fig. 1, we had to perform a next iteration.

In Iteration 7, we have concluded that no structural changes are necessary to the taxonomy at this point, so the taxonomy meets all objective ending conditions. We also have felt that all subjective ending conditions were met. With the three new dimensions of the previous iteration, the taxonomy has become adequately robust and explanatory for its intended use. Hence, we have ended the iteration cycle with a (for the scope of this paper) complete taxonomy comprising of eight dimensions with each between two and four values, as shown in Table 7.

Table 7. Overview of developed taxonomy structure
Full size table

6 Reflection

Our presented work on taxonomies is based on a rich real-world environment (RWS) and thus offers a strong empirical basis for contributions to the use of taxonomies as instruments to structure knowledge. In executing our work, we have made several interesting observations in this context, related to the domain of concern for which we develop our taxonomies: business process engineering.

Firstly, using the Nickerson framework [19], we found that our results benefit from an explicit definition of the ‘domain of concern’ as an important element of the structure. The identification of this domain of concern as a first step in developing taxonomies provides context and meaning to the definition of the meta-characteristics and subsequently to the specification of taxonomy dimensions, their values and ending conditions for the development process. We observed that developing a taxonomy of process activities for the domain of information systems results in different meta-characteristics, compared to the domain of business operations or information technologies. As noted before, we refer to this definition of the domain of concern as the ‘lens’ used in analyzing a collection of objects.

Secondly, the characteristics of the collection of objects under consideration are of importance as they influence the applicability and contribution of a taxonomy. This point has been raised previously [18]. In our pilot cases, we found that differences in the character (e.g., formalized vs. non-formalized) and the granularity of the business process objects under observation [4] had a profound impact on the resulting taxonomy and its match with its purpose. Even though we think that we have made adequate progress here, this issue requires further attention in our work.

Thirdly, the BPE domain and the IS lens are rather abstract in nature – compared to other domains where taxonomies are popular, such as biology, where objects under analysis are more ‘physical’. We found that this appears to lead to a bias towards deductive iterations as a basis in the taxonomy development process (our first four iterations are fully deductive). Inductive iterations are harder – perhaps because abstract objects are harder to observe than physical ones – but are required to achieve a good ‘fit’ of a taxonomy with the domain of concern it is intended for.

Finally, taxonomies are the result of a series of analysis iterations and iterations are evaluated on an individual basis either to be accepted or rejected. Next to this iterative evaluation process during construction cycles, the resulting taxonomy as a whole needs to be evaluated (in Step 16 of Fig. 1). Here we agree with the observations of Kundish et al. [16], but further operationalize the recommendations made in this work. In the case study described in this paper, this evaluation has been executed in a rather informal way. In the next case study of the research project, we plan to address this more formally, applying structures in methods like TAM [9] much more rigorously.

7 Conclusions and Further Work

With the work described in this paper, we have continued our design science research effort to develop a method that enables a mass customization approach to business process construction. After our initial quest into the properties of atomic building blocks, the levels of syntactic abstraction involved and the redundancies demonstrated [26], this paper focuses on the semantic expression of one of the three individual process factors (activities, actors and objects) that constitute the foundational components of business process elements. It is important to observe that the developed taxonomy approach is not the end goal of our research endeavor but is instrumental to our quest towards what we call business process DNA, as mentioned in the introduction to this paper, and as a fundamental element in business process engineering.

We see our contributions to the BPM research domain as twofold. Firstly, our work is among the first to use the promising research direction of taxonomy development for business process analysis and design in the context of complex, real-world business process management. To guarantee the relevance of our work in terms of design science research [15, 25], we explicitly choose this practical anchoring with a strong empirical basis. We guarantee rigor [15, 25] in our work by embedding our work in relevant approaches and using strict method execution. Secondly, our work provides a strong basis for a process activity semantics structure. This complements the existing work on process syntax structure, e.g., on process patterns.

In our next business case (which is on the way at the time of finishing this paper), we will broaden our taxonomy scope by developing taxonomies for the other two process factors (actors and objects) and broaden our view to include a business operations perspective next to an information systems perspective. We will perform this work in the industrial environment of a large construction company aiming at assisting them in aligning their business processes for physical asset management and deployment with their digital asset management processes.