The paper presents new organizational and technological options of process management as a result of a design-oriented research approach with particular consideration of self-organization and collective intelligence. The authors conceptually develop options for action. The concept is illustrated by a prototype platform for process management and real-world application scenarios in the construction industry. The paper finally presents an evaluation of the design-oriented research approach.

1 Introduction

1.1 Initial Situation and Objective

In the early 1990s, business process management (process management) evolved on the basis of a management trend into an established design approach of information systems, including concepts related to both business administration and computer science (Becker et al. 2005; Gaitanides 2007; Weske 2007). Regardless of the merits of process management, though, also several problems remain: Corporate systems of action are often highly dynamic, which is e.g. shown by the fact that a variety of operational functions is not or cannot be algorithmically specified and therefore cannot be executed by machines. However, human agents usually have considerable discretion of which they can take advantage in different ways depending on the specific task. Furthermore, the dynamic nature is shown by the fact that an organizational form once chosen has to be adapted to new conditions on a regular basis as otherwise the effectiveness and efficiency of the organization is at risk, especially in competition with rival organizations. Consequently, a central problem of process management is to adequately consider the dynamics of corporate systems of action.

Recently, many applications such as wikis, social networks, social bookmarks, and RSS feeds have emerged which are extensively discussed as innovations of Web 2.0. A key feature of Web 2.0 applications is the utilization of the full capabilities of individual users in a common action context. In this way, the previously mentioned Web 2.0 applications make it possible to react to events with high speed and to spontaneously support actions adequately to ensure their success (examples are Wikipedia, YouTube, XING, and Delicious).

However, Web 2.0 applications have primarily been designed for private and not for business users. Consequently, the question arises as to whether the design principles of Web 2.0 can be efficiently deployed in the business environment, particularly for the control of dynamics in process management.

1.2 The State of Research on Process Management from the Perspective of Web 2.0

In the plethora of scientific work dealing with Web 2.0 now also contributions dedicated to business applications are appearing (Alpar and Blaschke 2008; Kollmann and Häsel 2007; Back et al. 2008). Moreover, there are a few works dealing with the potential benefits of Web 2.0 applications in process management. For example, Ebersbach et al. (2008), Komus (2006), Komus and Wauch (2008), and Lai and Turban (2008) propose to use wikis for defining, modeling, and further developing processes. Komus and Wauch (2008) explain how blogs and social networks can be used for the implementation, execution, monitoring, and control of processes. Some authors also provide an overview of general application potentials (Schmidt and Nurcan 2009; Johannesson et al. 2009).

The mentioned contributions undoubtedly illustrate the general potential of typical Web 2.0 applications in process management. However, it has first to be stated that the works describe fairly general potential benefits without developing detailed and elaborated organizational and technological options from the perspective of Web 2.0. Second, they primarily describe the existing possibilities of using wikis, blogs, and similar applications without generalizing the basic design principles of Web 2.0 applications and developing new, innovative options for action in process management. For example, it remains unclear how exactly “social tags” can be used in process management.

1.3 Objective and Structure of Work

The aim of this study is to develop and evaluate innovative organizational and technological options of process management from the perspective of Web 2.0. In the present study we focus on the aspects of self organization and collective intelligence. To give reason for the presented options for action we critically analyze implicit assumptions of previous approaches in process management.

The section following this introduction outlines the research framework in terms of scientific theory. Section 3 focuses on key features of Web 2.0 applications. The dynamics of corporate systems of action is empirically validated in Sect. 4 on the basis of a specific domain from the construction industry. We discuss implicit assumptions of previous process management approaches in Sect. 5. The main section of this contribution, Sect. 6, presents the organizational and technological options of process management resulting from Web 2.0. Section 7 explains aspects of the evaluation of the research results. The paper concludes with a summary and an outlook on further issues in Sect. 8.

2 Research Framework from the Perspective of the Philosophy of Science

While prevailing scientific theories primarily rely on knowledge-oriented research that focuses on explaining, understanding or on the reconstruction of “the” reality, the present work takes a design-oriented approach focusing on the creation of a “new” reality. This understanding is closely modeled on the approach by Simon (1994) who argues for the science of the artificial. In terms of this view, information systems should be designed to provide alternative courses of action to the present information systems. The pursued design-oriented approach is structurally similar to the synthetic orientation of chemistry or biology, which focuses on the development of substances or organisms with new and theoretically interesting features as an essential goal of the research efforts. In this sense, our work conducts research on information systems with new features.

In terms of its objectives, the assumed scientific research framework is similar to the ideas of Hevner et al. (2004) on “design science”. However, we do not follow the methodological specification of Hevner et al. due to a number of known deficiencies (Frank 2006, pp. 29–31; Zelewski 2007). Therefore, we outline our methodological approach in the following.

