Business process modeling cannot be seen isolated from the larger context business process design, engineering and management. We consider business process modeling and the closely related development of graphical representations of process models as a social activity by nature. In this paper we present findings from a series of cross-industry in-depth interviews of practitioners in the domain of business process design and engineering which was found to strongly support this assumption and offers new insights into the collaborative practice of process modeling. To describe the social practice of business process modeling the interview data was analyzed and interpreted using an activity-theoretic perspective. Subsequently, a generic set of recommendations was derived that can be used as a starting point to design software environments that effectively support collaboration in process modeling and (re-)design.
Business process modeling has become a common practice in organizations that have recognized that describing business processes in a structured way is the basis for effective business process improvement. However, business process modeling cannot be seen isolated from it's larger context – business process (re-)design, engineering and management. In this paper process modeling is understood as an activity which is inherently embedded in the context of a process (re-)design activity. Understanding the characteristics of collaboration in process modeling therefore requires to investigate the practice of process (re-)design activities in organizations. We present findings from a series of cross-industry in-depth interviews of practitioners in the domain (domain experts) which was found to support the above assumptions.
We used an activity-theoretic perspective to analyze, interpret and structure the interview data. Finally, a generic set of recommendations was derived that can be used as a starting point to design software environments to support collaborati ve process modeling and (re-)design activities.
The practitioners (domain experts) represent a broad range regarding the industry
(telecom, oil, gaming, banking, insurance, manufacturing, consulting) and role in
process modeling. The practitioners were selected through the professional
network of the author, through a forum of BPM experts and through a telephone
survey in Austria's leading organizations. All interviews except two were
audiotaped and transcribed. In sum twelve interviews were conducted throughout a
three months period. The interviews were conducted using a open-ended
semistructured approach. The interview guideline contained questions to clarify the
experts expertise in the field and questions that addressed the characteristics of
collaboration in process (re-)design activities. As the interviews were conducted
recently this summary of findings has to be seen as preliminary. However, we
were able to identify main concepts prevalent throughout the interview data.
Contextual analysis of process modeling in practice
Activity theory (AT) is an approach that has gained increasing interest in the
research field of computer-supported collaboration (
According to AT an activity is the “minimal meaningful context” to study
individual human actions (Kuuttii, 1992). It is argued that in contrast to individual
goal-oriented actions an activity is driven by a collective motive. It is the collec
tive motive of an activity that makes individual actions meaningful and
understandable (
In the following we will suggest the activity system of business process (re-)design as the minimal meaningful context for studying collaborative process modeling (figure 1). We will discuss analyze and interpret the interview data against the this activity system.
tools software, methods,
modeling techniques, models process (re-)design team “as-is” process (actual process) “to-be” process (changed process) subject object outcome rules community division of work change management governance, project management standards, organizational standards orgasntiazkaetihoonl,dperroscess project plan, roles Principle 1: Collective, artifact-mediated and object-oriented activity system as the prime unit of analysis. A key idea of AT is that an activity is a collective phenomenon emerging through goal-oriented individual actions. Specific goals are subordinate to the collective motive of the entire activity system and only can be understood against this background. In the interviews we found strong evidence that practitioners rather think in terms of process (re-)design activities or even process improvement activities than in terms of process modeling when asked about the collaborative practice in modeling. “Enterprises do not pay for a process modeling activity rather they pay for a process improvement or a software implementation activity” (E09). Similarly the object and outcome of a collaborative (re-)design activity is mostly referred to as the process rather than the process model. Process models were reported to be used mainly as a mediating artifact to support communication, argumentation and validation during design rather than being the primary object of process (re-)design. This is also supported by the fact that almost all interviewees argued that they are quite indifferent about the modeling formalism to be used. Similarly interviewees almost unanimously regard the modeling software to be of minor importance though the documentation and sharing of process descriptions is regarded important. The interview data clearly reveals the importance of coordinative and communicative activities in process (re-)design.
Principle 2: Diversity of community. According to AT an individual subject's actions towards an object or outcome are strongly related to the community it belongs to. In the interviews conducted a general tendency is found that the community that has a stake in a process is generally large. Hence, for specific goals (e.g. elicitation of knowledge and feedback collection) small groups are formed as this is perceived more effective than involving the whole community. Large groups were reported to be only the exception to the rule and were formed only in kick-off workshops where the objectives, motivates and scope of a process (re-)design effort were presented to a larger audience. Three of the interviewees reported that such social events led to an improved awareness of colleagues involved in the same process. “.. I had projects where people participating in an identical process did not know each other, it was only through the kick-off meeting that people spread over different departments and floors got to know each other .. Naturally, it is more difficult to implement small process improvements when people do not know each other .. ” (E02). As the community directly or indirectly involved in a process (re-)design activity is large also multiple points of view, traditions and interests are existent. The analysis of interview data reveals that coordinative activities dominate over creative activities such as modeling. A continuous forth and back (review cycle, feedback loop) between stakeholders and modelers regarding the formalization of a process has been repeatedly mentioned in the interviews. To communicate results of process a variety of representations were reported to be used. Regarding the representational style of process models practice reveals that textual descriptions either unstructured or structured in the form of tables, lists and forms are equally used with graphical representations. “The world is divided .. Our process knowledge portal supports two views. One can see a process both textual and graphical. We have run reports [on the usage of representational styles]. Which reveals a 50 to 50 distribution, who uses what. Personally I prefer diagrams, colleagues prefer tabular representations, because they can use it like a checklist. I prefer to see the big picture, they like to read textual descriptions behind the activities.” (E10).
Principle 3: Historicity of activity system. Activity systems carry with them a history that reflects the experiences of the individuals involved. Following AT the knowledge and experiences of a community are engraved in the artifacts it produces. In fact, several interviewees referred to historical aspects in order to explain why process (re-)design is performed in a specific way, e.g. why they use a specific methodology, modeling technique, notation or software. For example, one interviewee reported that they shifted from a centralized approach of process documentation with a single repository of process models and a single modeling technique to a decentralized approach were the main organizational units can autonomously decide how to conduct a process (re-)design effort. Another interviewee reported that he has to adjust the terminology used in process (re-)design projects as some individuals have had bad experiences with process re-engineering approaches in the past. “Process management is fashionable today and commonly accepted. But until a year ago some people did not even want to hear the word 'process' as this was associated with consultants drawing some odd process charts .. ” (E07). Several interviewees give evidence that maintaining a revision history of process models is not valued as a source of knowledge for process (re-)design. Rather, process documentation is maintained in accustomed document management systems.
Principle 4: Contradictions as sources of change and development. Contradictions result from incompatibilities between the elements of an activity system. Contradictions are the driver for situational adaption of an activity system. For example, a modeling tool may not fulfill the requirements of a process (re-)design activity as notational elements to model organizational units are missing. Also conflicts may arise between stakeholders regarding the granularity (details to include) in the model. Contradictions emerge as well when stakeholders have to come to an agreement regarding a newly designed process. However, in the interview data we found evidence that process design takes place in an highly iterative manner between stakeholders and modelers. Thus, interviewees did not mention severe conflicts during process (re-)design to be an issue. Another example mentioned by interviewees is the gap between the stakeholders required and the stakeholders having capacity to participate in a process (re-)design effort. All these contradictions may influence the course a collaborative (re-)design activity takes, whether models are accepted and reused by a community.
Principle 5: Expansive transformations in activity. As contradictions may become aggravated over lengthy periods of time individuals begin to question established artifacts, norms, rules and procedures. Therefore an activity is evolving into a new activity system. For example, in two cases it was reported that rigid implementation of process governance standards failed due to the resistance of departments which did not follow the standards due to reasons of inadequacy and fear of transparency. This led to a more flexible and decentralized approach where departments were able to adapt corporate conventions to their needs or to use their own conventions and tools. Other practitioners pointed to the fact that they have gradually adapted the software tools used for process modeling and maintenance as tools did not meet specific requirements. The same is experienced with project methodologies or workflow procedures determining the way a community collaborates in a re-design activity.
In the preceding section we have used Activity Theory (AT) to identify and
discuss the minimal meaningful context of process modeling – business process
(re-)design. Though, only selected issues have been outlined in this paper we
found that for understanding collaboration in process modeling especially the
non-expert/expert interaction, diversity of the community and the developmental
character of process (re-)design a has to be investigated in more depth. In future
research activities we will use these findings to derive general guidelines for
designing respective software environments. In table 1 a set of six recommendations
is suggested which is not meant to be complete but can be seen as complementary
to other work in the field
R1: Integrate the larger context of process modeling. E.g. a process improvement, change management, requirements elicitation, system development, .. (← P1) R2: Support the shift from close (face-to-face, synchronous, co-located) to loosely coupled (asynchronous, distributed) collaboration in process (re-)design (← P2) R3: Provide means to use diverse representation styles, notations and tools for describing a process for a diverse community of stakeholders (← P2) R3: Provide mechanisms that allow the interaction with process models for a broad community and at the same time ensure the stability of process models (← P2) R3: Support the shift from initial process model creation activities to long-term process model maintenance (← P1, P3) R4: Support the smooth adaption of process modeling techniques and tools to situational needs (← P4, P5) R6: Consider the twofold nature of process models being primarily a mediating artifact for the design activity and the object of modeling (← P1, P4)