This paper does not aim at a “revolutionary change” of Business and Information Systems Engineering (BISE) practice. Instead, the claim is considerably more modest: First, we want to illustrate what BISE practice may look like against the background of new general conditions. Second, we will explain that the new course for action appears very appealing in comparison with the known options.

To achieve the identified objectives and to ensure the usefulness of the research results it is necessary to use appropriate research methods. According to our scientific understanding, research methods in the context of (a) design and (b) evaluation of an innovative information system can be distinguished (Fig.  1 ).

Fig. 1
figure 1

Design science research cycle

Full size image

Ad (a): In the design context methods from system development are used which are particularly suitable in contexts where the requirements for systems are not yet known, but have to be identified (“research through development”; Szyperski and Müller-Böling 1981). Thus, at the beginning of the work there was a vague idea that previous approaches of process management are unsatisfactory and new technologies like Web 2.0 offer interesting options for action. To obtain a clear picture of actual deficits and possible options for action we focused on a prototype-oriented system development. The applied research process is characterized by the following features:

  • Exploration: System development is used to explore the various fields of application of process management.

  • Participation: Potential users are involved in the research process. The appropriate involvement of “real” users and the consideration of “real” problems of process management are ensured by the fact that the research process is embedded in the BMBF-funded research projects ArKoS (www.arkos.info), BauVOGrid (www.bauvogrid.de), and PROWIT (www.prowit-projekt.de). In this way it is possible to take a variety of applications and roles in different companies into account.

  • Iterations: The development process traverses several iteration cycles. Within these cycles, the design is progressively refined, it is developed by further aspects and feedback from potential users is obtained.

  • Evolution: In the course of one iteration different designs are tested (“trial-and-error”). Feasible designs that received positive feedback are taken up in future iterations and are pursued further.

  • Prototype orientation: In the research process, a software prototype is developed. By means of a prototype both a viable instrument for gathering feedback from potential users is provided and an instrument to check whether certain concepts are viable is developed.

Ad (b): Regardless of the question on the design methods that yield research results, the question is how to scientifically assess the results obtained, i.e. how to evaluate them. The present work primarily focuses on the proposed criteria by Frank (2006, pp. 33–35):

  • Abstraction: Science is not interested in detailed descriptions of individual objects, but in capturing general contexts.

  • Originality: Scientific results must be original, at least in part.

  • Justification: Scientific results have to be justified. Different criteria can be used.

3 Self-Organization and Collective Intelligence in the Web 2.0

In this paper, the term “Web 2.0” is not so much taken as a specific application or a specific type of application, but rather refers to a paradigm for the automation of systems of action. Although the paradigm has been interpreted differently within the literature, many authors emphasize that self-organization and the harnessing of collective intelligence constitute two important beliefs of the paradigm (O’Reilly 2005; Kollmann and Häsel 2007, pp. 6–9; Wahlster and Dengel 2006). These two features are understood to be characteristic of Web 2.0 concepts in the present study.

The concept of self-organization is initially used in both the natural sciences like physics and biology (Leuthäusser 1987) and within the business sciences, particularly in organization theory (Gebhardt 1995). A system is awarded the feature of self-organization if it is able to ensure and develop its functionality by itself without external influence through cooperative behavior of its system components (Büttner 2001). To distinguish different types of self-organization, characteristics such as frequency of changes or effects of changes to the system structure or system behavior are used (Bolbrügge 1997; Büttner 2001; Gebhardt 1995).

Originally, the concept of collective intelligence comes from the field of biology (Schelske 2006). The term describes the fact that the locally controlled behavior of a number of individuals leads to successful problem solving (Lévy 1997). For example, a swarm of ants is in the position to find the shortest path between a food source and the ant colony by a clever distribution of so-called pheromones. This basic principle of problem solving is now exploited within logistics, e.g. for route optimization, or within computer science in the form of multi-agent systems.

Self-organization and harnessing collective intelligence are two key characteristics of Web 2.0 applications. For example, the success of applications such as Wikipedia would be impossible without the contribution of many people who have been involved in creating, testing, and developing the individual lexical entries. Moreover, the use of so-called “folksonomies” to access large amounts of photos, videos, link collections, and the like illustrates the potential implied by the exploitation of collective intelligence. Another example is the evaluation of products and services by users or the dissemination of news and information via blogs that are linked in many ways. These examples illustrate that self-organization and the harnessing of collective intelligence represent two key characteristics of typical Web 2.0 applications.

4 Exemplary Representation of Deficiency Management in the Construction Industry as a Dynamic System of Action

In the following, we will outline the dynamics of corporate systems of action based on the example of deficiency management in the construction industry. In doing so, we provide empirical evidence for the dynamics of corporate systems of action based on a concrete application domain. The statements relate to business functions that have been collected on the basis of the initially introduced research projects with the industrial partners. Consequently, the representations constitute generalizations of different users.

An important system of action in the construction industry is deficiency management, which consists of the following tasks:

  • collect deficiency,

  • assess deficiency,

  • verify deficiency,

  • eliminate deficiency,

  • verify removal of deficiency, and

  • unregister deficiency.

A typical defect may be for example a water pipe rupture in the building which leads to mildew at the corresponding wall of the building. If this deficiency is discovered, it has to be identified and evaluated. After examining the defect, for example regarding different causes or alternatives for repairing the defect, the deficiency is to be eliminated. The process is completed by a verification of the complete removal of the defects and a subsequent deregistration.

The outlined subtasks of deficiency management can be understood as a linear process. However, practical experience shows that in many cases this is not wise. Instead, often considerable dynamics exist (see Sect. 1.1) since the processes carried out in the event of deficiencies are handled differently depending on the respective type of deficiency, the urgency of repairing the defect, its severity, and the available resources. In addition, often members of different companies are involved (general contractors, subcontractors, project managers and consultants) who cooperate within the deficiency management and are responsible for and jointly develop a solution (removal of deficiencies in the construction) for a process problem (constructional defect).

In addition to the described dynamics the construction industry is characterized by heterogeneous partners of different sizes who insensitively and jointly carry out a variety of tasks. Due to the large number of participants involved in the system of action, further dynamics are created which have to be taken into account during process planning, execution, and control.

Apart from applications in the construction industry, the above-mentioned research projects also analyze other sectors with dynamic systems of action. Thus, in the context of the research projects potential applications in the following areas could be identified and examined: Supply Chain Management during stock management by a supplier, operational tasks of complex technical goods conducted by the manufacturer for the customer (“hybrid value creation”) and IT Service Management.

5 Explication of Implicit Assumptions of Process Management

Previous approaches to process management describe different tasks that are relevant for the management of processes (Allweyer 2005; Becker et al. 2005; Bucher and Winter 2007; Davenport and Short 1990; Gaitanides 2007; Hess and Schuller 2005). Although these approaches differ significantly in some respects, the following tasks are usually more or less explicitly mentioned:

  • Process planning: During the planning of the processes procedures are defined to perform certain operational functions.

  • Process execution: Process execution involves the actual execution of the planned processes.

  • Process control: The process execution is monitored and controlled by various control measures.

Some authors do not include the actual execution of processes in process management (Becker et al. 2005). However, in the following analysis we understand process management to include all of the above mentioned tasks, and thus also subsume planning and control of processes besides their execution (Bucher and Winter 2007; Weske 2007, p. 355).

In process management, often so-called process models play a prominent role providing an overview of the processes in an organization. The importance of process models is also reflected in the fact that for the linguistic formulation of process models a variety of artificial description languages, such as Event-driven Process Chains, Petri nets, or the Business Process Modeling Notation, have been developed and are used besides natural language descriptions.

Process management is often linked to several usually only implicit premises:

  • Extensive schematization of business processes: Business processes are captured by means of diagrams in the form of process models. Task contents not only can be regulated, but often have to be regulated. If a schematization of a task is not possible or does not make sense, these tasks are usually excluded from the process management.

  • Inadequate consideration of exceptional cases: As a result of the need for schematization of processes, the latter often constitute idealizations. Although such idealizations are usually associated with advantageous standardizations, it cannot be avoided that at any time during process execution special and exceptional circumstances may arise which have not been adequately anticipated during process planning.

  • Clear division of labor between the design and the execution of processes: Between those bodies collecting and designing processes and those responsible for their execution there is a clear division of labor. Thus, bodies engaged in the design of processes are dependent on gathering knowledge about the actual tasks from the executing bodies. Naturally, such a survey can only be done from a certain perspective and for a specific purpose and in this sense is always incomplete and limited.

  • No or insufficient feedback: Although feedback is regularly referred to a continuous improvement of processes, it remains unclear how exactly this is realized between the bodies of process design and execution.

  • Conflict of perspectives between process planning and control on the one hand and process execution on the other: It is necessary to take a so-called “bird’s eye view” (Huth 2004, pp. 79 f.) during the design of processes as otherwise the abundance of different details cannot be perceived at all. In contrary, in the execution of processes some bodies have to take a “blinkered approach” as otherwise they cannot perform their tasks. Naturally, there is a conflict between these two perspectives. Since existing approaches mainly assume that all business processes are to be documented in the form of process models, this conflict can be resolved only to a limited extent within process management.

  • Strict phase separation between build time and runtime: The previous assumptions are also reflected in the implementation of tools for process management. Usually, build time and runtime are distinguished, assuming a strict separation of phases. First, process models are created by process engineers at build time, which will be carried out in a second step by the executing bodies at runtime (Gadatsch 2002, pp. 135 ff).

Against the background of the dynamic nature of corporate systems of action as described in the previous section, it is apparent that in practice the implicit assumptions of process management are achievable in some case, but appear problematic in other cases. To relax the implicit assumptions of process management, Web 2.0 offers attractive starting points for innovative options for action.

6 Process Management from the Perspective of Web 2.0

As a result of the problematic situation outlined in the previous section, the following Sects. 6.1 and 6.2 illustrate new options for action for process management from the perspective of Web 2.0. A possible software technical support for the identified course of action is outlined in Sect. 6.3.

6.1 Organizational Options

A more detailed analysis of process management tasks with particular regard to two characteristics of Web 2.0 opens up fundamentally new organizational options:

  • Self-organization: While previous process management approaches assume an extensive central planning and control instance for the processes, the perspective of Web 2.0 leads to a decentralization of planning and control functions. In extreme cases, planning and control functions are largely carried out in a self-organized way. Thus, planning and control of processes is not so much based on a central authority (“top down”) as on individual actors (“bottom up”).

  • Harnessing collective intelligence: Traditionally, process management is centrally planned, implemented, and monitored by individual stakeholders (e.g. process coordinators, “process owners”). The stakeholders develop an “optimal” scheme for process structures. Although the organizational knowledge about processes is considered for example within process reorganization projects in the form of interviews, observations of operating schedules, or the study of existing organizational documents, this is usually done just once at the time of reorganization. A continuing consideration of the knowledge of the organization’s members usually does not take place. For dynamic systems of action centralized process management is only suited to a limited extent. The perspective of Web 2.0 makes clear, however, that it is possible to create process-related knowledge and make use of it within process control by harnessing the collective intelligence of everybody involved in a process. The group of members of the organization who are involved in the planning, execution, and control of a process are referred to here as a process collective.

The comprehensive consideration of the two aforementioned issues has two remarkable consequences for process management:

  • Move away from a mechanized conception of the organization: Existing process management is characterized by a mechanized view on the organization. Accordingly, it is a priority to ideal-typically fix schematized procedures in form of target process models. Target processes provide action schemes that are to be followed mechanically by the organization’s members. Often, actual situations (“actual processes”) are considerably neglected and a strong technology-centered perspective is taken. From the perspective of Web 2.0, however, the real treatment of individual processes and the possible problems themselves are highlighted.

  • Removal of the separation between build time and runtime: Process management tasks can be divided into planning and execution tasks, among others. The conceptual structure is usually reflected in a temporal separation of the two types of tasks, so that the execution phase has to be strictly distinguished from the development phase: During the development phase all planning functions of the process management are accomplished. During the execution phase, in contrast, all execution tasks are carried out. Although both phases are generally executed iteratively for example in the form of a continuous process improvement, it usually remains a sequential phase sequence. If the previously described aspects of self-organization and collective intelligence are consistently implemented, a temporal separation between the two phases is clearly untenable. Instead it is assumed that planning and execution of process management functions are handled by numerous intertwined decentralized bodies. Then, planning and execution tasks can be carried out both in the context of a process and in the context of different processes in a parallel and thus overlapping manner.

In summary, one central consequence for process management becomes apparent from the perspective of Web 2.0: It is not necessary to “completely” describe individual process schemes a priori; instead specific processes can be planned, executed, and controlled by taking advantage of self-organization and collective intelligence. This conclusion not only applies to the value-creating processes in an organization, but also to the process of the organization. Thus, the process of process management can be considered as a dynamic system of action following the previously established meaning. The individual tasks in the context of process management do not have to be determined a priori, but can be dynamically designed.

Additionally it should be noted that taking advantage of the new degrees of freedom in process management is not appropriate for all types of processes. Thus, it will continue to be purposeful at an early stage to schematize processes that are marked by less dynamics and high routine. Therefore, the use of the proposed organizational options does not exclude the use of established approaches, but represents an extension. It can be assumed that depending on the context different process management approaches are advantageous. For example, one could determine based on a classification of processes as regards their dynamics and their routine, which process management approach is used for what kind of processes.

6.2 Technological Options

6.2.1 Overview

From the perspective of Web 2.0, various technological options for the design of process management arise which are presented in an overview in this section. In the following subsection individual sub-aspects are explained in more detail that are of particular importance in the context of self-organization and the harnessing of collective intelligence.

Similar to the organizational options, the described aspects of self-organization and collective intelligence are also particularly emphasized with regard to the technological options. In the context of technological options, the focus is not set on the primary value-creation processes within the company, but on the supporting processes for research and development or the use of new technologies. Below, we particularly address the issue of development and application of software tools for process management, also known as process management systems.

If we consider existing approaches to software development and application, it is interesting to state that the consequences for process management described for the organizational options have already been discussed in software engineering for many years. This is shown e.g. by the studies on “Evolutionary Software Development” (Floyd 1984), “Extreme Programming” (Beck 2000), and “Open Source” (Raymond 2000). In other words, many of the previously outlined organizational options for business processes are in general already taken into account in various methods and techniques for software development processes in particular.

The illustrated connection is evident not only in processes of system development, but also in the developed software systems as a result of system development. Thus, e.g. software architectures with a higher degree of modularization have been attributed significant advantages for decades (Parnas 1972). While the modularization of a software system has been established at build time, more recently modular approaches are increasingly used in the context of service- and component-oriented architectures (see for example Amazon Web Services) where the modules of the entire software system are “dynamically” composed at runtime (Papazoglou and Georgakopoulos 2004).

The outlined developments also open up new options for the software tools used for process management. Thus, from the perspective of Web 2.0 these process management systems should not be seen as a monolithic system. Therefore in the following we do not talk of a “monolithic” tool for process management, but of a platform for process management which summarizes the different modules for each specific task of process management. The above mentioned modules are not tightly coupled, but are “dynamically” compiled at runtime.

The following description of the modules should not be understood as a static “overall architecture”, but rather constitutes an expression of the current state of knowledge in the presented research approach. In future, the described modules may be complemented by further modules with additional functionality for process management.

Fig.  2 shows a possible architecture of the existing technological options. The platform currently consists of mainly four modules, each offering special services:

  • Self-organization for process collectives: This module provides functionality to support self-organization and for harnessing collective intelligence.

  • Cooperative modeling management: Functionalities to cooperatively create models are offered in this module. This includes, for example, the simultaneous presentation and manipulation of individual process models at different locations.

  • Transformation and converter management: A model transformation is a relationship between two process models, each expressed in different modeling languages but with equivalent content. A converter is a software tool that allows for a (semi-)automated model transformation. Functionalities for the management of transformations and converters are provided by this module. From the perspective of Web 2.0, this functionality appears especially important since we can hardly expect a common modeling language for process models.

  • Management of dynamic process modules: This module manages a model library which stocks individual process modules. The process modules can be reused for the design of business processes and thus constitute reference models (Fettke and Loos 2004).

Fig. 2
figure 2

Architecture of the process management platform

Full size image

The data emerging in the platform are stored in a repository. In addition, the platform has several interfaces: On the one hand, there are interfaces to tools for the creation, maintenance, and analysis of process models (“classical” tools of process modeling and analysis). On the other hand, it can be assumed that the described platform is not uniquely instantiated in reality, but that multiple instances of the same or similar platforms exist for which interfaces are offered.

Existing tools for process management (ARIS, Casewise, and others) essentially assume a monolithic overall architecture in which integration and coupling of different tools constitute exceptions. In contrast, the proposed architecture is based on the idea of realizing the overall functionality through a loosely coupled set of individual components. In this way, individual tools can be flexibly integrated.

In the following, we present the available technological options for self-organization and collective intelligence in the module “self-organization for process collectives” in more detail.

6.2.2 Tagging as an Instrument for Self-Organization and Harnessing Collective Intelligence

We refer to the term “tag” as an identifier or name specified by the user for a concrete or abstract, but definite object. The term “tagging” denotes the use of tags as an instrument for structuring objects. During tagging it rests on the users to define structures by themselves and conduct a meaningful allocation of tags (Alby 2008, pp. 117 ff).

From the perspective of bibliographic documentation, tags are to be understood as non-standardized keywords (Gaus 1995). However, they have essential characteristics with regard to pragmatic aspects. First, tags are usually not specified by an archivist or librarian, but by the end users themselves. Secondly, the keywords are not uniquely fixed at a time, but can freely be added and manipulated by the users. As a result of these pragmatic characteristics, tags are especially designed to meet the needs of users and now enjoy great popularity in Web 2.0 applications like YouTube, XING, and Delicious.

As in the context of private applications tagging seems to involve significant benefits, the question arises whether this approach can be usefully applied in the context of process management. In this regard, three application areas in process management have particularly been identified within the research project:

  1. (1)

    Tagging of representations of actors and services

    As problem solvers, actors take an important role in dynamic processes. They represent carriers of information and skills that are required to deal with processes and to solve any problems that are encountered during the execution process or that may arise in future. Therefore, it is necessary to search for and to contact actors with specific skills in the process collective of a cooperation when a process problem is detected. Realizing such a search requires the tagging of representations of process actors (Koch et al. 2007, pp. 451–455). These offer differentiable services for the process collective and make them available as needed.

    In a construction project, for example, the actor Meier, who is available as a systems mechanic for sanitary engineering, heating engineering, and air conditioning, can be specified through typical service tags for the provided services: system mechanics, sanitary engineering, heating engineering, air conditioning, water installations, repairs.

  2. (2)

    Tagging of process problems and solutions

    We have stated the identification and structuring of dynamic systems of action to be a key organizational challenge. Tagging is used for the spontaneous, situational and demand-oriented identification of dynamic factors. Thus, individual tags are used for identifying and structuring dynamics according to the following scheme (Table  1 ): A process problem and an associated process problem solution are initially perceived as a black box. This black box is abstractly characterized by actors through their environment, their causes, and their effects, so that it can be detailed and modeled at a later point in time by the process actors.

    The tags can be assigned to the following aspects:

    • Process problem and solution: A process problem and a process problem solution are specified via tagging. The actor of the process, who is confronted with the dynamics, states a name for the process problem and describes the reference object to which a process problem refers. For solving the process problem, the solution steps of the process problem solution are documented via tags. For the example taken from construction industry, a supervisor may in case of water damage define e.g. the tags pipe_rupture (problem name) and water_pipe (reference object of the problem) for the process problem as well as search_leakage and applying_sealing_material as exemplary steps in solving a process problem.

    • Environment: Process problem and solution each occur in a particular context of action. To describe this action context, suitable tags are location, project and offered service. In our example, the environment can be further specified by the tags building_shell, 1st_floor, project_extension, construction_site_Mannheim.

    • Causes: Causes are influencing factors that must be analyzed when solving the process problem. For the construction industry, e.g. the tags material_failure, frost, corrosion might be defined in case of a pipe rupture to structure the problem with regard to possible causes.

    • Effect: Effect tags characterize current as well as future consequences that are associated with a particular process problem. For the pipe rupture example, tags like moisture_damage, mildew, increased_water_consumption as the process problem and as the influencing factors characterizing the process problem solution can be described.

  3. (3)

    Tagging of process patterns

    As a result of tagging process problems and solutions we achieve a cause-problem-effect-pattern (CPE pattern) by integrating process problem related tags, which can be viewed as a generalizing description of a process problem/ solution. The previously described tags for the identification of process problems and solutions are based on the spontaneous, responsive and situational tagging of processes and the events dynamically occurring in the processes. Here, CPE patterns were described by actors via tags to define a process problem. CPE patterns can be converted into model-based process problem patterns, which are used as reference patterns for solving process problems.

    If for example in the application scenario from the construction industry it is found that certain tag combinations such as “pipe rupture”, “water_pipe_basement”, and “mildew” occur in a correlated form, this can be regarded as evidence of the frequent occurrence of a specific process problem. Consequently, it appears obvious to transfer the created CPE patterns to a reference pattern and store them in the library of process modules.

    The decision on when a CPE pattern is to be converted into a new reference process model can be determined both based on the frequency of the CPE use for solving a process problem (indirect evidence of acceptance) and on the basis of an explicit rating of CPE patterns by the actors (direct evidence of acceptance). In this way higher and lower weighted CPE patterns emerge from increasing assessments and uses of CPE patterns. Higher weighted CPE patterns are those relevant for the process collective and references that are selected by the process collective. An additional variation for the identification of uniform process patterns is enabled by process mining techniques (van der Aalst et al. 2004), whose applicability is currently being investigated in this context. For example, these techniques could be used for automatically generating proposals for process patterns.

Table 1 Exemplary tagging of process problem and solution
Full size table

6.2.3 Summarizing Class Model

The previously stated, purely verbal remarks on tagging are summarized in Fig.  3 in the form of a class model. The class model can be used as a basis for the technical realization of a software module of a self-organization for process collectives. Table  2 describes the various classes of the model in more detail. The previously described options for tagging representations of actors, services, process problems, process solutions, and process patterns provide a starting point for the functional specification of this software module.

Fig. 3
figure 3

Class model for tagging as an instrument for self-organization and collective intelligence

Full size image
Table 2 Explanation of the class model
Full size table

6.3 Prototypical Implementation

The architecture of the process management platform as described in Fig.  2 has been prototypically implemented in the context of the research approach, which includes several development cycles. The prototypical development had several purposes:

  • Identification of options for action and technological options: Particularly in the initial development cycles, the prototype development was used as a heuristic instrument to identify new options for action. In this step, the options that have already been discussed in literature represented an initial starting point (see Sect. 1.2).

  • Demonstration of the options for action and the technological options: In addition, the developed prototype demonstrates how the described course of action can be exemplarily implemented using software. Thus, the prototype is used to communicate with potential users by elucidating the options for action in a concrete and vivid way.

  • Evaluation of the options for action and the technological options: Furthermore, the prototype is also used to implement the use cases selected for the research project with the participating industrial partners in order to possess the opportunity to evaluate the outlined options for action.

In the previous Sect. 6.2 we outlined that software systems today are modularized not only at build time, but are also dynamically coupled to a complete system at runtime. In this way, a significantly higher flexibility of the overall system can be achieved. These advantages are exploited in the prototype implementation of the architecture of the process management platform.

The developed prototype is based on several existing components, which are integrated into a tool platform:

  • The ARIS Toolset and the ARIS Web Designer of the IDS Scheer AG function as modeling tools. We integrated this process management tool into the implemented platform since the ARIS Toolset and the ARIS Web Designer are considered as the leading tools for process management. In addition, IDS Scheer was a partner in the research projects described in Sect. 2. Nevertheless, it is in the nature of the platform to consider other tool providers as well. To allow for this possibility, a transition and converter management is especially provided. An essential prerequisite here is, however, that the tool to be integrated offers open interfaces for the model repository.

  • In addition, Skype is used for communication between process participants, Dolphin is used to create social networks, and Delicious is used to manage tags. We chose these components as they offer a variety of open interfaces, are easy to integrate, and are considered to be the leading providers of the respective functionality.

The components used for the implementation are one possible alternative in order to demonstrate the technical feasibility of the described architecture. Due to the loose coupling of the individual components, it is also possible to replace individual components by others.

Fig.  4 visualizes the components of the developed tool prototype. The main component of the prototype is the model management platform COLLMAP, which essentially comprises a model repository for the management of process models and a user interface for web-based model management. COLLMAP accesses the application Dolphin for the management of users and the networking of (Web) profiles. In addition, Skype is integrated into the user management of COLLMAP via profile networking and user linking.

Fig. 4
figure 4

Components of the tool prototype

Full size image

Delicious is also used to tag models and users in the context of the model management in COLLMAP. The use of Delicious allows to identify tags by the use of data sets that are represented in the form of hyperlinks. In Delicious, various tag classes for models and users are prototypically implemented that can be used for the specification of data records. For example, process models or process actors can be searched by the use of tags, and suitable models or actors can be found using Delicious.

The modeling of process models is carried out in external modeling tools (e.g. ARIS Web Designer), which are integrated with COLLMAP via an interface. Furthermore, the prototype includes the independent modeling tool COMOMOD that can be used for the cooperative modeling of process models in real time and supports a cooperative modeling process due to the communication features of Skype. Process models can be shared through a web-based interface between different COLLMAP instances. In this way, process models of a cooperation partner can be accessed across organizational boundaries and initiate collaborative modeling processes.

For the developed prototype we assume that the dynamic systems of action are more or less fully documented in process models, where some operational tasks only need to be named without being “completely” modeled in detail. These process models are provided through the ARIS Web Designer on the modeling platform. The tasks individually described on the HTML pages are thus accessible via Delicious.

Fig.  5 shows the user interface of the realized modeling platform. When accessing the tagging module a window of Delicious opens in which a user can create new tags. The newly created tags are available for a process collective immediately after creation. They can then be used in the modeling platform for the characterization of models.

Fig. 5
figure 5

Development of a prototype for tagging (screenshot)

Full size image

7 Evaluation

The evaluation of results from design-oriented research approaches faces particular methodological challenges (Frank 2006, p. 5 f.). On the one hand, it is necessary to comprehensively examine the actual impact of the identified options for action on process management in as many “real” contexts as possible. On the other hand, in each case the analysis of the effects means a significant intervention into real information systems that can hardly be fully addressed in the context of a research project. Moreover, it remains questionable whether at all a relation of cause and effect can be convincingly demonstrated in such complex interventions in an intersubjective way. At the same time, it is obvious that the “real” success/failure of the identified course of action also depends on factors that can hardly be controlled to a satisfactory extent within the scope of scientific research. For example, a quality assessment of the identified course of action requires a comparison with alternative options from “classical” process management. Such a comparison only seems to be a priori meaningful, if for the new options for action not only prototypes, but tools are available, which have a maturity that can be compared to at least one of the tools available on the market. For the identified options for action, however, so far only prototypes can be used that are clearly inferior to the tools available on the market in terms of e.g. their stability and ergonomics. In order to develop market-ready tools, however, temporal and financial resources are required that are typically not available on the part of science. This interrelationship is impressively documented by Scheer (1994) with regard to the development of the ARIS Toolset. Moreover, it is questionable whether the development of market-ready tools should be a task of science.

Hevner et al. (2004) only inadequately dwell on the outlined evaluation problems of design-oriented research, so that their proposed methods such as “field study” or “controlled experiments” denote interesting ideals of evaluation, but can hardly be effectively achieved by research practice (Frank 2006, pp. 30 f.).

The previously described difficulties reveal boundaries of evaluating design-oriented research. However, this difficulty is not to be taken to mean that the scientific evaluation of the intended effects and of the (unintended) side effects of innovative options for action is not required at all.

Against this background we follow the proposal by Frank (2006, pp. 33–35) to evaluate design-oriented research in an argumentative way using key criteria of academic work:

  • Abstraction: The presented options for action are not based on the specific needs of a particular company, but are motivated from a general perspective. This is also clearly shown by the fact that several industrial partners participate in the research process, the respective boundary conditions of which have been generalized. In other words, we neither designed a specific information system during the research process nor did we develop a concrete marketable product of a process management tool. Instead, fundamental and promising options for the organization of process management and for the development of new tools for process management have been identified.

  • Originality: Real systems take advantage of the options for action of Web 2.0 merely to a very limited extent (Sect. 1.2). Section 5 points out that process management only insufficiently supports dynamic systems of action. The proposed options for process management have to be seen as inventive in this respect. Table  3 provides an overview of the characteristics of process management from the perspective of Web 2.0.

  • Justification: The presented options for action cannot be explained “beyond doubt” by means of formal-logical reasoning. Instead, we argue that corporate systems of action are extraordinarily dynamic (Sect. 4). Prevailing approaches to process management can hardly cope with these dynamics (Sect. 5). From the perspective of Web 2.0, many possibilities open up to organize process management in terms of the design of dynamic systems of action. We outlined possible options for action and a prototypical implementation of a software tool in section 6. The innovative systems of action promise to overcome the implicit assumptions have been described in Sect. 5:

    1. (a)

      No compulsory schematization of all business processes: The presented course of action does not require the schematization of all business processes in process models a priori. Instead, the functionality to manage process actors and process collectives makes it possible to support non-schematized processes as well.

    2. (b)

      Support for exceptional cases: The process actors can annotate the process model with problematic exceptions and selected solutions during process execution. If certain types of exceptions occur more frequently, this can give rise to a revision of the process description.

    3. (c)

      Stronger coupling between design and execution of processes and removal of the conflict between process planning and control as well as process execution: A stronger coupling between the design and execution of processes is determined by an analysis of exceptions that process models can be annotated with. Other starting points consist for example in the provided functionality for cooperative model management. In this way, the conflict between the perspectives of process planning and control (“bird’s eye view”) on the one hand and process execution (“blinkered perspective”) on the other can be mitigated.

    4. (d)

      Opportunities for feedback and tighter coupling between the phases of build time and runtime: Due to the support of exceptions and a stronger coupling between design and execution there is a close coupling between the bodies for process design and process execution. In this way, self-regulatory processes can be installed and the collective intelligence of the process actors involved can be utilized.

Table 3 Process management characteristics from the perspective of Web 2.0
Full size table

Moreover, experiences which have been made in the real application domain with various industry partners as outlined in Sect. 4 give a positive impression. However, we have to admit that the implemented scenarios “only” represent prototype applications for which no “complete” picture of the effects caused by the options for action could be identified.

Finally, it should be noted that while the previous evaluation results argue for the identified options for action, we have to assume that it will hardly be possible to “finally” assess the real impact of the proposed options for action in an early stage of the implementation of the identified options.

8 Summary

Current process management approaches often only partly account for the dynamics of operating systems of action. To that effect, various design options for process management open up from the perspective of Web 2.0:

  • Organizational options for action: Self-organization and the harnessing of collective intelligence are two characteristics of Web 2.0 applications, which can also be utilized in process management. In this contribution we showed that implicit assumptions of process management, such as the necessity for comprehensive schematization of all processes, an insufficient consideration of exceptional cases, and the inadequate coupling between design and execution can be relaxed by the use of self-organization and collective intelligence in process management.

  • Technological options for action: In addition to the organizational options for action we presented an architecture of a process management platform which is characterized by a modular composition of all functions. From a technological point of view, we particularly provided opportunities for self-organization and harnessing the collective intelligence of the actors involved in a process in terms of functions for profile creation, linking and search as well as for tagging process problems, patterns, etc. We also illustrated what a possible prototype implementation of the presented architecture, which also integrates existing components, may look like.

The presented options for action were subject to a first evaluation in terms of an exemplary application in real-world situations taken from the construction industry. Although the evaluation results obtained are very positive, many further questions arise:

  • How can opportunities for the schematization of processes be identified?

  • How can exceptions during process execution be schematized at an early stage? Although schematization can necessarily only take previewed exceptions into account, it has to be examined in particular how process management should efficiently react to unforeseen exceptions.

  • How can typical office applications, such as e-mail, calendar, shared document editing etc. be integrated into useful tools for planning, execution, and control of processes?

  • In what way is it possible to monitor and control processes in dynamic systems of action? What role do software sensors play that provide information about conditions of business application systems and that can be accessed via publicly available interfaces?